Category: Active Directory


Aging and Scavenging Parameters for Zones

list of the zone parameters that affect when records are scavenged. You configure these properties on the zone.

Zone Parameter Description Configuration Tool Notes
No-refresh interval Time during which the server does not accept refreshes for the record. (The server still accepts updates.) This value is the interval between the last time a record was refreshed and the earliest moment it can be refreshed again. DNS console and Dnscmd.exe When an Active Directory–integrated zone is created, this parameter is set to the DNS server parameter Default no-refresh interval . This parameter replicates through Active Directory replication.
Refresh interval The refresh interval comes after the no-refresh interval. At the beginning of the refresh interval, the server begins accepting refreshes. After the refresh interval expires, the DNS server can scavenge records that have not been refreshed during or after the refresh interval. DNS console and Dnscmd.exe When an Active Directory–integrated zone is created, this parameter is set to the DNS server parameter Default refresh interval . This parameter is replicated by Active Directory.
Enable Scavenging This flag indicates whether aging and scavenging is enabled for the records in the zone. DNS console and Dnscmd.exe When an Active Directory–integrated zone is created, this parameter is set to the DNS server parameter Default enable scavenging . This parameter is replicated by Active Directory.
ScavengingServers This parameter determines which servers can scavenge records in this zone. Only Dnscmd.exe This parameter is replicated by Active Directory.
Start scavenging This parameter determines when a server can start scavenging of this zone. Not configurable This parameter is not replicated by Active Directory.

list of the server parameters that affect when records are scavenged. You set these parameters on the server.

Aging and Scavenging Parameters for Servers

Server Parameter Description Configuration Tool Notes
Default no-refresh interval This value specifies the no-refresh interval that is used by default for the Active Directory–integrated zone. DNS console (shown as No-refresh interval ) and Dnscmd.exe By default, this is 7 days.
Default refresh interval This value specifies the refresh interval that is used by default for the Active Directory–integrated zone. DNS console (shown as Refresh interval ) and Dnscmd.exe By default, this is 7 days.
Default Enable Scavenging This value specifies the Enable Scavenging parameter that is used by default for the Active Directory–integrated zone. DNS console (shown as Enable scavenging )and Dnscmd.exe By default, scavenging is disabled.
Enable scavenging This flag specifies whether the DNS server can perform scavenging of stale records. If scavenging is enabled on a server, it automatically repeats scavenging as often as specified in the Scavenging Period parameter. DNS console, Advanced View (shown as Enable automatic scavenging of stale records ) and Dnscmd.exe By default, scavenging is disabled.
Scavenging Period This period specifies how often a DNS server enabled for scavenging can remove stale records. DNS console, Advanced View (shown as Scavenging Period ) and Dnscmd.exe By default, this is 7 days.

 

 

 

Advertisements

Hello All, hope you guys are doing great. Today, I wanted to write about the Change notification in site link.

what is Change Notification?

Change Notification is the interval between an originating update on a domain controller and notification of this change to its partners. When this interval elapses, the domain controller initiates a notification to each intra-site replication partner that it has changes that need to be propagated. Another configurable parameter determines the number of seconds to pause between notifications to other partners if any. This parameter prevents simultaneous replies by the replication partners.

There are two values for the interval – one for the first partner, and other for the subsequent partners. When a change is made on a Domain Controller’s Active Directory database, before the change is replicated, the DC waits for a specific period of time before sending the Change Notification to its first partner, and then waits for another period of time before sending the Change Notification to another partner, this process continues until all partners are notified.

For intra-site replication partners, a DC waits 15 seconds (300 in W2K) before notifying its first replication partner and then another 3 seconds (30 in W2K) before sending this change notification to subsequent partners. These intervals can be modified by the below DWORD values in the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Replicator notify pause after modify (secs)

&

Replicator notify pause between DSAs (secs)

These DWORD values control how long to wait before sending the Change Notification after a modify operation on a Domain Controller to its first partner and then all subsequent partners in the same site. But what about my Domain Controllers in other sites?. We know that replication honors Replication Intervals set on the Site Link between two sites and the minimum interval that can be set via the AD Sites and Services snap in is 15 minutes. What if your environment can afford to enable these change notifications between your sites or specific sites because you have a large amount of bandwidth. For this you can enable Change Notifications between sites as well.

To do this:

    • Open ADSIEdit.msc.
    • In ADSI Edit, expand the Configuration container.
  • Expand Sites, navigate to the Inter-Site Transports container, and select CN=IP.       Note: You cannot enable change notification for SMTP links.
  • Right-click the site link object for the sites where you want to enable change notification, e.g CN=DEFAULTSITELINK, click Properties.
  • In the Attribute Editor tab, double click on options.b.      If the Value(s) box contains a value, you must  derive the new value by using a Boolean BITWISE-OR calculation on the old value, as follows: old_value BITWISE-OR 1. For example, if the value in the Value(s) box is 2, calculate 0010 OR 0001 to equal 0011. Type the integer value of the result in the Edit Attribute box; for this example, the value is 3.
  • a.       If the Value(s) box shows <not set>, type 1
  • 6.       Click OK. or VBScript to Enable Change Notification for Site Links @ http://gallery.technet.microsoft.com/scriptcenter/390b54d2-cd49-4f46-92e0-c22ff6f25f1c  The value of Options attribute that we modified above, if the value is 1, then Change Notification is enabled with compression; and if you change the value to 5, then Change Notification is enabled without compression
  • But what about compression? Replication within a site for AD is not compressed, while in remote sites, replication data is always compressed to take advantage of the low speed links and intervals set between them. So if you are one of those environments that are enjoying the fruits of enabling Change Notification between sites and would like to replicate data uncompressed vs. compressed, then here is another tip.
  • What about disadvantage? Is there one? Well sure, it’s a possible and potential replication storm as all the domain controllers are part of the Change Notification intervals.
  • With Change Notification enabled between sites, changes propagate to the remote site with the same frequency that they are propagated within a site. The advantage of enabling Change Notification between sites is little to no conflicts. As a matter of fact, I have yet to see a Conflict object (will discuss some other time) between DCs in different sites if Change Notification is enabled between those sites. Plus if there are a lot of changes being made, these changes will not be queued up as they will be replicated with the same frequency as the domain controllers in the DC’s own site.
  • See PowerShell Script to Enable Change Notification @ http://gallery.technet.microsoft.com/scriptcenter/61cb88bb-8c61-477f-834e-79ed0c153669

Had you asked me what Active Directory was before I went to the Masters class, I probably would have just answered, “An LDAP-enabled database with many dependent LDAP-enabled applications and services sitting on top of it including Kerberos, Authentication, DNS, etc.” Now, having gone through the Master class, my answer would change to “A distributed Jet/ESE database that’s exposed through LDAP by the Directory System Agent (DSA) with many dependent LDAP-enabled applications and services sitting on top of it including Kerberos, Authentication, DNS, etc.”

