Es ist wirklich gigantisch wie viele Mails ich in letzter Zeit erhalten habe, was denn los wäre und warum ich mit meinen Blogeinträgen aufgehört hätte.

Deshalb vorweg hier ein paar Antworten auf Mails die ich erhalten habe: Mir geht es zum Glück gesundheitlich gut. Nein, ich habe weder das Land, noch diesen Planeten verlassen. Nein, auch das Schreiben an einen TV-Sender für die Sendung „Bitte melde dich“ ist nicht notwendig. Ja, ich bin weiterhin in der IT-Branche tätig. Nein, ich muss mich auch nicht verstecken.

Aber was ist passiert?

Wie ihr wisst können sich manchmal privat und/oder beruflich Situationen ergeben, die höchste Aufmerksamkeit und vor allem viel Zeit verlangen und dadurch die Internetaktivitäten (bei mir Blogartikel schreiben und in Foren teilnehmen) vorübergehend ausgesetzt werden müssen. So wie auch bei mir.

Zum einen habe ich mich zum 01.06.2011 beruflich verändert! Nach 10 Jahren bei meinem letzten Arbeitgeber wollte ich neue Aufgaben und neue Herausforderungen haben, um mich mit vollem Elan weiter nach vorne zu entwickeln.

Seit dem 01.06.2011 bin ich bei Microsoft Deutschland GmbH als Premier Field Engineer (PFE) – Active Directory am Standort „Bad Homburg“ mit viel Freude tätig! An dieser Stelle möchte ich alle meine PFE – Kolleginnen und Kollegen grüßen. :-)

Aber die berufliche Veränderung ist noch nicht genug! Zum anderen bzw. zeitgleich oder kurz vor meinem Jobwechsel haben sich meine bessere Hälfte und ich dazu entschieden, ein Massivhaus zu bauen. Das hatte mir monatelange schlaflose Nächte bereitet! Jobwechsel und Hausbau zur gleichen Zeit? Und das wo ich doch gerade der Sicherheitsmensch bin. Unser jetziges Haus muss schließlich auch noch so nebenbei verkauft werden. :-/

Aber letzten Endes haben wir uns gemeinsam dazu entschieden, beides zu tun. Die vielen Gespräche mit der Familie, Freunden, Microsoft-Freunden haben alle dazu beigetragen, diesen Schritt zu gehen. Wie heißt es so schön: No risk – no fun. ;-) Spatenstich ist in ca. zwei Wochen.

Man liest und ab sofort trifft man sich auch im Berufsleben!

Active Directory (AD) basierte Gruppenrichtlinienobjekte (auf Englisch: Group Policy Object, kurz GPO) bestehen hauptsächlich aus zwei Komponenten, bestehend aus der logischen und physikalischen Struktur. Der logische Teil einer GPO wird in der AD-Datenbank (NTDS.dit) gespeichert und wird als Gruppenrichtliniencontainer (auf Englisch: Group Policy Container, kurz GPC) bezeichnet. Die physikalische Komponente einer GPO wird im Dateisystem, im replizierten Verzeichnis SYSVOL gespeichert und lautet Gruppenrichtlinienvorlage (auf Englisch: Group Policy Template, kurz GPT).

In den Eigenschaften eines GPC werden alle AD relevanten Konfigurationsdaten einer GPO gespeichert, wie beispielsweise der Pfad zur Gruppenrichtlinienvorlage (das Attribut gPCFileSysPath im entsprechenden GPC , also der Pfad zum GPT), der Status von Gruppenrichtlinienobjekten (das Attribut flags ) oder die Zugriffsteuerungsliste (Access Control List, kurz ACL) die bestimmt, welcher Benutzer bzw. Gruppe die Einstellungen eines GPOs verwalten darf. Den GPC selbst findet man in der Domänenpartition im Container CN=Policies,CN=System,DC=<Domäne> . Diesen Container kann man in der MMC Active Directory-Benutzer und –Computer (dsa.msc) zum Vorschein bringen. Dazu muss man jedoch zuerst in der MMC dsa.msc unter Ansicht die „Erweiterte Features“ aktivieren. Die GPC werden im AD-Container Policies mit ihrer {GUID} dargestellt und ist derselbe, wie er auch im GPT angezeigt wird.

Im GPT befinden sich die meisten Einstellungen eines GPOs sowie verschiedene Verzeichnisse und Konfigurationsdateien. Im GPT werden also alle aktuellen GPO-Einstellungen eines GPOs gespeichert. Die GPTs werden im Dateisystem tatsächlich unter %windir%\SYSVOL\domain\Policies , jeweils dargestellt mit ihrer {GUID} , gespeichert. Nicht zu verwechseln mit den Junction Points unter %windir%\SYSVOL\sysvol\<Domäne>\Policies . Tools für die Verwaltung von GPOs (z.B. die GPMC) verwenden die Junction Points und nicht den echten Speicherort der GPTs.

