A Very Good Year

In setting up my development system, I noted a huge change in the default security setup for Internet Information Server (IIS) 6.0: It is now appropriately paranoid. For starters, IIS 6.0 is not installed during the initial configuration, because this would leave unnecessary listening ports running on the system if IIS were not required for a particular application. Microsoft has adopted a long-honored firewall-programming strategy--that which is not specifically allowed is denied--which is a complete about-face from the lax default security settings in IIS 5.0.

Using Windows Server 2003's Manage Your Server wizard, I installed and then removed Active Directory, DNS, POP3, and SMTP several times from my development system. Such moves would have been a kiss of death for NT 4.0, with its option-pack approach. Windows 2000 would have fared better than NT 4.0, but it would have required a manual, potentially error-prone process. When my shakeup was complete, Server 2003 was running perfectly. I left it running as my primary Web server, and six months later the event logs are still clean and the system has not had to be rebooted.

I installed two more machines so I could test specific productivity features. They too continue to run beautifully, despite my best attempts to do them in with ADSI (Active Directory Service Interfaces), the new Group Policy Management Console, and several of the new scripting tools. Speaking as an occasional Microsoft critic, I am duly impressed.

AD Improvements

The largest single consideration in migrating to Windows Server 2003 is the cost of going to Active Directory. Do the improvements in AD save money and make the migration easier? Not exactly: The changes are only marginal. The single greatest hurdle to adopting AD is the tremendous amount of training required for the technical staff. This being the case, I don't see a significant change in the cost of retraining the IT staff--even if Server 2003 provides better migration tools.Additionally, some of the features that claim to reduce customer apprehension about AD migration don't work as advertised. When rolling out Windows 2000 AD, it was sometimes impossible to reverse mistakes once AD was implemented in a production network. To alleviate customer fears, Server 2003 includes a domain-rename procedure that purportedly lets customers rename and restructure domains and correct any domain design errors. But there are problems with this workaround. Prerequisites for the domain rename procedure are unattainable, and the domain-rename process is far too complex (read more on the workaround in the sidebar, below.)

In previous versions of AD, the time required to replicate AD over slow WAN links was prohibitive and left customers with no viable option beyond building domain controllers at a central site and shipping them to the remote offices for installation. To address this problem, Microsoft created an "Install From Media" procedure. An AD database can be backed up to CD or other removable media and sent to remote sites, then used to build a domain controller--a big time-saver. This process installs the bulk of the AD database on the remote server via CD and then resynchronizes the new domain controller via the normal replication process, so there should be minimal worry about lag time between taking the snapshot and installing at the remote site.

To test Install from Media, I did a system-state backup of one of my working Windows Server 2003 machines and copied the backup file to CD. I then "shipped" the CD to a "remote site" and restored the system state from backup to a temporary directory on a local drive on the machine that I wanted to promote to domain controller. I ran DCPROMO/ADV and, at the "Copying Domain Information" page, I selected "from these restored backup files." Next I pointed to the system state that was restored to the temp directory earlier. A detailed procedure can be found by searching for "Creating additional domain controllers" on TechNet.

The Active Directory Migration Tool (ADMT) has been upgraded to address shortcomings in the Windows 2000 version. Specifically, ADMT now migrates passwords between domains and has scripting and command-line interfaces. And it's possible to develop and test migration scripts before the actual migration. These features once were only available in third-party tools.

Policy ImprovementsGroup Policy may be the greatest contributor to Microsoft's new and improved ROI model. However, its complexity has limited its adoption by Windows 2000 customers. Microsoft has addressed this by releasing a new tool called the Group Policy Management Console.

Group Policy, designed to automate management of users' desktop systems, lets an administrator lock down desktop systems to prevent users from damaging their systems inadvertently or by loading unapproved software. There are hundreds of canned policy settings included in the base OS installation; additionally, administrators create their own on the fly. Policies can be applied at several levels--local machine, site, domain and organization--and in various combinations. With the tools provided in Windows 2000, however, it was difficult to determine the combined effect of policies applied at different levels, such as policies for both a local machine and the domain. Not being able to predict the outcomes of combined policies at different levels means Group Policy configuration errors could have harmed the network in ways that would be difficult to troubleshoot and repair.

GPMC addresses this problem by consolidating several tools to provide a comprehensive view of policies applied at all levels (see screenshot). It lets administrators model policy changes before implementing them on a production network. And like ADMT, Group Policy has a scripting interface so administrators can automate network configuration. GPMC's major shortcoming is the lack of a rollback feature that would let an admin back out of changes that don't work as planned. This capability still requires a third-party product.

Script Management

Windows systems programming has had a checkered past. The Windows CLI (command-line interface) has always been a poor cousin to Unix shell programming tools and scripting languages. Even though newer tools--such as VBScript, PERL for Win32 and Windows Scripting Host--allowed some automation, many system-level functions were not accessible to an administrator from the command line. Until now, system functions could only be accessed using C or C++ programming, a skill that many administrators don't have. The result was that managing a Windows network required too much manual configuration through the Windows GUI.

Windows systems programming and scripting capabilities are beefed up in Windows Server 2003. In addition to the new scripting interfaces for ADMT and GP, Windows Management Instrumentation (WMI) sports an expanded API and a friendly command-line interface, called WMIC.

One could argue that the array of scripting options included with Server 2003 might be confusing, but at least there are options. Microsoft's intent in providing these options is to encourage more network automation and thereby lower the cost of network management. And in my testing I couldn't make Server 2003 crash--the value add there must be considered.

The bottom line is whether Windows Server 2003 really provides a significant ROI. In my opinion, yes, it can, but the savings are not directly tied to the daunting task of migrating to Server 2003. Once its implemented, however, Server 2003 enables significant savings by easing management of the entire network--servers, desktops and machines at remote sites, and by simplifying user configuration settings. In the hands of capable systems/network engineers, these new tools will let midsize and large organizations automate network management and reduce the labor costs required to meet end-user service-level expectations by making central control of desktops more feasible.

Jim Ryan is an infrastructure architect with Princeton Systems Consulting in Redmond, Wash. Write to him at [email protected].

Post a comment or question on this story.

The Domain rename procedure cannot be used until after the entire forest has been upgraded to Windows Server 2003 Domain controllers, and the forest is set to a "Windows Server 2003 Functional Level," a new forest level mode beyond even Window 2000's native mode. For most customers, transition to Windows Server 2003 Forest Functional Level will take several years to accomplish, which makes the Domain rename procedure irrelevant for the foreseeable future. In addition, the 70-page renaming procedure can only be described as intense. I have yet to find a veteran systems engineer who would be comfortable attempting this procedure on a production network. My best advice is to wait for Release 2 of the procedure.