Neue Updates für Exchange Server (Juni 2021)

Microsoft hat heute neue Updates für Exchange Server 2016 und 2019 veröffentlicht. Bei dem jetzt veröffentlichten CU21 für Exchange 2016 handelt es sich um das letzte CU, welches noch für Exchange 2016 erscheint. Ab jetzt wird es nur noch Sicherheitsupdates für Exchange 2016 geben.

Hier geht es direkt zum Download der CUs:

Das CU10 für Exchange 2019 lässt sich nun auch direkt von Microsoft runterladen, ohne dass ein VLSC Zugang, Action Pack oder Visual Studio Abo benötigt wird. Bisher war dies nicht möglich, aber scheinbar hat Microsoft hier seine Strategie überdacht und bietet den Download nun direkt an.

Details zu den behoben Problemen gibt es unter den folgenden Links (möglicherweise noch nicht direkt verfügbar):

Die CUs enthalten alle zuvor veröffentlichen Sicherheitsupdates.

Mit den Juni CUs für Exchange bekommen beide Versionen ein neues Feature. Das Windows Antimalware Scan Interface (AMSI) integriert sich nun auch in Exchange Server. AMSI ist auf Windows Server 2016 und 2019 verfügbar. Sollte Exchange 2016 noch auf Server 2012R2 installiert sein, lässt sich die AMSI Integration nicht nutzen.

Die AMSI Integration ermöglicht es, dass AMSI kompatible Software, die HTTP-Verbindungen zu Exchange Servern auf schadhaften Traffic untersuchen und blockieren können. Die AMSI-Integration in Exchange Server funktioniert mit jeder AMSI-fähigen Antiviren-/Antimalware-Lösung. Sollte keine AMSI kompatible Antimalwaresoftware auf dem Exchange Server installiert sein, übernimmt Microsoft Defender Antivirus (MDAV) das Scannen des Traffics. MDAV ist bereits in Windows Server 2016 und Server 2019 vorinstalliert. wird aber deaktiviert, sobald eine andere Antivirus Lösung installiert wird. Hier sollte geprüft werden, ob die eingesetzte Antivirensoftware AMSI kompatibel ist, damit das neue Feature genutzt werden kann. Wichtig: Bei der AMSI Integration handelt es sich nicht um eine Integration in einen Virenscanner im klassischen Sinn. AMSI ermöglicht es den HTTP Verkehr eines Exchange Servers zu untersuchen, also Protokolle wie MAPIoverHTTP, ActiveSync, EWS und OWA. Hier werden also nicht Mails auf Viren, Malware oder SPAM untersucht, sondern die Verbindungen der Clients zum Exchange Server.

Die Exchange AMSI Integration dürfte eine Reaktion auf die HAFNIUM Schwachstelle Anfang des Jahres sein, denn ein entsprechendes Signaturupdate hätte schnell die Auswirkungen abmildern können.

