roccomarcy

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?

Guten Morgen, ich wollte am Wochenende den zweiten Exchange - Server deinstallieren, leider lässt die GUI dies aus dem folgenden Fehler nicht zu: Ich habe beim Googlen den folgenden Befehl gefunden: setup.com /Mode:Uninstall. Meine Frage nun, Dieser deinstalliert hoffentlich ja nur den Exchange auf dem Server, wo der Befehl ausgeführt wird, oder? Die anderen bleiben erhalten? Sorry für die Nachfrage.

Hallo, ich habe hier einen zweiten Exchange-Server, der nicht mehr benötigt wird. Die Postfächer wurden alle deaktiviert. Kann ich diesen jetzt einfach deinstallieren ohne das der erste Exchange, der weiterhin benötigt wird, in Mitleidenschaft gezogen wird? Sollte ich vorher noch etwas prüfen? Die Connectoren habe ich entfernt, die Datenbanken ausgehängt und Adressbücher liegen auf dem Server auch nicht mehr. Kann ich die Deinstallation tagsüber durchführen oder lieber in einer arbeitsarmen Zeit? Gruß

Ah, okay. Dann bedeutet es ja etwas mehr Aufwand. Adressrichtlinie löschen bzw. anpassen und die E-Mailadressen auf den beteiligten Konten entfernen lassen. Akzeptierte Domäne löschen

Ja, natürlich. Allerdings muss ich auf dem Exchange doch die akzeptierte Domäne anpassen, sonst bleiben die E-Mails, die Anwender aus dem Client heraus erstellen, auf dem alten Exchange vorhanden bzw. werden auf den alten Postfächern zugestellt und nicht auf den neuen Exchange. Oder reicht es sogar nicht einfach aus, die akzeptierte Domäne komplett zu löschen? Nur was mache ich dann mit den Benutzern, auf denen die E-Mailadresse der o.g. Domäne TestB.de noch hinterlegt ist?