Even More about Windows Server Core 2012 and GUIs

I’ve written a bit recently about Server Core in Server 2012. But here’s yet more details. In Server 2012, the GUI is an installable feature – one you can add or remove. There are actually three levels of GUI within Server 2012:

• Full GUI – the full blown Windows Server GUI as we’ve always known it plus the Metro start panel, etc.
• MinShell – a partial GUI but one that enables you to run things like Server Manager, some control panel applets,MMC consoles and PowerShell ISE.  But no desktop/Metro Shell and no IE.
• None – The server core GUI as we love it – but with the opportunity to specify PowerShell as the window to open at boot (or when you RDP into it).

This provides a great compromise – you can have the GUI where you need it and remove it when you don’t. I love that – although not all applications will run on MinShell or Server Core itself. You need to check – but increasingly applications are server core friendly! For both MinShell and Server Core, the default is to run CMD.EXE as the default shell – when you logon to a server core box you see CMD.Exe. You can fix that easily enough so that at boot time you get PowerShell instead – a simple registry fix.
As part of the Launch of Server 2012 here in the UK next week, I’ll be presenting a bit on PowerShell and showing some of what it can do. One aspect of the server we are showing is Server Core and I’ll be demoing how easy it is – I wrote a script for that:

Function Set-GUI {  
[Cmdletbinding()]
Param(
[ValidateSet("Full", "MinShell", "None")]
[String] $GuiType = "Full"
) # Here check what to do and do it Switch ($GuiType) { "Full"     { Add-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
             $RegPath = "Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon"
             Remove-ItemProperty -Path $RegPath -Name Shell -ErrorAction SilentlyContinue –Force
           } "MinShell" { Uninstall-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra  # Just in case
             Add-WindowsFeature Server-Gui-Shell
             $RegPath = "Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon"
             Set-ItemProperty -Path $RegPath -Name Shell -Value 'PowerShell.exe -noExit -Command "$psversiontable"'  -Force 
           }
"None"     { Uninstall-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra
             $RegPath = "Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon" 
             Set-ItemProperty -Path $RegPath -Name Shell -Value 'PowerShell.exe -noExit -Command "$psversiontable"'  -Force  }Default    {"$GuiType unknown - enter Full, MinShell or None"; return
           }
} # Finally Reboot into new gui mode!
Restart-Computer
} # end of Set-GUI function

This could usefully have been added into the ServerCore Module!

Technorati Tags: PowerShell,Server 2012 Server Core

More on PowerShell on Server Core

PowerShell and Server Core – Server 2008 R2 and 2012

in July, I wrote a few articles on PowerShell in Server core (here, here, and here). There were two key points noted in those articles. First, Server Core in Server 2012 has a removable GUI – you can add it or remove it! Secondly, in Server Core in Server 2012, by default, the system starts up running CMD.EXE, not PowerShell, although there’s a simple registry hack that enables you to run PowerShell instead.I’ve been playing with this a bit and have discovered a few additional things about Server Core and PowerShell.

Adding PowerShell v3 to Server 2008 R2 Server Core

