Reparieren fehlgeschlagener Installationen von kumulativen Updates (CU) und Sicherheitsupdates (SU) von Exchange

  • Artikel
  • Gilt für::
    Exchange Server 2019, Exchange Server 2016, Exchange Server 2013, Exchange Server 2010 Service Pack 3

In diesem Artikel werden die Methoden zum Überprüfen der Installation von kumulativen Updates (Cumulative Updates, CUs) und Sicherheitsupdates (Security Updates, SUs) von Microsoft Exchange Server auf Ihren Servern beschrieben, bekannte Probleme aufgeführt, die bei der Installation von CUs und SUs auftreten können, und Lösungen zum Beheben der Probleme beschrieben.

Beheben von Fehlern bei der CU- oder SU-Installation

Weitere Informationen

HTTP 500-Fehler in OWA oder ECP

Problem:

HTTP 500-Fehler können in Outlook im Web (OWA) und in der Exchange-Systemsteuerung (ECP) auftreten, nachdem Updates installiert wurden. Nachdem Sie die Anmeldeinformationen für die Anmeldung bei OWA oder ECP angegeben haben, schlägt der Anmeldevorgang möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl:

Die Datei oder Assembly „Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35“ oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die angegebene Datei wurde nicht gefunden.

Lösung:

Installieren Sie an einer Eingabeaufforderung mit erhöhten Rechten das Sicherheitsupdate erneut.

  1. Wählen Sie Start aus, und geben Sie cmd ein.
  2. Klicken Sie in den Suchergebnissen mit der rechten Maustaste auf Eingabeaufforderung, und wählen Sie Als Administrator ausführen aus.
  3. Wenn das Fenster Benutzerkontensteuerung angezeigt wird, wählen Sie die Option zum Öffnen eines Eingabeaufforderungsfensters mit erhöhten Rechten aus, und klicken Sie dann auf Weiter. Wenn das UAC-Fenster nicht angezeigt wird, fahren Sie mit dem nächsten Schritt fort.
  4. Geben Sie den vollständigen Pfad der MSP-Datei für das Sicherheitsupdate ein, und drücken Sie die EINGABETASTE .
  5. Nachdem das Update installiert wurde, starten Sie den Server neu.

Weitere Informationen finden Sie unter OWA oder ECP funktioniert nach der Installation eines Sicherheitsupdates nicht mehr.

Zurück zum Anfang

HTTP 400-Fehler in OWA und ECP sowie Verbindungsfehler in PowerShell

Problem:

HTTP 400-Fehler können in Outlook im Web (OWA) und in der Exchange-Systemsteuerung (ECP) auftreten, nachdem Updates installiert wurden. Nachdem Sie die Anmeldeinformationen für die Anmeldung bei OWA oder ECP angegeben haben, schlägt der Anmeldevorgang möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl:

HTTP 400 – schlechte Anfrage
Kontext kann nicht serialisiert werden

Auch wenn Sie die Exchange-Verwaltungsshell starten, wird die folgende Fehlermeldung angezeigt:

FehlerCode : -2144108477
Übermittlungsnachricht: Der WS-Management Service kann die Anfrage nicht bearbeiten, da die XML ungültig ist.
Fehlerbericht: Die Verbindung mit dem Remoteserver exchange.contoso.com ist mit der folgenden Fehlermeldung fehlgeschlagen: Weitere Informationen finden Sie im Hilfethema about_Remote_Troubleshooting.

Ursache:

Dieses Problem tritt auf, wenn der Benutzername mit einem Dollarzeichen ($) endet, z.B. admin$.

Lösung:

Entfernen Sie das Dollarzeichen ($) aus dem Benutzernamen oder verwenden Sie ein anderes Administratorkonto, das nicht mit einem Dollarzeichen ($) endet.

Zurück zum Anfang

Fehlende Bilder in ECP

Problem:

Nach der Installation des SU zeigen OWA oder ECP möglicherweise keine Bilder an.

Ursache:

Dieses Problem tritt auf, wenn das SU nicht ordnungsgemäß installiert ist.

Lösung:

Deinstallieren und installieren Sie die MSP-Datei erneut, indem Sie das Update an einer Eingabeaufforderung als Administrator ausführen. Starten Sie nach Abschluss der Installation den Server neu.

Zurück zum Anfang

