Zertifikatsmeldung und nicht möglich Autodiscoverzuweisung neuer Exchange SE Server

Michi777

Commander
Registriert
Apr. 2009
Beiträge
2.228
Liebe Community!

Wir haben 3 redundante Exchange Server 2019 (virtuell auf 3 Standorten/HyperV Hosts) und sie können den Gesamtbetrieb jeweils aufrechterhalten sollte Einer ausfallen, welche nun von 3 neuen Exchange SE Servern ersetzt werden sollen, die erstmal migriert werden und dann Postfächer dorthin migriert werden.

Aktueller Stand: Exchange Installation fertiggestellt auf ersten Exchange SE Server.
Exchangerolle wurde erfolgreich installiert und alle Voraussetzungen (Nutzer ist Schema - und Schlüssedaministrator und AD Standort hinzugefügt), sodass es erst in die Installation gehen konnte.
Danach scheint er schon automatisch unter den Exchange Servern auf (als 4.Server) und hat keinerlei Postfächer oder weiter Konfiguration noch bekommen.

Jedoch erscheint Zertifikatsmeldung bei allen auf (normalerweise autodiscover auswahl einer der 3 verfügbaren Exchange Server).
Hier jedoch direkt Zertifikatsmeldung mit Nennenung des neuen Exchangeservers.
Mit PowerShell Befehl um ihn dem Autodiscover hinzuzufügen (dann greifen ja erst DNS Prioritätseinstellung beim Domänenhost) kommt folgender Fehler (per PowerShell sowie Admin Center versucht):

Fehlermeldung:
Eine Instanz der COM-Komponente mit der CLSID {XXXXXX} konnte aufgrund des folgenden Fehlers nicht von der IClassFactory erstellt werden: 800706ba Der RPC-Server ist nicht verfügbar. (Ausnahme von HRESULT: 0x800706BA).

Habt ihr da eine Lösung parat?
Ansätze von MS FAQ werden noch durchgegangen aber wird aufwändig:
https://learn.microsoft.com/de-de/t...e-pki/error-0x800706ba-certificate-enrollment

Vielen Dank im Voraus!
 
Das Problem dürfte eher die Extented Protection sein. Wie sind die entsprechenden Pfade konfiguriert für die Virtuellen Verzeichnisse?
 
@Mojo1987
Ohne dass ich da viel Vorwissen hab oder es konfiguriert zu haben (Virtuelle Verzeichnisse) die Infos die ich dazu nennen kann:

Autodiscover (Default Website) von bestehendem aktiven Exchange Server:
Authentifizierung: Einfach, NTLM, Windows ‎(integriert)‎, Windows SharePoint-Sicherheit, OAuth
Integrierte Windows Authentifizierung + Standardauthentifizierung = angehakt.
Digestauthentifizierung für Windows-Domänenserver = abgehakt

Autodiscover (Default Website) von neuem Exchange SE Server (automatisch erstellt)
Reiter Allgemein lässt sich öffnen, wenn ich auf Reiter Authentifizierung klicke kommt der genannte Fehler bzgl. RPC-Server nicht verfügbar.
Kommt ebenso bei anderen Virtuellen Verzeichniseinträgen zum neuen Exchange SE Server wie z.B. ecp (Default Website)
 
Bist du sicher das die Installation korrekt durchgelaufen ist?
 
@Mojo1987
Ja verlief erfolgreich, hier Screenshots zu relevanten Installationseinstellungen und Fertigestellungsmeldung.
Anzumerken auch dass wir eine große Enterprise IT mit strengen Regeln (oftmals Minimalprinzip) haben.
Jedoch durch vergangenen Erfahrungen, Dokus und Checklisten das Wissen dazu und alles möglichst korrekt und in Hinblick auf aktive Referenz Exchangeserver keine Fehler entdeckt.

Die Server (bestehend und produktiv im Einsatz d.h. sollen ersetzt werden):
Version 15.2 (Build 1748.10)
Der Exchange SE ist mit Version 15.2 (Build 2562.17) drinnen.

Fragen:
Kann es sein dass nun durch neue Versionierungen (Exchange Patches, Exchange SE sowie Windows Server 2025) neue Sicherheitsvorkehrungen gibt wo man etwas freischalten müsste?
....Extended Protection per PowerShell am IIS Server und Exchange SE Server deaktivieren bis alles läuft?

