How to Recover a Journal Wrap Error (JRNL_WRAP_ERROR) and a Corrupted FRS SYSVOL from a Good DC – What option do I use, D4 or D2? What’s the Difference between D4 and D2?

Original: 11/21/2013
Updated 8/30/2014

Errata

Ace here again. I’ working on updating all of my blogs. If you see any inconsistencies, please let email me and let me know.

Prologue

Are you seeing Event ID 13508, 13568, and anything else related to SYSVOL, JRNL_WRAPS, or NTFRS?

Note – I will not address Event ID 2042 or 1864. That’s an issue with replication not working beyond the AD tombstone. If you are seeing them, you’re best bet is to forcedemote the machine, run a metadata cleanup, and re-promote it, and make sure you configure your firewall and/or AV to allow replication traffic or stop using the ISP’s or router as a DNS address, or disable IP routing and WINS Proxy, to prevent this in the future. And while you’re at it bump up your AD tombstone to 180 days,

As for the NTFRS, after talking to numerous folks whether directly assisting a customer, or through the TechNet forums, there seems to be some confusion associated with how to handle Journal Wrap errors, what caused them, and what are the differences between the D2 and D4 options. I’ll try to quell this confusion in this blog, as well as provide an easy step-step and providing an explanation for the steps, to get out of this error. Note: The steps are from Microsoft KB290762. I just thought to further break it down so a layman will understand them.

Reference KB: Using the BurFlags registry key to reinitialize File Replication Service Replica Sets
http://support.microsoft.com/kb/290762

For Windows 2008/2008 R2/2012/2012 R2 with DFSR

Follow this KB to fix it:

How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like “D4/D2” for FRS)
http://support.microsoft.com/kb/2218556

Backing Up and Restoring an FRS-Replicated SYSVOL Folder
http://msdn.microsoft.com/en-us/library/windows/desktop/cc507518(v=vs.85).aspx

What Caused the Journal Wrap?

First you have to ask yourself, what caused this error on my DC? What did I do to get here? In a nutshell, JRNL_WRAPS are caused by SYSVOL corruption.

The usual culprit can be a number of things:

Abrupt shutdown/restart. I don’t usually see this unless there are power issues in the building with not power protection or UPS battery system.
Disk errors – corrupted sectors. This is a common issue with a DC on older hardware.
AV not configured to exclude SYSVOL, NTDS and the AD processes. This is the typical culprit I’ve seen in many cases.

Ok, So what do I have to do to fix this?