Leere Seite in EAC oder OWA

Problem:

Eine leere Seite wird angezeigt, wenn Sie sich beim Exchange Admin Center (EAC) oder OWA über Exchange Server 2016 oder Exchange Server 2013 anmelden. Wenn dieses Problem auftritt, wird möglicherweise die Ereignis-ID 15021 protokolliert.

Ursache:

Dieses Problem tritt auf, wenn es bei der SSL-Bindung an 0.0.0.0:444 eines oder mehrere der folgenden Probleme gibt:

  • Die Bindung wurde nicht ordnungsgemäß installiert.
  • Der Bindung wurde kein Zertifikat zugewiesen.
  • Die Bindung enthält falsche Informationen.

Lösung:

  1. Öffnen Sie auf dem Clientzugriffsserver (Client Access Server, CAS) die Internetinformationsdienste (Internet Information Services, IIS).

  2. Erweitern Sie Sites, klicken Sie auf Standardwebsite, und klicken Sie dann im Bereich Aktionen auf Bindungen.

  3. Öffnen Sie im Dialogfeld Seitenbindung die Bindung für die folgenden Werte:
    Type: https; Port: 443.

  4. Überprüfen Sie, ob ein gültiges SSL-Zertifikat für die Standardwebsite angegeben ist. Wenn dies nicht der Fall ist, geben Sie ein gültiges SSL-Zertifikat wie etwa Microsoft Exchange an, und klicken Sie auf OK.

    Screenshot, der zeigt, dass Microsoft Exchange als SSL-Zertifikat für die SSL-Bindung für die Standardwebsite ausgewählt ist.

  5. Führen Sie den folgenden Befehl in einem PowerShell-Fenster mit erhöhten Rechten aus, um IIS neu zu starten:

    Restart-Service WAS,W3SVC

  6. Führen Sie auf dem Postfachserver die Überprüfungsschritte 1 bis 5 für die Exchange-Back-End-Site aus.

    Screenshot, der zeigt, dass Microsoft Exchange als SSL-Zertifikat für die SSL-Bindung für die Exchange-Back-End-Website auf dem Postfachserver ausgewählt ist.

Weitere Informationen finden Sie in diesem Artikel.

Zurück zum Anfang

Anmeldung bei OWA oder EAC nicht möglich

Problem:

Wenn Sie versuchen, sich bei OWA oder der EAC in Exchange Server anzumelden, reagiert der Webbrowser nicht mehr, oder es wird eine Meldung angezeigt, dass das Umleitungslimit erreicht wurde. Darüber hinaus wird das Ereignis 1003 in der Ereignisanzeige protokolliert.

Ereigniskennung: 1003 Quelle: MSExchange Front End HTTPS Proxy Interner Serverfehler. Nicht behandelte Ausnahme: System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. unter Microsoft.Exchange.HttpProxy.FbaModule.ParseCadataCookies(HttpApplication httpApplication)

Ursache:

Dieses Problem tritt auf, weil das OAuth-Zertifikat (Exchange Server Open Authentication) abgelaufen ist.

Lösung:

Führen Sie die Schritte in diesem Artikel aus, um das Problem zu beheben.

Zurück zum Anfang

Nach der Exchange-Installation kann nicht auf EAC oder OWA zugegriffen werden

Problem:

Bei der Installation von Exchange Server 2016 oder Exchange Server 2013 ist der Installationsvorgang möglicherweise fehlgeschlagen, oder er wurde zu einem bestimmten Zeitpunkt unterbrochen, dann fortgesetzt und schließlich erfolgreich abgeschlossen. Wenn Sie jedoch versuchen, auf EAC oder OWA zuzugreifen, wird die folgende Fehlermeldung angezeigt:

Leider hat etwas nicht geklappt

Diese Informationen können wir momentan nicht abrufen. Wiederholen Sie den Vorgang zu einem späteren Zeitpunkt. Wenden Sie sich an den Helpdesk, wenn das Problem weiterhin auftritt.

Ursache:

Dieses Problem tritt auf, wenn die Datei „SharedWebConfig.config“ an einem der folgenden Speicherorte fehlt:

  • C:\Programme\Microsoft\Exchange Server\V15\ClientAccess
  • C:\Programme\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy

Lösung:

