Search Wiki:

Abstract

With the release of Windows Server 2008, the Server Core installation option was introduced. This new option made it possible to run only the base operating system along with a minimum of optional features and roles. Consequently, Server Core has become quite successful as a network services host OS. Windows Server 2008 R2 introduces further enhancements that enable Server Core to also be leveraged as an Application host OS.

There are unique considerations to be aware of when developing applications intended to run on a Server Core installation of Windows Server 2008 R2. If you are a native-code developer (using primarily C/C++), you need to be sure that the machine in which the application will run has the necessary runtimes. Likewise, if you are a managed-code developer (using primarily C#/VB.NET), then you must be certain that the target machine has the required .NET Framework installed. For both, managed and unmanaged developers, it is also imperative to have the WoW64 execution layer if you will be using executable binaries that are 32-bit (with R2, Windows Server is now 64-bit only). In this segment, you will learn how to install various requirements that your applications may need in order to successfully execute.


Related "5 Minute Concept" Webcasts


Related MSDN Code Gallery Articles


Why Server Core?

Windows Server 2008 introduced the option to install Windows Server without the familiar Graphical User Interface (GUI). Many Windows system administrators, for example, use the GUI-based Management Consoles extensively and on a daily basis. While losing the GUI functionality may seem like a step in the wrong direction for an operating system named "Windows", the new option to run without the GUI offers an array of advantages, especially for system administrators. One of the most important compensations is the smaller footprint taken by the operating system itself. By running a version of Windows that consumes fewer resources, available resources could be used for other tasks. For example, if an Enterprise installation of Windows Server 2008 requires 768 MB of RAM, the core installation could run with as little as 256MB; thus, allowing other roles, such as virtualization or web services, to utilize the available memory. Additional advantages include reduced Windows Updates requirements and a reduced attack surface. By the way, the GUI management consoles may still be used to administrate the server core system, but instead from a remote client machine.

Native-Code Gotchas

Most things remain unchanged for native-code developers in Server Core installations of Windows Server. Whether you are developing for core versions of R2 or Windows Server 2008, you will need to have the respective runtimes installed on the target machine. The Microsoft Visual C++ 2008 Redistributable Package includes runtime components of the C Runtime (CRT), Standard C++, ATL, MFC, OpenMP and other MS libraries. In essence, enabling your solution for a Server Core deployment target is most often an excercise in evaluating solution dependencies and accounting for those with a bit of care.

The 64-bit version of the Visual C++ 2008 Redistributable Package installer file can downloaded here and the 32-bit here. Once downloaded, the package can be easily installed on Server Core by using the quiet mode installation option:

    vcredist_x64.exe  /q

Actually, installing application dependencies, and especially redistributables, is a multi-faceted topic. Microsoft recommends using installer merge modules for most scenarios. Please see the "Notes On Manifests" document within the Downloads section of this site for more detailed guidance.

Managed-Code Gotchas

The Server Core installation of Windows Server 2008 R2 includes support for the .Net framework. This does not mean that the 3 framework versions (2.0, 3.0, and 3.5) are fully supported. A subset of these frameworks is supported and most of the unsupported features naturally have GUI dependencies (a Server Core "no-no").

The limitations for the 3.0 Framework deals specifically with absence of the Windows Presentation Foundation (WPF). This is due to the fact that Server Core does not have the required graphic functionalities to support WPF. LINQ and the WF additions from the 3.5 Framework are fully supported.

With the addition of .NET 2.0 support, IIS on Server Core now supports a subset of ASP.NET. Server Core includes the option to install the IIS-Management component, which enables IT Administrators to configure IIS via an MMC snap-in from a remote machine.

The following list details the namespaces that are not available in Windows Server 2008 R2 Core. As you can see from this list, most of these namespaces GUI aspects of a .NET application. Others are simply incompatible with a Server Core application usage scenario:

    Microsoft.Aspnet.Snapin
    Microsoft.Ink
    Microsoft.ManagementConsole.*	
    Microsoft.StylusInput.*
    Microsoft.VisualBasic.Compatibility.VB6	
    Microsoft.Windows.Themes
    Microsoft.WindowsCE.Forms
    Microsoft.WindowsMobile.DirectX.*
    System.ComponentModel.Design.*
    System.Data.Design
    System.Deployment.Application	
    System.Diagnostics.Design
    System.Media	
    System.Messaging.Design
    System.Speech.*
    System.Web.UI.Design.*   (note:   runtime support for expression builders is included, just not design-time)
    System.Windows.*	
    UIAutomationClientsideProviders

For managed-code solutions, additional considerations exist. First, it is imperative to understand that the .NET Framework is not enabled by default. The .NET Framework optional feature must be installed. Otherwise, the .NET assemblies will fail to execute. To install the 2.0 Framework, issue the following command at the Server Core command prompt:

    dism /online /enable-feature /featurename:NetFx2-ServerCore

To install the 3.0 Framework, the command is almost identical:

    dism /online /enable-feature /featurename:NetFx3-ServerCore

Running 32-bit Applications on Server Core

Even though Windows Server 2008 R2 is exclusively a 64-bit operating system, 32-bit applications are supported by enabling the WoW64 optional feature. If you do not enable this feature and try to run a 32-bit application, the application will fail to execute. The WoW64 execution layer is an optional component that is installed by default after beta1. You can save resources by removing the feature if you are not going to be running 32-bit applications on your Server Core install. Install the WoW64 Execution Layer using the following command:

    dism /online /enable-feature /featurename:ServerCore-WOW64

If your solution has a .NET 32-bit dependency, then also invoke the following sequence:

    dism /online /enable-feature /featurename:NetFx2-ServerCore
    dism /online /enable-feature /featurename:NetFx2-ServerCore-WOW64

Note: With Windows Server 2008 R2 beta1, WoW64 is an optional feature. This is changing. With Windows Server 2008 R2 RC1, WoW64 will be enabled by default. If you don't want WoW64 enabled, just disable the feature as follows:

    dism /online /disable-feature /featurename:ServerCore-WOW64

Remote Debugging Server Core Applications

There are several ways to remotely debug Windows application, regardless of whether or not the applications are hosted on Server Core. This section refers only to the techniques of debugging .NET and C++ applications using Visual Studio. You may wish to instead utilize the Debugging Tools for Windows tool-kit. Refer to the excellent help files included with that tool-kit.

The Visual Studio Remote Debugger is easy to use and powerful. It can help with tasks such as debugging 64-bit code from a 32-bit machine, debugging distributed High Performance Computing (HPC) applications, and debugging you code on Microsoft Windows Server 2008 R2, Server Core. Configuring a remote debug session is a straightforward task but there are various details you need to keep track off in order to have a pleasant debugging experience.

Once you complete a default Visual Studio installation, the 64-bit and 32-bit remote debuggers can be found within the following respective folders:

    C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x64
    C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86

In order to remotely debug your binaries, you must copy the x86 or x64 folder to your Server Core installation. In order to avoid running into configuration issues (e.g. because of long pathnames), it is a good idea to place the folder somewhere that would result in a short path (for example c:\). Furthermore, we recommend that you rename the folder so it has a name representative of what it is (for example, Remote-Debugguer-x64).

Once you copy the Remote Debugger, you can run it by invoking its name (msvsmon.exe) from the command prompt. The first time the debugger runs, it will ask you to select whether you would like a create a Firewall rule that will allow inbound traffic to come through. The second option, “Unblock remote debugging from computers in the local network (subnet)” should suffice for the vast majority of developers using test machines, for example.

ConfigureFirewall.jpg

Once you make your choice, the remote debugger will start listening for connections from remote clients as shown below:

DebugMonitor.jpg

If the ServerCore-WOW64 feature is installed on your Server Core host machine, then you can debug 32-bit applications. All you need to do is launch the x86 version of the remote debugger and configure it with the same steps just illustrated.

Once you have your code ready to be remotely debugged, the first thing that should be done is to create a project post-build command that will copy your Visual Studio solution "Debug folder" contents to your Server Core host machine. The application debug build executable, along with .pdb files, and runtime dependencies should be installed on on the Server Core host machine.

Selecting Properties from within the Solution Explorer for your managed project will reveal a Debug Tab:

DebugProperties.jpg

Instead of selecting the default option to Start project, you should select the second option, Start external program and enter the local path of your binary in the Server Core machine. For example, if your binary resided on your Server Core machine under C:\MyApplication, then you would enter C:\MyApplication\MyAssembly.exe.

StartAction.jpg

Once you have specified the remote application to debug, you must specify the name of the of your Server Core installation. To specify this, mark the check-box labeled Use remote machine and type the name of your server as shown below:

UseRemoteMachine.jpg

Once you save your changes and select Start Debugging, your client machine will connect to the Server Core machine, enabling you to debug as if you were running Visual Studio directly on the Server Core host machine.

The process to enable remote native-code application debugging is very similar. First, you must invoke the Visual Studio project properties menu and find the Debugging node on the left pane:

NativeProjectProperties.jpg

From the list of debuggers within the drop-down menu, the Remote Windows Debugger should be selected. Once selected, you must specify the following:
  1. In the Remote Command row the complete local path to the binary that resides within your Server Core host machine (if the path includes spaces, enclose it with quotes).
  2. The Remote Server Name.

DebuggerToLaunch.jpg

The intuitiveness of the Microsoft Visual Studio debugger makes finding errors in your code a pleasant activity. The same ease-of-use can also be experienced using the Microsoft Remote Debugger service in conjunction with Visual Studio. Ensure that your debugger service has been configured appropriately in order to avoid firewall blocking scenarios. Also ensure that you have the either Debugger User or Administrator privileges on the Server Core host machine in order to authenticate for the debugging session.

Try it Yourself!

Download the "Hands-on-Lab" demo project via the "Downloads" tab on this project page.

Related Community Resources

Last edited Mar 11 2009 at 10:53 PM  by philpenn, version 26
Updating...
Page view tracker