Versionshinweise zu Exchange 2013

  • Artikel

Gilt für: Exchange Server 2013

Willkommen beim Microsoft Exchange Server 2013! Dieses Thema enthält wichtige Informationen, die Sie für die erfolgreiche Bereitstellung von Exchange 2013 kennen müssen. Bitte lesen Sie dieses Thema vollständig, bevor Sie mit der Bereitstellung beginnen.

Dieses Thema enthält die folgenden Abschnitte:

  • Setup und Bereitstellung

  • Exchange-Verwaltungsshell

  • Postfach

  • Öffentliche Ordner

  • Nachrichtenübermittlung

  • Client-Konnektivität

  • Koexistenz mit Exchange 2010

Setup und Bereitstellung

  • msExchProductId spiegelt nicht die installierte Version von Exchange 2013 wider . Nachdem Exchange Ihr Active Directory-Schema erweitert und Active Directory für Exchange vorbereitet hat, werden mehrere Eigenschaften aktualisiert, um zu zeigen, dass die Vorbereitung abgeschlossen ist. Eine dieser Eigenschaften ist msExchangeProductId unter dem CN=<your organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=<domain> Container im Benennungskontext Configuration . Wenn in der Version von Exchange 2013, die Sie installieren, keine Active Directory-Schemaänderungen eingeführt werden, wird diese Eigenschaft nicht aktualisiert oder zeigt möglicherweise einen unerwarteten Wert an. Dies kann zu Verwirrung führen, wenn der Wert nicht mit der Version von Exchange 2013 übereinstimmt, die installiert wird.

    Dieses Verhalten wird erwartet, da der Wert von msExchProductId nicht die version von Exchange 2013 widerspiegelt, die installiert wird. Diese Eigenschaft gibt die Version von Exchange 2013 an, die zuletzt Änderungen am Active Directory-Schema vorgenommen hat. Um Verwirrung zu vermeiden, empfehlen wir Ihnen, die Schritte im Abschnitt Wie haben Sie dies funktioniert? unter Vorbereiten von Active Directory und Domänen auszuführen, um sicherzustellen, dass Ihr Active Directory aktualisiert wurde und für die Version von Exchange 2013 bereit ist, die Sie installieren.

  • Setup fordert fälschlicherweise .NET Framework 4.0 an: Wenn Sie versuchen, Exchange 2013 ohne .NET Framework auf dem Computer zu installieren, fordert Setup fälschlicherweise die Installation von .NET Framework 4.0 an, wenn tatsächlich .NET Framework 4.5 oder höher erforderlich ist.

    Installieren Sie .NET Framework Version 4.5 oder höher, um dieses Problem zu umgehen. Sie müssen .NET Framework 4.0 nicht installieren. Eine vollständige Liste der Voraussetzungen finden Sie unter Voraussetzungen für Exchange 2013.

  • Exchange XML-Anwendungskonfigurationsdateien werden während der Installation des kumulativen Updates überschrieben: Alle benutzerdefinierten Exchange- oder Internetinformationsservereinstellungen pro Server, die Sie in Exchange XML-Anwendungskonfigurationsdateien vornehmen, z. B. web.config Dateien auf Clientzugriffsservern oder die EdgeTransport.exe.config-Datei auf Postfachservern, werden überschrieben, wenn Sie ein kumulatives Exchange-Update oder Service Pack installieren. Stellen Sie sicher, dass Sie diese Informationen speichern, damit Sie Ihren Server nach der Installation einfach neu konfigurieren können. Sie müssen diese Einstellungen nach der Installation eines kumulativen Updates oder Service Packs für Exchange erneut konfigurieren.

  • Installieren von Exchange mithilfe von stellvertretenden Administratorrechten führt zum Setupfehler Wenn ein Benutzer, der nur Mitglied der Rollengruppe „Stellvertretender Administrator" ist, versucht Exchange auf einem bereitgestellten Server zu installieren, tritt ein Setupfehler auf. Dies liegt daran, dass die Gruppe „Delegiertes Setup" nicht über die erforderlichen Berechtigungen zum Erstellen und Konfigurieren bestimmter Objekte in Active Directory verfügt.

    Führen Sie einen der folgenden Schritte aus, um das Problem zu umgehen:

    • Fügen Sie den Benutzer, der Exchange installiert, der Active Directory-Sicherheitsgruppe „Domänenadministratoren“ hinzu.

    • Installieren Sie Exchange unter Verwendung eines Benutzers, der Mitglied der Rollengruppe „Organisationsverwaltung" ist.