Gehen Sie wie folgt vor:

  1. Identifizieren Sie auf dem Server, auf dem der Fehler auftritt, den Speicherort, an dem die Datei „SharedWebConfig.config“ fehlt.

  2. Generieren Sie die fehlende Datei:

    1. Führen Sie cd %ExchangeInstallPath%\bin aus, um das aktuelle Verzeichnis in den Ordner „bin“ zu ändern, der sich unter dem Exchange-Installationspfad befindet.

    2. Verwenden Sie das Tool „DependentAssemblyGenerator.exe“, um die Datei entsprechend zu generieren:

      • Wenn die Datei in C:\Programme\Microsoft\Exchange Server\V15\ClientAccess fehlt, führen Sie den folgenden Befehl aus:
      DependentAssemblyGenerator.exe -exchangePath "%ExchangeInstallPath%\bin" -exchangePath "%ExchangeInstallPath%\ClientAccess" -configFile "%ExchangeInstallPath%\ClientAccess\SharedWebConfig.config"
      • Wenn die Datei in C:\Programme\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy fehlt, führen Sie den folgenden Befehl aus:
      DependentAssemblyGenerator.exe -exchangePath "%ExchangeInstallPath%\bin" -exchangePath "%ExchangeInstallPath%\FrontEnd\HttpProxy" -configFile "%ExchangeInstallPath%\FrontEnd\HttpProxy\SharedWebConfig.config"

  3. Starten Sie den Server neu, oder öffnen Sie eine PowerShell-Sitzung mit erhöhten Rechten, und führen Sie den folgenden Befehl aus:

    Restart-Service WAS,W3SVC

    Weitere Informationen finden Sie in diesem Artikel.

Zurück zum Anfang

Setup von Exchange Server wird nicht ausgeführt

Problem:

Sie führen eine unbeaufsichtigte Installation aus, um Microsoft Exchange Server 2019, Microsoft Exchange Server 2016 oder Microsoft Exchange Server 2013 mithilfe von „setup.exe“ über PowerShell oder die Eingabeaufforderung zu aktualisieren. Das Setupprogramm wird gestartet und zeigt möglicherweise an, dass es erfolgreich abgeschlossen wurde. Exchange wird jedoch nicht aktualisiert.

Das Installationsmedium befindet sich auf Laufwerk D: und die unbeaufsichtigte Installation wird mit einem der folgenden Befehle gestartet:
„setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms“ (aus der PowerShell oder der Eingabeaufforderung) anstelle von
„.\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms“ (aus der PowerShell) oder
„D:\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms“ (aus der PowerShell oder der Eingabeaufforderung).

Ursache:

Wenn Sie einen Befehl in PowerShell oder an der Eingabeaufforderung ausführen, werden zuerst die Pfade in der Systemumgebungsvariablen „Path“ geprüft, um den auszuführenden Befehl zu überprüfen, bevor der aktuelle Pfad in PowerShell oder die Eingabeaufforderung überprüft wird. Diese Überprüfungsreihenfolge wird befolgt, es sei denn, die folgenden Bedingungen sind erfüllt:

  • "." wird vor dem Befehl oder Programm eingegeben, das in PowerShell ausgeführt wird.
  • Die Tab-Taste wird verwendet, um vor dem in PowerShell ausgeführten Befehl oder Programm automatisch "." hinzuzufügen.
  • Der vollständige Pfad wird verwendet, um „setup.exe“ (z. B. „D:\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms“) in PowerShell oder an der Eingabeaufforderung auszuführen.

In Abwesenheit dieser Bedingungen wird eine andere „setup.exe“-Datei, die sich in C:\Program Files\Microsoft\Exchange Server\V15\bin befindet, gefunden und von PowerShell anstelle der „setup.exe“-Datei im richtigen Pfad ausgeführt.

Lösung:

Führen Sie das Upgrade mit „.\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms“ (PowerShell) oder „D:\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms“ (PowerShell und Eingabeaufforderung) aus.

Weitere Informationen finden Sie in diesem Artikel.

Zurück zum Anfang

Upgradepatch kann nicht installiert werden

Problem:

Bei der Installation des SU wird möglicherweise die folgende Fehlermeldung angezeigt:

