Fix-MailboxGuid

Wie auf der Seite MailboxGUID bereits beschrieben ist, benötigt eine Mailbox auch eine GUID. Dieser eindeutige Kennzeichner einer Mailbox verbindet das Object im Active Directory mit dem Postfach in der Datenbank. ändert man die GUID beim AD-Benutzer, dann hat er beim nächsten Zugriff ein leeres Postfach und der Admin findet eine "Disconnected Mailbox" in seinem Postfachspeicher wieder. Änderungen an der GUID sollten also wohl überlegt sein.

Bei Exchange 2003 setzt der STORE die GUID bei einem neuen Benutzer, sobald der darauf zugreift. Bei Exchange 2007 machen das die Commandlet (New-Mailbox, Enable-Mailbox und Move-Mailbox). Allerdings kann es passieren, dass ein Admin mit "alten Exchange 2003-Tools" eine Mailbox in einer Exchange 2007 Umgebung ohne Exchange RUS anlegt. Die Folge ist dann ein quasi nicht pflegbares Objekt:

Auch in der GUI wird das Problem beim Bearbeiten des Objekts angezeigt

Nerviger ist hier, dass die Lösung durch Drücken von "OK" suggeriert wird, aber (Exchange 2007SP1) nicht durchgeführt wird. Weiter Irreführend ist hier die Feldbezeichnung "ExchangeGUID"

Lösung mit Skript

Es ist nicht ganz einfach, eine GUID sich auszudenken und per ADSIEDIT bei einem oder vielen Postfächern einzutragen. Besser ist hier natürlich ein Skript, welches sich über entsprechende Funktionen eine hinreichend eindeutige GUID erzeugt und bei den betreffenden Postfächern einträgt. Genau das macht Fix-MailboxGUID.ps1.

Es sucht mittels "Get-Recipient -RecipientType Usermailbox " zuerst alle Postfächer, egal ob Postfach, Links, Ressourcen oder Legacy) und prüft für jedes Postfach das Feld "msExchMailboxGUID" des Benutzerobjekt. Wenn das Feld nicht vorhanden ist, dann wird eine GUID generiert und geschrieben.

Download und Einsatz

Das Skript bedarf fast keiner Konfiguration, da es mit "Get-Recipient" startet und daraus dann die LDAP-Pfade der Objekte ableitet.

fix-mailboxguid.1.2.ps1
Nach dem Download als PS1-Datei umbenennen

Sie müssen das Skript aber aus der Exchange Management Shell starten und die defekten Empfänger auch modifizieren dürfen. Das trifft zu, wenn Sie in der Gruppe "Exchange Recipient Administratoren" Mitglied sind. Das Skript selbst startet per Default mit Rückfragen. Ehe die GUID geschrieben wird, erhalten Sie eine Rückfrage zur Bestätigung.

Die eigentliche Ausgabe erfolgt im PowerShell-Fenster.

Bildschirmausgabe

Wenn Sie das Skript automatisch z.B. per Taskplaner immer wieder laufen lassen wollen, dann sollten Sie die Definition von "$unattend" auf "$True" wie im hier im Codeauszug setzen.

#[bool]$unattend = $false # unattened Mode OFF
[bool]$unattend = $false # unattened Mode ON

In dieser Betriebsart wird ohne weitere Rückfrage eine GUID vergeben. In größeren Umgebungen sollten Sie überlegen, das Skript auf einen Domaincontroller zu fixieren, damit es bei häufigen Aufrufen nicht zur mehrfachen Festlegung der GUID kommt. Da die letzte Aktion gewinnt, könnten Mails davor in einer disconnected Mailbox landen.

Eine Überwachung des Skripts ist einfach über das Eventlog möglich.

Eventlog

GUID und PowerShell

Relativ wieder nur, weil die GUID ein Array von 16 Bytes ist, aber es verschiedene Verfahren der Anzeige und Verwaltung gibt, wie sie auch schon auf DumpRUSUser beschrieben sind. Hier erwischen mich vier Schreibweisen

  • ADSIEDIT
    Per LDAP erhalte ich Ein Array of OctedString, d.h. hexadezimale Zahlen als Array

93 2A 6B 5C DE 82 A4 4A 84 41 84 32 BC 91 66 38

  • PowerShell msExchMailboxguid
    Die Ausgabe eines per PowerShell und ADSI verbundenen Objekts liefert ein Array mit Dezimalzahlen
[PS]>$test3.msExchMailboxguid[0]
147 42 107 92 222 130 164 74 132 65 132 50 188 145 102 56
  • GUID native und String
  • Generiert man sich eine GUID per .NET Framework, dann erhält man eine kaum brauchbare Variable mit Inhalt. Erst mit "toByteArray()" erhält man ein per ADSIEDIT verwendbares Format. Mit "ToString()" die Textpräsentation ohne geschweifte Klammern:
[PS]>[guid]::NewGuid().ToString()
0609bb11-7f17-4db0-b862-f692373bb88c

Weitere Links