Wichtig für das Troubleshooting ist zu wissen, dass die hauptsächlichen Komponenten einer GPO, nämlich der GPC und das GPT, auf unterschiedliche Weise repliziert werden. Der GPC wird im Rahmen der AD-Replikation repliziert. Das GPT wird je nach Domänenfunktionsmodus entweder vom FRS (File Replication Service) oder vom DFS-R (Distributed File System Replication) repliziert. Liegen die Wurzeln einer Domäne im Domänenfunktionsmodus „Windows Server 2003“ oder niedriger, wird das GPT durch den FRS repliziert. Wurde die Domäne mindestens im Domänenfunktionsmodus „Windows Server 2008“ installiert, kommt DFS-R für die Replikation des GPT und somit des SYSVOLs zum Einsatz.

Die Performance bei der Abarbeitung von GPOs erhöhen

Für die Performance des Clients bei der Abarbeitung von GPOs (die auf ihn wirken) ist es empfehlenswert, den nicht konfigurierten Teil einer GPO stets zu deaktivieren. Das bedeutet, wenn in einer GPO lediglich Einstellungen im Benutzerkonfigurationsteil vorgenommen wurden, sollte der Computerkonfigurationsteil deaktiviert werden und vice versa.

Deaktivieren lässt sich ein Teil oder die gesamte GPO in der GPMC (Group Policy Management Console, zu Deutsch: Gruppenrichtlinienverwaltungskonsole). Mit einem Rechtsklick auf der entsprechenden GPO wählt man die Option Objektstatus aus und kann dann den gewünschten Teil oder die gesamte GPO deaktivieren. Das funktioniert auch wenn man die entsprechende GPO in der GPMC ausgewählt hat und danach zum Reiter Details wechselt.

Den Status der GPOs abfragen

Den Status einer GPO veranschaulicht das Attribut flags , das sich in den Eigenschaften jedes GPCs befindet.
Dabei kann das Attribut flags folgende Werte enthalten:

• Der Wert 0 im Attribut flags bedeutet, das gesamte Gruppenrichtlinienobjekt, also der Benutzerkonfigurations- und Computerkonfigurationsteil ist aktiviert.
• Der Wert 1 bedeutet, der Benutzerkonfigurationsteil einer GPO ist deaktiviert.
• Ist der Wert 2 , wurde der Computerkonfigurationsteil einer GPO deaktiviert.
• Beim Wert 3 ist das gesamte GPO deaktiviert.

State of the Art kann man den Status der GPOs in der AD-PowerShell mit folgenden Einzeilern abfragen:

# Alle GPOs mit ihrem Status anzeigen lassen:

Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A

Das Attribut flags automatisiert mit einem AD-PowerShellskript abfragen

Man kann die Abfrage auch automatisiert mit folgendem AD-PowerShellskript durchführen.

                ######################################################
