Archive for the ‘Active Directory’ Category

Running Domain Controller on top of Hyper-V and Failover Cluster?

July 15, 2011

Generally this questions is currently a well discussed topic in my customer scenarios therefore I would like to cover the important points when talking about virtualized DCs and especially when Failover Clustering is involved.


Mainly the virtualization of DC roles are generally supported if you had understood the caveats. Generally in production environments you should NOT use “snapshot/save state” features for DCs especially in multi-DC deployment but also in single-DC. Reason even for Single-DC environments is that domain members does update their computer password frequently and which doesn’t match anymore when you apply an previous snapshot (please see KB175468 around machine password). Of course, there are some workarounds but from my perspective none of them apply in production environments.

If you read the below articles and you are aware what exactly to overlook, “Yes you can” use this feature in lab scenarios, like you must snapshot all domain members at the same time or reset computer password after applying an earlier DC snapshot. But GENERALLY YOU SHOULD (NEVER) NOT USE SNAPSHOT/SAVE STATE FUNCTION IN PRODUCTION for DC role(s)!

So when running a domain controller within a Hyper-V virtual machine do NOT use:

1. Save states OR,
2. Virtual machine snapshots

In Hyper-V deployments there are some general “considerations” which need to overlooked when deploying virtualized domain controllers, here are some great articles which covers this in detail and gives also some guidelines:

Running Domain Controllers in Hyper-V

Things to consider when you host Active Directory domain controllers in virtual hosting environments

Considerations when hosting Active Directory domain controller in virtual hosting environments

The Domain Controller Dilemma

Problems with virtual machines and domain membership

Hyper-V and Domain Controllers – Demo Tips and Tricks

Effects of machine account replication on a domain

Running Domain Controllers within Virtual Server 2005

Failover Cluster:

Especially in Failover Cluster environments it is a “best practice” and recommended to have at least 1 physical/virtual DC available which is outside of the cluster environment as cluster service does require DC communication before starting cluster service (VCO/CNO).

Checkout the following blog post from my MVP colleague – Lai Yoong Seng MVP Virtual Machine – which discusses arising issues, when putting your DCs on top of Failover Cluster:

We call this “Henne und Ei Problem” in German where translation has the same sense “Chicken and Egg IssueSmile

Windows 2003 MSCS:

Determining Domain Controller Access for Server Clusters (Windows 2003)

Active Directory, DNS and Domain Controllers (Windows 2003)

Cluster Networking Requirements (Windows 2003)

Stay tuned…. Winking smile




Understanding Domain and Forest Level’s in Windows Server environment

March 11, 2010

Microsoft has since active directory publication (2000) different domain and forest level’s published. They generally follow the windows server edition’s like 2000, 2003 and now 200´8 (R2). Each level has his own feature set and compatibility requirements on domain controller side. For some applications which are active directory integrated like Exchange it is really important to have the right configuration in your active directory environment.

How Active Directory Functional Levels Work

Active Directory Functional Levels Technical Reference

What Are Active Directory Functional Levels?

Exchange 2007 System Requirements

Exchange 2010 System Requirements



NTDSUTIL – Mounting Snapshots

December 11, 2009

What a great tool – NTDSUTIL !

Just an example here with snapshots and mounting these :


image image

As you can see a shadow of the whole C:\ drive is mounted under root $SNAP_xxx As this is sooo easy I’m also using this sometimes for a fast backup and restore scenario 😉 Here I need the "C:\Temp” folder from the first snapshot 🙂

Unmounting the snapshots :


Broader documentation around “ntdsutil” can be found at Technet :

Read the next article for mounting these snapshots as an active directory instance for attribute restore scenarios

DCPROMO – Unattended Installation

December 7, 2009

Here is an sample dc.ini from which you can setup your own unattended file for automated installation of an domain controller and or DNS.

This is an example for adding an DC to an already existing forest :

; Run-time flags (optional)
; CriticalReplicationOnly=Yes
; RebootOnCompletion=Yes

dcpromo command syntax :

dcpromo /unattend:dc.ini

These scenario works with Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2008.

More information about additional switches can be found here :

Active Directory Logging

November 18, 2006

Möchte man die Protokollierung auf einem DC was das Active Directory betrifft erhöhen, so kann man dies in der Registry des DCs einstellen. Der Registry-Schlüssel wäre: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.

Hier können für einzelne Bereiche die Protokollierung angepasst (erhöht) werden, über die genauer protokolliert werden soll.