41 Gedanken zu „Neue Updates für Exchange Server (Juni 2021)“

  1. Nabend,

    derzeit scheitere ich schon an den Vorbereitung für das eigentliche Setup:
    Schema wurde erfolgreich von CU19 auf CU21 aktualisiert
    Setup.EXE /PrepareAD /IAcceptExchangeServerLicenseTerms bricht immer wieder ab:

    per GUI im Schritt 1 von 18:
    Fehler:
    Der folgende Fehler wurde generiert, als „$error.Clear();
    $createTenantRoot = ($RoleIsDatacenter -or $RoleIsPartnerHosted);
    $createMsoSyncRoot = $RoleIsDatacenter;

    #$RoleDatacenterIsManagementForest is set only in Datacenter deployment; interpret its absense as $false
    [bool]$isManagementForest = ($RoleDatacenterIsManagementForest -eq $true);

    if ($RolePrepareAllDomains)
    {
    initialize-DomainPermissions -AllDomains:$true -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
    }
    elseif ($RoleDomain -ne $null)
    {
    initialize-DomainPermissions -Domain $RoleDomain -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
    }
    else
    {
    initialize-DomainPermissions -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
    }
    “ ausgeführt wurde: „System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    bei Microsoft.Exchange.Management.Tasks.SetupTaskBase.LogReadObject(ADRawEntry obj)
    bei Microsoft.Exchange.Management.Tasks.InitializeDomainPermissions.InternalProcessRecord()
    bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
    bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)
    bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessTaskStage(TaskStage taskStage, Action initFunc, Action mainFunc, Action completeFunc)
    bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
    bei System.Management.Automation.CommandProcessor.ProcessRecord()“.

    Da ich bisher das CU20 nicht installiert hatte habe ich selbstredend versucht die Vorbereitungen für das CU20 vorzunehmen, dies funktioniert einwandfrei.
    Derzeit weiß ich nicht wo ich ansetzen kann. Berechtigungen sind fast ausgeschlossen (Upgrade von CU19 auf CU20 hat soeben funktioniert)

    Hat Jemand eine Idee?

    Danke & Gruß
    Mario

    Antworten
    • Hallo Mario,

      habe den gleichen Fehler bei einem Exchange 2019 CU 9. Upgrade schlägt auf die CU 10 mit dem gleichen Fehler fehl.

      Hier die Kreuzverlinkung:

      Gruß
      Tobi

      Antworten
      • Hi Stefan,

        würde mich auch interessieren. Bin seit Tagen dran am System aber kommen nicht weiter. Frank ist auch dabei im Administrator Forum.

        Antworten
      • Bei mir ist das Update von 2019 CU9 auf CU10 auch nicht möglich. Obwohl der User in der Gruppe Schema- und Organisationsadmins ist, schlägt die Vorbereitung des Setups mit der Meldung fehl: „Das Active Directory-Schema ist nicht aktuell, und dieses Benutzerkonto ist kein Mitglied der Gruppe ‚Schema-Admins‘ und/oder ‚Organisations-Admins‘.“

        Ich komme als gar nicht bis zur Installation. Und ja, das Setup wurde mit erhöhten Rechten in der PowerShell ausgeführt.

        Antworten
    • Hi Mario,

      der Fehler allein bzw. der Call-Stack genügen leider nicht. Was steht denn unmittelbar in der Zeile darüber?
      Das hier: Used domain controller NTVMDC05.kba.de to read object CN=AdminSDHolder,CN=System,DC=contoso,DC=com.
      ?
      Wenn ja führe bitte mal das aus (mit angepasstem DC=:
      C:\>dsquery * -filter „(&(objectCategory=*)(distinguishedName=CN=AdminSDHolder,CN=System,DC=contoso,DC=com)(!(msExchCU=*))(objectCategory=container)(|(&(msExchVersion<=1125899906842624)(!(msExchVersion=1125899906842624)))(!(msExchVersion=*))))"

      Was ist das Resultat? Etwa so: "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

      Wenn das für den Admin klappt, kannst Du das selbe Mal als LocalSystem auf dem Exchange Server ausführen? Dazu brauchst Du psexec von Sysinternals und startest es per: psexec -s -i cmd.exe

      Ralf

      Antworten
      • Hallo Ralf,

        ich sehe derzeit nicht was Du wissen möchtest.

        dsquery zeigt jeweils CN=AdminSDHolder,CN….. an, als Admin wie auch als System.
        Die Verbindung zu einem der AD Controller besteht und wird nicht angemeckert.

        Es besteht kein Handlingsfehler und es gibt auch keine Berechtigungsprobleme…

        [07.06.2021 12:53:17.0508] [2] Used domain controller AD-1.intern.de to read object DC=intern,DC=de.
        [07.06.2021 12:53:17.0560] [2] Used domain controller AD-1.intern.de to read object CN=AdminSDHolder,CN=System,DC=intern,DC=de.
        [07.06.2021 12:53:17.0571] [2] [ERROR] Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
        [07.06.2021 12:53:17.0572] [2] [WARNING] An unexpected error has occurred and a Watson dump is being generated: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
        [07.06.2021 12:53:17.0829] [1] The following 1 error(s) occurred during task execution:
        [07.06.2021 12:53:17.0829] [1] 0. ErrorRecord: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
        [07.06.2021 12:53:17.0829] [1] 0. ErrorRecord: System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
        bei Microsoft.Exchange.Management.Tasks.SetupTaskBase.LogReadObject(ADRawEntry obj)
        bei Microsoft.Exchange.Management.Tasks.InitializeDomainPermissions.InternalProcessRecord()
        bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
        bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)
        bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessTaskStage(TaskStage taskStage, Action initFunc, Action mainFunc, Action completeFunc)
        bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()
        bei System.Management.Automation.CommandProcessor.ProcessRecord()
        [07.06.2021 12:53:17.0831] [1] [ERROR] The following error was generated when „$error.Clear();
        $createTenantRoot = ($RoleIsDatacenter -or $RoleIsPartnerHosted);
        $createMsoSyncRoot = $RoleIsDatacenter;

        #$RoleDatacenterIsManagementForest is set only in Datacenter deployment; interpret its absense as $false
        [bool]$isManagementForest = ($RoleDatacenterIsManagementForest -eq $true);

        if ($RolePrepareAllDomains)
        {
        initialize-DomainPermissions -AllDomains:$true -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
        }
        elseif ($RoleDomain -ne $null)
        {
        initialize-DomainPermissions -Domain $RoleDomain -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
        }
        else
        {
        initialize-DomainPermissions -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest;
        }
        “ was run: „System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

        Gruß
        Mario

        Antworten
        • Mario, es hilft nicht wenn Du den selben CallStack wieder und wieder reinkopierst. Befindet sich der AdminSDHolder Container im AD auch an der Stelle: CN=AdminSDHolder,CN=…..
          Kannst Du mal einen LDAP Dump mit ldp.exe davon machen. Hatte gestern einen identischen Fall, da hat der Admin den Container CN=Computers umbenannt und eine OU=Computers erzeugt.

  2. Hallo
    diese Vorbereitung „Setup.EXE /PrepareAD /IAcceptExchangeServerLicenseTerms“ für das eigentliche Setup habe ich nie gemacht, ich habe aber immer alle CUs nathlos installiert und keines ausgelassen, ob das daranliegt?

    Antworten
    • Also, die Installation des CU21 auf Exchange 2016 mit Server 2016 lief problemlos duch.
      EAC kann man sich einloggen, keine Probleme erkennbar, E-Mails senden und empfangen funktioniert auch.

      Die Fehler in der Ereignissanzeige sind aber nicht verschwunden, aber die gibts schon seit 2017.

      Antworten
  3. Ex2016 CU20 auf CU21 lief problemlos durch. Der Exchange hat im Anschluss ganz schön gerödelt. Erst lief der. NET Optimizer an und dann ratterte bei den IIS Workern noch was durch. Ein Neustart hat aber wieder alles beruhigt.

    Antworten
  4. Upgrade auf einer Ex2019 DAG von CU9 auf CU10 problemlos durchgelaufen.
    Vorsichtshalber vor dem Setup noch auf den Nodes einen Reboot durchgeführt.

    Antworten
  5. Upgrade einer DAG 2016 von CU20 auf CU21 hat leider einen Node komplett gecrasht, Restore notwendig, trotz aller üblichen Vorab-Maßnahmen. Setup ist abgestürzt und der MSX ist auf dem Knoten nur noch halb drauf.

    Antworten
  6. Update von CU20 auf das CU21 lief ohne Probleme auf beide Server des DAG-Verbundes durch.

    Jedoch kommt es nun im Zusammenhang mit der Sophos Server Protektion (genauer Sophos AMSI Protection) zu erheblichen Problemen mit der Verbindung zu Outlook. Diese ist bei allen Clients nun brechend langsam. Mails Empfangen/Versenden dauert mehrere Minuten und bei manchen Kollegen geht Outlook schon gar nicht mehr auf. OWA, ActiveSync ist davon nicht betroffen.

    Das temporäre deaktivieren dieses Moduls bringt hier Abhilfe. Ticket bei Sophos ist derzeit noch offen.

    Antworten
    • Danke erstmal das du ein Ticket bei Sophos aufgemacht hast. Somit muss ich das nicht machen :)

      Gibt es schon eine Antwort auf das Ticket von Sophos?

      Antworten
  7. Update Exchange 2016 CU19 -> CU21 lief problemlos durch \o/

    Nach dem update wollte allerdings ein sendeconnector nicht mehr so wirklich tun was er sollte, ein deaktivieren und wieder aktivieren des Connectors hat das problem dann gelöst ;)

    Ansonsten bisher keine weiteren Auffälligkeiten.

    Antworten
  8. Irgendjemand eine Ahnung was mit KB5004623 passiert ist?
    Es stand für ~1 Stunde direkt nach dem Release des CU bei den Fixes dabei und es war sogar ein Link zu einem CVE vorhanden(der aber nicht funktioniert hat). Mittlerweile ist allerdings sogar die KB5004623 seite komplett gelöscht worden.

    Die Relevanten AD Schema Änderungen sind allerdings offenbar noch im CU vorhanden.

    Google Cache link:
    https://webcache.googleusercontent.com/search?q=cache:h5eg71PU66EJ:https://support.microsoft.com/en-us/topic/elevation-of-privilege-vulnerability-in-active-directory-because-of-msexchstoragegroup-schema-class-kb5004623-ae4dc955-ba80-4f5e-89a7-5005f80327b5+&cd=1&hl=de&ct=clnk&gl=de&client=firefox-b-e

    Antworten
  9. Update von DAG Exchange 2016 von CU20 auf CU21 ohne Probleme.

    Frage mich auch was Microsoft für Schema Änderungen im Update gesteckt hat.

    Antworten
  10. Wir betreiben unsere Exchangeserver 2016 (DAG) auf Server 2012R2.
    „AMSI Integration“ gem. obigen Beschrieb nicht möglich. Ist dies korrekt? Was passiert dann mit diesem neuem Modul? Wird es nicht aktiviert, gibt es Issues/Fehler/…?
    Hat jemand das CU21 auf einer solchen Konstellation schon installiert?

    Antworten
  11. Neues Sicherheitsupdate ist raus https://support.microsoft.com/de-de/topic/hinweise-zum-sicherheitsupdate-f%C3%BCr-microsoft-exchange-server-2019-2016-und-2013-13-april-2021-kb5001779-8e08f3b3-fc7b-466c-bbb7-5d5aa16ef064

    Downloadsymbol Download Security Update For Exchange Server 2019 Kumulatives Update 9 (KB5001779)

    Downloadsymbol Download Security Update For Exchange Server 2019 Kumulatives Update 8 (KB5001779)

    Downloadsymbol Download Security Update For Exchange Server 2016 Kumulatives Update 20 (KB5001779)

    Downloadsymbol Download Security Update For Exchange Server 2016 Kumulatives Update 19 (KB5001779)

    Downloadsymbol Download Security Update For Exchange Server 2013 Kumulatives Update 23 (KB5001779)

    Antworten
  12. Habe gestern das Security Update For Exchange Server 2016 CU20 (KB5004779) eingespielt und nun komme ich nicht mehr auf das ECP.
    erhalte diesen Fehler:
    Serverfehler in der Anwendung /owa.
    ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1

    hat da jemand eine Idee was hier passiert ist?

    Antworten
  13. Konnte das das Security Update für Exchange Server 2016 CU20 (KB5004779) auf einem einzelnen Exchange-Server einspielen. Jedoch leider nicht CU21, weder mit KB5004779 noch ohne. Die Installation von CU21 bricht jeweils bei Schritt 16 von 18 mit folgender Meldung ab:

    Der folgende Fehler wurde generiert, als „$error.Clear();
    Install-ExchangeCertificate -services „IIS, POP, IMAP“ -DomainController $RoleDomainController
    if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
    {
    Install-AuthCertificate -DomainController $RoleDomainController
    }
    “ ausgeführt wurde: „Microsoft.Exchange.Management.SystemConfigurationTasks.AddAccessRuleCryptographicException: Aufgrund einer Kryptografieausnahme konnte konnte kein Netzwerkdienstzugriff auf das Zertifikat mit dem Fingerabdruck BA9E98E9E395A7914DA49C7E376969F3197B21BD erteilt werden. —> System.Security.Cryptography.CryptographicException: Zugriff verweigert

    bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.CAPIAddAccessRule(X509Certificate2 certificate, AccessRule rule)
    bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.AddAccessRule(X509Certificate2 certificate, AccessRule rule)
    bei Microsoft.Exchange.Management.SystemConfigurationTasks.ManageExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services, String websiteName, Boolean requireSsl, ITopologyConfigurationSession dataSession, Server server, List`1 warningList, Boolean allowConfirmation, Boolean forceNetworkService)
    — Ende der internen Ausnahmestapelüberwachung —
    bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
    bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
    bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services)
    bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()
    bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
    bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.

    Antworten
    • Kannst Du mit New-ExchangeCertificate ein neues Zerifikat erzeugen?
      Kannst Du die fehlenden Rechte manuell zuweisen:

      Zertifikate -> Rechte Maustaste auf das „BA9E98E9E395A7914DA49C7E376969F3197B21BD“

      Alle Aufgaben -> Private Schlüssel verwalten

      Netzwerkdienst hinzufügen -> „lesen“ Rechte hinzufügen

      Antworten
      • Ja ich konnte ein neues, selbst signiertes Zertifikat in der Exchange Management Shell mittels des Kommandos „New-ExchangeCertificate“ erstellen. Und ich konnte auch die Rechte für dieses Zertifikat einsehen in der certlm.msc bzw. in „Benutzerzertifkate verwalten“ und dort durch rechten Mausklick auf das Zertifikat und Wahl von „Alle Aufgaben \ Private Schlüssel verwalten“.

        Ich habe dieses selbst signierte Zertifikat allerdings nicht das aktuelle Zertifikat ersetzen lassen, da ich Let’s encrypt Zertifikate mittels WIN-ACME nutze wie hier beschrieben auf https://www.frankysweb.de/exchange-certificate-assistant-keine-neue-version-aber-eine-bessere-alternative-win-acme/ .

        Das in der Fehlermeldung aufgeführte Zertifikat habe ich gar nicht mehr gefunden. Allerdings hatte ich zwischenzeitlich 2 uralte, nicht mehr genutzte Zertifikate gelöscht gehabt.

        Antworten
        • Dank Änderung der Zugriffsrechte für das Let’s Encrypt Zertifikat, dass ich Leserechte für „Netzwerkdienst“ ergänzt habe, konnten Exchange Server 2016 CU21 und KB5004779 erfolgreich installiert werden. Danke an Ralf für seinen wertvollen Tip!

Schreibe einen Kommentar