While working with one of my consulting colleagues recently on some Windows Server 2012 installations. There was an application requirement to install Media Player onto a couple of the servers. This met with some muttering and cursing from the nearby fabric covered box as the option to install the Desktop Experience feature is not as obvious as it was on Windows 2008 R2, highlighted below.
Using the GUI To Install PowerShell
I’m sure there is an oxymoron in there if you look hard enough!! If you want to just drive the GUI to install the Desktop Experience feature through Server Manager you have to expand the User Interfaces and Infrastructure feature and select the Desktop Experience component. So yes, it’s a little bit more hidden but you don’t have to be Indiana Jones to discover it..
This is shown in the screenshot below:
Update 28-10-2013: Added PowerShell example to install Desktop Experience
Installing Desktop Experience Using PowerShell
So that’s all nice, but what if we did not know that the Desktop Experience feature was located in that area? PowerShell to the rescue!!!!
Probably my favourite installation features in Windows Server 2012 are the Get-WindowsFeature and Install-WindowsFeature cmdlets.
What makes these cmdlets even more powerful, is that they accept wildcards as input. So in our case we can look for something called *Desktop*
Get-WindowsFeature *Desktop*
That’s pretty neat, and we can then see exactly where the Desktop Experience feature is located. The same goes for the GUI options that are present in Windows Server 2012:
Get-WindowsFeature *GUI*
We could then install it via Install—WindowsFeature.
So as an example, we could use the following PowerShell oneliner to install Desktop Experience:
Install-WindowsFeature Desktop-Experience
For those folks out there who used the Windows 2008 R2 cmdlets, you will have noted that I specified Install-WindowsComponent above and not Add-WindowsFeature.
This is because the cmdlet is Install-WindowsFeature. Add-WindowsFeature is an alias to Install-WindowsFeature. We can see this with the Get-Alias cmdlet:
Get-Alias Add-WindowsFeature | FL
Checking Computers Remotely
Using wildcards is neat, and can make administration quicker and faster. What makes this even more efficient is that Windows 2012 now has a ComputerName parameter so we can directly query a remote machine. Additionally we do not have to manually import the ServerManager module in Windows 2012 either. In the example below DC-1 is the local machine which then queries a remote computer called Server-1:
Installing PowerShell On Upgraded 2008 R2 Core Server
PowerShell is not installed by default onto a Windows 2008 R2 core installation. Most customers will install it unattended or manually since the addition of PowerShell was a great new Feature in Windows 2008 R2. One of the machines that was previously upgraded did not have PowerShell enabled on 2008 R2 and after the upgrade to Windows 2012 it was still not fully enabled.
OCLIST on 2008 R2 will show us the initial state, prior to upgrading
On Windows 2008 R2 the Sconfig tool was one way that PowerShell could have been enabled.
I noted that a clean 2008 R2 Core VM when upgraded to 2012 was not able to run PowerShell as the feature was not present.
Checking the installed components locally with DISM showed
Dism.exe /Online /Get-Features
Checking the installed components remotely shows that the PowerShellRoot is installed, but PowerShell itself is not installed.
To Check remotely from PowerShell we can use a separate machine, and we specify the –ComputerName parameter with the name of Server-10 which is the name of the upgraded 2008 R2 core machine.
Compare this to the below (a server with the GUI installed) and note that PowerShell is installed on the example below but not on the upgraded server shown above.
Since PowerShell is not installed we cannot use Add-WindowsFeature to install It locally, since it’s chicken and egg time….
DISM is still present so we can enable the feature using it:
DISM.exe /Online /Enable-Feature /FeatureName:MicrosoftWindowsPowerShell
Alternatively we could have used a remote Server 2012 machine, and specified the upgraded box using –ComputerName and installed PowerShell that way. This is shown below along with the –Restart parameter which automatically restarts the machine if required:
Logging off and back on to re-spawn the cmd prompt then allowed PowerShell to be launched.
Conclusion
One little cmdlet, but it’s so very powerful. You could change the above syntax to suit your requirements. PowerShell will show you the name of the feature, and now you can add it remotely and also restart the target machine when the installation is complete. As Bill & Ted would say – Excellent!! **
Cheers,
Rhoderick
** PS – Looks like a third film is planned. Hopefully this will be better than the proposed Highlander reboot……
You just saved my ass 🙂 You ALWAYS rock!!!