Veteran network administrators, prepare for a blinking cursor flashback: When you log in to a Server Core build of Windows 2008 Server, all you'll get is a DOS box. And unlike with PowerShell, if you minimize a Server Core command prompt, you'll be plunged into green-screen oblivion. Here, there's no escaping DOS, and that's exactly what Microsoft was aiming for.

"We heeded the call from our customers to provide an installation option that reduced the overall attack surface of Windows Server," says Andrew Mason, Windows Server team principal program manager.

Last month, we profiled PowerShell in the second edition of our Windows Server 2008 Rolling Review. In keeping with the command-line-driven theme, we present our take on Server Core, Microsoft's stripped-down OS build. We found Server Core to be a secure and optimized platform for running critical Windows services in dedicated roles, most remotely manageable via Microsoft Management Console snap-ins.

So what did Microsoft strip out of the base Windows Server build to make it faster, more stable, and more secure? For starters, Internet Explorer, 35 unnecessary services, the .Net framework, even the Windows Shell itself. But just like in the real world, high security comes at a price--in this case, cumbersome configuration.

Because Server Core is a scaled-down version of Windows Server, it's limited to a select number of standard roles and features: Active Directory, Active Directory Lightweight Directory Services, DHCP server, DNS server, file and print services, media services, IIS, and Hyper-V virtualization. Optional features include failover clustering, network load balancing, multipath I/O, backup, SNMP, and BitLocker.

This combination of roles and features makes Server Core a viable candidate for a diverse set of applications. And because Windows installs only the binaries required to run the roles selected, IT gains new options for making a Windows server more like an appliance or, dare we say it, a Linux box. For management, you can access your Server Core machine using the same remote administration tools that you're using for full Windows Server builds.

FAST AND SAFE
When we took Server Core for a spin in our Boston Real-World Labs, testing started out on a promising note as we built a Server Core OS in just about 12 minutes on our new Hewlett-Packard DL 360 G5. In comparison, a full build of the Enterprise version took almost 25 minutes on the same hardware. The basic OS footprint used a mere 2 GB of disk space and dropped only 70 services on the box, with just 38 in the running state. Contrast that with a full install of Enterprise Server, which took almost 6 GB of disk, with 105 services on the build, 46 running.

After the OS installation, we were greeted with the ever-familiar graphical log-in prompt, signed in, were presented with a friendly blinking cursor ... and that's where the fun ended. Reality hit home when we saw the Windows Shell was really gone, and we'd have to do some heavy lifting to get the server configured. We'll admit that our serviceable Linux expertise, coupled with strong knowledge of DOS and NT Resource Kit utilities, made us a tad cocky going into the lab. But none of that was much help with Server Core. Like many IT pros, we've become lazy and accustomed to pointing and clicking our way through daily administrative tasks. Take something simple, like configuring TCP/IP on a Windows Server. Most of us could do it blindfolded with a GUI (OK, so maybe not), but how in the world do you configure the IP address, subnet mask, and default gateway of a server from a DOS prompt?

Unfortunately, we're not aware of any Microsoft-supplied GUI shortcuts. You'll need to issue the following command in the DOS box: netsh interface ipv4 set address name="Local Area Connection" source=192.168.1.2 mask= 255.255.255.0 gateway=192.168.1.1.

Got that?

Other simple tasks, like changing the computer name, joining a domain, or adding a custom driver for a piece of hardware, require long commands because of a similar dearth of GUI tools to configure such items remotely. We were also stymied for a little while by the Windows firewall, which required a bit of massaging before we could even remotely access and manage our Server Core machine. We eventually gave up and found the magic command to turn off the Windows firewall completely so that our testing could resume unencumbered.