Der Upgradepatch kann vom Windows Installer-Dienst nicht installiert werden, weil das Programm, das aktualisiert werden soll, möglicherweise fehlt, oder weil der Upgradepatch eine andere Version des Programms aktualisieren würde. Stellen Sie sicher, dass das zu aktualisierende Programm auf dem Computer installiert ist, und dass Sie den richtigen Upgradepatch installieren.

Ursache:

Diese Fehlermeldung wird angezeigt, wenn die CU- und SU-Versionen nicht übereinstimmen.

Lösung:

Aktualisieren Sie entweder auf das richtige CU, oder laden Sie das richtige SU für das beabsichtigte CU herunter.

Zurück zum Anfang

Die Installation schlägt fehl, da einige Dienste nicht beendet werden

Problem:

Die Installation schlägt fehl, da Dienste nicht ordnungsgemäß beendet wurden.

Lösung:

Verwenden Sie die bewährte Methode, den Server neu zu starten, bevor Sie das CU oder SU installieren. Legen Sie für die Antivirensoftware, die Sie ausführen, die entsprechenden Ausschlüsse fest, oder deaktivieren Sie sie für die Dauer des Setups. Versuchen Sie in Fällen, in denen Dienste immer noch nicht wie erwartet beendet oder gestartet werden, Folgendes:

  1. Benennen Sie den Ordner „C:\ExchangeSetupLogs“ um (z. B. „ExchangeSetupLogs-ALT“).

  2. Ändern Sie den Starttyp für Exchange-Dienste in der Konsole services.msc in Automatisch.

    Hinweis: Führen Sie diesen Schritt nur für diejenigen Exchange-Dienste aus, die vor dem Setupversuch aktiv waren. Die POP3- und IMAP4-Dienste werden standardmäßig beendet. Sie müssen nur ausgeführt werden, wenn es Benutzer gibt, die sie benötigen.

Führen Sie dann das Setup erneut aus.

Zurück zum Anfang

Dienste werden nach der SU-Installation nicht gestartet

Problem:

Exchange-Dienste werden nicht gestartet, nachdem Sie die SU-Installation abgeschlossen haben.

Lösung:

Überprüfen Sie den Status der Dienste. Wenn sie Deaktiviert sind, setzen Sie sie auf Automatisch, und starten Sie sie manuell.

Hinweis: Die Dienste MSExchangeIMAP4, MSExchangeIMAP4BE, MSExchangePOP3 und MSExchangePOP3BE sind in der Regel standardmäßig deaktiviert. Überprüfen Sie das Exchange-Protokoll unter C:\ExchangeSetupLogs\ServiceControl.log, um festzustellen, welche Dienste während der SU-Installation deaktiviert wurden.

Zurück zum Anfang

Fehler beim Setup im Setupprotokoll

Problem:

Die folgende Fehlermeldung wird während des Setups in den Setupprotokollen angezeigt:

Problem beim Überprüfen des Status von Active Directory, oder die Postfachserverrolle ist auf diesem Computer nicht installiert.

Lösung:

Laden Sie das Skript zur Überprüfung des Exchange-Setupprotokolls SetupLogReviewer.ps1 herunter, und führen Sie es aus. Dieses Skript überprüft „ExchangeSetup.log“, bestimmt, ob es sich bei diesem Fehler um ein bekanntes Problem handelt, und zeigt eine Maßnahme an, die Sie ergreifen können, um das Problem zu beheben. Nachdem Sie das Skript heruntergeladen haben, verweisen Sie es wie unten gezeigt auf das Exchange-Setupprotokoll, und überprüfen Sie die Ausgabe.

.\SetupLogReviewer.ps1 -SetupLog C:\ExchangeSetupLogs\ExchangeSetup.log

Alternativ können Sie das Protokoll unter C:\ExchangeSetupLogs\ExchangeSetup.log auf den folgenden Fehler überprüfen:

„Problem beim Überprüfen des Status von Active Directory: Es wurden keine Exchange-Objekte auf Organisationsebene erstellt. Diese Objekte können nicht während der Installation erstellt werden, weil sich der lokale Computer nicht in derselben Domäne und nicht im selben Standort wie der Schemamaster befindet. Führen Sie die Installation mit dem Parameter /prepareAD auf einem Computer in der Domäne <Domänenname> und Site <Default_First_Site_Name> aus und warten Sie, bis die Replikation abgeschlossen ist.

