• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Detailed Replication Transaction Descriptions

    Now that we have a general idea of how replication works, let's examine details of the replication transactions themselves. This information helps to diagnose replication problems. It also helps to make critical architectural decisions such as where to place specific domain controllers and how to select the proper inter-site polling frequency.

    Multiple-master replication raises several challenges:

    • Data consistency. It is important that the replicas of each naming context match exactly on every domain controller after all updates have converged.

    • Redundant updates. Domain controllers should not waste time replicating updates that they have already received from the same replication partner.

    • Circulating updates. Domain controllers should not waste bandwidth by replicating updates from one partner when they have already received the update from another partner.

    • Update collisions. There is a good possibility that changes could be made to the same property or object on different domain controllers during the same replication interval. These potentially conflicting changes will eventually collide as they propagate around the system. Domain controllers must handle these collisions consistently to avoid database corruption.

    Property Metadata

    Active Directory deals with the challenges of multi-master replication by embedding replication control information into each property. This information is called property metadata. The metadata information is saved along with the property's primary value each time the property is modified. This is called an atomic transaction, meaning that if one value isn't written, none of them are written.

    You can view the property metadata for an object in one of several ways. The simplest is to use the REPADMIN utility. This utility is available on all domain controllers. You'll need to know the distinguished name (DN) of the object you want to view. For instance, the DN for the Sites object in the Company.com domain would be: cn=Sites,cn=Configuration,dc=Company,dc=com. Here is the REPADMIN syntax and a sample listing. The property in bold was updated after the object was initially created:

    repadmin /showmeta cn=sites,cn=configuration,dc=company,dc=com
    10 entries.
    Loc.USN    Originating DSA    Org.USN   Org.Time/Date        Ver  Attribute
    =======    ===============    =======   =============        ===  =========
       1165    Phoenix\DC-01        1165     2002-02-23 17:48.40   1   objectClass
       1165    Phoenix\DC-01        1165     2002-02-23 17:48.40   1   cn
       2765    Phoenix\DC-02        2843     2002-02-24 18:14.10   3   description
       1165    Phoenix\DC-01        1165     2002-02-23 17:48.40   1   instanceType
       1165    Phoenix\DC-01        1165     2002-02-23 17:48.40   1   whenCreated
       1165    Phoenix\DC-01        1165     2002-02-23 17:48.40   1   showInAdvancedViewOnly
       1165    Phoenix\DC-01        1165     2002-02-23 17:48.40   1   nTSecurityDescriptor
       1165    Phoenix\DC-01        1165     2002-02-23 17:48.40   1   name
       1165    Phoenix\DC-01        1165     2002-02-23 17:48.40   1   systemFlags
       1165    Phoenix\DC-01        1165     2002-02-23 17:48.40   1   objectCategory
    

    The column headings in the listing are abbreviations for the property metadata entries. Here is a description of their function:

    • Local Update Sequence Number (USN). A USN is a sequential number assigned to a property when it is created or modified. Each domain controller maintains a USN counter. Each time any property on any object is modified, the next available USN is obtained from the counter and stored in the property metadata. The USN is a 64-bit number, big enough for a domain controller to allot 10,000 USNs per second for 66 million years.

    • Originating DSA. DSA is the LDAP term for a server that hosts a copy of the Directory database. An Active Directory domain controller is an LDAP DSA. The REPADMIN listing identifies the DSA by its site and computer name, but the actual value is the server's Globally Unique Identifier (GUID). You may see a bare GUID if the server where you run REPADMIN cannot resolve the name and site of the originating server.

    • Originating USN. This is the USN assigned to the property in the replica hosted by the originating DSA. Note that in the example, with one exception, the Local and Originating USNs match. This indicates that the object was created on domain controller DC-01. The Description property was modified on domain controller DC-02. Note that a domain controller updates the Local USN value when a property is modified for any reason: a direct change or a replicated change.

    • Originating Time/Date. This is a timestamp indicating when the property was modified at the originating DSA. This information is used as a tiebreaker in case a property is changed at two different domain controllers in the same replication interval.

    • Property Version Number (PVN). The PVN is a sequential number that identifies how many times a property has been modified.

    The PVN is the key value that determines whether two replicas are internally consistent. The entire replication system is geared to ensure that properties with the same PVN have the same primary value. This is how Active Directory resolves the data integrity challenge. The next few sections detail how property metadata values help control redundant replication requests, prevent circulating updates, and manage collisions.

    Example Replication Transactions

    The next few examples use a three-node replication ring in a single domain and single site as shown in Figure 7.7. The Global Catalog status does not matter because there is only one domain.

    Figure 7.7. Three-node replication ring with all domain controllers in the same domain and site.

    graphics/07fig07.gif

    The example traces a change to a property for a user object with the common name cn=Al Bondigas. Here are a few of the property metadata values for the cn=Al_Bondigas object. The listing was taken by running REPADMIN on domain controller DC-01. The USN and PVN values for the Title property, shown in bold, are different because it was updated after Al's user object was created:

    Loc. USN   Originating DSA     Org.USN  Org.Time/Date                 PVN  Attribute
    =======    ===============     ====     =============                 ===  =========
       1416    Atlanta\DC-01       1416     2002-022002-02-01 01:20.50    1    objectClass
       1416    Atlanta\DC-01       1416     2002-022002-02-01 01:20.50    1    cn
       1416    Atlanta\DC-01       1416     2002-022002-02-01 01:20.50    1    description
       14D3    Atlanta\DC-01       14D3     2002-022002-02-02 12:14.31    2    title
       1416    Atlanta\DC-01       1416     2002-022002-02-01 01:20.50    1    department
    
    Use of Update Sequence Number (USN)

    The Local USN value prevents redundant replication requests. The system uses the Local USN as a high water mark to filter out all but the most current updates between replication partners. Procedure 7.2 shows how it works.

    Procedure 7.2 Replication Trace Showing USN Operation

    1. This series of examples modifies the Description property of the cn=Al Bondigas object.

      Here is the property metadata on DC-01:

      Loc. USN    Originating DSA     Org.USN   Org.Time/Date           PVN   Attribute Name
      =======     ===============     ====      =============           ===   =========
      1416        Atlanta\DC-01       1416      2002-02-01 01:20.50     1     description
      

      Here is the property metadata on DC-02:

      Loc. USN   Originating DSA      Org.USN    Org.Time/Date          PVN    Attribute
      =======    ===============      ====       =============          ===    =========
      2F5        Atlanta\DC-01        1416       2002-02-01 01:20.50    1      description
      

      Note the difference in the Local USN values. When a domain controller applies a change to a property, it includes the next available USN value from its own USN counter.

    2. Now let's modify the Description attribute for Al's object on DC-01. Here is the metadata for the modified attribute:

      Loc. USN   Originating DSA    Org.USN    Org.Time/Date           PVN   Attribute
      =======    ===============    ====       =============           ===   =========
      15B1       Atlanta\DC-01      15B1       2002-02-21 02:35.33     2     description
      

      Note that the PVN was incremented by one.

    3. DC-01 notifies DC-02 of the change and DC-02 pulls a replication packet. Here is the property metadata after DC-02 applies the update:

      Loc.USN   Originating DSA      Org.USN    Org.Time/Date          PVN    Attribute
      =======   ===============      ====       =============          ===    =========
      3AC       Atlanta\DC-01        15B1       2002-02-21 02:35.33    2      description
      

      The Local USN value reflects the state of the USN counter on DC-02 when the update arrived.

    4. When DC-02 received the update from DC-01, it took note of the USN assigned by DC-01. It put this in a USN Table. It uses entries in the USN Table to request only new updates from its partners. Let's see how this works by looking at another replication event, this one for the Department property.

      Here is the property metadata from DC-01 prior to any changes:

      Loc.USN   Originating DSA      Org.USN    Org.Time/Date          PVN    Attribute
      =======   ===============      ====       =============          ===    =========
      1416      Atlanta\DC-01        1416       2002-02-01 01:20.50    1      department
      

      Note that the PVN is 1 and the Local USN matches the Originating USN. This indicates that the object was created on DC-01.

    5. Now let's modify the Department attribute at DC-01. The new metadata listing looks like this:

      Loc.USN   Originating DSA       Org.USN    Org.Time/Date         PVN    Attribute
      =======   ===============       ====       =============         ===    =========
      15B2      Atlanta\DC-01         15B2       2002-02-21 02:37.15   2      department
      

      Note that the PVN has incremented to 2.

    6. DC-01 notifies DC-02 of the change and DC-02 pulls a replication packet but it also includes a stipulation. It refers to its USN Table and includes the last USN it got from DC-01, 15B1. It says, in effect, "Only send updates you haven't already sent me."

    7. DC-01 receives the request with the high water mark USN. It sifts through the queued updates and filters out the update to the Description property because its USN, 15B1, is equal to the high water mark USN submitted by DC-02. This leaves the update to the Department property with USN 15B2. DC-01 packages the update and sends it to DC-02.

    8. DC-02 applies the change. The metadata listing after the update looks like this:

      Loc.USN   Originating DSA       Org.USN    Org.Time/Date         PVN   Attribute
      =======   ===============       ====       =============         ===   =========
      3AD       Atlanta\DC-01         15B2       2002-02-21 02:37.15   2     department
      

    If you get impatient working through process traces, I really don't blame you. Here are the important points to remember so far:

    • When a property is modified, its PVN is incremented and the domain controller applies the next available USN.

    • When a domain controller obtains updates, it stores the USN applied by its replication partner in a USN Table.

    • When a domain controller requests updates, it includes the last USN it got from its replication partner. This high water mark USN prevents getting redundant updates.

    Use of Up-To-Dateness Vector

    The circular nature of directory replication makes it possible for updates to propagate back to domain controllers that have already received the update. Unchecked, these updates keep circulating and circulating, the packets getting bigger and bigger, until the entire network hemorrhages in an Ebola virus of unchecked replication traffic.

    Positive feedback calls for a dampener of some sort. In this case, the feedback dampener is called the Up-to-Dateness Vector, or UTD Vector. It works like this.

    The property metadata includes the identity of the originating server. When a domain controller receives a replication packet, it takes note of the originating server and the USN assigned by that server and stores this information in the UTD Vector table. The UTD Vector table contains the GUID and high USN for every domain controller that has ever originated an update.

    A domain controller includes its copy of the UTD Vector along with the high water mark USN in each replication request. In effect, it says, "Give me the most recent updates and also don't bother giving me any updates that I've gotten from another source." Procedure 7.3 is an example of how this works.

    Procedure 7.3 Replication Trace Showing UTD Vector Operation

    1. Recall from the previous example that the Description attribute modified at DC-01 looks like this:

      Loc. USN   Originating DSA      Org.USN    Org.Time/Date         PVN   Attribute
      =======    ===============      ====       =============         ===   =========
      15B1       Atlanta\DC-01        15B1       2002-02-21 02:35.33   2     description
      

      The metadata for this property at DC-02 looks like this:

      Loc.USN   Originating DSA       Org.USN    Org.Time/Date         PVN    Attribute
      =======   ===============       ====       =============         ===    =========
      3AC       Atlanta\DC-01         15B1       2002-02-21 02:35.33   2      description
      

      When DC-02 applied the update, it also improved the UTD Vector entry for DC-01 to reflect the 15B1 USN.

    2. Now consider what happens when DC-02 replicates the updated Description property to DC-03. Here is the property metadata at DC-03 before and after the update:

      Before:

      Loc.USN   Originating DSA     Org.USN    Org.Time/Date           Ver   Attribute
      =======   ===============     ====       =============           ===   =========
      101       Atlanta\DC-01       1416       2002-02-01 01:20.50     1     description
      

      After:

      Loc.USN   Originating DSA      Org.USN    Org.Time/Date          Ver    Attribute
      =======   ===============      ====       =============          ===    =========
      1B9       Atlanta\DC-01        15B1       2002-02-21 02:35.33    2      description
      
    3. When DC-03 applies the update, it improves the UTD Vector entry for DC-01 to show the 15B1 USN value.

    4. Within five minutes after applying the update, DC-03 notifies DC-01 that it has a pending update. DC-01 then requests a replication packet.

    5. Now, as the carnival magician says, watch the cards, not my hands. Ordinarily, DC-03 would include the update to the Description property in the replication packet. But DC-01 also included a copy of its UTD Vector, which shows an entry for itself of 15B2, the latest USN it assigned to an update in its own replica (the Department property described in the last trace).

    6. DC-03 sifts through the pending updates and sees that DC-01 was the originating server for the Description property with USN 15B1. This USN is lower than the 15B2 value in the UTD Vector, so DC-03 filters the update from the replication packet. The feedback loop is broken. Civilization is saved. Cut to commercial.

    The UTD Vector is a critical component in preventing replication storms. Remember these important points:

    • The UTD Vector is a combination of the GUID of the originating server and the USN applied by that server.

    • A domain controller includes a copy of the UTD Vector with every replication request.

    • When a domain controller receives a replication request, it filters out any updates with USNs equal or lower than the entries on the UTD Vector submitted by the replication partner.

    Replication Collision Handling

    So far, we've seen how property metadata ensures data consistency and controls unnecessary replication. We now need to address the final challenge of multi-master replication: how to deal with conflicting changes made on different domain controllers. These are called collisions. Several situations can cause a collision:

    • Simultaneous modifications. The same property is modified on different domain controllers.

    • Identical DNs. Objects with the same common name are created in the same container on different domain controllers.

    • Object moved. An object's property is modified on one domain controller while the object is moved to a different container on another domain controller.

    • Object deleted. An object's property is modified on one domain controller while the object is deleted on another domain controller.

    • Container deleted. An object's property is modified on one domain controller while the container holding the object is deleted on another domain controller.

    We'll take a detailed look at how Active Directory deals with each of these situations. First, though, we need to see what happens to deleted objects.

    Deleted Object Handling

    Objects deleted from Active Directory are not immediately removed from the database. This is because the system relies on replication to inform replication partners of changes, and it cannot very well replicate the absence of an object.

    Instead, a deleted object is treated like a disgraced officer. It is stripped of most of its attributes and moved to a hidden container called Deleted Objects. The object cannot be "undeleted."

    Following the object deletion, the domain controller notifies its replication partners. The partners pull a replication packet with an update that, essentially, changes the distinguished name of the object to move it to the Deleted Objects container. The replication partners perform this object move and strip the attributes.

    The Deleted Objects container is not revealed in the Active Directory management consoles. Nor does it appear in the ADSI Edit tool. See the sidebar, "Viewing Deleted Objects," for a way to browse the deleted objects in a given naming context.

    Viewing Deleted Objects

    Microsoft deliberately obfuscates the Deleted Objects container because there is really nothing to be gained by viewing its contents. During an incident analysis, you may want to make certain that an object was deleted and when it the deletion occurred. The tool to use for viewing the Deleted Objects container is the LDAP Browser, Ldp.exe, from the Support Tools:

    1. Bind to the domain.

    2. From the menu, select BROWSE | SEARCH. This opens a Search window.

    3. In the Base DN field, enter the following information (substituting your own domain name). The angle braces are important:

      <WKGUID=18E2EA80684F11D2B9AA00C04F79F805,DC=domain,DC=root>
      
    4. Click Options then Controls. This opens a Controls window.

    5. In the Object Identifier field, enter the following value:

      1.2.840.113556.1.4.417
      
    6. Clear the check for Value.

    7. Set Control Type to Server.

    8. Clear the check for Critical.

    9. Select the Check In >> option.

    10. Click OK to save the change and close the window.

    11. Under Search Call Type, select Extended.

    12. Clear the check for Attributes Only.

    13. Clear the check for Chase Referrals.

    14. Select the Display Results option.

    15. Click OK to save the changes and close the window.

    16. Under Scope, select the Subtree option.

    17. Click Run. The results of the search displays in the right pane. These are the objects in the Deleted Objects container.

    Garbage Collection

    Objects in the Deleted Objects container are called tombstones. Tombstones remain in the Deleted Objects container for 60 days. This is often called the tombstone interval.

    When the tombstone interval expires for a given object, the object is eligible for complete removal from the database. The removal is performed by the garbage collection process. Garbage collection runs every 12 hours. When garbage collection runs, it removes any expired tombstones then packs the database and re-indexes. Without doing this periodically, performance would degrade.

    Garbage collection compacts the database but leaves the physical size of the Ntds.dit file the same. The only way to recover physical disk space is to run offline defragmentation.

    A 60-day tombstone interval may seem like a long time, but it is long for a purpose. It is essential that the presence of deleted objects not cause database corruption following a tape restore of Active Directory.

    Consider what would happen if the tombstone interval were 1 day instead of 60. Let's say a domain controller fails. You are unable to find a viable tape newer than three days oldЧnot an uncommon occurrence. You decide to use the tape because you know that the domain controller will update the older Active Directory copy by pulling changes from its replication partners.

    Unfortunately, the tape is older than our hypothetical 1-day tombstone interval. This means that objects deleted since the tape backup may have been expunged from the directory database on other domain controllers. When you restore from the older tape, the objects would be in their original containers and there would be no information to the contrary in the databases of the replication partners. This would leave the objects in their original locations, corrupting the directory because it would now be different than its peers.

    The 60-day interval gives you lots of leeway in doing a tape restore; but always keep in mind that any copy of Active Directory, whether it comes from tape or a disk image or wherever, becomes useless 61 days after it was obtained.

    Armed with this information about deleted object handling, we can proceed to see how Active Directory handles replication collisions.

    Simultaneous Modification

    Consider this situation. The Chief Executive Officer wants her title to appear when people search "that Active Directory thing that you folks installed:"

    • The CEO calls the Help Desk. The technician handling the call is happy to help and changes the Title attribute of the CEO's user object to "CEO."

    • A system administrator gets a call from the CEO's Administrative Assistant asking for a favor. "Please change the boss' title, would you?" The administrator obliges by changing the Title attribute of the CEO's user object to "Chief Executive Officer."

    The Help Desk technician and the system administrator are logged on to different domain controllers. They make their changes during the same replication interval. This means that the modified attributes have the same PVN but contain different information.

    Offline Defragmentation

    There is no advantage to offline defragmentation other than reducing the physical size of the Ntds.dit file. You should size your storage to handle the largest possible size of Ntds.dit and its support files, so there is really no need to ever run offline defragmentation.

    Within the next 15 seconds, the changes begin to circulate around to the other domain controllers. Because the updates have the same PVN, the other domain controllers must decide which one to retain.

    They start by using the timestamp applied by the originating domain controller as a tiebreaker. If one update were saved a few seconds after the other, it would be retained.

    If the updates were saved at exactly the same time, the domain controllers apply an ultimate tiebreaker: a comparison of the GUID of the originating domain controller. The highest GUID wins. Sure, it's arbitrary, but at least it's consistentЧsomething like parental discipline.

    Identical Distinguished Names

    Here's another situation. A new user joins the company. Your internal procedures require that an HR representative with special directory permissions create the user object in Active Directory and set the correct parameters. This particular user is a VIP, though, and someone expedites the process by calling an Operations administrator directly.

    The HR representative and the Operations administrator both create a user object with the same name in the same container during the same replication interval. Objects cannot have the same distinguished names in Active Directory. When the new objects begin to replicate around the network, the other domain controllers are faced with a decision. Which object should be retained and which should be discarded?

    There's a possibility that information about a user could be lost if one object simply overwrites another, so both objects must be retained. One object is renamed to give it a different distinguished name. Each domain controller must rename the same object the same way so that the directory replicas remain consistent.

    The tiebreaker once again is timestamp followed by GUID. If the objects were created at different times, the domain controllers retain the name on the object with the later timestamp. The object with the earlier timestamp is renamed. If the timestamps match, the object created on the server with the higher GUID retains its name.

    The losing object gets a new name using this process:

    • Keep the original name as a prefix

    • Append a reserved character, an asterisk (*)

    • Append the GUID of the originating domain controller

    The resultant name would look like this:

    cn=Jane Jones*2FAC1234-31F8-11B4-A222-08002B34C003
    

    The only warning you get about this action is an entry in the Event log. When you discover the problem, you must examine both objects to decide which one to keep and which to delete.

    Notification of Collision Results

    When Active Directory errors occur, such as a replication collision, the system logs a warning in the Event log and goes on about its business. You may want to install a utility that sends you an email or a page when critical errors or warnings occur.

    An example of such a utility is LogCaster from RippleTech, Inc., at www.rippletech.com. This utility can be configured to look for specific events and send SNMP traps, pages, cell phone messages, and emails.

    A similar product called Event Log Monitor can be evaluated and purchased at Sunbelt Software at www.sunbeltsoftware.com.

    Moved Objects

    Here's another situation that can cause a collision. You make a change to an object's property while, at the same time, another administrator on another domain controller moves the object to a different container. When the property update arrives at the domain controller where the object was moved, the directory engine has a dilemma. The distinguished name of the object has changed, but the DN associated with the property for that object has not.

    Active Directory resolves this problem easily because the GUID of the object does not change when the DN changes. The directory just does a lookup for the object GUID, finds the new DN, and updates the property in the correct location.

    Deleted Objects

    The next collision situation could occur in this fashion. A Facilities staffer makes a change to the Telephone attribute for a user. At same time, the user's manager fires the user and insists that a network administrator delete the user's object. (In a true production environment, you would disable a user account for a period of time rather than delete it. You don't want to lose the user's Security Identifier (SID) until you're sure the user will never return.)

    Recall that when an object is deleted, the object is moved to the Deleted Objects container. It is also stripped of all but a few properties. If an update for one of those stripped properties arrives after the object has been deleted, the system ignores the update.

    Deleted Containers

    This collision scenario involves deleting an entire container on one domain controller while an object has been moved to the container on another domain controller.

    For instance, let's say that a friend of yours, Andy, calls you up to say that he's been promoted to manager of the company's branch office. "Do what you folks do to get me their computer stuff in the branch office, okay?" he says to you. What he wants is to be put in the Branch OU so he can get their desktop configuration and group policies. You're happy to do it and you move the object.

    At the same time, the CEO walks into another administrator's office and says, "We're destaffing the branch office. Do whatever you computer people do to remove their network access. They won't be back." The administrator obliges the CEO by deleting the entire Branch OU.

    An object move changes several properties of an object, including the object's distinguished name. If the updates to Andy's object arrive at a domain controller after the Branch OU has been deleted, Active Directory has a problem. Ordinarily, the system would move Andy's object to the target OU in its new location, but in this case that is the Deleted Objects container and the system doesn't know if you really wanted to delete the object. So instead, it moves the object to a hidden container called Lost & Found.

    Unlike the Deleted Objects container, Lost & Found can be viewed from the AD Users and Computers console by enabling the Advanced view options. The user object remains enabled so the user can still log on. You may be unaware that there's a problem unless the user complains that the desktop doesn't show the expected result from inheriting group policies.

    You can move an object out of the Lost & Found container to another container. You can also decide to delete it.

    Windows Time Service

    Proper time synchronization is critical for railroads, airports, blind dates, and Active Directory domains. Proper collision management requires consistent timestamps, so it's important that domain controller clocks stay in sync with each other. Also, the Kerberos authentication system uses timestamps to ensure that bad guys don't hijack authentication tickets and replay them at a later time.

    The service responsible for time synchronization is the Windows Time Service, or WTS. The actual service name for WTS is Win32Time, part of the Services.exe suite.

    WTS uses a standard implementation of the Simple Network Time Protocol (SNTP) as promulgated in RFC 2030, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI." Every Windows 2000 and Windows Server 2003 domain controller is an SNTP time server.

    SNTP uses a hierarchical approach to distributing time updates. The PDC Emulator acts as the time standard for a domain. (See Chapter 8, "Designing Windows Server 2003 Domains," for a description of Flexible Single Master Operators such as the PDC Emulator.) In a forest, the PDC Emulators in each domain sync their clocks with the PDC Emulator in the root domain. The root domain is the first domain created in the forest.

    Registry Tip: Windows Time Service

    The Registry settings for the Windows Time Service are stored as follows:

    
    Key:         HKLM | SYSTEM | CurrentControlSet | Services | 
    graphics/ccc.gifW32TIME | Parameters
    Value/Data:  LocalNTP / 0
    Value/Data:  Period / SpecialSkew
    Value/Data:  Type / NT5DS
    

    You can enable logging for the W32TIME, which is a big help when trying to diagnose time synchronization problems:

    
    Key:    HKLM | System | CurrentControlSet | Services | W32Time | 
    graphics/ccc.gifConfig
    Value:  FileLogName
    Data:   <path and name of log file>
    Value:  FileLogEntries
    Data:   0-109 (enter this as shown)
    

    Stop and restart the service to initialize the file and start logging. Remove the entries to stop logging.

    NET TIME and WIN32TM

    Windows Server 2003 has two command-line tools for managing WTS: NET TIME and W32TM. Of the two, W32TM has more options for setting and viewing SNTP parameters.

    For example, if you want to know the time source for a particular client, type

    w32tm -source -v
    

    This prints out a verbose listing that shows how WTS on the server discovered its time sources and what sources it discovered. By default, modern Windows clients use a domain controller for a time standard.

    You can also use net time /querysntp to show the time source for a client, but this will show time.windows.net, a time server on the Internet maintained by Microsoft. Member computers ignore this SNTP time source entry in favor of their logon server. Domain controllers ignore this SNTP time source entry in favor of the PDC Emulator in their domain. The PDC Emulators in each domain look to the PDC Emulator in the root domain.

    If you want to synchronize the PDC Emulator in the root domain with a time standard, you can type:

    net time /setsntp:<time_standard>
    

    The most commonly used time servers in the U.S. are maintained by the National Institute of Standards and Technology (NIST). Go to www.boulder.nist.gov/timefreq/service/time-servers.shtml for a list of the servers and their IP addresses. You'll need to open UDP port 123 through your firewall to use SNTP.

    You can use this same procedure if you have a standalone server or desktop at home that you want to keep synchronized with an Internet time standard. If you want to resynchronize a client, type

    w32tm -once
    

    This does a one-time resync to the NTP time standard for the client. You can also type

    net time /domain:<domain_name> /set
    

    Both of these options require you to have Change Local Time permission at the client. You can verify that you have this permission using the WHOAMI utility from the Resource Kit. Enter whoami /all to see your permissions and the groups you belong to by name and SID. Ordinary users are not granted permissions to change the local system time.

    If you have laptop users who experience time synchronization problems because they are off the network for long periods of time, you can give them permission to change the local time with a group policy. The policy is located in Computer Configuration | Windows Settings | Local Policies | User Rights Assignments | Change The System Time. Create a security group for your laptop users and add that group to the policy.

    You should not manually set the time on a domain controller. If you do, it puts incorrect timestamps on the updates it makes to Active Directory properties until it syncs again with the PDC Emulator. This can cause integrity problems when the objects are replicated. Always change time by synchronizing the domain controller with the time standard server. The easiest way to do this is by using the NET TIME command as follows:

    net time \\local_computer_name /set
    

    The NET TIME command cannot be used to connect to a non-Windows server because it uses SMB (Server Message Block) to handle the transaction. If you want to set a server to an outside time source, use the following syntax (the example shows the time standard server from the National Institute of Standards and Technology):

    net time /setsntp:nist1.datum.com
    

    The net time /setsntp option updates the Registry with the names or IP addresses of SNTP time servers. The target time server is checked when the server boots. If you use net time or net time /set, the /setsntp switch has no effect.

      Previous Section Next Section