Working with Server Core, as opposed to a full Windows Server deployment, conveys numerous benefits like simplicity and small attack surface.
Both Windows Server 2008 and Windows Server 2008 R2 give you considerable flexibility when it comes to deployment concerns. You can deploy either as a full installation or in a Server Core configuration.
A Server Core deployment is a lightweight Windows Server deployment with a minimal footprint. Server Core deployments lack many of the components are taken for granted in full Windows Server installations, so there are numerous myths surrounding Server Core. I’ll debunk some of these myths while also providing some best practices for working with Server Core deployments. All of the following examples are based on Windows Server 2008 R2.
One of the big myths surrounding Server Core is that it’s difficult to configure because you have to perform the entire configuration from the Command Prompt. Thankfully, there are a couple of tools that make configuring Server Core much easier.
Windows Server 2008 R2 comes with a built-in utility you can invoke by entering the SCONFIG command at the command prompt. This menu-driven utility lets you perform basic configuration tasks such as specifying an IP address, changing the computer name or joining a domain.
Another tool that greatly simplifies initial configuration is Server Core Configurator 2.0 (see Figure 1). This tool goes much further in simplifying the initial configuration than SCONFIG does. It includes the same functionality as SCONFIG, but also lets you add or remove server roles and manage various Control Panel settings. It even lets you enter a product key and activate the server. Download Core Configurator from coreconfig.codeplex.com/releases/view/36678.
Figure 1 The Server Core Configurator provides a GUI interface for configuring Server Core.
Because Server Core offers a limited set of services, it’s not suitable for all of the same tasks for which you would use a full Windows Server 2008 R2 deployment. Instead, Server Core can only accommodate a limited number of roles, none of which are installed by default. The roles that you can install include:
Some IT pros have thought that because Server Core has such a small footprint, they can treat it as an appliance, rather than a real server. This is not true—patch management is an essential administrative task, regardless of whether a system is running Server Core or a full Windows Server deployment.
However, because Server Core does have such a small footprint, many of the Windows Server patches don’t apply to Server Core environments. Therefore, running Server Core can help reduce the patch management burden, but it never goes away entirely.
Your best option for ensuring your Server Core deployment adheres to Microsoft’s recommended best practices is to use the Best Practices Analyzer. This can be a bit tricky, though, without a GUI. You have two main options for running a best practices scan. One is to run the scan directly from the Server Core desktop. The other option is to run the scan from another machine that does have a GUI.
One thing to keep in mind is that because Server Core consists of such a minimal set of services, there really isn’t any such thing as a set of best practices for configuring the core OS. That being the case, the Best Practices Analyzer is server role-specific. If your server is running only the core OS without any additional roles, you won’t be able to perform a baseline scan.
The scanning process is based on the use of BPA models. Those models are role-specific. For example, there’s a Hyper-V model and an Active Directory model.
If you want to perform a best practices scan from the command line, you’ll need to install Windows PowerShell. The easiest way to do that is to run the SCONFIG command and then click “Configure Remote Management,” followed by “Enable Windows PowerShell” (see Figure 2).
Figure 2 You can use the SCONFIG utility to enable Windows PowerShell.
Once you’ve installed Windows PowerShell, you’ll need to install the Server Manager cmdlets for Windows PowerShell, as well as the Best Practices Analyzer cmdlets. You can do this with the Deployment Image Servicing and Management (DISM) tool.
Normally, you’d use the DISM tool to manage deployment images, but by using the /Online switch, you can direct DISM to act against the current OS. You can install the necessary Windows PowerShell cmdlets by entering the following commands at the Command Prompt (see Figure 3):
DISM /Online /Enable-Feature /FeatureName:ServerManager-PSH-Cmdlets
DISM /Online /Enable-Feature /FeatureName:BestPractices-PSH-Cmdlets
Figure 3 You can use the DISM command to install the necessary Windows PowerShell cmdlets.
Now that you have the necessary components in place, you can run a best practices scan. Because you have to run the scan through Windows PowerShell, enter the PowerShell.exe command. When you do, the Command Prompt window will transform into a Windows PowerShell window.
The next thing you’ll have to do is import the cmdlets you enabled earlier. Do this with two simple Windows PowerShell commands:
Now that all of the pieces are in place, you should verify that the necessary Best Practices Analyzer models are in place. Do this by entering the following command:
The results should look something like what you see in Figure 4. If there were no results returned, then the Best Practices Analyzer won’t do anything if you attempt to perform a scan.
Figure 4 You can use the Get-BPAModel command to see which models are installed.
The easiest way to run a best practices scan is to use this command:
Get-BPAModel | Invoke-BPAModel
This command, which is shown in Figure 5, runs a best practices scan against all of the models installed on the server.
Figure 5 The best practices scan won’t display any results if the models aren’t in place.
Because the results weren’t displayed automatically, enter the following command to see them:
Get-BPAModel | Get-BPAResult | Out-File "C:\BPA.txt"
This command will create a text file with the scan results. You can copy the file to another system or you can use the following command to see the results:
You can see what the scan results look like in Figure 6.
Figure 6 This is what the scan results look like.
You could also use a GUI to perform a best practices scan of your Server Core deployment. To do so, you’ll need to run the scan from a server running Windows Server 2008 R2 or you can use a computer running Windows 7 with the Remote Server Administration Tools. If you decide to use Windows 7, then you can download the Remote Server Administration Tools from microsoft.com/download/en/details.aspx?displaylang=en&id=7887.
Like the command line-based best practices scan, scanning with the GUI requires that you have Windows PowerShell installed on the core server. You’ll also need to enable Remote MMC Management and Server Manager Remote Management. You can prepare the server by entering the SCONFIG command and following these steps:
Enter 4 (Configure Remote Management)Enter 2 (Enable Windows PowerShell)Restart the serverLog in and enter SCONFIGEnter 4 (Configure Remote Management)Enter 1 (Allow MMC Remote Management)Enter 3 (Allow Server Manager Remote Management)Enter 5 (Return to Main Menu)Enter 13 (Exit to Command Line)
To perform the scan, open Server Manager and right click on the listing for your server within the console tree. Then select the “Connect to Another Computer” from the shortcut menu. When prompted, enter the name of the computer you want to scan.
Once you’ve connected to the remote Server Core machine, expand the Roles container and then select the role for which you want to run a best practices scan. As you scroll through the results, you should see a section labeled Best Practices Analyzer. You can scan the role by clicking the Scan This Role link. The scan results are displayed within the Best Practices Analyzer section, as shown in Figure 7.
Figure 7 You can scan a core server by using another server’s GUI.
Many of the processes described here rely on Windows PowerShell being installed on the Server Core computer. Unless you plan on running an application that requires Windows PowerShell, you should probably move it when you’re done with the initial configuration and best practices testing.
This may sound strange because there are a lot of posts on the Internet claiming that if you want to manage Server Core from the command line, you must do so through Windows PowerShell. However, Server Core is designed to be managed from a Command Prompt, not from Windows PowerShell. In fact, the first version of Server Core wouldn’t even allow Windows PowerShell to be installed. Technically, there’s nothing wrong with having Windows PowerShell installed on your server. However, most people use Server Core because of its small footprint and small attack surface because having Windows PowerShell installed increases the server’s attack surface.
You can remove Windows PowerShell by opening a Command Prompt window and entering the following command (see Figure 8):
Start /W ocsetup MicrosoftWindowsPowerShell /Uninstall
Figure 8 You can use the Start /W OCSETUP Microsoft Windows PowerShell /Uninstall command to remove Windows PowerShell.
Some of you may wonder why I used the Start /W OCSETUP command instead of ServerManagerCMD. There are two reasons why I didn’t use ServerManagerCMD:
As you can see, the techniques used for managing Server Core differ from those used for managing a typical Windows Server 2008 deployment. Even so, Server Core is ideal for use in high-security environments or when you need to conserve server resources.