roccomarcy

Allerdings ploppt noch immer eine Meldung von Outlook hoch, wo der ehemalig interne Hostname angemeckert wird mit dem neuen Zertifikat. Wird sich das die Stunden automatisch bereinigen? @Norbert, du hast den letzten Denkanstoß gegeben. Ich brech zusammen. Es gab tatsächlich einen Benutzer, für den EwsEnabled auf $false konfiguriert war. Und das war genau meiner. Jetzt habe ich den Wert genullt und kann OOF und freigegebene Kalender beitreten. Sehe im Fiddler nun auch einen 401 und direkt danach ein 200, wenn auf /EWS/Exchange.asmx zugegriffen wird. Holy Sh*t. Sorry Leute für das gespame der letzten Tage.

Ich hab das jetzt nochmal explizit mit zwei anderen Benutzern ausprobiert, dort tritt das Verhalten, so wie es an meinem Benutzer auftritt, nicht auf. O_o Wenn das mit meinem Konto zu tun hat, dann muss es ja explizit an dem Benutzerkonto liegen, weil das Phänomen tritt auf zwei unterschiedlichen Systemen auf.

Nee, ein CAS-Array haben wir nicht ...

Achso, also hinfällig. Sind 6 Stück. Aber der eine EX ist für alle Standorte zuständig.

Moin, ich hab mir die Konfiguration noch einmal angeschaut und diverse Dinge ausprobiert - leider weiterhin ohne Erfolg. Aufgefallen ist mir allerdings nur, dass der SCP für einen anderen Standort hinterlegt ist, wo gar kein Exchange Server installiert ist. Ist das für mein Problem irrelevant oder liegt hier ggf. der Hund begraben? Der Exchange hat mit dem StandortWuppertal nichts zu tun.

Cross-Post im TechNet. https://social.technet.microsoft.com/Forums/de-DE/d62c1fa5-1d2a-4f28-bb98-b2125166a275/fehler-401403-kein-abwesenheitsassistent?forum=exchange_serverde

Schon probiert, leider auch ohne Erfolg. :| Das ist echt verrückt. Hab jetzt nochmal zurückgesetzt auf die alte Konfiguration, also mit den unterschiedlichen URLs intern und extern. Da gibt es keine 401/403 Fehler auf das /EWS-Verzeichnis.

So, ich hab mal mit Fiddler geschaut. Also Autodiscover-Mäßig konnte ich nichts ungewöhnliches feststellen. Allerdings scheint er Probleme beim Aufruf von EWS zu haben. Da versucht er ständig aufzurufen (dreimal) und klatscht dann 2x mit einem 401 an die Wand und zum Schluss mit einem 403. Ein Konfigfehler im vDir?

Ohjo, das hattest du ja geschrieben und ich schön überlesen. :) Wenn ich die Adresse mit deinem bzw. meinem Befehl anpasse, dann sollte dort ja auch zeitnah die neue Adresse (entweder autodiscover..... oder mail...) drin stehen, oder? Gibt es noch irgendwo Ansätze wo ich schauen könnte?

Alles klar, nächster Anlauf heute Abend mit Fiddler. Habe ich bereits vorbereitet, hoffentlich werde ich daraus schlauer. Andere Frage nochmal, kann das Verhalten evtl. auch über das Timing kommen? Ich hatte die umgestellten URLs, usw. ja nur für 15 - 25 Minuten aktiv und dann wieder zurückgeschaltet. Oder spielt das einfach keine Rolle? Intern gibt es für die anderen Domänen ja keinen http-redirect und auch keine Rekords im DNS. Sollte ich das ggf. noch korrigieren? Also könnte das auch zu dem o.g. Problem führen?

Überlegt habe ich es schon, habe allerdings dazu recherchiert und öfters Beiträge gefunden, dass dann noch mehr kaputt gegangen ist. :-D Weiß aber nicht inwiefern das noch aktuell ist mit aktuellem CU vom Exchange 2010 und Outlook 2016. Intern haben wir kaum bis gar keine OWA-Anwender, sodass mir das bis zur Migration eigtl. egal wäre.

Hi, ja - ich kann OWA im Client aufrufen. Bekomme auch keinen richtigen Zertifikatsfehler, außer das die Browser nun meckern wg. TLS 1.0 vom Server 2008 R2. :| Und ja, das neue Zertifikat hab ich an alle Dienste gebunden.

