Neue Exchange Server Updates (September 2021)

Microsoft hat neue Updates für Exchange Server 2016 und 2019 veröffentlicht. Ursprünglich sollte Exchange 2016 nur noch Sicherheitsupdates und keine neues Features mehr per CU erhalten. Jedoch wurde jetzt für Exchange 2016 das CU 22 veröffentlicht. Für Exchange 2019 wurde das CU 11 freigegeben. Beide CUs enthalten das neue Feature „Exchange Emergency Mitigation“, hier bekommt also auch Exchange 2016 noch einmal ein neues (sehr interessantes) neues Feature spendiert.

Hier geht es direkt zum Download der aktuellen CUs:

Das CU11 für Exchange 2019 lässt sich auch wieder direkt runterladen. Früher waren die Exchange 2019 CUs nur mit einem VLSC, Action Pack oder Visual Studio Abo verfügbar. Diese Hürde für den Download von Updates dürfte in der Vergangenheit dafür gesorgt haben, dass viele Exchange 2019 Organisationen nicht schnell auf das aktuelle CU updaten könnten, einfach weil der entsprechende Download fehlte. Der Exchange Admin hat ja nicht unbedingt zugriff auf das VLSC Portal…

Hinweis: Das neue CU erfordert das IIS URL Rewrite Modul. Das Modul muss vor der Installation des CUs installiert werden. Auf Windows Server 2012 R2 wird zusätzlich noch die Universal C Runtime vorausgesetzt.

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

Ich habe eingangs kurz erwähnt, dass es ein neues Feature für Exchange 2016 und 2019 gibt: Exchange Emergency Mitigation (EM). Mit EM liefert Microsoft ein sehr sinnvolles Feature für On-Prem Exchange Installationen, um das Ausnutzen von Sicherheitslücken auf Exchange Servern zu verhindern, bis entsprechende Updates eingespielt wurden. Ein Artikel zur Funktionsweise und Verwaltung von Exchange Emergency Mitigation folgt in Kürze:

Neue Exchange Server Updates (September 2021)

