Read an Excerpt

This is not an attempt to teach you Windows 2000 from the ground up ("Windows 2000 is an operating system. An operating system is necessary for you to run applications. Applications are..."). You should be comfortable in the Windows NT environment, and have had some exposure to Windows 2000, in order to get the most from this review of features and components central to the operating system and/or of particular interest from a scripting perspective. This is not a comprehensive overview, as that's not possible in this limited space. If you're very comfortable with Windows 2000, you can probably move ahead to Chapter 2, though you might want to stick around for the occasional pithy comment.

Dummies Need Not Apply

Windows 2000 is more complex than its predecessors, if not by an order of magnitude, then certainly by a healthy percentage. Yet Microsoft claims that Win2K will significantly reduce TCO (Total Cost of Ownership). While we'll all find out how that ends up in reality, it's fair to say that lower TCO does not mean administrators and support personnel will have less to do. The tradeoff for savings at the per-desktop level, and for the finer-grained control Windows 2000 allows, is that you'll have more settings to tweak than ever before.

The good news is that there's a more consistent logic to where things are and how they work in Windows 2000 than in Windows NT. The bad news is that it's often a different logic than before. Expect a learning curve, and don't brush off these changes as cosmetic; they're functions of fundamental changes in the operating system. Familiarizing yourself with Windows 2000 well enough to manage, implement, and troubleshoot it will takesome time.

If there's a key difference in Windows 2000 as compared to Windows NT, it's tied to namespaces. The NT domain structure is a single namespace. Windows 2000 encompasses several namespaces, all linked to one another. The DNS namespace is the foundation of the Active Directory's design. A site topology overlays the AD's domain structure, independent of it, but highly influential when it comes to enterprise architecture. Distributed File System trees generate another namespace. Distributed applications rely on and overlay all of these spaces, and bring with them their own topology. All these run on top of your physical network and system architecture.

Decision-making and troubleshooting Windows 2000 requires a multidimensional mindset. You must keep in mind the impact of your actions on all these namespaces, rather than just the domain structure.

What's New In Windows 2000: The Broad Strokes

Features, features, features! Microsoft has implemented a slew of new technologies in Windows 2000, as well as modifying existing OS features. A summary of all this, whether or not it's filtered through the author, can't help but read like a laundry list, so unfold that ironing board and prepare to steam through the pile. This is not meant to be a comprehensive list by any means; rather, it is the author's best effort at hitting the high points, particularly those that will influence how and why you script within this environment.

Versions

There are four distinct versions of Windows 2000:

• Windows 2000 Professional is the successor to Windows NT Workstation. It's a secure desktop and mobile operating system and supports two CPUs out of the box. Power management is built into this OS, as is Plug-and-Play.

• Windows 2000 Server maps to Windows NT Server. It supports four-way systems and can function as a member server, standalone server, or domain controller. Server comes with Windows Terminal Services for lightweight clients to access the Windows 2000 infrastructure.

• Windows 2000 Advanced Server (which approximates NT 4.0 Enterprise Edition) supports application failover clustering, eight-CPU systems, and up to 8GB RAM (contrasted with the 2GB limit for Pro, Server, and Windows NT).

• Windows 2000 DataCenter Server supports more advanced clustering, 16-CPU systems (32-way through OEMs), and up to 64GB of physical memory.

In terms of real-world usage, Professional is for the desktop, Server for departmental-level servers, Advanced Server for mission-critical applications and functions that require failure protection at the level of cluster failover, and DataCenter Server for key applications and data operations that require monster horsepower, storage, and reliability.

As tends to be the case with new Microsoft operating systems, Windows 2000 requires somewhat more resources than its predecessors, specifically in the area of memory. Microsoft recommends 64MB for Professional and 256MB for Server and Advanced Server. They'll support less than that, but these are solid, realistic numbers if you expect your systems to perform suitably in enterprise settings.

As for CPUs, Microsoft has finally abandoned 486-level systems, and recommends a minimum of a Pentium 133MHz to run Windows 2000. Free disk space minimums are 650MB for Professional and 1GB for Server and Advanced Server. If you're wondering about DataCenter Server's requirements, if you have to ask, you probably shouldn't install it.

Active Directory

The most profound change in Windows 2000 is the presence of the Active Directory. The AD is a single database containing all the objects in a Windows 2000 organization. Users, computers, groups, domains, sites, and properties of all of these entities are in the Active Directory.