Achso, ja das kann ich beim nächsten Anlauf heute Abend nochmal testen. Ansonsten fällt mir aktuell auch nichts spannendes mehr ein, wie ich dem Problem auf die schliche kommen könnte. Oder ob das mit meinem Benutzerkonto bzw. der E-Mailadresse zu tun hat. Autodiscover hab ich ja nur auf autodiscover.firma.de konfiguriert aber meine primäre SMTP-Adresse ist firma2.de. Dafür gibt es intern ja nirgends einen Eintrag für AD.

Ok, dann wäre das nochmal ein Ansatz. Andere Frage, Damit ich das aber richtig verstehe, an folgender Konstellation ist erstmal nichts verkehrt. Ich habe auf dem internen DNS-Server die Zonen für mail.firma.de und autodiscover.firma.de angelegt, die zeigen auf auf den Exchange. Extern habe ich beim Hoster natürlich auch die Records setzen lassen und zusätzlich für autodiscover.anderefirma.de. Die zeigen alle auf den Reverse-Proxy, welche auf den Exchange weiterleiten und für die autodiscover.*-Adressen ein Redirect machen. Das ist aber soweit korrekt? //Edit, 22:40 Uhr: Also ich habe es eben noch einmal ausprobiert und die .xml-Dateien aus dem Profil entfernt. Leider keine Besserung. Die Fehlermeldung kommt weiterhin und auch Kalender/OOF geht nicht. :|

Wird der Autodiscover-Cache nicht automatisch gelöscht, wenn ich ein neues Profil anlege? Die Spielereien via lokaler XML-Datei möchte ich eigentlich umgehen um sauber in die Migration zu gehen. :| Ach, was ich noch schreiben wollte. Ich hatte das Problem auch in Outlook WebApp, wenn ich dort einen freigegebenen Kalender öffnen wollte. Da passierte einfach nichts. Er teilte die Kalenderansicht, so wie man es kennt und wollte den zweiten Kalender einblenden, dieser blieb aber weiß - also da kam nichts. Ok, das scheint ein Firefox-Ding zu sein. Ging nach dem Rückstellen auf die Ursprungskonfiguration auch nicht. Mit Edge probiert und war sofort verfügbar. Also bitte nicht beachten.

Ja, IISReset habe ich schon durchgeführt. Siehe mein Einwand von oben. In der config? Du meinst bei den Befehlen? Habe ich schon einmal alle neugeschrieben und abgefeuert. :|

Ja, Ja, ich weiß. Der muss ja jetzt auch langsam mal weg. :) Keine Sorge. Hu? Den ecp habe ich doch auf mail.firma.de setzen lassen? Oder habe ich was überlesen? Get-EcpVirtualDirectory -Server exch | Set-EcpVirtualDirectory -InternalUrl 'https://mail.firma.de/ecp' Ja, leider auch bei einem neuen Profil. Teste hier mit zwei Maschinen und bei beiden kam der Fehler, auch nach neuem Profil. Leider. :|

Habe ich auch durchgeführt, ist in meiner Befehlsfolge hinterlegt. Get-OwaVirtualDirectory -Server exch | Set-OwaVirtualDirectory -InternalUrl 'https://mail.firma.de/owa' Get-EcpVirtualDirectory -Server exch | Set-EcpVirtualDirectory -InternalUrl 'https://mail.firma.de/ecp' Get-OABVirtualDirectory -Server exch | Set-OABVirtualDirectory -InternalURL 'https://mail.firma.de/OAB' Get-ActiveSyncVirtualDirectory -Server exch | Set-ActiveSyncVirtualDirectory -InternalURL 'https://mail.firma.de/Microsoft-Server-ActiveSync' Get-WEbServicesVirtualDirectory -Server exch | Set-WEbServicesVirtualDirectory -InternalURL 'https://mail.firma.de/EWS/Exchange.asmx' Get-ClientAccessServer -Identity exch | Set-ClientAccessServer -AutodiscoverServiceInternalUri 'https://autodiscover.firma.de/autodiscover/autodiscover.xml' Get-OutlookAnywhere -Server exch | Set-OutlookAnywhere -ExternalHostname mail.firma.de Get-WEbServicesVirtualDirectory -Server exch | Set-WEbServicesVirtualDirectory -InternalURL 'https://mail.firma.de/EWS/Exchange.asmx' -InternalNLBBypassUrl 'https://mail.firma.de/EWS/Exchange.asmx' Enable-ExchangeCertificate -Thumbprint Abcd1234 -Service IIS, IMAP, SMTP, POP Die externen URLs habe ich nicht angefasst, die standen ja bereits auf der korrekten Adresse. Nee, das Verzeichnis hab ich ja (noch) nicht. :)