Es stehen folgende Ereignistypen für Windows Server 2000/2003 zur Verfügung:

  1. Knowledge Consistency Checker (KCC)
  2. Security Events
  3. ExDS Interface Events
  4. MAPI Interface Events
  5. Replication Events
  6. Garbage Collection
  7. Internal Configuration
  8. Directory Access
  9. Internal Processing
  10. Performance Counters
  11. Initialization/Termination
  12. Service Control
  13. Name Resolution
  14. Backup
  15. Field Engineering
  16. LDAP Interface Events
  17. Setup
  18. Global Catalog
  19. Inter-site Messaging
  20. Nur für Windows Server 2003 noch weitere:
  21. Group Caching
  22. Linked-Value Replication
  23. DS RPC Client
  24. DS RPC Server
  25. DS Schema

Jeder dieser Ereignistypen, stellt ein REG_DWORD-Wert dar und haben alle als eingestellten Wert „0“ eingetragen.

Durch die Erhöhung dieses Wertes, kann die Protokollierung detaillierter stattfinden, aber Vorsicht, zu viele Einstellungen (z.B. man aktiviert auf allen Typen den höchsten Wert), kann den DC Performancetechnisch in die Knie zwingen. Daher sollte die vorgenommene Einstellung auch wieder rückgängig gemacht werden, wenn es nicht mehr benötigt wird.

Es stehen sechs Stufen (0-5) zur Verfügung:

0 (None) = In dieser Stufe werden ausschließliche kritische Fehler protokolliert. Dies ist die Standardeinstellung für alle Ereignistypen, die nur geändert werden sollte, wenn Probleme bestehen.

1 (Minimal) = Bei dieser minimalen Einstellung werden auch die etwas weniger kritischen Ereignisse protokolliert. Wenn man nicht weiß, wo genau das Problem besteht, sollte mit dieser Einstellung, dass Troubleshooting begonnen werden.

Alleine in dieser Stufe, werden bereits deutlich mehr Ereignisse in der Ereignisanzeige verzeichnet, daher sollte genauestens überprüft werden, ob diese Stufe für die Problemsuche ausreicht bevor man „erhöht“.

2 (Basic) = Diese Stufe erhöht die Protokollierung noch etwas. Falls Stufe 1 nicht ausreicht, sollte – ganz nach dem Motto „Schritt für Schritt“ – diese Stufe angewendet werden.

3 (Extensive) = In dieser Stufe werden alle Schritte der einzelnen Aufgaben im Active Directory detailliert protokolliert. Hier wird schon sehr viel protokolliert, im Gegensatz zu den Stufen 0 bis 2. Ab der Stufe 3 wird auch der Server durch die starke Protokollierung extrem belastet, daher sollten leistungsfähige Maschinen zur Verfügung stehen. Die Stufen 0-2 reichen für die Fehlerbehebung im Active Directory normalerweise aus.

4 (Verbose) = Bei dieser Stufe wird der Protokollierungsgrad noch weiter erhöht, als die Stufe 3. Allerdings ist die Steigerung der Protokollierung nicht so hoch, als bei der Erhöhung von der Stufe 2 zu 3.

5 (Internal) = Das ist die höchste Stufe, die man einstellen kann. In dieser Stufe werden alle Informationen in das Ereignisprotokoll geschrieben, die das Active Directory protokollieren kann. Diese Stufe sollte nur für wenige Ereignistypen gleichzeitig eingestellt werden, denn ansonsten wird es sehr schnell unübersichtlich in der Ereignisanzeige.

Es können noch bei weiteren Diensten eine höhere Protokollierung aktiviert werden, z.B. für:

NTFRS Diagnostic Logging


Mit dieser Einstellung, wird ein Debug Log im Verzeichnis: „%windir%\debug\NtFrs_0000n.log“ erstellt (ebenfalls mit den Stufen 0-5).

Die beiden Tools DCDIAG und NetDIAG aus den Windows Support Tools (die sich auf der Windows Server 2003 CD im Ordner Support befindet), sind bei der Fehlersuche ebenfalls behilflich.

„DCDIAG /v“ und „NetDIAG /v“ sollten zur Diagnose herangezogen werden.

Für die Auswertung des DCDIAGs, hatte ich hier einen Artikel geschrieben:

Für weitere Log-Möglichkeiten siehe diese Links:

Quelle : Yusuf’s Directory Blog)

Active Directory Replikation durch die Firewall ?!

November 18, 2006

