Archive for February, 2013


commands to manage DHCP

Use Netsh to find authorised DHCP Servers

 

netsh dhcp show server

Use DSQuery to find authorised DHCP Servers

 

Dsquery * “cn=NetServices,cn=Services,cn=Configuration, DC=forestRootDomain” -attr dhcpServers

 DHCP server information

 

netsh dhcp server \\DHCP_SERVER show all

 DHCP server dump

 netsh dhcp server \\DHCP_SERVER dump >>FilePath

Adding Single scope through command prompt

 Syntax: 

netsh dhcp server \\servername add scope subnetID subnetmask “ScopeName”

 netsh dhcp Server \\servername Scope subnetID Add iprange IPRangevalue

 netsh dhcp Server \\servername Scope subnetID set optionvalue Optionnumber Datatype “Value”

 Example:

 netsh dhcp server \\indiaw1234 add scope 10.15.254.0 255.255.254.0 “INDIA” “INDIA Site”

 netsh dhcp Server \\indiaw1234 Scope 10.15.254.0 Add iprange 10.200.3.1 10.200.3.99

 netsh dhcp Server \\indiaw1234 Scope 10.15.254.0 set optionvalue 3 IPADDRESS “10.200.3.154”

 netsh dhcp Server \\indiaw1234 Scope 10.15.254.0 set optionvalue 6 IPADDRESS “159.12.83.60”

 netsh dhcp Server \\indiaw1234 Scope 10.15.254.0 set optionvalue 15 STRING “contoso.com”

 DHCP Reservation through Command

 Syntax:

 netsh dhcp Server \\servername Scope subnetID add reservedip <ipaddress> <MAC> <hostname> <description>

 Example:

 Dhcp Server \\indiaw1234 Scope 10.15.254.0 Add reservedip 10.15.254.120 0001e6ac351e “printer1.contoso.com” “printer1”

 Command to delete a Scope:

 Syntax:

 netsh dhcp server \\servername delete scope subnetID DHCPFULLFORCE

 netsh dhcp server \\indiaw1234 delete scope 10.15.254.0 DHCPFULLFORCE

 Command to Set server Option:

 Syntax:

 Netsh dhcp server \\servername set optionvalue optionnumber datatype value

 Example:

 Netsh dhcp server \\indiaw1234 set optionvalue 066 STRING 10.156.100.250

 Netsh dhcp server \\indiaw1235 set optionvalue 067 STRING \boot\x86

 Bulk Scope Creation:

 Syntax:

 For /f “token=number of input attributes delims=,” %%a in (file path) do netsh dhcp server DHCP SERVERNAME addscope Attributes.

 Example:

 for /f “tokens=1,2,3,4,5 delims=,” %%a in (C:\temp\dhcpscope.txt) do netsh dhcp server \\INDIA123 add Scope %%a %%b %%c

 for /f “tokens=1,2,3,4,5 delims=,” %%a in (C:\temp\dhcpscope.txt) do netsh dhcp Server \\INDIA123 Scope %%a Add iprange %%d

 for /f “tokens=1,2,3,4,5 delims=,” %%a in (C:\temp\dhcpscope.txt) do netsh dhcp Server \\INDIA123 Scope %%a set optionvalue 3 IPADDRESS %%e

 for /f “tokens=1,2,3,4,5 delims=,” %%a in (C:\temp\dhcpscope.txt) do netsh dhcp Server \\INDIA123 Scope %%a set optionvalue 6 IPADDRESS “160.200.134.150” “160.200.134.252”

 for /f “tokens=1,2,3,4,5 delims=,” %%a in (C:\temp\dhcpscope.txt) do netsh dhcp Server \\INDIA123 Scope %%a set optionvalue 15 STRING “contoso.com”

 for /f “tokens=1,2,3,4,5 delims=,” %%a in (C:\temp\dhcpscope.txt) do netsh dhcp Server \\INDIA123 Scope %%a set optionvalue 43 BINARY “616C636174656C2E61343430302E30”

 for /f “tokens=1,2,3,4,5 delims=,” %%a in (C:\temp\dhcpscope.txt) do netsh dhcp Server \\INDIA123 Scope %%a set optionvalue 66 STRING “105.41.11.225”

 for /f “tokens=1,2,3,4,5 delims=,” %%a in (C:\temp\dhcpscope.txt) do netsh dhcp Server \\INDIA123 Scope %%a set optionvalue 67 STRING “a44N6”

 for /f “tokens=1,2,3,4,5 delims=,” %%a in (C:\temp\dhcpscope.txt) do netsh dhcp Server \\INDIA123 Scope %%a set optionvalue 46 Byte “2”

 Sample Input:

 103.142.32.0,255.255.255.0,”Scope 1″,103.142.32.1 103.142.32.254,103.142.32.254

