Windows Server 2008 R2: Get the Most from Server Core

Article
09/08/2016

Server Core is a basic, no-frills way of maintaining your Windows environment. If you’re not familiar with it yet, you soon will be.

Brien M. Posey

It’s easy to dismiss Server Core as a watered-down version of the full Windows OS. Microsoft has stated, though, that Server Core will be the preferred deployment type for Windows Server when Windows 8 is released. That being the case, it makes sense to start using Server Core right now. Get comfortable with Server Core in the current edition of Windows Server so the experience won’t be quite so foreign once Windows 8 arrives.

Why Use Server Core?

Microsoft provides a perfectly adequate interface for Windows Server, so you might be wondering why you’d even want to bother with Server Core. Besides laying the groundwork for Windows Server 8, there are three significant advantages to using Server Core:

Server Core has a reduced attack surface. Server Core has a much smaller footprint than a full-blown Windows Server deployment, which translates directly into a smaller attack surface.
Server Core is great for virtualization. Because Server Core has a smaller footprint than Windows Server, it also consumes fewer system resources. This makes Server Core ideal for use in a virtual server environment where making efficient use of hardware resources is essential.
Server Core helps reduce maintenance. Server Core deployments require fewer patches and fewer patch-related reboots than full Windows Server deployments. In fact, Microsoft estimates that you could eliminate about 59 percent of forced, patch-related reboots by using Server Core.

Choose Appropriate Server Roles

One of the most important best practices to keep in mind when deploying Server Core is to choose server roles carefully. Even though Server Core should prove much more capable in future versions of Windows Server, the Windows Server 2008 R2 version of Server Core is currently only capable of hosting specific server roles. These roles include:

Active Directory Certificate Services
Active Directory Domain Services
Active Directory Lightweight Directory Services (AD LDS)
Dynamic Host Configuration Protocol (DHCP) Server
DNS Server
File Services (including File Server Resource Manager)
Hyper-V
Print and Document Services
Streaming Media Services
Web Server (including a subset of ASP.NET)

Reduce the Server Core Footprint

It’s easy to think of Server Core as a minimal OS without all the bloat commonly associated with a full deployment. Believe it or not, though, Server Core does have some excess baggage. You might be able to reduce the Server Core footprint even further by eliminating certain functions.

If you think back to the original Server Core release in Windows Server 2008, you’ll recall it didn’t support Windows PowerShell. Windows PowerShell support was added in Windows Server 2008 R2. Of course, Windows PowerShell depends on the Microsoft .NET Framework, which is also present in the Windows Server 2008 R2 version of Server Core.

As you can see, since its inception, Server Core has grown significantly and added capabilities to the current iteration in Windows Server 2008 R2. However, there are three main components you might consider removing:

.NET Support (this saves about 500MB of disk space, but is required for Windows PowerShell)
Input Method Editor (IME) Support (this saves about 200MB of disk space, but is used for additional language packs)
Windows on Windows 64 (WoW64) Support (this saves about 150MB of disk space, but is required for running 32-bit applications)

Removing these components is a semi-permanent operation. Once removed, they’re gone for good unless you reinstall them, which usually requires a reboot.

More on WoW64

WoW64 lets you run 32-bit code on a 64-bit Windows OS. WoW64 installs by default and takes up roughly 150MB of disk space. You can safely remove it if you don’t plan on running any 32-bit code on the server.

Before you remove WoW64, there are two situations you need to consider in which WoW64 is required, even if you aren’t running any 32-bit applications. If your server is going to be acting as a domain controller or if it’s going to run AD LDS, then you’ll need WoW64.

Incidentally, if you remove WoW64 and the server is using code that needs it, you’ll see a vague error message that doesn’t specifically mention WoW64: “The subsystem needed to support the image type is not present.”

Similarly, attempting to install a 32-bit Microsoft Installer (MSI) file without WoW64 installed on the server will result in a different, but equally vague error message: “Error 1719. The Windows Installer Service Could Not Be Accessed. This Can Occur if the Windows Installer is not Correctly Installed. Contact Your Support Personnel for Assistance.”

