Welcome to Dirteam.com/ActiveDir.org Blogs Sign in | Join | Help



Kerberos Constrained Delegation, Double-Hops and Protocol Transition

Have been struggling with an issue where "Constrained Delegation" is enabled for an application and it is doing multiple "Hops" from the application and eventually making it to a SQL Server.  During the hops, an SPN is correctly presenting the Users TGT Hash as requested but then for some reason the TGT hash changes from an SPN to just a the HOST name of a member server (This was all observed through WireShark).  The internal code was reviewed and the same service calls were utilized when the correct Constrained calls were made and then when the call translated into an NTLM call(?).

Well it turns out we hadn't done anything wrong but when a multiple Hop Constrained Delegation configuration is used there is an issue where the User's TGT hash can transitioned to NTLM and the only way to continue to leverage Kerberos Constrained Delegation is to allow the SPN to allow it to "Use Any Authentication Protocol".

Basically an unrequested “Protocol Transition” occurs inflight transitioning from Kerberos to NTLM and the only way to get the intermediary hops to be able to use Kerberos Delegation through the process is to allow the intermediary services to request the authority to do a “Protocol Transition” back to Kerberos.

Kerberos Constrained Delegation May Require Protocol Transition in Multi-hop Scenarios

Posted Tuesday, July 29, 2014 12:57 PM by Paul Bergson | 0 Comments

NTFRS Depricated with Windows Server 2012

Microsoft has now officially deprecated FRS for Active Directory's use of it for SysVol replication.  That doesn't mean it still isn't supported and it isn't going away anytime soon but it has been reported that the next major release will be the last to support FRS replication and that o/s will probably be shipped sometime in 2015.

Ned Pyle has a great Blog on this in the link below:

No need to worry if you are running FRS right now, as a matter of fact you might not even realize that you are.  If you have a domain that you have upgraded since Windows Server 2003 or earlier then you most likely are still running FRS.  As of Windows 2008 GA DFSR became the new replication standard for Active Directory for new domain builds. 

There is a migration tool that is available that helps guide you through the process, but PLEASE test out in a lab before you apply in production.  Otherwise your production environment is just another test lab.

FRS to DFSR Migration Tool

Best of Luck 

Posted Monday, July 14, 2014 8:18 PM by Paul Bergson | 0 Comments

Filed under:

Can I Virtualize ALL My DC’s In the Domain?

