Bitschubser

Ja, wie geht es weiter. Ich schrieb ja weiter zuvor das nach dem Update der vcredist Packages für VC 2012+2013 und einem anschliessenden Neustart gar nichts mehr ging. Das Problem lag am fehlenden Zertifikat für das Backend. Im IIS habe ich das noch existierende dem Port 444 zugewiesen so das ich zumindest auf das ecp Backend kam. Ich bin dann noch in verschiedene Fettnäpfchen getreten, unter anderem das ich via Gui ein Zertifikat habe neu erstellen lassen was dann aber nicht in der Liste aufgetaucht ist. Über die Exchange Shell dann noch mal erstellen lassen und dann wurde es angezeigt. Etwas Wartezeit und Geduld muß man wohl auch an manchen Stellen mitbringen, das hatte ja auch Norbert geschrieben das man warten müsse. Als ich dann endlich Zugriff auf die Einstellungen für ecp hatte konnte ich das existierende Geotrust Zertifikat wieder ausser SMTP den anderen Protokollen zuweisen. So habe ich nun wieder einen funktionierenden Outlook Zugriff. Sorry das ich Eure Fragen ggf. nicht immer korrekt beantworten konnte, mir fehlen ganz viele Grundlagen. Ich kann mich zwar in vieles reinversetzen aber es ist b***d wenn man keine Ansatzpunkte hatte. Insofern erstmal vielen Dank für Eure Hilfe! Das Geotrust Zertifikat läuft noch bis April. Ich überlege wie ich meine emails lagern kann ohne eine Exchange zu haben und ohne eine riesige PST Datei die kaputt gehen könnte. Ideen willkommen

Die ungültigen habe ich alle ohne Warnungen gelöscht. Die Warnungen im ecp sind nun auch weg. Ich arbeite mich jetzt mal durch den Health Checker durch wie weiter oben vorgeschlagen. Aktuell update ich 2 x vcredist und mache einen Neustart. Ich poste wenn ich wieder hängen bleibe. Aktuell geht das Desktop Outlook 2019 leider noch nicht wieder. Ich vermute vor den Updates die zum Systemversagen geführt haben hat sich das Outlook 2019 das Geotrust Zertifikat geholt und fand das akzeptabel. Aber das scheint derzeit nicht der Fall zu sein. Hat da jemand noch eine Idee? Nach dem Installieren der vcredist wie vom Healthchecker angemeckert geht jetzt gerade nix mehr. Ich komme zwar auf die Exchange Management Shell drauf aber er verbindet sich nicht mehr mit dem Exchange Server.

Bei ecp sieht das mit den Warnungen so aus: Klickt man auf Details anzeigen, dann erscheint die Liste mit den jeweils ungültigen Einträgen. Das hat vor dem Update alles funktioniert. Ich vermute aber das das interne Zertifikat trotzdem hätte erneuert werden müssen. Fehlermeldungen habe ich jedenfalls nie bekommen. Ich gebe zu wenn etwas läuft dann verliert man sowas irgendwann auch mal aus den Augen. Also das selbst erzeugte Zertifikat "Microsoft Echange Server Auth Certificate -20260128120531" ist auf der Management Shell vom Exchange Server erstellt worden. Für externe Kommunikation hat letztes Jahr ein externer Admin das GeoTrust Zertifikat installiert.

Du meinst den owa Zugriff?

Ja genau so ist das mit Outlook 2019: Ich kann nur vermuten das Outlook sich das interne selbst erstellte Zertifikat vom Ex16 nimmt und dem nicht vertraut.

Gelöscht habe ich noch nichts. Outlook 2019 startet nicht und präsentiert mir auch leider damit kein Zertifikat. Outlook Webzugriff (owa) funktioniert mittlerweile, ecp kann ich auch drauf zugreifen mit 3 Warnungen. Unter Details bei ecp findet sich folgende Auflistung:

