Der Unterschied zwischen einer beschreibbaren und nur lesbaren Verzeichnispartition (auf Englisch Naming Context, kurz NC) liegt im Attribut instanceType. Dieses Attribut besteht aus einer Bitmaske und existiert in den Eigenschaften jeder Verzeichnispartition. Ist das dritte Bit (Hex = 0x4; Dezimal = 4) im Attribut instanceType, in den Eigenschaften einer Verzeichnispartition auf einem DC gesetzt, so ist die Verzeichnispartition auf diesem DC beschreibbar. Falls das dritte Bit nicht gesetzt ist, ist die Verzeichnispartition auf diesem DC nur lesbar.

Da ein Read-Only Domänencontroller (RODC) nur einen lesenden Zugriff auf die Active Directory-Datenbank (NTDS.DIT) und somit auf alle Verzeichnispartitionen hat, ist logischerweise in allen Verzeichnispartitionen die sich auf einem RODC befinden das dritte Bit in instanceType nicht gesetzt!

Auch in den fremden Domänenpartitionen die sich im globalen Katalog befinden, ist das dritte Bit in instanceType nicht gesetzt!

Überprüfen kann man das mit dem Schweizer Messer Werkzeug für die AD-Replikation Repadmin. Führt man den Befehl Repadmin /showrepl /verbose in der Kommandozeile aus, erhält man solch eine Ausgabe:

In der Ausgabe werden alle Verzeichnispartitionen aufgelistet, die der DC repliziert. Die Verzeichnispartitionen in denen der DC das Schreibrecht besitzt, sind mit WRITEABLE gekennzeichnet. Die Verzeichnispartitionen in der der DC lediglich das Leserecht besitzt, sind nicht mit WRITEABLE gekennzeichnet.

Ob eine Verzeichnispartition auf einem bestimmten DC nur lesbar oder beschreibbar ist, kann man mit dem folgenden AD-PowerShellskript überprüfen:

######################################################
#
# AD-PowerShellskript zum überprüfen ob eine Verzeichnispartition
# nur lesbar oder beschreibbar ist.
#
# Von: Yusuf Dikmenoglu 05/2011
#
# http://blog.dikmenoglu.de
#
######################################################


# Hier den distinguishedName der entsprechenden Verzeichnispartition (= NC = Naming Context) angegeben

$searchbase = "DC=ad2008R2,DC=dikmenoglu,DC=de"

# Wenn man einen NC von einem globalen Katalog (GC) abfragen möchte, muss man bei "-Server" den FQDN 
# des DCs und den GC-Port angeben. Also: "R2DCON01.ad2008R2.dikmenoglu.de:3268"

Get-ADObject -Server R2DCON01 -LDAPFilter "(instanceType=*)"  -SearchBase $Searchbase -SearchScope base -Properties instanceType | ForEach-Object {
      if ($_.instanceType -band 4){
            write-host $_.ncName "Beschreibbare Verzeichnispartition: $Searchbase"
      }
      else{
            write-host $_.ncName "Lesbare Verzeichnispartition: $Searchbase"
      }
}

Weitere Informationen:
Welche Verzeichnispartitionen befinden sich auf einem DC?
Instance-Type Attribute
Read-Only Domain Controller (RODC)

Hin und wieder kommt es vor, dass man den Benutzeranmeldenamen mehrerer Domänen-Benutzer ändern muss. Da sich die Domänen-Benutzer mit dem „Benutzeranmeldenamen“ oder mit dem „Benutzeranmeldenamen (Prä-Windows 2000)“ anmelden können, müssen beim ändern des Benutzeranmeldenamen die Werte in den beiden Attributen userPrincipalName (kurz, UPN) und sAMAccountName geändert werden. Bei wenigen Benutzern lassen diese sich recht einfach händisch ändern. Doch wie sieht es mit hunderten oder >1.000 Benutzern aus?!

