Versionshinweise zu Exchange 2013

Gilt für: Exchange Server 2013

Willkommen bei Microsoft Exchange Server 2013! Dieses Thema enthält wichtige Informationen, die Sie für die erfolgreiche Bereitstellung von 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 und Bereitstellung
Exchange-Verwaltungsshell
Postfach
Öffentliche Ordner
Nachrichtenübermittlung
Client-Konnektivität
Koexistenz mit Exchange 2010

Setup und Bereitstellung

msExchProductId spiegelt nicht die installierte Releaseversion von Exchange 2013 wider. Nachdem Exchange das Active Directory-Schema erweitert und Active Directory für Exchange vorbereitet hat, werden mehrere Eigenschaften aktualisiert, um anzuzeigen, 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 Configuration Namenskontext. 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 ist.

Dieses Verhalten wird erwartet, da der Wert von msExchProductId nicht der Version von Exchange 2013 entspricht, die installiert wird. Diese Eigenschaft spiegelt die Version von Exchange 2013 wider, die zuletzt Änderungen am Active Directory-Schema vorgenommen hat. Um Verwechslungen zu vermeiden, empfehlen wir, die Schritte im Abschnitt Woher wissen Sie, dass dies funktioniert hat? von Vorbereiten von Active Directory und Domänen zu befolgen, um sicherzustellen, dass Ihr Active Directory aktualisiert wurde und für die Version von Exchange 2013, die Sie installieren, bereit ist.
Setup fordert fälschlicherweise .NET Framework 4.0 an: Wenn Sie versuchen, Exchange 2013 zu installieren, ohne .NET Framework auf dem Computer installiert zu haben, fordert Setup fälschlicherweise an, dass Sie .NET Framework 4.0 installieren, obwohl eigentlich .NET Framework 4.5 oder höher erforderlich ist.

Installieren Sie .NET Framework 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 Exchange 2013 Voraussetzungen.
Exchange-XML-Anwendungskonfigurationsdateien werden während der Installation des kumulativen Updates überschrieben: Alle angepassten Exchange- oder Internetinformationsserver-Einstellungen 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 Exchange-Updates oder Service Packs 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 Planung und Bereitstellung.

Exchange-Verwaltungsshell

Die Shell lädt unerwartet Exchange 2007- oder Exchange 2010-Cmdlets Bisher führte das Öffnen der Shell auf einem Exchange 2013-Server dazu, dass die Shell eine Verbindung mit dem lokalen Server oder einem anderen Server öffnete, auf dem Exchange 2013 ausgeführt wurde. Wenn die Verbindung hergestellt ist, 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 kein Postfach hat, stellt die Shell eine Verbindung mit dem Server her, auf dem sich das Vermittlungspostfach SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} befindet. Der Zielserver kann eine beliebige unterstützte Version von Exchange sein. Das heißt, wenn sich das Postfach des angemeldeten Benutzers (oder das Vermittlungspostfach, wenn der Benutzer über kein Postfach verfügt) auf einem Exchange 2010-Server befindet, stellt die Shell eine Verbindung zu diesem Server her und lädt Exchange 2010-Cmdlets. Dadurch können Sie bestimmte Aufgaben möglicherweise nicht ausführen, da Exchange 2010-Cmdlets die Exchange 2013-Konfiguration 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 nach Exchange 2013. Wenn der angemeldete Benutzer kein Postfach hat, verschieben Sie das Vermittlungspostfach SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} auf einen Exchange 2013-Server.