Sofern es notwendig wird, dass Domänencontroller durch eine Firewall miteinander kommunizieren (replizieren) müssen, sollten folgende Dienste mit ihren entsprechenden Ports und Protokollen zu den Domänencontrollern durchgeleitet werden:


  • RPC: 135 TCP und UDP
  • Network Basic Input/Output System (NetBIOS) name service: 137 TCP und UDP, 138 UDP und 139 TCP
  • Dynamische RPC Portzuweisung: 1024-65535 TCP
  • Server Message Block (SMB) über IP / Microsoft-DS: 445 TCP und UDP
  • Lightweight Directory Access Protocol (LDAP): 389 TCP und UDP
  • LDAP über SSL: 636 TCP
  • Globaler Katalog (GC) LDAP: 3268 TCP
  • Globaler Katalog LDAP über SSL: 3269 TCP
  • Kerberos: 88 TCP und UDP
  • Domain Name Service (DNS): 53 TCP und UDP
  • Windows Internet Name Service (WINS): 1512 TCP und UDP
  • WINS Replikation (falls benötigt): 42 TCP und UDP

Dem aufmerksamen Administrator fällt nun auf, dass die „dynamische RPC Portzuweisung“ ein Problem darstellen könnte. In der Tat, möchte man nicht die Ports von 1024 bis 65535 öffnen, deshalb ist es ratsam zu prüfen, welche Ports an der Firewall geblockt werden, um nach und nach die Ports freizugeben und nicht alle auf einmal. Abgesehen davon, lieber einen Port zu wenig aufgemacht, als einen zuviel. Deshalb muss jedes Unternehmen vor dem öffnen der Ports genauestens prüfen, welche Ports für welche Active Directory Aufgaben notwendig sind.

Den meisten Verkehr durch eine Firewall, verursachen die Authentifizierungsanforderungen, als die wären:

  • Dateiserverzugriff
  • DNS Abfragen
  • Vertrauensstellungen
  • Benutzeranmeldung
  • Verbindung zwischen Mitgliedsservern und Domänencontrollern
  • Active Directory Replikation

Falls Memberserver wie z.B. Windows Exchange im Perimeter-Netzwerk, Verbindung mit dem internen Netzwerk haben sollen, ist es empfehlenswert die notwendigen Protokolle und Ports (für das Active Directory sowie die benötigten Dienste) von der jeweiligen IP-Adresse zum jeweiligen Domänencontroller auf der Firewall zu beschränken. 

Wenn Standorte (Niederlassungen) und somit ggf. Subdomänen erstellt werden, sind weitere Regeln auf der Firewall zu erstellen, um die Vertrauensstellung sowie Active Directory Replikation zuzulassen.

Weitere Informationen:
Active Directory Replication over Firewalls

Active Directory in Networks Segmented by Firewalls

How to configure a firewall for domains and trusts

Restricting Active Directory replication traffic to a specific port

Service overview and network port requirements for the Windows Server system

TechNet Webcast: Kerberos-Interoperabilität – Authentifizierungstickets für heterogene Clients

USN Rollbacks and Active Directory Replication Issues

November 18, 2006

I recently worked on an interesting issue where certain Distribution Groups (DGs) in the Active Directory (AD) were not replicating properly with the Exchange 5.5 Directory Service (DS). After adding several members to a DG in the AD, the changes did not replicate to the 5.5 server. One particularly problematic DG, lets call it Execs, had 58 members in AD and only 23 in the 5.5 DS, even after several replication cycles. Previously, we had gone through the basics of Active Directory Connector (ADC) troubleshooting, some of which are listed in 253841, but the problem still persisted. After weeks of spinning our wheels we decided to examine more closely the Update Sequence Numbers (USNs) of the problem DG.

Before adding another member in AD, we checked the USNCreated and USNChanged values and found the following:

USNCreated: 345530

USNChanged: 11240563

Nothing particularly strange so far. After adding another member on the AD side the values had changed to:

USNCreated: 307801

USNChanged: 3438089

The first odd thing I noticed was that the values decreased! What was happening here? This is really weird because under normal circumstances 1) USNCreated does not change and 2) the USNChanged increments and usually only by a bit (although on busier servers it may increment by more – but you can still tell that the new number is part of the same sequence). For instance, in my test environment, with a single Exchange server and a single Global Catalog (GC), adding a member to a DG causes the USNChanged to increment by at most 2 or 3.  What was even more surprising was that after making this one change, the DG’s membership successfully replicated to the 5.5 DS. We decided this was probably just luck. We had previously added members to this same DG and it did not replicate. I think the difference this time was the choice of Domain Controller (DC) that we made changes on. Before making the DG change the msExchangeServer1HighestUSNVector looked like this (see footnote section)

"OURDCA: 5225033"

"OURDCB: 11333798"

"OURDCC: 11269307"

"OURDCD: 3039867" <<—– DC we made changes on

"OURDCE: 72170045"

"OURDCW: 11316411"

"OURDCX: 22501269"

"OURDCY: 6993025"

"OURDCZ: 21918680"

