Windows 2008 Server Core - back to the Future (Command Line) ?

Where's my command line manual? Slick move or desperation? The news that Windows 2008 Server will be available in a "cut-down" version appears to be good news from many different aspects, especially for people who will want to run IIS or SQL Servers. Firstly, the ability to de-install complex logic which is not required for the core work (such as the GUI) will reduce the "attack surface" - the number of possible entry points where hackers can gain exploits. The smaller the operating system, the less likely there will be vulnerabilities. Secondly, it must logically simplify the runtime behavior of the OS, and make it easier to maintain and manage This can only be good news for Sys Admins involved with Windows Web and SQL Servers However, there are always concerns which arise. Since the only way to dialog with the Server will be via the new command-line shell, the question arises "How long will it be before this shell exhibits vulnerabilities?" On the face of it, Microsoft have neatly side-stepped questions about vulnerabilities in Internet Explorer, Explorer, Media Player, etc. etc. by the simple expedient of removing it from the build entirely. If you want a server, just get rid of all the non-server pretty stuff. At the same time, it has to be acknowledged that Microsoft do appear to have listened to their customers. Most organizations with Windows Server build their own cut-down deployment version, particularly for the "Edge" or DMZ where the web servers live. Microsoft have just reflected this preference. Although in this case, the amount of "fat" that can be cut out is far more than currently available with Windows 2003. In my view, good Sys Admins are always able to do most of their work from a command line. It sounds as if this will become essential in the future. The circle is complete Back in the old days of NT 3.5, you may remember that the GUI was de-coupled from the core Operating System. At the time, this was a clever approach by Dave and his designers. It fitted well with the fact that NT was inspired by the VMS 32-bit kernel, and enabled the GUI and core development to follow their own lines. I also heard that NT 3.5 systems could run successfully even if the GUI crashed - and I did see a partial example of this back in the early 90's. The problem with this approach was that the overhead of context switching in and out of the GUI every time a window had to be moved, or a box drawn, resulted in a slow Operating System on the desktop. And at the time, Microsoft wanted to maintain the one Operating System for both the Desktop and the Server ranges. With the introduction of the Windows 95-style shell, Microsoft did two things. They re-wrote Windows Server with a 95-style shell, and they made the shell itself a key part of the Server, thus destroying the de-coupling which had been done in the original version. The result was a relatively slim, stable and fast Desktop Operating system. It was also a reasonable Server, as anyone still using NT4 will testify. The problem was that the GUI itself and all it's attendant add-ons (Internet Explorer, for one) resulted in a more bloated OS, which became inefficient and vulnerable to attack. And as the Server market began to ramp up, Microsoft began to question the benefits of keeping a single code base for the Server and Desktop. With the introduction of Windows XP (and later Visa) for the Desktop, it became clear that the code had to be forked. It was time to specialize. So now we are back to the era of slimmed-down, command-line-only servers which only have the software for their own specific purposes. Any extraneous generic functionality is stripped off. Come to think of if, isn't that what SERVERS are really meant to be like ?