Wenn Sie diesen Fehler feststellen, führen Sie den folgenden Befehl auf einem Computer aus, der sich in derselben Domäne wie der Schemamaster befindet.

.\setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

Hinweis: Der Benutzer, der den Befehl ausführt, muss ein Mitglied der Gruppen Organisationsadministrator, Domänenadministrator und Schemaadministrator sein.

Um den Domänencontroller (DC) zu finden, der den Schemamaster enthält, führen Sie auf dem Domänencontroller den folgenden Befehl an einer Eingabeaufforderung mit administrativen Rechten aus:

netdom query fsmo

Zurück zum Anfang

Fehler bei der Updaterollupinstallation

Problem:

Wenn Sie diesen Updaterollup auf einem Computer installieren, der nicht mit dem Internet verbunden ist, kann die Installation lange dauern. Außerdem wird möglicherweise die folgende sinngemäße Fehlermeldung angezeigt:

Erstellen systemeigener Abbilder für .Net-Assemblys.

Ursache:

Dieses Problem wird dadurch verursacht, dass das Netzwerk eine Verbindung mit der folgenden URL anfordert:

http://crl.microsoft.com/pki/crl/products/CodeSigPCA.crl

Diese Netzwerkanforderungen stellen Versuche dar, auf die Zertifikatssperrliste für jede Assembly zuzugreifen, für die „Generieren nativer Images“ (NGen) in nativem Code kompiliert wird. Da der Server, auf dem Exchange Server ausgeführt wird, jedoch nicht mit dem Internet verbunden ist, kann der Prozess erst fortgesetzt werden, wenn für jede Anforderung das Wartezeitlimit überschritten wurde.

Lösung:

Gehen Sie wie folgt vor:

  1. Klicken Sie in Internet Explorer auf Extras>Internetoptionen.

  2. Wählen Sie die Registerkarte Erweitert aus.

  3. Deaktivieren Sie im Abschnitt Sicherheit das Kontrollkästchen Auf gesperrte Zertifikate von Herausgebern überprüfen, und wählen Sie dann OK aus.

    Hinweis

    Deaktivieren Sie diese Sicherheitsoption nur dann, wenn sich der Computer in einer streng überwachten Umgebung befindet.

  4. Aktivieren Sie nach Abschluss des Setupprozesses das Kontrollkästchen Auf gesperrte Zertifikate von Herausgebern überprüfen wieder neu.

Zurück zum Anfang

Setup schlägt mit dem Fehler „Der Dienst kann nicht gestartet werden“ fehl

Problem:

Das CU-Setup schlägt möglicherweise mit der folgenden Fehlermeldung fehl:

Der Dienst Microsoft Exchange-Diensthost kann nicht gestartet werden.

Möglicherweise werden der Dienst „Microsoft Exchange-Diensthost“ und/oder alle anderen Exchange-Dienste angehalten und im Modus Deaktiviert angezeigt.

Lösung:

Gehen Sie wie folgt vor:

  1. Benennen Sie den Ordner „C:\ExchangeSetupLogs“ um (z. B. „ExchangeSetupLogs-ALT“).

  2. Ändern Sie den Starttyp für alle Exchange-Dienste in der Konsole services.msc in Automatisch.

  3. Unter der Annahme, dass sich das Medium mit dem Exchange-CU auf dem Laufwerk D: befindet, öffnen Sie eine Eingabeaufforderung als Administrator, und setzen Sie das Setup mit dem folgenden Befehl fort:

    D:\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms

Zurück zum Anfang

SU-Installation schlägt aufgrund vorhandener IU fehl

Problem:

Während der SU-Installation wird möglicherweise folgende sinngemäße Fehlermeldung angezeigt:

Die Installation kann nicht fortgesetzt werden. Der Setup-Assistent hat festgestellt, dass dieses Interimupdate mit der aktuellen Konfiguration von Microsoft Exchange Server 2013, kumulatives Update 23, nicht kompatibel ist.

Lösung 1

Deinstallieren Sie das zuvor installierte Interimupdate (IU), bevor Sie dieses SU anwenden, da die Updates kumulativ sind. Frühere IUs finden Sie unter Programme hinzufügen/entfernen.

Lösung 2

