Hallo Freunde der Sonne,
heute geht es um das Verschieben von Postfächern ohne Bestätigung des Ausgangsservers.
Wann kann dies wichtig sein?
Wenn der alte Server nicht wiederhergestellt werden kann, aber die Rohdaten vorliegen bzw. die Berechtigungen der Postfächer übernommen werden sollen.
Ok, dieser Post baut darauf auf, dass man eine Datenbank mit Postfächern eines defekten Servers auf einem neuen Server wiederhergestellt hat. Es geht nun darum die Postfächer zur neuen Postfach-Datenbank zu verknüpfen.
Neu Verknüpfen der Mailbox-Datenbank von Postfächern
In diesem Artikel wird absichtlich keine Rücksicht darauf genommen wie man mit ADSIedit umgeht,
wer dies nicht beherrscht sollte sich erst damit auseinander setzen.
Daher auch wieder der allgemeine Hinweis:
Änderungen die via ADSIedit vorgenommen werden, können nicht rückgängig gemacht werden – es müssten alle Domänen-Controller auf einen gemeinsamen Zeitpunkt von vor der Anpassung wiederhergestellt werden.
Diese Praxis ist jedoch bei großen Netzwerken ehr schwer realisierbar – daher bei Unsicherheit oder alternativen Möglichkeiten FINGER WEG!
Wann ist der passende Zeitpunkt für das Anpassen der Mailbox-Datenbank gekommen?
Aus Erfahrung würde ich sagen: wenn sich der ursprüngliche Server nicht wiederherstellen lässt,
aber die Datenbank des Server selbst in einer verwertbaren Form befindet.
(Beispiel: nur Nutzdaten-Backup)
Kritischer Punkt außerdem sind die Postfacheinstellungen selbst – sollte der Aufwand des neu generieren von Postfächern auf Grund von Berechtigungen und weiterer AD-Verknüpfungen als zu gravierend formulieren.
(Beispiel: externe Lösungen, Postfachberechtigungen/-freigaben)
Um welche Objekte im ADSIedit dreht sich dieser Artikel?
Benutzerkonten, natürlich im ADSI als Container wie alle anderen Objekte auch.
Das Schema für dieses Objekt lautet: „person, user, organizationalPerson“.
Ggf. siehe auch: „objectCategory“ – deshalb ist „person“ unterstrichen…
In welchem ADSI-Kontext zu finden?
Standard/Domain
Wo finde ich diesen Benutzer, bzw. welches Attribut bezeichnet dieses Objekt?
Im Active Directory wäre das der „distinguishedName“, Beispiel:
CN=<Benutzer>,OU=<Organisationseinheit>,OU=<Organisationseinheit>,DC=<Domäne>,DC=<TLD>
Beispiel an „example.local“:
CN=max.mustermann,OU=Mitarbeiter,OU=Unternehmen,DC=example,DC=local
Um welche Attribute (unter Eigenschaften des Objekts) dreht es sich?
Erst einmal sollte man alle leeren Felder der Hauptobjekte ausblenden lassen,
dann geht es zu:
- homeMDB
- homeMTA
- msExchHomeServerName
Anpassungen unter Exchange 2007
Was sollte bei einem neuen Server mit altem Datenbanknamen geändert werden – unter: „homeMDB“?
Hier wieder am Beispiel „example.local“:
CN=Mailbox Database,CN=First Storage Group,CN=InformationStore,CN=SERVERNAME,CN=Servers,CN=Exchange Administrative Group (123456789123456),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=example,DC=local
Tipp: Der Objektpfad kann auch unter dem ADSI-Kontext: Konfiguration verfolgt werden,
wenn nicht dann ist etwas falsch.
Was sollte bei „homeMTA“ geändert werden?
Wieder am Beispiel von „example.local“:
CN=Microsoft MTA,CN=SERVERNAME,CN=Servers,CN=Exchange Administrative Group (123456789123456),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=example,DC=local
Und zu guter Letzt bei „msExchHomeServerName“?
Natürlich in Form der „example.local“:
/o=First Organization/ou=Exchange Administrative Group (123456789123456)/cn=Configuration/cn=Servers/cn=SBS
In diesem Prozedere wurde der Server auf den neuen Server angepasst.
Anpassungen unter Exchange 2010
Im Beispiel für Exchange 2010 markiere ich Felder bei geänderter Mailbox-Datenbank,
wer ein bisschen drauf achtet dem fällt auf: das Feld „homeMDB“ beinhaltet bei Exchange 2010 nicht mehr den Server. (allgemein sind bei Exchange 2010 auch die StorageGroups verschwunden)
Datenbankanpassung auf die Datenbank 1122334455, für den neuen Server: Servername2:
Was passiert unter „homeMDB“?
Siehe hier:
CN=Mailbox Database 1122334455,CN=Databases,CN=Exchange Administrative Group (123456789123456),CN=Administrative Groups,CN=EXAMPLE,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=example,DC=local
Was passiert unter „homeMTA“?
Siehe hier:
CN=Microsoft MTA,CN=SERVERNAME,CN=Servers,CN=Erste administrative Gruppe,CN=Administrative Groups,CN=EXAMPLE,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=example,DC=local
Anpassen in wäre möglich:
CN=Microsoft MTA,CN=SERVERNAME2,CN=Servers,CN=Exchange Administrative Group (123456789123456) ,CN=Administrative Groups,CN=example,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=example,DC=local
Bei mir im Test ist jedoch ein fataler Wert aufgetaucht: alter Server von 2003.
Scheint so als würde sich Exchange 2010 nicht mehr des Wertes „homeMTA“ bemühen…
(die Exchange 2010-Umgebung wurde direkt von Exchange 2003 migriert – alte Gruppe, alter Server)
Was sollte unter „msExchHomeServerName“ angepasst werden?
Siehe hier:
/o=EXAMPLE/ou=Exchange Administrative Group (123456789123456)/cn=Configuration/cn=Servers/cn=MAIL3
Hier wird der Server auf dem das Postfach liegt angegeben.
Dies war nun auch bei Exchange 2010 der, der „homeMTA“-Wert scheint also an Bedeutung verloren zu haben.
Nun ja man kann sich also ein Feld wegen der „LegacyDomain“ sparen wie es scheint.
Diese scheint unter anderem auch der primäre Grund zu sein, weshalb keine alten administrativen Gruppen aus dem ADSI gelöscht werden dürfen.
(es gibt also genug alte Objekte die daher die alten Pfadzuordnungen bedürfen – zum Beispiel: primärer öffentlicher Ordner der Domäne, alte Verteilergruppen)
Dieser Post/Artikel ist vorerst nur geschrieben worden um in den späteren Wiederherstellungs-Posts als letzte Möglichkeit verlinkt zu werden.
Anpassung ohne ADSIedit
Für alle die eine Datenbank auf einem neuen Server wiederherstellen und nicht per ADSIedit die Werte korrigieren wollen der Tipp:
Verwendet das PowerShell-Kommando:
Disable-Mailbox -Identity <Mailbox>
Dieses gibt Euch einen Fehler aus, dass keine Bestätigung vom Quellserver verfügbar war – entfernt aber die Exchange-Zuordnungen im Active Directory.
Danach könnt Ihr nach getrennten Postfächern in der wiederherstellten Datenbank suchen und diese mit den Benutzerkonten neu verbinden.
Weitere hilfreiche Kommandos wären hierbei (zum anzeigen von dann getrennten Konten):
Clean-MailboxDatabase <Database>
oder auch:
Get-MailboxStatistics | where-object { $_.DisconnectDate -ne $null } | Select DisplayName,MailboxGuid