Windows Server 2012 Installation Options

Windows Server 2008 was a huge release, not because of features such as Failover Clustering or Hyper-V, but because of how Windows Server is installed and managed. Changes to these processes in Windows Server 2008 affected every aspect of every installation.

Windows Server 2008 introduced three major technologies that have continued to evolve and become even more important with each new release—especially Windows Server 2012:

In this article, I focus on Server Core and some of its complementary technologies in Windows Server 2012.

A Brief History of Server Core

Server Core became an installation choice with Windows Server 2008. Installers could select either a Server Core installation or full installation. After initial selection, this setting couldn't be changed without reinstalling the OS. Both installations provided the same Windows OS with the same kernel, performance capabilities, registry, and authentication. However, Server Core provided a minimal OS environment that included only those components that were required to enable the server to run key infrastructure roles. In addition, the functionality of these roles was enhanced by many supported features.

What was missing from Server Core was the .NET Framework (which also meant no PowerShell), Windows Explorer (which meant no Start menu, system tray, or taskbar), Microsoft Management Console (MMC), Server Manager, Internet Explorer (IE), and two Control Panel applets (International and Date/Time). On the plus side, Notepad, the registry editor, and Task Manager were still available. For more details about the issues surrounding the Windows Server 2008 version of Server Core, see the sidebar "Server Core's Past."

Fortunately, Windows Server 2008 R2 moved Server Core forward in every way. Not only did Server Manager become remoteable (i.e., it could be used to remotely manage a Server Core installation), but the.NET Framework was broken up, allowing a subset of .NET Framework 2.0, 3.0, or 3.5 to be made available on Server Core. This change enabled support for PowerShell on Server Core and a subset of ASP.NET for Microsoft IIS. In addition, Server Core supported the Active Directory Certificate Services (AD CS) role and File Server Resource Manager (FSRM). In addition, many more management agents began to run on Server Core. (In fact, being able to run on Server Core became a logo requirement for management agents.)

What didn't change between Windows Server 2008 and Windows Server 2008 R2 was Server Core's focus: It was still targeted at specific infrastructure roles. And the choice of Server Core or a full installation had to be set at installation time and couldn't be changed without reinstalling the OS. Server Core was no option for application roles, and many organizations struggled with adopting it because of concerns about initial server configuration, lack of a GUI, and possible problems troubleshooting without a GUI.

Windows Server 2012 Server Core

Windows Server 2012 takes Server Core mainstream, emphasizing its focus as the configuration level of choice, whenever possible, for Windows Server installations. That's right: We now think in terms of configuration levels for Windows Server. Server Core is still one option, as is a full installation—now called the Server with a GUI configuration level—but there are others. Server Core is now the default configuration level. Rather than thinking of Server Core as a lesser OS, think of it as the core server OS, available in additionto a version with a GUI.

There are many improvements in Server Core with Windows Server 2012. Additional supported infrastructure roles and role services include Windows Software Update Services (WSUS), Active Directory Rights Management Services (AD RMS), Routing and Remote Access Services (RRAS),Remote Desktop Connection Broker (RD Connection Broker), Remote Desktop Virtualization Host (RD Virtualization Host), and Remote Desktop Licensing (RD Licensing). Nearly all Windows Server roles are now supported on a Server Core installation.

In its position as the preferred configuration level for servers, Server Core is no longer just for infrastructure roles. With Windows Server 2012, Server Core can also be thought of as a platform for running applications. Many applications are already making this switch, including SQL Server 2012, which now runs on a Server Core installation. As I mentioned earlier, one logo criteria for Windows Server 2012 applications is a minimal server interface that allows execution on Server Core. This alone should drive application vendors to add full support for Server Core in future versions of their products.

Windows Server 2012 puts a much greater emphasis on remote management. This is why the actual server OS doesn't need a rich GUI locally. Look at both Microsoft and third-party products: The provided management interfaces are becoming graphically richer and richer, which can consume a lot of resources and therefore ideally should not be running on the server anyway. The design goal of Windows Server 2012 is that it should be managed remotely from a Windows 8 client or a dedicated management Windows Server 2012 installation. This remote-management design goal explains why remote management is enabled by default on a fresh Windows Server 2012 installation, allowing remote management without additional configuration. (Note that remote management means that the server can be managed remotely, not that Remote Desktop Services is enabled by default.)

The emphasis on Server Core, the ability to use it as an application platform in addition to an infrastructure platform, and the benefits of reduced patching are all great. But remember that many organizations' fundamental objections to Server Core were the initial setup of the OS (using the command line), ongoing management effort, and troubleshooting situations. For these organizations, there is good news in Windows Server 2012. The GUI and management tools can be added or removed from a server installation at any time, requiring only a reboot to complete the switch. The installation choice between Server Core and Server with a GUI is no longer set in stone. Figure 1 shows the Remove Roles and Features Wizard as I remove the Graphical Management Tools and Infrastructure and the Server Graphical Shell features from my Server with a GUI installation.

