Restoreversuch eines alten AD-Backups

Die Tombstone Lifetime (TSL) definiert drei Verhaltensregeln innerhalb einer Active Directory Umgebung. Diese wären:

  1. Wie lange ein System State-/Full Server – Backup verwendet werden darf.
  2. In welcher Zeit sich die DCs mindestens einmal erfolgreich repliziert haben müssen.
  3. Wann ein gelöschtes Objekt endgültig vom Garbage Collection Prozess endgültig aus der AD-Datenbank (NTDS.DIT) entfernt wird.

Welchen Wert die TSL hat, wann und wo die TSL gesetzt wird oder wie man diese ändern kann, ist hier beschrieben:

Die Tombstone Lifetime
Folgende Besonderheiten gibt es bzgl. der TSL:

  1. Der Minimalwert der bis einschließlich „Windows Server 2008“ Gültigkeit hat ist „2“. Konfiguriert man bis Windows Server 2008 einen niedrigeren Wert (also 1), wird als Wert 60 festgelegt.
  2. Wird ab „Windows Server 2008 R2“ ein Wert kleiner 2 konfiguriert, wird als Wert immer 2 festgelegt. Der Minimalwert den ab Windows Server 2008 R2 die TSL haben kann ist also immer 2.

 

Was passiert eigentlich wenn man ein AD-Backup versucht rückzusichern, das älter als die TSL ist?

Versucht man nun ein z.B. System State Backup das älter als die TSL ist rückzusichern, erhält man gleich zu Beginn des Restoreversuchs diese Fehlermeldung:

WSB und TSL

Eine Rücksicherung wird direkt schon vom Backup-Programm geblockt.
Weitere Informationen:
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Der Container Deleted Objects
3.1.1.1.5.1 Tombstone Lifetime and Deleted-Object Lifetime

 

Die neuen AD – PowerShell CMDLets in Windows Server 8 Beta

Seit gestern 29.02.2012 – ca. 15:45 Uhr MEZ hat Microsoft die Clientversion mit dem Namen „Windows 8 Consumer Preview“ Build 8250 und die Serverversion „Windows Server 8 Beta“ veröffentlicht. Erreicht ein Release das Beta Stadium, ist es feature completed. Ab der Veröffentlichung einer Beta Version werden keine neuen Funktionen mehr eingebaut, sondern nur noch Fehlerbeseitigung betrieben.


Hier kann man sich die entsprechende Version herunterladen:


Windows 8 Consumer Preview
Windows Server “8″ Beta



Mit diesen beiden Major Releases erscheinen sowohl für den Client als auch für den Server die Weiterentwicklung von Windows 7 und Windows Server 2008 R2!


Die AD – PowerShell CMDLets wurden von 76 auf 134 und somit um 58 neue CMDLets erweitert!



 



Im Vergleich hier die AD – PowerShell CMDLets unter Windows Server 2008 R2:


AD-PowerShell Befehle



Erfreulich ist, dass es nun (endlich) 23 AD-Replikations CMDLets gibt. Viele Konfigurationen die bisher ausschließlich in der MMC „Active Directory-Sites and –Services“ (dssite.msc) vorgenommen werden konnten, können jetzt auch in der AD-PowerShell mit den neuen CMDLets durchgeführt werden.



 



Die Hilfe zu den einzelnen CMDLets lässt sich in gewohnter Weise mit dem Befehl Get-Help <Cmdlet Name> -Full aufrufen.


 


AD-Objekte abrufen (41 Cmdlets)


- Get-ADAccountAuthorizationGroup
- Get-ADAccountResultantPasswordReplicationPolicy
- Get-ADCentralAccessPolicy
- Get-ADCentralAccessRule
- Get-ADClaimTransformPolicy
- Get-ADClaimType
- Get-ADComputer
- Get-ADComputerServiceAccount
- Get-ADDCCloningExcludedApplicationList
- Get-ADDefaultDomainPasswordPolicy
- Get-ADDomain
- Get-ADDomainController
- Get-ADDomainControllerPasswordReplicationPolicy
- Get-ADDomainControllerPasswordReplicationPolicyUsage
- Get-ADFineGrainedPasswordPolicy
- Get-ADFineGrainedPasswordPolicySubject
- Get-ADForest
- Get-ADGroup
- Get-ADGroupMember
- Get-ADObject
- Get-ADOptionalFeature
- Get-ADOrganizationalUnit
- Get-ADPrincipalGroupMembership
- Get-ADReplicationAttributeMetadata
- Get-ADReplicationConnection
- Get-ADReplicationFailure
- Get-ADReplicationPartnerMetadata
- Get-ADReplicationQueueOperation
- Get-ADReplicationSite
- Get-ADReplicationSiteLink
- Get-ADReplicationSiteLinkBridge
- Get-ADReplicationSubnet
- Get-ADReplicationUpToDatenessVectorTable
- Get-ADResourceProperty
- Get-ADResourcePropertyList
- Get-ADResourcePropertyValueType
- Get-ADRootDSE
- Get-ADServiceAccount
- Get-ADTrust
- Get-ADUser
- Get-ADUserResultantPasswordPolicy


 



