Neue Updates für Exchange Server (April 2022)

Microsoft hat am 20.04.2022 neue Updates für Exchange Server veröffentlicht. Die neues Updates bringen einige Neuerungen mit und enthalten alle bisher veröffentlichten Sicherheitsupdates. Hier geht es direkt zum Download:

Mit der Veröffentlichung der Updates ändert Microsoft auch die Art und Weise wie Exchange Updates bereitgestellt werden. Bisher wurden CUs für Exchange Server vierteljährlich veröffentlicht. Ab jetzt wird es nur noch zwei mal im Jahr neue CUs für Exchange Server 2019 geben. Exchange 2016 erhält kein neues CU mehr, sondern nur noch Sicherheitsupdates. Exchange 2016 befindet sich bereits in der erweiterten Supportphase und erhält daher keine neuen Funktionen mehr. Sicherheitsupdates sind von dieser Regel nicht betroffen, hier wird Microsoft die Updates wie gehabt bei Bedarf Updates für Exchange Server bereitstellen, damit nicht auf das nächste CU gewartet werden muss. Am Supportmodell ändert die halbjährliche Veröffentlichung der Updates nichts, es wird wie gehabt das vorangegangene CU und das aktuelle CU unterstützt.

Mit den April CUs werden UNC Pfade in verschiedenen Exchange Befehlen nicht mehr unterstützt, diese Änderung könnte Probleme mit einigen Scripten verursachen. Insbesondere Scripte, welche Zertifikate importieren oder exportieren sollten einmal überprüft werden. Die Befehle welche von dieser Änderung betroffen sind, finden sich hier:

Eine weitere wichtige Änderung ist, dass Exchange 2019 nun auch auf Windows Server 2022 unterstützt wird. Bisher musste Exchange 2019 auf Windows Server 2019 installiert werden. Neuinstallationen mit CU12 können nun direkt auf Windows Server 2022 durchgeführt werden.

Die beiden wohl wichtigsten Neuerungen betreffen Exchange Hybrid Installationen. In CU12 für Exchange 2019 ist wieder ein Product Key für Exchange Server 2019 enthalten. Wenn Exchange 2019 also nur zum verwalten der Office 365 Postfächer verwendet wird und keine Postfächer mehr lokal gespeichert werden, muss kein Exchange Server mehr separat lizenziert werden. In Exchange 2013 und Exchange 2016 war dies bereits der Fall, nun hat Microsoft dies auch für Exchange 2019 umgesetzt.

Mit CU12 muss nicht mehr zwingend ein Exchange Server für das Verwalten der Office 365 Postfächer betrieben werden. Die Exchange 2019 Verwaltungstools können nun separat und ohne die Mailboxrolle auf einem Server oder Workstation installiert werden. Somit kann Azure AD Connect für die Synchronisation der Benutzerkonten verwendetet werden, ohne dass ein Exchange Server on-Prem für die Verwaltung der Postfächer laufen muss. Der letzte Exchange Server darf aber nach wie vor nicht deinstalliert werden, da sonst AD-Objekte welche für die Verwaltung der Office 365 Postfächer erforderlich sind entfernt werden. Der letzte Exchange Server darf also nur runtergefahren, aber nicht deinstalliert werden. In diesem Artikel finden sich die Details:

Zu guter Letzt hier noch die Links zu den Änderungen der Updates:

Hier noch der Artikel auf dem Exchange Team Blog:

Neue Updates für Exchange Server (April 2022)

