roccomarcy

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.

Moin, es ist noch Exchange 2010 mit dem letzten Update. Der soll ja nun ersetzt werden. Nochmal zur o.g. Anfrage, das kann ich ja theoretisch in einer arbeitsarmen Zeit ausführen? Die Anwender sollten davon ja idR nichts mitbekommen?

Hallo, danke für die Antwort - sollte natürlich auch für alle Verzeichnisse gelten, ich wollte die eine Befehlszeile allerdings nur exemplarisch zur Darstellung herausziehen. Den folgenden Haken wirklich entfernen ... ? Oder setzen?

Hallo, die Installation von einem neuen Exchange steht an. Jedoch möchte ich vorher noch Split-DNS einführen, da aus der Vergangenheit heraus das Thema versäumt wurde. Aktuell ist der Exchange-Server mit der internen URL auf servername.domäne.tld konfiguriert statt auf mail.firma.de. Die externe URL ist allerdings bereits schon korrekt auf mail.firma.de konfiguriert. Meine Herangehensweise wäre nun, dass ich folgende Tätigkeiten durchführe. Im DNS zwei Zonen für mail.firma.de und autodiscover.firma.de konfigurieren. Den Exchange-Server mit dem gültigen Zertifikat versorgen. Via PowerShell-Skript (Danke an FrankysWeb) die Adressen anpassen, Ausschnitt: [ ... ] Get-OwaVirtualDirectory -Server <Servername> | Set-OwaVirtualDirectory -InternalUrl 'https://mail.firma.de/owa' -ExternalUrl 'https://mail.firma.de/owa' [ ... ] Ist die o.g. Herangehensweise in Ordnung oder habe ich einen Punkt vergessen? Outlook sollte das ja (eigentlich?) nicht interessieren und sich die neue Adresse für die Verbindung ziehen, oder? Kann ich im IIS/Exchange irgendwo konfigurieren, dass der http-Zugriff automatisch auf https umgeleitet wird? Nach aktuellem Stand wurde z.B. OWA auch über mail.firma.de aufgerufen und dort hat die Umleitung der Reverse-Proxy übernommen. Gruß

Alles klar, vielen Dank. Dann werde ich es nach o.g. Liste durchführen. Für die Installation liegt das aktuellste Medium (CU22) schon bereit.

Hallo, ich bin mir nicht mehr sicher, ob ich beim letzten Mal das Schema-Update für die Installation von Exchange 2016 vor der eigentlichen Installation durchgeführt habe, oder ob dies das Setup selbstständig ausgeführt hat. Sei es drum - aktuelle Situation ist ein Exchange 2010 inkl. allen Updates und mehreren verteilten Domänen-Controllern. Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms Setup.exe /PrepareAD /OrganizationName:"ExchangeOrganisationName" /IAcceptExchangeServerLicenseTerms Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms Ich würde das Schema-Update für Exchange 2016 dann manuell vorher einspielen und die Replikation abwarten, bevor ich die Installation starte - das wäre vom Vorgehen soweit korrekt, oder? Das Domänen- sowie Gesamtstrukturlevel ist aktuell auch auf 2008 R2 konfiguriert, dies würde ich gerne vor der Installation von Exchange 2016 auf 2012 R2 anheben. Es sind nur DC mit Server 2012 R2 und Server 2016 im Einsat. Einzig Exchange 2010 läuft noch auf Server 2008 R2, sollte aber davon nicht betroffen sein? Funktionslevel der Domäne anheben Replikation abwarten Schema-Update für Exchange durchführen Replikation abwarten Exchange installieren + konfigurieren Migration Gibt es eurerseits Einwände?

Schlug auch alles fehl. Hab jetzt via ADSIEdit + DNS den Exchange entfernt. Danke trotzdem.

Okay, dann teste ich erstmal CLI. Du sagtest ja, der deinstalliert dann nur auf dem Exchange wo es ausgeführt wird und der zweite bleibt unangetastet? Gibt es für ADSIEdit irgendwo ein Manual?

Über die Systemsteuerung kommt o.g. Fehler. Es ist Exchange 2010 SP3 mit dem aktuellsten CU (also 32 aus März).

Lässt sich auch nicht aufrufen. :) Also bedenkenlos über die CLI mit setup.com /Mode:Uninstall ausführen?