Deployment Image Servicing and Management Tool

The tool of choice in Server Core for enabling or disabling roles and features is the Deployment Image Servicing and Management (DISM) tool. Using DISM is fairly straightforward. For example, if you want to see all of the features that are currently enabled, you could use this command, which lists all available features, and tells you whether each feature is enabled or disabled, and whether a reboot is pending (see Figure 1):

DISM /online /Get-Features

You can use DISM to display all available features

Figure 1 You can use DISM to display all available features.

Once you know the name of the feature you want to enable, you can do so with this command:

Dism /Online /Enable-Feature /FeatureName:<feature name>

Similarly, you can remove a feature with this command:

Dism /Online /Disable-Feature /FeatureName:<feature name>

Features such as the .NET Framework and WoW64 are installed by default. You can safely enable or disable them using the previously detailed methods. Removing a feature is different than simply disabling it. Removal actually removes the feature from the server hard drive. Do this with the Start /w ocsetup command, followed by the name of the component you want to remove and the /uninstall switch (see Figure 2). The component name is case-sensitive.

You can reduce the Server Core footprint by removing unnecessary features.

Figure 2 You can reduce the Server Core footprint by removing unnecessary features.

For instance, if you want to remove WoW64, the command would be:

Start /w ocsetup ServerCore-WOW64 /uninstall

Similarly, you can reinstall WoW64 by using this command:

Start /w ocsetup ServerCore-WOW64

You can see how the command is used (see Figure 3).

Use the ocsetup command to install Server Core components.

Figure 3 Use the ocsetup command to install Server Core components.

Be Familiar with .NET Framework and ASP.NET Limitations

Server Core deployments do indeed have limitations not found in full deployments. To truly make the most of Server Core, you have to know its limitations and work within them. With that in mind, there are also some limitations to the .NET Framework of which you need to be aware.

These limitations typically revolve around the fact that Server Core uses a subset of the Windows components. As such, there are .NET namespaces that don’t exist in Server Core. Similarly, Windows Presentation Foundation is missing from the .NET Framework.

Just as there are limitations associated with the .NET Framework, there are also some limitations with the use of ASP.NET by IIS. Server Core uses the same ASP.NET package as a full Windows Server installation. However, before you attempt to host a Web site on Server Core, it’s worth noting code that makes use of System.Web.Mail will fail because of the dependency on CDOSYS (which does not exist in Server Core). Microsoft recommends modifying Web application code to use System.Mail.Net instead of System.Web.Mail.

Test Your Support Applications

As you can see, there’s quite a bit of planning that goes into optimizing a Server Core deployment. You can install different roles and the components that should be included in the system image. It’s easy to focus on the OS requirements, but it’s important to not forget about required support applications. For example, most servers use backup agents and antivirus software. However, the minimalist nature of Server Core means that sometimes support applications such as these might not function properly in a Server Core deployment. As such, it’s important to thoroughly test your infrastructure applications with Server Core before placing any core servers into a production environment.

One Last Thing

Unlike a full-blown Windows Server deployment, Server Core doesn’t prompt you to enter a product key. Even the SCONFIG utility, which is designed to ease the initial configuration process, lacks a mechanism for entering a product key. That being the case, it can be easy to forget to license your Server Core deployment.

The tool of choice for doing so is SLMGR.VBS. If you’re not sure whether you’ve licensed your Server Core deployment, you can check the server’s license status by entering the following command:

SLMGR.VBS –DLI

The results for a fully licensed server are shown in Figure 4.

Figure 4 This is what a fully licensed server looks like.

If you find you need to enter a product key, you can do so by entering the following command:

SLMGR.VNS –IPK <your product key>

After entering a product key, you’ll need to activate your server. Initiate the activation process by entering this command:

SLMGR.VBS -ATO

Server Core deployments are sure to become much more common in the future. The key to effectively working with Server Core is to understand its limitations and how you can work within those limitations.

Raymond Chen

Brien M. Posey, MVP, is a freelance technical author with thousands of articles and dozens of books to his credit. You can visit Posey’s Web site at brienposey.com.