Exchange Install Site

Irgendwie machen wir alles das gleiche und laufen auch in die gleichen Probleme. Nachdem mir in einer Woche dreimal die Frage gestellt wurden, wie man die Zertifikatswarnungen in Outlook unterdrücken kann, die bei einer Neuinstallation eines Exchange CAS-Service erscheinen können, möchte ich auf dieser Seite die Zusammenhänge und Gegenmaßnahmen beschreiben.

Autodiscover und SCP

Die Problematik sollte eigentlich jedem Exchange Administrator nach dem Studium von Autodiscover bekannt sein. Outlook nutzt die Funktion Autodiscover um einen Exchange Server für seine Mail-Domäne zu suchen und nach erfolgreicher Anmeldung per HTTPS eine XML-Struktur mit den Zugangsdaten zu erhalten. Dabei gibt es zwei Arten von Clients zu unterscheiden:

  • Outlook Clients auf einem PC im Active Directory
    Diese Clients starten ihre Autodiscover-Anfrage zuerst mit einer LDAP-Suche auf einen bestimmten "Service Connection Point., Siehe dazu auch "Autodiscover und SCP"
  • Andere Clients ohne LDAP-Unterstützung
    Darunter fallen primäre Tablets und Smartphones aber auch Applikationen wie der Lync/Skype for Business Client und natürlich alle PCs, die nicht Mitglied im Active Directory sind

Die zweite Gruppe Clients kann einfach nur die SMTP-Domäne des Anwender nehmen und dann nach "autodiscover.<smtpdomain>" gehen um die Konfiguration zu ermitteln. Wenn Sie für diesen Fall im internen und externen DNS den Namen per Loadbalancer, Reverse Proxy oder DNS-Eintrag auf Server verweisen lassen, die ein korrektes Zertifikat vorweisen können, dann bekommen die Anwender auch keine Fehler.

Warnungen durch die Installation eines neuen Exchange Servers mit CAS-Rolle bekommen nur die ersten Clients. Durch die Installation eines neuen Exchange Server wird mit der Installation der CAS-Funktion im Active Directory auch ein Service Connection Point (SCP) mit dem FQDN des Servers addiert. Damit ist es nur eine Frage der Zeit, wann Client der ersten Gruppe bei eine Suche nach einem Autodiscover-Punkt auch diesen neuen Namen finden und nutzen. Wenn dann der nagelneue Server seinen IIS mit dem per Default ausgestellten "selbstsignierten Zertifikat" gestartet hat, können sich Clients verbinden, prüfen das Zertifikat und beschweren sich zurecht über ein nicht vertrauenswürdiges Zertifikate. Nach meinem Kenntnisstand ist Outlook der einzige Client, der überhaupt einen LDAP-Query auf einen Service Connection Point macht.

Abhilfe per AD-Site

Outlook stellt aber nicht eine plumpe generische Anfrage, sondern orientiert sich schon an den AD-Standorten, sofern diese im Active Directory gepflegt sind. Die Exchange Server pflegen nämlich an ihrem AD-Objekte sehr wohl die AD-Standorte, für die sich sich zuständig fühlen und so kann ein Outlook zuerst seinen eigenen Standort ermitteln und dann gezielt die Exchange CAS-Rollen finden, die "nahe" sind. Erst wenn diese nicht erreichbar sind, dann sucht Outlook etwas weiter.

Dies ist dann auch der Hebel, über den Microsoft gerne das Dilemma lösen möchte. Neue Exchange Server werden nicht einfach in die normale AD-Site installiert, sondern im Active Directory wird z.B.: die IP-Adresse des neuen Exchange Servers einer eigenen Site zugewiesen. Damit ignorieren ihn die Clients und der Exchange Administrator hat etwas mehr zeit die Installation und nachfolgende Konfiguration abzuschließen. Danach kann er den Server in die richtige Site umziehen indem er entweder eine neue passende IP-Adresse verwendet oder die bestehende IP-Adresse in den "AD Sites and Services" eben wieder umdefiniert wird.

Alternativen

Auf dem Papier funktioniert eine eigene AD-Site für die Installation neuer Server auch recht gut aber nicht jeder Exchange Administrator hat die Rechte eine AD-Seite anzulegen und zu pflegen. Zudem müsste man genau genommen ja noch einen DC in diese Site installieren, damit Exchange auch diesen "lokalen" DC nutzt. Ohne "lokalen" DC schlägt zumindest jedes Schema-Update fehlt, da das Setup dies nur mit einem lokalen DC durchführt.

Wer also auf so eine Thematik keine Lust hat, sucht nach Alternativen. Diese gibt es tatsächlich auch mit den verschiedenen Einschränkungen, z.B.

  • Schnelle Konfiguration (Augen zu und durch)
    Kaum dass der Server noch am Installieren ist kann man von einem anderen Server per Powershell ja schon die Konfiguration z.B. auf die zentrale URL ändern, die auf einen Loadbalancer verweist.
Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://Autodiscover/Autodiscover.xml
  • Zugriff der Clients unterbinden
    Statt mit einer AD-Site könnten Sie natürlich auch über Netzwerkfilter  (Firewall/Routing/Subnetz) verhindern, dass der unfertige Exchange Server von Clients erreicht wird. Das kann aber auch Effekte für die Kommunikation zwischen Servern haben
  • Gültiges Zertifikat vorbereiten
    Wenn eh schon klar ist, wie der Server heißt und auch die späteren virtuellen Namen bekannt sind, dann könnte man schon ein „vorbereitetes Zertifikat“ auf dem Server ablegen. Exchange installiert zwar wohl immer auch ein eigenes Zertifikat, aber er sollte das von einer PKI ausgestellte Zertifikat dem eigenen Zertifikat vorziehen.
  • Außerhalb der Betriebszeit/Wartungsphase
    Einfach können Sie es sich machen, indem Sie die Zeit einfach als „Wartungsfenster“ beantragen und dann eben schnell zuschauen, dass in der Zeit die Konfiguration korrekt abgeschlossen wird.

Es gibt also durchaus Alternativen einen neuen Exchange CAS-Server zu installieren und die Warn- und Fehlermeldungen beim Client zu minimieren. Gerade bei kleineren Installationen ist es vollkommen ausreichend, wenn die "Störzeit" sich auf wenige Minuten beschränken lässt.

Weitere Links