Now, that I just explained what AD is at its lowest level, a Jet database, why in the world would Microsoft choose Jet over say, a SQL database? SQL is so very well known, easy to access and manipulate; it almost sounds like a match made in heaven.  Jet was chosen because it’s a ridiculously simple and fast database. If Active Directory was going to be the center of many enterprises, it had to be fast and Jet delivers on that promise in spades.

 p1

 I like to describe the Directory System Agent (DSA) as the man behind the curtain, the bouncer, and the translator. It’s the component that talks to the database but also enables LDAP. Sorry to break it to you, but at the database level, distinguished names like ‘CN=users,DC=Contoso,DC=local’ don’t exist. It’s the DSA that creates this LDAP path based on the data in the underlying Jet database; this will make more sense in the next section. It also enforces data integrity, which data types are allowed for certain attributes. It really is the magic that creates this awesome LDAP database we call Active Directory. Jet makes it fast, the DSA makes it LDAP.

Now, within the ntds.dit file, there are actually many tables of data. The tables that are of most interest to us are the data table, which contains all the users, groups, OU’s. The link table, which contains any linked attributes for example, the members of a group. And lastly the SD table, which contains security descriptors or permissions that are assigned throughout Active Directory.

 p2

Structure of NTDS.dit

 Let’s first take a look at data table. One easy way to do this without some fancy third party tools is to run LDP.exe and leverage an operational attribute called ‘DumpDatabase’. Do note that this forest is called contoso.local with a child domain named child.contoso.local.

Start Ldp.exe on the domain controller.

  1. Connect locally, and then bind as an Domain Admin.
  2. Click Modify on the Browse menu.
  3. Edit for Attribute: dumpdatabase.
  4. Edit for Values: name ncname objectclass objectguid instancetype. You must leave one space between the attributes.
  5. Click Enter. The Entry List box contains the following entry:[Add]dumpdatabase:name ncname objectclass objectguid instancetype
  6. Click the Extended and Run options.
  7. The %systemroot%\NTDS\Ntds.dmp file is created, or you receive an error message in Ldp.exe that you must investigate.

Source: http://support.microsoft.com/kb/315098

 Data Table

The file created, ntds.dmp, is a text file that can be opened in notepad although the file size will depend on how big your Active Directory database is and we all know that notepad doesn’t like huge files. 🙂 Nonetheless, once you open it in notepad, what you’re looking at is the data table from Active Directory and it should look something like this:

Disclaimer: I excluded some columns from this picture that wouldn’t fit nor was relevant to this blog.

 p3

Here is a key for some of the above terms:

DNT: Distinguished Name Tag. Essentially is a primary key to identify each row within the database.

PDNT: Parent Distinguished Name Tag. Indicates which object in the database is the parent object of this object. References another objects DNT.

NCDNT: Naming Context Distinguished Name Tag. Indicates which “partition” this object belongs to. References the root of a partition’s DNT.

The first thing you’ll notice is that all the partitions in Active Directory are represented in this one data table. This is why we call them logical partitions. So, how does Active Directory keep track of the different
partitions and which objects belong to which partitions? This is where the DNT, PDNT, NCDNT values you see above come into play. The PDNT value tells each object what their parent object is plus the NCDNT value tells the object which partition it belongs to.

 p4

In the above diagram, you’ll notice that the DNT is just like a unique identifier where each row as a different value. The PDNT on each object tells us which object within the data table is its parent object. Additionally, you’ll notice the NCDNT on the Dave user account tells us that he belongs in the contoso.local domain partition. You’ll notice that the users container also has a NCDNT of 1788. This just indicates that the users container also belongs to the contoso.local domain partition. NCDNT tells us which partition each object belongs to.

The DSA then uses this information to map out the hierarchy of all objects and their partitions and delivers them in LDAP syntax. When I realized that almost all data and partitions in Active Directory are in this one data table and just organized by these hierarchal numbers, it forever changed my understanding of Active Directory. You’ll fully understand what I mean in a little bit.

Now, let’s also take a look at a GC at this low level. The official definition of a GC is that it contains a partial attribute set of every object in the Active Directory forest. While that is true, once again, all of this is stored in the one data table in Active Directory and organized by DNT’s, PDNT’s and NCDNT’s:

 p5

The diagram above is a dump from a forest-root GC. Once again, you’ll notice the PDNT references the parent object. The NCDNT references what partition this object belongs to. And the PDNT on the child object, which is the root of the child domain, points to the DNT of contoso.local. We know this is a GC because these objects here at the bottom are from the child domain, which only a GC would have.

Key Takeaway: Active Directory does not have different tables to store the different partitions including the GC partition. Everything is stored in the one data table which is logically and hierarchy organized.

Now that I knew and understood Active Directory in this way, my mind started to open up and understand things that I couldn’t fully comprehend before.

 Link Table & Linked Values

Linked values are a way of telling Active Directory that two attributes are related to one another. For example, on groups, we have an attribute called member that contains all the users that belong to that group. On each user account, we have an attribute called memberof that will show you all the groups that that user belongs to. Consequently, the member and memberof attributes are linked values that tell Active Directory they are related. Earlier, I mentioned the link table in the Active Directory database. It contains all the information about these linked values and in this case, who’s a member of these groups. Do remember that the link table may also contain information about other linked values as well, like the attributes ‘DirectReports’ and ‘ManagedBy’. Here is an example of the Dave user account belonging to the administrators group in contoso.local:

 p6

So when you go to the properties of the administrators group to see who is a member, the database would take the administrators DNT of 3566, search the link table for all matching link_DNT values, and then return backlink_DNT values, which would correspond to a user or group within the DB that are members of that group.

In the reverse, when I go to the properties of the Dave account to see what groups he belong to, the database takes my DNT of 3830 and searches the link table for all matching backlink_DNT values, and then returns the link_DNT values, which would correspond to groups within the DB that I belong to.

Key Takeaway: Anything that is linked, like member and memberof attributes, must reference a physical object in the database. This is for purposes of referential integrity and it must have a corresponding DNT value, which means it will have its own row in the database. Contrast this with any generic multi-valued attribute within AD. If it isn’t linked, you can go ahead and add any value you want to it.

With that being said, let’s say that I log onto the child domain (child.contoso.local) and want to make the user account Dave, from the forest root, an administrator in the child domain. Now remember that this child DC is NOT a GC so he wouldn’t have a copy of the Dave user account in his data table. Also, remember that when you add someone to a group, they MUST physically exist in the local data table in Active Directory.

Does that mean that I have to make this child DC a GC so Dave would exist in the data table so we could then then add him to the administrators group?

 Phantom Objects

