It all started with Windows NT, Microsoft’s first serious entry into the network server market. Versions 3.1 and 3.5 of Windows NT didn’t garner very much attention in a NetWare-dominated world because they were sluggish and refused to play well with others. Along came Win000dows NT 4.0, which used the new Windows 95 interface (revolutionary only to those who didn’t recognize Apple’s Macintosh OS user interface) to put a friendlier face on some simple yet fundamental architectural improvements. With Version 4.0, larger organizations saw that Microsoft was serious about entering the enterprise computing market, even if the product currently being offered still was limited in scalability and availability. For one, Microsoft made concessions to NetWare users, giving them an easy way to integrate with a new NT network. The company also included a revised security feature set, including finely grained permissions and domains, which signified Microsoft considered enterprise computing an important part of Windows.
After a record six and one-half service packs, NT 4.0 is considered by some to be the most stable operating system ever to come out of Redmond. However, despite that, most administrators with Unix experience required an OS more credible in an enterprise environment—one that could compare to the enormous Unix machines that penetrated that market long ago and had unquestionably occupied it ever since. It wasn’t until February 2000, when Windows 2000 Server was released, that these calls were answered. Windows 2000 was a complete revision of NT 4.0 and was designed with stability and scalability as first priorities.
However, something still was lacking. Sun and IBM included application server software and developer-centric capabilities with their industrial-strength operating systems, Solaris and AIX. Windows 2000 lacked this functionality. As well, the infamous security problems associated with the bundled Windows 2000 web server, Internet Information Services (IIS), cast an ominous cloud over the thought that Windows could ever be a viable Internet-facing enterprise OS. Given that many saw Microsoft as “betting the company” on a web services initiative called .NET, it was critical that the company save face and do it right the next time. It wasn’t too late, but customers were very concerned about the numerous security vulnerabilities and the lack of a convenient patch management system to apply corrections to those vulnerabilities. Things had to change.
From stage left, enter Windows Server 2003, otherwise known as Whistler Server, Windows XP Server, and Windows .NET Server. What distinguishes this new release other than a longer name and a three-year difference in release dates? That’s a difficult question to answer. Microsoft is slowly but surely raising the standard it sets for itself in creating a server OS: it’s transformed a departmental fileserver system into an enterprise-class, centrally managed OS and then into an application server platform designed to interoperate using open standards. Along with this transition, has come improved hardware support, redesigned directory services, management tools designed in a role-based paradigm, and a host of security enhancements.
Windows Server 2003 provides scores of new features that most administrators have been hoping for since the release of Windows 2000 Server, as well as critical bug fixes, tool improvements, management refinements, and enhancements to the general fit and finish of the product. In this section, I’ll take a look at the major changes in the product from Windows 2000 Server.
Windows Server 2003 indeed is fairly secure after the installation process is complete, as Microsoft promised. The product also benefited from the month-long halt of new development in March 2002, referred to by Microsoft as the beginning of the Trustworthy Computing Initiative, wherein all developers and product managers did nothing but review existing source code for security flaws and attend training on new best practices for writing secure code.
But it’s not only in the actual code that security takes front seat. Perhaps the most welcomed improvement in the eyes of network administrators with large Windows XP deployments is Windows Server 2003’s native understanding and support for the expanded featureset of Group Policy (GP) found in XP. Windows 2000 Server was unaware of the new XP support for software execution restrictions and remote desktop support tools and thus required a bit of handholding to get it all working together. Windows Server 2003 knows about these XP tools out of the box.
Of course, there’s still room for improvement, and Microsoft sees that: at the time of this writing, Microsoft made firm plans to ship the Security Configuration Wizard by mid-2005 with its release of Windows Server 2003 Service Pack 1. The wizard lists the services required for each server product (Exchange Server, SQL Server, IIS, and the like), compiling that information from an XML database containing the pertinent data for all of Microsoft’s server products. The tool can be used in conjunction with the Manage Your Server Wizard and operates in two modes. In an automatic mode, you specify certain roles for the machine, and the wizard automatically will shut off any nonapplicable services and any ports not required by the assigned server roles. In an expert mode, the wizard will analyze the current roles a server is performing and the current base of services installed and running. Using that information, it will report to the administrator what services might not be necessary, leaving the actual decision to terminate those services up to the administrator. I’ll explore Windows security features and configurations in greater detail in Chapter 7.
Windows Server 2003 also debuts new secure wireless LAN support, and as an added bonus, this support can extend to wired networks, too. This allows you to keep unauthorized hosts off any part of your network, wired or wireless. 802.1X clients can authenticate to Windows Server 2003 machines using the Internet Authentication Service (IAS). For added security, you can add dynamic key exchange and WEP support as well. This is a great boon to both wireless and wired security. I’ll cover this more in Chapter 11.
Changes designed to improve both performance and scalability received attention from the development team. When the product was released in early 2003, VeriTest, an independent testing organization, ran benchmarks and custom-designed tests that demonstrated Windows Server 2003 outperformed Windows 2000 and Windows NT 4.0 by a dramatic margin of anywhere from 100-200%, depending on the task, using the same hardware. That’s impressive for any follow-on release and bucks the all-too-familiar trend of needing to upgrade hardware and software simultaneously. Compared with NT 4.0, Windows Server 2003 is about twice as fast as a fileserver, three times as fast as a dynamic web application server, and up to 400% faster at just plain web-page hosting. VeriTest ran all the tests using the same server, but during the battery it alternated the number of processors in the machine at any given time, using one, two, four, and eight processors interchangeably.
In fact, performance is so good that a lot of companies might want to consider adopting Windows Server 2003 for the purposes of server consolidation. Improvements to the underlying operating system, coupled with a complete rewrite of IIS, make it possible to increase the duties of a single machine. If you find your datacenter is growing by leaps and bounds, by giving each Windows Server 2003 machine more responsibility—which it can handle—you can reduce the number of servers you have to support. Having fewer servers can make managing those servers easier, too, and it can provide the primary benefit of reducing the total cost of ownership (TCO), a frequent measure of the progress and success of IT projects.
As far as scalability is concerned, most notably, Windows Server 2003 offers the ability in the 32-bit versions to use computers that scale to 32 processors. On 64-bit platforms with the forthcoming Windows Server 2003 64-bit versions, operation can scale to 64 processors.
Improvements to GP, including the new Group Policy Management Console (GPMC), as well as a task-oriented suite of management tools helps administrators control and administer more servers with much less effort than Windows 2000 required.
The Microsoft Management Console (MMC) is a central location where various parts of Windows subsystems come together in a single, consistent, and integrated user interface. Windows Server 2003 includes the MMC, first introduced in parts of Windows NT and by default in Windows 2000, and integrates nearly all administrative components into it.
The GPMC is an MMC snap-in that introduces easier ways of working with Group Policy Objects (GPOs). In the past, an administrator had to view GPOs not with one tool, but with several depending on where a GPO was applied. This required different snap-ins, such as Active Directory Users and Computers, Active Directory Sites and Services, the Delegation of Control Wizard, Resultant Set of Policy (RSoP), and Access Control List (ACL) editors. Needless to say, it was not as simple as it should have been. Fortunately, Microsoft realized this pain-in-the-neck way of administering GP and released the GPMC, which offers a centralized view of all GPOs. Perhaps the largest benefit of the GPMC is that it reduces the amount of clicking you have to do to find the GPO you need to modify. If you’ve used GP with Windows 2000 before, you are all too familiar with this.
The GPMC makes it a lot easier to:
Import, export, copy, and paste GPOs.
Manage GP security.
Generate file- and printer-based GPO reports.
Examine GPO and RSoP data.
Back up and restore GPOs.
Script GPO operations that you can perform with the GPMC (i.e., you can’t script individual policy settings, only GPO operations such as template GPO importing).
Additionally, if you are running Windows XP on your desktop, you’ll be pleased to know that Microsoft has the Administrative Tools Pack available to install on Windows 2000 and Windows XP workstations. However, note that the Windows 2000 version of the Administrative Tools Pack does not install properly on XP. Windows Server 2003 comes with a new, released version of the administrative tools compatible with XP that you also can use to manage Windows 2000 servers.
These management tools and their enhancements are covered in their respective areas throughout the book. Specifically, I’ll discuss the GPMC in Chapter 6.
Having multiple domains in a forest is a
neat way to gain some significant management and security advantages,
primarily the ability to do away with the old, inflexible, and
difficult-to-manage Windows NT 4.0-style trusts. As well, with Active
Directory there’s a beneficial feature known as the
global catalog, which serves as a sort of
“superdirectory,” responding to
queries with a more efficient but smaller database than the full
Active Directory. But what happens when your corporations merge? What
do you do with two Active Directory forests that need to share things
within each other?
Windows Server 2003 introduces forest root transitive trusts, wherein you click two forest root domains and tell Windows that they ought to trust one another, and everything just automatically works. To tell the truth, you can create the end result of these transitive trusts in Windows 2000, but you need to create multiple trusts between all domains, a process that is tedious and ripe with room for error. As with all good things, though, this functionality has limitations. First off, there’s the somewhat prohibitive limitation that all domain controllers in both forests must be running Windows Server 2003 for this to work. I’ll explore these types of trusts, including additional limitations, in more detail in Chapter 5.
The standard process to create a Windows 2000 domain controller was to run the DCPROMO Wizard, enter your login information, and download a copy of the Active Directory database. If you spot a problem with this scenario, chances are you’ve run into said problem yourself. If your branch office is in an extremely remote location—say, a location with no broadband Internet connectivity or nothing higher than 28.8kbps dial-up connectivity—and your Active Directory database is, perhaps, larger than 500MB, the third step in the process is going to take quite a long time. On top of that, if your connection is faulty and drops in the middle (or worse, right at the end) of the download process, you have to start all over. Obviously that can make for a very frustrating and nonproductive upgrade session.
Windows Server 2003 enables you to create a copy of the Active Directory database on removable media at your home office, or at least at a branch office with good connectivity to the domain. You then can carry this copy to the remote office with the flaky and slow connection, run DCPROMO, and tell the wizard that you have the Active Directory database on removable media. The wizard will copy that database onto the computer, and at that point, the wizard needs only to replicate any changes made to directory information between that time and the point at which you made the copy of the directory database. It’s a really clever and simple solution.
I’ll also cover these domain controller feature enhancements in Chapter 5.
Active Directory replication to branch office domain controllers has always been a touchy subject for administrators. At what point do the disadvantages outweigh the benefits? Windows 2000 tried to make it a bit easier on flaky WAN links by enabling traffic compression by default, and by using a “least-cost” algorithm that calculates how and when it would be cheapest to send the data over the link. Microsoft improved the replication algorithm in Windows Server 2003 significantly. It wasn’t uncommon for branch-office domain controllers to experience high CPU loads while trying to decompress hundreds of megabytes of replication data. In the new edition, you can turn off compression and save some CPU cycles.
In
addition, you can now selectively replicate information between a set
of domain controllers, not just all domain controllers, using a new
feature called application partitions. In the
previous version of Windows 2000, if you had information that you
wanted to pass along to other controllers in a domain, you had to
send it to all of them. Active Directory-integrated DNS zones are a
popular example of this. But if your DNS servers are only in Seattle
and Boston, why would your domain controllers in Tokyo—at the
other end of an expensive WAN link—care about receiving new DNS
server information? They don’t, but they had to get
it anyway. In Windows Server 2003, only Active Directory-integrated
DNS servers get replicated information; other domain controllers do
not. Kudos to Microsoft on this
one.
I will discuss replication in more depth in Chapter 5.
In these days riddled with corporate investing, mergers, acquisitions, and divestitures, administrators can find that their business name, or the name of the network which they’re responsible for supporting, can change rapidly. In Active Directory implementations this can be embarrassing because with Windows 2000, once you have created and named a domain, you cannot rename it. Four years later, some businesses are still logging on to networks with names that ceased to exist many years before.
Windows Server 2003 introduces the ability to rename existing domains. That’s about all I can say on that issue because “the ability to” does not equate to “it is simple to do it.” There are several restrictions on the process, not the least of which is that all domain controllers in the domain must be running Windows Server 2003. That can be an expensive proposition for large companies, some of which might need Windows Server 2003 only for that very ability. You also have to reboot all the domain controllers in that domain twice and each member server once. So, you can rename domains, but not easily or cost-effectively in most cases.
Chapter 5 contains detailed information on how domain renaming works and the limitations thereof.
Some of the most exciting ground being broken in server technology today has to do with increasing storage capacity and availability, and Windows Server 2003 is taking part in the movement. Virtual disk services, volume shadow copy, dynamic disks, and storage area network (SAN) management technologies abound in Windows Server 2003.
One of the most useful features of Windows Server 2003 is its support for shadow copies, which allows an administrator to configure the operating system so that it will make copies of certain files, which an administrator identifies, from a disk volume at regular intervals—sort of like taking a snapshot of the disk at specific times—and store them in a protected area on a volume. By installing a client extension on Windows XP machines, an end user can simply click the option to “view previous versions” inside the folder view of any volume in Windows Explorer, and Windows will bring up a list of all saved versions. This is absolutely fantastic when, at 3:45 p.m., a user realizes that before lunch, she accidentally overwrote the final draft of her proposal that is due during a meeting that begins at 4:00 p.m. She can grab the snapshot taken before lunch and all is well. Administrators who routinely restore user data from backups after “accidents” or “unfortunate and inadvertent data misplacements” (to use politically correct terminology) will appreciate the ability to recover files at the user level. I cover shadow copies in Chapter 3.
Volume shadow copy services also enable administrators to periodically take snapshots of their disk volumes, which provides a great way to perform backups on critical databases that can never be taken down for traditional offline backup procedures. The snapshot of the database is taken and stored in a special folder on the disk, and that folder can be backed up at leisure. This reduces a lot of headaches and (at least somewhat) assuages the tediousness of performing backups.
Virtual disk services (VDS) also enable administrators to configure SAN hardware directly from Windows, bring volumes online and offline, format them, and use them without intermediary software. This also increases the availability of backup products because third-party providers of these products are spared the task of writing their own custom drivers. Those products can interface with the native Windows support for these types of tasks, thereby decreasing the cost of that software to make, sell, and buy.
There’s more, too: VDS is the foundation of two new command-line utilities that pack a lot of power.
- DiskRaid
DiskRaid, part of the Windows Server 2003 Deployment Guide and the Windows Server 2003 Resource Kit, is a utility that you can use to manage RAID subsystems. With it, you can script disk operations, list disks, create, delete, unmask, and extend logical units, and manage a RAID array or container from the command-line. It’s a great tool for automated server provisioning.
- DiskPart
DiskPart is a command-line version of the Disk Management snap-in that ships with the operating system. It’s completely scriptable and enables you to control any aspect of disks, partitions, and volumes without the GUI.
There’s more on both of these tools in Chapter 3 and Chapter 13, but the important thing to notice is that both of these tools take advantage of the underlying VDS systems in Windows Server 2003. Expect many more third-party disk management tools in the coming years as well.
An idea first introduced with Windows NT 4.0 Terminal Server Edition, Terminal Server has consistently improved with each release. Those of you with Windows 2000 Server machines on your network have appreciated the remote administration capabilities included with that OS for some time. And for years, a third-party software company, Citrix, has been making its MetaFrame software, going above and beyond the quality and support of Microsoft’s integrated terminal offering.
But with Windows Server 2003, the free Terminal Server part gets even better. Support for increased color depth, automatic redirection of sound and printer ports, and lower bandwidth requirements makes it easier to use Terminal Server to access your servers from home, even over dial-up connections. As well, Windows Server 2003 includes the Remote Assistance feature, which places a helpful user interface over a raw Terminal Server connection. (The Remote Assistance feature is exactly like that found in Windows XP.)
Windows Server 2003 also includes native support for headless servers, or servers without a keyboard, video card, or mouse. Now you can have machines in your server room without these bulky items and Windows will run normally, without a lot of software hacks. In addition, the OS also includes a new set of functionality called Emergency Management Services (EMS), which enables administrators to perform disaster recovery and server-down maintenance over a network from a location away from the broken machine.
Last but certainly not least, Windows Server 2003 introduces web-based management tools. It was an important design goal for Microsoft; the company wanted to enable administrators to manage 80% of the features of Windows using a web interface accessed (potentially) from any computer, anywhere. I’m pleased to report that this is now a reality. Although extremely low-level operations aren’t available over the web-based management points, it’s definitely a useful feature to be able to perform such tasks as:
Adding users and groups
Turning off services
Formatting disk drives
Creating a file share
Adding a disk to a logical volume
You can do all these on a computer in New York from your corporate office in Los Angeles, via only a web browser. I’ll cover these tools in Chapter 13.
The Microsoft .NET Framework is the programming model that developers use for writing, publishing, and executing web applications, smart client applications, and XML services. These applications allow network access to their features via SOAP, XML, and HTTP. With the .NET Framework fully integrated into the Windows Server 2003 operating system, developers are freed from writing “plumbing” code: the framework handles code integration and management details seamlessly.
The .NET Framework itself has not changed with the integration into Windows Server 2003. In fact, the default install looks as if Microsoft just slapped the .NET Framework 1.1 install on top of it. Nevertheless, its presence is a benefit to developers who write applications for you to host on your systems. Some key points include the following:
IIS 6 radically improves the hosting environment for ASP.NET web applications. The new concepts of application pools and web gardens enhance the stability, scalability, and performance of applications. The new security measures further pull ASP.NET into the leading technology for enterprise web application development.
Integrated Universal Description, Discovery, and Integration (UDDI) provides the management and organization of web services within secure company boundaries.
COM+ adds features that align it with .NET. These include application pooling, application recycling, partitioning, and SOAP support.
I discuss the .NET Framework in depth in Chapter 9.
Improvements to security, reliability, and interoperability enhancements in IIS 6 are possibly the most improved part of Windows in this release.
Most noticeably, IIS is not installed out of the box, and when it is installed, it’s locked tight. If you’ve been around Windows server editions for a while, you’ll recall that ever since NT 4.0 shipped, IIS has been available and, since Windows 2000, has been installed by default. The security vulnerabilities in IIS that caused the outbreaks of Melissa, Code Red, and Nimda (do these names ring a bell?) have convinced most administrators that IIS is suitable only for internal web sites and those applications that absolutely require ASP support.
But what a difference a release makes. Some improvements in IIS 6 include the following:
For the first time, you must explicitly install IIS.
You have to specifically enable scripting support, server extensions, and the dynamic page-generation language you plan to use.
In its default configuration, IIS will handle only static HTML pages. This is a welcome relief to anyone who has tried to install Windows 2000 and been infected with a nasty virus in the five minutes it takes to boot the server and then turn off the service.
On a lower level, IIS has been completely rewritten, and the HTTP generation module (
http.sys) is now a kernel-level driver, which provides Windows Server 2003 with the ability to isolate separate sites on a box and protect each separately from a program crash. That means no more high-load applications taking down an entire server.In addition, by being a kernel-level driver, IIS performance is greatly improved in a number of situations. IIS 6 is three times as fast as IIS on Windows 2000 at serving dynamic web pages. Eat your heart out, Apache.
I explore IIS 6 in Chapter 8.
Windows is a popular hate target of Unix system administrators. Unix people claim that Windows depends too much on the GUI. You might have heard these complaints:
“Windows isn’t customizable enough.”
“Windows hides the directness, the inner workings of the operating system, making it difficult to fix it when things go wrong.”
“Things go wrong too often with Windows.”
That is, until Windows Server 2003, of course. By my estimation (because Microsoft has not released any official numbers), more than 95% of features that can be managed through the GUI have an associated command-line utility that enables them to be controlled from a prompt (and therefore to be more easily scripted). On top of that, some functions, such as relocating the volume on which shadow copies are stored, are accessible only through a command-line utility.
Why is the command-line so important? For one, it’s
often a great deal easier to perform simple administrative tasks
through one command-line. Take adding a user as an example. With the
GUI, you need to click several different menu items, do some
right-clicking, use the keyboard, tab through some fields, click OK a
couple of times, and then close everything. But adding a user through
the command-line is simple: one line of net user /add, or even dsadd user, with all the
options specified, is a lot simpler than clicking through all the
graphical screens. Now of course, the GUI has its place, but when it
comes to quick-and-dirty system administration, Windows is closing
the gap with Unix and its brethren.
Windows Server 2003 creates a great new way to support multidomain-based, Active Directory-integrated DNS systems, called conditional DNS forwarding. This feature enables you to instruct Windows to access a specific DNS server if requests are made for a specific domain.
Let’s say your company, with the domain widgetsinc.com, has its own DNS service running internally. However, Widgets, Inc. purchased Whatzits Ltd., an English company, which needs to use whatzits.co.uk internally, and people within widgetsinc.com need to be able to log on to whatzits.co.uk resources. You want to keep the domain separate for logistical reasons. But that same need to keep your domains distinct creates the rub because domain controllers handle logons, and widgetsinc.com users need to contact a domain controller for whatzits.co.uk to log on. When your Widgets users ask for DNS information, they are sent to the public-facing DNS servers for Whatzits, which of course don’t know what a domain controller is. Windows Server 2003 enables you to tell the DNS service running for widgetsinc.com that if clients request information on whatzits.co.uk, they need to be sent to the actual internal domain controllers for the latter. Now, everyone is happy because domain controller information is available, you still can maintain separate sets of public- and private-facing DNS servers for each domain, and users can log on to each domain from the other. This is a big feature and a security enhancement, and I’ll cover this more in Chapter 4.
Windows Server 2003 also creates a new feature called stub zones, which are basically small scraps of a DNS zone file that are ideal for transferring between DNS servers. The process in which they’re used is quite complex and is covered in depth in Chapter 4 as well.
Yes, licensing rears its ugly head again. The corporate accounting folks will be pleased to learn that Microsoft has decided to keep the price of the Standard and Enterprise editions of Windows Server 2003 at their Windows 2000 levels. However, there is another change that might be somewhat surprising—and disheartening: as soon as you add a system running Windows Server 2003 to your network, you must purchase brand-new client access licenses (CALs).
What doesn’t make sense in this is that the upgrade from 2000 to Windows Server 2003 isn’t a major revision of the product. In keeping with history, Microsoft has consistently required new CALs for seats or devices on your network with every major revision of NT. However, with the NT 3.5 to 3.51 upgrade, which was a minor release, one of the main selling points was that your NT 3.5 CALs were still legal. Now I’m not attempting to argue that the new features and fit-and-finish improvements in Windows Server 2003 aren’t important, or necessary, or even desired. But I suspect those who have tested and evaluated the product would argue that it’s more of a Windows 2000 upgrade than a new product (one might note that in any window, choosing About from the Help menu denotes Windows Server 2003 as being Version 5.2). Of course Microsoft could remove this requirement at any time, but it’s definitely a cog in the wheel to the en masse deployments the company is hoping to see.
Although Windows Server 2003 boasts numerous other minor features, those features give you the idea that while Windows Server 2003 is not a revolutionary upgrade, it’s definitely several steps in the right direction.
Get Learning Windows Server 2003 now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
