Neue Updates für Exchange Server (April 2022)

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

1. 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

2. 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

3. 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

4. @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

5. 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

6. 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

7. 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

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. 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

10. Wie siehts aus wenn der Exchange auf CU12 geupdated wurde, ist dann ein InplaceUpgrade auf Windows Server 2022 möglich?

    Antworten

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

      Antworten

11. 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

12. 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

13. 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

14. Nach der Installation von CU 23 auf einem Exchange 2016 ist die „Admin EAC“ nach dieser Anleitung nicht mehr erreichbar (HTTP 400): https://www.frankysweb.de/exchange-2016-eac-nur-im-internen-netzwerk-freigeben/
    Hat jemand ebenfalls dieses Problem?

    Antworten

15. Bekommt denn der CU22 (Exchange 2016) weiterhin SUs (Security Updates), oder nur noch der CU23?

    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

16. 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

17. 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

    • Ja genau die Frage is bei ms im teamblog schon beantwortet in den Kommentaren.

      Antworten

18. 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