103.142.33.0,255.255.255.0,”Scope 2 “,103.142.33.1 103.142.33.254,103.142.33.254

103.142.34.0,255.255.255.0,”Scope 3″,103.142.34.1 103.142.34.254,103.142.34.254

103.142.35.0,255.255.255.0,”Scope 4”,103.142.35.1 103.142.35.254,103.142.35.254

Advertisements

Message -:A DHCP Server Error has occurred. The first event logged is detailed below, however examine System Event Logs for more detail.Event Number of first event recorded: 1014 The following problem occurred with the Jet database -1032: Jet database read or write operations failed. If the computer or database has just been upgraded, then this message can be safely ignored. If this message appears frequently, either there is not enough disk space to complete the operation or the database or backup database may be corrupt. To correct this problem, either free additional space on your hard disk or restore the database. After you restore the database, ensure that conflict detection is enabled in DHCP server properties. For information about restoring the database, see Help and SupportCenter. Additional Debug Information: JetBackup. (EventID = 1014)          (IAM Ref=000-000-002-000-043-000-001)

 Cause: The following problem occurred with the Jet database %1: Jet database read or write operations failed. If the computer or database has just been upgraded, then this message can be safely ignored. If this message appears frequently, either there is not enough disk space to complete the operation, or the database or backup database may be corrupt. To correct this problem, either free additional space on your hard disk, or restore the database. After you restore the database, ensure that conflict detection is enabled in DHCP server properties. For information about restoring the database, see Help and SupportCenter. Additional Debug Information: %2.

 Event ID: Event ID 1014 — DHCP Database Integrity

Event ID 1016 

Explanation: The DHCP service could not access the database to perform the backup

Possible causes include:

  • Another program is accessing the database.
  • The database and its backup directories were moved from the default location

 Resolution:

User Action: To resolve this problem, do one of the of the following:

  • Verify that other programs, such as an antivirus program, are not accessing the database. If such a program is accessing the database, make sure that the program does not scan the directory where the database is stored.
  • Verify that the database and its backup directories are located in the default folder.

Repair database and restore from a known good backup

If the DHCP server database becomes corrupted or is lost, recovery is possible by replacing the server database file (Dhcp.mdb), located in the %SystemRoot%\System32\Dhcp folder, with a backup copy of the same file.

If DHCP Manager was used previously to perform a backup, you can obtain the backup copy of the server database file located in the %SystemRoot%\System32\Dhcp\Backup folder. You can also restore the Dhcp.mdb file from a tape backup or other backup media.

To perform these procedures, you must be a member of the Administrators group, or you must have been delegated the appropriate authority.

To restore a backup copy of the DHCP database:

  1. Click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as Administrator.
  2. Type net stop dhcpserver, and then press ENTER.
  3. Type md c:\olddhcp, and then press ENTER.
  4. Type move %SystemRoot%\system32\DHCP\*.* c:\olddhcp, and then press ENTER.
  5. Type del %SystemRoot%\system32\DHCP\Dhcp.md, and then press ENTER.
  6. Type copy%SystemRoot%\system32\dhcp\backup\jet\new\dhcp.mdb%SystemRoot%\system32\dhcp\dhcp.mdb, and then press ENTER.
  7. Type net start dhcpserver, and then press ENTER.

