This is an updated version of the original Windows Server 2012 post. The genesis of which was an application requirement to install Media Player onto a couple of servers. This met with some muttering and cursing from my colleague in 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 which is 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 Jonesto discover it..
This is shown in the screenshot below:
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 newer versions of Windows are the Get-WindowsFeature and Install-WindowsFeaturecmdlets.
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 R2:
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 Install-WindowsFeature was used rather than Add-WindowsFeature.
Get-Command *WindowsFeature*
This is because the 2012 R2 cmdlet is Install-WindowsFeature. Add-WindowsFeature is an alias to Install-WindowsFeature. We can see this with the Get-Aliascmdlet:
Get-Alias Add-WindowsFeature
Checking Computers Remotely
Using wildcards is neat, and can make administration quicker and faster. What makes this even more efficient is that Windows 2012 R2 has a ComputerNameparameter 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:
The 2012 version of this post has an additional section about a specific issue to allow Installing PowerShell On Upgraded 2008 R2 Core Server.
Conclusion
One little cmdlet, but it’s so very powerful. You could change the Get-WindowsFeature 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 & Tedwould say – Excellent!! **
Cheers,
Rhoderick
** PS – Looks like a third film is still planned. Hopefully this will be better than the proposed Highlander reboot……
Wikipedia has updated the remake section since the original version of this post was published.
Thanks, you are the man!