To get yourself out of this quandary, it’s rather simple. Yea, you might say yea, right, this is not so simple, but it really isn’t that hard. It just requires a little understanding of what you have to do, which is all it’s doing is simply copying a good SYSVOL folder and subfolders from a good DC to the bad DC (the one with the errors.

Basically, you first choose which DC is the good DC to be your “source” DC for the SYSVOL folder. Then you you stop the NTFRS service on all DCs. Yes, NTFRS must to be stopped on all DCs to perform this. Then set the registry key on the good DC and the bad DC. That’s it. The process will take care of itself and reset the keys back to default after it’s done.

If you only have one DC, such as an SBS server, and SYSVOL appears ok, or restore just the SYSVOL from a backup. Then just follow the “Specific” steps I’ve outlined below.
If more than one DC, but not that many where you can’t shutdown the NTFRS on all of them, such as if you have 40 DCs, pick and choose the best one and set Burflags to D2 on the bad and D4 on the good.
If there are numerous DCs, such as a large infrastructure, simply run dcpromo /forcedemote the DC with the error, run a metadata cleanup, then re-promote to a DC back into the domain. If you unplug the DC and run a metadata cleanup, then you will have to rebuild the DC from scratch. The forcedemote switch removes the AD binaries off the machine allowing you to re-promote it.

To summarize:

You have two choices as to a restore from a good DC using FRS:

D2 is set on the bad DC: Non-Authoritative restore: Use the D2 option on the DC with the empty SYSVOL folder, or the SYSVOL folder with the incorrect data. This way it will get a copy of the current SYSVOL and other folders from the good DC that you set the BurFlags D4 option on.
D4 is set on the good DC: Authoritative restore: Use the BurFlags D4 option on the DC that has a copy of the current policies and scripts folder (a good, not corrupted folder).

The BurFlags option – D4 or D2? What do I use?

The steps refer to changing a registry setting called the BurFlags value. If the BurFlags key does not exist, simply create it. It’s a DWORD key.

More importantly, it references change the BurFlags to one of two options: D4 or D2. Therefore, before going further, I would like to squelch the confusion on what the D2 and D4 settings mean:

D2/D4 – Which is which?

D2, also known as a Nonauthoritative mode restore – this gets set on the DC with the bad or corrupted SYSVOL
D4, also known as an Authoritative mode restore – use this on the DC with the good copy of SYSVOL.
You must shut the NTFRS service down on ALL DCs while you’re doing this until instructed to start it.
You’ll probably want to copy the current SYSVOL structure on the good DC to another folder as a backup prior to doing this.

The D2 option on the bad DC will do two things:

Copies the current stuff in the SYSVOL folder and puts it in a folder called “Pre-existing.” That folder is exactly what it says it is, it is your current data. This way if you have to revert back to it, you can use the data in this folder.
Then it replicates (copies) good data from the GOOD DC (D4) to the bad guy (D2).

Once again, simply put:

The BurFlags D4 setting is “the Source DC” that you want to copy its good SYSVOL folder from, to the bad DC.
The bad DC BurFlags is set to D2, which tells it to pull from the source DC, the one you set D4 on.

Here are the steps summarized:

For an Authoritative Restore you must stop the NTFRS services on all of your DCs
In the registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
1. Set the BurFlags setting to HEX “D4” on a known DC that has a good SYSVOL (or at this time restore SYSVOL data from backup then set the Burflag to D4)
2. Then start NTFRS on this server.
3. You may want to rename the old folders with .old extensions prior to restoring good data.
Clean up the folders on all the remaining servers (Policies, Scripts, etc) – renamed them with .old extensions.
Set the BurFlags to D2 on all remaining servers and then start NTFRS.
Wait for FRS to replicate.
Clean up the .old stuff if things look good.
If the “D4” won’t solve the problem try the “D2” value.

So circling back, to fix this and make it work, just copy the contents of SYSVOL to another location, then follow the KB, which simply states you must stop the NTFR service on ALL DCs. Then pick a good one to be the “Source DC.”

Of course, as I’ve stated above, if you have a large number of DCs, the best bet is to forcedemote the bad DC, run a metadata cleanup to remove its reference from AD, then re-promote it.

If you have a small number of DCs, and if you have a good DC and a bad DC, on the good DC, you would set the BurFlags to D4, and on the BAD DC you would set the Burflags to D2.

Example run:

In the example below, if you set BurFlags to D4 on a single domain controller and set BurFlags to D2 on all other domain controllers in that domain, you can rebuild the SYSVOL from the D4 DC (the source DC).

I’ve also heard of admins manually copying the SYSVOL folder, then set the BurFlags options as mentioned, which works too. But no, I haven’t tested it. That would be for a lab on another day. 🙂

Authoritative Restore Example

Use the BurFlags D4 option on the DC that has a copy of the current policies and scripts folder (a good, not corrupted folder).

Stop the FRS service on all DCs. To do this to all DCs from one DC, you can download PSEXEC and run “psexec \\otherDC net stop ntfrs” one at a time for each DC.
On a good DC that you want to be the source, run regedit and go to the following key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
In the right pane, double-click “BurFlags.” (or Rt-click, Edit DWORD)
Type D4 and then click OK.
On the bad DC, run regedit and go to the following key:   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
   In the right pane, double-click “BurFlags.” (or Rt-click, Edit DWORD)
   Type D2 and then click OK.
Quit Registry Editor, and then switch to the Command Prompt (which you still have opened).
On the good DC, start the FRS service, or in a command prompt, type in “net start ntfrs” and hit <enter>
On the bad DC, start the FRS service, or in a command prompt, type in “net start ntfrs” and hit <enter>
On the bad DC, check the Sysvol folder to see if it started populating.
Check for EventID 13565 which shows the process started
Check for EventID 13516, which shows it’s complete
Start FRS on the other DCs.

The following occurs after running the steps above after you start the FRS service (NTFRS):

The value for BurFlags registry key returns to 0.
Files in the reinitialized FRS folders are moved to a <var>Pre-existing</var> folder.
An event 13565 is logged to signal that a nonauthoritative restore is started.
The FRS database is rebuilt.
The member replicates (copies) the SYSVOL folder from the GOOD DC.
The reinitialized computer runs a full replication of the affected replica sets when the relevant replication schedule begins.
When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.

Note: The placement of files in the <var>Pre-existing</var> folder on reinitialized members is a safeguard in FRS designed to prevent accidental data loss. You can copy this stuff back if it didn’t work, but I have not yet seen when this has not worked!

Summary

I hope this helps cleaning up your FRS and SYSVOL replication issues.

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services
Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This blog is provided AS-IS with no warranties or guarantees and confers no rights.

April 30, 2013May 10, 2013

DNS Zone Types Explained, and their Significance in Active Directory

==================================================================
==================================================================
Ace Fekay, MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
   Microsoft Certified Trainer
   Microsoft MVP: Directory Services
   Active Directory, Exchange and Windows Infrastructure Engineer and Janitor

Revisions

Original publication 4/30/2013

Prelude

Ace here again. I thought to touch base on DNS zones, and more so, focus on what AD integrated zones are and how they work. This blog almost mimics my class lecture on this topic. Check back for updates periodically, which I will notate with a timestamp above with whatever I’ve added or modified.

This topic was also briefly discussed in the following Microsoft Technet forum thread:
Technet thread: “Secondary Zones?”
http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/c1b0f3ac-c8af-4f4e-a5bc-23d034c85400

AD Integrated Zones AD Database Storage Locations

First up is a background on the various parts of the Active Directory database and what gets stored in them. This will help understand where DNS data is stored as I discuss it later in this blog.

The Active Directory Data Store (the AD database):

There are three possible storage locations for DNS zone storage in the Active Directory database:

DomainNC – This was the only available location with Windows 2000. This replicates to all DCs only in a specific domain.
DomainDnsZones partition – Introduced in Windows 2003 and used in all newer operating systems. This replicates to all DCs only in a specific domain in the forest.
ForestDnsZones partition. This replicates to all DCs in the forest.

You can see how not all partitions are replicated forest wide. It depends on the partition:

Ok, Now the DNS Basics:

A Secondary is a read-only copy
A Secondary zone stores it’s data in a text file (by default in the system32\dns folder)
A Secondary gets a copy of the zone data from the Primary
A Primary is the writeable copy
A Primary stores it’s zone data in a text file (by default in the system32\dns folder)
There can only be one Primary, but as many Secondary zones as you want.
You must allow zone transfer capabilities from the Primary zone if you want to create a Secondary.
AD integrated zones do NOT need zone transfers to be allowed (see below for specifics)

Active directory Integrated Zones changes this a bit:

AD Integrated zones are similar to Primary zones, however their data is stored as binary data in the actual AD database and not as a text file. The specific place in the AD database depends on the DC’s operating system version and replication scope, which means what “logical” part of the physical AD database it’s stored in, which will affect which DCs in the forest it will replicate to.

The “only one Primary Zone” rule is changed by introducing the Multi-Master Primary feature. This is because the data is not stored as a text file, rather it is stored in the actual, physical AD database (in one of 3 difference logical locations or what we call the Replication Scope), and any DC that has DNS installed (based on the replication scope) will be a writeable copy.
The zone data is replicated to other DCs in the replication scope where the data is stored (based on one of the 3 logical locations)
Each DC in the replication scope that has DNS installed, will automatically make available the zone data in DNS
Each DC that hosts the zone can “write” to the zone, and the changes get replicated to other DCs in the replication scope of the zone/
The DC that makes a change becomes the SOA at that point in time, until another DC makes a change to the zone, then it becomes the SOA
An AD Integrated zone can be configured to allow zone transfers to a Secondary, but the Secondary CANNOT be a DC in the same replication scope as the zone you are trying to create as a Secondary, otherwise the DC you are attempting to create the Secondary on will automatically change it to AD integrated, since it “sees” it in the AD database. In some cases, if this is forced or done incorrectly, it can lead to duplicate or conflicting zones in the AD database, which is problematic until fixed.

And if you install DNS on another DC, the zone data will *automatically* appear because DNS will recognize the data in the AD database. AD integrated zones can also act as a Primary zone for secondary zones, whether they are on Windows machines, BIND (on Unix) or any other name brand.

Remember, AD integrated zones still follow the RFCs, but have more features.

Duplicate or Conflicting zones?

Since I touched based on duplicate and conflicting zones, you may want to check if they exist in your AD database. You have to check each partition, and if you have more than one domain, you have to check the DomainDnsZones and DomainNC of each domain. You may even have to check it on multiple DCs in various AD Sites to see if they all “see” the same copy or different copies. You would be surprised what I’ve seen with AD replication problems and seeing different DCs “seeing” something different in its own database. This issue also manifests as a symptom in more than just a DNS problem, where you create a user on one DC and it never replicates to another DC.

Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones
http://msmvps.com/blogs/acefekay/archive/2009/09/02/using-adsi-edit-to-resolve-conflicting-or-duplicate-ad-integrated-dns-zones.aspx

Primary Standard Zone, Secondary Standard Zones & Zone Transfers

Zone transfers allow you to create a read only copy (a Secondary zone) on another DNS server, that will pull a copy (transfers) from the read/writable zone (the Primary zone).

Primary and Secondary zones store their data as text files.

On a Windows machine, the zone files can be found in the \system32\dns folder with a file name such as “domain.com.dns”. You can have numerous read only copies, but there can only be one read/write of that zone.

Please keep in mind, the authoritative DNS server listed in the registrar for a public domain name (zone) does not have to be a Primary, it’s just the host nameserver listed as authoritative. It can get it’s data from a Primary that is not listed, hence the writable copy is actually hidden and protected from public access.

Do I need Zone transfers Allowed for AD Integrated Zones if I do not have Secondaries Zones?

The short answer: NOPE.

The reason is that the term “AD Integrated” means the zone is stored in the AD database, and the zone will replicate to other domain controllers within the same replication scope (domain-wide or forest-wide) automatically as part of the AD replication process.

By default, AD integrated zones are configured to not allow zone transfers.

Allowing zone transfers is an option provided to support non-DC DNS servers, BIND or any other name brand DNS server that you want to allow zone transfers to a secondary on those servers.

Rotating SOA

Additional security options of AD integrated zones, is one of the feature of AD integrated zones, as well as the fact that there can be more than one Primary zone copy of it. This is because all DNS servers that host the zone in a domain or forest has the ability to be a writable copies and becomes the actual “start of authority” (SOA) of that zone when a specific DC/DNS accepts a write operation, such as a client machine registering, or the DC itself updating its SRV records.

For example, if a DC updates it’s SRV and other records at the default 60 minute interval (all other machines register every 24 hours), it will update its data into the DNS server listed as the first DNS address in the network card. This server now writes it into DNS and NOW becomes the SOA of the zone. That data is replicated to other DC/DNS servers with default AD replication. Now all other DC/DNS servers will see the change.

To further explain, since the zone is AD integrated, each and every DC in the replication scope of the zone, can accept changes, due to an AD integrated zone’s Multi-Master Primary Zone features. Based on the definition of what an SOA is, that is being the DNS server that’s authoritative to accept writes, therefore, whichever DC/DNS accepted a change to the zone, that specific DC/DNS will become the SOA for that moment in time. Then when the next DC/DNS that accepts a change, it will now become the new SOA. The SOA constantly changing in an AD environment is accepted, and default behavior.

That is why you can watch the SOA name on AD integrated zones change. The data is replicated automatically as part of the AD replication process because it is stored in the AD database.

Active Directory-integrated DNS zone serial number behavior (SOA default behavior)
http://support.microsoft.com/kb/282826

References

Configure AD Integrated Zones
(When converting to AD integrated zones)
Quoted: “Only primary zones can be stored in the directory. If a zone is configured on other domain controllers as a secondary zone, these zones will be converted to primary zones when you convert the zone to AD integrated. This is because the multimaster replication model of Active Directory removes the need for secondary zones when a zone is stored in Active Directory. Conversion of the zone from secondary to primary will occur when AD DS is restarted.”
http://technet.microsoft.com/en-us/library/ee649181(v=ws.10)

Understanding DNS Zones
http://www.tech-faq.com/understanding-dns-zones.html

Understanding stub zones: Domain Name System(DNS)
Jan 21, 2005 – The master servers for a stub zone are one or more DNS servers authoritative for the child zone, usually the DNS server hosting the primary …
http://technet.microsoft.com/en-us/library/cc779197(v=ws.10).aspx

April 19, 2013April 30, 2013

Reanimate an Exchange Server Deleted From the Exchange Organization in the Configuration Container in Active Directory

By Ace Fekay
MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services
Active Directory, Exchange and Windows Infrastructure Engineer & Janitor

Background:

Hey everyone, Ace here again. Here’s an interesting issue I came across when an administrator, while using ADSI Edit, deleted one of their Exchange 2010 servers from the Exchange Organization in AD’s Configuration Container. Of course, it was not intentional, so I didn’t even ask why or how, but I was told that they were working on something else in ADSI Edit, and the administrator unintentionally deleted the Exchange server object. And as we all know, there is no “Undelete” button in ADSI Edit.

Before I went about trying to perform an Authoritative Restore with AD, I figured I would try to use the AD Recycle Bin to recover the object. However, I knew it wouldn’t be there, because it was never deleted from ADUC Computer Container, rather it was deleted from the Exchange Organization. But I did it just to show how to do it, and to illustrate the differences in the object’s locations and significance.

What I did was is re-animated the deleted server using ADSI Edit. I used a lab machine to test it before attempted to try it on their production system.

Before I performed a test delete in my lab

Here are the three Exchange Servers, Van-EX1, Van-EX2, and Van-EX3, showing in the ADUC’s Computers Container:

Here’s VAN-EX3 in ADSI Edit and its attributes. This is what it’s supposed to look like.

Looking further into the server object attributes in ADUC Advanced View, Attribute Editor, it shows the server’s ObjectSID:

Delete VAN-EX3

Here’s where I deleted VAN-EX3 in ADSI Edit:

The delete warning message:

And the second delete warning message. Apparently ADSI Edit, the tool that doesn’t have an Undelete” button, wants to make sure that you want to delete it. I think it’s good that it asks twice:

VAN-EX3 has now been deleted from the Exchange Organization section in the Configuration Container:

However, as you an see in ADUC, it still shows VAN-EX3. That’s because we didn’t delete it from AD, rather it was deleted from the Configuration Container.

As you can see here, Exchange’s services still show that they’re still running.

Trying to find the deleted object in the Recycle Bin using LDP

Here’s where I looked for the Exchange object in the Recycle Bin using LDP. However, since the Exchange computer object still exists in AD, rather it was deleted from the Organization. I knew it won’t be in the Recycle Bin, because it wasn’t really deleted from AD.

These steps were more to show everyone the differences between a deleted computer object, that would show up here, and an Exchange server deleted from the Organization.

Click Connection, then Bind:

We’re binding using default values, meaning it will use the currently logged on domain administrator account.

In LDP, click Options, then Controls:

In the Load Predefined drop-down box, I chose to “Return Deleted Objects:”

As you can see, Return Deleted Objects chosen in the drop-down box:

Under Tree View, for the base DN, I typed in cn=deleted objects,dc=adatum,dc-com. As you can see, nothing showed up. So VAN-EX3 is not in the Recycle Bin.

Recreating VAN-EX3 in the Exchange Organization in the Configuration Container

I drilled down into the Exchange Organization in the Configuration Container, CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Servers. Then I right-clicked CN=Servers, New, Object.

By the way, not to get off topic, but if you’re wondering how the Exchange team came up with that Administrative Group name, “(FYDIBOHF23SPDLT),” click here.

Once the server object has been created, now we need to create the necessary Exchange server object containers under the server object we created. What helps is that the attributes are still in AD:

For “Select a Class” dialog box, scroll down and select msExchServersContainer

For the Value field, type in VAN-EX3:

Click Finish:

Now we must create the Exchange Information Store container. Right-click, New, choose Object:

In the Select a Class dialog box, choose msExchInformationStore:

Type “Information Store” in the Value field:

Click Finish:

The values appear correct so far. If you double-click on the CN=Information Store object, scroll down, you can see the DN value is correct (sorry, I didn’t screenshot that part):

Now let’s create the MTA. Same deal as above, in the Select a Class dialog box, right-click, New, scroll down and choose mTA:

Type in Microsoft MTA:

To get the time out and other values it’s asking, I opened another instance of ADSI Edit, and looked at the values for one of the other existing Exchange Servers:

The transRetryMins value of 5 that I populated, which I found from the other Exchange server:

The last attribute, which of course is the server’s name:

Now we must create the Microsoft System Attendant object for VAN-EX3 by right-clicking Van-Ex3, new, choose Object, and in the Select a Class dialog box, scroll down and select exchangeAdminService:

For the CN value, type in Microsoft System Attendant:

Scroll down in the Attribute Editor to deliveryMechanism, set it to 0 (zero):

Click Finish:

Now test logging on with a mailbox that exists in VAN-EX3, and try to send and receive an email. You should find that it works perfectly.

Point of the story: Be careful what you do in ADSI Edit.

Suggestions, Comments, Corrections are welcomed.

Ace Fekay

February 16, 2012October 20, 2014

Create an Active Directory Fine Grained Password and Lockout Policy Passwords Settings Object (FGP & PSO) Step by Step

Create an Active Directory Fine Grained Password and Lockout Policy Passwords Settings Object (FGP & PSO)

Original publish date 2/16/2012
Revised 10/20/2014

Prelude

Ace here, again! I’ve updated this blog to reflect the fact that it’s much easier to create a PSO in Windows 2012, as well as a little background on PSOs.

Scope

Password policies are normally set in the Default Domain Policy. If they are created anywhere else, they won’t work. It’s just a fact of how AD and GPO account settings work. They are a domain specific settings.

Therefore, I thought I would put this blog together to explain them along with a step by step with lots of screenshots, on how to create a Fine Grained Password & Lockout Policy PSO (Password Settings Object) that you can apply to a group of users that will override the domain level Password and Lockout Settings.

And this is for Windows 2008 R2, which is a bit more tedious to create. If you are searching for how to create a PSO in Windows 2012 or Windows 2012 R2, the following link will help:

How to use Fine-Grained Passwords in Windows Server 2012
http://blogs.technet.com/b/uktechnet/archive/2012/08/28/guest-post-how-to-use-fine-grained-passwords-in-windows-server-2012.aspx

PSO and FGPP Guidelines

You can create one or more PSOs in your domain. Each PSO contains a complete set of password and lockout policy settings. A PSO is applied by linking the PSO to one or more global security groups or users. Actually, by linking a PSO to a user or a re modifying an attribute called msDSPSOApplied, which is empty by default. This approach now treats password and account lockout settings not as domain-wide requirements, but as attributes to a specific user or a group. For example, to configure a strict password policy for administrative accounts, create a global security group, add the service user accounts as members, and link a PSO to the group. Applying fine-grained password policies to a group in this manner is more manageable than applying the policies to each individual user account. If you create a new service account, you simply add it to the group, and the account becomes managed by the PSO.

Precedence:

A PSO can be linked to more than one group or user, an individual group or user can have more than one PSO linked to it, and a user can belong to multiple groups. So, which fine-grained password and lockout policy settings apply to a user? One and only one PSO determines the password and lockout settings for a s precedence.
The precedence value is any number greater than 0, where the number 1 indicates the highest precedence. If multiple PSOs apply to a user, the PSO with the highest precedence takes effect. The rules that determine precedence are as follows:

• If multiple PSOs apply to groups to which the user belongs, the PSO with the highest precedence wins.
• If one or more PSOs are linked directly to the user, PSOs linked to groups are ignored, regardless of
their precedence. The user-linked PSO with the highest precedence wins.
• If one or more PSOs have the same precedence value, Active Directory must choose. It picks the PSO with the lowest globally unique identifier (GUID). GUIDs are like serial numbers for Active Directory objects—no two objects have the same GUID. GUIDs have no particular meaning—they are just identifiers—so picking the PSO with the lowest GUID is, in effect, an arbitrary decision. You should configure PSOs with unique, specific precedence values so that you avoid this scenario.

These rules determine the resultant PSO. Active Directory exposes the resultant PSO in a user object attribute, msDS-ResultantPSO, so you can readily identify the PSO that will affect a user. PSOs contain all password and lockout settings, so there is no inheritance or merging of settings. The resultant PSO is the authoritative PSO.

To view the msDS-ResultantPSO attribute of a user:

1. Ensure that Advanced Features is enabled on the View menu.
2. Open the properties of the user account
3. Click the Attribute Editor tab.
4. Click Filter and ensure that Constructed is selected.
5. Locate the msDS-ResultantPSO attribute.

PSOs, OUs, and Shadow Groups:

PSOs can be linked to global security groups or users. PSOs cannot be linked to organizational units (OUs). If you want to apply password and lockout policies to users in an OU, you must create a global its membership shadows, or mimics, the membership of an OU.

Note: There is no graphical tool in Windows Server 2008 to create shadow groups.
However, you can create and manage them by using a very simple script that will run
periodically. This script should enumerate user objects in the desired OU and put them in a group.

Creating a PSO Step by Step

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

Summary

I hope this helps in your endeavor.

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

September 2, 2009September 2, 2014

Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones

Revisions:

Original publication 3/2006
Recompiled 6/10/2010
Updated 12/9/2010
Updated 8/31/2014
—

Prologue

Ace here again. I’m cleaning up my blogs for technical and syntax errors. If you see anything that needs correction, please let me know.

Preface and Scope Of this Article

This blog explains how to use ADSI Edit to determine if duplicate zones exists in the AD database and to delete them.

When using ADSI Edit, the duplicate zones show up in the partitions with names that are prefixed with an “In Progress….” or “CNF…” and suffixed with a long GUID number. You will be checking EACH DC. When you find them, you will simply delete them. because they are useless and cause substantial problems.

This blog also explains how duplicate zones will appear to make zone records disappear.

Introduction to Duplicate Zones

Duplicate zones can cause numerous issues for the mere fact that the DNS zone that DNS is showing you on a specific DC may not have the latest up to date data. It literally may be missing data that you see on other DCs. If there are duplicate or conflicting zones, the zone data can’t replicate, resulting in each DC may have a different copy of the zone, which then results in unreliability and AD issues.

And to further complicate it, there are three different storage locations that AD can store AD integrated DNS zones – DomainDnsZones, ForestDnsZones, and the DomainNC partitions. You can read more on specifics in one of my other blogs:

DNS Zone Types Explained, Storage Locations in the AD database, and their Significance in Active Directory.
https://blogs.msmvps.com/acefekay/2013/04/30/dns-zone-types-explained-and-their-significance-in-active-directory/

Symptoms?

You may have a duplicate zone or a conflicting zone if a zone exists in both the Domain NC and/or in one of the Application Partitions. Some of the symptoms include:

Trying to change the replication scope, you receive an unusual error message stating, “The name limit for the local computer network adapter card was exceeded.”

Event ID 4515
An admin may see the data on a different DC is not there and will manually create records.
Zone data is disappearing, or it appears to be. This can be caused by:

Someone is intentionally or unintentionally deleting the data (usually unlikely but can occur). If you think someone is deleting zone data, enable auditing.
DNS Records Disappearing and DNS Auditing
http://msmvps.com/blogs/acefekay/archive/2010/12/09/dns-records-disappearing-and-dns-auditing.aspx

The data on each DC is different, and you are wondering why replication isn’t brining the zone data up to date, but it won’t because replication will either not occur or won’t occur if AD sees a duplicate.

Causes?

You’ve installed DNS on another DC and you don’t see the zone under DNS that is on the other DCs, so you manually created the AD zone because you didn’t have the patience to wait for replication to occur, which it would have automatically populated.
You’ve promoted a new DC in another site and didn’t have the patience to wait for the zone data to replicate.
Antivirus not configured to exclude AD communications (common cause).
At one time, or currently, the AD environment is a mixed Windows 2000/2003/2008 environment and DNS is installed on all operating system versions. On Windows 2000, if the zone is AD Integrated, it is in the DomainNC partition of the AD database, and should be set the same in Windows 2003’s or newer DC/DNS server to keep the zone data compatible and allow both operating system versions to be able to read and use them.
Someone must have attempted to change it in Windows 2003 or 2008 DNS to place the zone in the DomainDnsZones partition no realizing the implications, hence the duplicate. In a scenario such as this where you want to use the Windows 2003 application partitions, you then must insure the zone on the Windows 2003 is set to the DomainNC, then uninstall DNS off the Win2000 machine, then once that’s done and AD replication has been given time to occur, you can go to the Windows 2003 or newer DNS and change the partition’s replication scope to one of the application partitions.
A new domain controller was promoted into the domain, and the administrator manually created the zone name in DNS. This causes a duplicate. The proper way was to simply install DNS, and allow AD replication to occur. The zone will auto-populate into DNS.

I usually don’t want to assume someone’s deleting data. That’s would be the far end of the spectrum, especially if more than one DC is showing inconsistent zone data.

I feel the best approach to find out which is occurring is to first find out if there is a duplicate zone. This is because auditing is time consuming, and you need to parse through all the events generated in the Event Security Logs. It’s easier to run ADSI Edit to find if there are duplicates. Once you’ve determined it’s not a duplicate zone issue, then you can move on to DNS auditing. If it is a duplicate zone issue, follow the procedure below to remove them.

AD Integrated Zones Storage Locations

First, a quick review on the partitions. Hopefully you’ve taken a few moments to read my blog link that I posted above to understand the partitions. If not, I’ll just touch base on it here so you understand it and can relate to it. For specifics and the nitty gritty, read my other blog above.

Windows 2000:

the physical AD database is broken up into 3 logical partitions, the DomainNC (Domain Name Context, or some call the Domain Name Container), the Configuration Partition, and the Schema Partition. The Schema and Configuration partitions replicate to all DCs in a forest.

The DomainNC is specific only to the domain the DC belongs to. That’s where a user, domain local or global group is stored. The DomainNC only replicates to the DCs of that specific domain.

When you create an AD Integrated zone in Windows 2000, it gets stored in the DomainNC. This causes a limitation if you want this zone to be available on a DC/DNS server that belongs to a different domain. The only way to get around that is for a little creative designing using either delegation, or secondary zones. This was a challenge for the _msdcs.contoso.com zone, which must be available forest wide to resolve the forest root domain, which contains the Schema and Domain Name Masters FSMO roles.

Windows 2003 and newer:

There were two additional storage locations added to the AD database for DNS storage use. These areas are called “partitions,” specifically the DomainDnsZones and ForestDnsZones Application Partitions, specifically to store DNS data. They were conceived to overcome the limitation of Windows 2000’s AD Integrated zones. Now you can store an AD Integrated zone in either of these new partitions instead of the DomainNC. If stored in the DomainDnsZones app partition, it is available only in that domain’s DomainDnsZones partition. If you store it in the ForestDnsZones app partition, it will be available to any DC/DNS server in the whole forest. This opens many more design options. It also ensures the availability of the _msdcs.contoso.com zone to all DCs in the forest. By default in Windows 2003, the _msdcs.contoso.com zone is stored in the ForestDnsZones application partition.

Selecting the Replication Scope in Windows 2003 and newer:

When selecting a zone replication scope in Win2003, in the zone’s properties, click on the “Change” button. Under that you will see 3 options:

“To all DNS servers in the AD forest example.com” The top button. This option puts the zone is in the ForestDnsZones Application Partition. This setting will allow the zone data to replicate to all domain controllers to every domain in the forest, including if additional Trees exist in the forest.
“To all DNS servers in the AD domain example.com” The middle button. This option means the zone is in the DomainDnsZones Application Partition. This setting allows the zone to be stored and replicated in the DomainDnsZones Application Partition in the specific domain that it exists in. This setting is not compatible with Windows 2000 domain controllers. If Windows 2000 domain controllers exist in the domain, then the bottom option (below) will need to be used.
“To all domain controllers in the AD domain example.com” The bottom button. This option means the zone is in the DomainNC (Domain Name Context) portion of the actual AD database. This is only for Windows 2000 compatibility, that is if you have any Windows 2000 domain controllers in that specific domain you are administering.

If you receive an Event ID 4015 or the following error, it may indicate there is a duplicate or conflicting zone that exists in the DomainNC, the DomainDnsZones Application partition and/or in the ForestDnsZones partition.

DNS Duplicate zone - Scope Replication error - The Replication scope could not be set- The name limit for the local computer network adapter was exceeded.

*

Non-AD Integrated Primary and Secondary Zones

A Primary or Secondary zone that is not stored in AD is stored in a text file in the system32\dns folder. This type of zone storage has nothing to do with the above types ONLY unless it is truly a secondary with the Master being a DC transferring a copy of the zone. This types of zone storage is obviously not secure.

Now **IF** you did manually create a zone (whether intentionally or unknowingly) on one DC while it already existed on another DC, then you may have a duplicate.

Duplicate zone names will start with the letters, “CNF…” or “InProgress…”

If there is a duplicate, you can use either ntdsutil or ADSI Edit to take a look. I will outline in this article on how to use ADSI Edit to look for the duplicate.

A duplicate zone name will appear in ADSI Edit that starts with an “In Progress….” or “CNF…” with a long GUID number after it.

The “CNF…” means it’s in conflict due to a duplicate in the AD database.
The “In Progress….” means it is trying to replicate, but it can’t because there’s another identical zone name but with a different USN version number (USNs are used for replication control between DCs) on another domain controller, which also means there’s a duplicate zone.

You can simply delete them, which will clean up the whole problem. Yep, a simple deletion. The “CNF” data is not used by AD, but yet it will conflict with the zone that is actually used, and needs to be deleted.

But before doing anything about it just yet, let’s read on to explain more about this and what may have caused it.

Preventing Duplicate Zones

AD Integrated Zones will auto-populate when adding replica domain controllers

If an AD integrated zone exists on a DC, and the DNS service is install DNS on another DC in the domain or forest, depending on the replication scope, it will automatically appear on the new DNS installation without any interaction on your part. You may have to wait a certain period of time for it to populate depending on if the other DC is in the same AD Site or not, but it WILL AUTO-POPULATE.

However, if you attempted to manually create the zone, believing that you need to do this to make the zone available on that DC, then you’ve just introduced a duplicate zone in the AD database. It doesn’t matter if the zone say originally exists in the DomainNC, and you manually create the zone on the other DC and put it into the DomainDnsZones application partition, AD will still recognize it in the AD database.

Duplicate zones cause numerous AD communication and access problems.

The point is, AD is smarter than you think. Let it do it’s thing.

An Example of what an AD Duplicate Zones looks like in ADSI Edit

This image shows “In Progress…” entries. They need to be deleted.

Using ADSI Edit to look at your AD Partitions

This is a manual step by step. For a screenshot step by step, see the next section.

This section assumes you have a little familiarity withe ADSI Edit. If not, I suggest to get yourself familiar with it once you’ve connected into the various partitions as outlined below. Be careful deleting anything, for once deleted, it’s a destructive process and basically it’s gone. There is no “Back Button” or “Undelete,” or “Undo” button. To restore data, you will need to run an Authoritative Restore from your backup program restoring that specific object that was deleted.

Determine if there are any duplicate zone.

While in ADSI Edit, if you see the same exact named zone in multiple partitions, such as seeing the same zone name in the Domain NC (Name Container) Partition, in the DomainDnsZones App partition), and/or in the ForestDnsZones application partition, you have duplicate zones. If this is the case, then you must choose which zone you want to keep.