Weitere Informationen zum Installieren von Exchange 2013 finden Sie unter Planen und Bereitstellen.

Exchange-Verwaltungsshell

  • Die Shell lädt unerwartet Exchange 2007- oder Exchange 2010-Cmdlets. Zuvor hatte das Öffnen der Shell auf einem Exchange 2013-Server dazu führen, dass die Shell eine Verbindung mit dem lokalen Server oder einem anderen Server mit Exchange 2013 öffnete. Wenn die Verbindung hergestellt wird, werden Exchange 2013-Cmdlets geladen. Ab Exchange 2013 CU11 stellt die Shell eine Verbindung mit dem Exchange-Server her, auf dem sich das Postfach des angemeldeten Benutzers befindet. Wenn der angemeldete Benutzer über kein Postfach verfügt, stellt die Shell eine Verbindung mit dem Server her, auf dem sich das Schiedspostfach SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} befindet. Der Zielserver kann eine beliebige unterstützte Version von Exchange sein. Dies bedeutet, dass sich das Postfach des angemeldeten Benutzers (oder das Vermittlungspostfach, wenn der Benutzer über kein Postfach verfügt) auf einem Exchange 2010-Server befindet, die Shell eine Verbindung mit diesem Server herstellt und Exchange 2010-Cmdlets lädt. Dies kann Sie daran hindern, bestimmte Aufgaben auszuführen, da Exchange 2010-Cmdlets exchange 2013-Konfigurationen oder -Server nicht verwalten können.

    Ab Exchange 2013 CU11 ist dieses Verhalten beabsichtigt. Um sicherzustellen, dass die Shell Exchange 2013-Cmdlets lädt, verschieben Sie das Postfach des angemeldeten Benutzers in Exchange 2013. Wenn der angemeldete Benutzer über kein Postfach verfügt, verschieben Sie das SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}-Schiedspostfach auf einen Exchange 2013-Server.

    Ausführliche Informationen zum Verschieben des Vermittlungspostfachs finden Sie unter Exchange-Verwaltungsshell und Postfachankerung im Exchange-Teamblog.