Verify

Confirm that the server starts successfully and without errors.

Possible causes are listed here pls use any of the below as reference while handling the IM.

 1.Jet database read or write operations failed due to Another program(Symantec AntiVirus) is accessing the database.

 2.Jet database read or write operations failed due to tcpsvcs (4160) An attempt to move the file “C:\WINNT\System32\dhcp\backup\new” to “C:\WINNT\System32\dhcp\backup\old” failed with system error 5 (0x00000005): “Access is denied. “.  The move file operation will fail with error -1032 (0xfffffbf8).

 3.Jet database read or write operations failed due totcpsvcs (4160) The backup has been stopped because it was halted by the client or the connection with the client failed.

 4.Jet database read or write operations failed due to Another program(Backup Exec) is accessing the database.

 Website for reference:

 http://technet.microsoft.com/en-us/library/cc726907(WS.10).aspx

 http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows%20Operating%20System&ProdVer=5.2&EvtID=1016&EvtSrc=DHCPServer&LCID=1033

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

PowerShell code for adding Domain Controller

 #
 # Windows PowerShell script for AD DS Deployment
 #
Import-Module ADDSDeployment
 Install-ADDSDomainController `
 -NoGlobalCatalog:$false `
 -CreateDnsDelegation:$false `
 -Credential (Get-Credential) `
 -CriticalReplicationOnly:$false `
 -DatabasePath “C:\Windows\NTDS” `
 -DomainName “test.local” `
 -InstallDns:$true `
 -LogPath “C:\Windows\NTDS” `
 -NoRebootOnCompletion:$false `
 -SiteName “Default-First-Site-Name” `
 -SysvolPath “C:\Windows\NTDS” `
 -Force:$true

Introducing Hyper-V 3.0 Microsoft added some new features which allows for better virtualization management for Domain Controllers. From now, you don’t have to affraid USN Rollback when you restore your DC from snapshot or when you use DC’s clone in your environment. New Hyper-V 3.0 is “smarter” and it secures your environment. Thanks to that, you may use new feature for rapid DC deployment from the existing Domain Controller. You need to only allow cloning DC, adding it into appropriate domain group and prepare some XML config file with PowerShell v3.0 cmd-let. Then you can safely clone new DCs from the existing one(s).

In virtualized domain environments, this feature is also really good for disaster forest/domain recovery.

Important! To be able to use the new feature, you need at least one Windows Server 2012 Domain Controller on which you hold PDC Emulator operation master role.

More about Domain Controller virtualization process, you will read on Microsoft Technet at
http://technet.microsoft.com/en-us/library/hh831734.aspx

Active Directory Based Authentication

With Windows Server 2012, Microsoft presented new Windows activation method. This method is called Active Directory Based Authentication. That is available in Volume Activation Services role when you run Server Manager.

P1

Volume Activation Services – Active DIrectory Based Authentication

When you use Windows 8 in your environment, you can simply activate it when client is being joined to the domain. It happens automatically, you don’t need to put an activation key and there is no need to access the Internet.