AD-Objekte erstellen (17 Cmdlets)


- New-ADCentralAccessPolicy
- New-ADCentralAccessRule
- New-ADClaimTransformPolicy
- New-ADClaimType
- New-ADComputer
- New-ADFineGrainedPasswordPolicy
- New-ADGroup
- New-ADObject
- New-ADOrganizationalUnit
- New-ADReplicationSite
- New-ADReplicationSiteLink
- New-ADReplicationSiteLinkBridge
- New-ADReplicationSubnet
- New-ADResourceProperty
- New-ADResourcePropertyList
- New-ADServiceAccount
- New-ADUser


 



AD-Objekte entfernen (24 Cmdlets)


- Remove-ADCentralAccessPolicy
- Remove-ADCentralAccessPolicyMember
- Remove-ADCentralAccessRule
- Remove-ADClaimTransformPolicy
- Remove-ADClaimType
- Remove-ADComputer
- Remove-ADComputerServiceAccount
- Remove-ADDomainControllerPasswordReplicationPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Remove-ADGroup
- Remove-ADGroupMember
- Remove-ADObject
- Remove-ADOrganizationalUnit
- Remove-ADPrincipalGroupMembership
- Remove-ADReplicationSite
- Remove-ADReplicationSiteLink
- Remove-ADReplicationSiteLinkBridge
- Remove-ADReplicationSubnet
- Remove-ADResourceProperty
- Remove-ADResourcePropertyList
- Remove-ADResourcePropertyListMember
- Remove-ADServiceAccount
- Remove-ADUser


 



AD-Schreibvorgänge durchführen (27 Cmdlets)


- Set-ADAccountControl
- Set-ADAccountExpiration
- Set-ADAccountPassword
- Set-ADCentralAccessPolicy
- Set-ADCentralAccessRule
- Set-ADClaimTransformLink
- Set-ADClaimTransformPolicy
- Set-ADClaimType
- Set-ADComputer
- Set-ADDefaultDomainPasswordPolicy
- Set-ADDomain
- Set-ADDomainMode
- Set-ADFineGrainedPasswordPolicy
- Set-ADForest
- Set-ADForestMode
- Set-ADGroup
- Set-ADObject
- Set-ADOrganizationalUnit
- Set-ADReplicationConnection
- Set-ADReplicationSite
- Set-ADReplicationSiteLink
- Set-ADReplicationSiteLinkBridge
- Set-ADReplicationSubnet
- Set-ADResourceProperty
- Set-ADResourcePropertyList
- Set-ADServiceAccount
- Set-ADUser


 



AD-Objekte hinzufügen (7 Cmdlets)


- Add-ADCentralAccessPolicyMember
- Add-ADComputerServiceAccount
- Add-ADDomainControllerPasswordReplicationPolicy
- Add-ADFineGrainedPasswordPolicySubject
- Add-ADGroupMember
- Add-ADPrincipalGroupMembership
- Add-ADResourcePropertyListMember


 



AD-Objekte und optionale AD-Funktionen deaktivieren (2 Cmdlets)


- Disable-ADAccount
- Disable-ADOptionalFeature


 



AD-Objekte und optionale AD-Funktionen aktivieren (2 Cmdlets)


- Enable-ADAccount
- Enable-ADOptionalFeature


 



AD-Objekte verschieben (3 Cmdlets)


- Move-ADDirectoryServer
- Move-ADDirectoryServerOperationMasterRole
- Move-ADObject


 



AD-Objekte umbenennen (1 Cmdlet)


- Rename-ADObject


 



AD-Dienstkontenkennwörter zurücksetzen (1 Cmdlet)