I will select a DC that isn’t having a problem and delete the duplicates and conflicts off all other DCs.

Multiple domains or multiple tree forest?

If the AD forest is a multidomain forest with child domains and/or multiple trees, you must look at each domain’s DomainNC and DomainDnsZones partition, because each domain has one.

To view the DomainNC Partition (Default Naming Context)

In ADSI Edit, rt-click ADSI Edit, choose “Connect To,” in the Connection Point click on “Well known Naming Context”, then in the drop-down box, select “Domain”. If this is Windows 2003 or newer, this option shows up as “Default Naming Context”
Expand DomainNC or Default Naming Context, then expand your domain name. Drill down to CN=System. Under that you will see CN=MicrosoftDNS.
You will see any zones that are in the DomainNC partition under the MicrosoftDNS folder.
If you see anything that starts with an “In Progress….” or “CNF…” with a long GUID number after it, that’s a duplicate zone. Delete them!

To view the ForestDnsZones Application Partition:

[ForestDNSZones]

Click Start, click Run, type adsiedit.msc, and then click OK.
In the console tree, right-click ADSI Edit, and then click “Connect To.”
Click Select or type a Distinguished Name or Naming Context, type the following text in the list, and then click OK:
DC=ForestDNSZones, DC=contoso, DC=com
In the console tree, double-click DC=ForestDNSZones, DC=contoso, DC=com.
Double-click CN=MicrosoftDNS, and click the zone (contoso.com).
You should now be able to view the DNS records which exist in this DNS partition.