Diese Aufgabe lässt sich einfach und State of the Art mit Excel und der AD-PowerShell lösen! Die Basisdaten kann man sich recht simpel in eine CSV-Datei, die sich wiederum in Excel importieren lässt, aus dem AD exportieren. Dazu eignen sich CSVDE und die AD-PowerShell. Wie man einen Export (und Import) mit CSVDE oder der AD-PowerShell durchführen kann, zeigt dieser Artikel:

######################################################
#
# AD-PowerShell Skript zum umbenennen von AD-Benutzer.
# Mit diesem Skript wird der sAMAccountName, userPrincipalName
# und das Attribut name umbenannt
#
# Von: Yusuf Dikmenoglu 04/2011
#
# http://blog.dikmenoglu.de
#
######################################################



clear

# Excel Einstellungen
$excel = New-Object -ComObject Excel.Application # create base object 
$excel.visible = $false
$wb = $excel.workbooks.open("C:\Tools\Benutzernamen.xls")
$ws1 = $wb.Worksheets.item(1)  

# Programmbeginn
$count = 5
for ($index = 2; $index -lt $count; $index++) {
    Write-Host $index
    $loginAlt = $ws1.Cells.Item($index,6).text.trim()
    $loginNeu = $ws1.Cells.Item($index,10).text.trim()
    $aduser = Get-ADUser $loginAlt | ForEach-Object {
        $ws1.Cells.Item($index,4) = $_.givenname   
        $ws1.Cells.Item($index,3) = $_.surname
        $pricipalname = $loginNeu + "@Domäne.de"
        Set-ADUser -Identity $loginAlt -SamAccountName $loginNeu -UserPrincipalName $pricipalname
        Rename-ADObject -Identity $loginAlt -NewName $loginNeu     # Funktioniert nur, wenn das Attribut "name" gleich "sAMAccountName" ist
        
    }
}

$wb.save()
$wb.Close()
$excel.Quit()

Die Remote Server Administration Tools, kurz RSAT, für Windows 7 Service Pack 1 sind Released-To-Web (RTW)

Wenn man unter Windows 7 Service Pack 1 versucht das bisherige RSAT zu installieren, erhält man diese Fehlermeldung:

Error message when installing RSAT: 'This update is not applicable to your computer'

Hin und wieder kommen Administratoren auf die scheinbar glorreiche Idee, Domänencontroller (DC) zwecks der Ausfallsicherheit Clustern zu wollen. Zuerst einmal ist es lobenswert, dass sich Administratoren Gedanken über die Ausfallsicherheit von DCs machen. Schließlich sind DCs das Herz einer jeden AD Domäne und diese soll auch bei einem DC-Ausfall weiter funktionieren, möglichst ohne das Backup bemühen zu müssen.

Jedoch lässt sich technisch die DC-Funktionalität gar nicht Clustern. Die DC-Funktion ist nicht clusterfähig (cluster-aware)! Das muss sie aber auch nicht, da DCs die das „Active Directory“ (AD) bereitstellen über einen anderen Mechanismus redundant gehalten werden. Dieser Mechanismus ist die „AD-Replikation“.

Die hohe Verfügbarkeit sowie Ausfallsicherheit der DC-Funktionalität wird alleine durch den Einsatz von mehr als einem DC gewährleistet! Denn existieren in einer Domäne mehr als ein DC, replizieren sich die DCs die AD-Datenbank untereinander. Da DCs stets online sind, wird die Ausfallsicherheit und hohe Verfügbarkeit bereits durch die AD-Replikation und ohne einen Cluster zu bilden erreicht.

Setzt man Password Setting Objects (kurz PSOs) auch bekannt als fein abgestimmte Kennwortrichtlinien ein, kann es zu Verwirrungen bei der Meldung die Windows liefert kommen, wenn ein Benutzer ein Kennwort vergeben möchte das nicht den Vorgaben des ihm zugewiesenen PSO entspricht.

Welche Voraussetzungen existieren müssen damit PSOs eingesetzt werden können oder wie PSOs konfiguriert werden, steht neben weiteren Details im folgenden Artikel:

Password Setting Objects erstellen und verwalten