Hi, Fabian hier. Situationen wie heute Vormittag kommen fast täglich vor - ein Kollege gibt einen kurzen Ping per Messenger, ob man eine Idee für folgendes Szenario hätte (neudeutsch: Brainstorming):
Bei einem Kunden lief das Ereignisprotokoll "Security" auf DCs mit Events voll, so daß die Server stark unter Last standen und das Log nach kürzester Zeit "überlief". Um nun die den Events zugrunde liegenden Fehler schneller einzugrenzen, sollten die Einträge nach der ID gruppiert und dann ausgezählt werden. Hat man erst einmal die Anzahl an gleichen Event IDs, weiß man ggf., wo man nach der Ursache für die Flut an Einträgen suchen muß und kann die Ursache des Fehlers meist schnell beheben.
Da SCOM zur Auswertung der Ereignisprotokolle momentan nicht genutzt werden konnte, mußte eine andere Lösung her. Zuerst dachten wir an den LogParser, der wirklich viele interessante Möglichkeiten bietet, solche (und viele andere) Szenarien schnell zu erledigen. Nach ein, zwei kurzen Test zeigte sich aber, daß einmal mehr die PowerShell die Anforderung ebenfalls sehr schnell lösen kann. Und da die uns bekannten Administratoren Einzeiler lieben, hier eine schnelle Lösung für die Fragestellung:
PS C:\> Get-EventLog Security | Group-Object EventID | Sort-Object Count -descending | Select-Object Count, Name | Format-Table -autosize
- Auslesen des "Security" Eventlogs: Get-EventLog
- Gruppierung der Events: Group-Object
- Sortierung der gruppierten Events nach der Anzahl: Sort-Object
- Ausgabe der beiden gewünschten Objekte "Count" und "Name": Select-Object
- Formatierung der Ausgabe als Tabelle: Format-Table
Ach, ich liebe die PowerShell... :-)
Viele Grüße
Fabian
Hi! Hier ist wieder Florian, einer der deutschen MVPs mit einem Gastbetrag (*) zum Thema Gruppenrichtlinien. Diesmal würde ich hier gerne einige Randnotizen zur Group Policy Management Console (GPMC) veröffentlichen, die speziell das Sichern und Wiederherstellen betrifft.
Durch meine örtliche Nähe zu unserem südlichen Nachbarland der Schweiz, bekomme ich allerhand interessante Weisheiten nahegelegt, so etwa auch „ein ordentlicher Kerl hat stets sein Sackmesser dabei“ (wobei „Sackmesser“ hier als Taschenmesser übersetzt werden darf ;-) …). Wer so ein Sackmesser schon das ein oder andere mal verwendet hat, wird seinen Nutzen sicherlich zu schätzen wissen. Es bietet so ziemlich alles, was man fürs Überleben in der Wildnis braucht – oder zumindest ein Grundsatz an Werkzeugen, die man auf der Maiwanderung oder einem Vatertagsspaziergang gut gebrauchen kann. Ähnlich ist das mit der GPMC – sie ist sozusagen das Sackmesser für jeden GP-Administrator.
Das GP-Sackmesser hat neben vielen Annehmlichkeiten wie den Reitern für die Rechtedelegierung und dem HTML-Bericht auch eine Sicherungs- und Wiederherstellungsfunktion. Diese Sicherungs- und Wiederherstellungsfunktion erlaubt es, Gruppenrichtlinien als Ganzes zu speichern, und zu gegebenem Zeitpunkt (man hofft ja nie, dass dieser Fall eintritt) zurückzuspielen. Wie bei jeder guten Sicherung sollte, bevor man sich auf den Mechanismus verlässt, eine Probesicherung und -wiederherstellung durchgeführt werden – nicht zuletzt um auch das Handling zu testen und zu sehen, ob wirklich alle Daten erfolgreich zurückgespielt wurden.
Eine GPO besteht aus zwei Teilstücken. Ein Teilstück wird auf dem SYSVOL-Freigabebaum erstellt, während der zweite Teil ein Container im Verzeichnis, unter CN=Policies,CN=System,DC=domain,DC=tld ist. Beim Sichern einer GPO speichert die GPMC beide „Teile“ einer Richtlinie – sowohl die Daten aus dem SYSVOL als auch die Daten im Active Directory-Container sowie die zur Richtlinie gehörenden Daten wie Sicherheitseinstellungen oder Delegierung.
Leider gibt es auch einige Informationen, die zwar mit einer GPO in Verbindung stehen, jedoch nicht zu den gesicherten Daten gehören. Diese sollte man sich genau ansehen und gegebenenfalls zusätzlich sichern. Oder zumindest im Hinterkopf behalten, damit bei einem Restore einer GPO nicht kurzfristig weitere Brandherde gelöscht werden müssen. Zu den nicht mitgesicherten Informationen zählen beispielsweise die Verlinkungen der Richtlinien. Das GPMC-Backup sichert nicht mit, auf welchen OUs die Richtlinie verknüpft war – diese Information wird nämlich weder im SYSVOL noch im AD-Container der Richtlinie gespeichert, sondern im Attribut gpLink der verknüpften OU. Das Attribute gpLink enthält eine Auflistung aller Richtlinien, die mit der OU verlinkt wurden. Dabei ist die Liste entsprechend der Nummerierung, die in der GPMC zu sehen ist, aufgebaut.
Ähnlich geht es der Information, in der das GP-Attribut „Erzwungen“ gespeichert wird. „Erzwungen“ ist dafür verantwortlich, dass Einstellungen einer GPO nicht durch eine später abgearbeitete GPO überschrieben werden können. Administratoren können somit verhindern, dass beispielweise OU-Administratoren in eigenen GPOs identische Einstellungen konfigurieren, jedoch mit aufhebenden Konfigurationen. „Erzwungen“ wird ebenfalls nicht bei der Gruppenrichtlinie gespeichert, sondern mit der OU im Attribut gpOptions. Ist der Attributwert von gpOptions „1“, ist „Erzwungen“ aktiviert.
Wer WMI-Filter für die Verarbeitung seiner Gruppenrichtlinien einsetzt, sollte ebenfalls vorsichtig sein: WMI-Filter werden nicht als Ganzes mit Gruppenrichtlinien gespeichert, sondern ebenfalls in Active Directory als Objekt abgelegt: CN=<GUID>,CN=SOM,CN=WMIPolicy,CN=System,DC=domain,DC=tld. Zumindest die GUID des WMI-Filters mitgesichert, sodass beim Wiederherstellen einer GPO, sollte der WMI-Filter noch im System vorhanden sein, die Verlinkungen zwischen GPO und WMI-Filter erneut erstellt wird.
Möchte man Richtlinien sichern, die IPSec-Filter auf Zielmaschinen ausrollen, kann man sich am Verhalten von WMI-Filtern orientieren: auch IPSec-Filter werden nicht in der Gruppenrichtlinie gespeichert, sondern in CN=<Filterart><GUID>,CN=IP Security,CN=System,DC=domain,DC=tld, was bedeutet, dass IPSec-Filter mit einer Systemstatesicherung des Verzeichnisses gesichert und getrennt wiederhergestellt werden müssen.
Grundlegend gilt also, dass die GPMC alle Daten einer GPO sichert, die mit einer Gruppenrichtlinie in Active Directory und in der SYSVOL-Freigabe gespeichert werden. Andere Daten, die an speziellen Orten im Verzeichnis hinterlegt sind, werden nicht gesichert.
Eine Liste der Daten die im GPMC-Backup gesichert werden und welche nicht, listet der TechNet-Artikel „Backup using GPMC: Group Policy“, http://technet.microsoft.com/en-us/library/cc784474.aspx.
Um die nicht mit der gesicherten GPO Daten dokumentieren zu können und sie im Wiederherstellungsfall zurückkonfigurieren zu können, gibt es ein großartiges Werkzeug: die GPMC (unser Sackmesser)!
Unsere GPMC erstellt nämlich bei der GPO-Sicherung einen HTML-Bericht, den sie zusammen mit dem Backup als XML-Datei im Sicherungsordner als „gpreport.xml“ ablegt. Ruft man für die Wiederherstellung den Dialog „Sicherungen verwalten“ auf und wählt darin „Einstellungen anzeigen“ für eine gesicherte GPO, öffnet der Assistent den zur GPO gesicherten HTML-Bericht im Browser. Aus der XML-Datei wird ein HTML-Bericht generiert.
Bemerkenswert ist hierbei, dass ein zusätzlicher Abschnitt namens „Allgemein“ erstellt wird, der oberhalb der eigentlichen Computer- und Benutzereinstellungen angezeigt wird. Dieser Abschnitt ist, wählt man eine GPO in der GPMC aus, nicht im Reiter „Einstellungen“ zu sehen. Hinter „Allgemein“ verbergen sich alle wichtigen Metadaten der GPO – etwa die Verknüpfungen mit den OUs oder die Information, ob die Richtlinie als „Erzwungen“ konfiguriert war.
Wer einen HTML-Bericht seiner Gruppenrichtlinien manuell erstellen möchte, kann das auch über die Funktion „Bericht speichern“ tun. Auch hier wird der zusätzliche Abschnitt „Allgemein“ gesichert. Dieses Vorgehen kann vor allem dann nützlich sein, wenn man Änderungen an seinen Gruppenrichtlinien nachverfolgen oder die Einstellungen einer GPO zu einem bestimmten Zeitpunkt dokumentieren will.
Für Fans von Skripten, die ihre GPOs gerne automatisiert sichern und HTML-Berichte wie von Geisterhand erstellen lassen möchten, wird im „Scripts“-Ordner der GPMC für Windows XP eine Reihe von Beispielskripten mitgeliefert, die diese Arbeit automatisch erledigen können. GPO-Administratoren von Windows Vista oder Windows 7, die die GPMC per Remote Server Administration Tools (RSAT) installiert haben, können die Beispielskripts seperat herunterladen: http://www.microsoft.com/downloads/details.aspx?familyid=38c1a89b-a6d2-4f2a-a944-9236999aee65&displaylang=en&tm. Einzelne Richtlinien können etwa mit dem Skript „BackupGPO.wsf“ gesichert werden, während ein Bericht für eine GPO per „GetReportsForGPO.wsf“ erstellt werden kann.
Viel Spaß beim Sichern und bis zum nächsten Mal!
Cheers,
Florian
* Rechtlicher Hinweis: Bei den hier als "Gastbeitrag" markierten Artikeln handelt es sich um Blogs, die von nicht-Microsoft Mitarbeitern verfaßt wurden. Diese Beiträge geben ausschließlich die Meinung des jeweiligen Autors wieder und stimmen nicht unbedingt mit der Meinung von Microsoft überein. Microsoft macht sich diese Beiträge ausdrücklich nicht zu eigen. Eine Vorabkontrolle der Beiträge findet nicht statt. Dementsprechend kann Microsoft keine Verantwortung oder Gewähr für die Beiträge übernehmen.
Servus, Fabian hier. Seit einigen Tagen ist das Service Pack 2 für Windows Vista verfügbar. Im Dokument Hotfixes and Security Updates in Windows Server 2008 SP2 and Windows Vista SP2 wird angegeben, daß die in KB943729 angesprochenen Group Policy Preferences CSEs im Service Pack integriert sind – dies ist jedoch nicht der Fall.
Unter Windows Server 2008 RTM (SP1) waren die Group Policy Preferences CSEs direkt mit dabei, unter Vista müssen Sie derzeit jedoch nachinstalliert werden. Das Service Pack 2 für Windows Vista liefert die CSEs nicht mit.
Versucht man nun jedoch auf einem Windows Vista SP2 System die GPP CSEs zu installieren (KB943729), wird die Installation mit dem Fehler „The update does not apply to your system“ abgebrochen.
Das Problem ist uns bekannt und es wird nach derzeitigem Kenntnisstand schnellstmöglich eine aktualisierte Version der Installationsroutine für die GPP CSEs geliefert werden. Im Moment hilft der Workaround, vor einer Installation des SP2 für Windows Vista (also etwa auf Windows Vista mit SP1) die GPP CSEs über KB943729 zu installieren.
Sobald eine aktualisierte Fassung der Installationsroutine verfügbar ist, werden wir den Blog Eintrag hier mit dem Downloadhinweis aktualisieren.
Update 29.05.2009: Das Excel Dokument wurde entsprechend angepaßt, so daß der Hotfix nicht mehr als Windows Vista SP2 integriert angegeben wird: http://technet.microsoft.com/en-us/library/dd335033(WS.10).aspx
Viele Grüße
Fabian
Hi, Fabian hier. Oft gehen bestimmte Informationen im Hintergrundrauschen der täglich zu bewältigenden Informationsflut unter – daher auch von unserer Seite ein kurzer Hinweis darauf, daß seit kurzer Zeit deutschsprachige Technet Foren zur Verfügung stehen.
Ihr findet die Foren hier: http://social.technet.microsoft.com/Forums/de-DE/categories oder etwas kürzer über folgenden Link: http://www.technet-foren.de
In den Foren gibt es neben anderen Themen auch eine „Active Directory“ Kategorie – sicher ist das für den einen oder anderen von Euch interessant.
Happy posting,
Fabian
Moin, Fabian hier mit einem kurzen Hinweis: Relativ häufig sehen wir in letzter Zeit Anfragen zu DCPROMO Problemen mit Windows Server 2008 DCs, bei denen schlichtweg eine Firewall das Problem darstellt. Insbesondere beim DCPROMO über Standortgrenzen hinweg treten hier dann Fehler auf. Im Gegensatz dazu läuft ein DCPROMO von Windows Server 2003 Systemen problemlos.
Im der DCPROMO Logdatei “%SYSTEMROOT%\debug\DCPROMO.log” sieht das dann in etwa so aus:
05/20/2009 10:50:35 [INFO] Creating the NTDS Settings object for this Active Directory Domain Controller on the remote AD DC DC01.contoso.com...
05/20/2009 10:50:36 [INFO] Replicating the schema directory partition
05/20/2009 10:50:58 [INFO] EVENTLOG (Error): NTDS Replication / Setup : 1125
The Active Directory Domain Services Installation Wizard (Dcpromo) was unable to establish connection with the following domain controller.
Domain controller:
DC01.contoso.com
Additional Data
Error value:
1722 The RPC server is unavailable.
05/20/2009 10:50:58 [INFO] Error - Active Directory Domain Services could not replicate the directory partition CN=Schema,CN=Configuration,DC=contoso,DC=com from the remote Active Directory Domain Controller DC01.contoso.com. (1722)
05/20/2009 10:50:58 [INFO] EVENTLOG (Error): NTDS General / Service Control : 2047
Cannot replicate configuration and schema information. Check network and server availability.
05/20/2009 10:50:58 [INFO] EVENTLOG (Informational): NTDS General / Service Control : 1004
Active Directory Domain Services was shut down successfully.
05/20/2009 10:50:58 [INFO] NtdsInstall for contoso.com returned 1722
05/20/2009 10:50:58 [INFO] DsRolepInstallDs returned 1722
05/20/2009 10:50:58 [ERROR] Failed to install to Directory Service (1722)
Hintergrund ist bei einem solchen Fehler oft eine Firewall Einschränkung der „high ports“, d.h. die hohen Ports werden limitiert nur im Bereich von 1.024 – X (z.B. 2.000) freigegeben. Diese hohen Ports werden neben anderen Diensten unter anderem für die dynamische RPC Port Zuweisung genutzt.
Hier gab es jedoch unter Windows Server 2008 Änderungen im Vergleich zu Windows Server 2003, d.h. standardmäßig beginnt ein Windows Server 2008 Server nun nicht mehr bei TCP Port 1.024, wenn er eine dynamische Portzuweisung durchführt, vielmehr beginnt das System nun bei TCP Port 49.152. Sind nun die hohen Ports beschränkt, läuft man schnell in Probleme.
Daher sei an dieser Stelle explizit noch einmal der Hinweis auf den folgenden KB-Artikel gegeben, der dazu Informationen liefert:
929851 The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929851
Zusätzliche Informationen zu den Port Anforderungen finden sich neben einigen anderen Dokumenten auf Technet unter anderem auch hier:
179442 How to configure a firewall for domains and trusts
http://support.microsoft.com/default.aspx?scid=kb;EN-US;179442
Volles DCPROMO voraus,
Fabian
Hallo, Fabian hier. Mit zunehmender Verbreitung der Group Policy Preferences (GPP) stellen wir fest, daß die Frage nach der Priorität der Anwendung von GPP im Vergleich zu normalen Group Policy Objects (GPOs ) zunimmt. Leider auch bedingt durch die ein oder andere nicht ganz korrekte Dokumentation von uns aus der Anfangszeit, nachdem die GPP in unsere Produktpalette integriert wurden, hält sich hartnäckig das Gerücht, daß normale GPOs grundsätzlich Vorrang vor den Group Policy Preferences hätten. Dem ist jedoch nicht so.
An dieser Stelle nur ein kurzer, stark vereinfachter Ausflug in die Theorie der Gruppenrichtlinienverarbeitung: Wenn ein Client die für ihn oder den angemeldeten Benutzer eingesetzten Gruppenrichtlinien abarbeitet, gibt es im Grunde zwei Stufen - zuerst wird im Core Processing geprüft, welche Gruppenrichtlinien überhaupt wirken und ob die benötigten Zugriffsrechte / WMI-Filter etc. den Zugriff auf die Richtlinie ermöglichen. Hierbei werden auch die Daten ausgelesen, welche Komponenten in den Gruppenrichtlinien konfiguriert sind. Diese Komponenten sind zum Beispiel die Sicherheitseinstellungen, die administrativen Vorlagen, Softwareverteilung, Drahtlosverbindungseinstellungen etc. – und eben auch die GPP Komponenten. Für jede dieser Komponenten ist eine sogenannte Client Side Extension zuständig (CSE), die durch eine *.dll realisiert ist.
Nun treten wir mit der Abarbeitung der Gruppenrichtlinien in die zweite Phase ein: Nachdem wir durch das Core Processing wissen, welche Gruppenrichtlinien überhaupt greifen und welche Komponenten (Client Side Extensions) in den Richtlinien angesprochen werden, lesen wir die Richtlinieneinstellungen aus und bringen sie nacheinander zur Anwendung. Hierbei wird der sogenannte Richtlinienergebnissatz (Resultant Set of Policy - RSOP) errechnet - d.h. jede Komponente wird die Ihr bekannten anzuwendenden Einstellungen prüfen und zusammenführen, um dann letztendlich die "gewinnenden" Einstellungen auf dem Client vorzunehmen. Hier kann sich jede CSE unterschiedlich verhalten - die administrativen Vorlagen etwa, die über die Registry-CSE angewendet werden, schreiben tatsächlich die Einstellungen jeder einzelnen angewendeten Policy nacheinander in die Registrierung. Hingegen wird bei mehreren Policies mit Startup-Scripts nur die Policy mit der höchsten Priorität angewendet werden, d.h. die CSE arbeitet "ersetzend", nicht "ergänzend".
Die Group Policy Preferences bringen eigene CSEs mit, daher sind sie komplett eigenständig und auch für die GPP CSEs wird also ein eigener RSOP errechnet. Es findet kein Abgleich mit den "alten" GPOs (bzw. GPO CSEs) statt.
Die auf einem Client vorhandenen CSEs kann man unter folgenden Registrierungsschlüssel überprüfen: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions
Siehe dazu auch 216357 Identifying Group Policy Client-Side Extensions http://support.microsoft.com/kb/216357/en-US.
Klickt man sich hier ein wenig durch, findet man unter den GUIDs auch die entsprechenden Namen der CSE und die dazugehörige *.dll.
Die CSEs werden nacheinander in alphabetischer Reihenfolge abgearbeitet, d.h. die GUID der jeweiligen CSE entscheidet, wann genau in Phase zwei, also dem CSE Processing, bei der Gruppenrichtlinienverarbeitung die Anwendung einer Einstellung auf dem Client erfolgt. Ausnahme ist hierbei die GPO Registrierungs-CSE, diese wird immer zuerst abgearbeitet, unabhängig von der alphabetischen Anordnung der GPO Registrierungs-CSE {35378EAC-683F-11D2-A89A-00C04FBBCFA2}. Ansonsten kann man die Abarbeitungsreihenfolge anhand der Anordnung im Registrierungseditor genau voraussehen.
Ok, zurück zur praktischen Bedeutung dieser grauen Theorie: Definiert man nun also unterschiedliche Einstellungen in unseren GPOs und zusätzlich auch diesen GPOs widersprechende Group Policy Preferences, gewinnt eben nicht unbedingt die GPO, nur weil man dieser GPO etwa eine höhere Priorität zugewiesen hat. Vielmehr entscheidet der Zeitpunkt der Abarbeitung jeder einzelnen CSE, welche Einstellung gewinnt.
Definiert man beispielsweise in den Sicherheitseinstellungen (Security Templates) eine Einstellung, die bei der Abarbeitung einen Registrierungsschlüssel schreibt, und definiert zusätzlich die Einstellung "manuell" über die Group Policy Preferences Registry Einstellungen mit einem entgegengesetzten Wert, wird die Group Policy Preference gewinnen - die CSE wird schlichtweg später abgearbeitet:
[...]
Security, scecli.dll: {827D319E-6EAC-11D2-A4EA-00C04F79F83A}
[...]
Group Policy Registry, gpprefcl.dll: {B087BE9D-ED37-454f-AF9C-04291E351182}
Die Abarbeitung kann man auch gut in einem UserEnv / GPSVC Debug Log nachvollziehen. Hier schaut man in in die Abarbeitung der Gruppenrichtlinien und stellt fest, daß wie oben beschreiben die Registry CSE zuerst abgearbeitet wird und danach die Reihenfolge der Abarbeitung genau mit der Reihenfolge der GUIDs / CSEs übereinstimmt, die man auch in der Registrierung gesehen hat:
[…]
GPSVC(218.ac8) 21:41:46:732 ProcessGPOs: -----------------------
GPSVC(218.ac8) 21:41:46:732 ProcessGPOs: Processing extension Registrierung
GPSVC(218.ac8) 21:41:46:732 CompareGPOLists: The lists are the same.
GPSVC(218.67c) 21:41:46:733 ReadStatus: Read Extension's Previous status successfully.
GPSVC(218.ac8) 21:41:46:733 ProcessGPOs: Extension Registrierung skipped because both deleted and changed GPO lists are empty.
GPSVC(218.67c) 21:41:46:733 CompareGPOLists: The lists are the same.
GPSVC(218.ac8) 21:41:46:733 ProcessGPOs: -----------------------
GPSVC(218.67c) 21:41:46:733 CheckGPOs: No GPO changes and no security group membership change and extension Registrierung has NoGPOChanges set.
GPSVC(218.ac8) 21:41:46:733 ProcessGPOs: Processing extension Wireless Group Policy
GPSVC(218.67c) 21:41:46:733 ProcessGPOs: -----------------------
GPSVC(218.ac8) 21:41:46:733 CompareGPOLists: The lists are the same.
GPSVC(218.67c) 21:41:46:734 ProcessGPOs: -----------------------
GPSVC(218.ac8) 21:41:46:734 CheckGPOs: No GPO changes but couldn't read extension Wireless Group Policy's status or policy time.
GPSVC(218.67c) 21:41:46:734 ProcessGPOs: Processing extension Wireless Group Policy
GPSVC(218.ac8) 21:41:46:734 ProcessGPOs: Extension Wireless Group Policy skipped with flags 0x210002.
GPSVC(218.67c) 21:41:46:734 CompareGPOLists: The lists are the same.
GPSVC(218.ac8) 21:41:46:734 ProcessGPOs: -----------------------
GPSVC(218.67c) 21:41:46:734 CheckGPOs: No GPO changes but couldn't read extension Wireless Group Policy's status or policy time.
GPSVC(218.ac8) 21:41:46:734 ProcessGPOs: Processing extension Group Policy Environment
GPSVC(218.67c) 21:41:46:735 ProcessGPOs: Extension Wireless Group Policy skipped because both deleted and changed GPO lists are empty.
GPSVC(218.ac8) 21:41:46:735 CompareGPOLists: The lists are the same.
GPSVC(218.67c) 21:41:46:735 ProcessGPOs: -----------------------
[...]
GPSVC(218.ac8) 21:41:46:756 ProcessGPOs: -----------------------
GPSVC(218.67c) 21:41:46:756 ProcessGPOs: Processing extension Security
GPSVC(218.ac8) 21:41:46:758 CompareGPOLists: The lists are the same.
GPSVC(218.ac8) 21:41:46:758 CheckGPOs: No GPO changes but couldn't read extension Windows Search Group Policy Extension's status or policy time.
GPSVC(218.67c) 21:41:46:758 CheckGPOs: No GPO changes but couldn't read extension Security's status or policy time.
GPSVC(218.ac8) 21:41:46:758 ProcessGPOs: Extension Windows Search Group Policy Extension skipped because both deleted and changed GPO lists are empty.
GPSVC(218.ac8) 21:41:46:759 ProcessGPOs: -----------------------
[…]
Die Abarbeitung der CSEs von GPO und GPP erfolgt dementsprechend "vermengt" / mixed.
In jedem Fall ist also zu empfehlen, Einstellungen nur an einer Stelle vorzunehmen und nicht gleiche Einstellungen in GPO und GPP mit verschiedenen Werten zu versehen - das kann eine Vorhersage der Einstellung, die am Ende wirklich greift, recht komplex machen und sorgt für Probleme, sollte man doch einmal ein Troubleshooting durchführen müssen. Wenn man jedoch herausfinden möchte, welche Einstellung greifen würde, muß man die Abarbeitungsreihenfolge der CSEs betrachten, nicht die Reihenfolge / Priorität der jeweiligen Gruppenrichtlinie, in der die GPO Einstellungen / Preferences definiert wurde. Das ist “by design” und auch so gewünscht.
Die genannten Punkte gelten natürlich nur für Einstellungen, die 1:1 an die gleichen Stellen (etwa in der Registrierung) geschrieben werden. Schreibt eine GPP etwa in den HKEY_CURRENT_USER\Software Zweig und nicht in den HKEY_CURRENT_USER\Software\Policies Zweig, wie die meisten von uns mitgelieferten GPO Einstellungen, kann sich das Verhalten wiederum unterscheiden. Die jeweils damit konfigurierte Applikation entscheidet dann, welcher Schlüssel Vorrang hat. Ein Grund mehr die Konstellationen simpel und vor allen Dingen eindeutig zu halten - denn hier nimmt der Komplexitätsgrad der möglichen Ergebnisse noch einmal stark zu.
Viele Grüße
Fabian
Hallo, hier wieder einmal Rol mit einem Erfahrungsbericht. Zurück aus dem Urlaub habe ich nach der Wiederinbetriebnahme meine virtuellen Windows Server 2008 Domäne feststellen müssen, daß die AD Replikation nicht mehr funktioniert. DC RW08DC1 repliziert zwar problemlos von RW08DC2, umgekehrt aber nicht mehr.
REPADMIN /SHOWREPL zeigt dazu folgenden Fehler auf RW08DC2:
C:\Users\Administrator>repadmin /showrepl rw08dc2
Hub2\RW08DC2
DSA Options: (none)
Site Options: (none)
DSA object GUID: 500ac16c-8970-4b5f-8d15-f0f7c0ce219e
DSA invocationID: d2dcab05-f0e4-48fe-af8d-9c3913976b40
==== INBOUND NEIGHBORS ======================================
DC=RW08,DC=NET
Hub1\RW08DC1 via RPC
DSA object GUID: d0dab649-fe5b-4c50-9665-0a955b337c79
Last attempt @ 2009-04-01 13:04:33 failed, result -2146893022 (0x80090322):
The target principal name is incorrect.
7 consecutive failure(s).
Last success @ 2009-04-01 12:16:11.
Der Hintergrund für diesen Fehler wird klar, wenn man die Metadaten für das DC Konto RW08DC1 auf beiden DCs vergleicht.
Metadaten auf DC RW08DC1:
C:\Users\Administrator>repadmin /showmeta "cn=rw08dc1,ou=domain controllers,dc=rw08,dc=net" rw08dc1
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
12290 Hub1\RW08DC1 12290 2008-09-04 16:50:28 1 objectClass
12290 Hub1\RW08DC1 12290 2008-09-04 16:50:28 1 cn
...
61516 Hub1\RW08DC1 61516 2009-04-01 11:30:08 8 dBCSPwd
61516 Hub1\RW08DC1 61516 2009-04-01 11:30:08 8 unicodePwd
61516 Hub1\RW08DC1 61516 2009-04-01 11:30:08 8 ntPwdHistory
61516 Hub1\RW08DC1 61516 2009-04-01 11:30:08 8 pwdLastSet
Metadaten auf DC RW08DC2:
C:\Users\Administrator>repadmin /showmeta "cn=rw08dc1,ou=domain controllers,dc=rw08,dc=net" rw08dc2
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
7629 Hub1\RW08DC1 12290 2008-09-04 16:50:28 1 objectClass
7629 Hub2\RW08DC2 7629 2008-09-05 14:10:24 1 cn
...
49154 Hub1\RW08DC1 61452 2009-04-01 12:13:51 6 dBCSPwd
49154 Hub1\RW08DC1 61452 2009-04-01 12:13:51 6 unicodePwd
49154 Hub1\RW08DC1 61452 2009-04-01 12:13:51 6 ntPwdHistory
49154 Hub1\RW08DC1 61452 2009-04-01 12:13:51 6 pwdLastSet
Die Version das Passwortes für RW08DC1 ist in der Datenbank von DC RW08DC2 zwei Versionen älter als auf RW08DC1. Der DC RW08DC2 hat sich als KDC selbst ein Ticket für den Replikations-Zugriff auf RW08DC1 ausgestellt, allerdings mit einem bereits ungültigen Password (auch für die (n-1) Version). RW08DC1 lehnt den Zugriff ab, das erzeugt den Fehler “The target principal name is incorrect.”.
Die Lösung ist unter Windows 2008 ist nun wesentlich eleganter als noch unter Windows Server 2003 oder 2000. Wie zuvor muß man den DC RW08DC2 nur dazu bringen nicht sich selbst, sondern RW08DC1 als KDC zu verwenden. Hierbei kann man jetzt aber ein essentielles Windows Server 2008 Feature nutzen.
1) Dazu stoppt man auf RW08DC2 über den Server Manager oder Services.msc den KDC Dienst “Kerberos Key Distribution Center” und setzt den Startup Type auf Disabled.
2) Auf RW08DC2 startet man nun auch noch den NTDS Dienst “Active Directory Domain Services” neu.
Dies ist erst mit Windows Server 2008 möglich, dadurch werden die im Dienst Kontext gecachten Tickets beim Stoppen verworfen. Beim Start wird nun der KDC nicht mit gestartet (steht auf Disabled) und RW08DC1 als KDC verwendet. Jetzt stimmen auch wieder die entsprechenden Kerberos Tickets für die Replikation von RW08DC1.
3) Nach der erfolgreichen Replikation von RW08DC1 stellt man den Startup Type des KDC Dienst “Kerberos Key Distribution Center” auf Automatc und startet den Dienst. Damit hat man wieder den Normalzustand erreicht.
Unter Windows Server 2003 und 2000 war der Ticket Cache mit dem System Prozess LSASS.EXE verknüpft und daher ein kompletter Reboot notwendig, um das gleiche zu erreichen. Das neue Windows Server 2008 Feature des NTDS Dienstes verringert hier die Downtime für den DC also erheblich.
Damit frohes Schaffen und viele Grüße aus München, Rol
Hallo, heute mal wieder ein Gastbeitrag aus dem Netzwerk Team. Diesmal von Hubert mit seinem ersten Eintrag im „Aktiven Verzeichnis“.
Bei uns laufen immer wieder Anfragen auf, bei denen es um eine schlechte Netzwerkperformance insbesondere von Fileservern geht. Oft stellen wir fest, dass Access-based Enumeration (ABE) auf den Shares dieser Server aktiviert ist.
Deshalb möchte ich im folgenden etwas näher auf die Faktoren eingehen, die einen Einfluss auf die Performance der Server mit ABE haben, welche Möglichkeiten zur Verbesserung bestehen, und wie man erkennt, ob ABE der Grund für Performance Probleme auf einem bestimmten Server ist.
Was ist Access-based Enumeration?
Seit Windows 2003 SP1 ist ABE ein eingebautes Feature der Windows Server Reihe. Wenn es auf einen Ordner aktiviert wird (meist ein Share) so sieht ein Benutzer unterhalb dieses Ordners nur die Objekte (Dateien und Ordner) auf die er mindestens Leserechte hat, sofern der Zugriff über das Netzwerk erfolgt. Erfolgt der Zugriff lokal auf das Verzeichnis, so wirkt ABE nicht, und der Benutzer sieht wie üblich alle Dateien und Ordner.
Ein wie ich finde schönes Beispiel zum Sinn und Zweck von ABE gestaltet sich wie folgt:
Ein User (nennen wir ihn Bob) stolpert beim browsen durch das Share über einen Ordner namens „Kündigung CEO Februar 2009“.
Auch wenn Bob den Ordner nicht öffnen kann reicht ihm diese Information, um alle seine Aktien zu verkaufen, und seinen Kollegen ebenfalls zu diesem Schritt zu raten. Kurze Zeit nachdem der Chef gekündigt hat, und die Aktien-Kurse wie erwartet in den Keller gefallen sind fällt jemanden auf, dass kurz vor der Kündigung mehrere Mitarbeiter ihre gesamten Aktien verkauft haben. Schon hat man jemanden im Nacken sitzen, der einem etwas von Insider Handel erzählt.
In manchen Fällen reicht also schon der Ordnername aus, um sensitive Informationen preiszugeben. Mit ABE hätte Bob den Ordernamen gar nicht gesehen.
Einen guten Einblick bietet auch das ABE Whitepaper: http://www.microsoft.com/downloads/details.aspx?FamilyId=04A563D9-78D9-4342-A485-B030AC442084&displaylang=en
Im Abschnitt Limitations ist zu lesen:
"ABE can also demand CPU resources from file servers. However, Microsoft benchmarking tests indicate that even for very large file structures, running ABE only consumes two to three percent of CPU cycles. Administrators must use their judgment in balancing security and performance on file servers, even when the overhead is small."
Genau bei diesem “judgment” möchte ich mit diesem Beitrag helfen.
Wie funktioniert ABE?
Wenn der Client den Inhalt eines Verzeichnisses abfragt erhält er, wenn ABE aktiviert ist, nur die Dateien und Ordner übermittelt, auf die der jeweilige Benutzer Berechtigungen hat. Die Filterung findet also auf dem Server statt.
Um entscheiden zu können, ob der Server ein bestimmtes Objekt an den Client übermitteln darf muss er die Access Control List (ACL) des Benutzers mit der ACL des jeweiligen Objektes vergleichen. Dies ist naturgemäß recht CPU-Intensiv und kann insbesondere bei komplexen Shares mit vielen Objekten in einem Verzeichnis für sehr grosse Last auf dem Server sorgen. Dies äussert sich normalerweise auf dem Server durch eine hohe CPU-Auslastung und eine erhöhte Processor Queue Length.
Insbesondere wenn die Processor Queue Lenght hoch ist, kann es auf dem Client zu erheblichen Wartezeiten kommen. Meist äussert sich dies darin, dass es lange dauert, bis der Inhalt eines Ordners auf einem Share angezeigt wird und kann sogar soweit gehen, dass der Windows Explorer mit „not responding“ für einige Zeit hängen bleibt. Die selben Symptome können natürlich auftreten, wenn der Server aus anderen Gründen (Virenscan, Backup, etc.) unter hoher Last läuft.
Welche Faktoren spielen eine Rolle?
Um dieser Probleme Herr werden zu können, müssen wir erst einmal wissen, welche Faktoren bei den Lastanforderungen von ABE eine Rolle spielen:
- Anzahl der zeitgleichen Zugriffe / gleichzeitig arbeitender Benutzer
- Anzahl der Objekte in einer Hierarchie-Ebene, auf die ABE wirkt
- Rechtestruktur auf dem Share
- Komplexität der Benutzer-ACL (Anzahl der Gruppen und Verschachtelungen)
- der verwendete Client spielt indirekt eine Rolle
Im Folgenden wird detailierte auf die einzelnen Faktoren und ihre Auswirkungen eingegangen:
Zugriffe
Das die Anzahl der gleichzeitigen Zugriffe eine Auswirkung auf den Leistungsbedarf hat dürfte naheliegend sein.
Wie viele Zugriffe gleichzeitig auf dem Server auftreten ist jedoch noch von anderen Faktoren abhängig. Hierzu zählt natürlich die Anzahl der aktiven Benutzer insgesamt, aber auch die Dauer eines Zugriffes. Stellt der Server zum Beispiel das gesamte Netzwerkshare bereit, so werden die Verbindungen länger dauern und somit sich mit einer höheren Wahrscheinlichkeit zeitlich überschneiden, als würde der Server nur einen Teil des Shares (z.B. durch DFS) bereit stellen. Die Anzahl der Zugriffe pro Zeit wird natürlich auch durch das Benutzerverhalten beeinflusst, dass sich meist nicht realistisch für einen Test abbilden lässt.
Objekte
Die Dauer einer einzelnen ABE-Berechnung (ACL Vergleiche) wird durch die Anzahl der zu berechnenden Objekte beeinflusst.
ABE betrachtet hierbei pro Berechnung lediglich ein einziges Verzeichnis. Sind in diesem Verzeichnis viele Objekte enthalten, dauert es entsprechend länger die Berechnung durchzuführen, als wenn nur wenige Objekte vorhanden wären. Je länger die Berechnung dauert umso länger ist natürlich auch die CPU beschäftigt und umso länger dauert es bis der Client sein Ergebnis (die Liste an Objekten) erhält.
Struktur
Bei der Rechtestruktur sind insbesondere die Berechtigungen auf der höchsten Ebene interessant. Hat ein Benutzer zum Beispiel nur Zugriff auf einen von zwei Ordnern auf der höchsten Ebene, so hat man damit den Baum, den er sehen kann, und damit die Anzahl an ABE-Berechnungen die durchgeführt werden müssen, halbiert (einen symmetrischen Aufbau des Baums vorausgesetzt).
Benutzer-ACL
Da bei den Berechnungen die Access Control List des Benutzers mit der des Objektes verglichen wird, spielt es natürlich ebenso eine Rolle in wie vielen Gruppen der Benutzer Mitglied ist und wie komplex die Verschachtelung der Gruppen angelegt ist. Wie bei vielem gilt auch hier: Je schlanker, je schneller.
Client
Der Client mit dem zugegriffen wird (meist Windows Explorer) spielt eine entscheidende Rolle beim serverseitigen Leistungsbedarf.
Als Beispiel sei hier das Kommandozeilen „dir“ im Gegensatz zum Windows Explorer benannt. Beim ausführen des Befehls „dir“ auf ein auf das Share verbundenes Netzlaufwerk löst dies eine ABE-Berechnung für eine einzige Ebene aus. Greift man hingegen mit dem Windows Explorer auf dieses Netzlaufwerk zu, so parsed dieser beim ersten Zugriff das gesamte (sichtbare) Share bis in die unterste Ebene durch. Hierdurch wird in jedem Verzeichnis aufs Neue eine ABE-Berechnung ausgelöst. Dies verursacht demzufolge eine ganz andere Last als ein simples „dir“.
Was hierbei ebenfalls zum tragen kommt, ist die Tatsache, dass der Windows Explorer in seiner Standard-Konfiguration zusätzlich Previews der Dateien generiert, Thumbnails und Dateityp-spezifische Informationen lädt. Dies erzeugt zusätzlichen Netzwerkverkehr und auf dem Fileserver daher zusätzliche Last, was ebenso zu einer Verschlechterung der Antwortzeiten insbesondere bei sehr großen Shares führen kann. Die grösste Last verursacht jedoch eine Suche auf dem Share, da hierbei jede einzelne Datei „angepackt“ wird.
Andere wichtige Punkte
Zwei Punkte gibt es noch, die zusätzlich erwähnt werden müssen:
- Die ABE-Berechnungen werden nur dann an unterschiedliche CPUs des Servers verteilt, wenn sie von unterschiedlichen Netzwerk-Clients stammen.
Wenn ein Benutzer also sehr viele Berechnungen auslöst (zum Beispiel durch eine Suche auf dem Share) werden alle diese Anfragen in einer einzigen CPU abgearbeitet und können dazu führen das diese CPU komplett „aufgebraucht“ wird.
Alle weiteren Anfragen für diese CPU landen also erst mal in der Warteschlange (Processor Queue Length) bevor sie abgearbeitet werden können.
Daher ist Vorsicht bei der Verwendung von Terminal-Servern auf ABE-Shares geboten.
- ABE hat keinen Cache und muss daher bei jedem Zugriff auf ein Verzeichniss alle darin enthaltenen Objekte daraufhin prüfen, ob der Client sie sehen darf oder nicht. Der Grund hierfür sind Sicherheitsüberlegungen:
Wenn ABE einen Cache hätte und man würde die Berechtigungen eines Benutzers verändern, so wäre diese Änderung für die Ansicht erst nach Verfall des Caches wirksam.
Der Benutzer könnte also in der Zwischenzeit
- Objekte sehen auf die er keine Rechte (mehr) hat.
- Objekte nicht sehen auf der er (jetzt) Berechtigungen hat.
Do’s and Dont’s
Bevor wir tiefer einsteigen wie man die Performance verbessern kann hier ein paar grundsätzliche Dinge:
- Clients dürfen den Server nicht nach Viren scannen:
Hierdurch wird (egal ob mit oder ohne ABE) eine hohe und unnötige Last verursacht. Aufgrund der Berechtigungen kann ohnehin kein Client den gesamten Fileserver scannen.
- Applikationen nicht von Netzlaufwerken aus starten:
Beim Starten von Applikationen werden unter anderem DLLs geladen was wiederum ABE-Berechnungen auslöst.
- Einschränkung des Zugriffs möglichst weit oben auf dem Share:
Wie bereits erwähnt: Desto weniger Ordner der Benutzer auf der höchsten Ebene sieht, desto weniger Berechnungen müssen insgesamt durchgeführt werden.
- Schlanke Verzeichnisse:
Desto weniger Objekte in einem Verzeichniss, desto kürzer dauert die ABE Berechnung für dieses Verzeichniss.
- Scalable Networking Pack verwenden:
Hierdurch kann die CPU sehr stark entlastet und somit die Leistungsfähigkeit der Server gesteigert werden, sofern die Netzwerkkarten dies unterstützen:
Ref: SNP FAQ
http://www.microsoft.com/technet/network/snp/faq.mspx
Q. What types of workloads can benefit from Scalable Networking Pack enhancements?
A. The Scalable Networking Pack can improve the performance and scalability of such data-heavy workloads as file storage, backups, Web servers, and media-streaming. Depending on the workload, overall performance gains can range from 20 percent up to nearly 100 percent reduction of network packet processing overhead and increase network throughput up to 40 percent.
Um bekannte Probleme beim Einsatz des SNP zu vermeiden, sollte unbedingt das SNP Hotfix Rollup Package KB950224 installiert werden: http://support.microsoft.com/kb/950224/en-us
- Wenn irgend möglich die Last auf mehrere Server verteilen:
Hier gibt es neben dem klassischen Clustering auch noch DFS als sehr gute Option.
In diesem Falle empfhielt es sich die oberen Ebenen des Shares in ein DFS oder in eine DFS-Kaskade zu verlegen und das ABE auf den DFS-Links zu aktivieren.
Somit erfolgt die Filterung nur auf einer (oder bei einer Kaskade mehreren) Ebenen aber nichtmehr im gesamten Baum. Hierdurch wird die Anzahl der ABE Berechnungen stark reduziert.
Die DFS-Server haben (sofern nichts CPU-lastiges auf ihnen läuft) im Gegensatz zu den Fileservern meist genügend Reserven für die ABE-Berechnungen.
Bei mehreren DFS-Servern mit ABE auf den Links wird die ABE-Last auf mehrere Server verteilt, da die Clients per Zufall immer einen anderen Server im eigenen Standort kontaktieren.
Es ist wesentlich einfacher einen weiteren DFS-Server einzubinden als einen zusätzlichen Fileserver.
Hierbei gibt es jedoch ein paar Punkte zu beachten:
Vorsicht, wenn die DFS-Server gleichzeitig DCs sind!
Unter zu hoher CPU-Last (durch ABE) kann es passieren, dass keine Anmeldungen mehr möglich sind.
Die ACLs auf den DFS-Links und auf den Link-Targets müssen richtig gesetzt werden.
Siehe hierzu auch:
http://support.microsoft.com/kb/907458/en-us und http://support.microsoft.com/kb/961658/en-us
- Regelmässiges Überwachen der Performance:
Wenn sich einer der oben benannten Faktoren ändert, kann dies Auswirkungen auf die ABE-Performance haben.
Hierzu zählen aber nicht nur das Anwachsen der Shares oder veränderte Benutzer Berechtigungen, sonder auch neue Applikationen die in die Umgebung gebracht werden, und beispielsweise auf Shares zugreifen um dort Daten zu speichern.
Daher sollte, am Besten in Form eines regelmässigen Performance Audits, die Last auf den Server überwacht werden um sie mit Ergebnissen voriger Analysen zu vergleichen.
Somit können frühzeitig Gegenmassnahmen ergriffen werden ohne unter akutem Zugzwang zu stehen.
Neben den üblichen Performance Countern (Processor, Memory, Disk, Network, Process) sollten noch zwei weitere Counter aufgezeichnet werden.
Dies ist zum einen die bereits erwähnte System\Processor Queue Length aber auch Server\ File Directory Searches. Letzterer zeigt die Anzahl gleichzeitger Datei-Suchen auf dem Server an. Wie oben beschrieben kann eine Suche einen sehr negativen Einfluss auf die Performance haben.
Hilfestellung bei der Analyse der Counter kann der folgende Technet-Artikel liefern.
Auch wenn sich dieser explizit auf Exchange Server bezieht, sind viele der Werte und insbesondere die Bedeutung der Counter übertragbar:
http://technet.microsoft.com/en-us/library/cc671175.aspx
Kann man das irgendwie testen?
Der Leistungshunger von ABE hängt von den oben beschriebenen Faktoren ab. Einige dieser Faktoren (z.B. Benutzerverhalten) lassen sich nicht realistisch in einer Testumgebung nachstellen. Hinzu kommt (siehe Whitepaper), dass der Leistungsbedarf von ABE nicht Linear ansteigt.
Das bedeutet man kann nicht von einem kleinen Test-Szenario auf eine grössere Live-Umgebung Rückschlüsse ziehen. Die einzige Chance die also besteht, ist zu ertesten welche Last einem einzelnen Server zugemutet werden kann, so dass die Antwortzeiten für die Clients noch in Ordnung sind und auch Peak-Belastungen abgefangen werden können.
Basierend darauf kann dann überlegt werden, wie viele Server man für den Einsatz von ABE (zusätzlich) braucht. Im Folgenden skizziere ich ein Testkonzept hierzu:
Man nehme einen Server und setzte ihn 1:1 wie die Maschinen in der Produktiv-Umgebung auf. Dies gilt ebenfalls für die Shares auf diesen Maschinen. Das bedeutet sie sollten in Struktur und Umfang denen aus der Produktiv-Umgebung gleichen. Am besten also einfach alle Daten rüber kopieren. Genauso müssen auf dieser Test-Maschine natürlich die zusätzlichen Applikationen die in der Produktion (z.B. Virenscanner, Verschlüsselung, etc.) installiert und konfiguriert werden.
Hatte ich schon erwähnt, dass natürlich auch die Hardware der Produktion entsprechen muss?
Wenn der Server vorbereitet ist, geht es nun an die Clients. Wir brauchen mindestens einem Hardware Client mehr als der Server Cores hat (siehe „Andere Wichtige Punkte“ weiter oben). Würden wir z.B. nur 3 Hardware-Clients bei einem Quad-Core Server verwenden, so würden nur 3 Kerne unter Last gesetzt und wir somit kein aussagekräftiges Ergebnis erhalten. Diese Clients sollten ebenfalls analog mit allen Programmen zu einem Produktiv-Client aufgesetzt werden.
Zum Schluss brauchen wir noch ein paar Benutzer.
Mein Vorschlag ist erst mal 50 Benutzer (je nach Dimension des Servers) anzulegen und sie entsprechend auf den Shares zu berechtigen. Auch hier wieder alles analog zur Produktion (also mit Verschachtelung, unterschiedlicher Verrechtung, etc.).
Je nach Ergebniss (weiter unten) müssen ggf. noch weitere Benutzer angelegt werden um den Server auszulasten. Um sich eine Menge Tipp-Arbeit zu ersparen sollte ein kleines Skript vorbereitet werden, dass ein Netzlaufwerk gegen das Share verbindet und in einer Schleife mit einem 10 Sekunden Sleep ein dir /s auf dieses Laufwerk ausführt.
Nun können wir mit dem eigentlichen Test beginnen:
- An jedem der Hardware Clients wird ein Benutzer angemeldet.
- Nun werden zum Beispiel mit "runas" gleichmässig über alle Clients verteilt Kommandozeilen im Kontext der übrigen Benutzer angemeldet.
- Bei 5 physikalischen Clients und 50 Benutzern haben wir also dann auf jeder Maschine einen Benutzer direkt angemeldet und 9 Kommandozeilen Fenster offen.
- Nun wird über alle Maschinen gleichmässig verteilt unser Testskript (dir /s gegen das LW) aufgerufen.
- Sobald die erste Handvoll Skripts läuft sollte die Last auf dem Server überwacht und zusätzlich durch ein Browsen des Netzlaufwerks mit dem Windows Explorer vom Client aus überprüft werden, ob die Antwortzeiten in Ordnung sind.
Sind die Werte in Ordnung, kann die Last durch ausführen weiterer Skripte gesteigert werden bis die Antwortzeiten schlechter werden, oder der Server an seine Grenzen stösst. Notfalls müssen weitere Benutzer angelegt, verrechtet und per runas angemeldet werden.
- Die Anzahl der Benutzer sollte so variiert werden, dass
- der Server gut ausgelastet ist
- die Antwortzeiten für die Clients in Ordnung sind
- zusätzliche Suchanfragen gegen das Share (Start -> Suchen) möglich sind ohne das die Antwortzeiten zu sehr darunter leiden
- Reserven für andere Aufgaben (sofern nötig) und Peak-Zeiten bleiben
Zusätzlich sollte insbesondere bei Fileservern durch Kopieren grösserer Datenmengen die Last von Up- und Download-Vorgängen auf dem Server simuliert werden. Wenn diese Bedingungen erfüllt sind, kann man sich auf dem Server nun im Computer Management unter Sessions anschauen, wie viele Verbindungen der Server gleichzeitig bedienen kann.
Wenn man dies mit der Anzahl der gleichzeitigen Sessions in der Produktiv-Umgebung vergleicht bekommt man ein Gefühl dafür, wie viele Server für den Einsatz von ABE benötigt würden.
Aber VORSICHT!
Aufgrund der vielen Unwägbarkeiten in diesem Testszenario, vor allem weil man das Benutzerverhalten nicht realitätsnah abbilden kann, kann dieser Test nur einen groben Anhaltspunkt liefern. Was dieser Test jedoch leisten kann ist folgendes:
In vielen Umgebungen sind obige Parameter nicht einfach so änderbar. Dies gilt insbesondere für einen der kritischsten Parameter, die Verzeichnisstruktur. In diesem Test Szenario kann jedoch getestet werden, wie gross der Performancegewinn durch bestimmte Veränderungen wäre.
Wenn ABE bereits im Einsatz ist, und die Vermutung besteht dass es zu einer schlechten Performance beiträgt, so ist der einfachste und aussagekräftigste Test natürlich ABE für eine Zeit abzuschalten. Vorher- Nacher- Performance Analysen sind hierbei natürlich unerlässlich.
So!
Ich hoffe hiermit einen guten Einblick in die Thematik ABE und Performance gegeben zu haben und insbesondere bei den Admins das Bewusstsein für mögliche Performance Probleme mit ABE geschärft zu haben.
Viele Grüsse
Hubert
Hallo, Thomas hier. Immer wieder werden wir gefragt, wie man sich am Besten gegen etwaige Probleme beim Schema-Upgrade für Windows 2008 absichert. Deshalb habe ich einmal die wesentlichen Schritte für die Vor- und Nachbereitung zusammengestellt, die übrigens auch für alle anderen Schema-Updates analog verwendet werden können.
1. Stellen Sie sich die folgenden Fragen:
a.) Habe ich mir die Dokumentation zu ADPREP in der Technet (http://technet.microsoft.com/en-us/library/dd464018.aspx) genau angeschaut?
b.) Habe ich ein getestetes Konzept für die Recovery meines kompletten Forest in der Schublade?
Wenn nicht, hier abbrechen und dieses Konzept implementieren und vor allen Dingen testen. Hilfestellung hierzu findet man im Whitepaper “Planning for Active Directory Forest Recovery” unter http://www.microsoft.com/downloads/details.aspx?amilyid=afe436fa-8e8a-443a-9027-c522dee35d85&displaylang=en
Die Erfahrung lehrt, dass, wenn ein solches Konzept vorhanden ist und dessen Anwendung regelmäßig trainiert wird, Murphy die Lust zum Zuschlagen blitzartig vergeht.
c.) Funktioniert die AD-Replikation auf jedem DC meines Forests?
Wenn Sie Überwachungstools wie den Microsoft System Center Operations Manager einsetzen lässt sich die Frage relativ schnell beantworten.
Ansonsten ist es erforderlich, den Befehl
repadmin /replsum /bysrc /bydest /sort:delta >replsum<Sitename>.txt
in jeder Site auszuführen und die Textdateien auf Inkonsistenzen zu untersuchen.
d.) Wie aktuell sind meine System State Backups und lassen sich diese auch zurück sichern?
Dieses lässt sich ganz einfach überprüfen und als "Belohnung" hat man dann gleich die Testumgebung für das Schema Update:
- Erstellen Sie die System State Backups Ihres Schema Masters und auf je einem DC aus jeder Child Domäne mit NTBACKUP und sichern Sie diese auf die lokale Festplatte Ihrer Domänen Controller.
- Nehmen Sie jetzt die so entstandenen System State Backups und spielen Sie sie in Ihrer (virtuellen) vom Produktivnetz komplett isolierten Testumgebung ein.
- Wenn Sie die Fehler wegen fehlender Replikationspartner im Eventlog stören, entfernen Sie in der Testumgebung alle anderen DCs aus der AD Datenbank indemSie den Schritten aus KB 216498 How to remove data in Active Directory after an unsuccessful domain controller demotion http://support.microsoft.com/default.aspx?scid=kb;EN-US;216498 für jeden nicht mehr vorhandenen DC folgen.
e.) Funktioniert der Schema Upgrade in einer abgeschotteten Testumgebung?
Führen Sie jetzt die einzelnen ADPREP Schritte (/forestprep, /domainprep /gpprep und eventuell /rodcprep) in Ihrer Testumgebung durch.
Achtung: Bei 32-bit Systemen muss mit Windows 2008 R2 adprep32 verwendet werden.
Kontrollieren Sie nach jedem Schritt den Erfolg anhand der folgenden Kriterien:
- Keine Fehlermeldung auf der Kommandozeile. Wenn Fehler auftreten, finden Sie detaillierte Informationen im Verzeichnis %windir%\adprep\logs.
- Falls Probleme auftreten sollten, schauen Sie unter - Ask the Directory Services Team : Troubleshooting ADPREP Errors http://blogs.technet.com/askds/archive/2008/12/15/troubleshooting-adprep-errors.aspx nach einer etwaigen Lösung.
- Die Operational GUIDs unter CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain sind auf allen DCs vorhanden. Eine Liste finden Sie unter Windows Server 2008: Forest-Wide Updates http://technet.microsoft.com/en-us/library/cc771922.aspx
- Die Operational GUIDs unter CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,[DC=ChildDomain],DC=ForestRootDomain sind auf allen DCs der jeweiligen Domäne vorhanden. Eine Liste finden Sie unter Windows Server 2008: Domain-Wide Updates http://technet.microsoft.com/en-us/library/cc770385.aspx
- Die letzten beiden Punkte überprüft man am einfachsten mit ADSIEDIT.msc:
2. Hat alles funktioniert, dann ab in die Live-Umgebung.
- Überprüfen Sie noch einmal die Replikation des gesamten Forest wie oben unter c.) beschrieben.
- In der Live-Umgebung muss der Schema-Master für das Upgrade isoliert werden. Hierfür existieren unterschiedliche Ansätze:
- Deaktivieren der Replikation auf dem Schema Master mit dem Befehl repadmin /options +DISABLE_OUTBOUND_REPL
Dieser Ansatz ist dann zu wählen, wenn sichergestellt werden kann, dass kein anderer Administrator während des Upgrades den Befehl repadmin /force ausführt, da dieser das +DISABLE_OUTBOUND_REPL außer Kraft setzt.
- Verbringen des Schema Masters und eines anderen DCs in eine eigene Site, die vom restlichen Netzwerk isoliert ist. Die IP-Adressen dürfen hierfür nicht geändert werden. Am besten zwei Maschinen aus demselben Netzwerksegment verwenden und über einen Switch ohne Verbindung zum Hauptnetzwerk verbinden. Dieses ist die sicherste Methode in großen Umgebungen.
- Eintragen einer Sperrzeit von 1-2 Stunden auf allen Site-Links, die die Schema-Master Site mit dem Rest der Welt verbinden und Durchführen des Upgrades in diesem Zeitraum. Dieses stellt eine zusätzliche Absicherung dar und kann mit 2.1 und 2.2 kombiniert werden.
- Führen Sie adprep /forestprep aus und überprüfen Sie den Erfolg wie oben unter e.) beschrieben.
- Falls Probleme auftreten sollten, schauen Sie unter - Ask the Directory Services Team : Troubleshooting ADPREP Errors http://blogs.technet.com/askds/archive/2008/12/15/troubleshooting-adprep-errors.aspx nach einer etwaigen Lösung.
- Schalten Sie die Replikation entweder über repadmin /options -DISABLE_OUTBOUND_REPL bzw.durch Verbinden des Switches mit dem Hauptnetzwerk wieder ein.
- Starten Sie die Replikation via repadmin /syncall oder warten Sie das normale Replikationsintervall ab.
- Überprüfen Sie die Replikation der Änderungen mithilfe der Operational GUIDs für CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain zumindest stichprobenartig. Beobachten Sie hier besonders die DCs mit der größten Replikationslatenz.
- Warten Sie noch einen kompletten Replikationszyklus ab, bevor Sie fortfahren.
- Hat alles funktioniert kann nun der adprep /domainprep /gpprep auf den Infrastruktur Mastern aller Domänen, die mit Windows Server 2008 DCs ausgestattet werden sollen durchgeführt werden.
- Da hier keine dramatischen Eingriffe mehr geschehen kann auf die Absicherung wie in den Schritten 1. bis 8. dargestellt verzichtet werden.
- Besonders unkritisch ist der adprep /rodcprep Befehl, da dieser beliebig oft ausgeführt werden kann.
Viel Erfolg und viele Grüße
Thomas
Hi – ich bin Florian, einer von drei MVPs für Gruppenrichtlinien in Deutschland. Ich habe die Ehre, einen Gastbeitrag (*) für den „Aktives Verzeichnis“-Blog zu verfassen und möchte euch über ein Feature informieren, das sicherlich nicht überall bekannt ist.
Zeitgleich zum Launch von Windows Server 2008 hat Microsoft die „Group Policy Preferences“ veröffentlicht: eine umfangreiche Erweiterung zu den Gruppenrichtlinien, die man seit Windows 2000 kennt. Um gleich zu Beginn einen Mythos aus dem Weg zu räumen: damit man Group Policy Preferences verwenden kann, wird kein Windows Server 2008-Domänencontroller in der Domäne oder dem Forest benötigt. Es sind lediglich zwei Dinge notwendig:
- Die Installation der sogenannten „Client Side Extensions“ – Erweiterungen für Windows, sodass Clients die Preferences-Einstellungen verstehen können. Die Client Side Extensions sind frei zum Download verfügbar, werden aber seit einigen Monaten per Windows Update und WSUS auf Clients gespielt, sodass die allermeisten Clients die Erweiterungen ohnehin bereits installiert haben.
- Eine Managementstation, die Windows Server 2008 oder Windows Vista mit Service Pack 1, die das Remote Server Administration Toolkit (RSAT) installiert hat. Von dieser Station aus werden die Preferences dann mit administriert und verwaltet. Preferences können also in Domänen mit Server 2003-Domänencontrollern eingesetzt werden!
Neben den vielen Einstellungsmöglichkeiten, die die Preference zusätzlich zu den bereits vorhandenen Gruppenrichtlinien bieten, bringen sie eine Funktion mit, die das Testen und Verwalten von Einstellungen erleichtert. Gemeint ist die Import und Export-Funktion, die es ermöglicht, einzelne Preferences einfach zwischen Computern auszutauschen, als Backup auf einem Dateiserver zu speichern oder für Diagnosezwecke einzusehen. Das Schöne dabei ist nämlich, dass der Export im XML-Format vorliegt.
Es gibt drei einfache Möglichkeiten, eine Preference zu exportieren: die Einstellung kann entweder mit Copy&Paste (Rechtsklick-Kopieren, Rechtsklick-Einfügen) an einem anderen Ort eingefügt werden, per Drag&Drop an eine andere Dateisystemstelle gezogen werden oder mit dem Knopf „XML-Daten für ausgewählte Elemente anzeigen“ im Standardbrowser angezeigt werden. In jedem Fall wird die Einstellung als XML-Datei gespeichert oder angezeigt. Das Zusammenfassen von mehreren Einstellungen ist ebenfalls möglich. Hierzu werden mehrere Einstellungen markiert und anschließend exportiert. Die markierten Einstellungen werden auf diese Weise in eine einzige XML-Datei kopiert. Das macht es möglich, einen gewissen Einstellungsstand als Ganzes als Backup zu speichern oder im Zuge einer Versionshistorie vorzuhalten.
Das Importieren der XML-Datei ist ebenso einfach wie das Exportieren: ist eine Gruppenrichtlinie mit der entsprechenden Preference-Sektion geöffnet, lässt sich mit Hilfe von Copy&Paste oder Drag&Drop die exportierte Datei ohne Probleme einfügen.
Aus den oben genannten Möglichkeiten ergeben sich einige tolle Nutzungsszenarien. Wer beispielsweise eine Testdomäne für Gruppenrichtlinien und weitere Domänen- und Foresttests betreibt, kann so einzelne Preference-Einstellungen mühelos von der Testumgebung per XML-Datei in die Produktivumgebung kopieren, ohne dabei von der gesamten Gruppenrichtlinie ein Backup erstellen und wiederherstellen zu müssen. Die XML-Exporte sind domänen- und forestneutral gespeichert.
Vorstellbar ist auch eine Art „Baukastensystem“, mit dem man sich eine Gruppenrichtlinie aus einzelnen Preference-Einstellungen zusammenkopieren kann und sich auf diese Weise eine „Bibliothek“ zusammenstellt, mit der Grundaufgaben und immer wiederkehrende Preference-Einstellungen zu Kunden vordefiniert mitgenommen werden können. Die neuesten und coolsten Preference-Einstellungen könnten natürlich auch unter Admin-Kollegen, ähnlich wie in damaligen Grundschultagen Fussballaufkleber, ausgetauscht werden.
Die Cracks unter uns können selbstverständlich alle Preference-Einstellungen exportieren und mit einem Textprogramm von Hand editieren ;-):
Übrigens: wer ein weiteres, cooles Feature der Preferences, nämlich die Zieladressierung auf Elementebene (engl.: "Item-Level Targeting") verwendet, kann ebenfalls von der Import- und Exportfunktion der Preferences profitieren. Die Zieladressierung ist im XML-Export von <Filter>-Tags eingeschlossen und kann problemlos von einem Export in einen anderen kopiert werden. So kann man einen Filter mehrfach als exakte Kopie in mehreren Preferences verwenden – ohne ihn jeweils erneut Zusammenklicken zu müssen!
Im Beispiel oben wird nach der Organisationseinheiten gefiltert, die „Fileserver“ heißen („FilterOrgUnit“) und nach dem Betriebssystem des Clients, auf dem die Einstellung ausgeführt werden soll, nämlich Windows Server 2003 („FilterOs“).
Ich hoffe ich konnte euer Interesse für die Group Policy Preferences wecken und euch auf nette Features hinweisen.
Bis zum nächsten Mal!
Cheers,
Florian
* Rechtlicher Hinweis: Bei den hier als "Gastbeitrag" markierten Artikeln handelt es sich um Blogs, die von nicht-Microsoft Mitarbeitern verfaßt wurden. Diese Beiträge geben ausschließlich die Meinung des jeweiligen Autors wieder und stimmen nicht unbedingt mit der Meinung von Microsoft überein. Microsoft macht sich diese Beiträge ausdrücklich nicht zu eigen. Eine Vorabkontrolle der Beiträge findet nicht statt. Dementsprechend kann Microsoft keine Verantwortung oder Gewähr für die Beiträge übernehmen.
Hallo zusammen, da das Thema "Conficker" leider immer noch heiß gehandelt wird, obwohl das Ausnutzen der entsprechenden Lücke schon im letzten Jahr über das von uns bereitgestellte Security Update hätte verhindert werden können, hat uns unser Security Team ein paar kurze und aussagekräftige Informationen zur Verfügung gestellt, die Hinweise zum Thema geben. Danke an Uwe für diesen Gastbeitrag.
Diese folgenden Hinweise und Maßnahmen sind als Schutz vor einer Infektion/Reinfektion zu verstehen. Diese Schritte beinhalten keine Reinigungstools, sondern Hinweise zum manuellen Vorgehen.
Zunächst einige Informationen zum Thema Conficker:
http://www.microsoft.com/security/portal/Entry.aspx?Name=Worm%3aWin32%2fConficker.B
http://www.microsoft.com/security/portal/Entry.aspx?Name=Worm%3aWin32%2fConficker.C
http://www.microsoft.com/security/portal/Entry.aspx?Name=Worm%3aWin32%2fConficker.D
http://support.microsoft.com/kb/962007/de
http://blogs.technet.com/mmpc/archive/2009/01/22/centralized-information-about-the-conficker-worm.aspx
Zur Entfernung der Schadsoftware (Malware) und ob Ihre AV Lösung einen Schutz parat hat, kontaktieren Sie bitte Ihren AV Anbieter.
Conficker versucht sich auf folgende Art und Weise zu verbreiten:
Gegenmaßnahmen um eine Infektion/Reinfektion zu verhindern, nach einer durchgeführten Reinigung (etwa durch einen Anti-Viren Scanner):
- Installation von MS08-067 auf allen Systemen (http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx). Dies beseitigt nicht eine existierende Infektion. Das ist Aufgabe Ihres AV Anbieters oder eines entsprechenden Tools.
- Installation einer AV Lösung und Update der Definitionen auf allen Systemen.
- Bereinigung der Systeme gemäß KB 962007 (http://support.microsoft.com/kb/962007/de). Im KB-Artikel ist auch eine Anleitung vorhanden, wie Sie die Schutzmaßnahmen per Gruppenrichtlinie umsetzen können.
- Deaktivieren der Autorun-Funktion per Gruppenrichtlinie.
- Zusätzlich Deaktivieren von Autorun gemäß KB953252 (http://support.microsoft.com/kb/953252/), d.h. einspielen eines Registry Keys und des Fixes auf allen Systemen (da die normale Autorun GPO-Einstellung nicht für Netzlaufwerke gilt, solange der KB967715 nicht installiert ist).
- Alternativ zu KB953252 können Sie auch KB967715 (http://support.microsoft.com/?kbid=967715) per Microsoft Update/Windows Update/ WSUS verteilen. Zu Beachten ist dabei jedoch, daß Conficker die Windows Update Funktion deaktivieren kann, so daß die Verteilung des Hotfixes über WSUS unter Umständen ins Leere laufen kann.
- Ändern aller Passwörter und verwenden von komplexen Passwörtern.
- Bitte benennen Sie alle Dateien / Programme, die Sie zum Entfernen des Conficker Wurms einsetzen wollen (etwa MRT.exe, KB890[...], MS08-067[...], Windows-KB890830[...] etc.), um. Dies ist wichtig für den Fall, daß Sie Variante D haben sollten. Dieser überprüft die Prozesse nach bestimmten Strings und beendet die entsprechenden Prozesse sofort.
- Auf einem bekannt infizierten Problem sollte sich kein Domain Administrator anmelden!
Diese Maßnahmen sind an jedem Rechner ohne Ausnahme durchzuführen um den Rechner nach einer Bereinigung vor der Reinfektion zu schützen.
Sie sollten also infizierte Rechner vom Netz nehmen, die Schritte durchführen, und erst dann den Rechner wieder ans Netzwerk nehmen.
Generell empfehlen wir, ein einmal infiziertes System neu zu installieren, da man nie mit Gewissheit sagen kann, was die Schadsoftware alles verändert hat.
Viele Grüße
Uwe
Hallo zusammen.
Vielleicht haben sich einige unter Euch schon mal gewundert, warum ein Administrator in der MMC "Active Directory Benutzer und Computer" einem Benutzer ein leeres Passwort zuweisen kann. Obwohl doch in der Domäne Kennwortrichtlinien wie "minimale Kennwortlänge" oder "Komplexität von Kennwörtern" aktiv sind.
Das Geheimnis für solch ein Verhalten liegt in einem Attribut des Userobjekts - dem Attribut "UserAccountControl".
Ist auf einem Benutzerobjekt im Attribut "UserAccountControl" das Flag UF_PASSWD_NOTREQD gesetzt, kann ein Administrator auf einem Domaincontroller an der definierten Kennwortrichtlinie vorbei, ein Kennwort der Länge Null vergeben. Nur ein Administrator (Mitglieder der Gruppen Administrators oder Domain Admins) kann dieses "NULL Kennwort" auf ein Benutzerobjekt vergeben, das dieses Flag gesetzt hat. Diese Aktion kann auch über andere Tools als die MMC "Active Directory Benutzer und Computer", z.B. "NET USER" erfolgen., sowohl remote als auch lokal.
Der Benutzer selbst, dessen UserAccountControl Flag PASSWD_NOTREQD gesetzt hat, kann dies nicht. Er kann sich kein leeres Kennwort vergeben.
Wie kommt es nun eigentlich dazu, dass dieses Flag gesetzt ist?
Nun, beim Erstellen eines Benutzers wird dem Attribut "UserAccountControl" ein Wert "eingehaucht".
Das Tool MMC „Active Directory Users and Computer“ setzt den Default des "UserAccountControl" Flags für Benutzer auf den Wert 512. Damit ist das Flag UF_PASSWD_NOTREQD nicht gesetzt. Das Flag UF_PASSWD_NOTREQD repräsentiert den Wert 32 (dezimal). Triff man also zum Beispiel auf ein Benutzerobjekt mit einem "UserAccountControl" von 544, ist das Flag gesetzt. Diesen Wert kann man häufig nach Migrationen aus der NT4 Welt beobachten.
In vielen Umgebungen werden zusätzlich Tools oder Scripte verwendet, um Benutzerobjekte im Active Directory anzulegen.
Beim Einsatz der Methoden IADsContainer.Create, IADs.Put, IADs.SetInfo aus dem ADSI Interface wird das Flag UF_PASSWD_NOTREQD per default gesetzt. Tools, basierend auf dieser Schnittstelle verwenden diesen Default. Dies ist unter anderem hier dokumentiert http://msdn2.microsoft.com/en-us/library/ms675773.aspx:
UserAccountControl
Contains values that determine several logon and account features for the user.
By default, the following flags are set:
UF_ACCOUNTDISABLE - The account is disabled.
UF_PASSWD_NOTREQD - No password is required.
UF_NORMAL_ACCOUNT - Default account type that represents a typical user.
Das Anlegen eines Benutzerkontos über ADSIEDIT.MSC führt ebenso zu einem "UseraccountControl" Attribut, das das Flag UF_PASSWD_NOTREQD gesetzt hat. Auch erzeugt das Importieren eines Benutzers via LDIFDE über ein Importfile einen Benutzer mit einem "UserAccountControl", das das gesetzte Flag UF_PASSWD_NOTREQD enthält.
Zusammenfassend lässt sich sagen, dass ohne eine eigene Logik innerhalb von Tools, die Konten anlegen mit einem gesetzten UF_PASSWD_NOTREQD gerechnet werden muss - und damit, dass ein Benutzer ein leeres Kennwort haben könnte.
Möchtet Ihr eure Konten von diesem Flag "befreien", bietet unser Scriptcenter ein Beispiel, das über eine kleine Anpassung diese Aufgabe erledigt und hier zu finden ist http://www.microsoft.com/technet/scriptcenter/guide/sas_usr_hhdp.mspx?mfr=true. Dabei muss das dort verwendete Flag gegen ADS_UF_PASSWD_NOTREQD mit einem Wert von 0x20 ersetzt werden . Die Flags sind unter anderem hier dokumentiert http://msdn.microsoft.com/en-us/library/aa772300.aspx.
Hilfreich ist dabei noch eine Beschreibung der einzelnen Flags innerhalb des Attributs "UserAccountControl" unter "Verwendung der UserAccountControl-Flags zur Bearbeitung von Benutzerkontoeigenschaften" http://support.microsoft.com/kb/305144.
Damit kann man dann dem Administrator den Spaß nehmen, sich an der Kennwortrichtlinie vorbei zu schmuggeln :-).
Viele Grüße
Stefan
Hallo, anbei schreibt Stefan seinen ersten Eintrag im „Aktiven Verzeichnis“.
Auf einem deutschen Windows Server 2008 System kann man leicht in einige Fallen innerhalb des Tools NETDOM tappen, die unsere Entwickler bei Ihrer grundsätzlich guten und wichtigen Lokalisierungsarbeit aufgestellt haben.
Beispielsweise kann es erforderlich sein, über das Tool NETDOM einige Funktionen auf einem Trust zu verwalten. Vor allem die Parameter /enableSIDHistory und /Quarantine sind häufig im Einsatz.
Versucht man nun auf einem deutschen Windows Server 2008 die SIDHistory auf einem Trust zu aktivieren, sieht ein erster Blick in die Hilfe des Tools via "NETDOM TRUST /?" vor:
Die Syntax dieses Befehls lautet folgendermaßen:
NETDOM TRUST trusting_domain_name /Domain:trusted_domain_name [/UserD:user]
[/PasswordD:[password | *]] [/UserO:user] [/PasswordO:[password | *]]
[/Verify] [/RESEt] [/PasswordT:new_realm_trust_password]
[/Add] [/REMove] [/Twoway] [/REAlm] [/Kerberos]
[/Transitive[:{yes | no}]]
[/OneSide:{trusted | trusting}] [/Force] [/Quarantine[:{yes | no}]]
[/NameSuffixes:trust_name [/ToggleSuffix:#]]
[/EnableSIDHistory[:{yes | no}]]
[/ForestTRANsitive[:{yes | no}]]
[/CrossORGanization[:{yes | no}]]
[/AddTLN:TopLevelName]
[/AddTLNEX:TopLevelNameExclusion]
[/RemoveTLN:TopLevelName]
[/RemoveTLNEX:TopLevelNameExclusion]
[/SecurePasswordPrompt]
NETDOM TRUST verwaltet oder überprüft die Vertrauensstellung zwischen Domänen.
Na dann, flugs ausgeführt zwischen den Domänen ROOT und CHILD:
NETDOM TRUST ROOT /DOMAIN:CHILD /EnableSIDHistory:yes
Der SID-Verlauf für diese Vertrauensstellung ist deaktiviert.
Der Befehl wurde ausgeführt.
Wie? Was denn? Bitte aktivieren!
Also nochmal das Kommando ausgeführt:
NETDOM TRUST ROOT /DOMAIN:CHILD /EnableSIDHistory:yes
Der SID-Verlauf für diese Vertrauensstellung ist deaktiviert.
Der Befehl wurde ausgeführt.
Hmmm. OK. Dann schalten wir die SIDHistory eben ab:
NETDOM TRUST ROOT /DOMAIN:CHILD /EnableSIDHistory:no
Der SID-Verlauf für diese Vertrauensstellung ist deaktiviert.
Der Befehl wurde ausgeführt.
Ok, also können wir die SIDHistory weder deaktivieren noch aktivieren? Wirft man nun einen genaueren Blick in den unteren Teil der Hilfeseiten des Tools, fällt einem folgende Beschreibung ins Auge:
/EnableSIDHistory Nur gültig für eine ausgehende Vertrauensstellung auf Gesamtstrukturebene. Durch Angabe von "ja"
können Benutzer, die von einer beliebigen anderen Gesamtstruktur an die vertrauenswürdige Gesamtstruktur migriert wurden,
mithilfe des SID-Verlaufs auf Ressourcen in dieser
Gesamtstruktur zugreifen. Dies wird nur empfohlen, wenn die Administratoren der vertrauenswürdigen Gesamtstruktur
vertrauenswürdig genug sind, SIDs dieser
Gesamtstruktur im SID-Verlaufsattribut der Benutzer
angemessen anzugeben. Bei Auswahl von "nein" sind
die migrierten Benutzer in der vertrauenswürdigen Gesamtstruktur nicht mehr in der Lage, mithilfe des SID-Verlaufs
auf die Ressourcen in der Gesamtstruktur zuzugreifen. Bei Angabe von
"/EnableSIDHistory" ohne "ja" oder "nein" wird der aktuelle
Status angezeigt.
Aha. Hier erwartet NETDOM also ein "ja" anstatt eines "yes".
NETDOM TRUST ROOT /DOMAIN:CHILD /EnableSIDHistory:ja
Der SID-Verlauf für diese Vertrauensstellung wird aktiviert.
Der Befehl wurde ausgeführt.
Bingo.
Sollte also einmal jemand über eine Verweigerung von NETDOM stolpern, obwohl die Syntax vermeintlich korrekt ist, einfach die Parameter hinsichtlich ihrer Sprache prüfen.
Hi zusammen, Fabian vor der Kiste. Möchte man Delegierungen innerhalb einer AD-Umgebungen nutzen, benötigt man in den meisten Fällen nur unsere vorgefertigten Wizards. Diese geben in den meisten Anwendungsszenarien schon die erforderlichen Dialoge und vorgefertigten „Rollen“, die etwa notwendig sind, um der Personalabteilung die Bearbeitung von diversen Benutzerattributen zu gewähren. Andernfalls nutzt man besipielsweise ADSIEdit, DSACLS.EXE oder die erweiterten Optionen der Active Directory Benutzer und Computer MMC im Delegierungswizard. Der Einfachheit halber gehen wir hier nur auf die MMC Variante ein.
Grundsätzliche Informationen zur Delegierung gibt es beispielsweise hier:
Kommt man nun in die Verlegenheit, einzelne Attribute zu delegieren, stellt sich jedoch schnell die Frage, wie denn die anzupassenden Attribute überhaupt heißen. Denn die Anzeige der „City“ oder „Stadt“ in der Active Directory Benutzer & Computer MMC ist ja nicht gleich dem Attributnamen im AD. Dieser ist immer derselbe und damit sprachunabhängig. Von daher benötigt man Möglichkeiten, die Attribute zu identifizieren. Exemplarisch sollen in diesem Blog Eintrag drei Möglichkeiten genannt werden, obwohl es sicher noch mehr Varianten gibt. Viele Wege führen nach Rom. :-)
1. Die pragmatische Variante
Die Pragmatiker unter uns machen es sich einfach - sie setzen einfach auf einem Testbenutzer einen Beispielwert auf das gewünschte Feld und exportieren danach das Benutzerobjekt mittels LDIFDE oder schauen es sich direkt mit ADSIEdit.msc oder etwa LDP.EXE an. Soll es einem Mitarbeiter oder einen Dienstaccount z.B. ermöglicht werden, die „City“ / „Stadt“ zu bearbeiten, würde der Pragmatiker wie folgt vorgehen:
a) Setzen eines Testwertes in das gewünschte Feld
b) Export des Benutzerobjekts, z.B. mittels LDIFDE:
C:\> ldifde –d „CN=user1,OU=Users,OU=Corp,DC=contoso,DC=com“ –f C:\user1.ldf
Öffnet man die LDF-Datei nun mit einem Texteditor wie Notepad.exe, findet man den Testwert “TESTCITY“ recht problemlos (Export gekürzt):
dn: CN=user1,OU=Users,OU=Corp,DC=contoso,DC=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: user1
l: TESTCITY
givenName: user1
distinguishedName: CN=user1,OU=Users,OU=Corp,DC=contoso,DC=com
sAMAccountName: user1
Der Attributname für die „City“ / „Stadt“ ist also „l“ (kleines „L“ wie „Ludwig“) , was für „locality“ steht.
2. Die „ich nutze die neuen Medien“ Variante
Sind wir mal ehrlich: In den meisten Fällen greift der geübte AD-Admin zur Suchmaschine seiner Wahl, meist mit guten Ergebnissen. So auch in diesem Fall, denn die Suche mit Suchbegriffen wie „active directory attribute city“ führt einen recht schnell zu der folgenden MSDN Seite, die eine ganze Menge Attribute katalogisiert vorhält, so auch das gewünschte:
http://msdn.microsoft.com/en-us/library/cc220045.aspx
2.345 Attribute l
This attribute represents the name of a locality, such as a town or city.
cn: Locality-Name
ldapDisplayName: l
attributeId: 2.5.4.7
attributeSyntax: 2.5.5.12
omSyntax: 64
isSingleValued: TRUE
schemaIdGuid: bf9679a2-0de6-11d0-a285-00aa003049e2
systemOnly: FALSE
searchFlags: fCOPY | fATTINDEX
rangeLower: 1
rangeUpper: 128
attributeSecurityGuid: 77b5b886-944a-11d1-aebd-0000f80367c1
mapiID: 14887
isMemberOfPartialAttributeSet: TRUE
systemFlags: FLAG_SCHEMA_BASE_OBJECT |
FLAG_ATTR_REQ_PARTIAL_SET_MEMBER
schemaFlagsEx: FLAG_ATTR_IS_CRITICAL
Version-Specific Behavior: Implemented on Windows 2000 Server, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 7.
The schemaFlagsEx attribute was added to this attribute definition in Windows Server 2008.
3. Die „ich weiß, wovon ich spreche“ Variante
Zu guter Letzt soll noch eine Variante genannt werden, mit der man bei einem „zufälligen“ und lauten Gespräch auf dem Gang in der Personalabteilung Punkte sammeln kann und seinem Ruf als GEEK gerecht wird. So wissen die Kollegen wenigstens, wofür Ihr bezahlt werdet. Bitte die unten dick markierten Wörter besonders laut und wiederholt aussprechen. ;-)
Die Zuordnungen der Anzeigenamen zu Attributen sind wie oben schon angesprochen sprachunabhängig. Die Zuordnung erfolgt über die sogenannten Display Specifier, die in der jeweiligen Installationssprache die Anzeige auch in der Active Directory Benutzer & Computer MMC bestimmt. Möchte man nun herausfinden, welches Attribut zu dem Display Name / Anzeigenamen "City" / "Stadt" gehört, schaut man sich diese Display Specifier der user-Klasse an (da es sich um ein Benutzerobjekt handelt). Hierzu kann ebenfalls wieder ein LDIFDE Export, ADSIEdit, LDP oder ähnliches zählen, hier wurde exemplarisch LDIFDE genutzt:
a) Export der Display Specifier unterhalb des Configuration Naming Contexts
C:\> ldifde –d “CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=contoso,DC=com“ –f C:\user-display.ldf
In diesem Fall wurden die englischen Zuordnungen gewählt (409), Deutsch ware etwa “407” als Ländercode, siehe dazu http://msdn.microsoft.com/en-us/library/aa393651(VS.85).aspx.
b) In der exportierten Datei findet man nun die Attribute und deren Anzeigenamen, getrennt durch ein Komma (Ausgabe gekürzt):
dn: CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=contoso,DC=com
changetype: add
objectClass: top
objectClass: displaySpecifier
cn: user-Display
distinguishedName:
CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=contoso,DC=com
name: user-Display
adminPropertyPages: 12,{5969F63F-CACF-40bf-8891-CA580EB589E9}
shellPropertyPages: 1,{f5d121ed-c8ac-11d0-bcdb-00c04fd8d5b6}
classDisplayName: User
attributeDisplayNames: st,State/Province
attributeDisplayNames: sn,Last Name
attributeDisplayNames: samAccountName,Logon Name (pre-Windows 2000)
attributeDisplayNames: l,City
attributeDisplayNames: homeDirectory,Home Folder
attributeDisplayNames: givenName,First Name
attributeDisplayNames: generationQualifier,Generational Suffix
Mit dieser Zuordnung findet man nun auch leicht das Attribut zur Delegierung.
Zu guter Letzt noch ein Hinweis zur Delegierung selbst: Standardmäßig werden in der AD Benutzer & Computer MMC im Sicherheitsdialog nicht alle Attribute angezeigt. ADSIEdit oder LDP hingegen zeigen alle Attribute mit an.
Möchte man bestimmte Attribute auch in der AD Benutzer & Computer MMC anzeigen, kann man dies über die Datei
„%SYSTEMROOT%\system32\dssec.dat“ einstellen. So ist der „Anzeigewert“ für das Attribut „l“ (also „City“) gleich "7", d.h. es wird weder die Eigenschaft „Lesen“ noch „Schreiben“ angezeigt. Möchte man beides einblenden, muß der Wert auf „0“ (NULL) gesetzt werden, alternativ nur Lesen oder nur Schreiben, siehe 296490 How to modify the filtered properties of an object http://support.microsoft.com/default.aspx?scid=kb;EN-US;296490 . In der MMC wird dann übrigens der Anzeigename im Sicherheitsdialog angezeigt, nicht der Attributname. Im angesprochenen Fall sucht man im Dialog also nach "City".
Viele Grüße
Fabian
Hallo, hier ist wieder einmal der Herbert.
Das Wunschthema des Gewinners unserer Umfrage war "Disaster Recovery". Nun gibt es von Familienfesten über Parteitage zu Fußballspielen verschiedene Arten von Desastern. Im AD-Bereich haben Desaster in den meisten Fällen mit dem Verlust oder Korruption von AD Daten oder Domain Controllern zu tun, weniger oft mit dem Verlust von DCs oder ganzer Domains.
Ich möchte mich dieses Mal dem etwas schmerzhaften Thema Sichern und Wiederherstellen von Active Directory Daten widmen. Der Verlust von Objekten durch unbeabsichtigtes Löschen oder Datenverlust durch ein wild gewordenes Script oder Provisioning System ist bei uns der häufigste Auslöser von Anfragen, bei denen AD Daten verloren gegangen sind.
Als schmerzhaft empfinden viele besonders das Thema Restore, weil der Vorgang als sehr umständlich empfunden wird und nicht sehr gut beschrieben. Ein sicheres Anzeichen dafür ist die Länge dieses KB Artikels:
840001 How to restore deleted user accounts and their group memberships in Active Directory
http://support.microsoft.com/default.aspx?scid=kb;EN-US;840001
Wer nun die Vorgehensweise nicht regelmäßig übt, wird im Falle des Falles (fehlende Objekte oder falsche Daten), sich bei der Durchführung des Restores sehr unsicher fühlen und zur Vermeidung von weiteren Fehlern Hilfe brauchen. Schließlich steht der Betrieb für viele Benutzer, und das darf nicht länger dauern als nötig.
Bei der richtigen Vorbereitung und Systemversion könnt ihr Euch heutzutage auf Methode 1 aus Artkel 840001 beschränken, die besonders für Umgebungen mit einer Domain relativ gut zu "bedienen" ist. Dieser Ansatz ist auch der einzige, der einen vollständigen Restore der Objektlinks über Domain Grenzen hinweg sicherstellt.
Ihr könnt das durch die richtige Vorbereitung erreichen:
1. Verwenden der Windows 2003 Forest Modes und Links im LVR-Format.
Dies erlaubt das Verfolgen der gelöschten Links durch NTDSUTIL und späteren Import in anderen Domains des Forests.
2. Umwandeln der alten Gruppenmitgliedschaften (LEGACY) in Linked Value Mitgliedschaften.
Dazu müssen leider die Gruppenmitglieder entfernt und wieder hinzugefügt werden. Mit den Kommandozeilentools zur AD-Objektbearbeitung ist das aber recht einfach:
dsget group CN=GroupX,OU=Groups,DC=contoso,DC=com /members | dsmod group CN=GroupX,OU=Groups,DC=contoso,DC=com /chmbr
Mit dem Kommando werden in einem Rutsch die Mitglieder ausgetauscht.
Ihr solltet darauf achten, dass nicht zu viele Gruppen in zu kurzer Zeit umgestellt werden, denn die WAN Leitungen glühen sonst unter der Replikationslast. Es sollte auf den Replikationspartnern nicht zu beobachten sein, dass die Gruppenmitgliedschaften kurz weg waren. Die Änderung wird in einem Stück repliziert.
Nun gibt es folgende Probleme:
- Die Version von DSGET in Windows Server 2003 holt maximal 1500 Mitglieder aus einer Gruppe ab. Das heißt, ihr würdet die Mitgliedschaft auf 1500 Mitglieder verkürzen. Ich habe auch eine Testumgebung, in der DSGET gar keine Mitglieder anzeigt. Die Version von DSGET aus Windows 2008 hat diese Probleme aber nicht.
- Wenn eine Gruppe viele Mitglieder hat, wird bei der Ausführung von DSMOD der Version Store ausgereizt und das Hinzufügen der Mitglieder im LVR-Modus schlägt fehl. Nun ist das Umwandeln der Mitgliedschaften für jede Gruppe eine einmalige Angelegenheit.
Eine Idee für das Thema ist, erst einmal alle Mitgliedschaften in Dateien zu exportieren. Ich beschreibe das nachfolgend.
- Verwendung der richtigen Systemsoftware Version (siehe unten).
Gruppen auf LVR umwandeln
Ihr könnt den Zustand der Gruppenmitgliedschaft sehen, wenn in repadmin /showobjmeta bei den Links als „Type“ LEGACY gelistet wird:
Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver
======= ============ ============= ================= ======= ======= ===
Distinguished Name
=============================
LEGACY member
CN=test-user1,OU=Test-OU,DC=contoso,DC=com
PRESENT member 2008-09-16 18:22:29 HQ\contoso-DC1 175379684 175379684 1
CN=test-user2,OU=Test-OU,DC=contoso,DC=com
Die Zeile LEGACY hat keine Daten zur letzten Änderung, die ist mit den normalen Attributen gelistet.
Hinweis: Ich verwende für Schleifen CMD und das Kommando „For“ in der Syntax für direkte Ausführung. Bei Ausführung in CMD-Skripts braucht ihr doppelte Prozent bei den Variablen, also „%%f“.
Die Schritte sind nun:
Zunächst sollten Änderungen an Gruppen eingefroren werden.
Zum Exportieren der Gruppenliste bietet sich an:
Dsquery group dc=contoso,dc=com /limit 0 > Gruppenliste.txt
Ihr solltet aus dieser Liste die Gruppen im Builtin Container entfernen, und die „Domain Admins“ und andere Default Gruppen. Aus diesen Gruppen können nicht alle Mitglieder entfernt/getauscht werden, was weiter unten gemacht wird. Aber diese Gruppen können auch nicht gelöscht werden.
Nun holen wir die Mitglieder aller Gruppen auf Windows Vista mit RSAT oder 2008:
For "delims=§" %f in (Gruppenliste.txt) do DSGET %f /members > Gruppenmitglieder\%f
Wichtig: Die Gruppen-DNs sollten keine Zeichen “§:\/*?” enthalten. Bei "§" könnt ihr auch ein anderes Dummy-Trennerzeichen verwenden. Gruppen mit diesen Zeichen sollten vorübergehend umbenannt werden (nur anderer CN nötig).
Nun zählen wir die Mitglieder:
For "delims=§" %f in (Gruppenliste.txt) do wc Gruppenmitglieder\%f >> Mitgliederzahl.txt
In Mitgliederzahl.txt ist die erste Spalte die Anzahl der Mitglieder der Gruppe. Alle Gruppen mit mehr als 5000 Mitgliedern bekommen eine Sonderbehandlung. Ihre Mitgliederlisten verschiebt ihr in ein Verzeichnis "Gruppenmitglieder-gross1".
Für den Rest führt ihr aus:
Dir /b Gruppenmitglieder >Gruppenliste-Klein.txt
For /f "delims=§" %f in (Gruppenliste-Klein.txt) do dsmod group "%f" /chmbr < "Gruppenmitglieder\%f"
Hinweis: "%f" ist hier in doppelten Hochkommas, da die Ausgabe von "dir /b" keine enthält.
Dann sind diese Gruppen schon einmal versorgt.
Nun zu den großen Gruppen
Bei den großen Gruppen teilt ihr die Mitgliederliste einfach in mehrere Dateien auf nach jeweils 5000 Zeilen und legen die Abschnitte in eigene Verzeichnisse, wieder mit dem DN der Gruppe als Name:
Dir /b Gruppenmitglieder-gross1 >Gruppenliste-gross1.txt
For /f "delims=§" %f in (Gruppenliste-gross1.txt) do dsmod group "%f" /chmbr < "Gruppenmitglieder-gross1\%f"
Dir /b Gruppenmitglieder-gross2 >Gruppenliste-gross2.txt
For /f „delims=§“ %f in (Gruppenliste-gross2.txt) do dsmod group "%f" /chmbr < "Gruppenmitglieder-gross2\%f"
Ihr könnt von einigen Gruppen zur Kontrolle die Meta-Daten holen:
For "delims=§" %f in (Gruppenliste.txt) do repadmin /showobjmeta . %f > Gruppen-Meta\%f
In den Exportdateien sollte "LEGACY" dann nur noch für andere verlinkte Attribute gelistet sein.
Puh, das war schon ein schönes Stück Arbeit. Wenigstens brauchen wir uns um die primäre Gruppe nicht zu kümmern. :-)
Ich empfehle, dass Ihr erst einmal mit ein paar Testgruppen übt (auch wenn die Mitglieder dann schon im LVR Mode sind). Und danach macht Ihr mit kleinen OU-Bäumen weiter um dann mit mehr Erfahrung das für die ganze Domain und schließlich für alle Domains durchzuziehen.
Empfohlene Fixes
Leider gab es in letzter Zeit zwei Probleme, die die Replikation nach einem (Authoritative) Restore betroffen haben:
937855 After you restore deleted objects by performing an authoritative restoration on a Windows Server 2003-based domain controller, the linked attributes of some objects are not replicated to the other domain controllers
http://support.microsoft.com/default.aspx?scid=kb;EN-US;937855
943576 Active Directory objects may not be replicated from the restored server after an authoritative restore on a Windows Server 2003-based domain controller
http://support.microsoft.com/default.aspx?scid=kb;EN-US;943576
Wenn Ihr den Fix 943576 auf den DCs habt die regelmäßig gesichert werden, sollte es keine Probleme geben. Langfristig sollte der Hotfix auf alle Domain Controller im Unternehmen präsent sein.
Als würde das nicht reichen, kommen noch Probleme mit dem Tool zum Wiederherstellen von AD Daten dazu, dem NTDSUTIL.EXE. Da sind zunächst Probleme beim Umgang mit Objekten mit erweiterten Zeichen (jenseits 7 Bit ASCII) im Objektnamen:
886689 The Ntdsutil authoritative restore operation is not successful if the distinguished name path contains extended characters in Windows Server 2003 and in Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;EN-US;886689
910823 Error message when you try to import .ldf files on a computer that is running Windows Server 2003 with Service Pack 1: "Add error on line LineNumber: No such object"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;910823
Darüber hinaus gibt es noch das Problem, dass bereits vor dem Backup gelöschte Links restauriert werden:
951320 The ntdsutil.exe utility in Windows Server 2003 writes out too many links to .ldf files during an authoritative restore process
http://support.microsoft.com/default.aspx?scid=kb;EN-US;951320
Die gute Nachricht ist, dass mit Fix 951320 auf den regelmäßig gesicherten DCs auch diese Klippe umschifft ist, und man sich nur noch um das Problem 910823 per Hand kümmern muss.
Ungewollte Löschungen verhindern
Die meisten Fälle von Restores in unserer Support Praxis betreffen unabsichtlich gelöschte Objekte, meist ganze OUs mit Benutzer- und Gruppen-Konten. Das Thema hat Microsoft in Windows 2008 und Vista RSAT (Remote Server Administration Toolkit) angegangen. Die neue Version der Admin Tools bietet im Reiter Allgemein (General) eine Option zum Schützen vor unbeabsichtigter Löschung einer OU.
Damit werden auf der OU selbst und der Parent OU ACEs (Access Control Entries) eingetragen, die "Jeder" das Löschen des Objekts bzw. Kindobjekts verbietet. Das funktioniert auch schon mit Windows 2003, und auch mit selbst geschriebenen Tools und Scripts, solange die ACEs so beschaffen sind, wie vom Administrationstool geschrieben.
Somit kann die OU mehr unabsichtlich gelöscht werden, denn der (delegierte) Admin muss zuerst den Haken entfernen. Er wird dann kaum sagen können, dass es keine Absicht war.
Die Zukunft
In der Zukunft will Microsoft einen Schritt weiter gehen und einen Papierkorb für AD Objekte anbieten, in der Version die Windows 2008 R2 heißen wird. Es gibt bereits erste Informationen dazu, in diesem Release steht vor allem die Grundfunktionalität im Vordergrund, eine schöne Benutzerschnittstelle wird nachgeliefert.
Für den Papierkorb ändert sich das Speicherformat der Objektlinks in der Datenbank, deswegen wird es nötig sein, im Windows 2008 R2 Forest Mode zu sein. Es müssen dann auch alle Domain Controller dieses Betriebssystem verwenden.
Bis dieser Forest Mode erreicht ist, bleibt erst einmal die Restores richtig vorzubereiten und zu üben...