If you see anything that starts with an “In Progress….” or “CNF…” with a long GUID number after it, that’s a duplicate zone. Delete them!

To view the DomainDnsZones Application Partition

[DomainDNSZones]

Click Start, click Run, type adsiedit.msc, and then click OK.
In the console tree, right-click ADSI Edit, and then click “Connect To.”
Click Select or type a Distinguished Name or Naming Context, type the following text in the list, and then click OK: DC=DomainDNSZones,DC=contoso,DC=com.
In the console tree, double-click DC=DomainDNSZones,DC=contoso,DC=com
Double-click CN=MicrosoftDNS, and click the zone (contoso.com).
You should now be able to view the DNS records which exist in this DNS partition.

If you see anything that starts with an “In Progress….” or “CNF…” with a long GUID number after it, that’s a duplicate zone. Delete them!

Procedure with Screenshots:

Procedure to Delete the Duplicate zones

The easiest is to simply delete any duplicates you find in ADSI Edit. Choice #1, to delete them, can actually be safely done during production. Matter of fact, things may just start to work after you delete them! But Choice #2, which is a lengthy procedure, must be done during non-production hours.

Choice #1 (Recommended)

Just go into ADSI Edit and delete the duplicate zones you’ve found.

You can do this during production, and frankly, I’ve done it with a large infrastructure during production hours without any problems. This is my personal choice as long as there are no true duplicate zones, that is if there are duplicate zones without seeing any zone names prefixed with either an “In Progress….” or “CNF…” with a long GUID number after, and you truly see a duplicate of your actual zone, such as a domain.com in any of the partitions, then you must perform Choice #2.