- Reset-ADServiceAccountPassword


 



AD-Objekte wiederherstellen (1 Cmdlet)


- Restore-ADObject


 



AD-Objekte suchen (1 Cmdlet)


- Search-ADAccount


 



AD-Dienstkonto deinstallieren (1 Cmdlet)


- Uninstall-ADServiceAccount


 



AD-Objekt entsperren (1 Cmdlet)


- Unlock-ADAccount


 



AD-Kontoablaufdatum und ADClaimTransformLink zurücksetzen (1 Cmdlet)


- Clear-ADAccountExpiration
- Clear-ADClaimTransformLink


 



AD-Dienstkonto installieren (1 Cmdlet)


- Install-ADServiceAccount


 



AD-Konto synchronisieren (1 Cmdlet)


- Sync-ADObject


 



AD-Dienstkonto testen (1 Cmdlet)


- Test-ADServiceAccount


 


Auch wurden erstmals mit Windows Server 8 zehn “ADDS Deployment” CMDlets ins Serverbetriebssystem implementiert, um die Installation der DCs nun auch in der AD-PowerShell zu automatisieren. Wobei bis zur RTM die fünf “Test-ADDS*” CMDLets nicht mehr mit dem Befehl Get-Command -Module ADDSDeployment sichtbar sein werden!


Das manuelle Aufrufen von DCPROMO.exe unter “Start – Ausführen” ist ab Windows Server 8 nicht mehr möglich! Das manuelle Heraufstufen eines DCs erfolgt ab sofort im Server-Manager. Jedoch wird DCPROMO in einer Antwortdatei weiterhin unterstützt, damit die Unternehmen die bisher die Installation ihrer DCs weitestgehend automatisiert hatten, keinen Nachteil erhalten.



 


 


Ein Read-Only Domänencontroller Computerkonto erstellen (1 CMDLet) 


- Add-ADDSReadOnlyDomainControllerAccount


 


Eine ADDS Domäne in der Gesamtstruktur installieren


- Install-ADDSDomain


 


Einen Domänencontroller installieren


- Install-ADDSDomainController


 


Eine Gesamtstruktur bzw. die Root-Domäne installieren


- Install-ADDSForest


 


Die “Test-ADDS*” CMDLets werden bis zur Fertigstellung des Windows Server 8 RTM (Release to Manufacturing) nicht mehr mit “Get-Command -Module ADDSDeployment” sichtbar sein!


 


Einen Domänencontroller oder eine Domäne deinstallieren


- Uninstall-ADDSDomainController


 


Des Weiteren wurden die Gruppenrichtlinien CMDLets von 25 auf 28 und somit um drei CMDLets erweitert.



 


Backup-GPO
Mit diesem Cmdlet sichert man das angegebene Gruppenrichtlinienobjekt (GPO) oder alle Gruppenrichtlinienobjekte in einer angegebenen Domäne in ein Sicherungsverzeichnis. Dabei muss das Sicherungsverzeichnis bereits existieren.



Copy-GPO
Dieses Cmdlet erstellt eine neue GPO und kopiert die Einstellungen aus der Quell-GPO in die neue GPO. Mit diesem Cmdlet kann eine GPO aus einer Domäne in eine andere Domäne innerhalb der gleichen Gesamtstruktur kopiert werden.



Get-GPInheritance
Informationen zur Gruppenrichtlinienvererbung für eine angegebene Domäne oder Organisationseinheit kann man sich mit diesem Cmdlet ausgeben lassen.



Get-GPO
Eine bestimmte GPO oder alle GPOs innerhalb einer Domäne kann man sich mit diesem Cmdlet anzeigen lassen.



Get-GPOReport
Hiermit wird ein Bericht im XML- oder HTML-Format generiert, in dem die Eigenschaften und Richtlinieneinstellungen für eine angegebene GPO oder für alle GPOs einer Domäne angezeigt werden. Dieses Cmdlet eignet sich ideal zu Dokumentationszwecken. Möchte man alle Richtlinieneinstellungen aller GPOs innerhalb der Domäne in eine HTML Datei exportieren, so gilt es diesen Befehl auszuführen:
Get-GPOReport -All -Domain <Domäne.de> -ReportType HTML -Path C:\GPOReport\GPOReport.html. Das Zielverzeichnis muss bereits existieren, sonst erhält man eine Fehlermeldung.




Get-GPPermissions / Get-GPPermission