Diese Fehlermeldung kann auch auf einem Server angezeigt werden, auf dem keine IUs installiert sind, der aber nicht mit dem Internet verbunden ist. Daher kann die Zertifikatssperrliste nicht überprüft werden. In dieser Situation gehen Sie wie folgt vor:

  1. Klicken Sie in Internet Explorer auf Extras>Internetoptionen.

  2. Wählen Sie die Registerkarte Erweitert aus.

  3. Deaktivieren Sie im Abschnitt Sicherheit das Kontrollkästchen Auf gesperrte Zertifikate von Herausgebern überprüfen, und wählen Sie dann OK aus.

    Hinweis

    Deaktivieren Sie diese Sicherheitsoption nur dann, wenn sich der Computer in einer streng überwachten Umgebung befindet.

  4. Aktivieren Sie nach Abschluss des Setupprozesses das Kontrollkästchen Auf gesperrte Zertifikate von Herausgebern überprüfen wieder neu.

Zurück zum Anfang

Setup installiert ein älteres CU oder kann ein Sprachpaket nicht installieren

Problem:

Sie aktualisieren auf das neueste CU, aber Setup zeigt entweder an, dass ein vorhandenes CU auf dem Server installiert wird, ODER es schlägt mit der folgenden Fehlermeldung fehl:

Paket Das Paket 'C:\Programme\Microsoft\Exchange Server\V15\bin\Setup\' konnte nicht geöffnet werden<Paketname>. Dieses Installationspaket konnte nicht geöffnet werden. Stellen Sie sicher, dass das Paket vorhanden ist und Sie darauf zugreifen können, oder wenden Sie sich an den Hersteller der Anwendung, um sicherzustellen, dass es sich um ein gültiges Windows Installer-Paket handelt. Der Fehlercode lautet 1619.

Ursache:

Diese Probleme treten auf, wenn Sie die Installation über Windows PowerShell starten und den Befehl „setup.exe“ verwenden.

Lösung:

Wenn sich das Medium mit dem Exchange-CU im Laufwerk D: befindet, führen Sie ein Upgrade mit PowerShell mithilfe eines der folgenden Befehle aus: „.\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms“ (PowerShell) oder „D:\setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms“ (PowerShell und Eingabeaufforderung)

Zurück zum Anfang

Neustart von vorheriger Installation steht aus

Problem:

Auch nach dem mehrfachen Neustart des Servers wird die folgende sinngemäße Fehlermeldung angezeigt:

Das Setup von Microsoft Exchange Server kann nicht fortgesetzt werden, da ein Neustart nach einer vorherigen Installation oder Aktualisierung aussteht.

Lösung:

Befolgen Sie die Informationen unter Ein Neustart von einer vorherigen Installation steht aus, um das Problem zu beheben.

Wenn die Fehlermeldung weiterhin angezeigt wird, gehen Sie wie folgt vor:

  1. Führen Sie das HealthChecker-Skript aus.
  2. Führen Sie das Skript SetupAssist.ps1 aus.

Zurück zum Anfang

Der Nachrichtenfluss wurde angehalten

Problem:

Der Nachrichtenfluss wird beendet, nachdem Sie ein CU oder SU installiert haben.

Lösung:

Um den Nachrichtenfluss wieder funktionsfähig zu machen, stellen Sie sicher, dass die folgenden Anforderungen erfüllt sind:

  1. Alle Exchange-Dienste sind aktiviert und werden ausgeführt.
  2. Der Server befindet sich nicht im Wartungsmodus
  3. In der Exchange-Nachrichtenwarteschlangen-Datenbank ist genügend freier Speicherplatz verfügbar.

Zurück zum Anfang

Exchange Setup- oder PrepareAD-Fehler

Problem:

Wenn Sie entweder Exchange-Setup oder den Befehl PrepareAD ausführen, schlägt der Vorgang mit der folgenden Fehlermeldung fehl:

Der bekannte Objekteintrag B:<guid>:CN=Recipient Management\0ADEL:<guid>,CN=Deleted Objects,DC=contoso,DC=com auf dem otherWellKnownObjects-Attribut im Containerobjekt CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com zeigt auf einen ungültigen DN oder ein gelöschtes Objekt. Entfernen Sie den Eintrag, und führen Sie dann die Aufgabe erneut aus. at Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)

Ursache:

