< Day Day Up > |
Some of the new features in AD fix problems with Windows 2000, whereas others add new functionality. A majority of the improvements that will make a difference in the Windows 2000 enterprise are in the area of replication and Global Catalog (GC) servers. In the sections that follow, we discuss some of the significant features and enhancements in this area. We explain some in detail, and summarize others because we detail them in subsequent chapters of this book. Universal Group Membership CachingWindows 2000 native mode, as well as Windows Server 2003, requires users to be authenticated by a Global Catalog (GC) server. This often causes a problem for remote sites that have no GC and must therefore authenticate across a WAN (Wide Area Network). Microsoft provided an option in the form of a Registry key that permitted authentication without contacting a GC. However, without GC contact, universal groups cannot be added to the user's token. Thus, if a deny ace was set for a universal group on a resource, and a member of that group was authenticated without a GC, that user would have access to the resource because the universal group would not be in the user 's token. In Windows Server 2003, a new feature called Universal Group Membership Caching (sometimes called GC Caching) gives users a new option for dealing with this situation. Because at the time of this writing this feature is in its infancy, it is not well documented. Thus, we've chosen to provide a fair amount of detail here as it could have tremendous benefit for enterprises that have small remote sites or sites that do not have a local GC. Overview of Universal Group Membership CachingUniversal Group Membership Caching allows a user to log on, be authenticated by a local domain controller (DC), and retrieve global and universal group memberships from a "cache" located as attributes to the user object on the local DC ”even though the DC is not a GC. Group Membership Caching is not enabled by default and is intended to provide more efficient logon performance for users at sites where a GC is not justifiable, typically at smaller sites. Group Membership Caching is intended as a stop-gap until the number of users at a site justifies installation of a GC, as caching will require use of resources on the DCs to support it. The term "cache" as used here is not defined as you might normally think of a cache ”a temporary, volatile storage that is cleared on logoff or reboot. Rather, these values are stored as attributes of user objects in the AD and are purged only by an Administrator or by time-sensitive values. You create the cache by enabling the caching feature on the NTDS settings object in a site. When caching is enabled and the user logs on and is authenticated by a DC in that site, three attributes are added to the user object:
note Users who are authenticated by a DC that is also a GC will not have these attributes populated on that DC/GC. They will be populated on other DCs in the site that are not GCs. When you are authenticated by a GC, it always has the membership information and doesn't need to go anywhere else for the membership. Functional Level RequirementsThe Universal Group Membership Caching feature does not require any particular functional level. In fact, you can have Windows 2000 DCs in the domain and in the site where Universal Group Membership Caching is enabled. However, this can be a serious problem because Windows 2000 DCs don't have this functionality. Therefore, if a Windows 2000 DC validates the user, the group membership will be inconsistent because the Windows 2000 DC will have to always contact the GC. It is recommended that all DCs in a site where Universal Group Membership Caching is enabled are Windows Server 2003 DCs. Facilitating Universal Group Membership CachingUniversal Group Membership Caching is a site attribute that must be enabled specifically in the properties of the NTDS Site Settings object for each site on which you want Universal Group Membership Caching functional. To enable this feature, follow these steps:
note Caching for any user happens only on the sites in which it is enabled. Thus, a user can log on and be authenticated by a DC using cached memberships at one site, then travel to another where Universal Group Membership Caching is not enabled, and be required to contact a GC to be authenticated. Enabling Universal Group Membership Caching on Initial User LogonAfter caching is enabled on a site, each user's group membership is stored on the authenticating DC in that site after the user's initial logon ”after caching is enabled. The msDS-Site-Affinity attribute is populated with that site's GUID and is replicated to the other DCs in the site. This is accomplished in the following sequence of events. Refer to Figure 1.2 for the domain configuration in this and subsequent examples in this document.
Figure 1.2. Domain configuration for scenarios used in this section.
Table 1.1 lists the attribute values populated for Joe after the initial logon (note that this is a conceptual illustration only; the group memberships are actually a binary blob ). This table shows Joe's user object as viewed from all three DCs in the Atlanta site. Table 1.1. Attributes After Initial Login with Universal Group Membership Caching Enabled and Authentication by ATL-DC1
Figure 1.3 and 1.4 illustrate ADSIedit showing the cache of a user who has logged in for the first time to a site with caching enabled. Figure 1.3 shows the msDS-Cached-Membership and msDS-Cached-Membership-Time-Stamp attributes, and Figure 1.4 shows the msDS-Site-Affinity attribute. Note that while ADSIedit shows the hex representation, LDP simply shows this as <binary blob>, as shown in Figure 1.5. Figure 1.3. User's populated msDS-Cached-Membership and msDS-Cached-Membership-Time-Stamp attributes via the ADSIedit.msc tool.
Figure 1.4. User's populated msDS-Site-Affinity attributes via the ADSIedit.msc tool.
Figure 1.5. The LDP tool shows the Site Affinity attribute as a <binary blob>.Caching Behavior After Initial Logon in a SiteAfter the cache attributes are populated by the DC that authenticates Joe, and the Site Affinity attribute is replicated to the other DCs in the Atlanta site in the example, subsequent attempts by Joe to log on will be handled as described in the upcoming case scenarios. (Refer to Figure 1.2.) Prior to describing these three basic authentication scenarios, however, we need to define some terminology. We will present more detail on these parameters in the "Managing Cache Parameters" section.
Now that the terminology is defined, we can consider the following example scenarios.
Logging into Remote SitesAgain referring to Figure 1.2, suppose Joe is a mobile user and he travels to the Chicago site to work for two weeks. When he logs on and is authenticated by CHI-DC10, the DC determines that Chicago's site is not in Joe's msDS-Site-Affinity attribute, so it contacts a GC to get Joe's membership and populates the cache attributes, including adding a new time stamp and adding Chicago's site GUID to the msDS-Site-Affinity attribute. On the next refresh, CHI-DC11 will populate Joe's attributes as well. In this configuration, sites Dallas and Seattle are core sites with many users, good bandwidth, and GC servers at each site. Therefore, Universal Group Membership Caching is not enabled at those sites. If Joe travels to Seattle and logs in, the authenticating DC contacts a GC for Joe's group membership as it normally would. Time Passes . . .Joe completes his work in Chicago and returns to his home office in Atlanta. After a period of time, if Joe does not log in or change his password from Chicago, his attributes are purged from the Chicago DCs, including the site affinity. We will discuss these timeouts in the upcoming "Refreshing the Cache" section. If Joe goes back to Chicago after this time, his attributes will be refreshed as they were the first time he logged in. This guarantees that Joe's group membership is up-to-date. warning After the group membership attribute is populated, the DC will not contact a GC again for the user's membership until the next cache refresh. It will always use the cached membership in the msDS-Cached-Membership attribute. This can be a problem, especially in troubleshooting. If the Administrator changes the user's group membership (that is, he adds Joe to a new universal group) and has Joe log on, the new group might not be part of Joe's token. The administrator can force a cache refresh to update the membership, as described in the "Refreshing the Cache" section of this chapter. Refreshing the CacheRefreshing the cache is critical. If the cache isn't refreshed in a timely fashion, the user will not have the correct group membership because the security token is built from the cached attribute. The refresh process is not trivial, and the DC performs a number of actions to keep the cache up-to-date. This refresh is completed independently every eight hours, or on reboot, on each DC for all users. Stale cached attributes are eventually purged. For example, user Joe in our example traveled to Chicago from his home site in Atlanta. While he is in Chicago, his site affinity time stamp will be refreshed regularly while he is logged on. After he leaves , assuming the site stickiness setting is left at the default, Joe's cached attributes will be refreshed for another 90 days, even if he doesn't log on. When Joe returns to Atlanta, his cache for Chicago will be refreshed for another 90 days. Let's say Joe returns to Chicago and logs in 120 days after he left. Because he is beyond one-half the stickiness setting and less than the total stickiness setting, the site affinity time stamp will be refreshed when he logs on. If Joe returns after 180 days since leaving Chicago, he will have to contact a GC to get his cache populated because it will have been purged. These checks are to ensure that mobile users who go from site to site are not logging on with stale membership caches. note If the msDS-Cached-Membership values are purged, the worst thing that can happen is that the user will have to contact a GC when he or she logs in again, and if one is not available, cached credentials will be used. If cached credentials fail, login will be denied . Managing the CacheThe cache update mechanisms and checks introduced in the previous sections are somewhat confusing and hard to keep track of, but they are configurable. In this section, we will explain how to configure the parameters and manage the cache. Setting the RegistryYou control cache refresh parameters through Registry settings. It is important that you understand what you are doing before changing these values as they can have a negative impact on WAN traffic and user logon performance.
If you change these parameters from the default, you should be aware of the following:
The most common administrative chore associated with Universal Group Membership Caching is forcing a cache refresh to clean things up and start over. You can accomplish this task in four ways: purging the cached attributes for a single user, refreshing the cache for all users on a single DC, and deleting all cached attributes for all users at all DCs in a site, forcing a refresh for the entire site. Deleting the Cache for a Single UserThe Administrator might want to do this if a user's group membership has changed and it is desirable for the effects to take place immediately rather than waiting for the cache to refresh. The Administrator can use ADSIedit to accomplish this, as outlined in the following steps:
The next time the user logs in, because these attributes are not populated, the user is forced to contact the GC to get group membership, which will in turn populate the user's cache with the new group membership and a new time stamp. Refreshing the Cache on a Single DCIf some users' group memberships are out of date, it could be because their authenticating DC cache refresh failed. The Administrator can force a cache reset on a single DC by setting the updateCachedMemberships value to 1 on the rootDSE. The Administrator can do this using the LDP tool, as outlined in the following steps:
note Setting the updateCachedMemberships attribute triggers the DC to refresh the cache without rebooting the server. Another way to refresh the cache on a single DC is to reboot it. This triggers the refresh to occur about 15 minutes after reboot. Deleting the Cache for an Entire SiteYou can purge the Group Membership Cache for all users in a site by setting the Site Stickiness Setting to zero (0), as noted previously in the "Setting the Registry" section. Doing this on one DC in the site purges all the cached attributes on that DC, including the msDS-Site-Affinity attribute. The site affinity attribute reset is then replicated to all other DCs in the site. At the next cache refresh, the DCs determine that they don't have the site affinity attribute, and reset the msDS-Cached-Membership and the msDS-Cached-Membership-Time-Stamp attributes for all users. ConclusionAt the time of this writing, the Universal Group Membership Caching feature is so new that there is really no data in terms of recommendations based on experience. However, Universal Group Membership Caching has some negative impact on users and on the domain. Because the cache is a static value that is refreshed or updated periodically, this can cause delays in the user being affected by group membership changes. Therefore, if you're thinking about implementing this feature at a site, take note of the following:
If there are hundreds of users at a site, it might be prudent to locate a GC at that site, even if it is connected to the rest of the network via slow links. HP designed its network so that GCs are placed more frequently in sites with slow WAN links, thus shielding the users from those links. If there are only a few users in a small sales office, the use of Universal Group Membership Caching will give the users the performance of a local GC without the overhead and expense of having one at that site. The difference, of course, is the membership update latency. Global Catalog (GC) ImprovementsIn addition to the Universal Group Membership Caching feature, several other significant improvements were made to GC server functionality, including improved replication performance of the partial attribute set (PAS), improvements in GC demotion performance, and improvements in the way GCs advertise themselves . Perhaps the biggest single improvement, not only in the arena of GC performance, but in all of Active Directory, is the addition of the Install from Media (IFM) feature. Partial Attribute Set (PAS) ReplicationGCs provide quick access to commonly used objects and attributes for any domain in the forest, reducing WAN traffic and improving search performance from the user's perspective. By definition, GCs contain all the objects of all domains in the forest, all the attributes of the objects in the domain for which the GC is a DC, and some of the attributes of the objects in the other domains in the forest. The objects and attributes for the other domains are stored in a read-only context and comprise the PAS, which is defined in the schema. Attributes in the PAS have the property isMemberOfPartialAttributeSet set to TRUE, which causes them to be replicated to the GC server. If an Administrator desires to add additional attributes to the PAS so that searches on certain attributes occur more quickly, he or she could edit the appropriate object via the Active Directory Schema Manager, and change the attribute from the Optional list in the object properties to the Mandatory list. This action sets isMemberOfPartialAttributeSet to TRUE. For instance, on the PrintQueue object, printColor is an optional attribute. An Administrator who is a member of the Schema Admins group desires to add printColor as a mandatory attribute so that attribute will be replicated to all GCs. Thus, a user visiting a site from another domain can locate a color printer faster because the local GC has the printColor attribute associated with the printers. To set this, the Administrator would open the Active Directory Schema Manager snap-in, right-click on the printQueue object on the left pane, go to Properties, and add the printColor attribute from the Optional list to the Mandatory list, as illustrated in Figure 1.10. Figure 1.10. Changing an optional attribute to a mandatory attribute in the Active Directory Schema Manager.In Windows 2000, an operation as simple as this would cause all GCs in the forest to perform a full synchronization of the read-only directory partitions, causing a bandwidth spike for each GC roughly equivalent to promoting a DC to a GC, and causing a temporary disruption of service. Windows Server 2003 changes this behavior by replicating only the changed attributes. This is a significant improvement in performance, making the attribute change almost insignificant in most cases. GC Partition OccupancyIn Exchange 2000 and Windows 2000, there was an issue with Exchange failures caused during a GC promotion. Exchange 2000 and later versions rely on the GC for the Global Address List (GAL). When a GC is promoted, it does not require a reboot at the end of the process. When it is rebooted, the GC advertises itself as a GC and is used by Exchange for directory lookups. If it is rebooted before the read-only partitions are fully replicated, some MAPI clients might use the GC for the GAL, causing possible mail failure for those clients . Windows 2000 SP3 includes a workaround that allowed the Administrator to add the Global Catalog Partition Occupancy value to 6. This is located in the Registry at HKLM\system\currentcontrolset\services\ntds\parameters . This parameter does not allow the new GC to advertise itself until replication is complete for all naming contexts (NCs). (See Microsoft KB 304403 "Exchange Considerations for Promoting a Domain Controller to a Global Catalog Server" for more details.) Windows Server 2003 implements a new value in this same Registry location to set this behavior by default. The value is Global Catalog Promotion Complete, and the data for this value is set to 1 by default. This prevents the GC from advertising itself until the replication of all NCs to the GC is complete. At that point, DSAccess adds that GC to its GCList for use by Exchange clients. Install from Media (IFM)The Install from Media (IFM) feature is perhaps the single most significant improvement in the Windows Server 2003 GC features, and one of the top improvements in all of Active Directory. You enable this feature in DCPromo to permit replication from a restored backup of a DC or GC as the source, rather than replicating from a live DC or GC over the WAN. Thus, you can back up the system state of an existing DC/GC and then restore it to media that will be local to a server that will be promoted to become the new DC/GC. The media can be tape, CD, DVD, hard disk or other media that will be local to the new server (of course, the media must have the capacity to store the restored system state files). DCPromo can then be executed with the /ADV switch from a command line: DCPromo /ADV DCPromo produces an additional dialog box, shown in Figure 1.11, with the option to specify a path to the restored backup media. DCPromo will then use this media as the source to replicate the AD without touching a source DC. At the end of DCPromo, a connection is made to a live DC to source changes that occurred since the media was created. The "DCPromo" section later in this chapter details how the IFM feature works, and discusses the use of unattended answer files. Figure 1.11. The new DCPromo dialog box permits Administrators to specify a path to restored backup files to be used as a source for replicating AD, rather than replicating over the network.
Although it is highly beneficial to build DCs using this feature, it's even more beneficial to build GC servers in this way because of the size of the GC compared to a DC. A good example is Hewlett-Packard's AD deployment. The system state backup of a GC in HP's environment is about 10 to 12GB, but can be defragmented to about 7.5GB. In Windows 2000, HP experienced a number of GC- related problems that required GCs to be rebuilt. Because of the size of the AD and available bandwidth on the network, rebuilding a GC took from three to five days, depending on the location. This seriously impacted the users because the GC is used for Exchange's GAL, and loss of a GC at a site required the users to find another GC for GAL operations, impacting performance and putting an additional load on other GCs. In some cases, HP actually had backup GCs in some sites to mitigate the downtime required if a GC had to be rebuilt. Initial testing of Windows 2003's IFM feature proved that a GC could be rebuilt in about 20 minutes from media. HP viewed this as a critical feature to making the AD environment more resilient and significantly reducing downtime. IFM was a key reason why HP migrated to Windows Server 2003. In fact, HP had migrated the Americas domain to Windows Server 2003 native in November 2002, shortly after the release of Release Candidate 3 of Windows Server 2003. Thus, HP was running its production environment on beta software. That speaks volumes for the importance of IFM as well as for the stability of Windows Server 2003. Today, in actual practice, HP can rebuild a GC using IFM in about 20 minutes. Removing GC RoleOne of the contributing factors in the lengthy process of rebuilding a GC in Windows 2000 was the time required to demote the GC. The operation is quite simple. In the Sites and Services snap-in, you right-click on the NTDS Settings object of a DC and select Properties. On the Properties page, there is an option for Global Catalog. If this box is checked, clearing it initiates a demotion process that removes the read-only partitions from that DC. In Windows 2000, the GC removal process was limited to about 500 objects every time the Knowledge Consistency Checker (KCC) ran. By default, this was every 15 minutes. Thus, an AD with 4,000 users, 6,000 computers, and 500 groups (total of 10,500 objects) would require 21 iterations of the KCC to clean up one GC and make it a DC. Using the default 15-minute interval, this would require 5 hours and 15 minutes to complete this change. Windows Server 2003 changed the way this demotion is handled. Instead of replicating a certain number of objects per each KCC cycle, the operation continues removing objects until all objects are removed. Replicating these objects is a low priority among replication tasks , so if another replication request comes in, it takes priority. Thus, if you remove the GC role during low utilization periods, the process continues, possibly uninterrupted. Otherwise , it uses available bandwidth until the job is complete. This results in a more efficient way to remove the GC. Combined with the IFM feature, removing a GC role and adding the role to another DC is much faster and more efficient. Domain Controller RenameWhile supporting Windows 2000 Administrators during the past several years , I ran into a number of situations in which the name of the DC had to be changed. The problem with Windows 2000, of course, is that the only way to change the computer name of a DC is to demote it, change the name, and then repromote it. This is a complex process to perform a simple task. Of course, the answer in NT was worse ”you had to reinstall the DC. Windows Server 2003 provides a very viable feature called Domain Controller Rename (not to be confused with Domain Rename). This functionality requires the domain to be in Windows Server 2003 domain functional level and can be performed either via the GUI (Graphical User Interface) or by using the Netdom option. You'll learn both methods in the following sections. The Netdom method gives you more options, such as renaming the NetBIOS or the DNS (Domain Name System) name, whereas the GUI method renames both. note The Netdom method of renaming a DC requires the domain that the DC is a member of to be in Windows Server 2003 functional mode (all DCs are Windows Server 2003), whereas the GUI method works in Windows 2000 Native or Windows Server 2003 functional levels but only on Windows Server 2003 machines. Using the GUI MethodThis method is fairly simple. Use the same process you would use to rename any Windows 2000 Professional, Windows 2000 Server, Windows Server 2003 member server, or XP workstation. Right-click on My Computer, select Properties, and select the Change button in the Computer Name tab. A pop-up message appears, as shown in Figure 1.12. Just click OK and the familiar Computer Name Changes dialog box appears that allows you to change the name, as shown in Figure 1.13. You are prompted for credentials and, if all goes well, you are notified of the need for a reboot. As you can see, this process is pretty much the same as the process for renaming any other computer. This process modifies Registry values and cleans up DNS (mostly). If you want to see what is going on under the hood, or if you want to change the NetBIOS or the DNS name (but not both) read the "Using the Netdom Method" section coming up next. Figure 1.12. Warning message when attempting to rename a DC from within the UI (user interface).Figure 1.13. Familiar dialog box to rename a computer ”now available to rename a DC.
Using the Netdom MethodWindows Server 2003 added a couple of new options to the Netdom command-line utility: Computername and RenameComputer. The RenameComputer option isn't made to work for a DC. Although it does seem to work without error, it doesn't do all the things it needs to for a DC rename, so don't use it. Using the Netdom Computername command requires several steps, and the process gives you a good view of what is going on under the hood. The steps to rename a DC with the existing name of DC1 to ATL-DC1 are as follows : note Before proceeding, you must set the domain functional mode to Windows Server 2003 (all DCs in the domain must be Windows Server 2003).
DNS CaveatAlthough both methods of DC rename do a good job of cleaning up DNS, they both fail in changing the name of delegation records with the old computername. This can be a big problem if you let DCPromo configure DNS on the forest root DC (the first one in the forest) because it automatically delegates the _msdcs zone to that first DC. If you have child domains and use this delegation, a DC from each domain will have a delegation record to this zone. If you rename any of these DCs, the delegation record will not be updated (as of the RTM release of Windows Server 2003). This is demonstrated in Figure 1.14. This is a screen shot of the DNS snap-in of a DC, previously named ALMA.Company.com, renamed to ATL-DC1.company.com. Note that the _msdcs zone is delegated, and there is one delegation record to ALMA.Company.com. Figure 1.14. DCRename function does not clean up DNS delegation records for the renamed DC.Left in this state, all queries for Cname records and GC records will fail because the referral will go to a nonexistent server. You can easily change this by right-clicking on the record in the right pane, selecting Properties, selecting EDIT, and then entering the correct name and the IP address. Do this for each delegation record that points to a renamed DC. Application PartitionsOne of the criticisms of AD has been that its scalability is limited by the fact that you have only three naming contexts: configuration, schema, and domain. Windows 2003 introduced application partitions. An application partition is a user-defined naming context that can be hosted by any set of DCs from any domain. Thus, there is no domain boundary in such a partition. You create the partition in the NTDSUtil tool. When you create such a partition, you also create a DNS forward lookup zone and place SRV records of the DCs that host the partition. Think of a partition as a truck and data, such as the zone information, as cargo on the truck. When you replicate the partition, the zone information goes with it. You can add other data to the partition and replicate it to the DCs in the replica set. Application partitions have the following characteristics:
How Application Partitions WorkFigure 1.15 shows how an application partition, Payroll.company.com, was created in the Company.com forest. The forest also contains EU.company.com and NA.company.com> child domains. The application partition contains a DC from each of the three domains. Thus, DC1, DC3, and DC5 host the Payroll NC as well as the schema, configuration, and respective domain NCs. This partition is represented in the figure as a triangle, which usually denotes a domain. This is appropriate because this partition is a NC just like a domain is, although with limited capabilities. As noted previously in this section, executing Repadmin /showreps on one of the DCs lists the application partition's replication information just as any other NC: Kansas City\NA-DC5 DC Options: (none) Site Options: (none) DC object GUID: 5b557f71-d9f1-4ad2-9252-185eefa117eb DC invocationID: ac23b6a7-9734-4388-b644-80ba020aab13 ==== INBOUND NEIGHBORS =============================== <snip> DC=Payroll,DC=company,DC=com Seattle\Company-DC1 via RPC DC object GUID: df3cf60f-5b62-469a-a957-1782b52a00e8 Last attempt @ 2003-11-07 19:47:56 was successful. Oslo\EU-DC3 via RPC DC object GUID: 144b8bc1-3321-4fcf-9b27-40c3f2cc0346 Last attempt @ 2003-11-07 21:32:52 was successful. Figure 1.15. User-defined application partitions can use any DC from any domain in the forest as a replica.
Default Application Partitions: ForestDnsZones and DomainDnsZonesMicrosoft implemented two application partitions in Windows 2003 domains that are created and configured by default when a domain is created. They are called ForestDnsZones and DomainDnsZones, and you can see them in the DNS snap-in as forward lookup zones. All DCs (including GCs) in the forest are replicas for the ForestDnsZones partition, and all DCs in a domain are replicas for the DomainDnsZones partition. There is a separate DomainDnsZones partition for each domain in the forest. We describe these partitions in detail in the "DNS" section in Chapter 6, "The Physical Design and Developing the Pilot." Microsoft says it's inappropriate to replicate data where it isn't needed. In an Active Directory Integrated (ADI) zone, the zone data is held in AD and is replicated to all DCs, whether they are name servers or not. With the application partitions of ForestDnsZones and DomainDnsZones, DNS zone information is replicated only to DCs that are also DNS servers. ForestDnsZones contain only SRV records of DCs who are also DNS servers in the forest, and DomainDnsZones contain only SRV records of DCs who are also DNS servers in the domain. Each domain has one of these zones. Because it really isn't recommended to use these default partitions for other purposes, let's look at an example of how you can use a custom application partition. User-Defined Application Partition ExampleThe CFO of a company wants to develop a new in-house application to manage the compensation plan of the company's employees. Most of the data that the application will use is semi-static (pay rate, tax ID, health benefit selections, health benefit costs, and so on) and typically changes only on an annual basis. The human resources organizations that will leverage the application are split into two distinct groups. The NACompensation group manages North American employees and is located in New York. The APCompensation group manages Asia-Pacific employees and is located in Tokyo. The CFO mandates to the developers that unlike most information in the AD, the data managed by this application should be considered sensitive and should be replicated only between New York and Tokyo (both hub sites), but nowhere else. The in-house developers decide that the data needs to be replicated between both the New York and Tokyo sites and should also be updated from both locations for the purposes of day-to-day human resources functions, data analysis, and application fault tolerance. As such, the developers determine that the type of data, the data's user affinity, the requirement for replicated data, and the need for multi-master updates fit well with the features and capabilities of AD. The developers decide to use an AD application partition, which is created on a DC in New York, followed by the addition of a Tokyo DC to the replica set. After the DCs have a replica of the application partition, they register an A record in DNS for the application partition name as well as an _ldap SRV record for the site in which the server resides. The benefits of this architecture include the following:
The down side to this is that these partitions will work only on DCs, and it has long been recognized that installing applications on DCs is not a best practice. Another option is another Microsoft product called Active Directory Application Mode (ADAM). ADAM allows LDAP querying and replication to nondomain controllers but has some restrictions. We discuss ADAM in Chapter 5, "Active Directory Logical Design." Creating an Application PartitionIn the following example, we will create an application partition called MyAppPart in a forest that has three domains: Company.com, NA.company.com, and EU.com.
Finally, when a DC is demoted, DCPromo recognizes whether that DC is the last replica of an application partition. You will see a screen listing the application partitions and asking for confirmation that you want to continue and delete these partitions. AD ReplicationMicrosoft made a number of improvements to AD replication. This section provides a quick summary of these improvements, but you'll find a more detailed description, including examples of implementation, in the "Replication Topology" section of Chapter 5. Lingering ObjectsLingering objects have been causing problems in Windows 2000 deployments for some time, yet at conferences, none of the attendees recognize this issue. Simply stated, lingering objects are objects that are reanimated after their tombstonelifetime expires and is purged. This is caused when a DC or GC comes back online after having been offline for more than the tombstonelifetime period, 60 days by default. Objects that were deleted, tombstoned, and purged while the DC/GC was offline are replicated back into the environment when the DC/GC comes back online. This causes security problems because the user object of a dismissed employee could be reanimated, cause replication to break, and otherwise clutter the AD. The real problem is when a GC comes back online and reanimates read-only contexts of the objects, which were difficult or impossible to delete before Windows 2000 SP3. Windows 2003 and Windows 2000 SP3 and later provide functionality to prevent these objects from replicating through the forest and permit deletion of the read-only objects via a Registry key. "Tight" behavior refers to a condition in which replication from a DC/GC trying to reanimate purged objects is shut down until it is repaired. "Loose" behavior allows the lingering objects to be reanimated. Loose behavior is the default in Windows 2000 and is the default after upgrading from Windows 2000 to Windows Server 2003. We discuss this thoroughly in Chapter 5. ISTG Performance and Practical Limit to Number of SitesEven when Windows 2000 was still in beta, Microsoft was promising improvements in the performance of the Intersite Topology Generator (ISTG). The ISTG uses the spanning tree algorithm to generate the connection objects and the AD replication topology. This is the foundation of AD replication. The efficiency of this topology determines replication latency and the time the AD takes to perform its calculations. The performance of the KCC was inefficient enough to impose a practical limit on the number of about 200 sites in a topology in Windows 2000. Windows Server 2003 has a completely rewritten spanning tree algorithm that makes dramatic improvements in the ISTG's performance, raising the site limit to about 3,000, according to Microsoft testing as of this writing. It also has improved general AD performance and reduced latency in many cases. Chapter 5 provides a complete description of this issue. Bridgehead Load BalancingAnother limit in Windows 2000 was the number of sites that could be connected to a single hub site in a single domain. That is, if you have a strict hub and spoke topology and a single domain, you are limited to about 100 to 150 sites connected to a hub site. This is due to the fact that the KCC will only pick one Bridgehead Server (BHS) per domain per site, and large numbers of sites put a load on that single DC in the hub site sufficient to impact the DC's performance. The solution in Windows 2000 was to create all the connection objects manually, making connections from the site BHS to multiple DCs in the hub site. Unfortunately, this had to be managed manually as well. Windows Server 2003 provides the Active Directory Load Balancing Tool (ADLB), which is a GUI-based tool you can use to create and manage these connections. Chapter 5 provides details on this feature as well. Improved Data CompressionWindows Server 2003 has improved the algorithm that decompresses inter-site replicated data. This improves replication performance and reduces latency. Windows Server 2003 also permits you to turn off inter-site compression of data, trading the increased bandwidth for local DC performance. (See Chapter 5 for additional details.) OtherChapter 5 also covers a number of improvements in Windows 2003 Server in the area of AD replication. The chapter describes and analyzes practical examples and case studies of companies that have had success and failure in deploying AD in Windows 2000 and 2003. FRS and DFSChapter 5 also covers the new features and fixes made in Windows Server 2003, and provides a good description of new troubleshooting and diagnostic tools. For the purpose of this chapter, a brief summary is in order.
Time ServicesKerberos authentication relies heavily on accurate time synchronization between all computers in the forest. By default, the time skew between any two computers in the forest must be five minutes or less. Windows 2003 uses the Network Time Protocol (NTP) for a much more efficient means of synchronizing computers in the network than Simple Network Time Protocol (SNTP) used in Windows 2000, with the capability to synchronize computers within milliseconds . Windows Server 2003 also provides a new version of the Win32tm.exe utility to configure time services. Chapter 5 describes in detail how time services work in conjunction with Kerberos for security, as well as time-service configuration and troubleshooting tips. Domain RenameIf Windows Server 2003 were a retail business with a big electric sign out front advertising three exciting reasons to patronize the business, Domain Rename would likely be one of the three. With mergers, acquisitions, and divestitures becoming commonplace in the business community these days, the ability to rename a domain or forest is a very useful tool, especially because the alternative is to migrate users, groups, and computers from one domain/forest into another. In fact, HP is a good example of such a situation. Compaq had developed an extensive Windows 2000 infrastructure, participating as an early adopter in Microsoft's Rapid Deployment Program (RDP) and Joint Deployment Program (JDP). At the time of the merger with HP, Compaq was just completing a two-year migration of users from the old NT domains inherited from mergers with Digital and Tandem. HP, on the other hand, had a small NT environment and had not built a Windows 2000 structure at all. The decision was made to use Compaq's Windows 2000 infrastructure and to migrate the HP users into it. This made perfect sense, except for the name of the domain. The internal namespace for Compaq was CPQCORP.NET and was structured as shown in Figure 1.16. Thus, there became a business requirement to rename the domain. HP decided that the new domain should be HPQCORP.NET ”the net change being one letter ”C to H! Figure 1.16. Compaq's Windows 2000 and 2003 domain structure.
As of this writing, HP has not renamed this domain, but is planning on it. However, Microsoft has had a couple of customers successfully rename a domain, and Microsoft successfully renamed its corporate development domain as well. One of its customers mistakenly renamed a domain with Exchange 2003 (pre-SP1) and then had to rename it back to the original. Pretty impressive to do it twice, ending up with the same name and be successful. It also shows good resiliency. This section provides a fairly high-level description of how Domain Rename works to give you an idea of what's involved. We give pointers to Microsoft whitepapers that provide the details on how to actually rename a domain. The remainder of the section reviews Domain Rename from a design perspective, discussing capabilities and limitations of Domain Rename, application compatibility issues, details on Exchange compatibility, benefits and risks analysis, and a few examples along the way. How Domain Rename WorksThe Domain Rename procedure is well documented in two whitepapers, Understanding How Domain Rename Works, and Step-by-Step Guide to Implementing Domain Rename, which you can download from http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx. In this section, we don't rehash the material in the whitepapers, but rather, summarize their contents and apply my experience to make recommendations. The whitepapers are the definitive guide to Domain Rename, so download, read, and use them. The step-by-step guide provides the actual procedure. I worked at Microsoft during the Windows 2003 beta documenting training materials for Domain Rename, and have monitored HP's Domain Rename efforts. In addition, I have worked with a few customers who were considering using it, so I've had a good bit of exposure to Domain Rename. Following is a high-level view of the procedure. The forest must be at Windows 2003 functional level, and all domains must be at Windows Server 2003 functional level. This means every DC in the forest must be Windows Server 2003. Identify a member server in a domain (must have reliable access to the domain naming master) from which to run the Domain Rename commands. Get the Domain Rename tools, rendom.exe and gpfixup.exe, from the Windows Server 2003 CD in the \ValueAdd\ MSFT\MGMT\Domren directory, from the Web at http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx, or from the Web site that contains the whitepapers noted previously. These tools are also available on the Windows Server 2003 CD, but the versions included on early Windows Server 2003 CD releases broke Exchange. It's best to get them from the Web site to get any new versions available. The Step-by-Step Guide to Implementing Domain Rename whitepaper details the process used to rename the domain. Following is an overview of that process:
These steps have been included here to show you how complex this process really is, and that there really isn't an easy way back once you start. The key is step 5. You need to realistically determine how long it will take to contact every DC in every site in the entire forest. According to HP's AD team, end-to-end replication took a few hours, but they estimated that it could take several weeks to update all the DCs in the Domain Rename process. Now let's examine the capabilities ”what Domain Rename can and can't do ”to determine whether this operation can meet your requirements. Capabilities of Domain RenameIt is important to note that Domain Rename is not the same as "Prune and Graft." Prune and Graft operations usually imply a "merge" of two forests; that is, Company A buys Company B. Moving the B.com domain to become a child of A.com (B.A.com) is referred to as pruning and grafting . Domain rename is bounded by the forest. note Domain Rename is not the same as Prune and Graft. Prune and Graft, or merging of domains across forests, is not possible in Windows 2003. Now let's see what you can and can't do with Domain Rename. The following list identifies significant operations that Domain Rename can perform:
Limitations of Domain RenameDomain Rename has a number of limitations, some of which could prevent you from deploying Domain Rename, forcing you to use a migration solution instead. These limitations include the following:
Application CompatibilityThe problem at this point in the evolution of the Domain Rename technology is that there just isn't much data on application compatibility. Even Microsoft, at the time of this writing, doesn't have a definitive list of Microsoft applications that support Domain Rename. Note that no application is completely "incompatible," as it can certainly be uninstalled and reinstalled, but obvious costs and risks are involved in doing that. It is important to include application compatibility in any cost/benefit analysis for Domain Rename. There are certainly other ways to solve a problem than by renaming the domain and cleaning up afterwards. In the next section, we discuss the cost/benefit of Domain Rename in detail. Although our experience with Domain Rename is limited at this point, we do know the following:
note The information in this list is accurate as of this writing. Because reviewing application compatibility is an ongoing process, you should contact Microsoft via its Web site or directly via its support center to determine the current status of these and other applications. When I asked Microsoft for a list of applications it had compiled, the company told me that rather than providing the list (which will have changed by the time this book is printed), it preferred to give the following guidelines:
Exchange Recovery OptionsIt has already been noted that Exchange 2000 and Exchange 2003 (RTM or pre-SP1) do not support Domain Rename, and renaming a domain with these versions of Exchange deployed breaks the System Attendant. Microsoft recommends the following process for recovering Exchange if Domain Rename is deployed:
Microsoft reported customers who successfully renamed the domain back to the original name as a recovery measure, but careful planning and understanding the issues will avoid this, as it is time-consuming and costly. In terms of planning, it is important to determine whether Domain Rename is appropriate for your situation. Let's review the benefits and risks to help you determine whether Domain Rename really is the best solution. warning Rendom.exe versions prior to 6.0.4011.0 failed to detect Exchange 2000. Such versions erroneously allowed Domain Rename operations when Exchange was detected in the forest. Broken versions shipped on Microsoft.com in 2003 and on Windows 2003 installation media. Domain Rename breaks Pre-SP1 Exchange's System Attendant and implicitly Exchange 2000 name resolution. The fix for this was to rename modified domain names back to the original name. The updated rendom.exe is available from http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx. Exchange SP1 and later supports domain rename, but make sure you use the rendom.exe from this Web site. Benefits and RisksWhen considering Domain Rename as a solution for your situation, review the previous list of capabilities and limitations to determine whether Domain Rename fits your requirements. If it does, assess the impact on downtime, testing, and IT staff costs as well as how much time it will take. Remember that you must contact all DCs in the forest to complete the operation. Make sure all your applications will support Domain Rename as well. As noted previously, the best way to do this is to test your applications' compatibility in a Domain Rename operation in an accurate test environment. Next, determine how a simple migration stacks up against this criteria and see which one (migration or Domain Rename) makes sense. Microsoft's experience at this point suggests the following:
In HP's case, although Domain Rename is a big undertaking, it's not nearly as difficult as migrating the users, groups, and computers to a new domain. Remember, it took Compaq two years to migrate the Compaq objects ”it would have taken much longer with the HP users and they would have had to start all over again. In HP's case, the decision was basically whether to take another two or three years to remigrate everyone, or spend the time and money to test and implement the Domain Rename. One customer I spoke to at a conference worked for a subsidiary of a large aerospace company that was changing its company name. The company was currently at Windows 2000 and considered upgrading to Windows Server 2003 so it could simply rename the domain. The company has a single domain, 15 domain controllers in 8 sites, and about 1,000 users. I gave him an explanation of how it works, and helped him create a Domain Rename lab that I created for the conference. After three hours trying the lab (three DCs in the test forest), he decided migration with Active Directory Migration Tool (ADMT) would be easier and more reliable. Domain rename is a one-way street. Recovery of the original domain depends on your backups , whether you have any DCs left, and how the rest of the environment can absorb the impact. Remember that there are other alternatives to solve your problem; if you use Domain Rename, make sure it is the best solution available, and then thoroughly test it. Additional InformationAppendix B, "ProLaint Product Details," contains a Domain Rename flowchart that will be helpful in assessing the impact of implementing Domain Rename, as well as providing a good overview for the design of the process. In addition, a training exercise for Domain Rename is available on the book's Web site at http://www.phptr.com/title/0131467581. This exercise can easily be done using VMWare or Microsoft's Virtual PC software and will give you a good idea of how Domain Rename is accomplished. DCPromoDCPromo improvements in Windows 2003 consist primarily of the new Install from Media (IFM) feature noted previously in this chapter, and some improvements in the DCPromo answer file for unattended promotions. The next section provides a step-by-step procedure on how to use the IFM feature, followed by a section on unattended DCPromo operation. The latter provides details on creating a DCPromo unattended answer file and using it with the IFM restored backup files to create an unattended DCPromo using IFM. These two exercises require a DC and a member server in a domain. Install from Media (IFM)Previously, we described this feature from a benefits standpoint in the "Global Catalog Improvements" section of this chapter. This section provides a step-by-step description of how to perform IFM to restore a DC or a GC. The exercise backs up a DC's system state (AD), copies the backup file (.bkf) to a share on a member server, and restores the .bkf to a local directory on the member server. note IFM can restore only a replica DC. It cannot create the first DC in the domain because it uses the backup of an existing DC to source from.
note The restored files must exist on local media to the member server ”tape, CD, DVD, disk, and so on. This operation will not work from a network share. DCPromo proceeds as usual. The difference is that it will be sourcing from the media, not from a live DC. At the end, it will sync with a live DC to replicate changes between the state of the media and the current state of the AD. tip If you test this with a copy of your production data in a lab environment, try running a normal DCPromo operation and time it. Use IFM to promote another DC and compare the time. Unattended DCPromoThere are only a few new commands to the DCPromo unattended answer file syntax for Windows Server 2003, but the combination of an unattended answer file and the IFM feature presents some intriguing possibilities. For instance, one company had a remote office in Alabama with no IT staff. The company sent the receptionist to training so that she could perform basic tasks that required on-site attention. The company developed a simple .bat file and an unattended answer file to run from it, and sent that on a floppy disk (or even e-mail), along with the restored media and some instructions about where to put things, and she could run the .bat file and promote the DC without having to answer any questions in the process. In this section, we will demonstrate how you can create an unattended answer file for DCPromo on a member server. Then, you run DCPromo from a command line with the /adv switch to allow the AD to be installed from the restored backup rather than from a live DC, with the /answer : switch to read the answer file. This exercise assumes you have a DC and a member server in a domain.
If you successfully provide all the answers to DCPromo's questions, you will not be prompted. DCPromo completes and reboots the server. Obviously, you might have typos or other problems, so it's best to test this out before using it in production. A couple of important things to note:
warning The backup media is good only for the time specified by tombstonelifetime (default 60 days). Do not use media older than this, because it will cause lingering objects in the AD. (See Microsoft KB 216993 "Backup of the Active Directory has 60-day Useful Life.") Linked Value Replication (LVR)Windows NT performs replication on an object level, whereas Windows 2000 improves on this and performs replication on an attribute level. This is a significant improvement: When you changed the password on a user account, NT 4 replicated the whole object and Windows 2000 replicated the password attribute and not the rest of the object. However, this still had some limitations when replicating multi-valued attributes. Multi-valued attributes are attributes of AD objects that contain multiple values. Functionally, you can describe the Jet database as a table with rows, columns , and values in the cells. Table 1.3 depicts how a global group object would be stored in Jet. The cells labeled Group Name, Type, Members , and Scope are attributes. The entries Domain Users, Security, and Scope are attributes. Note that the group members are all lumped together in a single attribute, instead of each name being an attribute itself. In this case, Members is a multi-valued attribute. The problem comes when you remove or modify a member of the group, or add another member. Because Windows 2000 replicates the entire attribute, all values ”thus all the members of the group ”are replicated, too. In the case of large groups of thousands of members, this can have a negative impact on replication performance due to the increase in network bandwidth required. In addition, there is a limitation in the capability of the database write operation to make a change in large attributes. Because of this, Microsoft does not support groups that contain more than 5,000 members. Deployments like HP's with tens of thousands of users solved this with nested groups. Table 1.3. Functional Layout of a Global Group Object in the Jet Database
In Windows 2003, replication is performed on attribute values. Thus, for large groups, if the membership is modified, only the value (member) that is added, modified, or deleted is replicated. Thus, a single value can be replicated rather than the entire group. This has eliminated the infamous 5,000-member limit on groups. Group PolicyMicrosoft seems to be following a philosophy to expose options for just about anything through Group Policy. Windows NT had 79 System Policies, Windows 2000 had about 700 Group Policy settings, and Windows 2003 has added more than 200 new settings, many of which deal with new features such as Time Services (NTP), Wireless Network Policy, and Software Restriction policies. In addition, some significant new tools were produced that make managing and troubleshooting Group Policy much easier. First, we cover the new tools, and then we cover some of the new policies. Three new tools are significant to troubleshooting and managing Group Policy: Gpupdate.exe, DCgpofix.exe, and the Group Policy Management Console. GPupdate.exeThis tool replaces the old Secedit /refreshpolicy . Remember this because secedit no longer refreshes policies. GPupdate.exe includes a number of switches:
DCgpofix.exeCustomers using Windows 2000 frequently called for support when trying to restore the Default Domain Policy or Default Domain Controllers Policy to the original default settings. Microsoft developed a tool to address this problem. DCgpofix.exe has been enhanced and is now a built-in tool that restores the Default Domain Policy, the Default Domain Controllers Policy, or both using the following switch: /Target: Domain /Target: DC /Target: Both In addition, the /? switch produces a help file. warning If you reset these policies to the default, you will lose all manual settings you have made, including Encrypted File System (EFS) settings. Group Policy Management Console (GPMC)The GPMC tool is a welcome sight for Administrators of environments with multiple domains and many policies. It has a number of great features, including the following:
GPMC is available as a free download from Microsoft's Download Center on their Web site, although you technically need to have a Windows Server 2003 license. It runs on Windows 2000 or Windows 2003 domains. However, the machine that GPMC runs on must be a Windows Server 2003 server or a Windows XP client. We include more details and examples in Chapter 5. New Client-Side Extension PoliciesWindows Server 2003 policy includes three new Client Side Extensions (CSEs) ”Wireless Network Policy, Software Restriction Policy (SAFER), and QOS (Quality of Service) Packet Scheduler ”in addition to the CSEs that were in Windows 2000. The QOS Packet Scheduler was part of several updates to QOS in Windows Server 2003. This feature is used in QOS for bandwidth throttling. Software Restriction Policies are a new security feature described in the "Security" section of this chapter. Wireless Network Policy added settings in the policy to define wireless settings such as preferred networks (by Service Set Identifier ”SSID) and types of networks to access. Figure 1.17 shows the Wireless Network Policy Properties page available via the Group Policy Editor. Figure 1.17. Wireless Networks Property Policy page as it appears in the Group Policy Editor.note By default, no Wireless Network Policies are defined. The Wireless Network section of the Computer Configuration of Group Policy is blank. Right-click on the Wireless Network icon and select Create Wireless Network Policy. Note that you can create only one Wireless Network Policy. Changes in User RightsOne of the most glaring changes that trips up a lot of Administrators new to Windows Server 2003 is the old Logon Locally right as used in Windows 2000. This right does not exist as such in Windows Server 2003. It now has four settings:
New DNS/Net Logon PoliciesNet Logon settings, exposed only in the Registry, are easily configured now in Group Policy. Fourteen settings are located in Computer Configuration\Administrative Templates\System\Net logon . Some interesting ones include the following:
New Windows 2003 DC Locator DNS RecordsLocated in Computer\Administrative Templates\System\Net logon\Domain Controller Locator Records , this is another dangerous set of policies that allow you to change the behavior of the DC Locator. Here are some interesting ones:
Several other settings allow you to manually constrain the DC Locator. Make sure you have good reason for tweaking these settings, and that you thoroughly test and document them before implementing. New Client-Side DNS SettingsSeveral new settings control the client DNS functions, located in Computer Configuration\ Administrative Templates\System\Network\DNS Client . In Windows 2000, there was only a single setting: Primary DNS Suffix. Now there are 13 settings. Some of the interesting (and frightening) ones are as follows:
Computer Configuration\Administrative Templates\ System\ Group Policy
System Restore and Remote AssistanceWindows XP and Windows 2003 Remote AssistanceEnabling the Remote Assistance policy allows expert help by permitting access to the computer. Note that the user will still be prompted to allow access to the computer when the expert contacts it. You can find this policy in Computer Configuration\Administrative Templates\System\Remote Assistance . Windows XP System RestoreComputer Configuration\ The System Restore policy enables or disables the user's ability to restore an XP client to a previous known good state. You can find this policy in Administrative Templates\System\System Restore . Windows Installer System RestoreComputer Configuration \ Windows Installer creates a system restore checkpoint for each application during installation. You can disable this with this policy setting, found in Administrative Templates\System\System Restore . Error-Reporting PoliciesThe error-reporting policies enable you to control the error-reporting feature Microsoft first built into Windows XP. A typical error is shown in Figure 1.18. When an error is encountered, this pop-up window appears, prompting the user to indicate whether the information should be sent to Microsoft (assuming a current connection to the Internet). Microsoft uses these reports to gather data on problems to aid in resolution. It's a way of gathering data from a large number of users who would likely not report the problem, and I've actually seen cases in which Microsoft has used the data to resolve problems. In addition, if there is a possible solution, the user will be notified. I've seen cases in which a Microsoft Office application, such as Word, caused an error report and after I sent it, Microsoft notified me that the error could be solved by upgrading to a service pack and gave me the link to it. Figure 1.18. Typical error produced by the error-reporting mechanism in Windows XP and Windows Server 2003.
Microsoft is not trying to steal information and it offers the option of reviewing the report before it is sent. I highly recommend you always send this report. However, Group Policy also provides a number of options for error reporting, including the following. Basic Error ReportingBasic error reporting provides two options:
You can find this policy at Computer\Administrative Templates\System\Error Reporting . Advanced Error ReportingOnly one advanced error-reporting option is available. This policy setting contains more granular configuration of error reporting, such as enabling or disabling reporting of operating system errors, unplanned shutdown events, and application errors. You can find this policy at Computer\Administrative Templates\System\Error Reporting\Advanced Error Reporting . Miscellaneous Policies
New Uses of WMI FiltersWindows Server 2003 provides new capabilities for customizing queries using WMI (Windows Management Instrumentation), including the WMIC interface and the WMI filters in Group Policy. We cover WMI in detail in Chapter 10, "System Administration," in the "Windows Management Instrumentation" section. The WMI filter in Group Policy basically allows a WMI query (filter) to be applied from within a policy. For instance, the following WMI filter checks to see whether the physical memory of the computer is greater than 128MB: Select TotalPhysicalMemory from win32_ComputerSystem where TotalPhysicalMemory >= 134217728 Using the Group Policy Management Console (GPMC), which we describe briefly in this chapter and in more detail in Chapter 10, we can define the WMI filter and associate it with a Group Policy Object (GPO). The procedure to do this is as follows:
We have created a WMI filter on the Accounting Policy (in the example in the figures) so that this policy applies only to computers that have 128MB of memory or more. This is similar to the security filtering in Windows 2000, where you could apply or deny a policy only to certain users or groups. Of course, there is a price to be paid for this. Just like ACL (Access Control List) filtering in Windows 2000, you pay a logon performance price for WMI filtering. In addition, keep in mind that the Windows 2000 clients don't support the WMI queries, so they will always apply the policy, and the filter won't apply to them. ToolsMicrosoft made a number of enhancements to tools used for troubleshooting and monitoring in Windows 2003. The bad news is that most of them won't run on a Windows 2000 machine. The good news is that they will run on a Windows XP client or a Windows 2003 server in a Windows 2000 domain. One of the best troubleshooting tools I've found so far is a Windows XP client. In fact, I've required more than one customer to buy a copy of XP and load it on a client machine so that we could do proper troubleshooting. Here is a summary of some significantly improved tools in Windows Server 2003 (at least the ones I like). Descriptions and examples of how these tools are used are contained in various chapters in this book.
ScalabilityPreviously in this chapter, I've noted new features that provide enhanced scalability. These features are summarized here only to identify them with the fact that they do enhance scalability for the Windows architecture:
Interoperability and Functional LevelsMicrosoft introduced a new feature in Windows 2003, called functional levels, which provides interoperability with Windows 2000 and Windows NT DCs. Functional levels were implemented in Windows 2000, but they were simply known as "native mode" and "mixed mode," referring to whether there were downlevel (NT) DCs in the domain. Windows Server 2003 adds a degree of complexity: Not only does it add another OS that a DC can be installed with, but also introduces the concept of a "forest native mode." Forest native mode means all DCs in all domains in the forest must be at Windows Server 2003, all domains must be switched to native mode (similar to how Windows 2000 domains had to be switched to native mode), and the forest must then be switched to native mode. This is very important because the features and improvements discussed in this chapter depend on the functional level of the domain or forest. To get all the Windows Server 2003 benefits, you must be in a native Windows Server 2003 forest. Table 1.4 gives a good summary of each functional level, what DCs are allowed (by OS), and a comment about functionality. Chapter 3, "Migration Planning: Business and Technical," provides a thorough treatment of functional levels, including a detailed description of how they work and how to configure them, as well as how they affect the design and the migration. Table 1.4. Functional Levels in Windows Server 2003 Domains and Forests
SchemaIn Windows 2000, Microsoft made no small effort to frighten everyone away from modifying the schema because it cannot be restored from an earlier date. If damaged, the schema could cause the entire infrastructure to fail. This is still true in Windows Server 2003. However, there has been an improvement on the front of object management in the schema. Classes and attributes in the schema can now be disabled (as was the case in Windows 2000), but they can also be marked as " defunct " or "redefined." What we need still is the ability to purge and delete, which hopefully is coming in a future update. Dynamic TTLIn Windows 2000, objects existed until they were explicitly deleted. With Windows 2003, objects can be created with a Time To Live (TTL) stamp. They are then deleted when the time stamp expires unless they are refreshed. This should help keep the AD clean. |
< Day Day Up > |