- Important new features reduce the cost of running corporate networks, including Network Access Protection, Server Core, PowerShell and Read Only Domain Controllers
- Many existing components, such as IIS, Terminal Services and the file-sharing protocol have also had a thorough overhaul
- Many new features are not compatible with older Windows desktop and server systems
- Upgrades to existing servers will need careful planning
- More care is needed when purchasing Terminal Service Client Access Licences
- .NET framework and PowerShell are not available in Server Core configurations
- Training is required to make good use of the Server Core option
Launched on 27 February, Windows Server 2008 is designed to run on 32-bit and 64-bit processors from Intel and AMD, including multicore versions — many of which were unheard-of when Windows Server 2003 was first released.
Virtualisation is fast becoming a fixture in all IT operations, but is unfortunately missing from the launch version of Windows Server 2008. However, it will be integral to the new suite when Microsoft delivers its Hyper-V virtualisation hypervisor, which is due in August. A beta version of Hyper-V is currently included on the x64 version of the Windows Server 2008 installation media. US pricing for Windows Server 2008 ranges from $999 for the Standard edition up to $3,999 for the Enterprise edition.
As well as supporting the latest hardware technologies, Windows Server 2008 is easier to install and manage. In ZDNet UK's lab tests, we found that the installation process has been streamlined and it's now much quicker and easier to install a new server system. The installation utility asked for our country and licence number, and then a dialogue box offered full or Server Core versions of the Standard, Enterprise or Datacenter editions. Had we run the installation tool in an existing Windows Server 2003 system, the option to upgrade or make a clean install would also have been offered. After selecting the target disk partition, the installation tool proceeded to the end without stopping.
The Windows Server 2008 installation process has been streamlined.
Before we could log into our new servers, we needed to set a 'strong' password — that is, a password containing numbers and punctuation as well as letters. Once logged in, Windows presented the new Initial Configuration Tasks screen. This contains links to various utilities needed to handle the normal tasks of commissioning a new server, such as setting its time zone, assigning an IP address and changing its name. We needed to restart our server for the new name to take effect. There was also a link for configuring firewall settings, and we were pleased to see that the default firewall settings blocked most incoming connections — the exceptions were for things like router broadcasts. All outbound traffic was allowed.
The Initial Configuration Tasks screen provides links to the utilities required to set up your new server installation.
The old Windows Add or Remove Programs applet in Control Panel has been replaced by two new utilities. The Add Server Role wizard is used to add and configure complex applications, such as Active Directory (AD) and Network Policy and Access Services. There's also a new applet called Programs and Features that lists third-party software installed on the system. This has a link that launches Server Manager, which in turn can be used to launch the wizards to add or remove server roles and features.
We found 18 GUI-based server roles that could be installed using this new wizard. Eight of these roles could also be installed in Server Core systems, although in this case there's no graphical wizard. Similarly, the new Add Features wizard is used to add 35 simpler software components, such as a Telnet client and BitLocker Drive Encryption. There are links to start both these wizards on the Initial Configuration Tasks screen.
Manageability gets a big boost from the new PowerShell environment, which enables administrators to perform setup and administration tasks using scripts rather than via the Windows GUI. This will be a popular choice for tasks that must be scheduled or performed repeatedly on one or more servers: having written and tested a script, it can easily be deployed and executed on multiple systems. People familiar with Linux will see many similarities with the BASH scripts used to manage Linux systems; those more used to working with Windows and MS-DOS will see PowerShell scripts as a logical development from DOS batch files and Windows scripts.
Most Windows administrators will need some time and training in order to get the most from the new scripting options. Fortunately the graphical management tools have also been spruced up. Many now use the three-panel design seen in other Microsoft products, such as System Center 2007 and Virtual Machine Manager 2007. In particular, we like the new Server Manager utility, which allows you to inspect the server configuration and performance parameters, as well as make adjustments to the installed software.
Organisations running Active Directory Domain Controllers in remote offices will also benefit greatly from a new Read Only Domain Controller (RODC) option. As the name suggests, changes in the RODC's AD database are not replicated back to the datacentre DCs. In addition, by default no user or computer passwords are stored by the RODC, although we could select users and groups that would be cached by the RODC. The idea is to use RODC's in remote offices to reduce WAN traffic and improve security. For example, there would be no need to replace every password in the organisation should a remote-office DC be stolen or compromised.
We also found big changes in the Microsoft Internet Information Services 7.0 (IIS7) platform, which has been completely overhauled and is now much simpler to set up and manage. Although web administrators can still use the Windows GUI to set up web sites, a new site can be deployed simply by copying an XML file to the appropriate place on the server. Support for the open-source PHP server-side scripting language is now built in, and sites that don't need the .NET Framework — which includes PHP sites — can be hosted in Server Core systems.
Likewise, there are reliability benefits from the vastly improved clustering support — which now includes a new validation tool that checks the hardware setup — and a new setup wizard that reduces the number of steps needed to configure clustering on a server from 17 to 3. Other improvements meant we could create a cluster that had no single point of failure. Support for clustering in business continuity scenarios has also been improved: a new tuneable timeout parameter removes the 200km limit for members of a cluster, and clustered servers no longer have to be on the same IP subnet.
Other highlights include an overhaul to Terminal Services that makes it much easier to support remote clients and improves the way documents are printed on client systems. There's also a new Terminal Services Remote Application option to publish applications as well as complete Windows desktops, while the new Terminal Services Gateway eliminates the need for a VPN for remote clients. Using TS Gateway, clients can connect directly using HTTPS. For scalability and fault tolerance, a new TS Session Broker will help to balance TS sessions across between two and five servers. The broker decides where to place new sessions based on the number of active and disconnected sessions on each server in the TS farm.
Terminal Services Licensing has also finally been sorted out. Previously, per-client licensing was not enforced by the Terminal Services License Server. Consequently it was difficult for organisations to be sure they had purchased an adequate number of licenses. Now both the 'per user' and 'per device' client licence models are handled properly by the licence server. The downside to this is that IT departments must now specify which type of licence they require at the time of purchase, so they cannot easily convert one type of licence to another.
The new SMB2 file sharing protocol will be another popular enhancement for organisations with remote offices. Before Windows Server 2008, the Windows file-sharing protocol was notoriously slow when used over WAN links. So much so that many businesses had to invest in expensive alternative technologies to create a workable system. Although organisations will still want to protect SMB2 access using VPN connections, the updated protocol should make high-performance access to remote file servers much more affordable.
Although Windows Server 2008 is a great improvement, there are still a few areas that could be enhanced. In particular, it seems a pity that PowerShell and the .NET Framework are not available in Server Core systems. Microsoft says Server Core is an infrastructure platform, not an application server platform. Nevertheless we wouldn't be surprised to see the .NET Framework made available in a future version of Server Core. This would enable Server Core-based IIS systems to host many more web sites and be managed using PowerShell.
Internet Information Services 7
Like several other major subsystems in Windows Server 2008, Internet Information Services 7.0 (IIS7) has undergone a major overhaul and now looks set to compete with the open-source Apache web server on a more equal footing. Indeed, some would say that IIS7 has borrowed a number of ideas from Apache and built upon them. For example, IIS7 web sites can now be created simply by copying an XML file into the appropriate directory on the server. As you'd expect, those sites can be reconfigured simply by editing that XML file, and could be remotely deployed using the new robocopy command (short for 'robust copy'), which works with network connections and replaces the now-deprecated xcopy.
Support for the open-source PHP server-side scripting language has been improved, and can be used with Server Core configurations to make an attractive server configuration for some web-hosting organisations.
In ZDNet UK's lab tests we used the Add Server Role wizard to configure a Windows Server 2008 system to run IIS7. We used the default installation options, which added most of the components that organisations would need to host basic web sites.
There are many options for configuring IIS7, but most tasks can be accomplished using the IIS Manager GUI, or with the new command-line tool called appcmd.exe. PowerShell scripts can also be used for this kind of work, so we installed Windows PowerShell using the Add Features Wizard and tested it by running a simple script to create some web sites in our IIS hierarchy. We launched the PowerShell command-line interface using a link in the All Programs section of the Windows Start menu. By default PowerShell is configured only to run scripts that have been digitally signed, and as our script was unsigned we needed to adjust the PowerShell execution policy of our test system to allow our scripts to run. In production environments, server administrators may prefer to maintain the default setting.
We could then run our PowerShell script to create web sites rather than creating them using the Windows GUI. The script took just over two minutes to create and start 10,000 sites on our test system. A production server fitted with more disks would probably complete the task much quicker. We made a video walkthrough showing the script creating 1,000 sites, which took about 16 seconds to complete.
Existing ASP.NET web sites running on IIS6 servers will run without modification, but IIS7 has a new 'Integrated' mode that's only available to sites that have been migrated to IIS7's ASP.NET. There are command-line tools to convert older sites so they run properly using the new Integrated mode, and most people are likely to use them to convert their sites to gain access to the superior features available.
To test some PHP web sites, we also downloaded the latest version of the open-source PHP software from www.php.net. We wanted to use ISAPI to handle PHP requests, so we needed to add ISAPI support to our IIS configuration, which was easily done by clicking on the Add Role Services link in the IIS section of Server Manager.
Installing PHP into IIS7 is a quick and easy process — it took us about 15 minutes. First we created a PHP folder in the Inetpub directory and decompressed the PHP binaries into it. Then we created a php.ini file using the contents of php.ini-recommended (which comes with the PHP binaries) and configured a handler for PHP document requests using Inetpub\php\php5isapi.dll. Having selected our server in the IIS Manager GUI, we double-clicked on the Handler Mappings applet to create the appropriate mapping. We could also have used Inetpub\php\php-cgi.exe.
At this point we simply copied a directory containing a PHP web site into the IIS webroot directory and used the IIS Manager GUI to create a new web site. We could then connect to the site using a browser on our server.
Creating a Handler Mapping for PHP document requests in the IIS Manager.
Some nice features in IIS7 include a new backup facility, which is accessed from the appcmd environment. We tested this with the following command line, which took about one second to run:
appcmd add backup zdnet-test
Next we deleted our PHP web site from the IIS Manager hierarchy, and restored the backup facility using the following command:
appcmd restore backup zdnet-test
The Automatic Failed Request Trace Logging module is another useful new feature. As its name suggests, it watches for specific errors and logs them to a file. To use this feature we needed to add ASP.NET and Tracing Role Services to our IIS configuration using the Add Role Services link in the IIS section of Server Manager, and restart IIS Manager. We could then enable the module on our sites by highlighting them in the IIS Manager hierarchy and selecting the Failed Request Tracing link in the right-hand action panel.
The Automatic Failed Request Trace Logging module watches for specific errors and logs them to a file.
Next we used IIS Manager to create a Failed Request Tracing Rule for our site. We found the process of configuring IIS to log details of requests so easy that we didn't need to consult documentation. We created a rule to log details of requests that resulted in an HTTP status code of 404, which would cause the module to log details of requests for pages that could not be found, and tested our rule by browsing to a page that did not exist. Because we were using IIS7's enhanced error-reporting capability, which is enabled in default configurations, a fairly informative error report was returned to the browser rather than the terse 404 page that some web servers might offer. More impressive still was the vast amount of detail contained in the log file produced by the FRTL module, which was also formatted for easy viewing in a web browser. The information here enabled us to trace through each module used to handle our request and identify exactly why the request failed.
We created a Failed Request Tracing Rule that gave informative error reports on non-existent web pages thanks to IIS7's enhanced error-reporting capability.
Rather than watch for a specified status code, the FRTL module could be configured to watch for requests that took more than a specified amount of time to complete. The time value used must be an integer, but otherwise is arbitrary, so IT staff could use longer or shorter times depending on the behaviour of the application they are working with. FRTL could also be configured to log events according to the severity of the error message, for example, so it logged only 'critical errors'.
IIS7 is packed full of new features that will make it easier to run multiple web sites on a single server. In this review we've only been able to scratch the surface of what's becoming an excellent platform for corporate web applications.
Network Access Protection
According to Microsoft, Network Access Protection (NAP) is the single most popular new feature in Windows Server 2008. NAP is designed to help organisations manage client devices that connect to their networks. Its basic function is to check that PCs are configured according to IT policies and take appropriate action if they are not. For example, NAP can check that a client PC is running Windows Firewall, that its antivirus signatures are up to date and that specific patches are installed.
Should a PC fail to pass muster, NAP can be configured to warn the user, or reprogram a switch supporting RADIUS VLAN assignments so that the client is refused access to the LAN.
However, NAP simply asks the client operating system various questions, and it's up to the client to respond honestly. Should the client be infected with malware, it's likely to provide misleading responses to NAP's enquiries. Therefore, NAP is not so much a security enforcement system as a tool to help IT managers ensure that the bulk of their client devices are patched and configured correctly.
In ZDNet UK's lab tests, we installed NAP by using the Add Roles Wizard to add Network Policy and Access Services to one of our test systems. As we wanted to put the full NPS suite onto a single server we ticked the option box for Health Registration Authority (HRA), so the wizard told us we also needed to install Internet Information Services (IIS) and many of its management tools. HRA can be configured to issue certificates only to clients that are authenticated to a domain, or can work with all clients. Network Policy and Access Services is compatible with domains running Windows 2000 or later modes. For our tests we took the option to work with all clients. As we clicked through the dialogue boxes to complete the installation, the wizard told us it needed to install Active Directory Certificate Services and the Windows Process Activation Service in order to make a working NPS system, and warned us that once the software was installed we would not be able to change the name of the server.
The Network Policy Server tool allows client-access policies — in this case for devices connected over a VPN — to be configured for a network.
With the software installed, we used a wizard in the Network Policy Server (NPS) management tool to set up policies for our environment. For our test, we configured a policy for clients connected using a VPN. We could also create policies for clients connecting via DHCP, Terminal Services Gateway, 802.1x wired and wireless, and IPsec with HRA. The wizard gave us the option to specify RADIUS access servers, and then the option of groups of machines and users to which the policy would apply. Each policy can be set up to allow clients to authenticate to NPS using passwords or certificates, and NPS can work with certificates stored either in smartcards or certificate stores. You can also specify a remediation server, to which clients that fail the NAP checks can be restricted, and from which from which any required patches can be downloaded before trying the NAP checks again.
Security Health Validators compare the status of devices wishing to connect to the LAN, and either grant access, deny access or direct it to a remediation server.
Options are also available for clients to automatically remediate themselves against the remediation server; you can then choose whether to allow full access to NAP-ineligible clients.
Before testing our NAP setup, we needed to enable Routing and Remote Access using the appropriate tool from the Administrative Tools program group. For example, our XP SP2 system was not able to perform the NAP checks, but was allowed full network access because our VPN Non NAP Capable policy was configured to allow this. NAP will be supported by systems running XP SP3 and Vista SP1. Third-party vendors are expected to producte NAP clients for Linux and Mac OS X desktops in the near future.
The facility to force compatible clients to automatically remediate themselves if they don't pass the NAP health checks is clearly extremely useful. However, some organisations may wish to use NAP in either its reporting or deferred enforcement modes. Both of these modes can be used to improve the health of client systems before the policy enforcement mode is activated. Also impressive are NAP's reporting capabilities, which can show how many systems are compliant with an IT department's patching and configuration regimes.
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.
In ZDNet UK's lab tests, we installed an Enterprise Edition Server Core system from the normal installation utility. Unfortunately there's no way to convert an existing system between a Server Core and full GUI-based configuration. The installation utility proceeded in the same way as for the GUI versions of Windows. Likewise, we needed to set a strong password before we could log into our Server Core system for the first time. Once logged in we found that basic networking was enabled. For example, we could ping another device on our network. But as with the other versions of Windows, Windows Firewall was configured to block all incoming connections except Core Networking services, such as handling router broadcasts.
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.