Dieses Problem tritt auf, weil sich „otherWellKnownObjects“, das Objekt, auf das in der Fehlermeldung verwiesen wird, nicht mehr in Active Directory befindet. Daher muss die Verknüpfung zum Objekt entfernt werden.

Lösung:

Laden Sie das Skript SetupAssist.ps1 herunter, und führen Sie es aus.

.\SetupAssist.ps1 -OtherWellKnownObjects

Das Skript überträgt das Attribut „otherWellKnownObjects“ in eine Datei mit dem Namen „ExchangeContainerOriginal.txt“. Anschließend wird die Datei auf gelöschte Objekte überprüft. Wenn gelöschte Objekte gefunden werden, generiert das Skript eine neue Datei mit dem Namen „ExchangeContainerImport.txt“ und verwendet sie, um die fehlerhaften Werte zu entfernen.

Wenn Sie von dem Skript aufgefordert werden, die Ergebnisse zu überprüfen, gehen Sie wie folgt vor:

  1. Überprüfen Sie die Datei „ExchangeContainerImport.txt“ auf die vom Skript vorgenommenen Änderungen.
  2. Importieren Sie die Datei „ExchangeContainerImport.txt“ in Active Directory, indem Sie den Anweisungen des Skripts folgen.
  3. Führen Sie den Befehl „PrepareAD“ erneut aus.

Jetzt sollten Sie in der Lage sein, mit dem Setup fortzufahren.

Zurück zum Anfang

Exchange-Setup schlägt mit Fehlercode 1603 fehl

Problem:

Während der Exchange-Installation wird die folgende Fehlermeldung angezeigt:

Fehler beim Installieren des Produkts F:\exchangeserver.msi. Schwerwiegender Fehler bei der Installation. Der Fehlercode lautet 1603. Letzter vom MSI-Paket ausgegebener Fehler: „Der Installer besitzt keine ausreichenden Berechtigungen, um auf dieses Verzeichnis zuzugreifen: C:\Programme\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.1.2106.“

Lösung:

  1. Stellen Sie sicher, dass das Setup mithilfe eines lokalen Administratorkontos ausgeführt wird.
  2. Überprüfen Sie, ob dem in der Fehlermeldung angegebenen Ordner die folgenden Berechtigungen zugewiesen sind:
    1. Leseberechtigung für authentifizierte Benutzer
    2. Vollzugriffsrecht für System
    3. Volle Kontrolle auf <local_machine>\administrators>
  3. Stellen Sie sicher, dass die Vererbung im Ordner aktiviert ist. Aktivieren Sie andernfalls die Vererbung.

Nachdem Sie die Ordnerberechtigungen aktualisiert haben, setzen Sie das Setup fort.

Wenn die Fehlermeldung weiterhin angezeigt wird, führen Sie die Schritte in diesem Artikel aus.

Zurück zum Anfang

Aktualisieren von .NET bei der Migration von einem nicht unterstützten CU

Wenn Sie ein Upgrade von Exchange Server von einem nicht unterstützten CU auf das aktuelle CU durchführen und keine dazwischen liegenden CUs verfügbar sind, sollten Sie zunächst auf die neueste Version von .NET aktualisieren, die durch Ihre Version von Exchange Server unterstützt wird, und dann sofort ein Upgrade auf das aktuelle CU durchführen. Auch bei dieser Methode müssen Sie Ihre Exchange-Server auf dem neuesten Stand halten und auf das neueste unterstützte CU aktualisieren. Microsoft kann nicht garantieren, dass bei Verwendung dieser Methode kein Upgradefehler auftritt.

Wichtig

Versionen von .NET Framework, die nicht in den Tabellen der Exchange Server-Unterstützungsmatrix aufgeführt sind, werden in keiner Version von Exchange unterstützt. Dies schließt Nebenversionen und Versionen auf Patchebene von .NET Framework ein.