Danke
 

Anhänge

  • Installation fertiggestellt.jpg
    Installation fertiggestellt.jpg
    62,5 KB · Aufrufe: 44
  • Setup Details 2.jpg
    Setup Details 2.jpg
    22,9 KB · Aufrufe: 39
  • Setup Details.jpg
    Setup Details.jpg
    17,8 KB · Aufrufe: 39
Habt ihr denn beim neuen Server schon die virtual Directories und das Zertifikat im IIS angepasst, dass alles aufeinander stimmen sollte?

Michi777 schrieb:
....Extended Protection per PowerShell am IIS Server und Exchange SE Server deaktivieren bis alles läuft?
Eher das Gegenteil, erstmal prüfen ob auf den Exchange 2019 EP aktiv ist (sollte es sein, außer ihr habt es bei der Installation des letzten CU explizit unterdrückt) und falls nicht aktivieren
 
Ohne die genaue Umgebung, Pfade etc zu kennen ist es schwierig dir einen richtigen Tipp zu geben.

Generell ist es so, das die EP eben am meisten Probleme macht wenn die Pfade in der Umgebung nicht gleich sind oder sich interner / externer Pfad unterscheidet je Server oder oder oder.

Es gibt natürlich Voraussetzungen was die Exchange Installation angeht, die ggf. vom Installer nicht abgehandelt werden.

Was sagt der HealthChecker?
Laufen alle Dienste auf dem neuen Server, möglichweise werden die von eurer IT/Endpoint Security geblockt (das Problem hatte ich beim InPlace Upgrade z.B.)

Warum habt ihr eigentlich nicht mit InPlace Upgrades gearbeitet?
 
warum macht ihr keine "upgrades" die von Exchange 2019 auf SE unterstützt sind und problemlos funktionieren?
 
@Mojo1987
Ich denke es gibt Probleme mit der Kommunikation zum IIS.
Wir haben bereits den zweiten neuen virtuellen Exchangeserver aufgesetzt und als einzigen Unterschied, kein Rollen zuvor per PowerShell Befehl zu installieren, sondern es über das Exchange Setup (fehlende Rollen automatisch installieren) und dort stimmen die Pfade/Postfachrolle/Zertifizierungen:

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS, Server-Media-Foundation

In den virtuellen Verzeichnissen sieht es im Direktvergleich zu den Produktiven wie folgt aus:
Autodiscover (Default Web Site):

IIS://ExchangeServerNameNeu/W3SVC/1/ROOT/Autodiscover wurde nicht gefunden

ecp (Default Web Site):
Interner URL: identisch
Externer URL: fehlt und wenn ich hinzufüge kommt Fehler:
Der Verzeichniseintrag für die Internetinformationsdienste (IIS) kann nicht erstellt werden. Fehlermeldung: Das System kann den angegebenen Pfad nicht finden. . HResult = -2147024893

EWS (Default Web Site):
Eigener Servername anstatt korrekter Link mit webmail... drinnen, wenn ich korrekten eingeben will (Kopieren von aktiven Exchange Server) kommt Fehler "Das System kann den angegebenen Pfad nicht finden".

MAP (Default Web Site):
Eigener Servername anstatt korrekter Link mit webmail... drinnen, wenn ich korrekten eingeben will (Kopieren von aktiven Exchange Server) kommt Fehler "Es kann nciht festgestellt werden, welche ISS Verison ausgeführt wird...."

Jetzt müsste man den fehlerhaften wieder mühsam entfernen aus AD Struktur und HyperV Prüfpunkt (vor Exchange Installation nehmen) oder es gäbe einen Lösungsansatz.

@nubi80
In Place Upgrade wäre auch meine erste und deutlich komfortablere Wahl gewesen, jedoch wäre das Risiko bei einem Fehlschlagen höher und die redundante Struktur (3 produktive Server im Verbund) wäre dann auch nicht mehr funktionstüchtig, bei neuen Server hat der Chef den Vorteil der neuen Windows Server 2025 Version (End of Life deutlich später) und weiterhin bestehende unangetastete Produktivstruktur bis Postfächer verschoben werden.
 
Zurück
Oben