Die Berechtigungen für einen oder mehrere Sicherheitsprinzipale kann man mit diesen Cmdlets in der angegebenen GPO abrufen.




Get-GPPrefRegistryValue

Dieses Cmdlet zeigt eine oder mehrere Registrierungseinstellungen die unterhalb der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO getätigt wurden an.




Get-GPRegistryValue

Bei diesem Cmdlet werden eine oder mehrere registrierungsbasierte Richtlinieneinstellungen aus der Computerkonfiguration oder der Benutzerkonfiguration in einer GPO abgerufen.




Get-GPResultantSetOfPolicy

Mit diesem Cmdlet kann man die Richtlinienergebnissatz-Informationen für einen Benutzer, einen Computer oder für beide in eine Datei im HTML- oder XML-Format ausgeben lassen.




Get-GPStarterGPO

Ein bestimmtes oder alle Starter-GPOs werden mit diesem Cmdlet angezeigt.




Import-GPO

Dieses Cmdlet importiert die Einstellungen aus einer gesicherten GPO in die angegebene Ziel-GPO. Dabei kann sich das Ziel-GPO in einer anderen Domäne oder in einer anderen Gesamtstruktur befinden als die Sicherungs-GPO und muss vorher nicht existieren.




Invoke-GPUpdate
Ein GPUpdate durchführen.




New-GPLink

Eine GPO wird auf eine Organisationseinheit (OU), einen AD-Standort oder auf die Domäne mit diesem Cmdlet verlinkt.




New-GPO

Eine neue GPO wird mit diesem Cmdlet erstellt.




New-GPStarterGPO

Mit diesem Cmdlet wird eine neue Starter-GPO erstellt.




Remove-GPLink

Dieses Cmdlet entfernt eine GPO-Verklinkung von einer OU, einem AD-Standort oder von der Domäne.




Remove-GPO

Eine GPO wird mit samt allen Verlinkungen, mit diesem Cmdlet gelöscht.




Remove-GPPrefRegistryValue

Eine oder mehrere Registrierungseinstellungen werden aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO mit diesem Cmdlet entfernt.




Remove-GPRegistryValue

Um eine oder mehrere Registrierungsbasierte Richtlinieneinstellungen aus der Benutzerkonfiguration oder Computerkonfiguration innerhalb einer GPO zu entfernen, muss dazu dieses Cmdlet verwendet werden.




Rename-GPO

Mit diesem Cmdlet kann man eine GPO umbenennen bzw. der GPO einen anderen Anzeigenamen zuweisen. Dabei bleibt die GUID der umbenannten GPO erhalten.




Restore-GPO

Dieses Cmdlet stellt eine GPO-Sicherung in der Domäne wieder her, in der sie ursprünglich gespeichert wurde. Ist die ursprüngliche Domäne oder die GPO nicht mehr in der Domäne vorhanden, tritt ein Fehler auf.




Set-GPInheritance

Die Vererbung einer GPO kann mit diesem Cmdlet deaktiviert werden. Oder die Deaktivierung der Vererbung für eine angegebene OU oder Domäne lässt sich ebenfalls mit diesem Cmdlet aufheben.




Set-GPLink

Die Eigenschaften einer GPO-Verknüpfung lassen sich mit diesem Cmdlet festlegen.




Set-GPPermissions / Set-GPPermission
 
Die Berechtigungen einer GPO oder für alle GPOs innerhalb einer Domäne lassen sich mit diesen Cmdlets bearbeiten.




Set-GPPrefRegistryValue

Dieses Cmdlet konfiguriert eine Registrierungseinstellung unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO.



Set-GPRegistryValue

Mit diesem Cmdlet konfiguriert man eine oder mehrere registrierungsbasierte Richtlinieneinstellungen unter der Benutzerkonfiguration oder der Computerkonfiguration in einer GPO.



Die PowerShell Cmdlets für Gruppenrichtlinien

Die Besonderheit der „strict replication consistency“ in einem Forest mit Windows 2000 Wurzeln

Eines der Schutzmechanismen der AD-Replikation ist die strict replication consistency (strikte Replikationskonsistenz), die standardmäßig bei einer Migration von NT 4.0 auf Windows Server 2003 oder wenn ein Forest ab Windows Server 2003 erstellt wurde, aktiviert ist. Die Funktion der „strict replication consistency“ steht ab Windows 2000 Server SP3 (sogar schon mit Post-SP2 Hotfix) zur Verfügung, diese ist aber unter Windows 2000 standardmäßig deaktiviert!


