Exchange Server: OWA und EAC starten nicht nach Installation der Juli Updates

Nach der Installation der Juli Sicherheitsupdates kann es passieren, dass das Exchange Administrative Center (EAC) und OWA nicht mehr geöffnet werden können. Die Ursache ist ein abgelaufenes Zertifikat für die Exchange Server OAuth Authentifizierung. Auch Microsoft weißt auf dieses Problem in den Release Notes der Updates hin. Leider überliest man die Hinweise zu den Updates ja manchmal, oder installiert die Updates beispielsweise mit WSUS, sodass die bekannten Probleme der Updates meist nicht mit bekommt. Daher an dieser Stelle mal ein kleiner Artikel wie das Problem behoben werden kann.

OWA und EAC starten nicht nach Installation der Juli Updates

Ursache des Fehlers ist das abgelaufene Zertifikat mit dem Namen „Microsoft Exchange Server Auth Certificate“:

OWA und EAC starten nicht nach Installation der Juli Updates

In der Ereignisanzeige des Exchange Servers wird der folgende Fehler protokolliert:

Exchange EventID 1003
  • Ereignis-ID: 1003
  • Quelle: MSExchange Front End HTTPS Proxy
  • Meldung:

[Owa] An internal server error occurred. The unhandled exception was: Microsoft.Exchange.Diagnostics.ExAssertException: ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1 bei Microsoft.Exchange.Diagnostics.ExAssert.AssertInternal(String formatString, Object[] parameters) bei Microsoft.Exchange.Diagnostics.ExAssert.RetailAssert[T1,T2](Boolean condition, String formatString, T1 parameter1, T2 parameter2) bei Microsoft.Exchange.Clients.Common.HmacProvider.GetCertificates() bei Microsoft.Exchange.Clients.Common.HmacProvider.GetHmacProvider() bei Microsoft.Exchange.Clients.Common.HmacProvider.ComputeHmac(Byte[][] messageArrays) bei Microsoft.Exchange.HttpProxy.FbaModule.SetCadataCookies(HttpApplication httpApplication) bei Microsoft.Exchange.HttpProxy.FbaFormPostProxyRequestHandler.HandleFbaFormPost(BackEndServer backEndServer) bei Microsoft.Exchange.HttpProxy.FbaFormPostProxyRequestHandler.ShouldContinueProxy() bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.BeginProxyRequestOrRecalculate() bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalOnCalculateTargetBackEndCompleted(TargetCalculationCallbackBeacon beacon) bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass280_0.b__0()
bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func 2 filterDelegate, Action 1 catchDelegate)

Mit dem folgenden Script lässt sich das Problem beheben:

Das Script muss in einer Exchange Shell mit administrativen Rechten (Elevated) ausgeführt werden. Das Script startet die IIS AppPools neu, dies sorgt zwar für keine Unterbrechung der Outlook Verbindung, es kann allerdings bis zu einer Stunde dauern, bis OWA und EAC wieder funktionieren. Hier muss man also Geduld aufbringen.

Hinweis: In einer Exchange Hybrid Umgebung muss nach dem Wechsel des Zertifikats der Hybrid Configuration Wizard erneut ausgeführt werden, damit die Änderungen auch im Azure AD übernommen werden.

