Fragensteller
Exchange 2010 - Outlook 2010 - Verbindungsprobleme

Frage
-
Hi,
wir haben ein größeres AD mit 14 Domains in einem Forest mit drei Trees.
In einer Domain sind die Exchange 2010 Server installiert. 2x CAS im Array und 2x MB. (SP3 Rollup 2)(14.3, Build 123.4)
Alle Domains sind für Exchange erweitert (/PrepareDomain).
Seit kurzem erst haben manche Benutzer Probleme im Outlook, wenn sie auf freigegebene Kalender zugreifen. Diese freigegebenen Kalender befinden sich in Mailboxen von Benutzern der selben Domain, wie die des betroffenen Benutzers, sowie im selben Mailbox Store.
Das Problem äußert sich so, dass bei den zusätzlich geöffneten Kalendern oben neben dem Namen "keine Verbindung" steht. Im Kalender wird dann kein Inhalt dargestellt. Es tritt vollkommen unsystematisch auf. Wenn mehrere Kalender geöffnet sind, dann sind mal alle und mal nur ein paar und mal nur einer davon betroffen. Auch welche betroffen sind ist jedes mal verschieden. Es macht auch keinen Unterschied, ob es ein Raum-, Geräte- oder Benutzer-Postfach ist. Es kommt auch vor, dass ein Kalender erst einwandfrei angezeigt wird, doch sobald man im Monat navigiert kommt "keine Verbindung". Geht man zurück zum Datum, bei dem eben noch alles ok war, dann ist die Verbindung wieder da.
Der betroffene Benutzer hat dieses Problem an verschiedenen Computern mit verschiedenen Benutzerprofilen. Auch unabhängig davon, ob im Cache-Mode oder nicht. Damit kann ich die Outlook-Installation und das Benutzerprofil schon mal ausschließen. Anwendungsdaten sind nicht zentralisiert sondern standardmäßig im Profil.
Andere Benutzer am selben Computer, für welche auch dieselben GPO's gelten und greifen, haben nicht dieses Problem.
Ich habe schon rauf und runter gegoogelt, finde aber leider nichts. Wahrscheinlich suche ich falsch.
Weiteres Symptom:
Ruft der Benutzer die URL "https://casarray.domain.local/ews/Services.wsdl" im IE auf, dann kommt eine (bunte) XML-Seite. Geht er direkt über die URL's der beiden CAS, also z.B. "https://ex01.domain.local/ews/Services.wsdl" und "https://ex02.domain.local/ews/Services.wsdl", dann kommt ne Fehlerseite à la
"Die Webseite wurde nicht gefunden. (HTTP 400)"
Die Websites auf den CAS sind nicht an spezielle IP's gebunden. Damit sind die Websites über alle IP's des Servers erreichbar. Das beweist sich dadurch, dass ein anderer Benutzer auf demselben Computer alle drei oben genannten URL's aufrufen kann und jedes mal diese XML-Seite bekommt.
Ich denke, Ihr folgt mir, wenn ich davon ausgehe, dass es an den Berechtigungen der Benutzer liegen muss, wenn ein Benutzer kann und ein anderer nicht.
Jedoch finde ich nichts, wo ich die Benutzer in diesem Punkt unterschiedlich berechtigt habe könnte. Ich habe auch schon die Virtual Directories "EWS" auf beiden CAS auf Default zurückgesetzt, wobei diese gelöscht und neu erstellt wurden. Es ändert leider nichts.
So, jetzt muss ich noch erwähnen, dass alle Benutzer dieser Domain vor kurzem in eine andere, neue Domain (im selben Forest aber anderem Tree) mittels ADMT migriert wurden. Seit dem haben wir o.g. Problem. Es wäre jetzt aber leider zu einfach, zu sagen, dass das allein die Ursache ist und dabei was schief gelaufen sein muss. Denn es sind ja nicht alle Benutzer dieser Domain betroffen, und dabei wurden doch ausnahmslos alle migriert. Die meisten können problemlos mit Outlook arbeiten, wie bisher. Nur einige nicht (ca. 15 %)
Und bevor ich jetzt anfange zu heulen, ...
hat jemand von Euch ein Idee?
Emeriks
Alle Antworten
-
Überprüfe mal die Einträge im CASArray. Evtl. sind da alte oder fehlende Informationen.
- Bearbeitet Stefan Völker Dienstag, 1. Oktober 2013 19:38
-
Hi Emeriks,
was für Clients kommen genau zum Einsatz und läuft die Verbindung über RPC/TCP oder RPC/HTTP?
Gibt es Fehler im ServerEventLog und hast du mal ds Diagnoselogging erhöht?
Auch das OutlookLog könntest du mal aktivieren:
http://support.microsoft.com/kb/300479/de
Grüße
-
So, habe jetzt mal Outlook loggen lassen.
Log aktiviert. Outlook neu gestartet.
Sofort die Kalender aufgerufen. Hin und her navigiert. Fehler trat wieder auf.
Log deaktiviert. Outlook neu gestartet.Ein Log sieht dann z.B. so aus:
2013/10/02 13:30:48.093: Getting ASURL
2013/10/02 13:30:48.093: URL returned from cached autodiscover: https://dom-ex05.domain.local/EWS/Exchange.asmx
2013/10/02 13:30:48.093: Request to URL: https://dom-ex05.domain.local/EWS/Exchange.asmx
2013/10/02 13:30:48.093: Request action: http://schemas.microsoft.com/exchange/services/2006/messages/GetUserAvailability
2013/10/02 13:30:48.093: Request XML: <?xml version="1.0"?>
<q:Envelope xmlns:q="http://schemas.xmlsoap.org/soap/envelope/"><q:Header><wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing/">urn:uuid:EA8ECB24-6E60-4E8F-B20A-63AFC558BCF2</wsa:MessageID></q:Header><q:Body xmlns:wsa="http://www.w3.org/2005/08/addressing/"><ex12m:GetUserAvailabilityRequest xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types"><ex12t:TimeZone><ex12t:Bias>-60</ex12t:Bias><ex12t:StandardTime><ex12t:Bias>0</ex12t:Bias><ex12t:Time>03:00:00</ex12t:Time><ex12t:DayOrder>5</ex12t:DayOrder><ex12t:Month>10</ex12t:Month><ex12t:DayOfWeek>Sunday</ex12t:DayOfWeek></ex12t:StandardTime><ex12t:DaylightTime><ex12t:Bias>-60</ex12t:Bias><ex12t:Time>02:00:00</ex12t:Time><ex12t:DayOrder>5</ex12t:DayOrder><ex12t:Month>3</ex12t:Month><ex12t:DayOfWeek>Sunday</ex12t:DayOfWeek></ex12t:DaylightTime></ex12t:TimeZone><ex12m:MailboxDataArray><ex12t:MailboxData><ex12t:Email><ex12t:Address>name1@sub1.domain.de</ex12t:Address><ex12t:RoutingType>SMTP</ex12t:RoutingType></ex12t:Email><ex12t:AttendeeType>Required</ex12t:AttendeeType></ex12t:MailboxData><ex12t:MailboxData><ex12t:Email><ex12t:Address>name2@sub1.domain.de</ex12t:Address><ex12t:RoutingType>SMTP</ex12t:RoutingType></ex12t:Email><ex12t:AttendeeType>Required</ex12t:AttendeeType></ex12t:MailboxData></ex12m:MailboxDataArray><ex12t:FreeBusyViewOptions><ex12t:TimeWindow><ex12t:StartTime>2013-09-22T22:00:00</ex12t:StartTime><ex12t:EndTime>2013-10-22T22:00:00</ex12t:EndTime></ex12t:TimeWindow><ex12t:MergedFreeBusyIntervalInMinutes>30</ex12t:MergedFreeBusyIntervalInMinutes><ex12t:RequestedView>Detailed</ex12t:RequestedView></ex12t:FreeBusyViewOptions></ex12m:GetUserAvailabilityRequest></q:Body></q:Envelope>
2013/10/02 13:30:48.093: Sending request
2013/10/02 13:30:48.139: Request sent
2013/10/02 13:30:48.140: Response error code: 80004005
2013/10/02 13:30:48.140: HTTP status code: 400
2013/10/02 13:30:48.140: -------------------------------
2013/10/02 13:30:48.140: There is an error in request/response.
2013/10/02 13:30:48.140: XML response:
2013/10/02 13:30:48.140: -------------------------------
2013/10/02 13:30:48.140: Getting ASURL
2013/10/02 13:30:48.503: Failed to get ASURL. Error 8004010FBei anderen betroffenen Benutzern analog.
-
Hallo Emeriks,
hast Du in der Zwischenzeit die Ursache des Problems vielleicht gefunden?
Gruss,
Alex
Alex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können. -
Hallo Leute,
Wir (selbe Firma wie Emeriks) konnten leider bis zum heutigen Tage keinen Fehler direkt ausmachen und ein Call bei Microsoft ist ebenfalls erfolglos verlaufen. Der Fehler muss mit aller Wahrscheinlichkeit am AD-Benutzerkonto liegen, da selbst ein neues Postfach bei einem betroffenen Anwender keine Abhilfe schaffte. Insofern aber ein neues AD-Konto das Postfach vom betroffenen Anwender zugewiesen bekam, war alles wieder in Butter. So kam auch nicht mehr der Fehler in den Kalender von wegen "keine Verbindung" oder das der Abwesenheitsassistent sich nicht starten lies bzw. beim "E-Mail AutoKonfigurationstest" nichts stand.
Der Vorschlag von MS das Postfach vom betroffenen Anwender in eine andere DB zu verschieben war auch nicht die Lösung (Fehler bestand weiter), ganz davon abgesehen auf den ganzen Kalendern die betroffenen Anwender mit Prüferrechten zu versehen.
Selbst der Aufruf vom "E-Mail AutoKonfigurationstest" in Outlook lief ins leere und zeigte nichts an, ganz zu schweigen vom Aufruf der oben genannten Webseiten (https:....../EWS/Exchange.asmx) die einen Zugriffsfehler aufwiesen.
Unser Workaround ist jetzt, einen neuen AD-Benutzer für den Anwender anzulegen und das Postfach auf diesen zu übertragen (Postfach deaktivieren, Getrenntes Postfach verbinden mit dem neuen Konto). Es ist zwar aufwändig die ganzen anderen Daten zu übertragen, aber bei den Anwender kommt langsam auch Unmut auf weil es zu keine Lösung bisher kam. Zum Glück sind es nur ein paar Anwender und der Aufwand überschaubar.
-
Nachtrag:
Das erstellen neuer Benutzer war doch nicht die Lösung, hat uns aber auf die richtige Spur gebracht. Nachdem ein neuer Benutzer mit den Standard Gruppenmitgliedschaften versehen wurde, konnte Er ganz normal auf die Exchange Webseiten https:....../EWS/Exchange.asmx (bzw. IIS) zugreifen. Sobald aber dem Benutzer die identischen Gruppen zugeordnet wurden wie es beim Hauptbenutzer (mit den Outlook Fehler) hinterlegt ist, kamen die selben Fehler. Dies veranlasste uns die Gruppen näher zu betrachten und vielleicht eine korrupte Gruppe zu finden die den Fehler verursachte. Bei dieser intensiven Suche wurde uns so langsam der Fehler bewusst, den Wir die ganze Zeit aufgelaufen sind.
è Das Token vom Benutzer war für den Exchange Server (IIS) zu groß
Dadurch das Wir die User sowie Gruppen in die neue Domäne migriert haben und hier die SIDHistory (vor allem bei den Gruppen) einen großen Anteil an der Größe des Tokens zusteuerte, war dieses beim Exchange der Auslöser für den Fehler. Viele Gruppen wurden auf Grund der Migration vorab auf Universell geändert und nachdem Wir diesen wieder in Ihren ursprünglichen Typ änderten war das Token schon wieder unter dem Limit vom Exchange und der Fehler war weg. Die Bereinigung der SIDHistory ist der nächste Schritt.
- Als Antwort vorgeschlagen Lexxitus Mittwoch, 11. Dezember 2013 11:27