Figure 1: Management Tools and Graphical Shell

After this server reboots, it will be at the Server Core configuration level. None of the applications or configuration will be lost. You can see more of this process in the accompanying video.

One change in Server Manager in Windows Server 2012 (other than the completely redesigned UI and the ability to manage groups of servers) is that roles and features can be added and removed remotely. Now the switch from Server Core to Server with a GUI and vice versa can be made remotely. Even if a server is in Server Core configuration, it can be switched to Server with a GUI by using Server Manager, running remotely. This task can also be accomplished from PowerShell and the command line. But before I go into those details, I want to elaborate on configuration levels.

Configuration Levels

I mentioned earlier that there are more configuration levels than just Server Core and Server with a GUI. There are actually four configuration levels, although only three are used for most server installations. These configuration levels are shown in Figure 2, along with the components that you can add to Server Core to reach the various levels.

Figure 2: Four Levels of Configuration for Windows Server 2012 Installation

The Server Core component forms the base installation or configuration level, providing the key Windows services. On top of this foundation, various components can be added to change the configuration level. For example, adding the Server-Gui-Mgmt-Infra and Server-Gui-Shell components brings a server to the Server with a GUI configuration level, providing the full graphical and local management-tool experience.

This separation of the graphical shell from the management infrastructure provides additional options. Although the Server-Gui-Shell component includes Explorer.exe, IE, and the Start Screen (i.e., the graphical shell), it is the Server-Gui-Mgmt-Infra component that contains all the management tools and management infrastructure (i.e., MMC, Server Manager, and other internal components that many applications rely on). A Windows installation that has the management infrastructure but not the graphical shell installed is referred to as a Minimal Server Interface installation.

In Figure 2, you can see that the Server-Gui-Mgmt-Infra component is larger than the Server-Gui-Shell component. The reality is that Server-Gui-Shell contains only around 300MB of binaries, whereas Server-Gui-Mgmt-Infra contains around 4GB of binaries. This difference gives you a good indication of why a pure Server Core installation should be the desired end goal. Think of the Minimal Server Interface installation (with Server-Gui-Mgmt-Infra) as a full installation without the shell; the Server Core is the true stripped-down OS installation.

What does this new-found flexibility mean for the Server Core configuration level? Think of prior objections to using Server Core, specifically the pain of initial configuration and troubleshooting without a GUI. (Ongoing management with a GUI is no longer an issue because management will be performed remotely via Server Manager and other graphical tools, as previously discussed.) The ability to add and remove the graphical shell and management infrastructure at any time means that administrators performing manual installations and initial configurations can install a server at the Server with a GUI level, perform the configuration, then remove the shell and management infrastructure for the server's normal operations. If during these operations a problem is encountered and needs to be troubleshot locally on the server (something that shouldn't often occur), and if the lack of local graphical shell and management tools hinders progress, then the administrator can add back the shell and management tools, troubleshoot and resolve the issue, then remove the shell and tools again.

