Where to draw the line?

Reading Time: 5 minutes

Despite what Susan Bradley thinks it's not just JoeWare that likes this "new no GUI, no IE, Command line only version of the Server Operating System in Windows Server 2008"…
I too am growing very fond of Server Core. I love this little Operating System installation option and I am finding my way in it better everyday I use it. (I must admit I'm a typical infrastructure guy, which contributes a lot to these positive feelings since I seem to understand the purpose of it.)

Microsoft has big ideas on modularization in upcoming versions of Microsoft Windows Server when looking at the MinWin stuff and the way they handle criticism from the Partner eco system. Some of these modularization ideas can already be found in test builds of Windows Server 2008 today. To me features like Server Core installations, IIS 7 components, but also the Hyper-V hypervisor are perfect examples.

 

Today's world

Today's world isn't about just putting a monolithic mainframe in your server room, configure it to do a couple of tricks and leaving it run for a couple of decades anymore… Even if your choice is to have a mainframe you'd still need to exchange information with partners, suppliers and clients and the ways to communicate get altered pretty rapidly. Unified Communications is the latest example. The outside world wants you to be always on, but your company won't be able to do that without some technology. (whichever way you choose)

From an architectural point of view it's wise to distinguish infrastructure from functionality. Using common infrastructure blocks and building smart functionality blocks on top of these infrastructure blocks allow you to cope with the ever changing outside world. The amount of time, money and technology your company puts into developing an (service-oriented) architecture are choices your company might make.

Microsoft's Business Productivity Infrastructure Optimization is based upon this SOA style of thinking and Microsoft Windows Server 2008 Server Core could be one of the building blocks . It's a lightweight, low-maintenance, small-footprint and therefor stable, reliable and multi-purpose platform with a small attack surface. It's useful to build your services and applications on top of.

 

The dilemma

Server Core obviously lacks certain technology. It doesn't have (Internet) Explorer, Windows Mail, Windows Media Player, Windows Movie Maker … but these might all be considered a blessing for a Server Operating System, unless you're using it as your day-to-day Operating System or Terminal Server.

What might be considered more disturbing is Server Core doesn't offer .Net Framework or the spanking new Powershell command line. Of course the Powershell is missing because the .Net Framework is missing, so the .Net Framework and thus Managed Code Support is the real issue here.

Note:
You can perfectly run Powershell on your management workstation to manage a Server Core box or even multiple Server Core boxes remotely.
(as long as you open up the firewall on your Server Core box)

Small footprint, low maintenance versus…

I understand why the Server Core team wants to leave out the .Net Framework. It compromises the small footprint and the lightweightedness of the system. Since 1 GB is the goal for the hard disk footprint the .Net Framework is out of the question. Besides: Server Core is supposed to be the low-maintenance Server Operating System. I don't want it to reboot every second Sunday night of the month to install yet another Hotfix, Rollup, Service Pack or any other newer version of the .Net Framework…

Deployment scenarios

On the other hand the absence of Managed Code support, the .Net Framework and Powershell rather limits the amount of scenarios in which Server Core installations of Windows Server 2008 can be deployed.

Already the Server Core team positions their product as a server, dedicated to infrastructure roles, like (Read Only) Domain Controller, DHCP Server, DNS Server, WINS Server, File- & Print Server, Windows Media Server and basic Web Server. But you can't use Server Core in a deployment scenario to:
(not a complete list, I'm sure)

  • act as an Exchange Server 2007 Edge Transport Server;
  • act as an Internet Security and Acceleration (ISA) Server;
  • provide Windows Server Update Services;
  • perform Routing, VPN or NAP duties.

I consider these Server Roles infrastructure roles…

 

The outcome

Zooming out beyond the .Net Framework and Powershell discussion the Server Core team can make one of four decisions regarding functionality, lightweightedness and security:

  1. Provide a service, application or component
    Making a service, application of component from the Full version of Windows Server available in Server Core as a feature might help using Server Core in the scenarios I mentioned above. In these scenarios Server Core won't be a low-maintenance lightweight Server Operating System anymore, which basically makes is comparable to Windows Server 2003…
  2. Provide a subset of services, applications or components
    The team can decide to make a subset of services, applications or components available on Server Core installations. Despite still vaguely offering the Server Core promises of low maintenance, small footprint and reduced attack surface it's questionable whether the team can put sufficient parts of the services, application or components in Server Core to make it useful in the depicted scenarios above.Dependencies on other partial services, applications and components come to play here.
  3. Provide a special Server Core version of a service or component
    The outcome of this decision would resemble the outcome of the decision to provide a subset of a service or component, with two major differences: With a special version of a service or application the team could secure compatibility with other Microsoft server products, but should also provide a differentiated update scheme to update the specific parts of  Server Core only. In the case of the .Net Framework version 3.1 ServicePack 2 Update Rollup 4 with some additional hotfixes, this would provide enough work for the Server Core and .Net Framework teams decades to come…
  4. Don't provide specific services and applications.
    Of course the Server Core team can easily put aside these issues and continue on their current path and leave Managed Code support, the .Net Framework, Powershell and many other applications and services out of Server Core. The remaining question is 'will the Server Core team be able to pull this off despite of CEC 2009?'.

As a reference I made the following table. It clearly shows something has to give no matter which road the Server Core team chooses.

Choice

Small Footprint

Low Maintenance

Attack Surface

Deployment Scenarios

1. Provide service, application

+ / –

+

2. Provide subset of service

+ / –

+ / –

+ / –

?

3. Provide special service

+ / –

+ / –

+

4. Don’t provide service

+

+

+

 

Concluding

I think the Server Core team has difficult choices to make and to communicate.

Perhaps the difficult question is not whether to implement the .Net Framework and Powershell but rather when to implement it?
Perhaps Server Core is just an exercise in modularization of the Windows Server Operating System to see where to draw the line in usage scenarios?

One thing is for sure:
Let's stop whining about stuff that isn't in Server Core; let's focus on the stuff that's in.

Further Reading

So what is that GUI-less desktop?
Server Core at ITForum
How to install Windows Media Services in Windows Server 2008
Microsoft Partners: MinWin Could Soothe Vista Headaches
How to determine which versions of the .NET Framework are installed
Interoperability with Server Core

Disclaimer Beta Software

The information on this webpage applies to software from Microsoft that was in testing phase but utilizable by experienced users by the time the webpage was written. This software has not been released for sale, distribution or usage for the general public. The information on this webpage and the beta software are provided "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.