Postfach

  • Postfachserver, auf denen verschiedene Versionen von Exchange ausgeführt werden, können derselben Datenbankverfügbarkeitsgruppe hinzugefügt werden . Das Cmdlet Add-DatabaseAvailabilityGroupServer und das Exchange Admin Center lassen fälschlicherweise das Hinzufügen eines Exchange 2013-Servers zu einer Exchange 2016-basierten Datenbankverfügbarkeitsgruppe (DAG) zu und umgekehrt. Exchange unterstützt nur das Hinzufügen von Postfachservern mit derselben Version (z. B. Exchange 2013 im Vergleich zu Exchange 2016) zu einer DAG. Darüber hinaus werden im Exchange Admin Center sowohl Exchange 2013- als auch Exchange 2016-Server in der Liste der Server angezeigt, die einer DAG hinzugefügt werden können. Dadurch kann ein Administrator versehentlich einen Server mit einer inkompatiblen Version von Exchange zu einer DAG hinzufügen (z. B. hinzufügen eines Exchange 2013-Servers zu einer Exchange 2016-basierten DAG).

    Derzeit gibt es keine Abhilfe für dieses Problem. Administratoren müssen beim Hinzufügen eines Postfachservers zu einer DAG sorgfältig sein. Fügen Sie nur Exchange 2013-Server zu Exchange 2013-basierten DAGs hinzu, und nur Exchange 2016-Server zu Exchange 2016-basierten DAGs. Sie können jede einzelne Version von Exchange unterscheiden, indem Sie die Spalte Version in der Liste der Server im Exchange Admin Center betrachten. Im Folgenden werden die Serverversionen für Exchange 2013 und Exchange 2016 angegeben:

    • Exchange 2013 15.0 (Build xxx.xx)

    • Exchange 2016 15.1 (Build xxx.xx)

  • Erhöhung der Postfachgröße bei der Migration von früheren Exchange-Versionen: Wenn Sie ein Postfach von einer früheren Version von Exchange zu Exchange 2013 verschieben, kann die gemeldete Postfachgröße um 30 % auf 40 % erhöht werden. Der von der Postfachdatenbank belegte Speicherplatz wurde nicht erhöht, nur die Zuordnung des von den einzelnen Postfächern belegten Speicherplatzes wurde erhöht. Der Anstieg der Postfachgröße ist darauf zurückzuführen, dass alle Elementeigenschaften in Kontingentberechnungen einbezogen werden, wodurch eine genauere Berechnung des von Elementen innerhalb ihres Postfachs verbrauchten Speicherplatzes ermöglicht wird. Dieser Anstieg kann dazu führen, dass einige Benutzer ihre Postfachgrößenkontingente überschreiten, wenn ihr Postfach nach Exchange 2013 verschoben wird.

    Um zu verhindern, dass Benutzer ihre Postfachgrößenkontingente überschreiten, erhöhen Sie die Datenbank- oder Postfachkontingentwerte, um die neue Kontingentberechnung zu berücksichtigen. Verwenden Sie zum Konfigurieren von Datenbank- oder Postfachkontingentwerten die Parameter IssueWarningQuota, ProhibitSendQuota und ProhibitSendReceiveQuota für die Cmdlets Set-MailboxDatabase bzw . Set-Mailbox .

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

    Um dieses Problem für Outlook 2007- und Outlook 2010-Clients zu umgehen, machen Sie die interne OAB-URL über das Internet zugänglich. Outlook 2013 ist von diesem Problem nicht betroffen.

  • Die Installation von Exchange 2013 in einer vorhandenen Exchange-Organisation kann dazu führen, dass alle Clients das OAB herunterladen: Die Installation des ersten Exchange 2013-Servers in einer vorhandenen Exchange 2007- oder Exchange 2010-Organisation kann dazu führen, dass alle Clients in der Organisation eine neue Kopie des OAB herunterladen, was zu Netzwerkauslastungs- und Serverleistungsproblemen führt. Dieses Problem tritt auf, weil Exchange 2013 ein neues Standard-OAB in der Organisation erstellt, das das Exchange 2007- oder Exchange 2010-OAB ablöst. Postfächer, denen kein bestimmtes OAB zugewiesen ist oder sich in einer Postfachdatenbank befinden, der kein bestimmtes OAB zugewiesen ist, wird das neue Standard-OAB heruntergeladen.

    Um zu verhindern, dass Clients bei der Installation von Exchange 2013 eine neue Kopie des OAB herunterladen, weisen Sie jedem Postfach oder der Postfachdatenbank, in der sich die Postfächer befinden, ein OAB zu. Dies muss vor der Installation von Exchange 2013 in der Organisation erfolgen.

  • Benutzer werden möglicherweise an ein Postfach der OAB-Generation weitergeleitet, das nicht für das angeforderte OAB verantwortlich ist: Exchange 2013 CU5 und höhere CUs haben geändert, wie OABs mit Postfächern der OAB-Generierung verknüpft werden. Diese Änderung ermöglicht es, dass ein Benutzer an ein Postfach der OAB-Generation weitergeleitet wird, das nicht für das vom Benutzer angeforderte OAB verantwortlich ist. Dies kann passieren, wenn alle folgenden Punkte zutreffen:

    • Sie haben mehr als ein Postfach der OAB-Generation in Ihrer Organisation.

    • Sie aktualisieren die Postfachserver, die Postfächer der OAB-Generation hosten, bevor Sie Ihre Clientzugriffsserver aktualisieren.

    • Sie aktualisieren Ihre Exchange 2013-Server von einer Version vor CU5 auf eine spätere Version (z. B. ein Upgrade von Exchange 2013 CU3 auf Exchange 2013 CU6).

    • Auf Ihren Clientzugriffsservern wird ein Release vor CU5 ausgeführt.

    Um dieses Problem zu umgehen, stellen Sie sicher, dass Sie Ihre Clientzugriffsserver auf Exchange 2013 CU6 oder höher aktualisieren, bevor Sie Ihre Postfachserver aktualisieren. Dadurch wird sichergestellt, dass die Clientzugriffsserver wissen, wie die Anforderungen an das Postfach der OAB-Generierung gesendet werden, das für die Generierung des OAB des Benutzers verantwortlich ist.

    Weitere Informationen zu den OAB-Änderungen in Exchange 2013 CU5 finden Sie unter OAB-Verbesserungen in Exchange 2013 Kumulatives Update 5.

