Exchange Server: Neues CU verfügbar (September 2020)

by

Microsoft hat heute für Exchange 2016 und Exchange 2019 neue Cumulative Updates (CU) veröffentlicht:

Das Exchange 2019 CU 7 steht auch bereits via MyVisualStudio zum Download zur Verfügung. Hier eine Liste der behobenen Probleme:

  • 4570248 „Get-CASMailbox“ verwendet einen falschen LDAP-Filter für ECPEnabled in Exchange Server 2019
  • 4576652 Updates für Exchange Server 2019 Sizing Calculator Version 10,5
  • 4570252 Zeitweilige nicht verarbeitbare Nachrichten aufgrund von NotInBagPropertyErrorException in Exchange Server 2019
  • 4576649 System. InvalidCastException beim Ändern von Kennwörtern in Outlook im Web in Exchange Server 2019
  • 4570251 Posteingangsregel beim Anwenden einer persönlichen Kategorie wird RetentionDate in Exchange Server 2019 nicht gestempelt
  • 4570245 ESEUtil/p schlägt fehl, wenn ein Long-Wert (LV) in Exchange Server 2019 beschädigt ist.
  • 4570255 NullReferenceException tritt auf, wenn TestFederationTrust in Exchange Server 2019 ausgeführt wird.
  • 4576650 Beim Festlegen der e-Mail-Weiterleitung in Exchange Server 2019-Hybrid Umgebung kann kein Remotepostfach hinzugefügt werden
  • 4570253 CompletedWithErrors ohne Details für Post Fach Migrationsbatches in Exchange Server 2019
  • 4570247 CSV-Protokoll des Ermittlungs Exports schlägt in Exchange Server 2019 nicht ordnungsgemäß Escape-Ziel Pfad Feld vor
  • 4570246 Edgetransport stürzt mit der Ereignis-ID 1000 (Ausnahmecode 0xc00000fd) in Exchange Server 2019 ab
  • 4570254 MSExchangeMapiMailboxAppPool verursacht eine längere CPU-Auslastung von 100% in Exchange Server 2019
  • 4563416 Der Frei/Gebucht-Status des Online Benutzers kann in Exchange Server 2019 nicht angezeigt werden
  • 4576651 Nach der Installation von Exchange Server 2019 CU5 können Sie nicht an Teams-Besprechungen von Surface Hub-Geräten teilnehmen
  • 4577352 Beschreibung des Sicherheitsupdates für Microsoft Exchange Server 2019 und 2016:8. September 2020

Außerdem hat der Exchange Calculator ein Update erhalten.

Exchange Server: Neue CUs verfügbar (September 2020)