Was es mit der strict replication consistency auf sich hat und wann diese vor allem zum Einsatz kommt, wird in dem folgenden Artikel detailliert erläutert:


LDAP://Yusufs.Directory.Blog/ – Lingering Objects (veraltete Objekte)


Kurz gesagt verhindert die „strict replication consistency“, dass Lingering Objects (herumlungernde/veraltete Objekte) von einem (veralteten) Domänencontroller (DC) der sich länger als die Tombstone-Lifetime nicht mehr mit seinen Replikationspartnern repliziert hat, zurück zu den (aktuellen!) Replikationspartnern repliziert werden.


Ein Forest der unter Windows Server 2003 oder höher installiert wurde, verfügt über einen speziellen operativen GUID, der standardmäßig aber nicht in einem Forest mit Windows 2000 Wurzeln existiert!


Wird ein Server zum DC hochgestuft, überprüft dieser ob das folgende Objekt existiert: 


CN=94fdebc6-8eeb-4640-80de-ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain>


 


Erst wenn dieser Container zum Zeitpunkt des heraufstufen existiert, aktiviert der künftige DC die „strict replication consistency“ automatisch.


 


Ab Windows Server 2003 SP1 kann man die „strict replication consistency“ auf einem einzelnen DC mit dem folgenden REPADMIN-Befehl aktivieren: Repadmin /regkey <DC> +strict.


 


Auf allen DCs im Forest lässt sich die „strict replication consistency“ wie folgt aktivieren: Repadmin /regkey * +strict


 


 


Das bedeutet jedoch, jedes Mal wenn weitere DCs (in einen Forest mit Windows 2000 Wurzeln) hinzukommen, muss jedes Mal auf dem DC die „strict replication consistency“ mit dem Befehl „Repadmin /regkey <DC> +strict“ aktiviert werden.

Eine elegantere Variante ist, damit ab sofort auf allen künftigen DCs automatisch die „strict replication consistency“ aktiviert ist, man erstellt den operativen Container in der Konfigurationspartition manuell.


 


Mit ADSIEdit kann man das folgendermaßen erledigen:



  1. Nachdem ADSIEdit gestartet und der Eintrag ADSI Edit auf der linken Seite markiert wurde, gilt es zuerst auf Action und anschließend auf Connect to… zu klicken.


  2. Im darauf erscheinenden “Connection Settings” Dialogfenster kann man dann im Bereich Connection Point im Feld Select or type a Distinguished Name or Naming Context den folgenden LDAP-Pfad, sprich den Distinguished Name des folgenden Containers angeben und anschließend mit OK bestätigen: CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain>


  3. Als nächstes gilt es mit einem Rechtsklick auf CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<Root-Domain> die Option New -> Object… auszuwählen.


  4. Als class muss der Eintrag container ausgewählt werden.


  5. Im nächsten Schritt muss als Value dieser Wert eingegeben warden: 94fdebc6-8eeb-4640-80de-ec52b9ca17fa.


  6. Danach sollte man auf auf More Attributes klicken und unter Select a property to view die Option showInAdvancedViewOnly auswählen.


  7. Zusätzlich sollte im Bereich Attribute Values im Feld Edit Attribute als Wert TRUE eingetragen und mit SET bestätigt werden.


  8. Mit einem abschließenden Klick auf OK und Finish hat man dann das Objekt 94fdebc6-8eeb-4640-80de-ec52b9ca17fa erstellt. Ab sofort wird nun bei einem neuen DC der in einer Gesamtstruktur mit Windows 2000 Wurzeln hochgestuft (promotet) wurde, die „strict replication consistency“ automatisch aktiviert.


Wem jedoch dieser Vorgang zu heikel ist, der kann auch regelmäßig (evtl. in einem geplanten Task) den REPADMIN – Befehl ausführen, damit auf allen neuen DCs auch die „strict replication consistency“ aktiviert wird: Repadmin /regkey * +strict



Mit der folgenden GPO-ADM Datei lässt sich das ebenfalls lösen:



CLASS MACHINE
      CATEGORY “Strict Replication Consistency”
            KEYNAME “System\CurrentControlSet\Services\NTDS\Parameters”
            POLICY “Enable Strict Replication Consistency”
            EXPLAIN “This enables Strict Replication Consistency”.
            VALUENAME “Strict Replication Consistency”
            VALUEON NUMERIC 1
            VALUEOFF DELETE