No, what actually happens under the hood is the DC creates what’s called a phantom object in the data table that references the Dave account in the forest root. This phantom object is now a real object with its own DNT and exists in the data table in the child domain on all non-GC’s. Now, he can properly be added to the administrators group. Let’s take a look at this under the hood from the child DC that is not a GC:

 p7

 The first clue that this is a phantom object is because OBJ=False. But if we compare this phantom object to the actual user account in the forest-root domain, it looks like this:

  p8

Since this child DC isn’t a GC and didn’t have a copy of forest-root Dave account but had to still add Dave to the administrators group, it has to create a representation of Dave in its local database because the rules of linking state that the object must exist in the local data table and have a valid DNT.

Key Takeaway: Remember that GC’s don’t have nor need phantom objects because they have a row in their data table for every object in the forest so phantoms objects aren’t necessary. Non-GC’s only have the objects from their local domain so they have to create phantom objects to represent accounts from other domains.

 Now, let’s take a look at the link table on this DC in the child domain from adding the Dave account in the forest root to the administrators group in the child domain:

  p9

Tying It all Together

Now, why does any of this matter? Well, do you remember that recommendation that Microsoft made a long time ago about not putting the Infrastructure Master on a Global Catalog server? Everything I explained above is why. Let’s step through it one more time to make it clear. Before we do, let’s summarize some absolutes about Active Directory:

    1. Every domain controller is personally responsible for maintaining their own data table and how that data is internally linked. Internally, the DB on each DC may not be identical but the outcome will be the same.
    2. On each DC, to add a user to a group, that user must physically be present in the local data table either as a user account or a phantom object.
    3. A Global Catalog Server has a partial copy of every object in the forest in its data table. Objects from other domains don’t have all their attributes populated but nonetheless are present. Because of this, it doesn’t need phantom objects because it has the real objects locally.
    4. A Domain Controller that isn’t a GC doesn’t have a copy of every object in the forest in its data table. It only contains objects from its own domain. Because of this, it has to create phantom objects to reference the real objects from other domains.
    5. The infrastructure master is responsible for updating or deleting phantom objects if/when they change. For example, does the actual Dave account in the forest root still exist? Has he been moved or renamed? This process runs every 2 days and asks this question and then either updates or deletes the phantom objects accordingly.

 One day, the forest-root Dave account gets deleted. The infrastructure Master role is running in the child domain on a global catalog server. Let’s go through it step-by-step:

Disclaimer: AD replication occurs at a much higher level than this and does not occur based on DNT values. I am just doing it this way to put it into the context of this blog. Plus, DNT’s are local to each DC.

 1.) The Dave account in the forest-root domain contoso.local gets deleted.

p91

 2.) The DC in contoso.local replicates that deletion to the child domain GC by telling it to delete DNT 3830.

p92

 3.) The non-GC’s in the child domain don’t have the Dave account with a DNT of 3830. Instead, they have a phantom object that represents Dave with a DNT of 5585. Consequently, the Dave phantom object does not get deleted.

p93

  4.) This is where the Infrastructure Master comes in. There is one IM per domain. The IM process in this child domain runs every two days and says, “Let me review my phantom objects to make sure that the actual user accounts still exist”. Under normal conditions, it would determine that the actual Dave account got deleted and would then delete the Dave phantom object from itself and then replicate that to other DC’s in the child domain that aren’t GC’s. The problem here is though, the Infrastructure Master is running on a GC and we all know by now that GC’s doesn’t have any phantom objects. Consequently, the IM determines, “since I don’t have any phantom objects, there’s really nothing for me to do”. Therefore, the phantom object for the Dave account remains on all non-GC’s in the child domain. If you were to look at the administrators group on any of these non-GC’s in the child domain, Dave would still show as present even though the actual user account was deleted from the forest-root and replicated to all global catalog servers in the child.

Technically, the best practice should have been “Only put the Infrastructure Master on DC’s that have phantom objects” but this would have caused more confusion so Microsoft simplified it and just made it “Don’t put the Infrastructure Master on a GC”.

 Why, Oh Why?

I know you’re probably thinking all of this is a convoluted way of adding users from one domain to groups in another domain, right? Well, what are all of the possible options? Let’s think about this:

  1. Allow a DC to add a user to a group even though the user account doesn’t exist in the local data table. This would break the database and referential integrity. Definitely not a good option.
  2. Don’t allow our customers to add users from one domain into groups from another domain. Once again, not a good option.
  3. Recommend that all domain controllers be global catalog servers, which negates the entire phantom object scenario. Wait a minute, we already recommend that!
  4. Create Phantom Objects on non-GC’s in other domains and then allow the Infrastructure Master to keep those phantom objects update to date, which is exactly what we’re doing today.

The Windows 7 Boot Process (sbsl):

http://social.technet.microsoft.com/wiki/contents/articles/11341.the-windows-7-boot-process-sbsl.aspx

Active Directory Domain Services (AD DS) Overview: http://social.technet.microsoft.com/wiki/contents/articles/699.active-directory-domain-services-ad-ds-overview.aspx

Troubleshooting: Multiple members are referencing the same computer object, DFS-R Console: http://social.technet.microsoft.com/wiki/contents/articles/13092.troubleshooting-multiple-members-are-referencing-the-same-computer-object-dfs-r-console.aspx

Active Directory Domain Services (AD DS) Troubleshooting Survival Guide and Content Map: http://social.technet.microsoft.com/wiki/contents/articles/2285.active-directory-domain-services-ad-ds-troubleshooting-survival-guide-and-content-map.aspx

How AD RMS Works:                                                                               http://social.technet.microsoft.com/wiki/contents/articles/435.how-ad-rms-works.aspx

Active Directory Services Overview:                                         http://social.technet.microsoft.com/wiki/contents/articles/1026.active-directory-services-overview.aspx

Kerberos Survival Guide:                                                       http://social.technet.microsoft.com/wiki/contents/articles/4209.kerberos-survival-guide.aspx

Wiki: Active Directory Domain Services (AD DS) Portal http://social.technet.microsoft.com/wiki/contents/articles/13752.wiki-active-directory-domain-services-ad-ds-portal.aspx

How Active Directory Replication Works (en-US):                   http://social.technet.microsoft.com/wiki/contents/articles/4592.how-active-directory-replication-works-en-us.aspx

My TechNet WIKI : Biswajit Biswas:                                         http://social.technet.microsoft.com/wiki/contents/articles/14580.my-technet-wiki.aspx

Windows Trust, Migration, AGUDLP & ADMT

http://social.technet.microsoft.com/wiki/contents/articles/15079.windows-trust-migration-agudlp-admt.aspx

Active Directory: SYSVOL Replication Migration Guide: FRS to DFS Replication http://blogs.technet.com/b/schadinio/archive/2010/08/10/active-directory-sysvol-replication-migration-guide-frs-to-dfs-replication.aspx

Active Directory Quotas:

http://blogs.technet.com/b/activedirectoryua/archive/2009/03/18/active-directory-quotas.aspx