43 thoughts on “Exchange Server: Neues CU verfügbar (September 2020)”

  2. Kurze Frage:

    Aktuell haben wir eine Koexistenz mit einem Exchange 2010 und einem 2016er, wir sind also noch in der Migration :-). Dann kam CU18, was wir auch eingespielt haben, aber wir haben den 2016er Exchange vorher nicht in den Maintenance Mode geschickt. Seitdem gehen keine E-Mails mehr zwischen dem 2010ner und 2016ner durch. Könnte ich CU 18 noch einmal drüber installieren (und natürlich vorher den Maintenance Mode aktivieren)?

    Danke!

    Reply

  3. Kurze Frage, gibt es eine Lösung für das OWA Problem, bzgl. Anhänge und Co., bzw. die Umleitung auf die o365 URL? Ich Frage deshalb, bevor ich einen Fall bei MS aufmache.

    Reply

  4. Hallo Zusammen,

    habe das Cu18 auf einem Server2016 / Exchange2016 mit Cu11 installiert und scheitere an der Postfachrolle / Postfachdient im Schritt 13 von 17 mit Abbruch und unten stehendem Fehler. Aktualisierung Schema und AD erfolgte vorab ohne Fehler. Defender usw. deaktiviert, wie in Frankys Beschreibung aus vorangegangenen Problemen. Probiere schon das ganze Wochenende und finden keinen Ansatz. Vielleicht kann sich jemand erbarmen und hat einen Lösungsansatz für mich.

    Fehler:
    Der folgende Fehler wurde generiert, als „$error.Clear();
    if (($RoleIsDatacenter -ne $true) -and ($RoleIsDatacenterDedicated -ne $true))
    {
    if (test-ExchangeServersWriteAccess -DomainController $RoleDomainController -ErrorAction SilentlyContinue)
    {
    $sysMbx = $null;
    $name = „SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}“;
    $dispname = „Microsoft Exchange“;
    $mbxs = @( get-mailbox -arbitration -Filter {name -eq $name} -IgnoreDefaultScope -resultSize 1 );
    if ( $mbxs.length -eq 0)
    {
    $dbs = @(get-MailboxDatabase -Server:$RoleFqdnOrName -DomainController $RoleDomainController);
    if ($dbs.Length -ne 0)
    {
    $arbUsers = @(get-user -Filter {name -eq $name} -IgnoreDefaultScope -ResultSize 1);
    if ($arbUsers.Length -ne 0)
    {
    $sysMbx = enable-mailbox -Arbitration -identity $arbUsers[0] -DisplayName $dispname -database $dbs[0].Identity;
    }
    }
    }
    else
    {
    if ($mbxs[0].DisplayName -ne $dispname )
    {
    set-mailbox -Arbitration -identity $mbxs[0] -DisplayName $dispname -Force;
    }
    $sysMbx = $mbxs[0];
    }

    # Set the Organization Capabilities needed for this mailbox
    if ($sysMbx -ne $null)
    {
    Write-ExchangeSetupLog -Info („Setting mailbox properties.“);
    set-mailbox -Arbitration -identity $sysMbx -UMDataStorage:$true -Force;

    # No RetentionPolicy assigned to E-Discovery arbitration mailbox currently, we need to set it here.
    # This can be remove after BUG(O15#2555914) is fixed.
    if ($sysMbx.RetentionPolicy -eq $null )
    {
    $arbitrationRetentionPolicy = @(Get-RetentionPolicy -DomainController $RoleDomainController | where {$_.Name -eq ‚ArbitrationMailbox‘});
    set-mailbox -Arbitration -identity $sysMbx -RetentionPolicy $arbitrationRetentionPolicy[0].Identity -Force;
    }
    }
    else
    {
    Write-ExchangeSetupLog -Info („Cannot find E-discovery arbitration mailbox with name=$name.“);
    }
    }
    else
    {
    write-exchangesetuplog -info „Skipping creating Discovery Arbitration Mailbox because of insufficient permission.“
    }
    }
    “ ausgeführt wurde: „Microsoft.Exchange.Data.DataValidationException: ‚Database‘ ist für ‚UserMailbox‘ verbindlich.“.

    Fehler:
    Der folgende Fehler wurde generiert, als „$error.Clear();
    if (($RoleIsDatacenter -ne $true) -and ($RoleIsDatacenterDedicated -ne $true))
    {
    if (test-ExchangeServersWriteAccess -DomainController $RoleDomainController -ErrorAction SilentlyContinue)
    {
    $sysMbx = $null;
    $name = „SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}“;
    $dispname = „Microsoft Exchange“;
    $mbxs = @( get-mailbox -arbitration -Filter {name -eq $name} -IgnoreDefaultScope -resultSize 1 );
    if ( $mbxs.length -eq 0)
    {
    $dbs = @(get-MailboxDatabase -Server:$RoleFqdnOrName -DomainController $RoleDomainController);
    if ($dbs.Length -ne 0)
    {
    $arbUsers = @(get-user -Filter {name -eq $name} -IgnoreDefaultScope -ResultSize 1);
    if ($arbUsers.Length -ne 0)
    {
    $sysMbx = enable-mailbox -Arbitration -identity $arbUsers[0] -DisplayName $dispname -database $dbs[0].Identity;
    }
    }
    }
    else
    {
    if ($mbxs[0].DisplayName -ne $dispname )
    {
    set-mailbox -Arbitration -identity $mbxs[0] -DisplayName $dispname -Force;
    }
    $sysMbx = $mbxs[0];
    }

    # Set the Organization Capabilities needed for this mailbox
    if ($sysMbx -ne $null)
    {
    Write-ExchangeSetupLog -Info („Setting mailbox properties.“);
    set-mailbox -Arbitration -identity $sysMbx -UMDataStorage:$true -Force;

    # No RetentionPolicy assigned to E-Discovery arbitration mailbox currently, we need to set it here.
    # This can be remove after BUG(O15#2555914) is fixed.
    if ($sysMbx.RetentionPolicy -eq $null )
    {
    $arbitrationRetentionPolicy = @(Get-RetentionPolicy -DomainController $RoleDomainController | where {$_.Name -eq ‚ArbitrationMailbox‘});
    set-mailbox -Arbitration -identity $sysMbx -RetentionPolicy $arbitrationRetentionPolicy[0].Identity -Force;
    }
    }
    else
    {
    Write-ExchangeSetupLog -Info („Cannot find E-discovery arbitration mailbox with name=$name.“);
    }
    }
    else
    {
    write-exchangesetuplog -info „Skipping creating Discovery Arbitration Mailbox because of insufficient permission.“
    }
    }
    “ ausgeführt wurde: „Microsoft.Exchange.Data.DataValidationException: ‚Database‘ ist für ‚UserMailbox‘ verbindlich.
    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, Boolean reThrow)
    bei Microsoft.Exchange.Configuration.Tasks.DataAccessTask`1.Validate(TDataObject dataObject)
    bei Microsoft.Exchange.Configuration.Tasks.SetTaskBase`1.InternalValidate()
    bei Microsoft.Exchange.Configuration.Tasks.SetRecipientObjectTask`3.InternalValidate()
    bei Microsoft.Exchange.Management.Common.SetMailEnabledRecipientObjectTask`3.InternalValidate()
    bei Microsoft.Exchange.Management.RecipientTasks.SetUserBase`3.InternalValidate()
    bei Microsoft.Exchange.Management.RecipientTasks.SetMailboxBase`3.InternalValidate()
    bei Microsoft.Exchange.Management.RecipientTasks.SetMailbox.InternalValidate()
    bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
    bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.

    Reply

  5. Habe das Problem gefunden, mit Hilfe des Process Monitor.
    Konnte auf …\Exchange\Mialbox\address nicht zugreifen…
    Anschließend alles wie gewohnt durchgelaufen.

    Reply

  6. Habt Ihr einen Tip, wo ich die VersionsNummer von dem CU18 finde? Oder auch grundsätzlich für neue CUs?
    Srv01 Version 15.1 (Build 2106.2) habe ich als Ergebnis.

    Die Übersichten von MS scheinen nicht mehr gepflegt zu werden, womit mir die Verbindung CU18 zu Version und Build vom Exchange Server fehlt.

    Danke

    Reply

  7. Wir haben gestern das CU18 für Exchange 2016 installiert. Seither funktioniert unsere Outlook Suchfunktion nicht mehr. Hat hier jemand das gleiche Problem oder noch besser eine Lösung?

    Reply

  8. Hallo,
    bekomme beim Exchange 2016 CU18 Update diesen Fehler:

    Error:
    The following error was generated when „$error.Clear();
    buildToBuildUpgrade-ExsetdataAtom -AtomName SystemAttendant -DomainController $RoleDomainController

    “ was run: „Microsoft.Exchange.Management.Deployment.ExsetdataException: An error occurred with error code ‚3221684229‘ and message ‚Access is denied.‘.
    at Microsoft.Exchange.Configuration.Tasks.Task.ThrowTerminatingError(Exception exception, ErrorCategory category, Object target)
    at Microsoft.Exchange.Management.Deployment.ManageExsetdataAtom.HandleExsetdataReturnCode(UInt32 scErr)
    at Microsoft.Exchange.Management.Deployment.ManageExsetdataAtom.BuildToBuildUpgradeAtom(AtomID atomID)
    at Microsoft.Exchange.Management.Deployment.BuildToBuildUpgradeExsetdataAtom.InternalProcessRecord()
    at Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
    at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.

    Eventuell eine Idee was ich hier machen kann

    Reply

  9. Bei uns können nach dem EX 2016 CU18 die restlichen Outlook 2010 Clienten sich nicht mehr mit dem Server verbinden.
    „Keine Verbindung“ oder „Fehler beim Anmelden“. Da wir im Test vorher CU13 hatte und alles reibungslos klappte, muss irgendwas spezielles geändert worden sein. Alle neueren Outlooks ab 2013 bis 2019 haben kein Problem, auch OWA etc. klappt. Hat hier jemand eine Idee wo man suchen könnte?

    Reply

  10. Hallo Frank,

    kann man Exchange 2019 CU7 direkt als neuer Exchange Server installieren oder muss man irgendeine CU davor oder sogar die RTM vorher installieren?

    Dank und Gruß
    Tu

    Reply

  11. Hi,

    habe einen Exchange 2019 von CU5 auf CU7 ohne Probleme updaten können.
    Die User haben jetzt nur das Problem, das Mails im Outlook immer dieses „&nbsp“ in der Ansicht haben. Wenn man die Mails öffnet sieht alles normal aus.

    Haben die schon wieder was an der Kodierung geändert?

    Reply

    • Das haben wir auch bei Anwendern die mit Outlook 2010 ohne Cache Modus arbeiten. Ist der Cache Modus an sieht alles normal aus und wir habe Exchange 2016 CU18 im Einsatz. Bisher keine Lösung für unser Problem gefunden.

      Reply

  12. Exchange CU18 Installation lief fehlerfrei und die Server an sich auch.

    Aber:
    Wenn ich auf einem Verwaltungsserver bin (Nur die Management Tools installiert) und von dort mir die Warteschlange-Tolbox aufrufe und dann die Nachrichten ansehen möchte, stürzt die die MMC ab. Das passiert aber nicht auf einem Exchange Server sondern nur da wo allein die Tools laufen/installiert sind.

    Reply

  15. Hallo zusammen,

    ich habe das Update am Sonntag bei uns eingespielt. Wir haben seit dem folgendes Problem: Die Vorschaufunktion in OWA von PDFs ist buggy.
    Logge ich mich in OWA mit meinem Benuter ein und öffne eine Mail mit PDF Anhang, wird die Vorschau ganz normal angezeigt.
    Öffne ich jedoch ein weiteres Postfach im neuen Tab über die Funktion „ein weiteres Postfach öffnen“, funktioniert die Vorschau nicht mehr und der Download des Dokumtens ist ebenfalls defekt. Kann das jemand nachvollziehen?

    Ziemlich ärgerlich bei uns, da viele mit OWA arbeiten.

    Beste Grüße

    Reply

  17. Vielen Dank.
    Kann man mehrere CU’s überspringen? (konkret: Exchange2016 CU14 auf CU19)
    Und gibt es eine Anleitung, wie man bei einem Update von .net Framework vorgeht (im dag cluster).

    Reply

    • Moin Jürgen, ja dies ist möglich, versetze dazu einen Exchange Knoten in den Wartungsmodus.
      https://www.frankysweb.de/exchange-server-howto-zur-installation-von-updates/

      Anschließend musst du die Exchange Dienste auf diesen Knoten beenden und den Starttyp auf deaktiviert setzen.
      Nun kannst du die gewünschte supportete Version von .net Framework installieren.
      Wenn diese installiert ist, den Server einmal durchstarten und die Exchange Dienste wieder auf den Starttyp automatisch starten setzen.
      Das CU kann jetzt installiert werden, die Exchange Dienste werden vom Update automatisch gestartet.
      Nach dem Update den Wartungsmodus beenden und fertig.

      Reply

      • vor einiger Zeit hatten wir einen Case bei MS betreffs der Frage offen (jedoch zu Exchange 2013). „Wieviele CU’s überspringen empfiehlt MS“. Da hiess es, man solle nicht mehr als 2 CU’s im DAG überspringen.

        Reply

        • macht ja auch sinn. wir installieren jedes CU. bspw. wenn CU12 .net framework 4.8 nicht kann CU16, CU17 und CU18 aber .net framework 4.8 zwingend brauchen, dann hast ein gewisses problem. und ich glaub da ist es unabhängig ob DAG oder nicht DAG. vor allem Security Updates gibt es auch nur für die letzten 2 CUs.

  19. Gerade dabei das Sicherheitsupdate einzuspielen und dann taucht ein (gefühlt) eine Woche später das CU18 auf.
    Vielen Dank MS für die letzten Nachtschichten.

    MfG Paul

    Reply

    • Mimimi ;)

      Aber wenns tröstet, genau wie bei mir.
      Neu im MS Admingeschäft ? Willkommen !

      Mein Chef dazu: Nein, wir warten keine Woche mit nem kritischen Patch.
      Naja, ich lege dann die Wartung generell auf nach 20:00, dann krieg ich wenigstens Zulage ;)

      Rossi

      Reply

Leave a Comment