Öffentliche Ordner

  • Nicht autorisierte Absender können keine Nachrichten mehr an E-Mail-aktivierte öffentliche Ordner senden: Vor Exchange 2013 CU6 konnten nicht autorisierte Absender Nachrichten an E-Mail-aktivierte öffentliche Ordner senden. Dies ermöglichte es externen Absendern, E-Mails unabhängig von den für den öffentlichen Ordner festgelegten Berechtigungen an E-Mail-aktivierte öffentliche Ordner zu senden.

    Ab Exchange 2013 CU6 muss dem anonymen Benutzer mindestens die Berechtigung Elemente erstellen erteilt werden, wenn externe Absender E-Mails an E-Mail-aktivierte öffentliche Ordner senden sollen. Wenn Sie E-Mail-aktivierte öffentliche Ordner eingerichtet haben und dies nicht getan haben, erhalten externe Absender eine Zustellungsfehlerbenachrichtigung, und die Nachrichten werden nicht an den E-Mail-aktivierten öffentlichen Ordner übermittelt.

    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.

  • Die maximale Anzahl öffentlicher Ordner, die von älteren Exchange-Servern zu Exchange 2013 migriert werden können, beträgt 500.000. Weitere Informationen zur Migration öffentlicher Ordner finden Sie unter Verwenden der Batchmigration zum Migrieren öffentlicher Ordner zu Exchange 2013 aus früheren Versionen.

Nachrichtenübermittlung

  • TransportAgent-Cmdlets auf Clientzugriffsservern erfordern lokale Windows PowerShell: Es liegt ein Problem mit den *-TransportAgent-Cmdlets vor, das diese Cmdlets daran hindert, Transport-Agents mithilfe der Exchange-Verwaltungsshell auf Clientzugriffsservern zu installieren, zu deinstallieren und zu verwalten. Zum Installieren, Deinstallieren und Verwalten von Transport-Agents auf Clientzugriffsservern müssen Sie das Exchange Windows PowerShell-Snap-In manuell laden und dann die Cmdlets *-TransportAgent ausführen. Wenn Sie versuchen, Transport-Agents mithilfe der Exchange-Verwaltungsshell zu installieren, zu deinstallieren oder zu verwalten, werden Ihre Änderungen auf den Exchange 2013-Postfachserver angewendet, mit dem Sie verbunden sind.

    Führen Sie zum Installieren, Deinstallieren oder Verwalten von Transport-Agents auf Clientzugriffsservern die folgenden Schritte auf dem Clientzugriffsserver aus, den Sie verwalten möchten:

    Warnung

    Das Laden des Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell Snap-Ins und das Ausführen anderer Cmdlets als die Cmdlets -TransportAgent wird nicht unterstützt und kann zu irreparablen Schäden an Ihrer Exchange-Bereitstellung führen.

    Sie müssen ein lokaler Administrator auf dem Clientzugriffsserver sein, auf dem Sie Transport-Agents installieren, deinstallieren oder verwalten möchten. Die Änderung von Zugriffssteuerungslisten (Access Control Lists, ACLs) für Exchange-Dateien, Verzeichnisse oder Active Directory-Objekte wird nicht unterstützt.

    Wichtig

    Führen Sie das folgende Verfahren nur auf Clientzugriffsservern aus. Sie müssen das Exchange Windows PowerShell-Snap-In nicht laden, wenn Sie Transport-Agents auf Postfachservern verwalten möchten.

    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 des Transport-Agents wie gewohnt aus.

    4. Wiederholen Sie dieses Verfahren auf jedem Clientzugriffsserver, den Sie verwalten möchten.