28 Gedanken zu „Neue Updates für Exchange Server (April 2022)“

  1. Auch noch eine interessante Info – Exchange 2019 CU12 bringt nun endlich den Support für Windows Server 2022 Domain Controller. Leider wurde der für Exchange 2016 nicht mehr nachgereicht. Wäre ja auch zu einfach gewesen…

    Antworten
  2. Hi Frank,

    Vielen Dank für die ausführlichen Infos.
    Wir haben ein klassisches, aber relativ neues AD ohne installierten onprem-Exchange. Wir syncen mit Azure Ad connect. Mailadressen und aliase pflegen wir momentan via Attribut Editor oder powershell.

    Könnten wir jetzt die management tools installieren ohne einen exchange onprem betreiben zu müssen?

    Oder gilt das nur für Szenarien, bei denen ein lokaler Exchange bereits existiert?

    Danke!
    Gruß Christoph.

    Antworten
  3. Exchange stirbt erfolgreich weiter den On-Premise-Tod. Der Plan geht auf. Es heißt nicht, dass ich traurig um ein verbuggtes, patchintensives Softwareprodukt bin.

    Antworten
    • Natürlich erhält der noch Security Updates.
      The next CU will be released in H2 of 2022, and it will be for Exchange Server 2019 only; mainstream support has ended for Exchange Server 2013 and Exchange Server 2016. We will release SUs as needed while those versions are in extended support.

      Antworten
  4. Ich habe soeben wie immer das Upate gestartet aber einen Fehler bekommen bei Schritt 14 von 18:

    Keine ahnung was der bedeutet…

    Fehler:
    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

    # Max trace folder size 50 * 100 = 5GB
    $null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚MaxTraceFileSize‘ -PropertyType ‚Dword‘ -Value 50 -Force
    $null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚MaxTraceFileCount‘ -PropertyType ‚Dword‘ -Value 100 -Force

    $null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚UseGeneralSwitch‘ -PropertyType ‚Dword‘ -Value 1 -Force
    $null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚GeneralSwitch‘ -PropertyType ‚Dword‘ -Value 0 -Force
    }
    catch
    {
    # ETl tracing is not critical. Info only log
    Write-ExchangeSetupLog -Info („An exception ocurred while trying to Configure the FAST ETL traces. Exception: “ + $_.Exception.Message);
    }

    try
    {
    $fastFusionRegKeyPath = ‚HKLM:\SOFTWARE\Microsoft\Office Server\16.0\Search\FlightControl‘

    if (Test-Path -Path $fastFusionRegKeyPath)
    {
    Remove-ItemProperty -Path $fastFusionRegKeyPath -Name ‚fusion_new_enabled‘ -Force -ErrorAction SilentlyContinue
    Remove-ItemProperty -Path $fastFusionRegKeyPath -Name ‚fusion_old_enabled‘ -Force -ErrorAction SilentlyContinue
    Remove-ItemProperty -Path $fastFusionRegKeyPath -Name ‚fusion_compare_outputs‘ -Force -ErrorAction SilentlyContinue
    }
    }
    catch
    {
    # Removing new fusion keys is not critical. Info only log
    Write-ExchangeSetupLog -Info („An exception ocurred while trying to remove the fast new fusion reg keys. Exception: “ + $_.Exception.Message);
    }

    $fastInstallConfigPath = Join-Path -Path $RoleBinPath -ChildPath „Search\Ceres\Installer“;
    $command = Join-Path -Path $fastInstallConfigPath -ChildPath „InstallConfig.ps1“;
    $dataFolderPath = Join-Path -Path $RoleBinPath -ChildPath „Search\Ceres\HostController\Data“;

    # Remove previous SearchFoundation configuration
    &$command -action u -silent;
    try
    {
    if ([System.IO.Directory]::Exists($dataFolderPath))
    {
    [System.IO.Directory]::Delete($dataFolderPath, $true);
    }
    }
    catch
    {
    $deleteErrorMsg = „Failure cleaning up SearchFoundation Data folder. – “ + $dataFolderPath + “ – “ + $_.Exception.Message;
    Write-ExchangeSetupLog -Error $deleteErrorMsg;
    }

    # Re-add the SearchFoundation configuration
    try
    {
    # the BasePort value MUST be kept in sync with dev\Search\src\OperatorSchema\SearchConfig.cs
    &$command -action i -baseport 3800 -dataFolder $dataFolderPath -silent;
    }
    catch
    {
    $errorMsg = „Failure configuring SearchFoundation through installconfig.ps1 – “ + $_.Exception.Message;
    Write-ExchangeSetupLog -Error $errorMsg;

    # Clean up the failed configuration attempt.
    &$command -action u -silent;
    try
    {
    if ([System.IO.Directory]::Exists($dataFolderPath))
    {
    [System.IO.Directory]::Delete($dataFolderPath, $true);
    }
    }
    catch
    {
    $deleteErrorMsg = „Failure cleaning up SearchFoundation Data folder. – “ + $dataFolderPath + “ – “ + $_.Exception.Message;
    Write-ExchangeSetupLog -Error $deleteErrorMsg;
    }
    }

    # Set the PowerShell Snap-in’s public key tokens
    try
    {
    $PowerShellSnapinsPath = „HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\“;
    $FastSnapinNames = @(„EnginePSSnapin“, „HostControllerPSSnapIn“, „InteractionEnginePSSnapIn“, „JunoPSSnapin“, „SearchCorePSSnapIn“);
    $officePublicKey = „71E9BCE111E9429C“;
    $exchangePublicKey = „31bf3856ad364e35“;
    foreach ($fastSnapinName in $FastSnapinNames)
    {
    $fastSnapinPath = $PowerShellSnapinsPath + $fastSnapinName;
    $assemblyNameProperty = Get-ItemProperty -Path $fastSnapinPath -Name „AssemblyName“ -ErrorAction SilentlyContinue;
    if ($assemblyNameProperty -ne $null -and (-not [string]::IsNullOrEmpty($assemblyNameProperty.AssemblyName)))
    {
    $newAssemblyName = $assemblyNameProperty.AssemblyName -ireplace ($officePublicKey, $exchangePublicKey);
    Set-ItemProperty -Path $fastSnapinPath -Name „AssemblyName“ -Value $newAssemblyName;
    }
    }
    }
    catch
    {
    # Info only log
    Write-ExchangeSetupLog -Info („An exception ocurred while configuring Search Foundation PowerShell Snapin. Exception: “ + $_.Exception.Message);
    }
    }
    “ ausgeführt wurde: „System.Exception: Failure configuring SearchFoundation through installconfig.ps1 – Error occurred while configuring Search Foundation for Exchange.System.TimeoutException: Dieser an net.tcp://svraigex.aigner.loc:3803/Management/AdminService gesendete Anforderungsvorgang hat innerhalb des konfigurierten Zeitlimits (00:01:00) keine Antwort empfangen. Der für diesen Vorgang zugewiesene Zeitraum war möglicherweise ein Teil eines längeren Timeouts. Mögliche Ursachen: Der Dienst verarbeitet den Vorgang noch, oder der Dienst konnte keine Antwortnachricht senden. Erwägen Sie, das Zeitlimit für den Vorgang zu erhöhen (indem Sie den Kanal/Proxy in IContextChannel umwandeln und die OperationTimeout-Eigenschaft festlegen), und stellen Sie sicher, dass der Dienst eine Verbindung mit dem Client herstellen kann.

    Server stack trace:
    bei System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
    bei System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
    bei System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
    bei System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

    Exception rethrown at [0]:
    bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
    bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
    bei Microsoft.Ceres.CoreServices.Admin.IAdminServiceManagementAgent.UpdateConfiguration()
    bei Microsoft.Ceres.Exchange.PostSetup.NodeManager.AddNodeAndUpdateConfiguration(String node)
    bei Microsoft.Ceres.Exchange.PostSetup.NodeManager.DeployIndexNode()
    bei Microsoft.Ceres.Exchange.PostSetup.DeploymentManager.Install(String installDirectory, String dataDirectoryPath, Int32 basePort, String logFile, Boolean singleNode, String systemName, Boolean attachedMode)
    bei CallSite.Target(Closure , CallSite , Type , Object , Object , Object , Object , Object , Object , Boolean )
    bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
    bei Microsoft.Exchange.Management.Deployment.WriteExchangeSetupLog.InternalProcessRecord()
    bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
    bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.

    Antworten
  5. Ich habe danach das System Neugestartet und das Setup nochmal ausgeführt.
    Das System hat erkannt Update war fehlerhaft und Startet eine Rep. bzw. macht weiter.

    Insgesamt 11 Schritte.

    Nach d. Schritt 11 hat sich das Update Fenster einfach geschlossen.

    Aber nach dem Upate war ein Senden und Empfangen der E-Mails möglich.
    ECP und OWA erreichbar.
    Neustart ausgeführt

    ECP Login Fehler 500 Unerwarteter Fehler sowie in OWA.

    Habe daher:
    cd $exinstall
    cd .\Scripts\
    UpdateCas.ps1

    Danach das System Neugestartet
    Leider hat das nichts gebracht.

    Die OWA und ECP pfade passen zugriff via Exchnage Mgmt Shell habe ich auch.

    Wo liegt d. da der fehler !!

    Antworten
  6. Habe noch einmal in googel gesucht und diesen Befehl abgesezt.
    ECP, OWA läuft wieder.

    C:\Windows\system32>lodctr /r

    Info: Die Leistungsindikatoreinstellung konnte erfolgreich aus dem Systemsicherungsspeicher neu erstellt werden.
    C:\Windows\system32>iisreset

    Es wird versucht, den Dienst zu beenden…
    Internetdienste wurden erfolgreich beendet.
    Es wird versucht, den Dienst zu starten…

    Antworten
    • Nein. Inplace Upgrades gabs und gibts derzeit nicht. Steht übrigens auch in den Kommentaren im EHLO Blog bei MS.

      Antworten
  7. Auf einem einzelnen Domänen-Mitgliedsserver Exchange-Server 2016 Standard CU22 15.1.2375.24 mit neuesten Windows Updates erscheint bei dem Installationsversuch des Kumulativen Updates CU23 KB5011155 bei Schritt 17 von 18 eine Fehlermeldung. Ich habe den Server vorerst rückgesetzt auf den Zustand vor CU23. Das in der Fehlermeldung aufgeführte Zertifikat ist das aktuell genutzte Let’s Encrypt Zertifikat, welches noch bis 14.07.2022 gültig ist. Wer hat Lösungsvorschläge?

    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 A36E14805AAA54197ED33072DDF0DB23B4C75EBC 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
    • Hallo Platon,
      bei Verwendung von Let’s Encrypt wird so ein Fehler bei einem CU Update immer auftreten, auch nach einem bekannten Lösungsvorschlag in Verbindung mit dem schreibgeschützten Zertifikat.
      Geht aber einfach zu lösen, bei mir zumindest.
      Wähle das Zertifikat im IIS für HTTPS ab und setzte bsw. das interne Exchange Zertifikat, danach ein IIS Reset oder Neustart, während der Instl. aus.
      Starte das Setup erneut und es instl. automatisch weiter. Nach Abschluß der Instl. wird sich das Setupfenster einfach ohne Kommentar usw. schließen. Wähle anschließend im IIS für HTTPS wieder das Let’s Encrypt Zertifikat aus und führe ein Neustart aus. Prüfe anschließen alle Dienste und wenn alle gestartet sind, autmatisch oder manuell, müsste alles wieder funktionieren. War zumindest bei mir so nach jedem CU Update. Viel Erfolg!

      Antworten
      • Ja OK werde ich in 2 Wochen so testen. Bisher gab es mit Let’s Encrypt Zertifikat keine Probleme. Ich habe zuvor mehrere CU Updates problemlos mit Let’s Encrypt Zertifikat installiert. Jetzt mit CU23 das erste Mal, dass es nicht mit Let’s Encrypt geklappt hat.

        Antworten
      • Mittlerweile konnte ich CU23 ganz normal auch mit einen neu generierten Lets Encrypt Zertifikat installieren. Es war nicht notwendig, zeitweise auf ein anderes Zertifikat umzustellen. Vor der Installation von CU23 mussten alle Windows und Exchange Updates installiert werden, dann CU23 und abschließend noch das letzte Sicherheitsupdate für CU23.

        Antworten
    • Install-AuthCertificate -DomainController $RoleDomainController

      Ist dein Auth-Cert evtl. abgelaufen? „Zurücksetzen“ eines Exchange klingt für mich irgendwie immer, als wäre das ein Snapshot. Wär mir schon wegen der ggf. auftretenden Datenkonsistenz nie in den Sinn gekommen. :)

      Antworten
      • Das Zertifikat „Microsoft Exchange Server Auth Certificate“ ist noch bis 20.08.2024 gültig. Sowohl Exchange-Server als auch Active Directory Server sind beide virtualisiert mittels Hyper-V und ich sichere diese vor Einspielen von Updates oder bestimmten Änderungen. Nachdem die Installation von Exchange-Server CU23 fehlgeschlagen war habe ich beide rückgesetzt auf den Stand vor dem Installationsversuch von CU23. Die Exchange-Server Datenbanken sind auf einer separaten virtuellen Festplatte, so dass ich vom Exchange-Server lediglich Laufwerk C: mit Betriebssystem und sämtlicher Software rückgesetzt habe, nicht jedoch die Exchange-Server-Datenbanken.

        Antworten
      • …und keine Snapshots, sondern ich fahre die jeweiligen Server herunter, sichere / ersetze die jeweiligen virtuellen Festplatten und starte danach die Server wieder. So lassen sich monatlich die entsprechenden Serversicherungen auf externen Festplatten in mehreren Generationen an unterschiedlichen Standorten entsprechend archivieren.

        Antworten
  8. Hi,

    hat bei mir geklappt. EX 2016 CU22 alle Updates drin und dann auf CU23. Ob es wirklich das letze CU für den 2016 ist wird sich zeigen ;-).
    WildCard Zertifikat.

    Antworten
  9. Hallo Lanwolf,
    Danke für die Info. Ich wollte mich mal erkundigen wie die Installation von CU23 auf Exchange 2016 klappt. Da ich nun schon mehrfach von Fehlern gelesen habe bin ich da etwas unsicher.

    Wie lief es denn bei euch?

    Antworten
    • Gestern Abend installiert. Lief ohne Probleme durch. Alles scheint bisher zu funktionieren.

      Exchange 2016 kein DAG

      Gruß

      Antworten
  10. Wir haben nach dem Update von einem Exchange 2016 das Problem das die Suche bei den Clients nicht funktioniert.
    Einen neuen Index haben wir bereits erstellt, sowie die beiden Such Dienste überprüft ( ob deaktiviert). Owa usw. funktionieren ohne Probleme
    Bin da jetzt mittlerweile ein wenig ratlos. Das Update lief ohne Probleme . Hat jemand auch diese Problematik?

    Antworten
  11. Hi @all,

    Ich habe soeben bemerkt via IIS.
    OWA und ECP bei Bindungen:

    https://localhost:444/ecp
    Outlook
    400

    Ungültige Anforderung

    Die vom Browser gesendete Anforderung war ungültig.

    Office

    https://localhost:444/owa

    Die Webseite wurde nicht gefunden

    HTTP 400

    Wahrscheinlichste Ursachen:
    •Die Adresse enthält eventuell einen Tippfehler.
    •Der Link, auf den Sie geklickt haben, ist eventuell nicht mehr aktuell.

    Mögliche Vorgehensweise:

    Geben Sie die Adresse erneut ein.

    Gehen Sie zur vorherigen Seite.

    Wechseln Sie zur und suchen Sie dort nach den gewünschten Informationen.

    Weitere Informationen Weitere Informationen

    Was ist hier falsch ?
    Der Normale Webzugang via Hostname ECP und OWA funktioniert.

    Antworten
  12. @Darksniper, ich möchte dir nicht zu nahe treten, aber ich denke du machst besser ein Ticket auf oder fragst einen Dienstleister. ein einfaches C&P von Fehlermeldungen ist nicht wirklich zielführend und da wird Hilfe unmöglich, da das Problem nicht wirklich abgrenzbar ist.

    Gruß Final

    Just my 2 ct

    Antworten
  13. Hallo allerseits,
    haben einen Windows Server 2016 mit Exchange Server 2019. Das neue CU 12 wurde installiert. Soweit so gut.
    AMSI Schutz wurde schon deaktiviert.

    Nun haben die Outlooks eine Reaktionszeit von 3000 ms pro Postfach. Somit kann man Outlook vergessen. Es ist einfach so langsam.
    OWA ohne Probleme.

    Kennt einer das Ereignis?

    LG

    Antworten
  14. Hallo Jungs und Mädels,

    wollte nun bei unserem einzigen Exchange Server 2016 das anscheinend letzte CU (CU23) installieren.
    Beim Vorbereiten der Organisation bricht das Setup mit Fehler ab:

    The following error was generated when „$error.Clear();
    initialize-ExchangeUniversalGroups -DomainController $RoleDomainController -ActiveDirectorySplitPermissions $RoleActiveDirectorySplitPermissions

    “ was run: „System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    bei Microsoft.Exchange.Management.Tasks.InitializeExchangeUniversalGroups.CreateOrMoveEWPGroup(ADGroup ewp, ADOrganizationalUnit usgContainer)
    bei Microsoft.Exchange.Management.Tasks.InitializeExchangeUniversalGroups.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()“.
    [06.05.2022 12:30:08.0326] [1] [ERROR] Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    [06.05.2022 12:30:08.0331] [1] [ERROR-REFERENCE] Id=443949901 Component=
    [06.05.2022 12:30:08.0332] [1] Setup is stopping now because of one or more critical errors.

    Bereits vier Mal versucht nach mehrmaligen Neustarts. Updates auf dem Windows Server 2016 sind alle eingespielt, ebenso auf den drei DC2, ebenfalls 2016er.

    Änderungen am AD, insbesondere OUs hat’s die letzten zwei, drei Monate sicher nicht gegeben.

    Ich komme nicht weiter. In artverwandten Threads wird immer wieder von „WellknownObject“ gesprochen; den Hinweis gibt’s in der Fehlermeldung nicht.
    Auch wundert mich der Zeitstempel im Log: Das Setup wurde um 14.27 Uhr gestartet und nicht um 12.27 Uhr wie es im Log steht.
    Uhrzeit ist auf dem Server und den DCs sowie der gesamten Domäne korrekt.
    Blick nicht was das soll.
    Hat da einer von Euch einen hilfreichen Hinweis?
    Vielen Dank.

    Antworten
  15. Ich habe dieses Mal richtig Spaß!!! Offenbar hat das Setup es hinbekommen das die AD nicht mehr gefunden wird.

    [07.07.2022 01:37:09.0271] [0] [ERROR] Setup encountered a problem while validating the state of Active Directory: Der Active Directory-Server ist nicht verfügbar. Fehlermeldung: Active Directory-Antwort: Der LDAP-Server ist nicht verfügbar. See the Exchange setup log for more information on this error.
    [07.07.2022 01:37:09.0416] [0] [ERROR] Active Directory server is not available. Error message: Active Directory-Antwort: Der LDAP-Server ist nicht verfügbar.
    [07.07.2022 01:37:09.0417] [0] [ERROR] Der LDAP-Server ist nicht verfügbar.
    [07.07.2022 01:37:09.0424] [0] Setup will use the domain controller “.
    [07.07.2022 01:37:09.0425] [0] Setup will use the global catalog “.
    [07.07.2022 01:37:09.0467] [0] No Exchange configuration container was found for the organization. Message: ‚Der Active Directory-Server ist nicht verfügbar. Fehlermeldung: Active Directory-Antwort: Der LDAP-Server ist nicht verfügbar.‘.

    Wärend der weiteren Installation, macht das Setup trotz der ganzen Fehler einfach fröhlich weiter:

    [07.07.2022 01:38:15.0496] [0] Setup will run the task ‚test-SetupPrerequisites‘
    [07.07.2022 01:38:15.0496] [1] Setup launched task ‚test-SetupPrerequisites -DomainController $null -ExchangeVersion ‚15.1.2507.6‘ -Roles ‚LanguagePacks‘,’FrontendTransport‘,’Cafe‘ -ScanType ‚PrecheckUpgrade‘ -SetupRoles ‚LanguagePacks‘,’AdminTools‘,’FrontendTransport‘,’Cafe‘ -TargetDir ‚D:\Exchange Server‘ -ADInitError ‚Problem beim Überprüfen des Status von Active Directory: Der Active Directory-Server ist nicht verfügbar. Fehlermeldung: Active Directory-Antwort: Der LDAP-Server ist nicht verfügbar. Im Exchange-Setupprotokoll finden Sie weitere Informationen zu diesem Fehler.‘ -LanguagePackDir ‚F:\‘ -LanguagesAvailableToInstall $true -SufficientLanguagePackDiskSpace $true -LanguagePackVersioning $true -HostingDeploymentEnabled $false‘
    [07.07.2022 01:38:15.0521] [1] Die Active Directory-Sitzungseinstellungen für ‚test-SetupPrerequisites‘ lauten: Vollständige Gesamtstruktur anzeigen: ‚True‘,
    [07.07.2022 01:38:15.0521] [1] User specified parameters: -Roles:’LanguagePacks‘,’FrontendTransport‘,’Cafe‘ -LanguagesAvailableToInstall:’True‘ -DomainController:$null -ExchangeVersion:’15.1.2507.6′ -LanguagePackDir:’F:\‘ -SufficientLanguagePackDiskSpace:’True‘ -ADInitError:’Problem beim Überprüfen des Status von Active Directory: Der Active Directory-Server ist nicht verfügbar. Fehlermeldung: Active Directory-Antwort: Der LDAP-Server ist nicht verfügbar. Im Exchange-Setupprotokoll finden Sie weitere Informationen zu diesem Fehler.‘ -ScanType:’PrecheckUpgrade‘ -LanguagePackVersioning:’True‘ -HostingDeploymentEnabled:’False‘ -TargetDir:’D:\Exchange Server‘ -SetupRoles:’LanguagePacks‘,’AdminTools‘,’FrontendTransport‘,’Cafe‘
    [07.07.2022 01:38:15.0521] [1] Beginning processing test-SetupPrerequisites

    Das geht immer so weiter… Offenbar fehlt jetzt komplett die Verbindung zur AD/DC. Im DNS habe ich plötzlich ganz viele IPV6 Adressen.

    Ich habe grade keine Lösungsansätze, die AD läuft einwandfrei. Ideen?

    Antworten

Schreibe einen Kommentar