# # AD-PowerShellskript zur Statusabfrage von GPOs # # Von: Yusuf Dikmenoglu 05/2011
# # http://blog.dikmenoglu.de #
###################################################### $auswahl = Read-Host "Welcher
GPO-Status soll angezeigt werden (0... Alle komplett aktiven GPOs anzeigen 1...Benutzerkonfiguration
ist deaktiviert 2...Computerkonfiguration ist deaktiviert 3...GPOs die komplett deaktiviert
sind):"switch ($auswahl){
0 {         Get-ADObject -Server <DC>
-LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope
Subtree -Properties displayName,flags | ForEach-Object
{                      if ($_.flags
-eq 0){          write-host "Gesamte
GPO aktiviert: " $_.displayName } } } 1 {         Get-ADObject
-Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope
Subtree -Properties displayName,flags | ForEach-Object
{                      if ($_.flags
-eq 1){          write-host "Benutzerkonfiguration
des GPO ist deaktiviert: " $_.displayName } } } 2 { Get-ADObject -Server <DC>
-LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope
Subtree -Properties displayName,flags | ForEach-Object
{                      if ($_.flags
-eq 2){          write-host "Computerkonfiguration
des GPO ist deaktiviert: " $_.displayName } } } 3 { Get-ADObject -Server <DC>
-LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope
Subtree -Properties displayName,flags | ForEach-Object
{                      if ($_.flags
-eq 3){          write-host "Gesamte
GPO deaktiviert: " $_.displayName } } } default{
Write-Host "Ungültige
Eingabe" } }
              

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)

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'

Bevor die aktuelle Exchange Version 2010 SP1 unter Windows Server 2008 R2 installiert werden kann, müssen zum einen die Betriebssystemvoraussetzungen erfüllt und zum anderen die notwendigen Patches für Exchange 2010 SP1 installiert sein.

Um Exchange 2010 RTM unter Windows Server 2008 R2 zu installieren, musste der Administrator in der PowerShell zuerst den Befehl Import-Module ServerManager und anschließend den Befehl Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy –Restart ausführen, um damit die Betriebssystemvorrausetzungen für die Rollen Client Access, Hub Transport und Mailbox zu erfüllen.

Das ist bei der Installation von Exchange 2010 SP1 nicht mehr notwendig. Denn eines der vielen Neuerungen im SP1 für Exchange 2010 ist die vereinfachte Installation. Während der Installation von Exchange 2010 SP1 hat man die Möglichkeit, die Option Für Exchange Server erforderliche Windows Server Rollen und -Funktionen automatisch installieren zu aktivieren. Damit werden die benötigten Betriebssystemkomponenten automatisch installiert und das Ausführen der PowerShellbefehle ist somit nicht mehr notwendig.

Hat man die Option aktiviert, weist einen der Setup-Assistent auf der Seite Abschließende Überprüfung darauf hin, dass ein Neustart aufgrund einer vorherigen Installation notwendig ist. Nach einem Neustart und nach dem erneutem Ausführen des Exchange 2010 SP1 Setups erkennt der Assistent, dass es aus einer vorherigen Installation erneut gestartet wurde. Bestätigt man die Abfrage mit „Ja“, werden die zuvor eingegebenen Konfigurationseinstellungen verwendet. Danach startet direkt die Abschließende Überprüfung. Hat es der Setup-Assistent nicht geschafft, alle Betriebssystemvoraussetzungen zu installieren, kann man zurück navigieren und durch erneutes Aktivieren der Option Für Exchange Server erforderliche… die noch fehlenden Voraussetzungen automatisch installieren lassen.

Weitere Informationen:
Exchange 2010 Prerequisites: Exchange 2010 SP1 Help

Der Infrastrukturmaster ist dafür verantwortlich, die Integrität der Objektreferenzen zwischen domänenübergreifenden Objekten innerhalb einer Gesamtstruktur aktuell zu halten. Beispielsweise bei domänenübergreifenden Gruppenmitgliedschaften.

Fügt man in einem Single-Domain Forest ein Sicherheitsprinzipal, wie es ein Benutzer, eine Gruppe oder ein Computer darstellt, zu einer Gruppe hinzu, wird der Distinguished Name (DN) des Sicherheitsprinzipals ins member Attribut (Forward-Link) der Gruppe hinzugefügt. Das AD erstellt im Gegenzug ohne ein zusätzliches Objekt einen Back-Link (das memberOf Attribut im Sicherheitsprinzipal) und referenziert damit das Sicherheitsprinzipal, das zur Gruppe hinzugefügt wurde. Benennt man ein Sicherheitsprinzipal um, verschiebt oder löscht es, wird automatisch das member Attribut der Gruppe aktualisiert. Da der Infrastrukturmaster seine Aufgabe erst in einem Multi-Domain Forest wahrnimmt, befindet er sich in einem Single-Domain Forest in einem inaktiven Zustand, da es für ihn keine Arbeit gibt.

Möchte man aber innerhalb eines Multi-Domain Forest beispielsweise den BenutzerA aus der DomäneA zur GruppeB aus der DomäneB hinzufügen, so hat das AD ein Problem. Denn das AD kann keinen Back-Link zu einem Objekt erstellen, das sich in einer anderen Domäne und somit in einer anderen Domänenpartition befindet. Das AD löst dieses Problem durch das Erstellen eines Phantomobjekts. Mit Phantomobjekten (nicht zu verwechseln mit Tombstones, Lingering Objects oder Foreign Security Principals) ist es möglich, Objekte in anderen Domänen innerhalb der Gesamtstruktur zu referenzieren. Innerhalb der AD-Datenbank wird eine Referenz auf das Objekt als ein Zeiger auf das Phantomobjekt repräsentiert. Phantomobjekte werden also erst dann erstellt, wenn in der Gesamtstruktur mehr als eine Domäne existiert und zwischen zwei Objekten, die sich in verschiedenen Domänen befinden, eine Verknüpfung besteht!

Phantomobjekte werden aber nur vom Infrastrukturmaster erstellt. Deshalb ist es der Infrastrukturmaster aus der DomäneB, der ein Phantomobjekt für BenutzerA erstellt. Das Gruppenobjekt „GruppeB“ verweist mit dem Phantomobjekt auf das Benutzerobjekt „BenutzerA“. Dabei enthält das Phantomobjekt eine minimale Menge an Informationen, damit ein DC das ursprüngliche Objekt (BenutzerA) an seinem ursprünglichen Ort referenzieren kann. Jedes Phantomobjekt in der AD-Datenbank enthält vom referenzierten Objekt die folgenden Informationen: objectGUID , objectSID (für Verweise auf Sicherheitsprinzipale) und den DN des Objekts.

Der Infrastrukturmaster ist auch für die Verwaltung eines Phantomobjekts verantwortlich. Wenn das Sicherheitsprinzipal (BenutzerA), auf das sich ein Phantomobjekt bezieht, umbenannt, verschoben oder gelöscht wird, aktualisiert der Infrastrukturmaster das Phantomobjekt. Dazu vergleicht der Infrastrukturmaster in regelmäßigen Abständen die Phantomobjekte mit den Informationen vom globalen Katalog (GC). Stellt der Infrastrukturmaster dabei eine Abweichung fest, aktualisiert er das Phantomobjekt. Die Aktualisierung repliziert er dann zu seinen Replikationspartnern innerhalb der Domäne, die ebenfalls eine Kopie des Phantoms besitzen. Ohne diese Vorgehensweise würden die eigentlichen Änderungen an den referenzierten Objekten (z.B. BenutzerA wird umbenannt) nicht an das gegenüberliegende Objekt (GruppeB) übertragen werden.

Da der globale Katalog regelmäßig Aktualisierungen für alle Objekte in der Gesamtstruktur erhält, sind die Daten auf dem GC stets auf dem aktuellen Stand. Dadurch das e in GC bereits über ein Teilreplikat aller Objekte in der Gesamtstruktur besitzt, speichert er auch keine Phantomobjekte. Denn er kennt bereits jedes Objekt aus allen Domänen innerhalb der Gesamtstruktur und somit existieren keine Verweise auf Objekte, die ein GC nicht kennt. Daher darf der Infrastrukturmaster in einem Multi-Domain Forest nicht einem GC zugewiesen werden, denn er würde keine Unterschiede erkennen. Der Infrastrukturmaster leistet seine Arbeit innerhalb seiner Domäne ausschließlich an DCs, die kein GC sind.

Wird allerdings in einem Multi-Domain Forest auf jedem DC in der Domäne, in der auf dem Infrastrukturmaster der GC aktiviert wurde ebenfalls der GC aktiviert, werden auf keinem der DCs dieser Domäne jemals Phantomobjekte erstellt. Daher erübrigt sich das Aktualisieren der Phantomobjekte. Denn alle DCs dieser Domäne kennen bereits durch das Aktivieren des GC alle Objekte in der Gesamtstruktur und somit hat der Infrastrukturmaster nichts zu tun. In solch einem Fall wird der Infrastrukturmaster ebenfalls in einen inaktiven Zustand versetzt.

Die FSMO-Rollen verschieben

Wenn der AD-Papierkorb in der Gesamtstruktur aktiviert ist

Ist allerdings der AD-Papierkorb aktiviert, der sich erst ab dem Gesamtstrukturfunktionsmodus „Windows Server 2008 R2“ aktivieren lässt, ist die Funktion des Infrastrukturmasters nicht mehr länger an einen einzelnen DC gebunden! Die Aufgabe des Infrastrukturmasters ist jetzt auf alle DCs in der Gesamtstruktur verteilt. Jeder DC in einem Multi-Domain Forest ist für die Aktualisierung seiner domänenübergreifenden Objektverweise, sprich, für das Phantomobjekt das sich in seiner lokalen AD-Datenbank befindet, verantwortlich. In dem Fall, dass das referenzierte Sicherheitsprinzipal umbenannt, verschoben oder gelöscht wird, aktualisiert jeder DC sein Phantomobjekt.

Wenn also der AD-Papierkorb aktiviert ist, hat der Infrastrukturmaster keine Aufgaben mehr und es ist irrelevant, welcher DC die FSMO-Rolle des Infrastrukturmaster innehat!

Der Active Directory-Papierkorb im Windows Server 2008 R2

Weitere Informationen:
Verknüpfte Attribute
Die verknüpften Attribute abfragen
Lingering Objects (veraltete Objekte)
Globaler Katalog (Global Catalog - GC)
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Phantoms, tombstones and the infrastructure master
7.1.5.5 Infrastructure FSMO Role