After adding a member to Execs, its USNchanged was now 3438089, higher than 3039867, and so the next time the ADC polled the AD the changes replicated to Exchange 5.5. I speculated, given the USNChanged for Execs before adding the member (11240563), that the DC responsible for replicating the change to the 5.5 directory was one of the following:

"OURDCB: 11333798"

"OURDCC: 11269307"

"OURDCW: 11316411"

because they seemed to have sequences in the same range as Execs. I also speculated that since their USNs were all higher than 11240563, Execs was not going to replicate to 5.5 until its USN exceeded the high water mark for one of these 3 DCs. Graham McIntyre, our resident ADC guru, thinks the problem was that changes to the DG were not making it to the AD bridgehead which is the endpoint for the connection agreement responsible for the DG.

But I still wondered why the USNChanged and USNCreated got reset on OURDCD and so I took a flight of stairs down to talk to our Active Directory folks (Exchange runs on top of windows, so naturally we sit a floor above the windows Active Directory team :))  They told me that one possible cause of this is a USN Rollback, an occurence that they have seen a few times recently. USN rollbacks are described in detail in article 875495 and there are 2 ways to detect them:

  1. Applying the fix described in the article and looking out for the listed 2095, 1113, 1115 and 2103 events.
  1. Running repadmin /showutdvec * dc=<domain name>,dc=<domain suffix> and then looking at the output to determine if for any given DC A, some other remote DC B has a higher watermark USN for A than A has for itself. (If the difference in USN is only slight it could be a timing issue rather than a rollback — i.e. repadmin ran on A first, its high water mark USN incremented, the changes replicated to B and then repadmin ran on B)

Ultimately, option 1 was going to be hard to justify because our customer had a rigorous change control process they follow before applying a fix. Most enterprise customers do, even for fixes that are known to definitively solve a specific problem (and this fix was only going to detect a problem we thought the customer might have). That left us with option 2. Unfortunately, with 44 DCs, going through the repadmin command output was going to be more difficult to go through (44 x 44) than the simple example in the article:

Repadmin /showutdvec dc1 dc=contoso,dc=com

Site1\DC1 @ USN 10 @ Time 2004-08-04 15:07:15
Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59

Repadmin /showutdvec dc2 dc=contoso,dc=com
Site1\DC1 @ USN 50 @ Time 2004-08-04 15:07:15
Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59

where DC1 has clearly experienced a rollback since DC2 has a higher USN for DC1 (50) than DC1 has for itself. (10). Like a good boy scout, I wrote a Perl script,, to parse the output and detect possible rollbacks. Running the script showed several entries that looked like this:

———- rollback —————–

DC OURDCD may have experienced a USN rollback. It’s Self Highest USN = 8280087 but the remote DC OURDCA has a USN = 8288138 for OURDCD that is higher than what OURDCD has for itself

———- rollback —————–

DC OURDCD may have experienced a USN rollback. It’s Self Highest USN = 8280087 but the remote DC OURDCB has a USN = 8290610 for OURDCD that is higher than what OURDCD has for itself

We had indeed made our change to Execs on OURDCD. According to the article, the most common sources of USN rollbacks are:

  1. Virtualized Hosting Environments, including but not limited to Microsoft Virtual Server 2005 and EMC VMWARE
  2. Software that backs up and restores an Active Directory operating system installation or a hard disk volume that contains the installation (including but not limited to Norton Ghost)
  3. Advanced disk subsystems that can selectively copy a volume that contains an Active Directory operating system installation that was saved in the past

On further questioning the customer said they may have done a system state restore on OURDCD because it had experienced ‘hardware issues’. The article further states that there are only 2 ways to recover from a rollback.

  1. Use the Active Directory Installation Wizard (dcpromo.exe) to remove and then reinstall Active Directory (If you are not interested in the changes made on the problem DC)
  2. Restore the system state from a good recent backup using a supported method.

Our customer decided to dcpromo down OURDCD and then promote it back to a DC and since then they have not experienced DG replication issues.

This customer’s rollback manifested as an ADC replication issue but broken AD replication can affect Exchange in numerous ways. In fact, to say that Exchange relies on AD is to grossly understate it. The moral of the story is, you should avoid doing any of the listed things that can cause a USN rollback.


For those not familiar with msExchServer1HighestUSNVector, it is an attribute that the ADC uses to store the high-watermark USN for every DC with which it replicates. The ADC periodically polls the AD for objects with higher USNs than the last highest USN that successfully replicated with the 5.5 DS and replicates the new changes. There is a corresponding msExchServer2HighestUSNVector that is used to track replication changes from Exchange 5.5 to the AD. The exact mechanics of this process are described in article 253840.

Published Tuesday, November 29, 2005 7:01 PM by jasperk