A Guide to Active Directory Replication: Must Read 

http://technet.microsoft.com/en-us/magazine/2007.10.replication.aspx

Domain controller demotion & Metadata cleanup   http://social.technet.microsoft.com/wiki/contents/articles/3984.domain-controller-demotion-metadata-cleanup.aspx

Troubleshooting AD Replication error 1818 The remote procedure call was cancelled: http://social.technet.microsoft.com/wiki/contents/articles/11795.troubleshooting-ad-replication-error-1818-the-remote-procedure-call-was-cancelled.aspx

http://blogs.technet.com/b/ashleymcglone/archive/2012/01/03/everything-you-need-to-get-started-with-active-directory.aspx

http://blogs.technet.com/b/ad/archive/2009/01/02/fooling-the-dc-locator.aspx

Lingering Objects

When some object is deleted on a DC it is changed into a tombstone. When an object is transformed into a tombstone ALL almost attributes values, except those mandatory and additionally manually configured, are stripped from the deleted object.

NOTE:

  • The values of the following attributes are preserved during a deletion:
    • objectGUID, objectSid, nTSecurityDescriptor and uSNChanged.
    • Additionally on W2K3 SP1 DCs: sIDHistory
  • Additional attributes can be configured to be preserved by:
    • Using ADSIEDIT.MSC and connecting to the schema partition
    • Configure the “searchFlags” property of the attribute which consists of bits, each with a certain meaning! Don’t just change this without knowing what you are doing!!!
    • Enabling the FOURTH bit on the “searchFlags” property preserves the attribute value in the tombstone of the deleted objects.
      • 1st bit: 2^0=1
      • 2nd bit: 2^1=2
      • 3rd bit: 2^2=4
      • 4th bit: 2^3=8 <——this one!

 

After that the new object form (the tombstone) replicates (at least… it should!) to all DCs/GCs. The lifetime of the tombstone within the directory service depends on the “tombstone lifetime period”, which is a forest-wide configuration. The value for the “tombstone lifetime period” can be seen on:

  • Object: “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<domain>,DC=<tld>”
  • Attribute: “tombstoneLifetime”
  • Value:
    • Fresh install of AD with W2K DCs (all SPs): 60 days
    • Upgrading AD with W2K DCs to W2K3 DCs: 60 days
    • Upgrading AD with W2K DCs to W2K3 SP1 DCs: 60 days
    • Fresh install of AD with W2K3 DCs (all SPs): 60 days
    • Upgrading AD with W2K3 DCs to W2K3 SP1 DCs: 60 days
    • Fresh install of AD with W2K3 SP1 DCs (all SPs): 180 days
    • <not set> means: 60 days

 

A process on each DC called the “Garbage Collection Process” runs each 12 hours and checks, amongst other activities, if tombstones are older than the configured “tombstone lifetime period” they are removed from the directory forever! (nothing to worry as this is a normal process and it should work this ways!) That removal does not replicate to others DCs, but each DC on its own does this check.

 

So now let’s look at HOW lingering objects occur!

Lingering objects occur when a DC/GC is not available (e.g. due to network connectivity issues or DNS issues or it has been shutdown or whatever) for more than the “tombstone lifetime period”.

 

Because of that, that particular DC/GC is not able to replicate at least once within the “tombstone lifetime period” to receive the tombstones. If the unavailable/disconnected DC/GC becomes available again after the “tombstone lifetime period” has passed, inconsistencies (may… but probable will) exist between DCs/GCs, which might cause security related issues, replication issues and even loss of functionality.

Whether or not the lingering objects replicate back to the other DCs/GCs depends on how the two defense mechanisms (for W2K3 and later) against lingering objects are configured. W2K DCs only have one defense mechanism, being option 2.

  1. Replication time between DCs exceeds the “tombstone lifetime period”
  2. Strict and loose replication

 

(1): Replication time between DCs exceeds the “tombstone lifetime period”

When a DC/GC does not replicate at least once within the “tombstone lifetime period” with other DCs/GCs, replication is halted with that DC.

This defense is NOT in place when the following registry name is available and set to a value of 1 (one).

This defense is in place when the following registry name is set to a value of 0 (zero) or is not available:

  • Registry Key: HKLMSystemCurrentContro
    lSetServicesNTDSParameters
  • Registry Name: Allow Replication With Divergent and Corrupt Partner
  • Registry Type: REG_DWORD

 

(2): Strict and loose replication

When strict replication is enabled on a DC/GC the inbound replication of lingering objects is halted and reported (event ID 1988 in the Directory Service event log) for the partition that contains the lingering object. When loose replication is enabled on a DC/GC the inbound replication of lingering objects is NOT halted but it is reported (event ID 1388 in the Directory Service event log). Lingering objects can be detected on DCs by either looking for event ID 1388 or event ID 1988 on DCs/GCs using, amogst others, the EventCombMT tool (Resource Kit).

This defense is NOT in place when the following registry name is NOT available or it is set to a value of 0 (zero).

This defense is in place when the following registry name is available AND set to a value of 1 (one):

  • Registry Key: HKLMSystemCurrentControlSetServicesNTDSParameters
  • Registry Name: Strict Replication Consistency
  • Registry Type: REG_DWORD

 

When STRICT replication is ENABLED:

  • Event ID 1988 is registered in the Directory Service event log of the DC NOT containing the lingering (while replication of the lingering object was prevented), which specifies:
    • The transport-specific network address of the “source DC” (the DC containing the lingering object)
      • Example: ed0c6501-28c1-47e9-b3db-5dcf281e9e31._msdcs.ADCORP.LAN)
    • The “distinguishedName” of the “lingering object”
      • Example: CN=JORGE DE ALMEIDA PINTO,OU=Users,OU=ORG,DC=ADCORP,DC=LAN
    • The “objectGUID”  of the “lingering object”
      • Example: r84ssk2a-92kj-938r-n49a-b3xxc7912423
  • This event ID will only be logged on the DC when an attempt is made to inbound replicate the lingering object from the DC containing the lingering object. That attempt will be triggered when a changed is made on the lingering object on the DC containing the lingering object.

 

When LOOSE replication is ENABLED:

  • Event ID 1388 is registered in the Directory Service event log of the DC which previoudly did NOT contain the lingering (while replication of the lingering object was NOT prevented), which specifies:
    • The transport-specific network address of the “source DC” (the DC containing the lingering object)
      • Example: ed0c6501-28c1-47e9-b3db-5dcf281e9e31._msdcs.ADCORP.LAN)
    • The “distinguishedName” of the “lingering object”
      • Example: CN=JORGE DE ALMEIDA PINTO,OU=Users,OU=ORG,DC=ADCORP,DC=LAN
    • The “objectGUID”  of the “lingering object”
      • Example: r84ssk2a-92kj-938r-n49a-b3xxc7912423
    • The “Directory partition” containing the lingering object(s)
      • Example: DC=ADCORP,DC=LAN
    • The “Destination highest property USN” (the highest commited USN on the DC NOT containing the lingering object)
      • Example: USN: 14221
  • This event ID will only be logged on the DC when an attempt is made to inbound replicate the lingering object from the DC containing the lingering object. That attempt will be triggered when a changed is made on the lingering object on the DC containing the lingering object.