The first interesting thing I’ve found is that you can add PowerShell V3 to Server 2008 R2 Server Core. However, to do that, you need to add the .NET Framework 4.0 to your server core system. Go to the Microsoft Download centre and download the Microsoft .NET Framework 4 (Standalone Installer for Server Core. Your Server Core installation needs to be running SP1 or higher. Read the instructions carefully!

Adding GUI to Server Core – Which Shell to Run

In one recent article, I noted how you could add and remove the GUI from Server Core. I’ve written two functions (Enable-GUI and Disable-GUI) that convert between the two GUI modes. I’ve tested these functions pretty thoroughly and the adding and removing of the GUI is straightforward, albeit on the slow side.

One thing I found is that if I first set PowerShell as the default shell (see here), then add the GUI, when Windows Server 2012 restarts, you have the GUI, but the shell itself doesn’t start – PowerShell runs as the default shell!  It took me a few minutes to work out what was going on. A very simple workaround is to remove the Shell default value from the Registry before rebooting. The code to add the full GUI back to Server core now looks like this:

Install-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra -Source d:\sources\sxs
$RegPath = "Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon"
Remove-ItemProperty -Confirm -Path $RegPath -Name Shell -ErrorAction SilentlyContinue

To get the full scripts see here (for Enable-GUI) and here (Disable-GUI).

Technorati Tags: PowerShell v3,Server 2012,Server Core

More on PowerShell as the Default Shell in Server Core 2012

Yesterday, I posted an article showing how easy it was/is to change your default shell inside Windows Server 2012’s Server Core installation option, and I’ve been playing around with it a bit more. I also noticed Paul Gregory’s blog post on the subject.

The shell that Windows Server 2012 uses to determine which shell to run is at: Hklm:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon" in the Shell item property.  In Server 2012, this is set, by default, to Explorer.exe. I’m still not quite sure how Explorer knows to load CMD.exe, but it seems to!

To change the shell is simple – just run a variation on: Set-ItemProperty -Path $RegPath -Name Shell -Value 'PowerShell.exe'.

By some variation – I mean you can, in the value entry, specify parameters to PowerShell at startup. If you just want a plain old shell, with all 4 profile files attempted, then leaving the Shell value to just “PowerShell.exe” is fine. But here are some other parameters you could also specify:

• -MTA, –STA – you can specify to always start up PowerShell in a single threaded or multithreaded apartment. –STA is the default, but if you always need an MTA on a given server, you can.
• -PSConsoleFile – you can create a console by configuring PowerShell the way you want it to run, then use Export-Console. This might be useful on a single function server to pre-load specific modules, but you’d need to work out how to manage the exported console (where do you put it, how do you update it, etc).
• -NoProfile – speeds up startup, and is arguably a tad safer. You could theoretically get your profiles ‘infected’ – this option avoids such malware running.
• -EncodedCommand – accepts a base-64 encoded string – useful if you have to pass a command to PowerShell that requires complex quoting, and use of braces ({}).
• -Command, –NoExit – you can get PowerShell to run a command, over and above the profile files by specifiying the Command parameter. If you use the Command parameter, you should also specify –NoExit to avoid PowerShell from running the command and immediately exiting!
• -Version – starts a specific version of PowerShell. This is useful to get PowerShell to start up in V2 on Server 2012, where V3 would of course be the default.

There are a few more parameters, but those are the key ones.

 

Technorati Tags: Server2012,PowerShell,Server Core

Making PowerShell the Default Shell in Server 2012 Server Core

Server Core, in Windows Server 2012, is a much improved version of this installation option, first introduced in Windows Server 2008. At the time Server Core was first introduced, it made sense to make CMD.EXE the default shell. Heck – PowerShell could not even run in that environment. But times move on and in Windows Server 2012, Microsoft install PowerShell by default in Server Core. But the legacy of CMD.EXE still remains – at least by default
.
Turns out it’s just a registry setting to tell Winlogon what shell to start-up at boot time. Thanks to a post by Jeff Hicks, I knew where in the registry the key was, and thanks to James O’Neill, I knew what to put in the value! Setting it is then remarkably easy:

$RegPath = "Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon"

Set-ItemProperty -Confirm  -Path $RegPath -Name Shell -Value 'PowerShell.exe -noExit -Command "$psversiontable'

Restart-Computer

After rebooting – you have PowerShell as your default shell in Server Core. If you are brave, you could just even the –Confirm from the Set-ItemProperty!

Technorati Tags: Server 2012,PowerShell,Server Core

Adding (and removing) the GUI From Server Core in Server 2012

One (of the very many!) neat feature of Server Core inside Windows Server 2012 is the ability to add/remote the GUI. This is a feature I wanted since Microsoft first brought out Server Core.  To add or remove the GUI in Server Core, you need to run a cmdlet from the DISM module. To Add the GUI to Server core:

Enable-WindowsOptionalFeature –Online –NoRestart `
  -Featurename ServerCore-FullServer,Server-Gui-Shell,Server-Gui-Mgmt 

Removing the GUI is equally as simple:

Disable-WindowsOptionalFeature –Online -NoRestart `  
  -Featurename ServerCore-FullServer, Server-Gui-Shell,Server-Gui-Mgmt 

I’ve written a couple of functions that do this for you – posted over on my PowerShell Scripts blog.
This is pretty cool – and it works incredibly easily. This allows you to install a server core machine, add the GUI for initial setup or subsequent troubleshooting but then easily remove it for production running. Another GREAT Server 2012 Feature enabled with PowerShell!!

[Later]

Thanks to Scott R for noting a typo in this post - now fixed!

Technorati Tags: Server 2012,PowerShell,GUI,Server Core

PowerShell V2 Release Timescales

In yesterday’s PowerShell related blog entry, I noted that the next CTP for V3 is coming very soon. Like the child sitting in the back of the car on a long journey, I just want V2 to be here now. But despite wanting it, and frankly expecting it by now – it’s not here and won’t be for a wee while (i.e. around a year from now). At one level that’s bad, but at several others, it’s good as I explain in this post!

First the basic release news. On his blog, super-star and good friend Dmitry Sotnikov sets out the dates that Microsoft announced at TechEd EMEA. Namely:

• CTP3 - Dec 20087 CTP 3. NB: this may be called Beta 1
• RTM – in Windows 7 and Windows 7 Server (aka Windows 2008 Server R2), when that ships. Late 2009 or Early 2007.
• RTM – for XP, 2003, Vista and Server 2008 (RTM) – a few months after that, V2 will be available for download to these older OS versions.

So the final versions of V2 won’t be here for at least a year, and possibly longer for those of us using legacy OSs. So that’s the “bad” news. I also expect V2 to be baked into Exchange 14, so may ship early if for some reason Exchange 14 ships earlier. We’ll know more about the Exchange 14 time scales in due course.

So that sounds bad. It’s life – things take longer than we’d like! But there’s also two bits of good news.

First, there will be more CTP releases. CTP3 has a AWESOME set of features. While we wait to get the final version, the CTPs will allow us PowerShell addicts to have some fun, and develop stuff that will prove even more valuable once RTM occurs. For example, all the scripts over on the PowerShell Scripts blog should all work just fine on V2 – and going forward, some will require V2 or a pre-release of V2 to run (well probably!). So in the short time, there’s plenty of updated features to get to know and leverage.

But the really good news is that PowerShell is now a fully fledged Feature within Windows. Whilst many of us probably think this should have happened with Server 2008/Vista, but that did not happen. Being a Feature means PowerShell is just as important to the overall product as say the file system, the kernel or the fail-over clustering component.

This means that going forward, we’ll see PowerShell align with OS release schedules. Just as there are not major updates of say Active Directory, File sharing, or Failover Clustering outside of a full OS release, there is far less likely to be any major updates to PowerShell outside major OS releases. Thus, we’ll see updates at around the 2 year cycle at best. That is provides the team with a much clearer time frame in which to produce V3, V4, etc.

The reason this is good, is that other OS Win 7 feature teams can take dependencies on PowerShell V2 in order to produce new Cmdlets, etc, knowing that V2 will be ready and will ship at the same time! This also means a whole lot more testing – testing all those cool upcoming cmdlets with PowerShell V2 code. While all the recent releases of PowerShell have been pretty reliable, the more testing the better! And of course, since ISVs can now count on V2, they can target new product releases to run on R2 and can make PowerShell support part of their tool kits.

We’ll also see another important thing in Windows 7/Server 20098 R2 – PowerShell in Server Core. Horray! This to my mind enables a much more unified admin experience (or darn well better!) for Server core. The mixture of obscure command line utilities and near-random VB Script files was just awful. With PowerShell, things should be a whole lot easier. And where there are existing tools that continue to be valuable but are obscure, the community can develop wrappers (i.e. PowerShell Functions or scripts) to vastly simplify the use of those tools. All in all, this represents a great step forward!

So while I really wanted V2 by now, waiting another year or so really isn’t that bad. It’s a wait that I find OK – the result is worth it. I’m pretty excited about the potential. Or should I say I’ STILL pretty excited about the potential.

Technorati Tags: PowerShell,PowerShell V2,Windows 7,Server 2008,Server Core