With the advent of Windows Server 2012 R2, Microsoft has worked diligently to provide support for virtualization and allow corporations to reduce costs by virtualizing as much hardware as possible. New features in 2012 R2 help prevent USN rollback and/or Lingering objects via the new VM-Generation ID.  If a guest o/s is restored from a snapshot the VM-Generation Id that is stored in the DIT (msDS-GenerationID attribute on the DC's computer object) is compared to the value on the Host.  If they don't match then the Invocation-Id is updated with a new value and any RID's from the machine are replaced with a new set from the RID Master. 

So the question is, “Do I need a physical DC in my Domain?”

Microsoft has no requirements that at least one DC be physical. They do have a recommendation that there is at least one but this is to ensure that you always have access to the domain in the event the virtualization HOST is unavailable. If a site loses its virtual HOST then all guests on this HOST are unavailable including any DC’s. Virtualization and Active Directory Domain Services (ADDS) architects need to plan carefully to ensure that ADDS is always available at any site.

Having a physical DC at a site is to just ensure there is fault tolerance in the event a virtual DC fails there is a second one to continue to provide ADDS services. This physical DC protection can be handled by a two separate virtual (Hopefully clustered) HOST’s running on either separate virtual farms –or- using anti-affinity groups.

“Windows Server 2012 introduces an “anti-affinity” function so you can specify that two particular VMs shouldn’t run on the same host. This would defeat the benefits of guest clustering. VMM 2012 SP1 supports this, as well as extending this functionality to non-clustered, standalone hosts it also manages”

From: http://technet.microsoft.com/en-us/magazine/jj663520.aspx

So therein lies the risk.  Can you ensure that the virtual enterprise is always available similar to how it would be for a physical system? 
The article below calls out that you need to "Avoid Creating Single Points of Failure", in this Microsoft points to the fact that you need to ensure that you are controlling your guests to independent HOST hardware.  Below is guidance for your infrastructure for Server 2008/2008 R2, nothing has been released to cover Server 2012/2012 R2.

You should attempt to avoid creating potential single points of failure when you plan your virtual domain controller deployment. You can avoid introducing potential single points of failure by implementing system redundancy. For example, consider the following recommendations while keeping in mind the potential for increases in the cost of administration:

  1. Run at least two virtualized domain controllers per domain on different virtualization hosts, which reduces the risk of losing all domain controllers if a single virtualization host fails.

  2. As recommended for other technologies, diversify the hardware (using different CPUs, motherboards, network adapters, or other hardware) on which the domain controllers are running. Hardware diversification limits the damage that might be caused by a malfunction that is specific to a vendor configuration, a driver, or a single piece or type of hardware.

  3. If possible, domain controllers should be running on hardware that is located in different regions of the world. This helps to reduce the impact of a disaster or failure that affects a site at which the domain controllers are hosted.

  4. Maintain physical domain controllers in each of your domains. This mitigates the risk of a virtualization platform malfunction that affects all host systems that use that platform. 

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

One thing I find interesting is Microsoft is pushing to move to the cloud in a BIG way, Azure if you aren't aware.  If you have a solution that is completely in the cloud using Azure or one of its competitors there is no way to have a physical DC, unless of course you had a site-to-site VPN to an on premise DC infrastructure. Just another stone to examine as you try and look at all the options on what can be considered.

I have also heard folks talk about the PDCe should be a physical machine. My question is “Why”? The PDCe isn’t magical but the one thing that can make it different from other DC’s is that it can use from 2% - 12% more physical resources than other DC’s. So with that thought in mind, manage your platforms on your DC’s. If you are doing your due diligence on your platforms to ensure they aren’t being overloaded then it shouldn’t matter where your PDCe is running.

Thx to Bill Richardson for assistance 

Posted Saturday, July 12, 2014 4:42 PM by Paul Bergson | 0 Comments

ADMT Now Supports Server 2012/2012 R2

Great news the Directory Services team has released ADMT for Server 2012/2012 R2.


Posted Friday, June 13, 2014 10:40 AM by Paul Bergson | 0 Comments

Can't Add the Role "Active Directory Domain Services" to my 2008 R2 Server

Recently I was given a server in a rush situation to promote a new DC.  When I attempted to add the DC role the following error popped up

"Update DirectoryServices-DomainController of package DirectoryServices-DomainController-Package failed to be turned on. Status: 0x80070bc9."

This was perplexing as I had never run into this and the only details on the web were to rebuild this server.  Considering this was a newly built server I didn't believe it was something that required that type of drastic event.  So I decided to see what made this server different from my up and running DC's, first thing to check was the services running and what caught my eye almost immediately was the fact that the server service was disabled.  Obviously a DC needs this so I just went and enabled and re-attempted to add the role and "Bammmmmm" it worked as expected.

So if you run into this or other situations where you can't add a role to your server, verify the Server service is enabled and runinng.

Posted Tuesday, April 29, 2014 8:57 AM by Paul Bergson | 3 Comments

Export DNS Forwarders

If you have ever had to move or rebuild a DNS server and have a complicated forwarder list there is an easy way to export the list and then import them back into the new server and/or use this export for a new build.

  • open up regEdit
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones

From the menu select File and then Export.  Saving the file to a location that will be available for the new server.

Open up the newly exported files and clean up any zones you may not want to transfer, save and close it

Log onto the new server and open up regEdit then select File and Import.

Follow this by restarting the DNS server service

Bring up the DNS mmc console and you should now see the new zones.

Posted Monday, October 21, 2013 3:09 PM by Paul Bergson | 0 Comments

Inconsistent Membership of a Security Group

I ran across an issue the other day that had me scratching my head and calling PSS to try and track down the problem.

For some reason we had members of a security group that were inconsistently being denied access to RDP to our SQL servers.  There is a special group the SQL DB's belonged to which elevated them to Local Administrators on the box and this would also provide them the ability to RDP to the box.  We created a new security group and granted the exact same memberhsip and permissions to a test box and we couldn't get the permissions to fail, yet we continued to have the intermittent issues with our original group.

Running WireShark on the SQL box we could see where the proper connections were being sent and received, since originally we expected some type of Kerberos issue that we didn't see but we soon ruled that out.  Finally the Microsoft tech asked us to run a command within NTDSUtil I had never even known about before "Group Membership Evaluation".

Evaluate Group Membership will dump the contents of what groups for the user token to a text file and you can then look to see what the DC sees.  In this case we ran the command against each DC within the domain and sent the data off to Microsoft.  In the mean time I looked at each text file and found three DC's with a rather odd Group-Owner attribute on three different DC's.  The owner was a SID that couldn't be translated to a friendly name and looking closer I could see that the SID wasn't defined correctly, it had a corrupted value.  With this corruption also caused the evaluation of the group to quit showing the members within the group <DING, DING, DING>.  It couldn't evaluate who belonged to the group since the owner SID was corrupted.

I figured I would try and change the owner to a new administrative group and whah lah the group immediately exposed all the correct members within NTDSUtil.  I had the SQL DB's attempt to logon and it was still failing for them so I figured I would and reboot the box to correct any possible caching issue and upon this the problem went away.

When logged on the DC, open a CMD prompt
Type: group membership evaluation
Type: run "Domain FQDN" "User Name"

Output is a "Tab Seperated Value" (.tsv) file, so open in Excel and it will show you all the tokens associated with the security principal in nice order.

NTDSUtil and Group Membership Evaluation

Posted Thursday, September 26, 2013 8:17 AM by Paul Bergson | 0 Comments

Clean Up DCs SYSVOL FRS Member Object

If you have ever run dcDiag and ended up with the error output as follows:

      Starting test: VerifyEnterpriseReferences

         The following problems were found while verifying various important DN

         references.  Note, that  these problems can be reported because of

         latency in replication.  So follow up to resolve the following

         problems, only if the same problem is reported on all DCs for a given

         domain or if  the problem persists after replication has had

         reasonable time to replicate changes.

           [1] Problem: Missing Expected Value

             Base Object:

            CN=OLDDC,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=domainName,DC=loc

             Base Object Description: "SYSVOL FRS Member Object"

             Value Object Attribute Name: frsComputerReference

             Value Object Description: "DC Account Object"

             Recommended Action: Check if this server is deleted, and if so

            clean up this DCs SYSVOL FRS Member Object.  Also see Knowledge

            Base Article:  Q312862


            [2] Problem: Missing Expected Value

             Base Object:

            CN=OLDDC,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=domainName,DC=loc

             Base Object Description: "SYSVOL FRS Member Object"

             Value Object Attribute Name: serverReference

             Value Object Description: "DSA Object"

             Recommended Action: Check if this server is deleted, and if so

            clean up this DCs SYSVOL FRS Member Object.  Also see Knowledge

            Base Article  Q312862


         ......................... DC01 failed test VerifyEnterpriseReferences

This probably occured from a lost DC that was never fully cleaned up or some similar hoursekeeping task that doesn't cause any type of error generation on day to day tasks.

To clean this up you will want to bring up ADSIEdit and browse to the object and right click on it and delete it.  Obviously you will always want to get a backup in the event of some unknown issue.

Details from Microsoft that discuss this

Posted Monday, June 24, 2013 11:06 AM by Paul Bergson | 0 Comments

Unexplained dcDiag Errors

So I have been banging my head against a wall trying to figure out why I have been getting these crazy errors in dcDiag.  From all that I can tell replication is working as expected but yet I am getting errors that are mostly undocumented and difficult to find out any real information on.

Starting test: VerifyReplicas
            For the partition

            (DC=ForestDnsZones,DC=Domain,DC=COM) we encountered

            the following error retrieving the cross-ref's


               LDAP Error 0x52b (1323).
......................... DC-02 failed test VerifyReplicas

Starting test: VerifyEnterpriseReferences
   Can't determine the age of the cross-ref


   for the partition DC=ForestDnsZones,DC=Domain,DC=COM, so

   following errors relating to this cross-ref/partition may disappear

   after replication  coalesces.  Please ensure that replication is

   working from the Domain Naming FSMO to this DC, and retry this test to

   see if errors continue.
   Can't determine the age of the cross-ref
......................... DC-02 failed test VerifyEnterpriseReferences

Starting test: CutoffServers
   * Configuration Topology Aliveness Check
   * Analyzing the alive system replication topology for DC=ForestDnsZones,DC=Domain,DC=COM.
   * Performing upstream (of target) analysis.
   DsReplicaSyncAllW failed with error The naming context specified for this replication operation is invalid..
   * Performing downstream (of target) analysis.
   DsReplicaSyncAllW failed with error The naming context specified for this replication operation is invalid..
......................... DC-02 passed test CutoffServers


I went through and verified i was in the Domain Admins group, I verified that the Domain Admins security group had full permissions to the objects in error.  Did extensive research on the internet in a number of different Bing searches to try and come up with even a hint as to what the problem was.  Still nothing.  I posed the question to DS MVP colleagues and the one thing Jorge pointed out was this was some type of password issue related to the 0x52b error.  I had run across something on the internet as well related to password and had been why I checked into the permissions on the objects.

Finally a thought crossed my mind... I was using a trusted administrator user account from a User Forest, so out of desperation I logged on as a local admin.       BAM!!!!!!  All the errors went away.  So the password error was probably some how related, but I couldn't explain why...

Long story short - When running dcDiag always use a domain local admin account.

Posted Friday, June 14, 2013 1:23 PM by Paul Bergson | 0 Comments

How to Build an AD Replication Delay (Lag) Site

To prevent having to restore objects from Active Directory due to accidentally deleting an object, you can have a remote DC which only sends/receives replication on a limited basis.  You also want to prevent users from authenticating against, as well as services being used by other machines, since the metadata on this DC is aging away w/o replication keeping it up to date


Because of this you want to remove all advertised services via dns lookup.  To do this, this DC must be isolated from other DC’s and all replication controlled.  For that reason a separate site is required to control Intersite Replication.


The following are the steps taken to create a single lag site dc.  If you would like to have more than one time frame to fall back upon, all you need do is repeat these steps for a different DC.


  • Promote a member server to a DC and allow replication to complete
    • Don’t load any unnecessary services
    • Don’t load WINS nor make this a WINS client
  • Create a separate site and site link (I use “Lag” as part of the name to help document it)
    • Create a new site
    • Create a new site link, including the source and the Lag sites.  If you notice I have set the Site Link Replication Frequency (Replicate Every) to 15 minutes.


    • Click on the “Change Schedule” button to set the replication schedule to a time frame that fits for your enterprise.  In this example, I have set the replication schedule for Saturday morning from the hours of 12:00 am to 2:00 am.  So this site should allow replication updates to occur every 15 minutes, on Saturday’s, from the hours of 12:00 am until 2:00 am.  Once a replication cycle starts it will continue until complete, which can go beyond the 2:00 am time frame, but no new cycles will start after 2:00 am.


  • Define the subnet and link it to a site
    • Borrowing some knowledge from a blog from Brian Desmond, I have created a separate single host site sub-net.  I have reserved the address for the dc in dhcp (I reserved .240) and then defined the subnet as a /32 ip mask.  The most precisely defined subnet in sites and services is considered the subnet location.


  • Move the new dc to the newly defined site (Lag Site)

Now that the DC has been placed in its own site and is no longer receiving regular AD replication updates, it needs to no longer advertise itself as a usable DC.  To do this, a Group Policy Object will be created and linked to this new site.


  • Create a new GPO, but do not link it to any OU or Site at this time
  • Edit the Policy DC Locator DNS records not registered by the DCs.  This is located at Computer Configuration / Administrative Templates / System / Net Logon / DC Locator DNS Records.  The following mnemonics should be entered into the entry box:
    • Ldap LdapAtSite Pdc Gc GcAtSite GcIpAddress DcByGuid Kdc KdcAtSite Dc DcAtSite Rfc1510Kdc Rfc1510KdcAtSite GenericGc GenericGcAtSite Rfc1510UdpKdc Rfc1510Kpwd Rfc1510UdpKpwd
  • Link this new Group Policy to the “Lag” site, where the new DC resides
    • Change the policy to allow authenticated users to read and remove (Don’t deny) the right to apply
    • Add the computer name of the new DC and grant it Read and Apply.  This will help prevent the wrong DC’s from having policy applied against.
  • Shut down the new Lag site DC
    • Open up the dns zone _msdcs and remove all of the new DC’s dns service records
      • Do not remove the Alias (CNAME) record at the root of the zone
    • Power the DC backup
      • During the reboot any dns records that would be needed will be rebuilt

Run dcdiag, repadmin and dnslint in verbose mode.

  • DCDIAG /V /C /D /E /s:yourdcname > c:\dcdiag.log
  • repadmin.exe /showrepl dc* /verbose /all /intersite > c:\repl.txt
  • dnslint /ad /s  "ip address of your dc"


**Note 1: Using the /E switch in dcdiag will run diagnostics against ALL dc's in the forest.  If you have significant numbers of DC's this test could generate significant detail and take a long time.  You also want to take into account slow links to dc's which will also add to the time.


**Note 2: There are certain errors to expect, since the lag site DC won’t be advertising as a KDC you will be warned about this, etc…  But, replication should be error free.


**Note 3: Forced replication will still occur, this model only prevents scheduled replication.

Posted Tuesday, May 14, 2013 6:58 AM by Paul Bergson | 0 Comments

Upgrading AD from 2003 to 2008

Upgrading Active Directory from 2003 to 2008

--- (Note: This is a copy from another site and at this time my snapshots are missing)---

·        Microsoft’s Preupgrade check list

·        Before upgrading AD verify all current applications are compatible     

o   Verify you are on the correct version for 2008

§  For example, does your SAN at its current release support 2008

§  Does the version of Exchange you are running support 2008

o   Ensure all dc’s Windows 2000 dc’s are at least at SP4

§  From a command prompt run

Ø repadmin/showattr

·        Verify that your Active Directory forest is healthy

o   DCDIAG /V /C /D /E /s:yourdcname > c:\dcdiag.log

o   netdiag.exe /v > c:\netdiag.log (On each dc)

o   repadmin.exe /showrepl dc* /verbose /all /intersite > c:\repl.txt

o   ntfrsutl ds your_dc_name > c:\sysvol.log

o   dnslint /ad /s "ip address of your dc"

·        Get a backup up of at least two separate dc’s, including your PDCe

·        Although you can upgrade, I would strongly urge you to do fresh install on all new 2008 installations

o   Upgrading

§  Verify that the hardware will be compatible with 2008

§  You cannot directly upgrade from W2K to W2K8, you must go W2K to W2K3 and then W2K3 to W2K8

§  The bloat associated with patching, etc… just is a waste of space

Ø Verify you have plenty of disk space available

Ø If you don’t have a good 20gb of free space, you are probably going to run into space issues, trust me on this.  All future patches, etc… that roll into the o/s are kept in the system folder and slowly over time start to chew your volume.

§  verify that the machine upgrading holds the FSMO role of operations Master (Upgrade DC order)

o   Fresh install

§  Ensure you had at least a 50gb system partition

§  Consider using x64, all future Windows server operating systems are going to x64 bit, starting with 2008 R2

Prep the forest, domain and dns zones

·        Prep your forest

o   Copy the adprep folder to a local folder on your dc or run from the cd

o   Make sure that you can log on to the schema master with an account that has sufficient credentials to run adprep /forestprep. You must be a member of the Schema Admins group, the Enterprise Admins group, and the Domain Admins group of the domain that hosts the schema master, which is, by default, the forest root domain.

o   Execute adprep  (See KB753437, Be sure this is run on the Schema master, otherwise it will not run)

C:\adprep>adprep /forestprep 


Before running adprep, all Windows 2000 Active Directory Domain Controllers in the forest should be upgraded to Windows 2000 Service Pack 4 (SP4) or later.

[User Action]

If ALL your existing Windows 2000 Active Directory Domain Controllers meet this requirement, type C and then press ENTER to continue. Otherwise, type any other key and press ENTER to quit.


Opened Connection to DCTEST

SSPI Bind succeeded

Current Schema Version is 30

Upgrading schema to version 44

Connecting to "DCTEST"

Logging in as current user using SSPI

Importing directory from file "C:\WINDOWS\system32\sch31.ldf"

Loading entries............................................................................................................................................

139 entries modified successfully.


You should see multiple entries similar to above.  Just let the system spin and you can go take a break while waiting.  At the end you will see the following (Hopefully!).






Adprep successfully updated the forest-wide information.


o   Although this dc has completed the schema upgrade, you must wait until ALL dc’s in your forest receive this change via replication (Converge). 

§  Depending on your forest this could be in a few minutes to possibly days


·        Once the proper amount of time has passed, the domain’s should now also be ready to be prep’ped

o   If you would like to verify that the forest has been upgraded

§  Start up ADSIEdit

1.     Connect to Configuration / Configuration / ForestUpdates / ActiveDirectoryUpdate

1.     Right Click and select Properties

1.     Revision = 2

Ø Connect to Schema / Schema

        Right click and select properties

1.     ObjectVersion = 44

o   Adprep /domainprep    (Domain must be in Native Mode 2003)

§  Adprep /domainprep /gpprep  (Use this command line if upgrading from Windows 2000, Windows must be in Native Mode 2000)

C:\adprep>adprep /domainprep

Running domainprep ...

Adprep successfully updated the domain-wide information.

The new cross domain planning functionality for Group Policy, RSOP Planning Mode, requires file system and Active Directory Domain Services permissions to be updated for existing Group Policy Objects (GPOs). You can enable this functionality at any time by running "adprep.exe /domainprep /gpprep" on the Active Directory Domain Controller that holds the infrastructure operations master role.

This operation will cause all GPOs located in the policies folder of the SYSVOL to be replicated once between the AD DCs in this domain.  Microsoft recommends reading KB Q324392, particularly if you have a large number of Group policy Objects.

o   Although this dc has completed the domain prep upgrade, you must wait until ALL dc’s in this domain receive this change via replication (Converge). 

§  Depending on your domain this could be in a few minutes to possibly days


·        Once the proper amount of time has passed

o   If you would like to verify that the domain has been upgraded

§  Start up ADSIEdit

Ø Connect to Configuration / Configuration / ForestUpdates / ActiveDirectoryUpdate


·        If there are any near or far term plans to install RODC’s, prep your dns zones

o   Adprep /rodcprep

§  This will traverse through the separate partitions and update the permissions

Ø Verify that the prep completed without error

        Adprep completed without errors. All partitions are updated. See the ADPrep.log in directory C:\WINDOWS\debug\adprep\logs\yyyymmdd999999 for more information.

·        Prep your domain

o   Connect to the FSMO Infrastructure Master role holder

o   From the cd either copy the \sources\adprep or run the following:

§  Adprep /domainprep /gpprep


Begin the actual installation

·       New 2008 DC

o   Verify that the AD DS role has been installed on your 2008 member server

o   From an elevated command prompt promote this new DC

§  Dcpromo



·       The following will pop up



·       Followed by, Select Next



·       Read the description on new secure channel controls and verify that you understand its impact and then select next

o   KB942564 explains in greater details its impact within your organization



·       Select Existing Forest and click next



·       Verify the forest and credentials are properly set and click next



·       Select a domain for this additional domain controller and click next



·       Select the site where you would like the new dc to be placed in and click next



·       Select those additional services you would require this dc to have and click next



·       If the following pop up box appears



§  If you are installing an additional domain controller in either the forest root domain or a tree root domain, you do not have to create the DNS delegation. In this case, click Yes and disregard the message.


·       Verify the default locations are as expected and click Next



·       Enter the AD DS password and click Next



·       On the Summary dialog box, verify all settings are correct and hit Next



·       The following box will appear while the promotion advances.  Please be patient during this process, depending on the size of your AD environment this could take a few minutes to multiple hours.



·       Once the promotion is complete, click Finish and Restart the newly promoted dc






·       Once complete allow all DC’s to properly replicate all changes within the infrastructure

·       Microsoft recommends moving the FSMO roles to a 2008 DC

o   From Active Directory Users and Computers (ADUC) right click on the domain and select Operations Masters



o   From each of the three tabs (RID, PDC and Infrastructure) change to a 2008 DC



§  If your destination IM is also a GC, make sure all other dc’s are gc’s or that this is a single domain forest.  Otherwise you can create phantom object problems.

o   From Active Directory Domain and Trusts

§  Verify you are connected to the DC you want to transfer the Domain Naming role to

§  Right click and select Operations Manager



o   From Schema Management

§  If you haven’t already, register the schema management

·       From a command prompt

o   regsvr32 schmmgmt.dll

·       In the mmc console add the Schema management

·       Select the Schema management console and connect to the DC you want to move the FSMO role to

·       Right click on Schema management and Select operations Management



o   To verify all fsmo roles have been transferred run the following from a command prompt

§  Netdom query fsmo


Posted Thursday, April 25, 2013 6:53 AM by Paul Bergson | 0 Comments

Preventing Spoke DC’s from Advertising in the Hub Site for Authentication Availability

If you have a hub and spoke site topology, it may not be a good idea for certain (Or all) spoke dc’s to be advertising, via dns services, the ability to provide authentications services.  If you have a remote site with a dc that fails it is usually best that the spoke send its users to the hub for authentication purposes.  By default Active Directory (AD) doesn’t act this way.  If you would like set up your spokes to only advertised in its own site then you will want to configure a group policy (Windows 2003 and above) to prevent these spoke dc’s from advertising.  For machines running Windows 2000 you will need to do a reg hack (KB article defined later).

You will need to create a new group policy and define which DC’s will have read and apply policy.  Make sure to remove the authenticated users apply permission otherwise ALL dc’s will have this policy applied once it is link to the Domain Controllers ou.


·         Open up Group Policy Management and create a new Policy

·         Select this new Policy and click on the Delegation tab

o   Select the Advanced button

§  Remove the apply permission to the Authenticated users

§  Add each DC you would like to apply this policy to  and provide read and apply permissions

·         Right click on the policy and select Edit

o   Computer Configuration / Administrative Templates / System / Net Logon / DC Locator DNS records

§  Double click on DC Locator DNS records not registered by the DCs

·         Key in the Mnemonics below (Copy and paste)

DC DcByGuid Gc GcIpAddress GenericGC Kdc Ldap LdapIpAddress Rfc1510Kdc Rfc1510Kpwd Rfc1510UpdKdc Rfc1510UdpKpwd

·         See below for Mnemonics definitions



Wait for/or force replication and then from a command prompt on each dc in question key in the following:

·         Gpupdate /force

o   This will apply the new policy

·         Restart the NetLogon service (Or run netdiag /fix)

o   This will update the dns records.  Make sure when you check that you verify on the server this dc is attached to or wait for replication to take place.



The following table was taken from the KB article KB306602

Reference Tables

The following tables contain mnemonics, types, and the owner names of the domain controller locator DNS records that should not be registered by the satellite domain controllers and global catalogs to optimize the domain controller location.

Domain Controller-Specific Records

Collapse this tableExpand this table



DNS Record




























Global Catalog-Specific Records

Collapse this tableExpand this table



DNS Record










Posted Wednesday, January 02, 2013 2:21 PM by Paul Bergson | 1 Comments

How to Decommission a Domain Controller

Decommissioning a dc requires all domain services that currently reside on a server need to be moved to other dc’s. 


  • You need to move any fsmo roles from this dc to another dc (KB255960)
    • To learn where the roles reside run the command     netdom query fsmo
    • If the PDCe fsmo role resided on this DC then you need to reconfigure the new holder of the PDCe to either use the internal hardware clock or an external source.  I would recommend using an external source KB816042.
  • There needs to be at least one Global Catalog (GC) in each domain and it is recommended that there is one in each site (KB313994)
  • Move DNS services to other DC’s if this DC is a DNS provider.  Also point all clients that use this server for DNS to the new DNS server
    • If AD integrated simply installing DNS on a member server prior to promotion will bring up a new DNS server
    • If not AD integrated and this is a primary server then a new primary server will need to be brought online.  From DNS server manager the server needs to be promoted to primary
    • If a secondary server then make the new dc a new secondary server
  • If a dhcp server then the dhcp servers database needs to be backed up and copied to the new dhcp server.  The old dhcp server deauthorized and the new dhcp server authorized (KB325473)
  • If you have Encryption File System (EFS) enabled you will need to move the private key if it resides on this dc (KB241201).  You use the recovery agent's private key to recover data in situations when the copy of the EFS private key that is located on the local computer is lost
  • If this server manages Terminal Server Licensing (TSL) then it will have to be moved to a new DC.  From Add/Remove programs you will need to add a new TSL.  You can then restore the licenses by using the TS License Manager tool with the Telephone activation mechanism. You can switch to the Telephone mechanism by right clicking on the server in TS License Manager, and then selecting properties from the menu. (TS FAQ)
  • What about WINS
  • Check to see if your clients are using the ip address of this DC for DNS services, if so point the DNS clients to a new DNS server


Finally once this is all accomplished go ahead and demote the dc to a member server (KB238369)

Once the DC is demoted, as a final step you will need to go into Active Directory Sites and Services and manually remove the computer object from the site

Posted Wednesday, July 25, 2012 7:01 AM by Paul Bergson | 0 Comments

Create A Test Domain (Old Style)

This document was prepared for the building of a copy of the production Active Directory. Following these steps will define how to rebuild the entire Microsoft Active Directory for a test domain. *** Be careful ***

The first set of steps is to get a good pc into the production domain. Once this pc is a member it needs to be promoted and be a healthy participant in the network. The new DC then needs to be removed from the network before it is restarted (From its restore) to prevent any replication activity from damaging the production system. Reconnection to the production system will create major problems in the production system

1. Shutdown ALL pc’s within the test sub-net (For this document it will be 192.168.1.x, gateway =, mask =

2. Remove the physical cable for the new pc and build the member server (This all should reside within the test domain) in production

· Install DNS (AD Integrated needed for this document)

3. Re-connect the cable and join the Domain_Name.com domain

· Select the IP Address

· Select the mask to

· Select the Gateway

· Point the DNS services to a production AD DNS server

4. Promote the server to a Domain Controller (DC) via dcpromo.exe

5. Promote the server to a Global Catalog Server

6. Let the system sit idle (2 hours) for Replication to sync up

· Point the DNS services to itself

7. Open up a command prompt

· dcdiag /v /test:ridmanager

· Make sure no errors with the rid manager

· Create an object on the new DC

· Physically disconnect the cable

· Bring up “Active Directory Users and Computers”

· By disconnecting you force the system to attach locally

· Create a test user with the account disabled

· Reconnect the physical cable

8. At a command prompt type in NTBACKUP and do a system state backup saving the file to the local server

9. Demote this server to a member server with in the production domain (DCPROMO)

· Remove the NS record in the production environment

10. Physically disconnect the server from the network by unplugging the cable from the hub

11. Move the server to the test domain

12. Re-Promote once this system has been disconnected and the ip changed

· Dcpromo

· Domain Name = Domain_Name.com

· NetBios Name = NetBIOS_Name

· Allow the promotion to create the DNS domain

· Once this DC is brought online (The DNS services on the member server can be shut down), define it with Integrated Active Directory DNS and all name space records will be restored. Make sure to bring up DNS and select reload to refresh all data

· Active Directory Integrated

· Only Secure Updates

13. Reboot this server and After the POST Select F8

· Scroll down and select the option

“Directory Services Restore Mode (Windows 200x domain controllers only)”

14. Log on as the administrator (This is within the old SAM account)

15. Restore the System State from the previous NTBACKUP

16. Re-boot the Domain Controller (DC)

Now that the DC is restored it needs to take control of all Flexible Single Master Operation roles (FSMO and the File Replication service). Because of this utilities need to be loaded off of the Windows 200x install CD. NTDSUTIL will perform most of these steps. Since this is the first DC it needs to be a Global Catalog server and validate that it is the primary server in the domain.

17. After the POST Select F8

· Scroll down and select the option

“Directory Services Restore Mode (Windows 200x domain controllers only)”

18. Log on as the administrator (This is within the old SAM account)

19. Install the Windows 200x Active Directory Administration Tools from the server cd

· D:\i386\ Adminpak.msi

20. Install the Windows 200x Server Resource Kit from the server cd

· D:\support\tools\200xrkst.msi

21. Re-boot the Domain Controller (DC)

22. Log on as the administrator (This is with the AD account)

23. Reset the ip address to the test domain, the restore resets the ip address. Make sure to also point the dns server to itself as well

24. Set this server as a Global Catalog (Ignore this step in a multi-domain environment and this DC holds the Infrastructure Master Role)

· Click Start, click Run, type mmc, and then click OK

· On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Sites and Services, click Close, and then click OK

· Double Click Active Directory Sites and Services

· Double Click Sites

· Double Click MP-Default-Site

· Double Click Servers

· Double Click the DC

· Right Click on NTDS Settings and Select Properties

· If the “Global Catalog” check box is not checked, check it

25. All Flexible Single Master Operations (FSMO) roles need to reside on this DC

· Seize the PDC

· Click Start and then click Run

· In the Open text box, type ntdsutil

· Type roles

· Type connections

· Type connect to server <DC name>

· Type q

· Type seize pdc

· Click “Yes”

· Seize the Infrastructure master role

· Type seize infrastructure master

· Click “Yes”

· Seize the Domain Naming master role

· Type seize domain naming master

· Click “Yes”

· Seize the schema master role

· Type seize schema master

· Click “Yes”

· Seize the RID Master Role

· Type seize rid master

· Click “Yes”

· Type q

· Type q

26. Remove all other DC server objects (Repeat this step for each DC) KB216498

· Click Start and then click Run

· In the Open text box, type ntdsutil

· Type metadata cleanup

· Type connections

· Type connect to server <DC>

· Type q (The metadata cleanup prompt should now show)

· Type select operation target

· Type list domains (A list of domains should be displayed)

· Type select domain <#> (This is the domain of the server to be pruned)

· Type list sites (A list of sites should be displayed)

· Type select site <#> (This is the site of the server to be pruned)

· Type list servers in site (A list of servers should be displayed)

· Type select server <#> (This is the server to be pruned)

· Type q

· Type remove selected server (You should get confirmation of the removal)

· Type q

· Type q

27. Remove all other DC orphaned records in Active Directory (Repeat this step for each DC) KB216498

· Click Start - Programs - Windows 200x Support Tools - Tools - ADSI Edit

· Delete the computer account in OU=Domain Controllers, DC=Domain_Name,DC=com

· Delete the FRS member object in CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=Domain_Name,DC=com

28. Remove all other DC orphaned records in DNS

· Click Start - Programs - Administrative Tools - DNS

· Click <DC>.Domain_Name.com - Forward Lookup Zones - Domain_Name.com

· Delete the cname (alias) of all other DC’s

· Delete the a record of all other DC’s

29. This DC needs to be the File Replication Service Master (KB316790)

· Stop the File Replication service on the DC

· Make sure the following folders exist, if not create them

· C:\WINNT\SYSVOL\staging

· C:\WINNT\SYSVOL\sysvol (Share as SYSVOL)

· C:\WINNT\SYSVOL\sysvol\Domain_Name.com

· copy the contents of C:\WINNT\SYSVOL\domain to this folder

· Start Registry Editor (Regedt32.exe)

· Locate and then click the BurFlags value under the following key in the registry:

· HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

· On the Edit menu, click DWORD, click Hex, type D2, and then click OK

· Quit Registry Editor

· Restart the File Replication Service

· Check the FRS event viewer to see if the system states that the sysvol is now being shared and defines all the paths

30. Ensure that the DC has registered the proper computer role

· Enter net accounts at a dos prompt

· The computer role should say "primary”

Finally any information related to the old DC’s need to be purged from AD.

31. Re-boot the Authoritatively restored DC

32. Within the production system delete the test user and computer account

33. Within the production system delete the server object within the site that it was placed into for replication

Note: The File Replication Service can prevent the computer from becoming a Domain Controller (See below). If when doing a dcdiag a message states that the rid pool is corrupt, what is probably happening is there are problems with replication. Check the “File Replication Service” Event Log. Also make sure that all sub-folders are available within c:\winnt\sysvol.

To re-test just the rid pool: dcdiag /v test:ridmanager

Never again connect this server to the production system!!!

When you restore a domain controller from backup (or when you restore the System State), the FRS database is not restored because the most up-to-date state exists on a current replica instead of in the restored database. When FRS starts, it enters a "seeding" state and then tries to locate a replica with which it can synchronize. Until FRS completes replication, it cannot share Sysvol and Netlogon.

If you restore all of the domain controllers in the domain backup, all the domain controllers enter the seeding state for FRS and try to synchronize with an online replica. This replication does not occur because all of the domain controllers are in the same seeding state. Setting the primary domain controller FSMO role holder to be authoritative forces the domain controller to rebuild its database based on the current contents of the system volume. When that task is completed, the Sysvol and Netlogon shares are shared. All the other domain controllers can then start synchronizing from the online replica

(See - KB316790)

Posted Tuesday, July 03, 2012 5:04 PM by Paul Bergson | 0 Comments

Windows 2000/2003 Replication through a Firewall

Configuring Domain Controller Ports


To establish secure communications between DC’s defined and variable ports (High Ports) need to be able to communicate.  In the scenario defined below the internal dc’s have no outbound restrictions, inbound is restricted to a need to have with the restriction of 200 RPC ports are set for on demand need.


The following port definitions should be defined on ALL DC's within the DMZ that could be replicating to external DC’s.  These define which ports will be made available to there requesting DC's.


Start Registry Editor (Regedt32.exe).


Restrict FRS Traffic to a Specific Static Port - KB319553

Locate and then click the following key in the registry:


New     =          Reg_DWORD

Name   =          RPC TCP/IP Port Assignment

Value   =          10000              (Decimal)


Restricting AD replication traffic to a single port - KB224196

Locate and then click the following key in the registry:


New     =          REG_DWORD

Name   =          TCP/IP Port

Data     =          10001              (Decimal)


RPC dynamic port allocation - KB154596
     (Only allow ports 10002 - 10200 for RPC from other machines)


Locate and then click the following key in the registry:


Create a New Key = Internet

Locate and then click the following key in the registry:


Add the values

"Ports" (MULTI_SZ)                            =          10002-10200

"PortsInternetAvailable" (REG_SZ)       =          Y

"UseInternetPorts" (REG_SZ)               =          Y


Configure 2003 Firewall Ports – KB179442





RPC Connector Helper (Machines connect to find out what high port to use)




NetBIOS Name




NetBIOS Netlogon and Browsing




NetBIOS Session
























WINS Replication












SMB over IP (Microsoft-DS)













10002 –10200



RPC – Dynamic High Open Ports







If you would like to test connectivity to validate FRS communication

            NTFRSUTL version server_name

                        If the two can communicate through the firewall via FRS the response will provide the current version number


If you would like to validate connectivity between DC’s use the tool PortQryUI

            Download PortQryUI and run the tool

            Select the destination DC or PDC

            Select Domains and Trusts

                        Validate the ports that should be open in fact are via the output provided by the tool.

                                    For additional info on this tool see PortQry features, this is the backend tool for PortQryUI



Posted Tuesday, May 15, 2012 1:39 PM by Paul Bergson | 2 Comments

More Posts Next page »