Recipient Type Mismatch
Exchange Objekte haben eigentlich immer einen eindeutigen Status. Postfächer sind entweder On-Premises oder in Exchange Online. Was passiert aber, wenn etwas doch nicht passt? Dann finden Sie mit "Get-Recipient" einen MailUser, der eigentlich ein Postfach ist. Zeit für eine Verifizierung.
Auslöser
Bei einem Kunden habe ich das Exchange Provisioning entwickelt und ein Linux-basiertes Identity Management hat meine PowerShell-REST-API aufgerufen, welche dann die gewünschten Aktionen mit den Exchange Commandlets umgesetzt hat. Natürlich hat der Code die Voraussetzungen geprüft und Protokolle geschrieben. So ist mir in einem Fehlerprotokoll aufgefallen, dass mit ein Objekt vorgegeben wurde, welches "unstimmig" war. Meine Skripte trauen nämlich niemandem und prüfen jede Eingabe. Ein "Get-Recipient" liefert mir aber folgende Ausgabe:
Der erfahrene Exchange Admin wird sofort, sehen, dass diese Kombination nicht möglich ist. Ein "MailUser" ist aus Exchange Sicht ein Kontakt und kann keine "RecipientTypedetails=UserMailbox" sein. Eine genauere Untersuchung des Objekts hat gezeigt, dass es tatsächlich kein lokales Postfach hatte, sondern schon lange zu Exchange Online migriert wurde. Der RecipientTypeDetails hätte also ein "RemoteUserMailbox" sein müssen. Das die vorgefundene Konfiguration nicht passen konnte, lieferte auch der Versuch diese Objekte gezielt zu finden. Ich wollte ja sicher sein, ob es nur eines ist.
Get-Recipient ` -RecipientTypeDetails UserMailbox ` -RecipientType MailUser None of the specified RecipientTypeDetails are included in any specified recipient type.
Die direkte Abfrage nach diesen Empfänger hat auch bemerkt, dass dies nicht gültig sein kann.
Auflistung der Kombinationen
Ich habe mir dann erst einmal einen Überblick verschafft, indem ich alle Empfänger geladen, die beiden Felder RecipientType und RecipientTypeDetails verbunden und gruppiert ausgegeben habe.
Get-Recipient -ResultSize unlimited `
| foreach-object {"$($_.RecipientType)+$($_.RecipientTypeDetails)"} `
| group -NoElement `
| ft -autosize
Count Name
----- ----
1245 MailContact+MailContact
976 UserMailbox+UserMailbox
523 MailUser+MailUser
19530 MailUser+RemoteUserMailbox
11 MailUser+UserMailbox
1 UserMailbox+DiscoveryMailbox
4021 MailUser+RemoteSharedMailbox
11380 MailUniversalSecurityGroup
1 MailUniversalDistributionGroup
816 MailUniversalDistributionGroup
454 UserMailbox+SharedMailbox
359 UserMailbox+RoomMailbox
220 MailUser+RemoteRoomMailBox
8 MailUser+SharedMailbox
155 MailUser+RemoteEquipment
29 UserMailbox+EquipmentMailbox
Das sind nicht alle möglichen Kombinationen aber der erfahrene Administrator sieht zwei Einträge, die nicht erlaubt sind:
11 MailUser+UserMailbox
8 MailUser+SharedMailbox
Diese Kombination ist nicht möglich, denn ein MailUser ist entweder ein MailUser bei den Details oder eben eine RemoteUserMailBox, RemoteSharedMailbox o.ä. Damit weiß ich zwar immer noch nicht, wer dafür verantwortlich ist aber ich habe eine weitere Unstimmigkeit gefunden.
Auswertung
Wenn Sie sich die verschiedenen Varianten auf msExchRecipientTypeDetails anschauen, dann finden Sie die Inhalte der AD/LDAP-Felder "msExchRecipientTypeDetails" und "msExchRecipientDisplayType". Zudem gibt es noch das Feld msExchRemoteRecipientType, welches wir dann auch noch unter einen Hut bringen müssten. Eine vollständige Liste aller möglichen Kombinationen habe auch ich nicht. Aber wir können eine Auswertung mit anderen Feldern machen, und basierend darauf ein paar Prüfungen ableiten, z.B.
- Mailnickname
Nach meinem Wissen haben generell alle Exchange Empfängerobjekte auch immer einen eindeutigen Wert in "Mailnickname". Daher kann z.B. geprüft werden, ob das Feld im Forest eindeutig ist und nur Objekte mit einem MailNickname sind für Exchange überhaupt relevant und haben weitere Inhalte in den Exchange Feldern
Das bedeutet im Umkehrschluss auch, dass ein Objekt ohne MailNickname eigentlich auch keinen msExchRecipientTypeDetails oder msExchRemoteRecipientType hat. Wie so wohl bestätigen aber Ausnahmen die Regel
if mailnickname = null and
HomeMDB <> Null
or msexchangerecipienttype <> Null
or msexchangerecipientdisplaytype <> Null
or ProxyAddresses <> Null
then -> Unvollständig deprovisioniertes Object
- Mailbox hat HomeMDB
Alle Objekte, die lokal ein Postfach haben, haben zwingend auch einen Wert in "HomeMDB" und wer einen HomeMDB hat, kann keine RemoteMailbox sein
if HomeMDB and
msExchRecipientTypeDetails > 0x80000000
or msExchRecipientDisplayType <0 (Remote sind <0)
then -> OnPrem User ist als remoteRecipient konfiguriert
- TargetAddress
Eine RemoteMailbox in Exchange Online MUSS eine TargetAddress in die Cloud haben. Achtung: Kontakte haben auch dieses Feld, obwohl sie jeder einen HomeMDB noch eine RemoteMailbox-Konfiguration haben. Die TargetAddress muss auch in den ProxyAddresses erscheinen und zumindest bei einer RemoteMailbox muss diese Domain auch als "RemoteDomain" mit "TargetDeliveryDomain=$True" geführt sein.
if msExchRecipientTypeDetails > 0x80000000 or msExchRecipientDisplayType <0 (Remote sind <0) and TargetAddress = "" then -> Missing.....
Je länger und häufiger sie "Troubleshooting" in Umgebungen machen, desto mehr Fehler lernen sie im Laufe der Zeit kennen. Die Ursache ist dabei zumindest nachträglich nicht immer einfach zu ermitteln. Auhc die Exchange Commandlets von Microsoft sind nicht fehlerfrei oder haben unerwartete Seiteneffekte
Heilung
Eine pauschale Aussage zur Korrektur defekter Elemente kann es nicht geben. Dazu ist jeder Fall getrennt zu betrachten. Manchmal reicht es mit "Update-Recipient" einfach der Exchange PowerShell die Aufgabe zu überlassen, eine Unstimmigkeit zu entfernen. Bei den kniffligen Fällen, insbesondere wenn Sie von der Exchange Powershell gar nicht als defekt erkannt werden, bleibt dann nur noch die Handarbeit.