To DETECT lingering objects (but not remove):

  • STRICT replication consistency MUST be enabled for the following to work.
  • Will NOT work with LOOSE replication consistency as the data between the “DC with lingering objects” and “DC with correct data” is the same
  • REPADMIN /REMOVELINGERINGOBJECTS <FQDN of DC with lingering objects> <objectGUID of DC with correct data> <DN of partition containing lingering objects> /ADVISORY_MODE
    • Example:
      • repadmin /removelingeringobjects BAD-DC.ADCORP.LAN ed0c6601-28c1-47e9-b3db-5dcf291d9e31 DC=ADCORP,DC=LAN /advisory_mode
  • On the DC/GC containing the lingering objects the event IDs 1938 (starting detection summary), 1946 (for each lingering object detected) and 1942 (final detection summary) are registered in the Directory Service event log.

To DETECT and REMOVE lingering objects:

  • STRICT replication consistency MUST be enabled for the following to work.
  • Will NOT work with LOOSE replication consistency as the data between the “DC with lingering objects” and “DC with correct data” is the same
  • REPADMIN /REMOVELINGERINGOBJECTS <FQDN of DC with lingering objects> <objectGUID of DC with correct data> <DN of partition containing lingering objects>
    • Example:
      • repadmin /removelingeringobjects BAD-DC.ADCORP.LAN ed0c6601-28c1-47e9-b3db-5dcf291d9e31 DC=ADCORP,DC=LAN
  • On the DC containing the lingering objects the event IDs 1937 (starting removal summary), 1945 (for each lingering object detected and removed) and 1939 (final removal summary) are registered in the Directory Service event log.

So if STRICT replication is ENABLED, possible ways to detect lingering objects:

  • REPADMIN /REMOVELINGERINGOBJECTS with the /ADVISORY_MODE option
  • Scan DCs for event ID 1988 which contain information about the lingering objects (e.g. with EVENTCOMBMT)
  • For global catalogs use can ALSO use GCCHK from joeware.net (http://www.joeware.net/win/free/tools/gcchk.htm)

So if LOOSE replication is ENABLED, possible ways to detect lingering objects:

  • Scan DCs for event ID 1388 which contain information about the lingering objects (e.g. with EVENTCOMBMT)

 
MY €0.02:

  • Don’t enable LOOSE replication (because of security issues with re-introduced objects that should have been deleted) as this really does not solve the real problem. It only extends it!
  • Be carefull using a mixture of loose replication and strict replic
    ation as that may lead to inconsistencies and/or security issues
  • Enable STRICT replication (=default on W2KSP4 and W2K3)
  • Detect and cleanup lingering objects if applicable
  • Make sure you MONITOR end-to-end AD and SYSVOL replication between DCs!!!
    • Should be a MUST on your priority list!!!
  • Make sure you MONITOR DC/BH/GC/FSMO availability and detect disconnected DCs ASAP!!!
    • Should be a MUST on your priority list!!!
  • Monitoring is a preventive measure that helps you NOT getting the headaches you may have now concerning lingering objects!

To make things a bit easier for those that experience lingering objects on W2K3 DCs:

I have created some scripts (see the zip file at the end of the post where it says ‘attachments’) that automate this a bit more. Use them as you wish and at your own risk!!! Get there scripts from HERE.

The logic works as follows:

  • For EACH domain in the forest specify in ‘DC-LIST-FQDN-HEALTHY.TXT’ ONE DC that is considered HEALTHY
  • Specify in ‘DC-LIST-FQDN-UNHEALTHY.TXT’ ALL DCs/GCs that are considered UNHEALTHY and may contain lingering objects
  • Execute ‘GET-GUID-NCs-FROM-FQDN.CMD’ to generate:
    • ‘DC-LIST-GUID-FQDN-HEALTHY.TXT’
      • –> contains the GUID and FQDN of the HEALTHY DCs
    • ‘<FQDN UNHEALTHY DC>-NCs.TXT’
      • –> For each unhealthy DC contains ALL writable and read-only NCs (partitions)
  • Execute ‘CLEAN-LINGERING-OBJECTS-ON-UNHEALTHY-DCs.CMD’
    • In detect mode (first argument = DETECT) (argument = case sensitive)
    • In clean mode (first argument = CLEAN) (argument = case sensitive)
    • ‘CLEAN-LINGERING-OBJECTS-ON-UNHEALTHY-DCs_DETECT.TXT’
      • –> contains ALL detected lingering objects
    • ‘CLEAN-LINGERING-OBJECTS-ON-UNHEALTHY-DCs_CLEAN.TXT’
      • –> contains ALL detected AND cleaned lingering objects

Were these scripts useful? Just say: Thanks!

Let me know what you think by leaving comments behind

Enjoy!

### DISCLAIMER ###

  • These scripts are freeware. Use it as you wish at your own risk.
  • I do not warrant these scripts to be fit for any purpose or use
  • I do not guarantee that it will not damage or destroy your system
  • Make sure you test these scripts FIRST in a test environment!
  • If you don’t know how to use the scripts DON’T USE them!

 

More and additional information about lingering objects can be found in the following Microsoft articles:

The following has been copied from the URL below, for those who are interested to know how the “/removelingeringobjects” works.

http://technet2.microsoft.com/WindowsServer/en/Library/1465d773-b763-45ec-b971-c23cdc27400e1033.mspx

 

RemoveLingeringObjects Implementation

When you run repadmin /removelingeringobjects, the tool performs the following steps to compare the directories of the source and destination domain controllers and log (or remove) any found lingering objects:

  1. Check to ensure that the directory partition and the source domain controller are valid.
  2. Verify that the user has the DS-Replication-Manage-Topology extended right on the directory partition container object specified in <NC>. This extended right is required to verify object state between two domain controllers. Members of the Domain Admins group have this right by default.
  3. Ensure that both source and destination use the same objects for comparison by merging the up-to-dateness vectors to filter out any objects that have not replicated from the source to the destination or from the destination to the source. This check rules out a lingering object on the destination if the destination has not received the tombstone from the source, and vice versa. Any such nonreplicated objects are removed from the comparison.
  4. Create the list of object GUIDs for each domain controller to be compared. Examine the metadata of each object and use the merged up-to-dateness vector to determine whether the object should be present on both source and destination.
  5. For each GUID that is in the list for the destination, determine if it is in the list of GUIDs for the source.
  6. If a GUID is not found on the source, the object is identified to be outdated on the destination and is either displayed or deleted on the destination server. If advisory mode has been specified, the GUID is displayed only.

Strict Replication Consistency is a registry value that prevents destination domain controllers (DC) from replicating in lingering objects. Lingering objects are objects that have been deleted on one DC but replication failures prevent a partner DC learning of the deletion. The result is those deleted objects remain “live” on the replication partners. If the replication failure persists for longer than tombstone lifetime but is later corrected, the DC that failed to inbound replicate the deletions will continue to have “live”/lingering objects in its copy of the AD database. When one or more attributes are modified on these “live” objects, that object must replicate outbound. DCs that don’t have Strict Replication Consistency enforced will replicate in these formerly deleted objects, re-animating them.

Note: for the sake of readability, when I say “Windows Server 2003” in the document, I mean Windows Server 2003 or later. Windows Server 2008 and Windows Server 2008 R2 behave the same in this respect.

A Windows Server 2003 server can automatically configure Strict Replication Consistency during the domain controller promotion process certain conditions have to be true. There are some myths and badly worded documents out there that imply Windows Server 2003 DC’s always configure themselves for strict replication , so this blog post aims to set the record straight.

Forests originally created on Windows 2000 Server – but later upgraded to Windows Server 2003 require an additional step to automatically enable strict replication consistency on newly promoted domain controllers. While Windows Server 2003 DCs tend to quarantine themselves if they have not replicated for greater than Tombstone Lifetime, failure to implement this step will leave all newly promoted Windows Server 2003 DCs configured for Loose Replication Consistency; leaving them at risk of re-animating lingering objects from Windows 2000 replica DCs or Windows Server 2003 DCs that have had Allow Replication With Divergent and Corrupt Partner set but have not been cleaned of lingering objects first.

If to the you want new domain controllers added forest to have strict replication consistency automatically enabled, you can import the Operational GUID cited below to the Configuration directory partition using Ldifde.exe. The presence of this object in the Configuration partition causes dcpromo.exe to enable Strict Replication Consistency on any Windows Server 2003 domain controller that is promoted into the forest.

1. Start notepad.exe and copy in the sample LDF text below. Edit both lines containing DC=<domain>,DC=<com> to match your forest root domain.

Example: If your forest root domain were contoso.com the DN would be DC=contoso,DC=com

dn: CN=94fdebc6-8eeb-4640-80de-ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<domain>,DC=<com>
changetype: add
objectClass: container
showInAdvancedViewOnly: TRUE
name: 94fdebc6-8eeb-4640-80de-ec52b9ca17fa
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=<domain>,DC=<com>

2. Once the DN has been modified correctly save the file as StrictRepl.ldf.

3. Open a command prompt with Enterprise Administrator credentials and issue this command:

      Ldifde.exe -i -f StrictRepl.ldf

It’s important to note that just adding this object to the CN=Operations container will not cause existing Windows Server 2003 DCs to configure themselves for Strict Replication Consistency. For existing DCs you must add the Strict Replication Consistency registry value and set it to 1 before they will enforce strict replication. The good news is this can be done remotely using repadmin.exe from a command prompt opened with Enterprise Admin credentials. The command to run is:

repadmin.exe /regkey <dcname> +strict

If you want to make certain this is configured on all DCs in the forest you can pass a wildcard to repadmin.exe like this,:

repadmin.exe /regkey * +strict

If you are running this against all DCs in the forest you should pipe this out to a text file and verify all DCs have been contacted and the value has been set correctly.

Warning: Before you implement this change forest-wide it is important to understand that all replication between the source DC and the destination DC will stop for any partition that has a lingering object in it. Replication will only be restored once the lingering object is removed. This could cause forest-wide authentication issues until replication is restored.

For more information about this operational GUID see Technet.

Hopefully this will clear up the common misconception that all Windows Server 2003 domain controllers will always enforce strict replication consistency and will lead to closer examination of current configurations before lingering objects start causing issues.

The process of location is to use DNS to identify a set of candidate domain controllers from a list, based on SRV records.

 When you login what happens in the background is à

1.)    Check for the primary /secondary DNS in your workstation

