(0) exportieren Drucken
Alle erweitern

Versionshinweise zu Exchange 2013

 

Gilt für: Exchange Server 2013

Letztes Änderungsdatum des Themas: 2014-08-25

Willkommen bei Microsoft Exchange Server 2013! Dieses Thema enthält wichtige Informationen, die Sie für eine erfolgreiche Bereitstellung des kumulativen Updates 6 für Exchange 2013 benötigen. Bitte lesen Sie dieses Thema vollständig, bevor Sie mit der Bereitstellung beginnen.

Dieses Thema enthält die folgenden Abschnitte:

  • Setup fordert fälschlicherweise .NET Framework 4.0   Beim Versuch, Exchange 2013 auf einem Computer .NET Framework zu installieren, fordert Setup Sie fälschlicherweise zur Installation von .NET Framework 4.0 auf, obwohl die Version .NET Framework 4.5 benötigt wird.

    Um dieses Problem zu umgehen, installieren Sie .NET Framework 4.5. Sie müssen .NET Framework nicht installieren. Eine vollständige Liste der Voraussetzungen finden Sie unter Voraussetzungen für Exchange 2013.

  • Exchange XML-Anwendungskonfigurationsdateien werden während der Installation kumulativer Updates überschrieben   Alle benutzerdefinierten Einstellungen auf Serverbasis, die Sie an Exchange-XML-Anwendungskonfigurationsdateien vornehmen (z. B. an "web.config"-Dateien auf Clientzugriffsservern bzw. an der Datei "EdgeTransport.exe.config" auf Postfachservern), werden bei der Installation eines kumulativen Exchange-Updates oder Service Packs überschrieben. Stellen Sie sicher, dass diese Informationen gespeichert werden, damit Sie Ihren Server nach der Installation leicht erneut konfigurieren können. Nach der Installation eines kumulativen Exchange-Updates oder Service Packs müssen Sie diese Einstellungen neu konfigurieren.

  • Während der Serverwiederherstellung wird kein virtuelles MAPI-Verzeichnis erstellt   Wenn Sie Setup.exe mit der OptionRecoverServer auf einem Server ausführen, auf dem die Serverrolle ClientAccess installiert ist, wird das virtuelle MAPI-Verzeichnis nicht erstellt. Wenn das virtuelle MAPI-Verzeichnis nicht existiert, können Clients, die zur Verbindung mit dem Exchange-Server das Protokoll MAPI über HTTP verwenden, z. B. Outlook, keine Verbindung herstellen.

    HinweisHinweis:
    Dies ist nur dann ein Problem, wenn das Protokoll MAPI über HTTP auf Ihren Client Access-Servern aktiviert ist. Es ist standardmäßig deaktiviert. Wenn MAPI über HTTP deaktiviert ist, verwenden Clients stattdessen das Protokoll RPC über HTTP.

    Um dieses Problem zu lösen, führen Sie die Schritte im Knowledge Base-Artikel KB2931223 (MAPI-virtuelles Verzeichnis fehlt in der Standardwebsite) aus.