END POLICY
END CATEGORY


Wird anschließend diese GPO auf die OU “Domain Controllers” verlinkt, wird ebenfalls auf jedem neuen DC die „strict replication consistency“ automatisch aktiviert.



 


Weitere Informationen:
Event ID 1388 or 1988: A lingering object is detected: Active Directory

Ruhig ist es hier geworden

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.



Lange Rede kurzer Sinn: Wie geht es hier nun weiter?


Wie gehabt, nur nicht mehr so wie in den vergangenen fünf Jahren (meist) im zwei-Wochen Rhythmus. Ich hoffe ihr versteht das! Natürlich betreibe ich meine mit Herzblut betriebene Web-Visitenkarte bzw. meinen Blog weiter. Die Leser meines Blogs (zwischen 4.000 bis 6.000 unique Hits pro Tag) und die vielen Mails in den vergangenen 2 Monaten sind Motivation genug um weiterzumachen!


Wenn dann mal der Alltag einkehrt (Hausbau fertig inkl. des Umzugs was Ende diesen Jahres/Anfang 2012 geplant ist), geht es hier mit Vollgas weiter. Bis dahin versuche ich jedoch auch noch einiges zu schreiben. Ich bitte euch nur um Nachsicht. :-)


So, nun habt ihr ein Lebenszeichen vor mir erhalten und kennt die Umstände, warum es hier in letzter Zeit so ruhig geworden ist. Ich mach‘ mich wieder ans lernen und freue mich schon, viele Leser meines Blogs in meiner neuen Rolle als AD-PFE demnächst im Berufsleben persönlich kennenzulernen. Einige konnte ich bereits kennenlernen.


Mit dem Wechsel zu Microsoft habe ich natürlich meine drei Buchstaben, sprich meinen MVP Titel abgeben müssen. Naja, ich habe meine drei Buchstaben nicht abgegeben, sondern gegen zwei [MS] bzw. 4 Buchstaben [MSFT ß das ist die Abkürzung an der Börse] eingetauscht. =) Und wenn mein Blogbetreiber, der kein anderer als der ice-Veranstalter „Nicki Wruck“ ist, mal die Zeit findet, wird er sicher demnächst auch das MVP-Logo auf der linken Seite meines Blogs entfernen.


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

Die Komponenten einer GPO und den Status von GPOs abfragen

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



# Alle GPOs anzeigen, die beide Teile (Benutzer- und Computerkonfiguration) aktiviert haben:


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



# Alle GPOs die den Teil der Benutzerkonfiguration deaktiviert haben, werden folgendermaßen angezeigt:


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



# Alle GPOs die den Computerkonfigurationsteil deaktiviert haben, werden wie folgt angezeigt:


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



# Alle komplett deaktivierten GPOs (beide Teile Benutzer- und Computerkonfigurationsteil sind deaktiviert) werden so angezeigt:


Get-ADObject -Server <DC> -LDAPFilter “(flags=3)” -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

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 = 0×4; 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)

Mit Excel und der AD-PoSh AD-Benutzer umbenennen

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:


Massenimporte- und -exporte mit CSVDE und der AD-PowerShell durchführen



Die Excel-Datei könnte beispielsweise folgendermaßen aussehen:





Danach lässt sich der userPrincipalName sowie sAMAccountName mit dem folgenden AD-PowerShellskript ändern.

######################################################
#
# 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()


 

Weitere Informationen:
Die Active Directory-Attribute hinter den Feldnamen
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
LDIFDE – LDAP Data Interchange Format Data Exchange

Die RSAT für Windows 7 Service Pack 1 sind RTW

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’



Nun hat Microsoft die aktualisierte Version vom RSAT für Windows 7 Service Pack 1 zum Download zur Verfügung gestellt.
Darin enthalten ist auch die neueste Version vom Hyper-V Manager, der sowohl Dynamic Memory und RemoteFX unterstützt.



Herunterladen kann man die RSAT für Windows 7 Service Pack 1 hier:


Download details: Remote Server Administration Tools for Windows 7 with Service Pack 1 (SP1)


 

DCs zu Clustern ist nicht möglich

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.


Wie viele DCs pro Domäne werden benötigt?