2.)    Hit the DNS to have the corresponding Srv records of Domain controller(It will happened depends on the subnet/site where you resides on)

3.)    Dns will provide the list of SRV records of the Domain controllers, with that list workstation will try to reach any of the alive domain controller.

DC locator process

The client is initialized with DomainName. FQDN being set to the Domain Name System (DNS) name of the domain to locate, for example server1.test.com

The general process is shown in the following diagram:

The first step is to perform the DNS discovery.
The client issues a DNS request for _ldap._tcp.dc._msdcs.server1.test.com
The DNS server returns a list of SRV records that match this request. If no records are available, then the domain location fails.
If target hosts have the same priority, the client select a return SRV record according to weighted pseudorandom order.

The client then resolves the SRV record to an address, again as specified in the DNS protocols.

Once the address is known, the client sends an LDAP “Ping,” as a way of detecting that the domain. controller is in fact handling requests and determining the characteristics of this domain controller The LDAP “Ping” also known as connectionless LDAP is sent over UDP

After each packet is sent, the client waits for a response, and if no response is received, it sends a packet to the next domain controller. The client continues this process until it receives a valid response that specifies the requested services or has tried all of the domain controllers.

When a client tries to locate a domain controller after it has received the IP address from DNS, it varies the time it waits for a response based on the number of domain controllers it has already pinged. For the first five domain controllers, it waits for 0.4 seconds, and for next five domain controllers, it waits for 0.2 seconds. After 10 domain controllers have been pinged, the client uses a 0.1 second wait for the remaining requests.

The LDAP “Ping” is an LDAP rootDSE search to the domain controller, looking for an attribute called “NetLogon.”

The domain controller server inspects the query and returns the NetLogon result.
The response is typically returned in a NETLOGON_SAM_LOGON_RESPONSE_EX.

Upon receipt of the LDAP SearchResultEntry, the client validates the capabilities returned by the domain controller.

If the capabilities returned by the domain controller are incompatible with the requirements specified by the invoker of the locator algorithm on entry, the client must select another candidate domain controller from the list of domain controller SRV records returned above.

Incompatibility in this case can arise because the client requested a Kerberos KDC, but the domain controller did not indicate that a KDC was present, or the client requested a domain controller that could accept writes, but this domain controller is read-only.

These sorts of negative results are cached by the client. However, they are purged promptly (on the order of minutes).

Because the LDAP “Ping” returns a snapshot of the current state of the domain controller at the moment of the query, services such as a time server, may not be running at the moment, but may be available once the server has completely started.

If all the responses in the SRV records have been checked, and each SRV record points to a server that is either not available or does not match the requirements, then the location operation has failed.

Upon successful response from the domain controller, the location portion completes.

===================================================================================

For additional information,

DC Locator Process in W2K, W2K3(R2) and W2K8

