Quelltext der Seite Migration / Zusammenführung von zwei Domänen - Praxiserfahrung

Zwar findet man im Internet einige Beiträge darüber, wie man eine Active Directory Domäne migeriert (auch [https://www.microsoft.com/de-de/download/details.aspx?id=19188 Microsoft bietet ein Handbuch hierfür zum kostenlosen Download an]), ich möchte hier meine praktische Erfahrung bei der Migration unter Windows Server 2008 R2 und mit Windows 7 Clients festhalten - vielleicht hilft's dem ein oder anderen weiter.

== Vorüberlegungen / Vorbereitungen ==

Nachfolgen ein paar Punkte, die vorbereitend eingerichtet werden sollten/können:

# Vertrauensstellung zwischen der Quell- und Zieldomäne (bidirektional)
# Die Vertrauensstellung setzt eine funktionierende DNS Infrastruktur auf beiden Seiten voraus
# Das [https://www.microsoft.com/de-de/download/details.aspx?id=8377 Active Directory Migration Tool ADMT V3.2], installiert auf einem Windows Server 2008 R2
# Ein Domänen-Admin Account in beiden Domänen mit demselben Benutzernamen und Kennwort, z. B. der Benutzer ''mig''
# Lade dir das [http://www.faq-o-matic.net/2010/05/26/jos-version-3-0-ist-da/#download Tool Jose herunter] und halte damit den aktuellen Stand der Quelldomäne vor der Migration fest - kann man später z. B. für die Anpassung des ADs der Zieldomäne verwenden...

Ich werde hier nicht erklären, wie man eine Vertrauensstellung einrichtet - das setze ich als Grundkenntnisse voraus. Jedem anderen Leser dieses Artikels empfehle ich http://www.google.de oder einen externen 

Berater hinzuzuziehen.

Was gilt es nun zu beachten?

# Die Version des zu verwendenden/installierenden ADMT ist abhängig davon, welche Clients (XP, Vista, 7) man migrieren möchte bzw. auf welchem Server das Tool installiert wird. Das ADMT ist abwärtskompatibel zu Client-Systemen, die Version 3.2 ist aber für die Installation auf Windows Server 2008 R2 vorgesehen
# Um ADMT V3.2 verwenden zu können, muss die Domänen-Funktionsebene beider Domänen mindestens Windows Server 2003 lauten
# Das ADMT ist in der Zieldomäne auf einem Windows Server 2008 R2 Rechner zu installieren
# ADTM setzt einen installierten SQL-Server voraus, hier reicht [https://www.microsoft.com/de-de/download/details.aspx?id=25052 die kostenlose SQL Server 2008 Express Edition SP1]
# Builtin-Gruppen wie etwa "Domänen-Admins" können nicht migriert werden, näheres dazu weiter unten
# Sollten in der Quelldomäne Konten oder Gruppen existieren, die auch in der Zieldomäne vorhanden sind, so sind diese Prinzipale umzubenennen; andernfalls läuft man Gefahr, dass entweder ein Fehler bei der Migration auftritt ODER (was schlimmer wäre) einem Account der Zieldomäne die SIDs und AD-Attribute des Quellkontos gegeben werden (Voraussetzung hier ist natürlich, dass im ADMT der Haken bei ''In Konflikt stehende Objekte migrieren und zusammenführen'' gesetzt ist...)
# Erteile dem Benutzer ''mig'' aus beiden Domänen (Quell- und Zieldomäne!) das Recht, sich am ADMT-Server anmelden zu können; mit dem Konto der Quelldomäne wird nämlich das ADMT gestartet, andernfalls wäre es z. B. nicht möglich, den ADMT Agent, der später auf den Clients der Quelldomäne zur Migration des Computerkontos benötigt wird, zu installieren
# Bei der Migration der Benutzer inkl. zugehöriger Gruppen (Haken im ADMT) werden alle Objekte in ein und dieselbe OU der Zieldomäne kopiert - beachte oben den Download zu Jose... 

Als netter Admin sollte man seine User rechtzeitig über die bevorstehende Migration informieren. Warum? Sollten Monatsabschlüsse anstehen, man die Migration genau an einem Wochenende vorher durchführen und es am Montag danach zu Problemen kommt, hat man Ärger am Hals

Falls ein Exchange Server in der Quelldomäne existiert, der auch umgezogen werden muss, würde ich eine 3-Schritte-Migration empfehlen:
# Schritt: Migration von Benutzer, Gruppen und Client-Computer (kann parallel zur bestehenden Domäne durchgeführt werden)
# Schritt: Migration des Exchange Servers
# Schritt: Migration der Server der Quelldomäne

Ich werde die vorgehensweise basierend dieser 3-Schritte-Migration nun dokumentieren.

== Benutzer- und Gruppenmigration ==

Nachdem das ADMT erfolgreich installiert, Domänenfunktionsebene geprüft und der "mig"-User in beiden Domänen angelegt wurde, kann man mit der Benutzer- und Gruppenmigration starten. Sollten in der Zieldomäne für User der Quelldomäne bereits Konten existieren, empfiehlt sich, die Benutzerkontenumstellung in zwei Schritte zu gliedern:

# Schritt: Migration der Benutzer, die in der Zieldomäne noch kein Konto haben
# Schritt: Migration der User, die ein Konto in der Zieldomäne haben

Die Konstellation mit vorhandenen Konten hat man z. B. dann, wenn Mitarbeiter in der Zieldomäne mit einer Anwendung arbeiten, die ein AD-Account in der Zieldomäne voraussetzt.

Suche also zunächst doppelte Benutzerkonten, Gruppen und Computer heraus und benenne diese in der Quelldomäne um. Natürlich müssen Benutzerkonten nicht umbenannt werden, solange Quell- und Zielbenutzer demselben Anwender gehören (siehe oben).

=== Schritt 1: Benutzermigration bei nicht vorhandenen Zielkonten ===

Melde dich am ADMT-Server mit dem ''mig''-Account der Quelldomäne (!) an und starte die ADMT Konsole:

# Rechte Maus auf ''Active Directory-Migariontsprogramm'' und ''Assistent zum Migrieren von Benutzerkonten''
# Wähle Quell- und Zieldomäne aus
# Wähle die Benutzerkonten der Quelldomäne aus, die in der Zieldomäne nicht existieren; es empfiehlt sich vielleicht, testhalber erst einen Account zu migrieren - wenn möglich ein Account, der nicht mehr groß verwendet wird...
# Gib die ''Zielorganisationseinheit'' an - beachte: alle ausgewählten Benutzer und Gruppen landen in dieser OU, daher wäre es von Vorteil, mit Jose das alte AD zu dokumentieren
# ''Kennwortoptionen'': es gäbe die Möglichkeit, einen Passwort Export Server (PES) einzusetzen und von der Quelldomäne auch die Kennwörter zu migrieren. Das habe ich außen vor gelassen, da ich eine schrittweiße Migration mache und den neuen Account sowieso erst als Admin einrichten muss (siehe weiter unten); daher wählte ich die Option ''Komplexe Kennwörter generieren'', für das migrierte Konto setzte ich dann dieses Passwort zurück und richtete so den Account der Zieldomäne fertig ein
# ''Kontoaktualisierung'': spricht eigentlich für sich; da wir eine Migration über SIDHistory-Attribut machen, bitte den Haken bei ''Benutzer-SIDs zur Zieldomäne migrieren'' setzen :-)
# Benutzerkonto der Quelldomäne für den Migrationsvorgang angeben - hier verwende ich den User ''mig''
# Die nächsten Optionen sind interessant:
## Servergespeicherte Profile konvertieren: diese Option lasse ich so stehen (kein Haken), da beim Migrieren des File Server Computerkontos, auf welchem die Profile abgelegt sind (sofern man mit Roaming Profiles arbeitet...), die Rechte ohnehin entsprechend gesetzt werden
## Benutzerrechte aktualisieren: hat der zu migrierende Account in der Quelldomäne etwa das Recht, Rechner in die Domäne hinzuzufügen, Systemzeit zu ändern etc., so werden die Rechte mitgenommen; ich habe den Haken gesetzt...
## Zugeordnete Benutzergruppen migrieren - Migrierte Objekte aktualisieren: dürfte klar sein, Haken setzen
## Gruppenmitgliedschaften der Benutzer korrigieren: Haken setzen
# Im nächsten Step könnte man bestimmte AD-Attribute der zu migrierenden Konten von der Migration ausschließen, z. B. wenn in der Zieldomäne der Account bereits existiert, hier ein Profilpfad hinterlegt ist und dieser auch weiter gültig sein soll, könnte man das Attribut ''profilePath'' ausschließen; '''ACHTUNG:''' der Terminalserverprofilpfad ist ein Binärfeld und kann hier NICHT ausgeschlossen werden, das muss später per Hand korrigiert werden!
# Quellobjekte nicht migrieren, wenn in der Zieldomäne ein Konflikt ermittelt wird: da ich in 2 Schritte migriere (nicht vorhandene und vorhandene Accounts) und zunächst nicht vorhandene Konten migrieren möchte, bitte diese Option auswählen; so sieht man gleich, ob man hier in Konflikt kommen würde. Der Grund nochmal: existiert in der Quelldomäne ein Konto ''max.mustermann'', in der Zieldomäne ebenfalls ein ''max.mustermann'' und würde man diese, in Konflikt stehenden Konten zusammenführen, obwohl es sich um zwei ganz unterschiedlichen Menschen handelt, hat man ein Problem :-) Daher die 2-Schritte-Migration von Benutzerkonten
# Nach Klick auf ''Fertig stellen'' sollte die Migration eigentlich ohne Fehler durchlaufen, andernfalls das Protokoll durchlesen und analysieren

=== Schritt 2: Benutzermigration bei vorhandenen Zielkonten ===

Nochmal: existiert in der Quelldomäne ein Konto ''max.mustermann'', in der Zieldomäne ebenfalls ein ''max.mustermann'' und würde man diese, in Konflikt stehenden Konten zusammenführen, obwohl es sich um zwei ganz unterschiedlichen Menschen handelt, hat man ein Problem. Bis zum Schritt ''Konfliktverwaltung'' ist das, was unter Schritt 1 steht, identisch. Wähle bei ''Konfliktverwaltung'' aber nun ''In Konflikt stehende Objekte migrieren und zusammenführen'' und setzte den Haken bei ''Zusammengeführte Objekte in die angegebene Zielorganisationseinheit verschieben'', um gleich zu sehen, welche Konten betroffen sind.

== Sicherheitskonvertierung NTFS- und Freigaberechte ==

Bis zum jetzigen Zeitpunkt hat sich für die Benutzer der Quelldomäne nichts geändert - der Schritt ''Benutzer- und Gruppenmigration'' kann im Live-Betrieb durchgeführt werden. Bevor man aber nun die Computerkonten umstellt und - damit verbunden - die User dazu "zwingt", sich an der neuen Domäne anzumelden, muss man die NTFS- und Freigaberechte der Server der Quelldomäne um die Konten und Gruppen der migrierten Zielobjekte ergänzen. Hierzu dient der Sicherheitskonvertierungs-Assistent vom ADMT - bitte starten:

# Zuvor migrierte Objekte: auswählen
# Domänenauswahl: bedarf keiner Erklärung
# Computer aus Domäne auswählen: klaro...
# computerauswahl: dürfte auch einleuchtend sein
# Objekte konvertieren: hier ist was zu erklären
## Dateien und Ordner: sollte klar sein, hier werden die NTFS-Rechte entsprechend für die neuen Zielobjekte auf den Computern der Quelldomäne gesetzt
## Lokale Gruppen: macht nicht viel / keinen Sinn, lokale Gruppen auf Servern sollte man evtl. per Hand anpassen
## Drucker: logisch, Rechte auf Printservern sollten gesetzt werden, sodass die migrierten User drucken können
## Registrierung: es macht keinen Sinn, die Registry auf Servern aktualisieren zu lassen - hier sollten die migrierten Konten keine speziellen Rechte haben
## Freigaben: auch selbsterklärend, natürlich sind Freigaberechte anzupassen
## Benutzerprofil: hierbei handelt es sich um die Benutzerprofile auf den Servern - obacht! Nicht um die Roaming Profiles...
## Benutzerrechte: auch hier ist kein Haken zu setzen
# Hinzufügen: da die alten Konten und Gruppen aktiv arbeiten und die neuen Accounts nach und nach aktiviert werden, sollte diese Option gewählt werden.
# Nach Klick auf ''Fertig stellen'' wird die Sicherheitskonvertierung gestartet.

Ein Fehler, der bei mir auftrat, hatte damit zu tun, dass die Länge eines Dateipfades über 253 Zeichen lang war. In diesem Fall bitte das Protokoll durchlesen und die Pfade so anpassen, dass diese für die Migration < 253 Zeichen sind.

Sollte ein Fehler auftreten, einfach den Sicherheitskonvertierungs-Assistenten neu starten und laufen lassen.

'''Anmerkung:''' diese Sicherheitskonvertierung muss immer dann ausgeführt werden, wenn ein weiterer Benutzer oder Gruppe aus der Quell- in die Zieldomäne kopiert wurde. Der Assistent ergänzt nämlich dadurch entsprechend die Rechte der Server der Quelldomäne um die SIDs der neuen, migrierten Benutzer und Gruppen der Zieldomäne.

=== Dienstkonten, Geplante Tasks / Aufgabenplanung und SQL Agent Jobs ===

Benutzerkonten für Dienste, Geplante Tasks bzw. Aufgabenplanung und SQL Agent Jobs werden NICHT automatisch migriert bzw. umgestellt - hier ist Handarbeit gefragt. Werfe einen Blick in die Diensteverwaltung, die Geplanten Tasks und den SQL Agent jedes Servers und stelle sicher, dass diese nach der Migration entsprechend mit den jeweiligen Konten der Zieldomäne ausgeführt werden.

=== Dienstkonto und Jobs für Symantec BackupExec ===

Mir wurde geraten, vor Umstellung des Backup-Servers in die neue Domäne das Dienstkonten für BackupExec auf ein Konto der neuen Domäne umzustellen - nachträgliche Änderungen sind scheinbar schwierig / unmöglich, eine Neuinstallation wäre notwendig.

Die BackupExec Jobs müssen nach Lahmlegung der alten Domäne übrigens neu erstellt werden. Da man schwer an die alten Job-Infos rankommt, am Besten vorher die Jobs genau dokumentieren (Sicherungsausnahmen, wann wird der Job ausgeführt etc.).

=== Gruppenmigration ===

In aller Regel sollten auch alte, nicht mehr existierende Benutzeraccounts inkl. deren Gruppen migriert werden. Dadurch vermeidet man, separat nochmal die Gruppen migrieren zu müssen. Nochmal: Builtin-Gruppen wie etwa Domänen-Admins können NICHT migriert werden. Hier ist Handarbeit gefragt: alle Mitglieder müssen in der Zieldomäne per Hand nachgepflegt werden.

== Computermigration: umstellen der Client-Rechner und der Domänenameldung ==

Den Schritt ''Benutzer- und Gruppenmigration'' und die ''Sicherheitskonvertierung'' kann man im "Live-Betrieb" machen, also auch dann, wenn User in der Quelldomäne nach wie vor arbeiten. Wenn man nun das Computerkonto umstellt, sollte/muss man auch die Benutzerkonten der Zieldomäne zum Anmelden verwenden. In meiner Umgebung führte ich das Umstellen der Computeraccounts nach und nach durch, so kommt es nicht zum "Wochenend-Stress". Starte den Computermigrations-Assistenten:

# Domänen auswählen
# Computer aus Domäne auswählen
# Wähle den entsprechenden Rechner aus
# Gib die Ziel-OU an, in der das Computerkonto erstellt werden soll
# Im Gegensatz zur Sicherheitskonvertierung für Server, wähle bei ''Objekte konvertieren'' alles aus
# Bei den ''Optionen für die Sicherheitskonvertierung'' auf ''Hinzufügen'' stellen - tut ja keinem weh...
# Die Minuten im nächsten Schritt zielen darauf ab, dass die DCs der Zieldomäne in diesem Zeitraum miteinander repliziert haben und das Konto somit auf jedem DC bekannt ist
# Wie beim Benutzerkonto auch, kann man wieder bestimmte Attribute rausfiltern, die nicht migriert werden sollen
# ''Quellobjekte nicht migrieren, wenn in der Zieldomäne ein Konflikt ermittelt wird'': klar, wenn dasselbe Computerkonto in der Zieldomäne existiert, sollte man den PC-Namen des Quellobjektes vorab anpassen

Nachdem das Computerkonto in der neuen Domäne erstellt wurde und man beim ''Migrationsstatus'' auf ''Schließen'' klickt, wird ein weiterer Assistent automatisch aufgerufen. Dieser installiert auf dem Zielsystem dann einen Agent, welcher die Domänenmitgliedschaftsänderung, Rechtevergabe etc. durchfürt. 

'''Wichtig: der Client muss zum Zeitpunkt der Migration eingeschalten und am Besten vorher mal neu gestartet worden sein!''' Durch den Neustart soll verhindert werden, dass Dateien im Benutzerprofil im Zugriff sind - sonst kommt es während der Migration zu Fehlern.

In dem Assistenten wähle bei ''Agent-Aktionen'' die Option ''Vorüberprüfung und Agent ausführen'' aus, klicke dann auf ''Starten'', um den Vorgang auszuführen.

== Erstanmeldung in der neuen Domäne ==

=== Vorarbeiten ===

Benutzer, Gruppen und Client-Rechner sind nun in der Zieldomäne, auf den Servern der Quelldomäne wurde die Sicherheitskonvertierung fehlerfrei ausgeführt. '''Bevor man sich das erste mal nun anmeldet,''' sollte noch geprüft werden:

# Passen die zugeordneten Gruppenrichtlinien für Benutzer und Computer?
# Wurden die Anmeldeskripte aus der alten Domäne (sysvol) in's sysvol der neuen Domäne kopiert?
# Passt der Pfad zum Terminalserverprofil?
# Wurde das Zufallskennwort zurückgesetzt?

Wer einen Terminalserver in der alten Domäne im Einsatz hat und die von mir angewendete "Schritt-für-Schritt" Migration durchzieht, der erhält beim Login mit dem Konto der Zieldomäne am Terminalserver der alten (Quell-) Domäne evtl. folgende Meldung:

 Gesamtstrukturübergreifende servergespeicherte Benutzerprofile werden deaktiviert

Die Lösung steht auf http://www.lubby.org/result.jsf?DB=lkb_windows_german&ID=137 - einfach eine Gruppenrichtlinie konfigurieren und fertig. Die Richtlinie ist zu finden unter

 Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinien\Gesamtstrukturübergreifende Benutzerrichtlinien und servergespeicherte Benutzerprofile zulassen

und muss für den Terminalserver (!) aktiviert werden. Davon ausgehend, dass für den Terminalserver ohnehin eine spezielle Gruppenrichtlinie (mit aktiviertem Loopback-Verarbeitungsmodus) eingerichtet ist, einfach diese Policy entsprechend um den genannten Eintrag erweitern,

 gpupdate /target:computer

am Terminalserver ausführen und schon sollte es mit der Anmeldung klappen. Klar: am Terminalserver muss der lokalen Gruppe ''Remotedesktopbenutzer'' evtl. noch die migrierte Gruppe der neuen Domäne hinzugefügt werden. Auch darauf achten, dass die Sicherheitskonvertierung über den Terminalserver gelaufen ist. Wie man Richtlinien für Terminalserver einrichtet, findest du im Beitrag [http://wiki.butzhammer.de/index.php/Korrektes_Einstellen_von_Gruppenrichtlinien Koorektes Einstellen von Gruppenrichtlinien]

=== Erstanmeldung ===

Meldet man sich - unter Beachtung der Vorarbeiten - nun am migrierten PC mit dem migrierten Benutzerkonto an, sollte das auch problemlos klappen. Prüfe, ob die Laufwerke verbunden wurden, Gruppenrichtlinien ziehen, der User drucken kann, Programmaufrufe funktionieren usw. Auch ein Blick in die Ereignisanzeige kann auf Probleme / Fehler hinweisen.

=== Besonderheiten für Exchange und Outlook ===

Um dem migrierten User nun Zugriff auf sein Postfach am alten Mailserver zu gewähren, müssen ein paar Postfach-Rechte angepasst werden. Ich gehe davon aus, dass ein Exchange 2007 oder 2010 zum Einsatz kommt, starte die Powershell am Server und führe folgende Befehle aus

 Add-MailboxPermission "<Postfachname>" -User "neue-domäne\migrierter_user" -AccessRights FullAccess
 Add-ADPermission -Identity "<Postfachname>" -User "neue-domäne\migrierter_user" -ExtendedRights Send-As
 Add-ADPermission -Identity "<Postfachname>" -User "neue-domäne\migrierter_user" -ExtendedRights Receive-As

Achtung: bis das Recht, Mails zu versenden, zieht, kann einige Zeit vergehen - eventuell bis zu einer Stunde! Starte nun Outlook und vergewissere dich, dass der Benutzer das Postfach problemlos öffnen kann. 

'''Achtung - Recht "Senden als" wird nach 10 Minuten automatisch wieder entfernt:"''' während der Migration ist mir folgendes Problem aufgefallen. Das Recht zum ''Senden als'' wurde wie oben beschrieben für das entsprechende Postfach gesetzt, nach 10 Minuten waren die gemachten Einstellungen aber wieder verschwunden, lediglich der Vollzugriff auf's Postfach funktionierte nach wie vor, beim Versenden einer Nachricht erhielt man aber die Meldung

  Sie sind nicht berechtigt, diese Nachricht zu senden, weil Sie sie im Auftrag eines anderen Absenders zu senden versuchen, ohne dazu berechtigt zu sein. Vergewissern Sie sich, dass Sie im Auftrag des richtigen Absenders senden, oder wenden Sie sich an den Systemadministrator, um die erforderliche Berechtigung zu erhalten.

Die Ursache: http://www.msxfaq.de/konzepte/adminsdholder.htm Kurz zusammengefasst: im Snap-In ''Active Directory-Benutzer und -Computer'' mit der rechten Maus auf das entsprechende Benutzerkonto in der Quelldomäne klicken, ''Eigenschaften'' wählen und die Registerkarte ''Sicherheit'' auswählen. Klicke dann auf den Button ''Erweitert'' und setze den Haken bei ''Berechtigungen übergeordneter Objekte, sofern vererbbar, über alle untergeordneten Objekte verbreiten (...)''. Öffne dann den ADSI Editor (Domain-Knoten), rechte Maustaste auf das betroffene Benutzerkonto und prüfe das Attribut ''adminCount''. Hier sollte bei ''Value'' der Wert ''1'' eingetragen sein. Öffne das Attribut und klicke auf den Button ''Clear'', was dazu führt, dass adminCount auf ''<Not Set>'' gesetzt wird. Prüfe anschließend noch, ob das betroffene Konto Mitglied in einer der folgenden Gruppen ist:


 Enterprise Admins
 Schema Admins
 Domain Admins
 Administrators
 Account Operators
 Server Operators
 Print Operators
 Backup Operators
 Cert Publishers
 krbtgt

Sollte dies der Fall sein, bitte die Frage stellen, ob die Gruppenmitgliedschaft notwendig ist. Befolge sonst noch die Anweisungen auf http://www.msxfaq.de/konzepte/adminsdholder.htm zum Zurücksetzen der ACL auf Standard-Einstellungen.

Vergib nun nochmal erneut die Rechte am Exchange, evtl. wieder die 1 Stunde abwarte, der Versand sollte anschließend klappen:

 Add-ADPermission -Identity "<Postfachname>" -User "neue-domäne\migrierter_user" -ExtendedRights Send-As
 Add-ADPermission -Identity "<Postfachname>" -User "neue-domäne\migrierter_user" -ExtendedRights Receive-As

Beim Versand kann es zur genannten Verzögerung kommen, hier einfach immer wieder mal eine Testmail versenden probieren.

Führe oben aufgezeigte Befehle für alle Postfächer, auf die der migrierte User Zugriff haben soll, aus. 

'''Achtung - Outlook NK2-Dateien:''' wenn man in das "An"-Feld von Outlook einen Empfänger eintippt, wird - sollte man bereits mal eine Mail an diesen Empfänger verschickt haben - die Adresse in einer Vorschlagsliste angezeigt. Diese Datei (bis Outlook 2007, ab Outlook 2010 im Menü unter "Datei" zu finden) muss gelöscht werden, da es sonst zu Effekten kommt, wie: "Die Mail ist beim Empfänger nie angekommen". Wie man hier vorgeht, findest du im Beitrag [[Outlook-Cache für Adressen löschen]].

=== Public Folder unter Outlook 2010 ===

Outlook 2010 mach bei den Öffentlichen Ordnern Probleme: wenn man auf den Public Folder am alten Server mit dem migrierten, neuen Konto zugreifen will, wird der Zugriff ggf. verweigert. Soweit ich das verstanden habe, hängt das damit zusammen, dass Outlook nun nicht mehr hergeht und als "Postfachbenutzer" auf den Öffentlichen Ordner zugreift, sondern Outlook die Anmeldeinfos des aktuell angemeldeten Windows-Benutzers übermittelt. Wenn hier die Rechte im Public Folder nicht passen, hat man keinen Zugriff. Abhilfe: man kann etwa das Tool PFDavAdmin - Beitrag [PfDavAdmin - das kleine aber feine Helferlein] beachten - bzw. unter Exchange 2010 das mitgelieferte Tool ExFolders verwenden, um der Gruppe "Jeder" zumindest Lesezugriff auf sämltiche Ordner zu geben. Sollte das nicht gewünscht sein, so muss man zunächst Benutzer, die keinen Zugriff auf den Öffentlichen Ordner haben, migrieren und eine Wochenend-Schicht einlegen, um dann die übrigen Konten + Exchange umziehen zu können.

== Problem mit defekten bzw. nicht funktionierenden Benutzerprofilen ==

Zwar trat bei mir keiner der genannten Fehler auf, unser Support-Partner wies aber auf eventuelle Probleme mit Benutzerprofilen hin (vielen Dank!).

Effekte:
# User kann per Regedit unter HKCU\Software keinen neuen Key erstellen
# Tastaturlayout ist Englisch
# Keine Desktophintergrund
# Outlook-Konfig fehlerhaft
# Sofortige Abmeldung bei Windows 7-Rechnern
# Keine Netzlaufwerke
# ...

Behebung:
# User abmelden und als MAX-AICHER-Administrator annmelden
# Regedit starten und auf HKEY_USERS klicken
# Im Menü auf "Datei->Struktur laden..." und die NTUSER.DAT aus dem Profilverzeichnis des Problembenutzers auswählen (C:\Users\... oder c:\Dokumente und Einstellungen\...).
# Als Name einen beliebigen Namen, z.B. Test wählen
# Über das Kontextmenü der neuen Struktur "Berechtigungen..." wählen und dem Problembenutzer Vollzugriff erteilen
# Die folgenden Registrykeys löschen
## HKEY_USERS\Test\Software\Policies
## HKEY_USERS\Test\Software\Microsoft\Windows\CurrentVersion\Policies
## HKEY_USERS\Test\Software\Microsoft\Windows\CurrentVersion\Group Policy
# Auf HKEY_USERS\Test klicken und über das Menü "Datei->Struktur entfernen..."
# Als Administrator abmelden und als Benutzer anmelden. Kontrolle über Regedit und neuen Key innerhalb von HKCU\Software anlegen und wieder löschen

== SID-Leichen entfernen ==

Auch dieser Tipp stammt von unserem Support-Partner.

Falls trotz aller Mühe SID-Leichen im Dateisystem entstanden sind, kann durch das Tool subinacl (Download über die Microsoft-Webseite) die SIDs der Quell-Domain durch die SIDs der Ziel-Domain ausgetauscht werden. Dazu dient der Befehl 

 subinacl.exe /subdirectories <laufwerk>:\*.* /replace=<SID in der Quelldomain>=<SID in der Zieldomain>

Dabei können folgende BuildIn-SIDs bei der Zuordnung hilfreich sein:
# S-1-5-21-<Domainanteil>-500 = Administrator
# S-1-5-21-<Domainanteil>-512 = Domänen-Admins
# S-1-5-21-<Domainanteil>-513 = Domänen-Benutzer
# S-1-5-21-<Domainanteil>-514 = Domänen-Gäste
# S-1-5-21-<Domainanteil>-515 = Domänencomputer
# S-1-5-21-<Domainanteil>-516 = Domänencontroller

Beispiel:

 subinacl.exe /subdirectories d:\*.* /replace=S-1-5-21-414998999-842725246-687007330-513=S-1-5-21-1644417447-675588072-1845911577-513

Den Domänenteil der Quell- und Zieldomäne findet man am Leichtesten raus, indem man sich an einem Quellserver als Domänen-Admin anmeldet und in die Registry unter

 HKEY_USERS\

nachsieht. Hier stehen die SIDs sämtlicher User, die an dem Server angemeldet waren - interessant sind jene Schlüssel:

 S-1-5-21-414998999-842725246-687007330-<...>

Was der Domänen-Teil ist - siehe oben. Dasselbe mache bitte auch an einem Server der neuen Domäne, hier lautet dann die SID z. B.

 S-1-5-21-1644417447-675588072-1845911577-<...>

[[Kategorie:Domänencontroller]]