Fix-MAPIProfile

Ein ähnlicher und eventuell sogar besserer Ansatz einer Lösung finden Sie auf "VBScript to Remap your Outlook Profiles to a new server." (http://davedolan.com/blog/?p=83). Ich wollte ihnen aber die Ausführungen und Analysen nicht vorenthalten.

Mit Exchange 2010 hat sich eine Funktion des CAS-Servers geändert, die den meisten Administratoren erst mal nicht weiter auffällt. In allen vorherigen Versionen von Exchange waren Sie es gewohnt, das ein Outlook Client sich bei jedem Start mit dem Server verbindet, der im Profil hinterlegt ist.
Wurde dann das Postfach auf einen anderen Server verschoben, dann hat der alte Exchange Server dem Client einen "Redirect" mit gegeben und Outlook hat sich zukünftig mit dem neuen Server verbunden. In dem Zuge wurde auch das lokale MAPI-Profil aktualisiert, d.h. auch bei zukünftigen Starts hat Outlook den neuen Server gefragt. Entsprechend hat ein schlauer Admin den alten Server einige Zeit lang noch laufen lassen, bis sich ein Großteil der Clients automatisch umkonfiguriert hat. Selbst nach der Deinstallation des alten Exchange Servers konnten sie mit einem DNS/WINS-Eintrag arbeiten, der Anfragen auf den alten Server auf einen funktionierenden Server geleitet hat.

Mit Exchange 2010 RTM ist genau diese Umleitung mit umkonfiguration aber nicht mehr Bestandteil des CAS-Servers oder CAS-Array. Nicht umsonst empfiehlt daher Microsoft den Kunden mit Exchange 2010 immer ein CAS-Array einzurichten, selbst wenn sie nur einen Exchange Server haben.
Wenn spätestens bei der nächten Migration des Postfachs auf einen anderen Exchange 2010 Server bleibt im MAPI-Profil der alte Servername erhalten. Wenn dies schon ein CASArray war und der neue Server in der gleichen AD-Site liegt, ist das kein Problem. Wenn aber der neue Server in einer anderen AD-Site liegt, dann greift der Client weiterhin auf den "alten" Servernamen zu.

Interessanterweise war das Problem auch schon mit Exchange 2003 da, wenn man Benutzer über eine Admingroup hinweg verschoben hat

After you move a mailbox across an administrative group, any Microsoft Outlook profiles that were in use für this mailbox no longer function correctly. Mailbox servers can refer Outlook to the correct server after mailboxes have been moved within an administrative group, but this process does not work correctly für mailboxes that are moved across an administrative group. Security settings für e-mail mesages, calendaring, free and busy information, public folder moderation, and delegation may not work. You must Update the profile für 100 percent functionality after such a move. A profile redirector tool has been created to address this situation.
Quelle: 873214 The Exchange Profile Update tool

Mit Exchange 2010 hat sich das aber noch verschlimmert, da es hier keine sichtbaren Admingroups mehr gibt (alle in der gleichen Admingroup) aber ein verschieben der Mailbox in eine andere Seite dennoch keinen Redirect (ecWrongServer) antriggert.

Richtige Lösung ?

Eigentlich würde ich fragen, warum Microsoft diese nette Funktion in Exchange 2010 entfernt hat. Vielleicht war es im Rahmen der Migration zu MOMT nicht anders möglich oder man hat Stark auf "Autodiscover" gesetzt. Ein Client versucht ja eine neue Auflösung, wenn er das Postfach nicht erreicht. Aber wenn Firmen ihre Postfächer innerhalb der Organisation in andere Standorte verschieben, dann bleibt das Problem essentiell. Und wer will schon immer die alten Namen als DNS-Alias weiter mitführen. Schlimmer ist aber die Auswirkung, dass ein Client den "falschen" CAS für den Zugriff auf das Postfach per MAPI nutzt.

Interessanterweise kann man beim Einrichten eines Profils durchaus einen "falschen" Server angeben und Outlook wird dann zu dem Server verwiesen, der an der Exchange Datenbank "RPCClientAccessServer" gepflegt ist. Hier sollte das CASARRAY in der AD-Site hinterlegt sein.

Zugriffe per ActiveSync, OutlookWebApp etc. sind hiervon nicht betroffen.

Hinweis:
Wenn Outlook 2007/2010 den Server nicht mehr findet, dann wird ein "Autodiscover" gestartet. Wer also den "alten" Server im Rahmen einer Komplettmigration "entfernt", so dass dieser per DNS nicht mehr auflösbar ist, dann startet ein neuer Autodiscover-Prozess. Ich weiß leider nicht, ob dies auch bei einer "nicht Erreichbarkeit" gegeben ist.
Ein CASArray kann man natürlich einfacher mal "umbenennen" als einen Server.

 

Offene Tests:
MAPI-Einrichtung mit "falschem CAS". wird er umgeleitet ?
Move 2007->2010. wird MAPI umgestellt (ex2007 leitet um?)
Move 2010 > 2007 wird Outlook wirklich nicht umgestellt ?
Move 2010 -> 2010  (z.B. von DAG auf NichtDAG oder andere Site. Wird Outlook nicht angepasst ?

 

Suche nach Abhilfe

Richtig Ruhe hat mir das nicht gelassen und so habe ich ein paar Tests gemacht. Wenn man schon nicht direkt per C++ die MAPI-Profile beackern will, wie dies Firmen wie Priasoft, Quest und andere tun, dann sollte es doch nicht so schwer sein, das MAPI-Profil in der Registrierung so zu verändern, dass Outlook annimmt, es sei noch nicht "überprüft" worden und eine neue Verbindungseinrichtung vornimmt.

Ich habe dann zuerst mal mein MAPI-Profil exportiert und dann über die Einstellungen einfach im Feld mit meinen "Namen" etwas geändert aber nicht gespeichert. Sofort hat Outlook auch den unterstrichenen Servernamen wieder "frei" gegeben. Diesen Stand habe ich wieder exportiert.

Es wurden mehrere Schlüssel entfernt, von denen ein Zweig am interessantesten war:

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\19f82bc60987bf4e89960348269cc4ee]
"001e6602"="NAWEX001"
"001e6603"="/o=Net at Work GmbH/ou=Paderborn/cn=Recipients/cn=fcarius"
"001e6612"="/o=Net at Work GmbH/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=NAWEX001"
"101e6613"=hex:06,00,00,00,1c,00,00,00,33,00,00,00,44,00,00,00,56,00,00,00,69,\
00,00,00,8c,00,00,00,6e,63,61,63,6e,5f,76,6e,73,5f,73,70,70,3a,4e,41,57,45,\
58,30,30,31,00,6e,65,74,62,69,6f,73,3a,4e,41,57,45,58,30,30,31,00,6e,63,61,\
63,6e,5f,6e,70,3a,4e,41,57,45,58,30,30,31,00,6e,63,61,63,6e,5f,73,70,78,3a,\
4e,41,57,45,58,30,30,31,00,6e,63,61,63,6e,5f,69,70,5f,74,63,70,3a,4e,41,57,\
45,58,30,30,31,2e,6e,65,74,61,74,77,6f,72,6b,2e,64,65,00,6e,63,61,6c,72,70,\
63,3a,4e,41,57,45,58,30,30,31,00
"001f3001"=hex:66,00,72,00,61,00,6e,00,6b,00,2e,00,63,00,61,00,72,00,69,00,75,\
00,73,00,40,00,6e,00,65,00,74,00,61,00,74,00,77,00,6f,00,72,00,6b,00,2e,00,\
64,00,65,00,00,00

Diese Einträge waren danach "weg" und wer die HEX-Felder in einem String anschaut, sieht auch hier, dass da z.B. mein LegacyExchangeDN codiert war. Ich habe dann mal versucht mein aktives Profil durch entfernen einzelner Schlüssel in den "nicht konfigurierten" Zustand zu bringen, d.h. das der Servername und Benutzername nicht "unterstrichen" waren.

Ich habe dann mal ein Feld nach dem anderen umbenannt und immer wieder in den Outlook Profilen nachgeschaut, bis die Daten nicht mehr "unterstrichen" waren. Anscheinend spielt das Feld "001f3001" eine Schlüsselrolle.

Weiterhin wurden auch in anderen Zweigen des Profile Felder gelöscht. Es waren erstaunlich viele Felder mit dem Namen "Identity Eid" dabei und auch Felder mit dem Namen "00033009" wurde geändert. Ich kann anhand der im Umfeld befindlichen Eintragungen nur vermuten, dass es sich dabei um zusätzlich geöffnete Postfächer und Stellvertreter handelt, die ebenfalls im Profil eingebunden sind.

Das Skript löscht die folgenden vier Einträge

			Shell.RegDelete(exprofile & "\" & "001e6603")
			Shell.RegDelete(exprofile & "\" & "001e6612")
			Shell.RegDelete(exprofile & "\" & "001e6613")
			Shell.RegDelete(exprofile & "\" & "001f3001")

Danach war bislang immer das Profil als "nicht aufgelöst" gelistet. Ich konnte aber noch nicht 100% sicherstellen, dass danach Outlook ein "Autodiscover" macht.

Der Weg zum MAPI Profil

Nachdem diese Registry-Änderungen anscheinend eine Lösung darstellen könnten, muss es natürlich einen Weg geben, diesen Zweig zu "finden. Denn ein Vergleich mit anderen Profilen hat ergeben, dass die GUID nicht immer identisch ist. Aber mit etwas Recherchieren im Internet und meinen eigenen Informationen von MAPI mit RegEdit konnte ich einen vermutlich sicheren Pfad ermitteln.

Es beginnt alles wieder beim Master-Key" eines Profils, der anscheinend immer gleich ist.

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\<profilname>\9207f3e0a3b11019908b08002b2a56c2

Unter diesem Schlüssel gibt es ein Feld "01023d02", welches auf den ersten Blick nur Zahlen enthält.

Aber genau diese Zahlenkette ist ein Link auf den nächsten Schlüssel im Profil.

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\<profilname>\<link>

In diesem Bereich gibt es dann wieder ein Feld "01023d15", welches erneut einen Link enthält. Dieser verweist allem Anschein auf das Exchange Profil.

Damit wäre der Weg gefunden.

Let's Patch

Die Modifikationen des Profils müssen auf dem Client vorgenommen werden, da die Einstellungen in "HKEY_Current_User" zu finden sind. Diese können nicht direkt zentral geändert werden. Da auf den wenigsten Clients "PowerShell" installiert ist, bleibt nur die Entwicklung einer EXE oder eines VBScripts. Als "Proof of concept" ist VBScript natürlich sehr gut geeignet.

Das folgende Skript wird vom Benutzer aufgerufen, sucht sich den Weg durch alle Profile und entfernt das Feld, damit beim nächsten Start von Outlook eine neue Verbindungssuche stattfindet. Outlook wird zwar erneut den alten Server ansprechen (was man sicher auch noch "patchen" könnte, aber dann auf den richtigen CAS-Server verwiesen.

Das folgende Skript löscht ziemlich rabiat ein paar Schlüssel in den Profilen, um Outlook eine Neuermittlung aufzuzwingen

Da es keine verlässliche Dokumentation zu den Registrierungsschlüsseln eines MAPI-Profils gibt, erfolgt der Einsatz auf eigene Gefahr.

fixmapiprofil.1.0.vbs

Einschränkungen bzw. offene Punkte

Natürlich ist dieser "Weg" einer Veränderung weit weg von irgend einer "supporteten" Version und kann, aber muss nicht funktionieren. Zudem bin ich nicht sicher, wie Outlook zusätzliche Einträge von Stellvertretern, zusätzlichen Kontakten oder Verweise auf öffentliche Ordner behandelt. Hier ist sicher noch mehr Aufwand in Analyse und Test erforderlich.

 

Weitere Links