- Shopping Bag ( 0 items )
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.
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.
There are four distinct versions of Windows 2000:
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.
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:
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...
Posted November 28, 2001
It's obvious at this point that we're not going to be able to escape some form of scripting to function in a large 2000 network. This book is a great intro and discusses both Jscript and VBScript.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.