Microsoft hat heute für Exchange 2016 und Exchange 2019 neue Cumulative Updates (CU) veröffentlicht:
- Exchange Server 2019 Cumulative Update 7 (KB4571787), VLSC Download
- Exchange Server 2016 Cumulative Update 18 (KB4571788), Download,
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.
Hat jemand den OU Picket in der /clientaccess/ecp/web.conf angepasst? Das scheint in CU 18 nicht mehr zu funktionieren
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!
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.
Das würde mich auch interessieren, schon ein Unding, habe diesbezüglich mit 365 nie was gemacht, warum wird das nach einem Update umgestellt. Oder leitet MS direkt alles zum 365 weiter und durch den Patch hat man ein Fehler gemacht und aufgedeckt. Sehr fragwürdig. Habe keine Lösung bis jetzt gefunden, auch keine Einstellung gesehen.
https://support.microsoft.com/en-us/help/4588297/attachments-not-downloaded-or-previewed-from-owa
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)“.
Hallo Ulli,
siehe hier:
https://www.frankysweb.de/exchange-2016-fehler-bei-der-installation-migration-database-ist-fuer-usermailbox-verbindlich/
Gruß,
Frank
PS: Bitte das nächste Mal ins Forum. Danke.
Habe das Problem gefunden, mit Hilfe des Process Monitor.
Konnte auf …\Exchange\Mialbox\address nicht zugreifen…
Anschließend alles wie gewohnt durchgelaufen.
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
Habt Sie selbst gefunden: https://docs.microsoft.com/de-de/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2016
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?
Lösung gefunden: https://social.technet.microsoft.com/wiki/contents/articles/31215.exchange-2013-fast-search-technology-failed.aspx
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
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?
Hallo Oliver,
hast du TLS 1.2 am Client aktiviert?
Gruß,
Frank
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
ja, man kann, hat sich somit erledigt. Danke.
Hallo Tu,
du kannst direkt das CU7 zur Installation nutzen.
Gruß,
Frank
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 „ “ in der Ansicht haben. Wenn man die Mails öffnet sieht alles normal aus.
Haben die schon wieder was an der Kodierung geändert?
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.
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.
Vielen Dank für die Info.
Direkt mal einplanen das CU einzuspielen
Upgrade von Exchange 2019 CU5 lief problemlos.
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
Exchange 2016 sollte ich noch hinzufügen ;)
Bei unserem Server genau das selbe.
Sobald man ein weiteres Postfach aufmacht, betrifft alle Anhänge und integrierte Bilder.
Wenn man versucht die Anhänge downloaden verlinkt er auf https://outlook.office365.com/owa/… Mail Adresse
Ich habe auf dem Server nichts mit Office365 und auch so haben wir damit nichts zu tun.
Zudem ist, nachdem Update die komplette Suche buggy, alles voller Fehler im Fehlerprotokoll
was mit der Search auf dem Exchange zu tun hat. Windows Server 2012 R2 alle Updates mit Exchange 2016.
Das selbe Problem mit pdf Anhaenge (OS 2016/Exchange 2016). Have Search noch nicht untersucht.
Jo, hier auch selbes Bild bei den pdfs
Das selbe auch bei uns.
Exchange 2016 CU18
Hallo zusammen,
also bei uns funktioniert es. gestern extra getestet. pdf im preview angezeigt, da wird bei uns word online gestartet vom oos der im edit mode eingerichtet ist und in owa dürfen nur attachments über oos angesehen und editiert werden. downloaden ist gesperrt. dann dieses pdf an shared mailbox gemailt. shared mailbox im owa geöffnet und preview von dem pdf wurde angezeigt. keine ahnung ob das ein guter test ist.
lg,
mom20xx
Dito, sehr ärgerlich
Gleiches Problem hier unter Exchange 2019 nach dem Einspielen des neuesten CU!
Gleiches Problem auch bei uns, Exchange 2016 CU18. Öffnet auch in der Preview nach Öffnen des weiteren Postfachs „…outlook.office365.com“
Hat wer einen guten Draht zu Microsoft und könnte da einen Bugreport oder so aufmachen? Scheint tatsächlich bei allen aufzutreten.
Moins,
hat jemand jetzt schon einen Fall aufgemacht?
lg Olli
Workaround von MS
https://support.microsoft.com/en-us/help/4588297/attachments-not-downloaded-or-previewed-from-owa
Habe das CU (EXCH2016) gestern eingespielt. Bisher ohne Probleme.
Gruß
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).
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.
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.
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.
Hallo Paul,
das ist aber immer so, dass ca. 1 Woche nach den SUs die CUs kommen, zumindest in dem 3 Monatsplan.
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
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