By default a client that knows in what AD site it is in, will ask for a DC in that same site by querying DNS with:

  • _ldap._tcp.<SITE>._sites.dc._msdcs.<DOMAIN>.<TLD>

 snap

By default all DCs in AD site <SITE> will register that DNS SRV record. If no DCs are in that AD Site, the DCs in the nearest AD site will cover that AD site by registering their records in the DC-less AD site. The DCs in the site list are in a random order and provided by the DNS round robin mechanism.

If a client does not know in what site it is in, it will ask for a DC in that same domain by querying DNS with:

  • _ldap._tcp.dc._msdcs. <DOMAIN>.<TLD>

By default all writable DCs in AD domain <DOMAIN> will register that DNS SRV record. The writable DCs in the domain list are in a random order and provided by the DNS round robin mechanism. Read-Only DCs (RODCs) in Windows Server 2008 will not register domain-wide SRV records. RODCs only register SRV records for the AD site they are in.

To determine the AD site of a client:

  • NLTEST /DSGETSITE

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate/service the client:

  • NLTEST /DSGETDC:<FQDN DOMAIN>

So if you look at the situation where a client queries for a DC in the domain because it does not know in what AD site it is in, it can be somewhat interesting when you find out the client is communicating with some DC on the other side of the world. Not really efficient! In HUB and SPOKE environments this can be a problem. It can be really annoying when some client in branch office X is authenticating to a DC in branch office Y, while then WAN links between both branch offices (SPOKES) and the datacenter (HUB) are not that fast. To prevent that situation, it is a best practice to allow the DCs in the datacenters (HUB) register whatever SRV record and allowing the DCs in the branch offices (SPOKES) to register only their site specific SRV records. That way when a client queries for a DC in the domain it will be serviced by one of the DCs in the datacenter (HUB) and NOT in some branch office far far way!

This same situation occurs when a client is joined to the domain using the GUI. At that moment the client does not know its site and it will thus query for A DC in the domain to create its computer account. Guess what, after the clients reboots you might experience authentication problems because the computer account was created at a DC in branch office X while the client is in branch office Y. The issues will go away as soon as the computer account replicates from branch office X to the datacenter and from the datacenter to branch office Y. How long that takes depends on your AD site and replication topology. By using the configuration explained above, the computer account will be created on a DC in the datacenter. That way it only needs to replicate from the datacenter to the branch office. To target the correct AD site where the client will based it is better to use the command-line tool NETDOM. Using that command-line tool you can specify a DC in the AD site where the client will based AND you can specify in what OU the computer account should be placed. The syntax is:

  • NETDOM JOIN %COMPUTERNAME% /DOMAIN:<DOMAIN><DC> /OU:<distinguished name of OU> /USERD:<DOMAIN><USER> /PASSWORDD:<PASSWORD>
  • REMARK: I specify %COMPUTERNAME% instead of the computername because this command needs to be executed locally on the client/server that needs to be joined to a domain

Because DCs by default register all SRV records, you need to configure the branch office NOT to register certain records. W2K DCs do not have a GPO setting to do the configuration, so you need to configure the registry locally. To prevent that you can still create your own ADM file. W2K3 DCs do have a special GPO setting to make the configuration.

To Configure Domain Controllers or global catalogs to Not Register Generic (domain wide) Records

  • For W2K DCs
  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters
  • Registry value name: DnsAvoidRegisterRecords
  • Registry value type: REG_MULTI_SZ
  • Registry value data: <list of ENTER-delimited mnemonics>

For W2K3(R2)/W2K8 DCs and later:

  • GPO setting path: “Computer ConfigurationAdministrative TemplatesSystemNet LogonDC Locator DNS Records”
  • GPO setting: “DC Locator DNS records not registered by the DCs”
  • GPO setting mode: Enabled
  • GPO setting value: <list of SPACE-delimited mnemonics>

List of “mnemonics” that should not be registered by branch office DCs:

  • Dc
  • DcByGuid
  • Gc
  • GcIpAddress
  • GenericGc
  • Kdc
  • Ldap
  • LdapIpAddress
  • Rfc1510Kdc
  • Rfc1510Kpwd
  • Rfc1510UdpKdc
  • Rfc1510UdpKpwd

UPDATE:

If you have configured your branch office DCs to not register domain-wide specific records, the clients will use those DCs and fail over to the datacenter if the local DC becomes unavailable. However if the local DC comes back online the client keeps using the datacenter DC until the client is restarted or the datacenter DCs become unavailable for some reason. Apparently it does not rediscover its local DC is available again. MS-KBQ939252 provides a hotfix and registry configuration for Windows XP (SP1 & SP2) and Windows Server 2003 (SP1 & SP2). The registry configuration is the ability to configure a discovery interval for the locator process.

Make sure you also see MS-KBQ247811, as there it mentions: “After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.”

Looking at this all, the DC locator process as explained above still applies to Windows Vista and to Windows Server 2008 and later. Are there any differences or additions? Yes, there are!

Basically the client either queries for a DC in the AD site it is in or it queries for a DC in the AD domain it is in. I have always asked myself why the DC locator process did not support following the site topology based on the site cost to find the next closest DC for authentication. The answer to that is unknown to me, but both Windows Vista and Windows Server 2008 provide an additional possibility that exists between “a DC in the AD site” (the closest end) and “a DC in the AD domain” (the far end). The new possibility is “a DC in the next closest site”.

Both Windows Vista and Windows Server 2008 still use the default behavior W2K, WXP, W2K3(R2) have. For both Windows Vista and Windows Server 2008 to locate a DC in the next closest site, it needs to be enabled explicitly. That can be done by using the following:

  • For WVT/W2K8 and later:
  • GPO setting path: “Computer ConfigurationAdministrative TemplatesSystemNet LogonDC Locator DNS Records”
  • GPO setting: “Try next closest site”
  • GPO setting mode: Enabled

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate the client:

  • NLTEST /DSGETDC:<FQDN DOMAIN>

To determine a writable DC within a set of DCs in the next closed AD site from the client’s perspective that could authenticate the client:

  • NLTEST /DSGETDC: <FQDN DOMAIN> /WRITABLE /TRY_NEXT_CLOSEST_SITE

Until now I talked about locating a DC for authentication. What I did not talk about yet is locating the SYSVOL to apply GPOs and to use the legacy NETLOGON share. Let’s see how that works.

Each AD domain contains one system domain DFS that allows access to the SYSVOL and NETLOGON share. After a computer or user has been authenticated a referral is requested at the authenticating DC for \<Domain Name><SYSVOL or NETLOGON>. The authenticating DC creates two lists being one list with random referrals IN the same AD site as the computer/user and one list with random referrals OUTside the AD site of the computer/user. As you can see the authenticating DC is not by default (it can be however) also the DC that provides access to the SYSVOL or NETLOGON shares. It can thus be another DC in the same AD site as the computer/user that will provide access to the SYSVOL or NETLOGON shares. To make sure the authenticating DC in the same AD site as the computer/user is at the top of the DFS referrals in-site list an update needs to be installed on the DCs and a registry configuration needs to be made on the same DCs. For more information see MS-KBQ831201.