Aber selbstverständlich lässt sich ein Cluster auf zwei DCs installieren, ohne die DC-Funktionalität selber zu Clustern. Das könnte der Administrator in Erwägung ziehen, um beispielsweise eine Applikation geclustert zu betreiben. Warum allerdings das Betreiben von zusätzlichen Diensten bzw. Applikationen auf einem DC alles andere als eine gute Idee ist, stellt dieser Artikel dar:


Warum es ein dedizierter DC sein sollte!




Weitere Informationen:
Windows 2000, Windows Server 2003, and Windows Server 2008 cluster nodes as domain controllers
Cluster Service May Not Start if Domain Controller Is Unavailable
When a Windows Server 2003 cluster node is a domain controller, you may receive an error message when you add domain users to the cluster file share
Die NO-GOs und Empfehlungen zu virtuellen DCs

Hinweise zu PSOs

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



Damit man nicht aufs Glatteis durch die von Windows erzeugte Meldung geführt wird und um PSOs erfolgreich zu implementieren, hier ein paar wichtige Hinweise:



  • Versucht ein Benutzer auf den ein PSO verlinkt wurde, auf einem Windows XP Client oder Windows Server 2003 sein Kennwort zu ändern, erhält er diese Meldung:




    In diesem Fall hat der Benutzer erfolglos versucht sein Kennwort zu ändern. Das neue Kennwort entsprach nicht den Vorgaben aus dem PSO. Daher ist es folgerichtig, dass eine Meldung erscheint. Allerdings stammen die Kennwort-Anforderungen in dem Dialogfenster aus der Domänenrichtlinie Default Domain Policy, die auf Domänenebene verlinkt ist! Die Meldung hat sich leider mit Einführung von PSOs nicht verändert. Es erscheint kein eigenes Dialogfenster, in dem die Kennwortvorgaben des PSO enthalten sind!


  • Versucht der Benutzer auf einem Windows 7 Client oder Windows Server 2008/R2 sein Kennwort zu ändern, erhält er bei nicht Einhaltung der Kennwortvorgaben aus dem PSO diese Meldung:




    Auch diese Meldung ist irreführend, denn es wird auf die Kennwortrichtlinie der Domäne, also auf die Default Domain Policy verwiesen, in der standardmäßig die Kennwortvorgaben auf Domänenebene definiert sind. Eine andere Meldung mit den Kennwortvorgaben der PSO erscheint weiterhin nicht!


  • Versucht der Administrator, das Kennwort eines Benutzers auf den ein PSO verlinkt wurde zu ändern, erscheint diese Meldung:




    Diese Meldung ist ebenfalls trügerisch, denn angeblich entspricht das neue Kennwort nicht den Anforderungen der Kennwortrichtlinien. Abgesehen davon das es sich bei dem PSO nicht um eine Kennwortrichtlinie sondern um ein AD-Objekt handelt, erscheint einmal mehr kein Hinweis auf das PSO!



  • Führt man auf dem Client unter Start – Ausführen das Resultant Set of Policy (RSoP) aus, werden dort die Kennwortvorgaben wieder aus der Default Domain Policy angezeigt! Daher bringt ein RSOP.msc für die Überprüfung eines PSO nichts! Denn da es sich bei den PSOs nicht um Gruppenrichtlinien (GPOs) handelt, werden diese auch nicht im RSOP angezeigt.

    Und abgesehen davon ist RSOP.msc zum Überprüfen von GPOs nicht mehr State oft the Art und sollte ab Windows 7 und Windows Server 2008 R2 auch nicht mehr verwendet werden. Besser ist es in der Kommandozeile diesen Befehl zu verwenden: GPResult /h GPO-Report.html.


  • PSOs dürfen erst erstellt werden, wenn sich der Domänenfunktionsmodus bereits im Modus Windows Server 2008 oder höher befindet. Wenn PSOs erstellt werden bevor sich der Domänenfunktionsmodus mindestens in der Ebene Windows Server 2008 befindet, werden diese auch nach dem Hochstufen nicht angewendet!


  • Ob und welches PSO auf einen Benutzer verlinkt ist, sollte mit dem Kommandozeilenbefehl dsget user <DN des Benutzers> -effectivepso kontrolliert werden. Beispielsweise: dsget user ” CN=Yusuf Dikmenoglu,OU=IT,DC=ad2008R2,DC=Dikmenoglu,DC=de” -effectivepso

Wie viele Sprachen sprechen Sie? Ich spreche bloß eine: LDAP!