I've not yet mentioned the final component (and configuration level), Desktop-Experience, because very few servers will need it. Desktop-Experience, as the name suggests, gives a server the experience that's associated with the Windows 8 client OS. This experience includes elements such as Windows Media Player and its associated codecs, photo management, and Windows Runtime (WinRT). This latter component allows the execution of Windows 8 Modern (aka Metro) applications that use the new WinRT, including access to the Windows Store. Very few servers need or should want this capability; the exceptions are a specific Microsoft Exchange role that needs the media codecs and people who use the server OS as their desktop OS. (And now that Windows 8 has Hyper-V built in, that shouldn't be necessary.) Remote Desktop Session Host (RD Session Host) also uses Desktop-Experience to give users a richer experience.

Using PowerShell or the Command Line to Switch Configuration Levels

Figure 1 showed the graphical way to add and remove the various features that make up the configuration levels. You can also use the command line and the Deployment Image Servicing and Management (DISM) command-line tool. Or you can use PowerShell and the Install-WindowsFeature and Uninstall-WindowsFeature cmdlets. DISM uses slightly different feature names than PowerShell, so stick to using PowerShell when possible.

The following code shows the use of DISM to switch from a Server with a GUI installation to Server Core:

Dism /online /disable-feature /featurename:ServerCore-FullServer

The following code shows the use of DISM to move from Server Core to Server with a GUI:

Dism /online /enable-feature /featurename:ServerCore-FullServer  /featurename:Server-Gui-Shell /featurename:Server-Gui-Mgmt

The following command uses PowerShell to switch from Server with a GUI to Server Core. Note that with this method, only Server-Gui-Mgmt-Infra needs to be removed; doing so automatically removes Server-Gui-Shell, which is dependent on Server-Gui-Mgmt-Infra.

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -Restart

To use PowerShell to switch from Server Core to Server with a GUI, use this command:

Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell -Restart

You can simply add Server-Gui-Mgmt-Infra to switch from Server Core to a Minimal Server Interface installation:

Install-WindowsFeature Server-Gui-Mgmt-Infra -Restart

Or you can remove Server-Gui-Shell from a Server with a GUI installation to switch to a Minimal Server Interface installation:

Uninstall-WindowsFeature Server-Gui-Shell –Restart

All this flexibility in configuration level is great, but which level is right for you? Aim for Server Core, and make sure that you have management agents such as backup, monitoring, and malware that run on Server Core. Run all the infrastructure roles and server applications that are supported on Server Core.

For server applications that don't run on Server Core, use a Minimal Server Interface installation (i.e., use the management infrastructure but not the graphical shell). I've seen many software installers that have GUI and IE dependencies, but once installed, the app runs fine on Minimal Server Interface. If something isn't installing, it might be an installer issue, so convert to Server with a GUI, install the application, and then convert back to Minimal Server Interface. If an application has dependencies on the graphical shell, then you'll need to run it on the Server with a GUI configuration level. However, many applications should eventually develop management tools that can run remotely, with no dependencies on the graphical shell or management infrastructure.

No matter which configuration level you use for a Windows Server 2012 system, manage it remotely. Your Windows Server 2008 R2 and Windows Server 2008 servers can also be managed remotely, using the Windows 8 Server Manager, providing that they have Windows Management Framework 3.0 installed.

Watch the Kilobytes

In England, there's a saying: Watch the pennies, and the pounds will take care of themselves. Basically, this means that if you're responsible with your money at the lowest level, the bigger finances will be fine. The same idea applies to disk space: Watch the kilobytes, and the megabytes will take care of themselves. In other words, be responsible at the server level, and your overall disk usage should be fine. This brings me to another change in Windows Server 2012: Features on Demand.

If you've ever managed Windows NT Server 4.0, then you know the "pleasure" of needing to insert the installation media and reinstall service packs every time a new service is enabled. This routine went away with Windows 2000 Server, when Microsoft decided that the management and time savings were worth the extra disk space for the OS installation. The solution introduced with Windows 2000 was to copy the entire OS and all possible services (now called roles and features) to the server's hard disk, storing them in the WinSxS folder (side-by-side assembly). When a service is enabled, the files are simply taken from the WinSxS folder; no installation media is required. When a service pack is applied to a server, all files in the WinSxS folder are patched, so if a service is later enabled on the server, there is no need to reapply the service pack.

However, in a few very specific instances, reducing the disk footprint of an installation might be more important than saving management effort. Imagine having 300 instances of the same virtual machine in a virtual environment, such as an IIS load-balanced farm. In such a case, the gigabytes of additional disk space used for the (unlikely to ever be needed) binaries of each instance add up to a huge amount of additional required storage. Another example is placing Windows Server 2012 on a small storage device, such as on a motherboard. In this case, minimizing the disk footprint is crucial. Windows Server 2012 allows roles and features to be removed from the WinSxS folder, reducing the disk footprint. This removal is performed by using the PowerShell Uninstall-WindowsFeature cmdlet with the -Remove parameter

Uninstall-WindowsFeature  -Remove

or by using DISM with the /remove switch

Dism /online /disable-feature /featurename: /remove

If an installation has had a role or feature removed from the disk and then tries to add the role or feature, then by default Windows Server downloads the required binaries from Microsoft Windows Update servers on the Internet. Alternatively, you can specify the WinSxS folder of another server, the Windows Server installation Windows Imaging Format (WIM) file from the installation media, or a share with the contents of the extracted installation WIM file. This can be specified as part of the removal command, set as the default in the server registry (via the HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesServicingLocalSourcePath value), or set using Group Policy.

This functionality should not be used as a default part of server installation but should be reserved for very specific use cases, as I already mentioned. Although saving disk space might seem like a good idea, the additional issues you might encounter if roles or features need to be added in the future can outweigh the disk-space savings unless reducing space is a necessity.

A Rewarding Shift

I don't want to underplay the scale of these changes—especially configuration levels: It's big. Many organizations will still manage each server locally by using RDP and running all configurations directly on the server. Remotely managing and using Server Core is a huge change, but organizations that make the shift can reap large rewards with simplified patching and management.