Weitere Informationen zur Installation von Exchange 2013 finden Sie unter Planung und Bereitstellung.

  • Erhöhung der Postfachgröße bei der Migration von früheren Exchange-Versionen   Beim Verschieben eines Postfachs von einer früheren Version von Exchange auf Exchange 2013 steigt die angezeigte Postfachgröße möglicherweise um 30 bis 40 %. Der von der Postfachdatenbank belegte Festplattenspeicherplatz bleibt unverändert, lediglich die zugeordnete Größe der einzelnen Postfächer ist gestiegen. Der Grund für die Erhöhung der Postfachgröße ist die Aufnahme aller Elementeigenschaften in Kontingentberechnungen, sodass der durch die Elemente innerhalb eines Postfachs belegte Speicherplatz präziser berechnet werden kann. Aufgrund dieser Erhöhung überschreiten einige Benutzer beim Verschieben ihrer Postfächer nach Exchange 2013 möglicherweise die für die Postfachgröße festgelegten Kontingente.

    Erhöhen Sie die Kontingentwerte für die Datenbank oder die Postfächer, um die neue Kontingentberechnung zu ermöglichen, ohne dass die Benutzer die für die Postfachgröße festgelegten Kontingente überschreiten. Verwenden Sie die Parameter IssueWarningQuota, ProhibitSendQuota und ProhibitSendReceiveQuota mit den Cmdlets Set-MailboxDatabase und Set-Mailbox, um die Kontingentwerte für die Datenbank bzw. die Postfächer festzulegen.

  • Outlook 2007- und Outlook 2010-Clients können das Offlineadressbuch möglicherweise nicht herunterladen   Wenn die interne URL des Offlineadressbuchs (OAB) über das Internet nicht zugänglich ist, können Outlook 2007- und Outlook 2010-Clients das OAB möglicherweise nicht herunterladen.

    Machen Sie die interne URL des OAB über das Internet zugänglich, um dieses Problem bei Outlook 2007- und Outlook 2010-Clients zu umgehen. Outlook 2013 ist von diesem Problem nicht betroffen.

  • Durch die Installation von Exchange 2013 in einer bestehenden Exchange-Organisation wird das OAB möglicherweise von allen Clients heruntergeladen   Wenn Sie den ersten Exchange 2013-Server in einer bestehenden Exchange 2007- oder Exchange 2010-Organisation installieren, führt dies möglicherweise dazu, dass alle Clients in der Organisation eine neue Kopie des OAB herunterladen. Dies kann zu Netzwerküberlastung und Problemen mit der Serverleistung führen. Dieses Problem tritt auf, weil Exchange 2013 ein neues Standard-OAB in der Organisation erstellt, welches Vorrang vor dem Exchange 2007- bzw. Exchange 2010-OAB besitzt. Postfächer, denen kein bestimmtes OAB zugewiesen ist oder die in einer Postfachdatenbank ohne besondere OAB-Zuweisung gespeichert sind, laden das neue Standard-OAB herunter.

    Damit Clients bei der Installation von Exchange 2013 keine neue Kopie des OAB herunterladen, weisen Sie jedem Postfach oder der Postfachdatenbank, in der die Postfächer gespeichert sind, ein OAB zu. Dies muss vor der Installation von Exchange 2013 in der Organisation erfolgen.

  • Benutzer werden möglicherweise an ein OAB-Generierungspostfach weitergeleitet, das für das angeforderte OAB nicht zuständig ist   Mit Exchange 2013 CU5 und späteren kumulativen Updates wurde geändert, wie Offlineadressbücher mit OAB-Generierungspostfächern verknüpft sind. Durch diese Änderung wird es möglich, dass ein Benutzer an ein OAB-Generierungspostfach weitergeleitet wird, das nicht für das vom Benutzer angeforderte Offlineadressbuch zuständig ist. Dieses Problem kann auftreten, wenn alle nachstehenden Bedingungen zutreffen:

    • In Ihrer Organisation gibt es mehrere OAB-Generierungspostfächer.

    • Sie führen ein Upgrade der Postfachserver durch, die OAB-Generierungspostfächer hosten, bevor Sie ein Upgrade Ihrer Clientzugriffsserver durchführen.

    • Sie führen ein Upgrade Ihrer Exchange 2013-Server von einer Version vor CU5 auf eine höhere Version durch (beispielsweise Upgrade von Exchange 2013 CU3 auf Exchange 2013 CU6).

    • Auf den Clientzugriffsservern wird eine Version vor CU5 ausgeführt.

    Um dieses Problem zu umgehen, müssen Sie unbedingt vor dem Upgrade Ihrer Postfachserver ein Upgrade Ihrer Clientzugriffsserver auf Exchange 2013 CU6 durchführen. Dadurch wird sichergestellt, dass die Clientzugriffsserver wissen, wie Sie die Anforderungen an das OAB-Generierungspostfach, das für die Generierung des Offlineadressbuchs des Benutzer zuständig ist, mittels Proxy weiterleiten müssen.

    Weitere Informationen zu den OAB-Änderungen in Exchange 2013 CU5 finden Sie unter Verbesserungen beim Offlineadressbuch im kumulativen Update 5 für Exchange 2013.

  • Unautorisierte Absender können Nachrichten an öffentliche Ordner senden   Vor Exchange 2013 CU6 konnten unautorisierte Absender Nachrichten an E-Mail-aktivierte öffentliche Ordner senden. Dadurch bestand die Möglichkeit, dass externe Absender, unabhängig von den für den öffentlichen Ordner festgelegten Berechtigungen, E-Mails an E-Mail-aktivierte öffentliche Ordner senden.

    Ab Exchange 2013 CU6 muss dem Benutzer mit dem Status Anonym zumindest die Berechtigung Objekte erstellen erteilt werden, wenn Sie zulassen möchten, dass externe Absender E-Mails an E-Mail-aktivierte öffentliche Ordner senden können. Wenn Sie E-Mail-aktivierte öffentliche Ordner eingerichtet und diese Berechtigung nicht erteilt haben, erhalten externe Absender eine Zustellungsfehlerbenachrichtung, und die Nachrichten werden dem E-Mail-aktivierten öffentlichen Ordner nicht zugestellt.

    Sie können die Shell oder Outlook verwenden, um die Berechtigungen für den anonymen Benutzer festzulegen. Weitere Informationen zum Festlegen der Berechtigungen für anonyme Benutzer finden Sie unter E-Mail-Aktivierung oder E-Mail-Deaktivierung von öffentlichen Ordnern.

  • Über Exchange-Webdienste kann nicht auf ältere öffentliche Ordner zugegriffen werden   Clients, die über Exchange-Webdienste eine Verbindung mit Exchange 2013 herstellen, können nicht auf öffentliche Ordner zugreifen, die auf Exchange 2007- oder Outlook 2010-Servern abgelegt sind. Zu Clients, die EWS verwenden, zählen Mac Outlook und Outlook Web App. Wenn ein EWS-Client versucht, auf einen älteren öffentlichen Ordner zuzugreifen, erhält er eine Fehlermeldung.

    Die zurzeit einzige mögliche Abhilfe ist die Migration der älteren öffentlichen Ordner zu Exchange 2013. Dabei gibt es allerdings einige Punkte zu berücksichtigen, bevor Sie Ihre öffentlichen Ordner migrieren. Weitere Informationen finden Sie unter Öffentliche Ordner.

  • Die TransportAgent-Cmdlets erfordern auf Clientzugriffsservern die Verwendung der lokalen Windows PowerShell   Bei den Cmdlets *-TransportAgent besteht ein Problem, aufgrund dessen diese Cmdlets nicht mit der Exchange-Verwaltungsshell verwendet werden können, um Transport-Agents auf Clientzugriffsservern zu installieren, zu deinstallieren und zu verwalten. Für die Installation, Deinstallation und Verwaltung von Transport-Agents auf Clientzugriffsservern müssen Sie das Exchange Windows PowerShell-Snap-In manuell laden und anschließend die *-TransportAgent-Cmdlets ausführen. Beim Versuch, Transport-Agents über die Exchange-Verwaltungsshell zu installieren, zu deinstallieren oder zu verwalten, werden die Änderungen auf den Exchange 2013-Postfachserver angewendet, mit dem Sie verbunden sind.

    Führen Sie auf dem Clientzugriffsserver, der verwaltet werden soll, die folgenden Schritte aus, um Transport-Agents auf diesem Server zu installieren, zu deinstallieren oder zu verwalten:

    VorsichtAchtung:
    Das Laden des Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell-Snap-Ins und das Ausführen von anderen Cmdlets als den *-TransportAgent-Cmdlets wird nicht unterstützt und kann irreparable Schäden an der Exchange-Bereitstellung zur Folge haben.
    Sie müssen Mitglied der lokalen Administratorgruppe auf dem Clientzugriffsserver sein, auf dem Transport-Agents installiert, deinstalliert oder verwaltet werden sollen. Änderungen an Zugriffssteuerungslisten für Exchange-Dateien, Verzeichnisse oder Active Directory-Objekte werden nicht unterstützt.
    WichtigWichtig:
    Führen Sie die folgenden Schritte ausschließlich auf einem Clientzugriffsserver aus. Das Exchange Windows PowerShell-Snap-In muss nicht geladen werden, wenn Transport-Agents auf Postfachservern verwaltet werden sollen.
    1. Öffnen Sie ein neues Windows PowerShell-Fenster.

    2. Führen Sie den folgenden Befehl aus.

      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
      
    3. Führen Sie die Verwaltungsaufgaben für Transport-Agents wie gewohnt aus.

    4. Wiederholen Sie diese Schritte auf jedem Clientzugriffsserver, der verwaltet werden soll.

  • NTLM-Authentifizierung misslingt bei Clients, die nicht der Domäne beigetreten sind   Die Authentifizierung zwischen einem Client wie Windows Live Mail und Exchange 2013 kann misslingen, wenn die folgenden Bedingungen vorliegen:

    • Die Authentifizierungsmethode, die der Client verwendet, ist NTLM.

    • Der Computer ist nicht der Domäne beigetreten.

    Um dieses Problem zu umgehen, können Sie eine der folgenden Aufgaben ausführen:

    • Lassen Sie den Computer, auf dem der Client ausgeführt wird, der Domäne beitreten.

    • Ändern Sie den Authentifizierungstyp des Clients von "NTLM" in "Standardauthentifizierung über TLS".

  • Die GSSAPI-Authentifizierung schlägt bei Verwendung mit dem Cmdlet "Send-MailMessage" fehl   Die GSSAPI-Authentifizierung (Generic Security Service Application Program Interface) kann fehlschlagen, wenn das Cmdlet Send-MailMessage, das zur Standardinstallation von Windows PowerShell gehört, verwendet wird, um authentifizierte E-Mails an Exchange 2013 zu senden. Wenn dies geschieht, wird im Ereignisprotokoll Anwendung auf dem Exchange 2013-Clientzugriffsserver, der die Verbindung empfangen hat, ein Ereignis mit folgenden Informationen angezeigt:

    • Quelle   MSExchangeFrontEndTransport

    • Ereignis-ID   1035

    • Beschreibung   Fehler IllegalMessage bei der eingehenden Authentifizierung für den Empfangsconnector "Client-Front-End <Servername>". Der Authentifizierungsmechanismus ist Gssapi. Die Quell-IP-Adresse des Clients, der die Authentifizierung bei Exchange versucht hat, lautet [<IP-Adresse des Clients>].

    Zum Beheben dieses Problems müssen Sie die Authentifizierungsmethode Integrated aus dem Clientempfangsconnector für Ihre Exchange 2013-Clientzugriffsserver entfernen. Führen Sie zum Entfernen der Authentifizierungsmethode Integrated aus einem Clientempfangsconnector auf allen Exchange 2013-Clientzugriffsservern, die Verbindungen von Computern empfangen können, mithilfe des Cmdlets Send-MailMessage den folgenden Befehl aus:

    Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS
    
  • Nach einem Upgrade auf Exchange 2013 SP1 kann es zu einer schlechten Leistung von MAPI über HTTP kommen   Wenn Sie ein Upgrade von einem kumulativen Update für Exchange 2013 auf Exchange 2013 SP1 durchführen und MAPI über HTTP aktivieren, kann es zu schlechter Leistung kommen, wenn Clients über dieses Protokoll eine Verbindung mit einem Exchange 2013 SP1-Server herstellen. Der Grund dafür ist, dass erforderliche Einstellungen bei einem Upgrade von einem kumulativen Update auf Exchange 2013 SP1 nicht konfiguriert werden. Dieses Problem tritt nicht auf, wenn Sie ein Upgrade von Exchange 2013 RTM auf Exchange 2013 SP1 durchführen oder einen neuen Server mit Exchange 2013 SP1 oder höher installieren.

    HinweisHinweis:
    Dies ist nur dann ein Problem, wenn das Protokoll MAPI über HTTP auf Ihren Client Access-Servern aktiviert ist. Es ist standardmäßig deaktiviert. Wenn MAPI über HTTP deaktiviert ist, verwenden Clients stattdessen das Protokoll RPC über HTTP.

    Um dieses Problem zu beheben, führen Sie folgende Schritte aus:

    1. Führen Sie auf Servern, auf denen die Clientzugriffs-Serverrolle installiert ist, in einer Windows-Eingabeaufforderung die folgenden Befehle aus:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"
      
    2. Führen Sie auf Servern, auf denen die Serverrolle Mailbox installiert ist, in einer Windows-Eingabeaufforderung die folgenden Befehle aus:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\Microsoft\Exchange Server\V15
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiMailboxAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiMailboxAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiMailboxAppPool"
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiAddressBookAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiAddressBookAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiAddressBookAppPool"
      

  • Anforderungen für den Zugriff auf Exchange 2010-Postfächer misslingen möglicherweise, wenn sie mittels Proxyweiterleitung durch Exchange 2013-Clientzugriffsserver gesendet werden   Mitunter funktioniert die Proxyanforderung zwischen den Exchange 2013- und Exchange 2010 Service Pack 3 (SP3)-Clientzugriffsservern ohne die Installation von Updaterollups möglicherweise nicht einwandfrei, und es wird ein Fehler angezeigt. Dieses Problem kann auftreten, wenn alle nachstehenden Bedingungen zutreffen:

    • Ein Benutzer mit einem Exchange 2013-Postfach versucht, Exchange 2010-Postfach mit einer der folgenden Methoden zu öffnen:

      • mit der Option Anderes Postfach öffnen in Outlook Web App -ODER-

      • mit der Option Anderer Benutzer im Exchange Admin Center.

    • Auf dem Clientzugriffsserver, mit dem der Benutzer eine Verbindung hergestellt hat, läuft Exchange 2013.

    • Der Exchange 2010-Clientzugriffsserver wurde auf Exchange 2010 SP3 aktualisiert aus der RTM-Version (Release to Manufacturing) von Exchange 2010 oder einem früheren Exchange 2010 Service Pack.

    Falls alle voranstehenden Bedingungen zutreffen, kann der Benutzer nicht auf die Exchange 2010 Outlook Web App-Optionen eines anderen Benutzers zugreifen, und es erscheint ggf. eine leere Seite.

    Installieren Sie zum Beheben dieses Problems auf allen Exchange 2010-Servern das Exchange 2010 SP3 Updaterollup 1 oder höher.

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft