Exchange: Kein Drag & Drop in Outlook – Ursache und Lösung

Nach einer Migration von Exchange 2010 auf Exchange 2013, die mit dem DELL Migration Manager for Exchange durchgeführt wurde, haben sich Nutzer beschwert, dass sie in Outlook keine Elemente per Drag & Drop in einen bestimmten Unterordner des Posteingangs und dessen Unterordner verschieben können. Da dieser Ordner der e-Mail-Archivierung im Unternehmen diente, betraf es alle Nutzer und war auch beliebig reproduzierbar. Eine weitere Untersuchung ergab, dass:

  • auch keine neuen Elemente in diesen Ordnern erstellt werden können,
  • das Verschieben per Rechtsklick –> Verschieben nach… funktioniert
  • in OWA auch Drag & Drop funktioniert
  • nur diese archivierungsbezogenen Ordner betroffen sind
  • es keine Unterschiede in den Zugriffsrechten zwischen funktionierenden und nicht funktionierenden Ordnern gibt.

Der Blick auf die MAPI-Properties der Ordner per MFCMAPI ergab folgendes Bild, das auch schnell zur Lösung führte:

  • in Exchange 2010 fehlt in den betroffenen Ordner die Property PR_CONTAINER_CLASS komplett
  • in Exchange 2013 haben die „defekten“ Ordner zwar diese Property, sie ist aber leer
  • in beiden Systemen haben die Default-Ordner und solche, die von Hand angelegt wurden (und wo Drag & Drop ausnahmslos funktioniert) die Property auf den korrekten Wert „IPF.Note“ gesetzt.

Der Versuch, manuell den Wert für PR_CONTAINER_CLASS auf IPF.Note in einem der „defekten“ Ordner zu setzen, brachte sofort die Linderung für den betreffenden Ordner. Da 1.200 Postfächer betroffen waren und die Unterordner-Strukturen überall unterschiedlich waren, habe ich das folgende Skript geschrieben, das die Angelegenheit global heilt:

Damit dieser Code ausgeführt werden kann, benötigt das ausführende User-Account mindestens das Recht, alle Postfächer aufzulisten und deren SAMAccountName und PrimarySMTPAddress zu lesen (also: Mitgliedschaft in irgendeiner Exchange-Administratorrolle) sowie die ApplicationImpersonation-Berechtigung. Da alle Postfächer zu bearbeiten waren, war das Zuweisen dieser Berechtigung denkbar einfach:

Noch ein wenig Hinergrund: Die Unterordner im Quellsystem wurden mit einem Skript angelegt, welches EWS Managed API 2.0 und ebenfalls ApplicationImpersonation nutzt. Dabei wurde denkbar einfach vorgegangen:

Die FolderClass-Eigenschaft wurde nicht explizit gesetzt. Offensichtlich erstellt dabei EWS Managed API auch keine Property PR_CONTAINER_CLASS. DELL Migrator hingegen erstellt diese Property offenbar standardmäßig, bestückt sie jedoch strikt mit dem Wert, den sie im Quellsystem hatte. In diesem Fall also: mit keinem.

Happy troubleshooting!

Ersten Kommentar schreiben

Antworten

Deine E-Mail-Adresse wird nicht veröffentlicht.


*


Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.