One of the biggest criticisms of Windows NT, in comparison to other operating systems, was that it had no unified directory service. This meant that administrative tasks often had to follow awkward logical paths, such as going to User Manager to establish domain trust relationships. Finding a domain's trust relationships in Windows 2000 is somewhat more logical: just right-click the domain name in Active Directory Names and Trusts (we'll get to that later on), and select Properties. The property sheet will have a Trusts tab, as shown in Figure 1-1.

Just as the directory services model has changed, so has its structure down at the file level. The Active Directory doesn't have the limitations of the NT SAM database; in theory, it can hold millions of objects without size constraints, as opposed to the 40,000-object cap on the SAM. The database engine-the ESE (Extensible Storage Engine), derived from the Microsoft Exchange Directory-is also, as its name indicates, open to adding new objects and properties. Contrast that with the SAM, which held users, computers, domains, and groups with a fixed set of properties.

In Windows 2000, the definition of a domain controller is simply a system which has a copy of the Active Directory. The NT distinction is gone between primary domain controllers or PDCs (one per domain, with the only read-write copy of the SAM) and backup domain controllers or BDCs (having a read-only SAM). All copies of the Active Directory are read-write, and directory replication in Windows 2000 is a multimaster affair. Replication is granular down to the attribute level; if you change a user's fax number, only that changed property will be replicated to the other domain controllers. Bandwidth utilization also differs from NT days, when an entire object would be replicated from PDC to BDC(s). There will be more, but smaller, replication messages.

In addition, making a Windows 2000 system a DC is not irrevocable, as it was in Windows NT. The answer to the ubiquitous exam question (paraphrased!), "Joe wants to make SERVER5 a member server rather than a BDC. How does he do this?" used to be "Reinstall Windows NT Server." In Windows 2000, the dcpromo command, located in %windir%\System32, kicks off the Active Directory Installation Wizard, which allows you to add or remove the AD.

GUI-based interaction with the Active Directory takes place through several utilities, which can either be found in Start I Programs I Administrative Tools or loaded as snap-ins to your own custom Microsoft Management Console (MMC). Think of the MMC as a generic container for administrative utilities of all sorts. Figure 1-2 shows a typical overstuffed MMC.

It's possible to create your own custom snap-ins for the MMC. That requires familiarity with robust programming languages such as Visual Basic or C++, but keep it in mind. Microsoft has a tool on its Web site which gives VB coders the ability to create their own snap-ins.

The Active Directory is based on X.500, a set of international standards for directory services. The directory is accessed through Lightweight Directory Access Protocol (LDAP) v3, which we'll discuss shortly. Objects in the AD are referred to by their distinguished name (DN), a funky naming structure which might represent a certain well-known CEO as:

CN=BillG,CN=Users,DC=Microsoft,DC=Com

For scripting purposes, the AD is accessed through ADSI, the Active Directory Service Interfaces. ADSI has a chapter all to itself later on. ADSI is provider-based, which means that it can manage any directory service for which provider code is written. Out of the box, this includes NT 4 Directory Services and Novell's NDS.

Back to replication for a moment. Within a domain, all Active Directory objects and properties are replicated to all domain controllers. One DC is designated as a Global Catalog server. The GC stores a full copy of all Active Directory objects within its domain, and a partial copy of objects from other domains. This partial replication is enabled in the interests of security and bandwidth. As an administrator, you may not want certain business information replicated to all your domains. More importantly, limiting the replication will make your network hardware happy, happy, happy. You can make the decision about what or what not to replicate to the Global Catalog with an MMC snap-in. Be forewarned, you'll be touching the schema, the underlying architecture of the Active Directory, when you do this. Be very careful.

The Active Directory has three sections (directory partitions) called naming contexts. The Domain Naming Context (Figure 1-3) can be viewed through the Active Directory Users and Computers snap-in. It contains computers, groups, users, and other objects.

The Schema Naming Context (Figure 1-4) shows the properties and object classes contained in the Active Directory. Viewing it requires the Active Directory Schema snap-in from the Windows 2000 Resource Kit.

The Configuration Naming Context contains information about sites, transports, IP subnets, domain controllers, and AD replication topology. The Active Directory Sites and Services snap-in displays much of this, as shown in Figure 1-5.

Bear in mind that the Active Directory should not be considered a place to dump volatile application data (unless you enjoy the thought of the replication overhead sucking away your bandwidth before your very eyes), nor as a substitute for the local file system or registry...