Client-Konnektivität

  • Bei nicht in die Domäne eingebundenen Clients tritt bei der NTLM-Authentifizierung ein Fehler auf: Die Authentifizierung zwischen einem Client, z. B. Windows Live Mail, und Exchange 2013 schlägt möglicherweise fehl, wenn die folgenden Bedingungen erfüllt sind:

    • Anschließend verwendet der Client die Authentifizierungsmethode NTLM.

    • Der Computer ist nicht in die Domäne eingebunden.

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

    • Fügen Sie den Computer, auf dem der Client ausgeführt wird, in die Domäne ein.

    • Ändern Sie den vom Client verwendeten Authentifizierungstyp von NTLM in Standardauthentifizierung über TLS.

  • Die GSSAPI-Authentifizierung schlägt fehl, wenn sie mit dem cmdlet Send-MailMessage verwendet wird: Die GSSAPI-Authentifizierung (Generic Security Service Application Program Interface) schlägt möglicherweise fehl, wenn das Cmdlet Send-MailMessage, das in Standardinstallationen von Windows PowerShell enthalten ist, zum Senden authentifizierter E-Mails an Exchange 2013 verwendet wird. In diesem Fall wird ein Eintrag im Anwendungsereignisprotokoll auf dem Exchange 2013-Clientzugriffsserver angezeigt, der die Verbindung mit den folgenden Informationen empfangen hat:

    • Quelle: MSExchangeFrontEndTransport

    • Ereignis-ID: 1035

    • Beschreibung: Bei der eingehenden Authentifizierung ist ein Fehler IllegalMessage für den Namen >des Empfangsconnectors Client-Front-End-Server < aufgetreten. Der Authentifizierungsmechanismus ist Gssapi. Die Quell-IP-Adresse des Clients, der versucht hat, sich bei Exchange zu authentifizieren, ist [<Client-IP-Adresse>].

    Um dieses Problem zu umgehen, müssen Sie die Integrated Authentifizierungsmethode aus dem Client-Empfangsconnector auf Ihren Exchange 2013-Clientzugriffsservern entfernen. Um die Integrated Authentifizierungsmethode von einem Client-Empfangsconnector zu entfernen, führen Sie den folgenden Befehl auf jedem Exchange 2013-Clientzugriffsserver aus, der Verbindungen von Computern empfangen kann, auf denen das Cmdlet Send-MailMessage ausgeführt wird:

    Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS

  • MAPI über HTTP kann eine schlechte Leistung beim Upgrade auf Exchange 2013 SP1 aufweisen: Wenn Sie ein Upgrade von einem kumulativen Exchange 2013-Update auf Exchange 2013 SP1 durchführen und MAPI über HTTP aktivieren, können Clients, die über das Protokoll eine Verbindung mit einem Exchange 2013 SP1-Server herstellen, eine schlechte Leistung aufweisen. Dies liegt daran, dass die erforderlichen Einstellungen während eines Upgrades 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.

    Hinweis

    Dies ist nur ein Problem, wenn das MAPI-über-HTTP-Protokoll auf Ihren Clientzugriffsservern aktiviert ist. Sie ist standardmäßig deaktiviert. Wenn MAPI über HTTP deaktiviert ist, verwenden Clients stattdessen das RPC-über-HTTP-Protokoll.

    Um dieses Problem zu umgehen, führen Sie die folgenden Schritte aus:

    1. Führen Sie auf Servern, auf denen die Serverrolle Clientzugriff ausgeführt wird, die folgenden Befehle in einer Windows-Eingabeaufforderung 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 Postfachserverrolle ausgeführt wird, die folgenden Befehle in einer Windows-Eingabeaufforderung 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"

Koexistenz mit Exchange 2010

  • Anforderungen für den Zugriff auf Exchange 2010-Postfächer funktionieren möglicherweise nicht, wenn sie über Exchange 2013-Clientzugriffsserver per Proxy gesendet werden: In einigen Situationen funktioniert die Proxyanforderung zwischen exchange 2013 und Exchange 2010 Service Pack 3 (SP3) ClientZugriffsservern ohne installierte Updaterollups möglicherweise nicht ordnungsgemäß, und es wird ein Fehler angezeigt. Dies kann passieren, wenn alle der folgenden Bedingungen erfüllt sind:

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

      • Die Option "Weiteres Postfach öffnen" in Outlook Web App -OR-

      • Die Option "Anderer Benutzer " im Exchange Admin Center

      • Auf dem Clientzugriffsserver, mit dem der Benutzer verbunden ist, wird Exchange 2013 ausgeführt.

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

    Wenn alle oben genannten Bedingungen erfüllt sind, kann der Benutzer nicht auf die Exchange 2010-Outlook Web App Optionen des anderen Benutzers zugreifen, und möglicherweise wird eine leere Seite angezeigt.

    Um dieses Problem zu umgehen, installieren Sie Exchange 2010 SP3 Update Rollup 1 oder höher auf jedem Exchange 2010-Server.