Choice #2 (Not recommended)

This is a multi-step process to first change the zone to a Standard Primary Zone, which removes it from the AD database, allow AD replication to complete, delete the duplicates, then change the zone to AD integrated, and allow AD replication to complete.

Choose only one DC to perform this action.
- For example, if the duplicate is in the DomainDnsZones partition or DomainNC partition of a child domain, perform it only on a DC in that domain.
- If the Duplicate is in the ForestDnsZones partition, you can choose any DC in the forest.
Right-click the zone name, Choose Properties.
Under the General tab, click on the “Change” button next to the “Type” section.
Then uncheck the box that says “Store the zone in Active Directory (available only if the DNS servers is a domain controller.”
Click Ok, Don’t click Ok again just yet. Just click on Apply.
IMPORTANT – You must allow AD replication to occur to replicate the change to all DCs that are in the replication scope of the zone. If you have DCs in another AD Site and have replication schedule set for example, to 3 hours, then you must WAIT for 3 hours.
This action makes the zone a Standard Primary zone. This means it is now stored in the system32\dns\ZoneName.com.dns text file and is no longer in the AD database.
You can also force replication, as well. If there are AD Sites configured, and the replication schedule on the Site Connection objects is say 3 hours, you can reduce the replication schedule on the Site Connection objects to the minimal time allowed, which is 15 minutes. Then force replication by choosing the partner DC’s NTDS Setting, right –click, and choose Replicate Now.
Once confirmed that replication has occurred, and refreshing the ADSI Edit window and seeing the zones no longer exist in any of the partitions, then you can now safely delete the duplicate zones.

Note: Just to be clear, you will be deleting any zone names that you find that are prefixed with an “In Progress….” or “CNF…” and suffixed with a long GUID number after it.
Also Note: Deleting a zone is a destructive operation. Make sure you are only deleting duplicates!

Click Start, point to All Programs, point to Administrative Tools, and then click DNS.

In the console tree, right-click contoso.com, point to All Tasks, and then click Restart.

Change the zone back to AD Integrated into the Replication Scope it’s supposed to be in.

Once the duplicates have been deleted, once again, you MUST allow AD replication to occur. If you had changed the Replication Schedule on the Site Connection objects to quicken AD replication, you will want to reset them to their original setting.

References

DNS zone replication in Active Directory
http://technet.microsoft.com/en-us/library/cc779655(WS.10).aspx

Oops, our AD Integrated DNS zone’s are missing in Windows 2003!
http://blogs.technet.com/b/networking/archive/2007/05/10/oops-our-ad-integrated-dns-zone-s-are-missing-in-windows-2003.aspx

Directory Partitions:
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsbg_dat_favt.asp

kbAlertz- (867464) – Explains how to use ADSI Edit to resolve app partitions issues:
http://www.kbalertz.com/kb_867464.aspx

Event ID 4515 is logged in the DNS Server log in Windows Server 2003
http://support.microsoft.com/kb/867464

Summary

It seems like a lot of steps, but it really isn’t. Just read it over a few times to get familiar with the procedure. You may even want to change it into a numbered step by step list if you like. If you only have one DC, and one Site, then it’s much easier since you don’t have to mess with secondary zones or play with the site objects.

I hope that helps!

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services
Complete List of Technical Blogs and Videos: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This blog is provided AS-IS with no warranties or guarantees and confers no rights.

Suggestions, Comments and Corrections are Welcomed!