nach Migration: zusätzlich in Outlook eingebundene Postfächer können nicht geöffnet werden

[Jack Bauer 10]

Hallo,

 

wir haben ein Problem beim Zugriff auf zusätzlich in Outlook 2010 eingebundene Postfächer. Sie erscheinen links im Menü (per Autodiscover oder auch manuell), doch es erscheint die Meldung "Der Ordner kann nicht erweitert werden. Ein Clientvorgang ist fehlgeschlagen." wenn man einen aufklappen möchte.

Die Benutzer- und Gruppen-Konten sowie deren Postfächer wurde von Exchange 2010 auf 2016 cross-forest migriert. Konten mit ADMT inkl. SIDhistory und Passwörtern, Postfächer mit einem Drittanbieter-Tool.

Die Vollzugriff-Berechtigungen sind korrekt gesetzt, zur Konfiguration wurden wahlweise das Exchange Admin Center oder PowerShell genutzt. Ein Zugriff auf die Gruppen-Postfächer per OWA ist möglich, so dass kein Zweifel an der Berechtigungskonfiguration der Postfächer besteht.

Leider lässt sich dies nicht hundertprozentig reproduzieren. Der weitaus größte Teil der Postfächer lässt sich nicht öffnen. Uns aufgefallen ist allerdings, wir wissen dies aber nicht zu deuten, dass es eine Abhängigkeit zur Authentifizierung an Outlook zu geben scheint. Die meisten User werden bei einer Neuanlage eines Outlookprofils nicht zur Passworteingabe aufgefordert. Der Zugriff auf das persönliche Postfach funktioniert dann, doch aus weitere nicht. Bei wenigen Usern wird bei jedem Outlookstart ein Passwort abgefragt. Dann ist auch der Zugriff auf weitere Postfächer möglich.

 

Ich freue mich auf Hinweise, die uns der Lösung etwas näher bringen. Vielen Dank!

 

 Jack

[Sunny61 806]

Habt ihr schon, für ausgesuchte Testuser, dem betroffenen User ein neues Outlook- bzw. Benutzerprofil in Windows verpasst? Wenn Vollzugriff auf ein Postfach besteht, ist ein PW nicht erforderlich. Ebenfalls ist ein PW für das Postfach des jeweiligen Users erforderlich.

[Jack Bauer 10]

Outlookprofile wurden bereits mehrfach bei unterschiedlichen Usern erneuert, danach immer gleiches Verhalten wie vorher. Windowsprofile sind wir noch noch angegangen, machen wir sofort morgen früh!

Was meinst du genau mit deinem letzten Satz? Ist eine Passworteingabe bei der Erstverbindung zum persönlichen Postfach erforderlich? Und wenn ja: Wie kann ich das erzwingen, wenn‘s jetzt ohne geht?

[Sunny61 806]

vor 1 Stunde schrieb Jack Bauer:

Was meinst du genau mit deinem letzten Satz? Ist eine Passworteingabe bei der Erstverbindung zum persönlichen Postfach erforderlich? Und wenn ja: Wie kann ich das erzwingen, wenn‘s jetzt ohne geht?

Der User authentifiziert sich ja schon bei der Anmeldung, daher braucht es kein PW wenn Outlook startet und zum Postfach auf den Exchange verbindet.

[Jack Bauer 10]

Neue Windowsprofile lösen das Problem leider nicht. 

[Sunny61 806]

Dann wird es von der Ferne aus sehr schwer. Rechtsklick mit gedrückter STRG-Taste, *während* das Fenster für die PW-Abfrage noch da ist, auf das Outlook Symbol in der Infoleiste, EMail Autokonfiguration und Verbindungsstatus anschauen.

 

EDIT: Gibt es einen Proxy? Firewall? Autodiscover mittels XML oder SPN gesetzt?

bearbeitet 4. Oktober 2019 von Sunny61

[Jack Bauer 10]

Hallo Sunny, es gibt keinen Proxy. Die Firewall zwischen den Netzen ist auf Durchzug konfiguriert, hier gibt es keine Blocks im Log. Für das Autodiscover haben wir eine Forward-Lookupzone (autodiscover.domain.de) erstellt, welche einen Host-Eintrag mit der IP des neuen Exchange enthält. Zertifikate sollten hier auch passen.

Den Outlook-Verbindungsstatus habe ich mal überflogen, muss ich aber noch etwas Zeit reinstecken, melde das Resultat dann zurück.

Bei der Authentifizierungsproblematik konnte ich folgendes feststellen: User mit ausschließlich persönlichen Postfächern benötigen keine Authentifizierung, läuft. (Wie du beschrieben hast.) User mit zusätzlich eingebundenen ebenfalls migrierten Postfächern haben dort keinen Zugriff drauf und werden auch nicht zur Authentifizierung aufgefordert. User mit Berechtigungen auf zusätzliche Postfächer, die bereits auf dem Zielsystem vorhanden waren, bekommen diese automatisch hinzugefügt und werden beim Öffnen zur Eingabe von Benutzername/Kennwort aufgefordert. Danach ist ein Zugriff möglich - aber dann auch auf die migrierten zusätzlichen Postfächer, die "solo" nicht zur Authentifizierung aufforderten.

Soweit der Zwischenstand - ich hoffe das produziert Geistesblitze...  :)

[Sunny61 806]

vor einer Stunde schrieb Jack Bauer:

User mit zusätzlich eingebundenen ebenfalls migrierten Postfächern haben dort keinen Zugriff drauf und werden auch nicht zur Authentifizierung aufgefordert.

Und die User sind via ECP oder PS auf dem Postfach mit Vollzugriff eingetragen? Als User oder als Gruppe? Falls letzteres, mach mal als User direkt. Zuerst rausnehmen, speichern und dann wieder hinzufügen.

 

Gibt es in der 'alten' Domain die User noch? Melden sich die User auch richtig an?

[Jack Bauer 10]

Für die Berechtigungsvergabe wurde ECP und PS getestet. Rechte hängen mit großer Mehrheit an Usern, nicht an Gruppen.

Die alte Domäne ist noch in Verwendung. Es besteht eine bidirektionale und transitive Vertrauensstellung zwischen a.de und b.de. Migriert wie initial beschrieben wurden die User (als Kopien mit SIDhistory) von c.b.de nach a.de. Dann die Postfächer rüber auf den neuen Exchange. Das AD-Attribut ‚Mail‘ der Quell-User (in c.b.de) wurde an das Zielsystem angeglichen, so dass Autodiscover funktioniert. Diese User aus der Quell-Domäne sind weiter in Verwendung. Geht auch aufgrund von zahlreichen Abhängigkeiten vorerst nicht anders. Also: username.c.b.de meldet sich mit seinen Windows-Anmeldedaten (an c.b.de) an, verbindet sich in Outlook aber mit mailserver.a.de.

bearbeitet 4. Oktober 2019 von Jack Bauer

[Jack Bauer 10]

Nachtrag: Das Problem steht definitiv in Zusammenhang mit der SIDhistory. Wird diese manuell aus den Userkonten entfernt, dann funktioniert alles tadellos. Eine Lösung für den umfassenden Postfachzugriff bei gleichzeitiger SIDhistory-Nutzung habe ich leider nicht.

[NorbertFe 2.035]

Liest sich etwa wie das hier:

http://ezoltan.blogspot.com/2015/07/sidhistory-and-exchange-resource-forests.html?m=1