This much more secures your environment in comparison to KMS server. When KMS was present in the environment, you need to only know server name on which it was running (there is also other method for that but I would not describe it here  and you can simply activate your Windows copy. Now, with AD BA you need to add client to the domain to allow for OS activation. It is also important to limit users in your environment with permission for joining computers into domain.

Of course, you can still use KMS server for that. It is suported by AD BA. However, it is required for previous Windows OSes. AD BA may be only used for Windows 8 activation!

Important! To be able to use AD BA option, you need to extend Active Directory schema to Windows Server 2012 but you don’t need to have Windows Server 2012 Domain Controller

RID Operation Master

Microsoft improved RID FSMO role in Windows Server 2012. The most know improvement in this role is its RID pool incrementation. Previously we had 2^30 available RIDs and now we have one bit more 2^31. This bit incremented pool  from one billion to two billions of RIDs. Thanks to that improvement we have doubled RID’s pool. But we need to know one important thing. If we want to use that, we need to have Windows Server 2012 Domain Controllers or Windows Server 2008R2 with appropriate hotfix installed. Other Windows versions do not support extended RID pool.

Remember! Extended RID pool may be used only by Windows Server 2012 and Windows Server 2008R2 with appropriate hotfix installed. Additionally, you need to have RID Operation Master role on Windows Server 2012 Domain Controller!

Another great thing introduced with Windows Server 2012 is RID Pool re-use feature! Microsoft did not fix RID leak issue which happens mostly when you are creating new users in a script mode. When password set up by script does not meet domain password criteria, object cannot be created successfully and RID is lost. In case that your script was prepared to create many user objects, you are loosing many RIDs. With Windows Server 2012 on which RID Operation Master is held, those RIDs are going to RID Pool re-use. This pool catches all those RIDs and uses them for the next objects which are created. If pool is empty then standard RID is used from global DC’s pool.

Important! RID Pool  re-use is only available until you will restart Domain Controller. After server reboot that pool is empty!

In Windows Server 2012 Microsoft introduced also event logging for used RIDs. The first entry will appear when RID consumes 100.000.000 (10% of pool). Another entry will be recorded when 10% of remaining pool will be used (in this case 1.000.000.000 – 100.000.000 = 900.000.000 and 10% from remaining pool is 90.000.000).

Events are recorded every 10% consumption of remaining pool. Smaller RIDs pool more frequent logs in Event log.

Microsoft changed also, possibility to issue large pool of RIDs from RID Master to other Domain Controllers. By default RIDs are delivered in 500 in a pool for each Domain Controller. Administrator is able to change that value in registry but when he/she sets up too high value, RIDs may be exhausted in short time. In Windows Server 2012 Microsoft limited maximum amount of RIDs to issue. The maximum pool allowed for distribution is 15.000 (decimal). When you set up higher value in the registry, it won’t be issued to Domain Controller(s) because new mechanism will issue maximum 15.000 RIDs in a pool.

One more interesting thing introduced in new RID Mater FSMO role is RID Manager artificial ceiling protection mechanism. Microsoft knows that administrators do not read event log frequently and even if they read it, they do not react too fast to solve the issue recorded in Event log. They implemented new mechanism which blocks RID distribution when its pool exceeds 90%. From that point, RID Master does not issue any pool to other Domain Controllers. Administrator must manually unlock this. That mechanism informs administrator about pool exhaustion (90% RIDs in general pool are used) and informs that additional activity may be required to prevent complete exhausting RID pool.

Other new Active Directory features

  • Kerberos enhancements
  • Active Directory Replication and Topology Management
  • Off-Premises Domain Join
  • Group Managed Service Accounts (GMSA)
  • Deferred Index Creation

Refer:  http://technet.microsoft.com/en-us/library/hh831477.aspx.

New features in Active Directory in Windows Server 2012

Some new features or improvements in Windows server 2012 Active directory.

  • New Domain Controller promotion process
  • Improved Active Directory Administrative Center console
  • New Domain Controller virtualization features
  • Dynamic Access Control
  • Active Directory Based Authentication
  • RID Operation Master improvements

For more features and advancement, Refer: http://technet.microsoft.com/en-us/library/hh831477.aspx

New Domain Controller promotion process

Microsoft simplified Domain Controller promotion process as much as they can. In Windows Server 2012 they do a real great improvement. Domain Controller promotion process allows much more simple introduction of the first Windows Server 2012 DC in your existing domain environment.

You don’t have to extend your schema and prepare domain environment for the first Windows Server 2012 Domain Controller. Previously, you had to extend schema and prepare domain using adprep manually with appropriate switches before you were able to promote DC based on newer operating system. Also dcpromo known from previous Windows v    ersions is no longer used for server promotion. That command is integrated with new Windows Server Manager. Whole process for Windows Server 2012 Domain Controller introduction in the existing environment is based on GUI wizard in Server Manager.

You need to only be logged on with appropriate permissions and you can start the process very quickly. Just add Active Directory: Domain Services role from the new manager and after all, follow post-installation steps in notification area. When you are promoting new DC, you are informed that wizard extends schema and prepares domain for the new Domain Controller.

P1

Automatic forest and domain preparation

P2

Automatic forest and domain preparation

P3

As I mentioned above, dcpromo cannot be used for DC promotion as it was in the previous versions of Windows. It is integrated with Server Manager and if you try to run it from command-line, you will see that it is not possible and you have to run the process from new manager.

P4

There is No dcpromo

However, you can still use dcpromo in command-line to:

  • forcefully decommission DC (/forceremoval switch)
  • install from media DC (/adv switch)

Note! You need to know that everything you will do in Server Manager is translated to PowerShell v3.0 code and run in the background.

New Active Directory Administrative Center

Microsoft introduced for the first time ADAC in Windows Server 2008R2. We were able to use this console for:

  • User management
  • Computer management
  • Group management
  • OU management
  • Domain Functional Level management
  • Forest Functional Level management
  • LDAP queries

Now, new Active Directory Administrative Center console allows for more. Of course, all the previous features are still suported but some new are available:

You don’t have to use complicated PowerShell cmd-lets to restore deleted object(s) or create/modify Fine-Grained Password policy. From now, you can simply use GUI for that. Just run new ADAC (it is available in tools or execute dsac.exe in run box) and go to Deleted Objects container to restore deleted object(s)

P5

GUI for AD Recycle Bin

The same situation is for Fine-Grained Password Policy, you don’t have to use ADSI Edit or PowerShell to create new PSO. This is also available over GUI method in ADAC console.

P6

GUI for Fine-Grained Password Policy

Everything what you do in Active Directory Administrative Center is also translated into PowerShell v3.0 code and run in the background. In this case, ADAC has implemented new feature called PowerShell History viewer which allows you to see cmd-lets used for action and whole syntax. You can copy it into notepad and modify to run it later. This is really good method to learn PowerShell.

PowerShell History viewer is available at the bottom of Active Directory Administrative Center console

PowerShell History viewer

Completely new feature in Windows Server 2012 is Dynamic Access Controll. It is responsible for simplified management of claims in AD and allows to extend FileServer permissions out of standard ACL method. User does not need to be a member of many groups in Active Directory, You can allow him/her access to resources over claims in combination with DAC. This option reduces Kerberos token size which is really important in large domain environments where user is a member of many groups.

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.

Loopback processing in GPO

What is loopback processing? 

Group Policy loopback is a computer configuration setting that enables different Group Policy user settings to apply based upon the computer from which logon occurs. 

Breaking this down a little more:

  1. It is a computer configuration setting. (Remember this for later)
  2. When enabled, user settings from GPOs applied to the computer apply to the logged on user.
  3. Loopback processing changes the list of applicable GPOs and the order in which they apply to a user. 

 Why would I use loopback processing?

Administrators use loopback processing in kiosk, lab, and Terminal Server environments to provide a consistent user experience across all computers regardless of the GPOs linked to user’s OU. 

Our recommendation for loopback is similar to our recommendations for WMI filters, Block Inheritance and policy Enforcement; use them sparingly.  All of these configuration options modify the default processing of policy and thus make your environment more complex to troubleshoot and maintain, whenever possible, keep your designs as simple as possible.

 How to configure loopback processing

The loopback setting is located under Computer Configuration/Administrative Templates/System/Group Policy in the Group Policy Management Editor (GPME). 

 Use the policy setting Configure user Group Policy loopback processing mode to configure loopback in Windows 8 and Windows Server 2012Earlier versions of Windows have the same policy setting under the name User Group Policy loopback processing mode. 

loop1

 When you enable loopback processing, you also have to select the desired mode.  There are two modes for loopback processing:  Merge or Replace.

loop2

 Loopback Merge vs. Replace

Prior to the start of user policy processing, the Group Policy engine checks to see if loopback is enabled and, if so, in which mode.

Loopback Merge

During loopback processing in merge mode, user GPOs process first (exactly as they do during normal policy processing), but with an additional step.  Following normal user policy processing the Group Policy engine applies user settings from GPOs linked to the computer’s OU.  The result– the user receives all user settings from GPOs applied to the user and all user settings from GPOs applied to the computer. The user settings from the computer’s GPOs win any conflicts since they apply last.

 To illustrate loopback merge processing and conflict resolution, let’s use a simple chart.  The chart shows us the “winning” configuration in each of three scenarios:

  1. The same user policy setting is configured in GPOs linked to the user and the computer
  2. The user policy setting is only configured in a GPO linked to the user’s OU
  3. The user policy setting is only configured in a GPO linked to the computer’s OU

loop3

 Now, going back to our original example, loopback processing in Merge mode applies user settings from GPOs linked to the user’s OU followed by user settings from GPOs linked to the computer’s OU.

loop4

 GPOs for the user in OU ”E” apply in the following order (the first part is identical to normal user policy processing from our original example):

Local Group Policy

  1. Group Policy objects linked to the Site
  2. Group Policy objects linked to the Domain
  3. Group Policy objects linked to OU “A”
  4. Group Policy objects linked to OU “B”
  5. Group Policy objects linked to OU “E”
  6. Group Policy objects linked to the Site
  7. Group Policy objects linked to the Domain
  8. Group Policy objects linked to OU “A”
  9. Group Policy objects linked to OU “C”
  10. Group Policy objects linked to OU “G”

 Loopback Replace

 Loopback replace is much easier. During loopback processing in replace mode, the user settings applied to the computer “replace” those applied to the user.  In actuality, the Group Policy service skips the GPOs linked to the user’s OU. Group Policy effectively processes as if user object was in the OU of the computer rather than its current OU. 

 The chart for loopback processing in replace mode shows that settings “1” and “2” do not apply since all user settings linked to the user’s OU are skipped when loopback is configured in replace mode.

loop5

 Returning to our example of the user in the “E” OU, loopback processing in replace mode skips normal user policy processing and only applies user settings from GPOs linked to the computer.

loop4

 The resulting processing order is: 

  1. Local Group Policy
  2. Group Policy objects linked to the Site
  3. Group Policy objects linked to the Domain
  4. Group Policy objects linked to OU “A”
  5. Group Policy objects linked to OU “C”
  6. Group Policy objects linked to OU “G”

 Recap

  1. User Group Policy loopback processing is a computer configuration setting.
    • Loopback processing is not specific to the GPO in which it is configured. If we think back to what an Administrative Template policy is, we know it is just configuring a registry value.  In the case of the loopback policy processing setting, once this registry setting is configured, the order and scope of user group policy processing for all users logging on to the computer is modified per the mode chosen: Merge or Replace.
  2. Merge mode applies GPOs linked to the user object first, followed by GPOs with user settings linked to the computer object. 
    • The order of processing determines the precedence. GPOs with users settings linked to the computer object apply last and therefore have a higher precedence than those linked to the user object.
    • Use merge mode in scenarios where you need users to receive the settings they normally receive, but you want to customize or make changes to those settings when they logon to specific computers.
  3. Replace mode completely skips Group Policy objects linked in the path of the user and only applies user settings in GPOs linked in the path of the computer.  Use replace mode when you need to disregard all GPOs that are linked in the path of the user object.

Those are the basics of user group policy loopback processing. For more updates and troubleshooting series , please refer  http://cbfive.com/blog/post/Loopback-Policy-Processing-Debug-Series-Replace-Mode.aspx

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.