10 Gedanken zu „Neue Exchange Server Updates (September 2021)“

  1. Hallo Frank,

    auf Grund von der Einführung von „Exchange Emergency Mitigation“ will Microsoft jetzt auch die Angabe während der Installation oder dem Schema Update ob Diagnose Daten gesendet werden dürfen.

    /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
    Use this switch to accept the license terms and send optional data to Microsoft when the EM service requests mitigations

    /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF
    Use this new setup switch to accept the license terms and disable sending optional data to Microsoft.

    MfG Paul

    Antworten
  2. Kaum das CU für den Exchange 2019 eingespielt geht die Suche nicht mehr. Das MS das nicht einfach mal gelöst bekommt oder die Bing Suche wieder raus schmeißt.

    Antworten
    • Kleine Zusatz. Das komplette Loggile zu BigFunnelRetryFeederTimeBasedAssistant ist jetzt voll mit:

      Microsoft.Exchange.Data.Storage.AccessDeniedException

      Meldungen.

      Antworten
  3. Hallo,

    ich hatten jetzt auf drei „on premise stand allown“ Exchange2019 Server nach dem installieren vom CU11 von CU10 den Fehler, dass über des Web-Management (ECP) keine Benutzer mehr angelegt werden konnten.
    Fehler:
    Beim Lastenausgleich konnte keine gültige Postfachdatenbank gefunden werden
    oder
    Load balancing failed to find a valid mailbox database

    Behoben durch:
    Get-mailboxdatabase | ft name,isexcludedfromprovisioning
    Die Datenbank steht auf „True“
    Abhilfe:
    Get-mailboxdatabase | set-mailboxdatabase -isexcludedfromprovisioning $false
    danach keine Probleme mehr.

    Antworten
  4. Hallo in die Runde,

    wir hatten seit Ewigkeiten mal wieder Problem bei einer CU Installation.

    Unsere Exchange Umgebung sind 2 Exchange 2019 an zwei AD Standorten, keine DAG.

    Installation auf dem 1. Exchange lief Problemlos durch.

    2h später ging das Update auf dem anderen Exchange zunächst schief.

    Abbruch bei Schritt 10 von 16: Postfachrolle Transportdienst

    Es folgt eine ewig lange Fehlermeldung (hier nur der Anfang)

    Der folgende Fehler wurde generiert, als „$error.Clear();
    if ($RoleProductPlatform -eq „amd64“)
    {
    try
    {
    # Need to configure the ETL traces before the fast service is installed. This will ensure that when the service comes up
    # it will have the necessary trace session setting available to read from the registry
    $fastPerfEtlTraceFolderPath = Join-Path -Path $RoleBinPath -ChildPath „\Search\Ceres\Diagnostics\ETLTraces“
    $fastDiagnosticTracingRegKeyPath = ‚HKLM:\SOFTWARE\Microsoft\Office Server\16.0\Search\Diagnostics\Tracing‘
    if(-not(Test-Path -Path $fastPerfEtlTraceFolderPath))
    {
    $null = New-Item $fastPerfEtlTraceFolderPath -Type ‚Directory‘ -Force
    }

    if (-not(Test-Path -Path $fastDiagnosticTracingRegKeyPath))
    {
    $null = New-Item -Path $fastDiagnosticTracingRegKeyPath -Force
    }

    $null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚TracingPath‘ -PropertyType ’string‘ -Value $fastPerfEtlTraceFolderPath -Force
    $null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚TracingFileName‘ -PropertyType ’string‘ -Value ‚DocumentProcessingTrace‘ -Force
    $null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚DocumentParserSuccessLogMessage‘ -PropertyType ‚Dword‘ -Value 1 -Force
    $null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚DocumentParserLoggingNoInitialisation‘ -PropertyType ‚Dword‘ -Value 1 -Force

    Erstmal ratlos haben wir an allen Stellen gesucht und gesehen, dass es im AD ein Problem mit der Schema Replikation gibt / gab. Hier weiter geschaut scheint das mit einem Schreibkonflikt mit einen „Healthmailbox Objekt“ zusammenzuhängen.

    An der Stelle haben wir aber erstmal nichts weiter gemacht und das Setup nach einem Reboot neu gestartet. Das CU Setup meldete eine unvollständige Installation und wollte weiter machen.

    Das CU lief dann durch und beide Exchange laufen bisher sauber. Ich hatte uns schon in der Nacht mit /Recoverserver sitzen sehen. Jahre nicht mehr gemacht.

    Die AD Replikationsmeldung ist auch weg.

    Es bleibt ein ungutes Gefühl, da wir nicht wirklich wissen was hier passiert ist und ob es hier Zusammenhänge gibt.

    Wenn also jemand Ideen hat bin ich sehr dankbar.

    Danke und VG Sven

    Antworten
  5. Wurde durch das CU22 für Exchange Server 2016 dieses Problem behoben?
    Fehler „E-Mail kann nicht gesendet werden – Ihr Postfach ist voll“, wenn Sie iPhone-Mail verwenden, um sehr große Anlagen zu senden (KB5004622)
    https://support.microsoft.com/de-de/topic/fehler-e-mail-kann-nicht-gesendet-werden-ihr-postfach-ist-voll-wenn-sie-iphone-mail-verwenden-um-sehr-gro%C3%9Fe-anlagen-zu-senden-kb5004622-eb95555f-80fd-47b4-bc6f-5c2c4fc4fea0

    Die Website sagt ja immer noch:
    Ursache
    Dieses Problem tritt auf, nachdem Sie eines der folgenden kumulativen Updates installiert haben:
    Kumulatives Update 21 für Exchange Server 2016

    bzw.
    Status
    Dieses Problem ist Microsoft bekannt und stellt weitere Informationen in diesem Artikel bereit, sobald ein Fix verfügbar ist.

    Antworten
  6. Neus CU via CMD-Adminmodus eingespielt. Folgenden Error erhalten:

    Installing product E:\exchangeserver.msi failed. Fatal error during
    installation. Error code is 1603. Last error reported by the MSI package is
    ‚The installer has insufficient privileges to access this directory: C:\Program
    Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.1.2375. The
    installation cannot continue. Log on as administrator or contact your system
    administrator.‘.

    Irgend jemand eine Idee?
    Vorher war CU19 drauf. Exchange 2016.

    Antworten

Schreibe einen Kommentar