Server Core
Windows Server 2008 includes a ground-breaking new installation option called Server Core that installs a Windows Server system with a minimalist graphical user interface (GUI) and a limited set of roles. This requires much less RAM and patching than a normal Windows system. Microsoft estimates around half the RAM than an equivalent GUI version, and 40 per cent fewer patches than an equivalent Windows Server 2003 configuration. Customers have long complained about the need to install numerous patches to Windows servers, and it appears Microsoft has taken heed.
The downside to Server Core installations is largely short term. IT staff will need additional resources and training to learn how to install, configure and manage applications running in the Server Core environment.
Server Core installs a Windows Server 2008 system with a minimalist graphical user interface (GUI) and a limited set of roles.
However, one of the useful things about Server Roles-based installations is that, in addition to installing the necessary software components, the Server Role installation tool reconfigures the Windows environment to work with the applications that make up the role. So in order to make a functioning IIS7 system, we needed to type only one command into the Server Core CLI to install the software and reconfigure Windows Firewall.
For a default installation of IIS, we typed the following at a command prompt and pressed "ENTER":
start /w pkgmgr /iu:IIS-WebServerRole;WAS-WindowsActivationService;WAS-ProcessModel
With setup complete, Windows started the IIS service automatically -- all we needed to do was connect to the server via a web browser and confirm that IIS was working normally. To select specific IIS modules for installation would have involved typing the name of each required module on the command line, which would probably have resulted in a much longer command.
Next, we reconfigured Windows Firewall to allow incoming connections to the Microsoft Management Console using the following command:
netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
At this point you can run Computer Manager on a Vista SP1 desktop or another Windows Server 2008 system and connect it to a Server Core environment. However, only a subset of management tasks can be performed using a remote MMC connection to Server Core. For example, you can't use Computer Manager to add or remove roles or features.
The following command enables management via a remote desktop:
cscript C:\Windows\System32\ Scregedit.wsf /ar 0
Although this would be useful in many datacentre environments to provide remote access to Server Core systems, it's not a solution to the problem of using scripts and text-based commands to manage a Server Core system. The command enabled our Server Core desktop to be accessed remotely from a Terminal Services client, but the remote desktop was just as spartan as the local one, with only a command prompt, Task Manager and a few other graphical tools available.
We also tested Server Core running in a virtual machine hosted by VMware Workstation 6, so we wanted to install the VMware Tools utility into our system. We found that the normal method of installation using the VMware 'Install VMware Tools' menu item didn't work. However, having selected this menu item, we used the command prompt to install the software by changing to drive 'D', which was the local drive letter assigned to our DVD drive. From here we found it best to copy the software to a directory on the 'C' drive and execute the 'VMWare Tools.msi' file from the command line.
At this point the installation utility launched properly and we could use its graphical dialogue boxes to begin the installation. Unfortunately the installation utility froze near the end of the normal process, so we waited a few minutes for disk activity to stop and then 'Cancelled' the VMware Tools installer and forced a reboot of the system.
We found that some elements of VMware Tools had indeed been installed correctly. Although there are reports that some beta versions of Windows Server 2008 need VMware Tools to be installed for networking to function, the network connections on the launch version worked without requiring this step.
3%
2%
Be very careful of building applications based on M$ servers... Server 2003 dropped support for earlier API calls, and our application failed to work... The problem was that with M$ you can't really stay on older versions, as support is dropped etc, yet there is no corporate commitment to retain reverse compatibility. It would not have hurt M$ to retain the API support... but M$ just thought everyone should be migrated onto the newer M$ ways of doing things (.NET etc further lock-in). Our problem was that we were not yet ready to re-write that functionality.. and the programers who did write the earlier stuff were no longer around. To this day, for adding new users to an M$ Access application, we need to copy the database off the 2003 server back to the prior server (NT server) and make the changes, then re-copy the database files back onto the 2003 server. Clearly the application still works, but what changed was M$' support for functions done within their own complementary products (eg Access).
The good: Can't think of any... Presumably some of the security problems of the earlier product are addressed... but at a cost of greater lock-in.
The bad: Our experience with non-compatibility in 'upgrading' from one M$ product to its replacement has meant that we are seriously looking to standardise on only Linux servers, knowing that Linux retains strict reverse-computability and adherence to true standards.