Hallo Norbert, ja, das Exchange 2016 quasi tot ist weiß ich. Ich hatte bereits eine Lizenz Exchange Server 2019 beschafft mit entsprechenden Lizenzen aber der Niedergang meiner Branche hat sämtliche Bemühungen in Updates in diese Richtung gekillt. Im Prinzip bin ich mittlerweile nur noch Einzelkämpfer und hatte vor im März nach einer Alternative zu suchen. Aus Datenschutzgründen kommt für mich kein Microsoft 365 oder sowas in Frage. Aber für nur PST Datei ist das mit 50GB problematisch... Ich habe bisher noch keine gute Lösung gefunden, da ist mir das Problem hier gerade auf die Füsse gefallen :-( Zum Thema IIS: Exchange IIS Information ------------------------ Name State HSTS Enabled Protocol - Bindings - Certificate ---- ----- ------------ --------------------------------- Default Web Site Started False http - *:80: - NULL http - 127.0.0.1:80: - NULL https - *:443: - B96CC109734CE046B585D4B18B1A64326FE32773 https - 127.0.0.1:443: - B96CC109734CE046B585D4B18B1A64326FE32773 Exchange Back End Started False http - *:81: - NULL https - *:444: - 2B99CBF3AF49BAFB875C675832A3AFC4573E9952 Certificate Binding Issue Detected: '2B99CBF3AF49BAFB875C675832A3AFC4573E9952' Has expired and will cause problems. Das Certificate Binding Issue meint wohl dieses hier: Certificate: FriendlyName: Microsoft Exchange Thumbprint: 2B99CBF3AF49BAFB875C675832A3AFC4573E9952 Lifetime in days: -128 Certificate has expired: True Certificate status: DateInvalid Key size: 2048 ECC Certificate: False Signature Algorithm: sha1RSA Signature Hash Algorithm: sha1 It's recommended to use a hash algorithm from the SHA-2 family More information: https://aka.ms/HC-SSLBP Bound to services: IMAP, POP, IIS Internal Transport Certificate: False Current Auth Certificate: False Next Auth Certificate: False SAN Certificate: True Namespaces: EX16 EX16.corp.<lokale_domain>.de Es gäbe IMHO dazu passend das neu erstellte Zertifikat hier: Certificate: FriendlyName: Exchange Default TLS Thumbprint: B96CC109734CE046B585D4B18B1A64326FE32773 Lifetime in days: 1825 Certificate has expired: False Certificate status: Valid Key size: 2048 ECC Certificate: False Signature Algorithm: sha256RSA Signature Hash Algorithm: sha256 Bound to services: IMAP, POP, IIS, SMTP Internal Transport Certificate: True Current Auth Certificate: False Next Auth Certificate: False SAN Certificate: True Namespaces: EX16 EX16.corp.<lokale_domain>.de Aus dem Bauch heraus hätte ich nun geraten das ich das eine zuweisen muss und dann das andere lösche. Aber wie macht man das richtig wenn es der nächste Schritt ist?

Guten Morgen @NorbertFe und @Nobbyaushb, get-exchangecertificate liefert: Thumbprint Services Subject ---------- -------- ------- 8BC2AC74D4815B8D1BBBD4D22921B430FFFE8200 ....S.. CN=Microsoft Exchange Server Auth Certificate B96CC109734CE046B585E4B18B1A64326FE32773 IP.WS.. CN=EX16 9D54FBE4F1C878AF3BEB9D2EBC1B69D7BBEF85A4 ....S.. CN=<meinedomain>.de FAF85AF8E6121598B4DFC4D5E726CE2BD46500B6 ....S.. CN=<meinedomain>.de 6A3565F23F3091BFFB4DA623BE0C311AF71B31C9 ....... CN=SpamAssassinInABoxService 4862008248B92BA8BEB2E66A63FC0F309B9516A1 ....... CN=ExchangeServerToolboxArchiveSearchService 4A55A374E44B9963BFC6FEF73A2CE5650001AE9C ....... CN=ExchangeServerToolboxDistributedInstallationService 2B99CBF3AF49BAFB875C775832A3AFC4573E9952 IP.W... CN=EX16 FEA656B213C7485D986A220874B14C315CC24E34 ....... CN=WMSvc-SHA2-EX16 D2C4B450C605275EFCECBDBFA9211C9A49D43B55 ....S.. CN=Microsoft Exchange Server Auth Certificate Der Exchange läuft als VM unter Proxmox, es sind 4 Prozessoren und 24 GB RAM zugewiesen. Der Exchange 2016 hat CU 23 und Update 19 installiert, meines Wissens nach der letzte verfügbare Stand. Der Health Checker zeigt für die virtuelle Hardware: Processor/Hardware Information ------------------------------ Type: Physical Manufacturer: QEMU Model: Standard PC (i440FX + PIIX, 1996) Processor: Intel(R) Xeon(R) Gold 6134 CPU @ 3.20GHz Current Total Processor Usage: 1.56 Number of Processors: 2 Number of Physical Cores: 4 Number of Logical Cores: 4 Hyper-Threading: Disabled All Processor Cores Visible: Passed Max Processor Speed: 3192 Physical Memory: 24 GB Kann ich die Thumbprints der Zertifikate hier posten oder ist das ein Sicherheitsrisiko und ich sollte die lieber ändern?

So, jetzt ist morgen. Mir wird wieder was angezeigt aber ein Zugriff mit Outlook ist nicht möglich: Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor. Das Sicherheitszertifikat stammt nicht von einer vertrauenswürdigen Zertifizierungsstelle. Von Outlook kann keine Verbindung mit dem Proxyserver 'mail.<hiermeinedomain>.de' hergestellt werden (Fehlercode: 18). Über Browser auf ecp leider auch nicht. Im lokalen Zertifikatspeicher sind jetzt zwei neue Zertifikate vorhanden die ich gestern mit dem obigen Vorgehen erzeugt habe. Aber die alten (abgelaufenen) Zertifikate sind auch noch vorhanden. Muss ich die löschen damit die neuen Zertifikate benutzt werden? Auch mein Zertifikat vom letzten Jahr von Geotrust was lange abgelaufen ist ist noch vorhanden. Ich habe heute morgen den HealthChecker in Version 25.12.15.1344 laufen lassen und dort etliche rote Einträge gefunden. Ich würde aber ungerne alles hier posten ohne das es Sinn macht. Vielleicht hat jemand von Euch Ideen wie ich weitermachen kann?

Hallo zusammen, Ich habe meinen Windows Server 2016 aktualisiert mit - 2026-01 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5073722) - 2026-01 Servicing Stack Update für Windows Server 2016 für x64-basierte Systeme (KB5073447) danach neu gestartet. Und dann habe ich den Tag lang bis heute zwar noch neue email empfangen können aber ich konnte nichts mehr senden. Der Befehl "Get-ExchangeCertificate" blieb leer. ein früherer Thread hier im Forum hatte eine ähnliche Problembeschreibung. Test-ServiceHealth habe ich also ausgeführt: Role : Postfachserverrolle RequiredServicesRunning : True ServicesRunning : {IISAdmin, MSExchangeADTopology, MSExchangeDelivery, MSExchangeIS, MSExchangeMailboxAssistants, MSExchangeRepl, MSExchangeRPC, MSExchangeServiceHost, MSExchangeSubmission, MSExchangeThrottling, MSExchangeTransportLogSearch, W3Svc, WinRM} ServicesNotRunning : {} Role : Clientzugriffs-Serverrolle RequiredServicesRunning : True ServicesRunning : {IISAdmin, MSExchangeADTopology, MSExchangeMailboxReplication, MSExchangeRPC, MSExchangeServiceHost, W3Svc, WinRM} ServicesNotRunning : {} Role : Unified Messaging-Serverrolle RequiredServicesRunning : True ServicesRunning : {IISAdmin, MSExchangeADTopology, MSExchangeServiceHost, MSExchangeUM, W3Svc, WinRM} ServicesNotRunning : {} Role : Hub-Transport-Serverrolle RequiredServicesRunning : True ServicesRunning : {IISAdmin, MSExchangeADTopology, MSExchangeEdgeSync, MSExchangeServiceHost, MSExchangeTransport, MSExchangeTransportLogSearch, W3Svc, WinRM} ServicesNotRunning : {} MonitorExchangeAuthCertificate.ps1 habe ich das aktuellste Script heruntergeladen und laufen gelassen: Monitor Exchange Auth Certificate script version 25.10.14.1658 The script was run without parameter therefore, only a check of the Auth Certificate configuration is performed and no change will be made Current Auth Certificate thumbprint: D2C4B450C605275EFCECBCBFA9211C9A49D43B55 Current Auth Certificate is valid for -321 day(s) Test result: The Auth Certificate in use must be replaced by a new one. Daraufhin habe ich das Skript erneut aufgerufen: .\MonitorExchangeAuthCertificate.ps1 -ValidateAndRenewAuthCertificate $true Monitor Exchange Auth Certificate script version 25.10.14.1658 Mode: Testing and replacing or importing the Auth Certificate (if required) Renewal scenario: The Auth Certificate in use must be replaced by a new one. Unattended Exchange certificate generation The following actions will be performed without the need to reconfirm: - The internal transport certificate will be queried - A new certificate will be generated, it overrides the internal transport certificate - The internal transport certificate will be set back to the previous one or - A new internal transport certificate will be generated if the previous one is invalid [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "J"): j Bestätigung Möchten Sie diese Aktion wirklich ausführen? Ausführen des Vorgangs "Generate new Auth Certificate" für das Ziel "New-ExchangeCertificate". [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "J"): j Bestätigung Möchten Sie diese Aktion wirklich ausführen? Ausführen des Vorgangs "Enable-ExchangeCertificate" für das Ziel "Certificate: B96CC109734CE046B585D4B18B1A64326FE32773 on: EX16 for: IIS, SMTP". [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "J"): j Bestätigung Möchten Sie diese Aktion wirklich ausführen? Ausführen des Vorgangs "Set-AuthConfig" für das Ziel "Certificate: 8BC2AC74D4815B8D1BBBC4D22921B430FFFE8200 Date: immediately". [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "J"): j Bestätigung Möchten Sie diese Aktion wirklich ausführen? Ausführen des Vorgangs "Set-AuthConfig" für das Ziel "PublishCertificate". [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "J"): j Bestätigung Möchten Sie diese Aktion wirklich ausführen? Ausführen des Vorgangs "Set-AuthConfig" für das Ziel "ClearPreviousCertificate". [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "J"): j Bestätigung Möchten Sie diese Aktion wirklich ausführen? Ausführen des Vorgangs "Restart-WebAppPool" für das Ziel "EX16". [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "J"): j The renewal action was successfully performed Log file written to: C:\Program Files\Microsoft\Exchange Server\V15\Logging\AuthCertificateMonitoring\AuthCertificateMonitoringLog_20260128000529.txt Ich hatte gehofft das nun alles wieder geht und optimistisch ``Get-ExchangeCertificate | Format-List`` ausgeführt aber das bleibt leer im Ergebnis. Via mmc.exe -> Zertifikate -> lokaler Computer -> eigene Zertifikate habe ich geschaut, dort sind Zertifikate vorhanden. Also scheint der Exchange die Zertifikate einfach nicht zu finden. Ein Versuch über ecp Webzugriff zu arbeiten funktioniert nicht. Ich bekomme schnell die Anzeige das Zertifikate abgelaufen sind. So bin ich etwas ratlos und fühle mich wie der Ochs vorm Berg. Hat jemand eine Idee wo ich weitermachen kann?