Details und Informationen zum Verschieben des Vermittlungspostfachs finden Sie unter Exchange-Verwaltungsshell und Postfachverankerung 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 erlauben fälschlicherweise das Hinzufügen eines Exchange 2013-Servers zu einer Exchange 2016-basierten Database Availability Group (DAG) und umgekehrt. Exchange unterstützt nur das Hinzufügen von Postfachservern mit derselben Version (z. B. Exchange 2013 gegenüber Exchange 2016) zu einer DAG. Darüber hinaus zeigt das Exchange Admin Center sowohl Exchange 2013- als auch Exchange 2016-Server in der Liste der Server an, die verfügbar sind, um einer DAG hinzuzufügen. Dies könnte es einem Administrator ermöglichen, versehentlich einen Server, auf dem eine inkompatible Version von Exchange ausgeführt wird, zu einer DAG hinzuzufügen (z. B. das 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 sich die gemeldete Postfachgröße um 30 % bis 40 % erhöhen. Der von der Postfachdatenbank belegte Speicherplatz wurde nicht erhöht, nur die Zuordnung des von den einzelnen Postfächern belegten Speicherplatzes hat sich erhöht. Die Zunahme der Postfachgröße ist darauf zurückzuführen, dass alle Elementeigenschaften in die Kontingentberechnungen einbezogen werden, was eine genauere Berechnung des von Elementen in ihrem Postfach belegten Speicherplatzes ermöglicht. Diese Erhöhung kann dazu führen, dass einige Benutzer ihre Postfachgrößenkontingente überschreiten, wenn ihr Postfach zu 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 in den Cmdlets Set-MailboxDatabase bzw. Set-Mailbox.
Outlook 2007- und Outlook 2010-Clients können das Offlineadressbuch möglicherweise nicht herunterladen: Wenn die interne URL des Offlineadressbuchs (OAB) 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-organization 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-organization kann dazu führen, dass alle Clients in der organization eine neue Kopie des OAB herunterladen, was zu Netzwerksättigung und Problemen mit der Serverleistung führt. Dieses Problem tritt auf, weil Exchange 2013 ein neues Standard-OAB in der organization erstellt, das das Exchange 2007- oder Exchange 2010-OAB ersetzt. Für Postfächer, denen kein bestimmtes OAB zugewiesen ist oder die 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 erfolgen, bevor Exchange 2013 in der organization installiert wird.
Benutzer können an ein Postfach zur OAB-Generierung weitergeleitet werden, das nicht für das angeforderte OAB zuständig ist: Exchange 2013 CU5 und höher CUs haben die Art und Weise geändert, wie OABs mit OAB-Generierungspostfächern verknüpft werden. Diese Änderung ermöglicht es, dass ein Benutzer an ein OAB-Generierungspostfach weitergeleitet wird, das nicht für das OAB verantwortlich ist, das der Benutzer anfordert. Dies kann passieren, wenn alle folgenden Bedingungen erfüllt sind:
- Sie haben mehr als ein OAB-Generierungspostfach in Ihrer organization.
- Sie aktualisieren die Postfachserver, auf denen Postfächer der OAB-Generierung 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 eine Version 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 sie die Anforderungen an das OAB-Generierungspostfach weiterleiten, 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öglicht externen Absendern die Möglichkeit, E-Mails an E-Mail-aktivierte öffentliche Ordner zu senden, unabhängig von den für den öffentlichen Ordner festgelegten Berechtigungen.

Wenn Sie ab Exchange 2013 CU6 möchten, dass externe Absender E-Mails an einen E-Mail-aktivierten öffentlichen Ordner senden, muss dem anonymen Benutzer mindestens die Berechtigung "Elemente erstellen" erteilt werden. Wenn Sie E-Mail-fähige öffentliche Ordner eingerichtet haben und dies noch nicht getan haben, erhalten externe Absender eine Benachrichtigung über einen Übermittlungsfehler, 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 Batch-Migration zum Migrieren öffentlicher Ordner von früheren Versionen zu Exchange 2013.

Nachrichtenübermittlung

TransportAgent-Cmdlets auf Clientzugriffsservern erfordern lokale Windows PowerShell: Bei den *-TransportAgent-Cmdlets liegt ein Problem vor, das verhindert, dass diese Cmdlets Transport-Agents auf Clientzugriffsservern mithilfe der Exchange-Verwaltungsshell installieren, deinstallieren und 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 *-TransportAgent-Cmdlets 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 auf dem Clientzugriffsserver, den Sie verwalten möchten, die folgenden Schritte aus, um Transport-Agents auf Clientzugriffsservern zu installieren, zu deinstallieren oder zu verwalten:

Warnung

Das Laden des Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell-Snap-Ins und das Ausführen anderer Cmdlets als der TransportAgent-Cmdlets 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. Wir unterstützen nicht die Änderung von Zugriffssteuerungslisten (ACLs) für Exchange-Dateien, -Verzeichnisse oder Active Directory-Objekte.

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 diese Schritte auf jedem Clientzugriffsserver, den Sie verwalten möchten.

Client-Konnektivität

Die NTLM-Authentifizierung schlägt für nicht in die Domäne eingebundene Clients fehl: Die Authentifizierung zwischen einem Client, z. B. Windows Live Mail, und Exchange 2013 kann fehlschlagen, wenn die folgenden Bedingungen erfüllt sind:
- Die vom Client verwendete Authentifizierungsmethode ist NTLM.
- Der Computer ist nicht mit der Domäne verbunden.
Um dieses Problem zu umgehen, können Sie einen der folgenden Schritte ausführen:
- Verbinden Sie den Computer, auf dem der Client ausgeführt wird, mit der Domäne.
- Ändern Sie den Authentifizierungstyp, den der Client verwendet, von NTLM in Basic Auth über TLS.
Die GSSAPI-Authentifizierung schlägt fehl, wenn sie mit dem Send-MailMessage-Cmdlet 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 auf dem Exchange 2013-Clientzugriffsserver, der die Verbindung empfangen hat, ein Eintrag mit den folgenden Informationen im Anwendungsereignisprotokoll angezeigt:
- Quelle: MSExchangeFrontEndTransport
- Ereignis-ID: 1035
- Beschreibung: Eingehende Authentifizierung fehlgeschlagen mit Fehler IllegalMessage für den Namen >des Empfangsconnectorclient-Front-End-Servers<. Der Authentifizierungsmechanismus ist Gssapi. Die Quell-IP-Adresse des Clients, der versucht hat, sich bei Exchange zu authentifizieren, lautet [<Client-IP-Adresse>].
Um dieses Problem zu umgehen, müssen Sie die Integrated Authentifizierungsmethode aus dem Clientempfangsconnector auf Ihren Exchange 2013 Clientzugriffsservern entfernen. Um die Integrated Authentifizierungsmethode von einem Clientempfangsconnector 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 beim Upgrade auf Exchange 2013 SP1 eine schlechte Leistung aufweisen: Wenn Sie ein Upgrade von einem kumulativen Update für Exchange 2013 auf Exchange 2013 SP1 durchführen und MAPI über HTTP aktivieren, kann die Leistung von Clients, die über das Protokoll eine Verbindung mit einem Exchange 2013 SP1-Server herstellen, beeinträchtigt werden. Dies liegt daran, dass erforderliche Einstellungen während eines Upgrades von einem kumulativen Update auf Exchange 2013 SP1 nicht konfiguriert werden. Dieses Problem tritt nicht auf, wenn Sie von Exchange 2013 RTM auf Exchange 2013 SP1 aktualisieren 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. Es 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 Clientzugriffsserverrolle 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 Rolle "Postfachserver" 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 als Proxyserver verwendet werden: In einigen Situationen funktioniert die Proxyanforderung zwischen den 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 "Anderes Postfach öffnen" in Outlook Web App -ODER-
  - Die Option "Anderer Benutzer" im Exchange Admin Center
  - Auf dem Clientzugriffsserver, mit dem der Benutzer eine Verbindung hergestellt hat, wird Exchange 2013 ausgeführt.
  - Der Exchange 2010-Clientzugriffsserver wurde von der RTM-Version (Release to Manufacturing) von Exchange 2010 oder einem früheren Exchange 2010 Service Pack auf Exchange 2010 SP3 aktualisiert.
Wenn alle oben genannten Bedingungen zutreffen, 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 den Updaterollup 1 oder höher für Exchange 2010 SP3 auf jedem Exchange 2010-Server.

Last updated on 2026-08-19