Führen Sie diese Schritte aus, um die neueste Version von .NET Framework zu installieren:

  1. Versetzen Sie den Server in den Wartungsmodus. Führen Sie den folgenden Befehl aus:

    set-servercomponentstate \<server_name\> -Component serverwideoffline -State inactive -Requester Maintenance

  2. Beenden Sie alle Exchange-Dienste, indem Sie entweder die Dienste-MMC oder PowerShell verwenden. Wenn Sie PowerShell verwenden möchten, führen Sie den folgenden Befehl zweimal aus, um alle Exchange-Dienste zu beenden:

    Get-service \*exch\* \| stop-service

    Hinweis: Es wird davon abgeraten, den Befehl -Force zu verwenden, um alle Dienste zu beenden.

  3. Laden Sie die richtige Version von .NET Framework gemäß der Exchange Server-Unterstützungsmatrix herunter, und installieren Sie sie.

  4. Starten Sie nach Abschluss der Installation den Server neu.

  5. Aktualisieren Sie auf das neueste CU, das für Exchange 2013, 2016 oder 2019 verfügbar ist.

  6. Starten Sie den Server neu, nachdem das CU installiert ist.

  7. Stellen Sie sicher, dass sich alle Exchange-Dienste im normalen Startmodus befinden und gestartet wurden. Mithilfe von PowerShell können Sie den folgenden Befehl ausführen, um sie zu starten:

    Get-service \*exch\*

  8. Deaktivieren Sie den Wartungsmodus für den Server. Führen Sie den folgenden Befehl aus:

    set-servercomponentstate \<server_name\> -Component serverwideoffline -State active - Requester Maintenance

Zurück zum Anfang

Umgang mit benutzerdefinierten OWA- oder CONFIG-Dateien

Wichtig

Bevor Sie ein CU anwenden, sollten Sie eine Sicherungskopie Ihrer benutzerdefinierten Dateien erstellen.

Wenn Sie ein CU (für Exchange Server 2013, 2016 oder 2019) oder ein Rolluppaket (für Exchange Server 2010) anwenden, werden bei Bedarf OWA- und CONFIG-Dateien aktualisiert. Daher werden alle Anpassungen, die Sie möglicherweise an Exchange- oder Internetinformationsserver(IIS)-Einstellungen in Exchange XML-Anwendungskonfigurationsdateien auf dem Exchange-Server vorgenommen haben, bei der Installation eines Exchange-CU überschrieben. Beispiele für solche Anwendungskonfigurationsdateien sind web.config-Dateien, EdgeTransport.exe.config-Dateien und alle benutzerdefinierten logon.aspx-Dateien von Outlook im Web. Stellen Sie sicher, dass Sie diese Informationen speichern, damit Sie die Einstellungen nach der Installation des CU problemlos wieder anwenden können.

Zurück zum Anfang

Installieren des Updates für die CAS-CAS-Proxying-Bereitstellung

Wenn die beiden folgenden Bedingungen auf Ihr Szenario zutreffen, installieren Sie den Updaterollup zuerst auf Clientzugriffsservern (Client Access Server, CAS) mit Internetzugriff, bevor Sie ihn auf Clientzugriffsservern ohne Internetzugriff anwenden:

  • Sie sind CAS Proxy Deployment Guidance-Kunde.
  • Sie haben CAS-CAS-Proxying bereitgestellt.

Hinweis

In anderen Exchange Server 2010-Konfigurationen müssen Sie den Updaterollup nicht in einer bestimmten Reihenfolge auf Ihre Server anwenden.

Zurück zum Anfang

Installieren des Updates unter einer DBCS-Version von Windows Server 2012

Sie sollten den Updaterollup 32 für Exchange Server 2010 SP3 unter einer Doppelbyte-Zeichensatz-Version (Double-Byte Character Set, DBCS) von Windows Server 2012 nicht installieren oder deinstallieren, wenn die Spracheinstellung für Nicht-Unicode-Programme auf die Standardsprache festgelegt ist. Wenn die Standardsprache festgelegt ist, müssen Sie diese Einstellung ändern, bevor Sie mit der Installation beginnen.

  1. Wählen Sie in der Systemsteuerung die Option Zeit und Region>Region>Verwaltung aus.
  2. Wählen Sie im Bereich Sprache für Unicode-inkompatible Programme die Option Gebietsschema ändern aus.
  3. Wählen Sie in der Liste Aktuelles Gebietsschema die Option Englisch (Vereinigte Staaten) aus, und klicken Sie dann auf OK.

Jetzt können Sie den Updaterollup 32 nach Bedarf installieren oder deinstallieren. Nachdem der Vorgang abgeschlossen ist, setzen Sie die Spracheinstellung entsprechend wieder zurück.

Zurück zum Anfang