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.
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.
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:
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:
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:
Removing these components is a semi-permanent operation. Once removed, they’re gone for good unless you reinstall them, which usually requires a reboot.
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.”
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
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.
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).
Figure 3 Use the ocsetup command to install Server Core components.
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.
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.
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:
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:
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.