27 Gedanken zu „Exchange Server: OWA und EAC starten nicht nach Installation der Juli Updates“

  1. Moin Franky,

    danke für die Infos.
    Bei uns war nicht das betroffene Zertifikat abgelaufen, sondern war einfach nach dem Update nicht mehr
    zugewiesen bzw. es stand ein komplett anderer Thumbprint drin, welcher überhaupt nicht mehr zu einem existierenden Zertifikat gehörte.
    Also dann statt ein neues Zertifikat zu erstellen das vorhandene, gültige neu zuweisen und dann lief das umgehend wieder.

    Gruß, Mario

    Antworten
      • Hallo Dirk,

        hatte genau das gleiche Phänomen wie Mario, Zert vorhanden und noch gültig aber nicht mehr zugewiesen, und es lief mit diesem vorhandenen Zertifikat danach auch wieder.
        1. Thumbprint des vorhandenen gültigen aber aktuell nicht zugewiesenen Zerts mit „Get-ExchangeCertificate“ ermitteln. Ist der wo „CN=Microsoft Exchange Server Auth Certificate“ als Subject steht.
        Danach:
        Set-AuthConfig -NewCertificateThumbprint -NewCertificateEffectiveDate (Get-Date)
        Set-AuthConfig –PublishCertificate

        Danach noch den „Microsoft Exchange Service Host Service“ und IIS neu gestartet und schon klappte OWA/ECP wieder

        Hoffe das hilft.

        Antworten
  2. Sollte das neue Zertifikat bei dieser Gelegenheit nicht gleich gegen SHA2 ausgetauscht werden?
    Das „New-ExchangeOAuthCertificate.ps1“-Script erzeugt ja wieder ein altes SHA1-Zertifikat, oder?

    Antworten
  3. Hallo wer nicht X Stunden warten möchte :-)
    kann auch gerne die Zeitzone des Exchagne Server auf „UTC World Time“ ändern, dann den IIS Reset per cmd console starten..
    und siehe da es geht wieder… MAGIC…

    Quelle:
    https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/cannot-access-owa-or-ecp-if-oauth-expired

    ChristianZickler-1785 · 5 days ago

    I found this solution in another post.
    There seems to be a timezone issue with this fix. So to get around the 12 hour waiting, you can just change the timezon in your Windows Exchange Server to UTC World Time.
    Afterwards you can login to ecp without having to wait.
    I found this solution in another post.
    There seems to be a timezone issue with this fix. So to get around the 12 hour waiting, you can just change the timezon in your Windows Exchange Server to UTC World Time.
    Afterwards you can login to ecp without having to wait.

    Antworten
  4. Hallo zusammen,
    hallo Frank,

    habe 4 Kunden – da laufen Mailserver so mit – sollen sie!

    2013, 2016 und 2019 – der 2013 hat jetzt den Fehler. Owa/ecp geht nicht mehr – löscht man den Update geht es wieder. Ergo, kann ja wohl das Zertifikat nicht abgelaufen sein – ist geht auch noch bis 2025. ???

    2x 2016 und 1 x 2019 habe ich deswegen erstmal nix gemacht.

    Sorry, mich kotzt diese MS-Sch…. langsam aber sicher an. Alle paar Wochen irgendein Mist. Erst gehackt, dann Immer wieder Sicherheitslücken und jetzt auch noch der Update fehlerhaft.

    Vielleicht bin ich zu blöd bzw. bei manchen Dingen auch echt nicht so sicher!

    Habe Frank geschrieben: benötige jemanden der mir mal hilft – gegen Bezahlung.

    Freu mich auf Rückmeldungen.

    info@stefankempf.com

    Gruss
    Stefan
    „Gereitzt“

    Antworten
    • Moin,
      Ich kann leider nicht viel helfen, nur den Hinweis geben das bei uns schon vor dem Update das Zertifikat abgelaufen war (und trotzdem alles lief), nach dem Update scheint Exchange das genauer zu prüfen ob das Zertifikat okay ist oder nicht.

      Gruß
      Philipp

      Antworten
  5. die letzten CUs waren immer problematisch, aber diesmal hat der Exchange 2019 das echt problemlos durchgemacht.

    Hatte schon das Script parat zur Ausführung, aber nach dem Einspielen des CU10 und Neustart hat alles normal funktioniert. Soll man das script trotzdem ausführen? Bis wohin verlängert sich das msexch-Auth Zert dann?

    Zertifikat ist bei mir mit „not after“ 26.10.2021terminisiert – spätestens da muss ich dann wohl prüfen bzw. erneuern.

    Antworten
  6. Hallo Leute.

    Ich hab gestern früh ganz entspannt auf meinem Exchange Server 2016 CU20 das Sicherheitsupdate eingespielt und musste feststellen, ups kein Zugriff mehr auf OWA und ECP.

    Deinstallieren kann ich das Update leider auch nicht mehr.

    Nun hab ich ein neues Cert erstellt, dieses läuft auf den Services I W S. Auch nach mehrmaligem Neustart und abwarten seit gestern Abend bekomme ich die aufgeführt Fehlermeldung.

    Hab auch den Trick mit der „Worldtime“ ausprobiert und den IIS immer resetet. Leider ohne Erfolg. Wo mache ich den Fehler?

    Zur Info das neue Cert ist gültig seit gestern bis 2026.

    Kann mir einer noch nen Tip geben?

    Antworten
  7. Ich gehe davon aus, dass es als ungültig angesehen wird.
    Als Ursache kann ich mir unsicherer Algorythmus wie SHA1 oder so vorstellen!

    Antworten
  8. Mahlzeit,
    ich habe – wie üblich – erst *nach* der Installation des Updates an den üblichen Stellen gelesen. Bei unserem Exchange 2013 CU23 ist zunächst auch das Problem des unbekannten Thumbprint für das OAuth Zertifikat aufgetreten. Das lässt sich ja relativ einfach fixen – OWA und ECP laufen. Allerdings lässt sich Outlook nur mit viel Geduld zur Verbindung überreden und scheint immer mal wieder die Verbindung zu verlieren.
    Zudem kann man auf dem Server die Management Shell nicht mehr starten mit dem Hinweis: ‚… die angeforderte HTTP-URL nicht verfügbar ist….‘
    Im Eventlog finden sich keine Hinweise – was tun?

    Antworten
    • Die Lösung war dem IIS als IP-Adresse ‚Keine zugewiesen‘ für die Websites Default und Backend erneut zuzuweisen. Warum auch immer, es war nur die primäre IP zugeordnet. Die zweite IP ist für die iSCSI Verbindung.

      Antworten
  9. Servus in die Runde,

    vllt. hat jemand einen Lösungsansatz oder steht vor dem gleichen Problem, bei dieser Exchange Cluster Config.

    Exc2016 2x Frontend 4xBackend (DAG) – „ja, wird heute nicht mehr so gebaut, hab es von meinem Vorgänger übernommen“. :)
    Nach CU21 lief alles noch problemlos, nachdem das SecurityUpdate installiert wurde, funktionierte wie zu erwarten OWA & EAC nicht mehr.
    Betroffenes Cert, wäre bei uns erst am 07.12.2021 abgelaufen.

    ⦿CU21 sowie SecurityUpdate auf allen 6 Servern installiert.
    ⦿Script von Franky schon auf allen Servern ausgeführt
    ⦿das Vorgehen von MS schon durchgespielt auf allen Servern
    https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/cannot-access-owa-or-ecp-if-oauth-expired
    ⦿altes Cert erneut gebunden
    ⦿sowie den Ansatz, dass die Zeitzone vor erstellen eines neuen Certs auf UTC gestellt wird und nachträglich wieder zurück

    Durch Dienstleister wurde das Ticket direkt an MS eskaliert, da ich jetzt keine Idee mehr habe

    Antworten
  10. Vielen Dank für das Script – es dauert tatsächlich mehrere Stunden – Wie bereits die „Vorposter“ erwähnten – Geduld ist angesagt.

    Gruß
    BS

    Antworten
  11. Hey,

    ich hatte das Problem auch auf einem Ex2016 unter W12R2.
    Ich konnte es nach der installation von KB5004779 sofort lösen über diese Anleitung (bei mir ohne Wartezeit)

    https://www.der-windows-papst.de/2021/03/14/microsoft-exchange-server-auth-certificate-is-missing/

    New-ExchangeCertificate -KeySize 4096 -PrivateKeyExportable $true -SubjectName “cn= Microsoft Exchange Server Auth Certificate” -DomainName “*.dwp.local” -FriendlyName “Microsoft Exchange Server Auth Certificate” -Services smtp

    $date=get-date
    Set-AuthConfig -NewCertificateThumbprint E44267F16D478E1435F44BE320496C964CA1FDB0 –NewCertificateEffectiveDate $date
    Set-AuthConfig –PublishCertificate

    Set-AuthConfig -ClearPreviousCertificate
    IISRESET

    Nachdem das Zertifikat erstellt und gebunden wurde, kann es vorkommen, das man 1 Stunde warten muss, bis das Zertifkat seine Anwendung findet. Gerade in Hinblick auf das Thema und der Fehlermeldung “ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1”.

    Antworten
  12. Hallo,
    Ich bekam heute in Outlook das mein Cert abgelaufen ist. Habe ein Neues erstellt. Aber es funktioniert nicht.
    Exchange Management Shell funktioniert nicht.
    Wie hier beschrieben die Scripte funktionieren auch nicht.

    Kann mir bitte jemand Helfen ?

    C:\Users\Administrator\Desktop\New-ExchangeOAuthCertificate.ps1 : Die Benennung „Get-AcceptedDomain“ wurde nicht a
    Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die
    Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
    In Zeile:1 Zeichen:1
    + .\New-ExchangeOAuthCertificate.ps1
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,New-ExchangeOAuthCertificate.ps1

    Antworten
  13. Zugriff auf die Exchange Management Shell kommt das :

    New-PSSession : [MAILservername] Beim Verbinden mit dem Remoteserver „MAILservername“ ist folgender Fehler
    aufgetreten: Die Anforderung kann von WinRM nicht verarbeitet werden. Bei Verwendung der Kerberos-Authentifizierung
    ist der folgende Fehler mit Fehlercode 0x8009030e aufgetreten: Eine angegebene Anmeldesitzung ist nicht vorhanden.
    Sie wurde gegebenenfalls bereits beendet.
    . Mögliche Ursachen:
    – Der angegebene Benutzername oder das angegebene Kennwort ist ungültig.
    – Kerberos wird verwendet, wenn keine Authentifizierungsmethode und kein Benutzername angegeben werden.
    – Kerberos akzeptiert Domänenbenutzernamen, aber keine lokale Benutzernamen.
    – Der Dienstprinzipalname (Service Principal Name, SPN) für den Remotecomputernamen und -port ist nicht vorhanden.
    – Der Clientcomputer und der Remotecomputer befinden sich in unterschiedlichen Domänen, zwischen denen keine
    Vertrauensbeziehung besteht.
    Wenn Sie die oben genannten Ursachen überprüft haben, probieren Sie folgende Aktionen aus:
    – Suchen Sie in der Ereignisanzeige nach Ereignissen im Zusammenhang mit der Authentifizierung.
    – Ändern Sie die Authentifizierungsmethode; fügen Sie den Zielcomputer der Konfigurationseinstellung „TrustedHosts“
    für WinRM hinzu, oder verwenden Sie den HTTPS-Transport.
    Beachten Sie, dass Computer in der TrustedHosts-Liste möglicherweise nicht authentifiziert sind.
    – Führen Sie den folgenden Befehl aus, um weitere Informationen zur WinRM-Konfiguration zu erhalten: „winrm help
    config“. Weitere Informationen finden Sie im Hilfethema „about_Remote_Troubleshooting“.
    Andere mögliche Ursache:
    Der Domänen- oder Computername war in den angegebenen Anmeldeinformationen nicht enthalten. Beispiel: DOMAIN\UserName
    oder COMPUTER\UserName.
    In Zeile:1 Zeichen:1
    + New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Micr …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
    gTransportException
    + FullyQualifiedErrorId : 1312,PSSessionOpenFailed

    Antworten
  14. Dadurch bei mir nix mehr Funktionierte.
    Habe ich das Exchange2016-KB5004779-x64-de De-Installiert und Neugestartet.
    Danach im IIS die Bindungen überprüft und das Zert angegeben.
    Seitdem habe ich via Managment Shell wieder zugriff.
    Wenigstens eines Funktioniert wieder.

    Aber Outlook kann sich noch immer nicht Verbinden.
    ECP und OWA Funktionieren ebenfalls noch immer nicht.

    Antworten

Schreibe einen Kommentar