Ich denke nicht, habe mich zwischendurch auch fix schlaugelesen. Wie oben schon geschrieben, war nur etwas verwirrt, weil es auf der Seite unseres Anbieters für die Zertifikate so positioniert wurde. cj_berlin hat es ja auch noch einmal aufgegriffen. :) Okay, den http-redirect könnte ich ja von außen lösen. Habe vor dem Exchange einen Reverse-Proxy, der das abfackeln könnte. Aber für die internen Anfragen? Bekomme beim Starten von Outlook auch noch eine Zertifikatsfehlermeldung. Hinter dem geschwärzten steht der interne FQDN des Exchange-Servers. Das Zertifikat ist allerdings für die neue Adresse. Habe mir dann via den folgenden Befehlen noch einmal alle URLs ausgeben lassen, aber das passt soweit. Es steht eigtl. überall nur noch die externe Adresse drin (mail.firma.de) und unter ClientAccessServer ist die autodiscover.firma.de-Adresse konfiguriert. Get-OwaVirtualDirectory -Server exch | fl *url* Get-EcpVirtualDirectory -Server exch | fl *url* Get-OABVirtualDirectory -Server exch | fl *url* Get-ActiveSyncVirtualDirectory -Server exch | fl *url* Get-WEbServicesVirtualDirectory -Server exch | fl *url* Get-ClientAccessServer -Identity exch | fl autodiscover* Get-OutlookAnywhere -Server exch | fl *hostname IIS hatte ich auch neugestartet. Habe dort durch Zufall noch gefunden, dass in der Default Web Site eine HTTP-Umleitung auf https://mail.firma.de/owa/ hinterlegt war. Die habe ich auch entfernt. Dennoch keine Besserung, o.g. Fehlermeldung kommt weiterhin - könnte damit auch leben bis zur Migration, allerdings bleibt die Funktion vom Abwesenheitsassistenten und der Anzeige von freigegebenen Kalendern unverändert. Wie Norbert schon meinte, scheint irgendwas am Autodiscover zu klemmen. Das Cmdlet Test-OutlookWebServices habe ich auch einmal durchlaufen lassen, bis auf folgender Eintrag war alles erfolgreich. Inhaltlich gleich wie die o.g. Fehlermeldung unter Outlook. Gibt es noch einen Punkt wo ich mehr Logs generieren oder was ich überprüfen könnte? Habe jetzt erstmal die alte Konfiguration wiederhergestellt, das geht ja dank PowerShell recht zügig und die Funktion ist nicht eingeschränkt.

Gibt es einen Unterschied? Ich bin nur die Seite des Anbieters für unsere Zertifikate überflogen und da wurde zwischen Multidomain und SAN-Zertifikaten unterschieden. Habe mir aber das Zertifikat noch einmal angeschaut, dort wird unter Alternativer Antragsstellername beide Adressen (mail. und autodiscover.) aufgelistet. //Edit: Brauche ich in dem Zertifikat eigtl. alle Namen der Domänen, die verarbeitet werden? Wir haben ca. 10 unterschiedliche E-Maildomänen, die den einzelnen Anwendern als primäre SMTP-Adresse zugeordnet ist.

Intern nicht, nein. Nur von außen, der Reverse-Proxy. Mir ist aber grad glaube ein dummer Fehler aufgefallen, wobei ich nicht weiß, ob der damit zu tun hat. Ich glaube, dass das Zertifikat ein Multidomain und kein SAN-Zertifikat ist.

Hmmm, laut Outlook aber 'erfolgreich'?

Ah Okay, Mist. :) Habe jetzt die URLs und das Zertifikat getauscht. Scheint auch E-Mailtechnisch soweit zu laufen, allerdings kann ich keine freigegebenen Kalender mehr aufrufen und Abwesenheitsnotizen hinterlegen. Allerdings sind die korrekten URLs unter dem Punkt WebServicesVirtualDirectory konfiguriert.

Hu, muss im Zertifikat auch der alte Servername, also servername.domäne.tld auftauchen? Ich hab jetzt nur eins mit mail.firma.de inkl. autodiscover.firma.de und wollte die Adresse als externe und interne URL angeben.

Ja, genau. Ich meine die Anpassung der URLs und Einrichtung von Split-DNS. Ob der Anwender die Änderung spürt oder ob es ohne große Einwirkung auf den Anwender übernommen wird.