In addition to installing the update on the DCs the following configuration needs to be made on the DCs to put the authenticating DC on top of the DFS referrals list:

  • Registry key: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDfsParameters
  • Registry value name: PreferLogonDC
  • Registry value type: REG_DWORD
  • Registry value data: 1

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8.

It gets even worse if a computer/user is authenticated outside its AD site because its DC is not available or because it is a DC-less AD site. In that situation it will use ANY DC to gain access to the SYSVOL or NETLOGON shares and in the worst case it will use some DC on the other side of the world with the tiniest WAN link you can imagine. That kinda sucks!

For both W2K and W2K3 a solution exist so that the referral process uses the nearest referral based upon site link costs. To achieve this the following is needed:

  • For W2K SP4 (!) DCs
  • Install update as mentioned in MS-KBQ823362
  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsDriver
  • Registry value name: DfsEnableSmartClient
  • Registry value type: REG_DWORD
  • Registry value data: 1

For W2K3(R2) DCs and later:

  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsParameters
  • Registry value name: SiteCostedReferrals
  • Registry value type: REG_DWORD
  • Registry value data: 1

To determine DFS referral information:

  • DFSUTIL /SPCINFO
  • DFSUTIL /PKTINFO

NOTE: This works on W2K and W2K3 and at this moment I’m not sure if it is still needed for W2K8. If it is the most probably you need to use the W2K3 configuration

Now imagine the client used a DFS referral for the SYSVOL or NETLOGON outside of its AD site because its local DC was not available for some reason. Of course you want the client to fallback to its local DC in the AD site as soon as it becomes available to either access the SYSVOL or NETLOGON share. But will it do that? No! It will use the DFS referral outside its AD site until it is rebooted or its cached is reset. W2K3 SP1 allows a client to fallback to its local DFS referral target as soon as it becomes available again and it needs to access the SYSVOL or NETLOGON share.

On W2K3 SP1 DCs and later:

  • Registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDfsParameters
  • Registry value name: SysvolNetlogonTargetFailback
  • Registry value type: REG_DWORD
  • Registry value data: 1

1.We already have a Windows 2003 DC and we promote another Windows 2008 DC. In this situation, Sysvol will use FRS to replicate the data and not DFSR

2. We are installing a Windows 2008 DC in a new domain/forest. This is the first DC of this forest. But while running dcpromo you select 2003 domain functional level instead of 2008. Even though the DC is running on Windows 2008, since the domain functional level is 2003, SYSVOL will still use FRS to replicate the content instead of DFSR

In the scenario 2, we can although later on change the way SYSVOL will replicate the content. This is where we do Migration of the replicating engine from FRS to DFSR

 3. We are installing a Windows 2008 DC in a new domain/forest. This is the first DC of this forest. But while running dcpromo you select 2008 domain functional level.

In this scenario 3, SYSVOL will use DFSR to replicate the content

 

In the environment where the sites are located in different geographical locations, most of the administrators have confused with time services and how it’s works.

 Let me explain how the Time and Time sync works.

Active directory uses the Kerberos for authenticating users and computers in a domain
I am not going to explain the Kerberos authentication process, just how the Kerberos uses the time for authentication.

When the server receives request for authentication (the ticket), it check for client’s clock time. The server then checks the client’s time to make sure that it falls within the server’s time and the allowable skew and client time should be unique not the same as or earlier than the time of another authenticator

If the client’s time falls within the allowable skew and its timestamp is unique, the server then slightly modifies the contents of the original authenticator and re-encrypts it with the client’s secret key, establishing mutual authentication. The server then acknowledges the client by sending the modified authenticator with the client’s original timestamp back to the client for identification. Client’s clock time should sync with the server (Domain controllers) clock time in order to get successful authentication

Time synchronization in an Active Directory
In Active Directory environment PDC emulator is acting as a time server, PDC emulator is located in the forest root domain and is connected to an external time source. The external time source holds the position of greatest accuracy, or stratum one. The PDC emulator is at stratum two. The forest root domain can also be called the parent domain, and each domain under the parent or forest root can be called a child domain. Any domain controller that accesses time directly from the PDC emulator of the forest root domain is designated as stratum.

 

Understanding the time zone configuration in windows

Difference between time
Before describing the time zone configuration you should know what is time zone and how and why it’s used, relation between time and time zone, and difference between time

Due to time difference between the countries, like time in UK is not the same in US, to differentiate the time between the different parts of the world we use the time zone, I call it difference between time

Computers and servers store time in Coordinated Universal Time (UTC), when viewed through any application (or) viewing system time it’s displayed according to the local time zone of the computer, UTC is equal to GMT

Current system time (UTC) + Time zone (UTC +5.30) = Display time

5 + 5.30 = 10.30

So on the whole,  all the systems are uses UTC time, while displaying the system time it will be converted according to the time zone configuration.

The W32Time service starts automatically on computers that are joined to a domain. For computers that are not joined to a domain, you can start the time service manually. On computers that are joined to a domain, time synchronization takes place when the W32Time service turns on during system startup. The Net Logon service looks for a domain controller that can authenticate and synchronize time with the client. When a domain controller is found, the client sends a request for time and waits for a reply from the domain controller. This communication is an exchange of SNTP packets intended to calculate the time offset and roundtrip delay between the two computers.

Time passed to any client in the domain is unadjusted UTC time, which is adjusted to local time based on the time zone configuration of the workstation. Adjusting the time on the domain controllers will not change the time for the workstations. They have to be updated with the new time zone information as well.

Time zone information will not sync to client from Domain controller, we have to do the time zone change manually, for bulk change we can users the Microsoft hot fix

W32Time uses coordinated universal time (UTC), which is based on an atomic time scale and is the correct term to use when talking about time and time synchronization. UTC is the name for time that is independent of time zone. Time zone information is stored in the computer’s registry and is added to the system time just before it is displayed to the user.

How to change time zone configuration in windows

In Control Panel -> Date/Time -> Time Zone

The process to change the DST is as follows:

Or Use the utility TZEDIT.EXE

Start->Run->TZEDIT.EXE

Then select your time and time zone.

Unknown object in AD

User object has been displayed as unknown object.

“The Active Directory object could not be displayed.”

“Unable to view attribute or value. You may not have permissions to view this object.”

Cause:

Open User account property -> Security permission, -> advanced

In the Access control list.

You can see deny permission for self and everyone.

This might be added automatically or someone. (No Idea)

Resolution:

Open User account property -> Security permission, -> advanced

In the Access control list.

You can see deny permission for self and everyone.

Remove the deny permission from the ACE (self and everyone)

Now the issue will be fixed.