In diesem Artikel erfahren Sie, wie Sie statische RPC-Ports für die Dienste RPC-Clientzugriff, Exchange-Adressbuch und Zugriff auf öffentliche Ordner in Exchange 2010 konfigurieren.

Stellen Sie sich vor, wir haben eine komplexe Organisation mit Austausch server 2010 SP1 (oder höher), das . CAS-Server befinden sich normalerweise in einem Netzwerk, das durch Firewalls von den Netzwerken getrennt ist, von denen Benutzer den Zugriff erwarten (Outlook-Netzwerke). Die Verbindung des Outlook-Clients zum CAS-Server erfolgt über RPC, das heißt auf Netzwerkschicht jeder Port im freien Portbereich kann verwendet werden. Es ist kein Geheimnis, dass in Windows Server 2008 und 2008 R2 verwenden 49152-65535 als dynamischen Portbereich für RPC-Verbindungen (vorherige Windows-Versionen Der Server verwendete RPC-Ports im Bereich 1025-65535).

Um zu verhindern, dass Firewalls zu einem „Sieb“ werden, ist es wünschenswert, den Bereich der verwendeten RPC-Ports einzuschränken, indem Sie sie idealerweise auf jedem Clientzugriffsserver im Clientzugriffsarray statisch machen. Darüber hinaus können Sie durch die Verwendung von statischen RPC-Ports den Speicherverbrauch auf Load Balancern (insbesondere HLB) reduzieren und ihre Konfiguration vereinfachen (keine Notwendigkeit, große Portbereiche anzugeben).

In Exchange 2010 können der RPC-Clientzugriffsdienst sowie der Exchange-Adressbuchdienst auf statische Ports festgelegt werden. Outlook kommuniziert mit diesen Diensten über die MAPI-Schnittstelle.

Statischer Port für den Exchange 2010-RPC-Clientzugriffsdienst

Der virtuelle Exchange 2010-RPC-Clientzugriffsdienst ist dem RPC-Clientzugriffsdienst zugeordnet, mit dem Outlook-MAPI-Clients in Exchange 2010 eine Verbindung herstellen. Wenn ein Outlook-Client auf einem Exchange 2010-Clientzugriffsserver eine Verbindung mit Exchange herstellt, verwendet der RPC-Clientzugriffsdienst den TCP-Endpunktzuordnungsport (TCP/135) und einen zufälligen Port aus dem dynamischen RPC-Portbereich (6005-59530) für eingehende Nachrichten Verbindungen

Um einen statischen Port für den RPC-Clientzugriffsdienst in Exchange 2010 festzulegen, müssen Sie den Abschnitt im Registrierungseditor öffnen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC

Erstellen Sie einen neuen Schlüssel mit dem Namen ParameterSystem, in dem ein Typparameter erstellt wird REG_DWORD Mit Namen TCP/IP-Port. Die TCP/IP-Porteinstellung gibt einen statischen Port für den RPC-Clientzugriffsdienst an. Die Microsoft-Dokumentation empfiehlt, einen Port im Bereich 59531 - 60554 zu wählen und diesen Wert auf allen CAS-Servern zu verwenden (wir haben natürlich Port 59532 angegeben, er sollte von keiner anderen Software verwendet werden).

Nach statischen Portzuweisungen müssen Sie den Microsoft Exchange RPC-Clientzugriffsdienst neu starten, damit die Änderungen wirksam werden.

Neustart-Dienst MSExchangeRPC

Statischer Port für den Exchange 2010-Adressbuchdienst

Vor SP1 verwendete Exchange 2010 eine spezielle Konfigurationsdatei, um den statischen Port des Exchange 2010-Adressbuchdiensts festzulegen Microsoft.exchange.addressbook.service.exe.config. Nach der Veröffentlichung von Exchange 2010 SP1 können Sie den statischen Port dieses Dienstes über die Registrierung festlegen. Öffnen Sie dazu den Registrierungseditor und gehen Sie zum Zweig:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters

Erstellen Sie einen neuen Parameter RpcTcpPort(vom Typ REG_SZ) und geben Sie ihm die Portnummer, die Sie für den Exchange-Adressbuchdienst reparieren möchten. Es wird empfohlen, einen beliebigen freien Port im Bereich 59531-60554 zu verwenden und ihn dann auf allen Exchange 2010-Clientzugriffsservern in der Domäne zu verwenden. Wir werden RpcTcpPort=59533 setzen

Danach müssen Sie den Microsoft Exchange-Adressbuchdienst neu starten

Neustart-Dienst MSExchangeAB

Wichtig: Bei der Migration von Exchange 2010 RTM zu SP1 muss dieser Schlüssel manuell gesetzt werden, er wird nicht automatisch vererbt.

Einrichten eines statischen Ports zum Verbinden mit freigegebenen Ordnern

Auf öffentliche Ordner wird von einem Outlook-Client direkt über den RPC-Clientzugriffsdienst auf einem Server mit der Postfachrolle zugegriffen. Diese Einstellung muss auf allen Servern mit der Mailbox-Rolle durchgeführt werden, die die Datenbank enthalten geteilte Ordner(ähnlich CAS-Servern). Öffnen Sie den Registrierungseditor und gehen Sie zum Zweig

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC

Erstellen Sie einen neuen Schlüssel mit dem Namen ParameterSystem, in dem ein Parameter vom Typ REG_DWORD mit dem Namen erstellt wird TCP/IP-Port. Stellen Sie seinen Wert ein: TCP/IP-Port = 59532.

Nachdem Sie den Port für öffentliche Ordner statisch festgelegt haben, müssen Sie den Microsoft Exchange RPC-Clientzugriffsdienst auf jedem Postfachserver neu starten.

Überprüfen Sie die statische Portnutzung zwischen Outlook und Exchange 2010

Nachdem die Änderungen vorgenommen wurden, überprüfen Sie, ob Outlook eine Verbindung zu den von uns angegebenen statischen RPC-Ports herstellt. Starten Sie dazu auf dem Clientcomputer Outlook neu und dann in Befehlszeile Führen Sie den Befehl aus:

Netstat -na

Anwendbar auf: Exchange Server 2010 SP1

Abschnitt zuletzt geändert: 2011-04-22

Dieser Abschnitt enthält Informationen zu Ports, Authentifizierung und Verschlüsselung für alle in Microsoft Exchange Server 2010 verwendeten Datenpfade. Der Abschnitt „Hinweise“ nach jeder Tabelle erläutert oder definiert nicht standardmäßige Authentifizierungs- oder Verschlüsselungsmethoden.

Transportserver

In Exchange 2010 gibt es zwei Serverrollen, die Nachrichtentransportfunktionen ausführen: ein Hub-Transport-Server und ein Edge-Transport-Server.

Die folgende Tabelle enthält Informationen zu Ports, Authentifizierung und Datenpfadverschlüsselung zwischen diesen Transportservern und anderen Exchange 2010-Servern und -Diensten.

Datenpfade für Transportserver

Datenweg	Erforderliche Ports			Verschlüsselungsunterstützung
Zwischen zwei Hub-Transport-Servern				Ja, mit TLS (Transport Layer Security)
Von einem Hub-Transport-Server zu einem Edge-Transport-Server		direktes Vertrauen	direktes Vertrauen	Ja, mit TLS
Von einem Edge-Transport-Server zu einem Hub-Transport-Server		direktes Vertrauen	direktes Vertrauen	Ja, mit TLS
Zwischen zwei Edge-Transport-Servern		Anonym, Zertifikatsauthentifizierung	Anonym, mit Zertifikat	Ja, mit TLS
Vom Server Postfächerüber den Microsoft Exchange Mail Submission Service		NTLM. Wenn die Hub-Transport-Serverrolle und die Postfach-Serverrolle auf demselben Server ausgeführt werden, wird das Kerberos-Protokoll verwendet.		Ja, mit RPC-Verschlüsselung
Von einem Hub-Transport-Server zu einem Postfachserver über MAPI		NTLM. Wenn die Hub-Transport-Serverrolle und die Postfach-Serverrolle auf demselben Server installiert sind, wird das Kerberos-Protokoll verwendet.		Ja, mit RPC-Verschlüsselung
				Ja, mit TLS
Microsoft Exchange EdgeSync-Dienst von einem Hub-Transport-Server zu einem Edge-Transport-Server				Ja, mit LDAP über SSL (LDAPS)
Greifen Sie von einem Hub-Transport-Server auf Active Directory zu
Zugriff auf den Active Directory-Rechteverwaltungsdienst (AD RMS) von einem Hub-Transport-Server				Ja, mit SSL
SMTP-Clients zu einem Hub-Transport-Server (z. B. Endbenutzer, die Windows Live Mail verwenden)				Ja, mit TLS

Hinweise für Transportserver

• Der gesamte Datenverkehr zwischen Hub-Transport-Servern wird mit Transport Layer Security (TLS) und den vom Exchange 2010-Setup installierten selbstsignierten Zertifikaten verschlüsselt.
• Der gesamte Datenverkehr zwischen Edge-Transport-Servern und Hub-Transport-Servern wird authentifiziert und verschlüsselt. Als Authentifizierungs- und Verschlüsselungsmechanismus wird gegenseitiges TLS verwendet. Anstelle der X.509-Validierung verwendet Exchange 2010 direktes Vertrauen. Direktes Vertrauen bedeutet, dass das Vorhandensein eines Zertifikats in Active Directory Services oder Active Directory Lightweight Directory Services (AD LDS) die Authentizität des Zertifikats überprüft. Der Active Directory-Verzeichnisdienst gilt als vertrauenswürdiger Speichermechanismus. Bei der Verwendung von direktem Vertrauen spielt es keine Rolle, ob ein selbstsigniertes Zertifikat oder ein von einer Zertifizierungsstelle signiertes Zertifikat verwendet wird. Wenn Sie einen Edge-Transport-Server bei einer Exchange-Organisation abonnieren, veröffentlicht das Edge-Abonnement das Zertifikat des Edge-Transport-Servers im Active Directory-Verzeichnisdienst, damit Hub-Transport-Server es überprüfen können. Der Microsoft Exchange EdgeSync-Dienst fügt Active Directory Lightweight Directory Services (AD LDS) einen Satz von Hub-Transport-Serverzertifikaten hinzu, damit der Edge-Transport-Server sie validieren kann.
• EdgeSync verwendet eine sichere LDAP-Verbindung von einem Hub-Transport-Server zu abonnierten Edge-Transport-Servern auf TCP-Port 50636. Active Directory Lightweight Directory Services überwacht auch TCP-Port 50389. Verbindungen zu diesem Port verwenden kein SSL. Sie können LDAP-Dienstprogramme verwenden, um eine Verbindung zu diesem Port herzustellen und AD LDS-Daten zu überprüfen.
• Standardmäßig wird der Datenverkehr zwischen Edge-Transport-Servern in zwei verschiedenen Organisationen verschlüsselt. Das Exchange 2010-Setup erstellt ein selbstsigniertes Zertifikat und aktiviert standardmäßig TLS. Dadurch kann jedes sendende System eine eingehende SMTP-Sitzung zu Exchange verschlüsseln. Standardmäßig versucht Exchange 2010 auch, TLS für alle Remoteverbindungen zu verwenden.
• Die Authentifizierungsmethoden für den Datenverkehr zwischen Hub-Transport-Servern und Postfachservern sind unterschiedlich, wenn die Hub-Transport- und Postfach-Serverrollen auf demselben Computer installiert sind. Die lokale E-Mail-Übertragung verwendet die Kerberos-Authentifizierung. Die Remote-E-Mail-Übertragung verwendet die NTLM-Authentifizierung.
• Exchange 2010 unterstützt auch die Domänensicherheit. Domänensicherheit ist eine Reihe von Features von Exchange 2010 und Microsoft Outlook 2010, die eine kostengünstige Alternative zu S/MIME und anderen Internet-Messaging-Sicherheitslösungen bieten. Domänensicherheit bietet eine Möglichkeit, sichere Kommunikationspfade zwischen Domänen im Internet zu verwalten. Sobald diese sicheren Pfade konfiguriert sind, werden Nachrichten, die von einem authentifizierten Absender erfolgreich über sie gesendet wurden, Benutzern von Outlook und Outlook Web Access als "geschützte" Nachrichten auf Domänenebene angezeigt. Weitere Informationen finden Sie unter Übersicht über die Domänensicherheit.
• Viele Agents können sowohl auf Hub-Transport-Servern als auch auf Edge-Transport-Servern ausgeführt werden. Typischerweise Schutzmittel Junk-Mail Informationen verwenden lokalen Computer auf denen sie ausgeführt werden. Also Interaktion mit entfernte Computer. Die Ausnahme ist die Empfängerfilterung. Die Empfängerfilterung erfordert einen AD LDS- oder Active Directory-Aufruf. Wir empfehlen, dass Sie die Empfängerfilterung auf einem Edge-Transport-Server durchführen. In diesem Fall befindet sich das AD LDS-Verzeichnis auf demselben Computer, auf dem die Edge-Transport-Serverrolle installiert ist, sodass keine Remoteverbindung erforderlich ist. Wenn die Empfängerfilterung auf einem Hub-Transport-Server installiert und konfiguriert ist, ist Zugriff auf den Active Directory-Verzeichnisdienst erforderlich.
• Der Protokollanalyse-Agent wird von der Absenderzuverlässigkeitsfunktion in Exchange 2010 verwendet. Dieser Agent stellt auch eine Verbindung zu verschiedenen externen Proxyservern her, um eingehende Nachrichtenpfade für verdächtige Verbindungen zu ermitteln.
• Alle anderen Anti-Spam-Funktionen verwenden Daten, die gesammelt, gespeichert und nur auf dem lokalen Computer verfügbar sind. In der Regel werden Daten wie die kombinierte Liste sicherer Absender oder Empfängerdaten für die Empfängerfilterung mithilfe des Microsoft Exchange EdgeSync-Diensts in das lokale AD LDS-Verzeichnis übertragen.
• Information Rights Management (IRM)-Agents auf Hub-Transport-Servern stellen eine Verbindung mit Active Directory Rights Management Services (AD RMS)-Servern in der Organisation her. Active Directory Rights Management Service (AD RMS) ist ein Webdienst, den wir zum Sichern mit SSL empfehlen. Verbindungen zu AD RMS-Servern werden über HTTPS hergestellt und je nach Konfiguration des AD RMS-Servers entweder über Kerberos oder NTLM authentifiziert.
• Protokollregeln, Transportregeln und Nwerden in Active Directory gespeichert und vom Protokollierungs-Agent und dem Transportregel-Agent auf Hub-Transport-Servern aufgerufen.

  Mailbox-Server

  Ob auf Postfachservern NTLM- oder Kerberos-Authentifizierung verwendet wird, hängt vom Benutzerkontext oder Prozess ab, unter dem der Verbraucher der Exchange-Geschäftslogikschicht ausgeführt wird. In diesem Zusammenhang sind Verbraucher alle Anwendungen oder Prozesse, die die Ebene der Exchange-Geschäftslogik verwenden. Als Ergebnis in der Spalte Standardauthentifizierung Tische Datenpfade für Postfachserver Viele Zeilen haben einen Wert NTLM/Kerberos.

  Die Ebene der Exchange-Geschäftslogik wird verwendet, um auf den Exchange-Informationsspeicher zuzugreifen und mit ihm zu interagieren. Die Exchange-Geschäftslogikebene wird auch vom Exchange-Informationsspeicher aufgerufen, um mit externen Anwendungen und Prozessen zu interagieren.

  Wenn ein Consumer der Exchange-Geschäftslogikschicht im lokalen Systemkontext ausgeführt wird, ist die Authentifizierungsmethode des Consumers für den Zugriff auf den Exchange-Informationsspeicher immer Kerberos. Die Kerberos-Authentifizierungsmethode wird verwendet, da der Empfänger mit authentifiziert werden muss Konto Computer "Lokales System" und erfordert bidirektionales Vertrauen mit Authentifizierung.

  Wenn der Empfänger der Exchange-Geschäftslogikebene nicht im Kontext des lokalen Systems ausgeführt wird, ist die Authentifizierungsmethode NTLM. Wenn ein Administrator beispielsweise ein Cmdlet der Exchange-Verwaltungsshell ausführt, das die Ebene der Exchange-Geschäftslogik verwendet, wird die NTLM-Authentifizierung verwendet.

  RPC-Datenverkehr ist immer verschlüsselt.

  Die folgende Tabelle enthält Informationen zu Ports, Authentifizierung und Datenpfadverschlüsselung für Postfachserver.

  Datenpfade für Postfachserver

  Datenweg	Erforderliche Ports	Standardauthentifizierung	Unterstützte Authentifizierungsmethode	Verschlüsselungsunterstützung	Datenverschlüsselung standardmäßig
  	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC-Netzanmeldung)			Ja, mit Kerberos-Verschlüsselung
  Administrativer Fernzugriff (Remote Registry)				Ja, mit IPsec
  Administrativer Fernzugriff (SMB, Dateien)				Ja, mit IPsec
  Verfügbarkeits-Webdienst (Client-Mailbox-Zugriff)				Ja, mit RPC-Verschlüsselung
  Clustering				Ja, mit RPC-Verschlüsselung
  Zwischen Clientzugriffsservern (Exchange ActiveSync)	80/TCP, 443/TCP (SSL)		Kerberos, Zertifikatsauthentifizierung	Ja, mit HTTPS	Ja, mit einem selbstsignierten Zertifikat
  Zwischen Clientzugriffsservern (Outlook Web Access)	80/TCP, 443/TCP (HTTPS)			Ja, mit SSL
  Clientzugriffsserver zu Clientzugriffsserver (Exchange-Webdienste)				Ja, mit SSL
  Clientzugriffsserver zu Clientzugriffsserver (POP3)				Ja, mit SSL
  Clientzugriffsserver zu Clientzugriffsserver (IMAP4)				Ja, mit SSL
  Office Communications Server zu Clientzugriffsserver (wenn die Office Communications Server- und Outlook Web App-Integration aktiviert ist)	5075-5077/TCP (EIN), 5061/TCP (AUS)	mTLS (erforderlich)	mTLS (erforderlich)	Ja, mit SSL

  Hinweise für Clientzugriffsserver

  Server einheitliches System Nachrichtenübermittlung

  IP-Gateways und IP-PBX-Anlagen unterstützen nur die Zertifikatsauthentifizierung, die die gegenseitige TLS-Authentifizierung zum Verschlüsseln des SIP-Datenverkehrs und die auf IP-Adressen basierende Authentifizierung für SIP- oder TCP-Verbindungen verwendet. IP-Gateways unterstützen keine NTLM- und Kerberos-Authentifizierung. Daher verwendet der Authentifizierungsmechanismus für unverschlüsselte Verbindungen (TCP) bei Verwendung der IP-Adressen-basierten Authentifizierung die IP-Adressen der Verbindungen. Bei Verwendung in Unified Messaging prüft die IP-basierte Authentifizierung, ob die angegebene IP-Adresse eine Verbindung herstellen darf. Die IP-Adresse wird auf dem IP-Gateway oder der IP-PBX konfiguriert.

  IP-Gateways und IP-PBX-Anlagen unterstützen Mutual TLS zum Verschlüsseln des SIP-Datenverkehrs. Nach dem erfolgreichen Importieren und Exportieren der erforderlichen vertrauenswürdigen Zertifikate fordert das IP-Gateway oder die IP-PBX ein Zertifikat vom Unified Messaging-Server an und fordert dann ein Zertifikat vom IP-Gateway oder der IP-PBX an. Der Austausch vertrauenswürdiger Zertifikate zwischen dem IP-Gateway oder der IP-PBX und dem Unified Messaging-Server ermöglicht beiden Geräten die sichere Kommunikation über Mutual TLS.

  Die folgende Tabelle enthält Port-, Authentifizierungs- und Verschlüsselungsinformationen für Datenpfade zwischen UM-Servern und anderen Servern.

  Datenpfade für Unified Messaging-Server

  Datenweg	Erforderliche Ports	Standardauthentifizierung	Unterstützte Authentifizierungsmethode	Verschlüsselungsunterstützung	Datenverschlüsselung standardmäßig
  Zugriff auf Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC-Netzanmeldung)			Ja, mit Kerberos-Verschlüsselung
  UM-Einwahl (IP-PBX/VoIP-Gateway)	5060/TCP , 5065/TCP, 5067/TCP (im nicht sicheren Modus), 5061/TCP, 5066/TCP, 5068/TCP (im sicheren Modus), dynamischer Portbereich 16000–17000/TCP (Verwaltung), dynamisches UDP Ports aus dem Bereich 1024-65535/UDP (RTP)	Nach IP-Adresse	Nach IP-Adresse, MTLS	Ja, mit SIP/TLS, SRTP
  UM-Webdienst	80/TCP, 443/TCP (SSL)	Integrierte Windows-Authentifizierung (Aushandeln)		Ja, mit SSL
  Von einem Unified Messaging-Server zu einem Clientzugriffsserver	5075, 5076, 5077 (TCP)	Integrierte Windows-Authentifizierung (Aushandlung)	Basic, Digest, NTLM, Negotiate (Kerberos)	Ja, mit SSL
  UM-Server zu Clientzugriffsserver (Wiedergabe auf dem Telefon)	Dynamischer RPC			Ja, mit RPC-Verschlüsselung
  Von einem Unified Messaging-Server zu einem Hub-Transport-Server				Ja, mit TLS
  Von einem Unified Messaging-Server zu einem Postfachserver				Ja, mit RPC-Verschlüsselung

  Hinweise für Unified Messaging-Server

  • Wenn Sie ein UM-IP-Gateway-Objekt in Active Directory erstellen, müssen Sie die IP-Adresse des physischen IP-Gateways oder der IP-PBX definieren. Wenn Sie die IP-Adresse des UM-IP-Gateway-Objekts bestimmen, wird die IP-Adresse der Liste gültiger IP-Gateways oder IP-PBX-Anlagen (auch als SIP-Sitzungsteilnehmer bezeichnet) hinzugefügt, mit denen der UM-Server kommunizieren darf. Nachdem Sie ein UM-IP-Gateway erstellt haben, können Sie es einem UM-Wählplan zuordnen. Durch das Zuordnen eines UM-IP-Gateways zu einem Wählplan können UM-Server, die einem Wählplan zugeordnet sind, die IP-Adressen-basierte Authentifizierung für die Kommunikation mit dem IP-Gateway verwenden. Wenn das UM-IP-Gateway nicht für die Verwendung der richtigen IP-Adresse erstellt oder konfiguriert wurde, schlägt die Authentifizierung fehl, und die UM-Server akzeptieren keine Verbindungen von der IP-Adresse dieses IP-Gateways. Wenn Sie darüber hinaus gegenseitiges TLS, ein IP-Gateway oder eine IP-PBX-Anlage und Unified Messaging-Server implementieren, muss das UM-IP-Gateway für die Verwendung eines vollqualifizierten Domänennamens (FQDN) konfiguriert werden. Nachdem Sie ein UM-IP-Gateway mithilfe des FQDN konfiguriert haben, müssen Sie der Forward-DNS-Lookupzone auch einen Hosteintrag für das Gateway hinzufügen.
  • In Exchange 2010 kann der Unified Messaging-Server über Port 5060/TCP (nicht sicher) oder Port 5061/TCP (sicher) kommunizieren und für die Verwendung beider Ports konfiguriert werden.

  Weitere Informationen finden Sie unter Grundlegendes zur UM-VoIP-Sicherheit und Grundlegendes zu Protokollen, Ports und Diensten in Unified Messaging .

  Regeln Windows-Firewall vom Exchange 2010-Setup erstellt

  Die Windows-Firewall mit erweiterter Sicherheit ist eine zustandsbehaftete computerbasierte Firewall, die eingehenden und ausgehenden Datenverkehr basierend auf Firewallregeln filtert. Das Exchange 2010-Setup erstellt Windows-Firewallregeln, um die Ports zu öffnen, die für die Server- und Clientkommunikation in jeder Serverrolle erforderlich sind. Daher müssen Sie den SCW nicht mehr verwenden, um diese Einstellungen zu konfigurieren. Weitere Informationen zur Windows-Firewall mit erweiterter Sicherheit finden Sie unter Windows-Firewall mit erweiterter Sicherheit und IPsec.

  Die folgende Tabelle listet die Windows-Firewallregeln auf, vom Programm generiert Exchange-Installationen, einschließlich der Ports, die für jede Serverrolle geöffnet sind. Sie können diese Regeln anzeigen, indem Sie das MMC-Snap-In „Windows-Firewall mit erweiterter Sicherheit“ verwenden.

  Regelname	Serverrollen	Hafen	Programm
  MSExchangeADTopology – RPC (TCP-Eingang)		Dynamischer RPC	Bin\MSExchangeADTopologyService.exe
  MSExchangeMonitoring – RPC (TCP-Eingang)	Clientzugriffsserver, Hub-Transport-Server, Edge-Transport-Server, Unified Messaging-Server	Dynamischer RPC	Bin\Microsoft.Exchange.Management.Monitoring.exe
  MSExchangeServiceHost – RPC (TCP-Eingang)		Dynamischer RPC	Bin\Microsoft.Exchange.ServiceHost.exe
  MSExchangeServiceHost – RPCEPMap (TCP-Eingang)			Bin\Microsoft.Exchange.Service.Host
  MSExchangeRPCEPMap (GFW) (TCP-Eingang)
  MSExchangeRPC (GFW) (TCP-Eingang)	Clientzugriffsserver, Hub-Transport-Server, Postfachserver, Unified Messaging-Server	Dynamischer RPC
  MSExchange - IMAP4 (GFW) (TCP-Eingang)	Clientzugriffsserver
  MSExchangeIMAP4 (TCP-Eingang)	Clientzugriffsserver		ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
  MSExchange - POP3 (FGW) (TCP-Eingang)	Clientzugriffsserver
  MSExchange - POP3 (TCP-Eingang)	Clientzugriffsserver		ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
  MSExchange - OWA (GFW) (TCP-Eingang)	Clientzugriffsserver	5075, 5076, 5077 (TCP)
  MSExchangeOWAAppPool (TCP-Eingang)	Clientzugriffsserver	5075, 5076, 5077 (TCP)	inetsrv\w3wp.exe
  MSExchangeAB RPC (TCP eingehend)	Clientzugriffsserver	Dynamischer RPC
  MSExchangeAB-RPCEPMap (TCP-Eingang)	Clientzugriffsserver		Bin\Microsoft.Exchange.AddressBook.Service.exe
  MSExchangeAB-RpcHttp (TCP-Eingang)	Clientzugriffsserver	6002, 6004 (TCP)	Bin\Microsoft.Exchange.AddressBook.Service.exe
  RpcHttpLBS (TCP-Eingang)	Clientzugriffsserver	Dynamischer RPC	System32\Svchost.exe
  MSExchangeRPC - RPC (TCP-Eingang)		Dynamischer RPC
  MSExchangeRPC - PRCEPMap (TCP-Eingang)	Clientzugriffsserver, Postfachserver		Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeRPC (TCP eingehend)	Clientzugriffsserver, Postfachserver		Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeMailboxReplication (GFW) (TCP eingehend)	Clientzugriffsserver
  MSExchangeMailboxReplication (TCP eingehend)	Clientzugriffsserver		Bin\MSExchangeMailboxReplication.exe
  MSExchangeIS – RPC (TCP-Eingang)	Mailbox-Server	Dynamischer RPC
  MSExchangeIS RPCEPMap (TCP-Eingang)	Mailbox-Server
  MSExchangeIS (GFW) (TCP-Eingang)	Mailbox-Server	6001, 6002, 6003, 6004 (TCP)
  MSExchangeIS (TCP-Eingang)	Mailbox-Server
  MSExchangeMailboxAssistants – RPC (TCP eingehend)	Mailbox-Server	Dynamischer RPC
  MSExchangeMailboxAssistants – RPCEPMap (TCP-Eingang)	Mailbox-Server		Bin\MSExchangeMailboxAssistants.exe
  MSExchangeMailSubmission – RPC (TCP-Eingang)	Mailbox-Server	Dynamischer RPC
  MSExchangeMailSubmission – RPCEPMap (TCP-Eingang)	Mailbox-Server		Bin\MSExchangeMailSubmission.exe
  MSExchangeMigration – RPC (TCP eingehend)	Mailbox-Server	Dynamischer RPC	Bin\MSExchangeMigration.exe
  MSExchangeMigration – RPCEPMap (TCP-Eingang)	Mailbox-Server		Bin\MSExchangeMigration.exe
  MSExchangerepl – Protokollkopierer (TCP-Eingang)	Mailbox-Server		Bin\MSExchangeRepl.exe
  MSExchangerepl - RPC (TCP-Eingang)	Mailbox-Server	Dynamischer RPC	Bin\MSExchangeRepl.exe
  MSExchangerepl - RPC-EPMap (TCP-Eingang)	Mailbox-Server		Bin\MSExchangeRepl.exe
  MSExchangeSearch – RPC (TCP-Eingang)	Mailbox-Server	Dynamischer RPC	Bin\Microsoft.Exchange.Search.ExSearch.exe
  MSExchangeThrottling – RPC (eingehender TCP-Verkehr)	Mailbox-Server	Dynamischer RPC	Bin\MSExchangeThrottling.exe
  MSExchangeThrottling – RPCEPMap (eingehender TCP-Verkehr)	Mailbox-Server		Bin\MSExchangeThrottling.exe
  MSFTED - RPC (TCP-Eingang)	Mailbox-Server	Dynamischer RPC
  MSFTED - RPCEPMap (TCP-Eingang)	Mailbox-Server
  MSExchangeEdgeSync – RPC (TCP-Eingang)	Hub-Transport-Server	Dynamischer RPC
  MSExchangeEdgeSync RPCEPMap (TCP eingehend)	Hub-Transport-Server		Bin\Microsoft.Exchange.EdgeSyncSvc.exe
  MSExchangeTransportWorker – RPC (TCP-Eingang)	Hub-Transport-Server	Dynamischer RPC	Bin\edgetransport.exe
  MSExchangeTransportWorker – RPCEPMap (TCP-Eingang)	Hub-Transport-Server		Bin\edgetransport.exe
  MSExchangeTransportWorker (GFW) (TCP-Eingang)	Hub-Transport-Server
  MSExchangeTransportWorker (TCP-Eingang)	Hub-Transport-Server		Bin\edgetransport.exe
  MSExchangeTransportLogSearch – RPC (TCP-Eingang)		Dynamischer RPC
  MSExchangeTransportLogSearch – RPCEPMap (TCP-Eingang)	Hub-Transport-Server, Edge-Transport-Server, Postfachserver		Bin\MSExchangeTransportLogSearch.exe
  SESWorker (GFW) (TCP-Eingang)	Unified Messaging-Server
  SESWorker (TCP-Eingang)	Unified Messaging-Server		UnifiedMessaging\SESWorker.exe
  UMService (GFW) (TCP-Eingang)	Unified Messaging-Server
  UMService (TCP-Eingang)	Unified Messaging-Server		Bin\UMService.exe
  UMWorkerProcess (GFW) (TCP-Eingang)	Unified Messaging-Server	5065, 5066, 5067, 5068
  UMWorkerProcess (TCP-Eingang)	Unified Messaging-Server	5065, 5066, 5067, 5068	Bin\UMWorkerProcess.exe
  UMWorkerProcess - RPC (TCP-Eingang)	Unified Messaging-Server	Dynamischer RPC	Bin\UMWorkerProcess.exe

  Hinweise zu Windows-Firewallregeln, die vom Exchange 2010-Setup erstellt wurden

  • Auf Servern mit installiertem IIS öffnet Windows die Ports HTTP (Port 80, TCP) und HTTPS (Port 443, TCP). Exchange 2010 Setup öffnet diese Ports nicht. Daher sind diese Ports nicht in der vorherigen Tabelle aufgeführt.
  • In Windows Server 2008 und Windows Server 2008 R2 können Sie mit der Windows-Firewall mit erweiterter Sicherheit einen Prozess oder Dienst angeben, für den ein Port geöffnet ist. Dies ist sicherer, da der Port nur von dem in der Regel angegebenen Prozess oder Dienst verwendet werden kann. Das Exchange-Setup erstellt Firewallregeln mit dem angegebenen Prozessnamen. In einigen Fällen wird aus Kompatibilitätsgründen auch eine zusätzliche Regel erstellt, die nicht auf diesen Vorgang beschränkt ist. Sie können nicht prozessbeschränkte Regeln deaktivieren oder entfernen und die entsprechenden prozessbeschränkten Regeln beibehalten, wenn Ihre aktuelle Bereitstellungsumgebung sie unterstützt. Regeln, die nicht auf Prozesse beschränkt sind, können durch das Wort unterschieden werden (GFW) im Namen der Regel.
  • Viele Exchange-Dienste verwenden für die Kommunikation Remoteprozeduraufrufe (RPC). Serverprozesse, die Fernprozeduraufrufe verwenden, stellen eine Verbindung mit dem RPC-Endpunkt-Mapper her, um dynamische Endpunkte abzurufen und sie in der Endpunkt-Mapper-Datenbank zu registrieren. RPC-Clients interagieren mit der RPC-Endpunktzuordnung, um die vom Serverprozess verwendeten Endpunkte zu ermitteln. Standardmäßig überwacht die RPC-Endpunktzuordnung Port 135 (TCP). Wenn Sie die Windows-Firewall für einen Prozess konfigurieren, der Remoteprozeduraufrufe verwendet, erstellt das Exchange 2010-Setup zwei Firewallregeln für diesen Prozess. Eine Regel ermöglicht die Kommunikation mit dem RPC-Endpunkt-Mapper, und die zweite Regel ermöglicht die Kommunikation mit einem dynamisch zugewiesenen Endpunkt. Weitere Informationen zu Remoteprozeduraufrufen finden Sie im Artikel. Weitere Informationen zum Erstellen von Windows-Firewallregeln für dynamische Remoteprozeduraufrufe finden Sie im Artikel.

    Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 179442

www.microsoft.com

Artikel Exchange 2013-Front-End-Transportdienst ist der erste einer Reihe von Artikeln zur Funktionsweise der Transportdienste von Exchange Server 2013. Dieser Artikel konzentriert sich auf Front-End-Transportdienst auf Clientzugriffsservern.

In der Version 2013 des Exchange-Servers gab es ziemlich starke Änderungen in der Architektur und jetzt gibt es nur noch zwei Hauptrollen – den Postfachserver (Mailbox Server oder kurz MBX) und den Clientzugriffsserver (Client Access Server – CAS). Herausragend ist die Rolle des Edge-Transport-Servers. Service Exchange 2013 Front-End-Transport befindet sich auf CAS-Servern und fungiert als Proxy.

Dies ist der erste Artikel in einer Reihe über die Funktionsweise der Exchange 2013-Transportpipelinedienste, aber hier ist die vollständige Liste:

Sowie Artikel zur Verwaltung der Protokollierung dieser Dienste:

Vergessen Sie nicht die offizielle Dokumentation.

Weitere Informationen zur Konfiguration und Verwaltung von Exchange 2013 finden Sie in meinem Blog im Hauptthema Artikel -.

Es ist einfach so, dass es in Exchange 2013 inzwischen eine ganze Reihe von Transportdiensten gibt, die ähnliche Namen haben, sich aber grundlegend in Zweck und Funktionsweise unterscheiden. Hier sind alle diese Dienste:

• Front-End-Transportdienst auf Clientzugriffsservern (Anzeigename ist Microsoft Exchange FrontEnd Transport, abgekürzt als MSExchangeFrontEndTransport);
• Transport-Service auf Postfachservern (Anzeigename ist Microsoft Exchange Transport, abgekürzt MSExchangeTransport);
• Postfachtransportdienst auf Postfachservern (beinhaltet wirklich zwei Dienste – Microsoft Exchange Mailbox Transport Delivery und Microsoft Exchange Mailbox Transport Submission, abgekürzte Namen – MSExchangeDelivery bzw. MSExchangeSubmission);
• Transportdienst auf Edge-Transport-Servern (Anzeigename ist Microsoft Exchange Transport, abgekürzt als MSExchangeTransport).

Dabei erfüllen nur der zweite und der vierte Dienst eine vergleichbare Funktionalität, der Rest unterscheidet sich grundlegend. Zusammen bilden sie alle die Transportpipeline, die das Herzstück des Mailservers darstellt.

Transportband

Im Allgemeinen sieht die Transportpipeline so aus:

Uns interessiert im Rahmen dieses Artikels der obere Teil der Abbildung, der den Client Access Server zeigt:

Es gibt eine Nuance in diesem Schema. Tatsache ist, dass MBX-Server standardmäßig E-Mails unabhängig über Port 25 SMTP versenden können. Um sicherzustellen, dass ein Sendeconnector E-Mails immer über Clientzugriffsserver an das Internet sendet, müssen Sie den Sendeconnector-Parameter explizit auf festlegen FrontendProxyaktiviert in die Bedeutung $wahr(oder aktivieren Sie in der EAC das Kontrollkästchen Proxy über den Clientzugriffsserver in den Eigenschaften des Sendeconnectors). Auf dieser Konfiguration werde ich in Zukunft aufbauen.

Im Folgenden werde ich versuchen, das Funktionsprinzip etwas klarer zu machen. Exchange 2013-Server mit der CAS-Rolle.

Arbeitsprinzip

Front-End-Transport(in der Microsoft-Terminologie - Front-End-Transportdienst) verarbeitet keine Nachrichteninhalte, verwendet keine Nachrichtenwarteschlange und interagiert nicht mit dem Postfachtransportdienst. Mit anderen Worten, Exchange 2013-Server mit nur der CAS-Rolle speichern Daten weder dauerhaft (unter Verwendung einer Datenbank) noch vorübergehend (in einer Nachrichtenverarbeitungswarteschlange).

Der Front-End-Transportdienst verfügt jedoch über eigene Transportagenten (siehe Abbildung – Protokollagenten). Mit Agents können Sie die Funktionalität eines Exchange-Mailservers erweitern, indem Sie der Nachrichtenverarbeitungslogik benutzerdefinierten Code hinzufügen. Agenten werden aufgerufen, wenn SMTP-Ereignisse auftreten. Diese Ereignisse wiederum werden in der einen oder anderen Phase der Nachrichtenverarbeitung generiert, wenn sie die Transportpipeline durchlaufen. Es ist erwähnenswert, dass die meisten der standardmäßig vorhandenen Agenten ausgeblendet sind oder ihre Einstellungen nicht gesteuert werden können. Die Funktionalität von Agenten auf CAS-Servern ist ziemlich eingeschränkt und nur für die MBX- und Edge-Rollen vollständig vorhanden.

Sende- und Empfangsconnectors

Auf dem Diagramm (siehe oben) Front-End-Transportdienst Wir bezeichnen den Clientzugriffsserver auf jedem eingehenden und ausgehende Verbindung entsprechenden Port, wodurch sich folgende Darstellung ergibt:

Ein separater Empfangsconnector ist für das Abhören von Verbindungen an jedem im Diagramm angegebenen Port verantwortlich, von denen standardmäßig drei Teile erstellt werden, wenn die CAS-Rolle installiert wird:

Neben sichtbaren und für den Administrator zugänglichen Konnektoren gibt es auch versteckte System-Sendekonnektoren:

• Interner Proxy-Sendeconnector für eingehenden Datenverkehr (SMTP 25/2525 in )
• Client-Proxy-Sendeconnector (SMTP empfangen auf Port 587 in Transportdienst auf Postfachservern an Port 465)

Übrigens wird der erste Connector in der russischen Version von Exchange Server 2013 den Namen haben Interner Sendeanschluss für Eingang. Anschluss Proxy-Server, und zweitens - Client-Proxy-Sendeconnector. Dies ist nur für den Fall, um beim ersten Treffen mit diesen Anschlüssen nicht in eine Benommenheit zu geraten.

Als Ergebnis erhalten wir die folgende vollständige Tabelle:

Name	Zweck	Hafen	Richtung
Standard-Frontend	Rezeption	25	Von externen Servern
Outbound-Proxy-Frontend	Rezeption	717	Von MBX-Servern
Client-Frontend	Rezeption	587	Von externen Clients sichere Verbindung
Client-Proxy-Sendeconnector	Senden	465	Zu MBX-Servern
Interner Proxy-Sendeconnector für eingehenden Datenverkehr	Senden	25/2525	Zu MBX-Servern. Es werden nur Verbindungen auf Port 587 akzeptiert
Manuell erstellter Sendeconnector	Senden	25	An externe Server

Übertragen wir die Namen der Anschlüsse in das Diagramm Front-End-Transportdienst.

Exchange-Server und Firewalls

Firewalls (Firewalls) für Mailserver (Exchange Server), Mailserver-Ports, Frontend- und Backend-Mailserver, Virtuelle Server SMTP, POP3, IMAP4

Wie jeder mit dem Internet verbundene Computer muss der Computer, der den Mailserver hostet, mit einer Firewall geschützt werden. Gleichzeitig können die Optionen für die Installation eines Mailservers in Bezug auf die Netzwerkkonfiguration sehr unterschiedlich sein:

· Die einfachste Möglichkeit besteht darin, einen Mailserver auf einem Computer zu installieren, der auch Proxy/Firewall ist, und dann die erforderlichen Ports auf der Schnittstelle zum Internet zu öffnen. Typischerweise wird dieses Schema in kleinen Organisationen verwendet;

Eine andere Möglichkeit ist die Installation des Mailservers in lokales Netzwerk und konfigurieren Sie es so, dass es über einen Proxy-Server funktioniert. Dazu können Sie die öffentliche IP-Adresse an den Mailserver binden und über einen Proxy weiterleiten oder Port-Mapping-Tools auf dem Proxyserver verwenden. Viele Proxyserver verfügen über spezielle Assistenten oder vordefinierte Regeln zum Organisieren einer solchen Lösung (z. B. in ISA Server). Diese Option wird in den meisten Organisationen verwendet.

· Eine andere grundsätzliche Möglichkeit besteht darin, eine DMZ zu erstellen und darin einen Frontend-Exchange-Server (eine solche Möglichkeit gibt es seit Version 2000) oder ein SMTP-Relay auf der Grundlage eines anderen Exchange-Servers oder beispielsweise sendmail on *nix zu platzieren. Wird normalerweise in Netzwerken großer Organisationen verwendet.

In jedem Fall muss der Mailserver die Kommunikation mindestens auf TCP-Port 25 (SMTP) und UDP-Port 53 (DNS) sicherstellen. Andere Ports, die je nach Ihrer Netzwerkkonfiguration möglicherweise von Exchange Server benötigt werden (alle TCP):

80 HTTP - für den Zugriff auf die Webschnittstelle (OWA)

· 88 Kerberos-Authentifizierungsprotokoll – wenn Kerberos-Authentifizierung verwendet wird (selten);

· 102 MTA .X .400 Connector über TCP /IP (wenn X .400 Connector für die Kommunikation zwischen Routinggruppen verwendet wird);

· 110 Post Office Protocol 3 (POP 3) – für Clientzugriff;

· 119 Network News Transfer Protocol (NNTP) – wenn Newsgroups verwendet werden;

135 Client/Server-Kommunikation RPC-Exchange-Verwaltung – Standard-RPC-Port für Remote-Exchange-Verwaltung Standard bedeutet Systemmanager;

· 143 Internet Message Access Protocol (IMAP) - für den Kundenzugang;

· 389 LDAP – um auf den Verzeichnisdienst zuzugreifen;

· 443 HTTP (Secure Sockets Layer (SSL)) (und darunter) – dieselben Protokolle, die durch SSL geschützt sind.

563 NNTP (SSL)

636-LDAP (SSL)

993 IMAP4 (SSL)

995 POP3 (SSL)

· 3268 und 3269 – Anforderungen an den globalen Katalogserver (Suche in Active Directory und Überprüfung der Mitgliedschaft in universellen Gruppen).

Es macht keinen Sinn, die Exchange Server-Schnittstelle innerhalb der Organisation mit einer Firewall zu schließen - sie wird verwendet, um mit Domänencontrollern, Verwaltungsdienstprogrammen und Systemen zu interagieren Exemplar reservieren usw. Für eine Schnittstelle, die dem Internet ausgesetzt ist, wird empfohlen, die Ports 53 zu belassen (wenn Exchange Hostnamen selbst auflöst und Anforderungen nicht weiterleitet). lokaler Server DNS) und 25. Sehr oft müssen Kunden von außen auf ihre Postfächer zugreifen (von zu Hause aus, während einer Geschäftsreise usw.). Die beste Lösung in dieser Situation besteht darin, OWA (die Webschnittstelle für den Zugriff auf Exchange Server, die standardmäßig installiert ist und unter http://server_name/exchange verfügbar ist) so zu konfigurieren, dass sie über SSL funktioniert und den Zugriff nur auf Port 443 zulässt Das Beheben von Problemen mit sicherer Authentifizierung und Nachrichtenverschlüsselung löst automatisch das Problem mit SMTP-Relay (dazu später mehr) und die Situation, wenn ein Benutzer versehentlich eine funktionierende Email um Client-Ordner zu mailen Heimcomputer, und dann kann er diese Nachrichten auf der Arbeit nicht finden (ganz zu schweigen von der Tatsache, dass das Speichern von Arbeitsmails zu Hause eine Sicherheitslücke darstellt).

Eine neue Funktion, die in Exchange Server eingeführt wurde. seit Version 2000 die Möglichkeit, mehrere virtuelle SMTP- und POP3-Server mit unterschiedlichen Sicherheitseinstellungen zu verwenden. Beispielsweise kann der SMTP-Server, der mit dem Internet kommuniziert, für erhöhte Sicherheit und strenge Übermittlungseinschränkungen konfiguriert werden, während der SMTP-Server, den Benutzer innerhalb der Organisation verwenden, für maximale Leistung und Benutzerfreundlichkeit konfiguriert werden kann.

Es ist auch notwendig, eine gewisse Verwirrung in der Terminologie zu erwähnen - Firewalls für Exchange werden sehr oft als Nachrichtenfiltersysteme bezeichnet, auf die weiter unten eingegangen wird.

[Dieser Artikel ist ein vorläufiges Dokument und kann in zukünftigen Versionen geändert werden. Leere Abschnitte sind als Platzhalter enthalten. Wenn Sie eine Bewertung schreiben möchten, würden wir uns freuen, diese zu erhalten. Senden Sie es uns an E-Mail [E-Mail geschützt]]

Anwendbar auf: Exchange-Server 2016

Informationen zu den Netzwerkports, die Exchange 2016 für den Clientzugriff und den Nachrichtenfluss verwendet.

Dieses Thema enthält Informationen zu den Netzwerkports, die von Microsoft Exchange Server 2016 verwendet werden, um mit E-Mail-Clients, Internet-Mail-Servern und anderen Diensten zu kommunizieren, die sich außerhalb Ihrer lokalen Exchange-Organisation befinden. Bevor Sie beginnen, beachten Sie die folgenden Grundregeln.

Wir unterstützen keine Einschränkung oder Änderung des Netzwerkdatenverkehrs zwischen internen Exchange-Servern, zwischen internen Exchange-Servern und internen Lync- oder Skype for Business-Servern oder zwischen internen Exchange-Servern und internen Active Directory-Domänencontrollern in einem der Topologietypen. Wenn Sie Firewalls oder Netzwerkgeräte verwenden, die diesen Netzwerkverkehr einschränken oder modifizieren können, müssen Sie Regeln einrichten, um freie und uneingeschränkte Kommunikation zwischen diesen Servern zuzulassen (Regeln, die Netzwerkverkehr zu und von jedem Port zulassen, einschließlich zufälliger RPC-Ports und beliebiger Protokoll). , das kein einziges Bit ändert).

Edge-Transport-Server befinden sich fast immer im Umkreisnetzwerk, sodass der Netzwerkdatenverkehr zwischen dem Edge-Transport-Server und dem Internet sowie zwischen dem Edge-Transport-Server und der internen Exchange-Organisation voraussichtlich begrenzt sein wird. Diese Netzwerkports werden in diesem Abschnitt beschrieben.

Es wird von Ihnen erwartet, dass Sie den Netzwerkdatenverkehr zwischen externen Clients und Diensten und der internen Exchange-Organisation einschränken. Sie können auch den Datenverkehr zwischen internen Clients und internen Exchange-Servern einschränken. Diese Netzwerkports werden in diesem Abschnitt beschrieben.

Inhalt

Für Clients und Dienste erforderliche Netzwerkports

Für den E-Mail-Fluss erforderliche Netzwerkports (keine Edge-Transport-Server)

Für den E-Mail-Fluss mit Edge-Transport-Servern erforderliche Netzwerkports

Für Hybridbereitstellungen erforderliche Netzwerkports

Für Unified Messaging erforderliche Netzwerkports

Die Netzwerkports, die E-Mail-Clients für den Zugriff auf Postfächer und andere Dienste in der Exchange-Organisation benötigen, werden unter beschrieben nächstes Diagramm und in der Tabelle.

Anmerkungen.

Das Ziel für diese Clients und Dienste sind die Clientzugriffsdienste auf dem Postfachserver. In Exchange 2016 werden Clientzugriffsdienste (extern) und interne Dienste zusammen auf demselben Postfachserver installiert. Weitere Informationen finden Sie im Abschnitt.

Obwohl das Diagramm Clients und Dienste aus dem Internet zeigt, sind die Konzepte für interne Clients identisch (z. B. Clients in einer Kontogesamtstruktur, die auf Exchange-Server in einer Ressourcengesamtstruktur zugreifen). Ebenso gibt es in der Tabelle keine Quelle-Spalte, da die Quelle ein beliebiger Speicherort außerhalb der Exchange-Organisation sein kann (z. B. das Internet oder eine Kontogesamtstruktur).

Edge-Transport-Server nehmen nicht am Netzwerkdatenverkehr teil, der diesen Clients und Diensten zugeordnet ist.

Zweck	Häfen	Anmerkungen
Verschlüsselte Webverbindungen werden von den folgenden Clients und Diensten verwendet. AutoErmittlungsdienst Exchange ActiveSync Exchange-Webdienste (EWS) Verteilen von Offline-Adressbüchern Outlook Anywhere (RPC über HTTP) MAPI Outlook über HTTP Outlook im Web	443/TCP (HTTPS)	EWS-Referenz für Exchange
Unverschlüsselte Webverbindungen werden von den folgenden Clients und Diensten verwendet. Veröffentlichen Sie Ihren Kalender im Web Outlook im Web (Umleitung auf Port 443/TCP) Autodiscovery (Fallback, wenn Port 443/TCP nicht verfügbar ist)	80/TCP (HTTP)	Wir empfehlen, wann immer möglich, verschlüsselte Webverbindungen auf Port 443/TCP zu verwenden, um Anmeldeinformationen und andere Daten zu schützen. Einige Dienste müssen jedoch so konfiguriert werden, dass sie unverschlüsselte Webverbindungen an Port 80/TCP zu Clientzugriffsdiensten auf Postfachservern verwenden. Weitere Informationen zu diesen Clients und Diensten finden Sie in den folgenden Artikeln.
IMAP4-Clients	143/TCP (IMAP), 993/TCP (Sicheres IMAP)	IMAP4 ist standardmäßig deaktiviert. Weitere Informationen finden Sie im Abschnitt. Der IMAP4-Dienst in den Clientzugriffsdiensten auf dem Postfachserver leitet Verbindungen zum internen IMAP4-Dienst auf dem Postfachserver weiter.
POP3-Clients	110/TCP (POP3), 995/TCP (sicheres POP3)	Standardmäßig ist das POP3-Protokoll deaktiviert. Weitere Informationen finden Sie im Abschnitt. Der POP3-Dienst in den Clientzugriffsdiensten auf dem Postfachserver leitet Verbindungen zum internen POP3-Dienst auf dem Postfachserver weiter.
SMTP-Clients (mit Authentifizierung)	587/TCP (Authentifiziertes SMTP)	Der standardmäßige Empfangsconnector ist „Client Frontend " im externen Transportdienst überwacht Port 587 auf Nachrichten von authentifizierten SMTP-Clients. Notiz. Wenn Sie über E-Mail-Clients verfügen, die nur authentifizierte SMTP-Nachrichten an Port 25 senden können, können Sie den Bindungswert dieses Empfangsconnectors so ändern, dass er auch Port 25 auf authentifizierte SMTP-Nachrichten überwacht.

Zum Anfang

Für den E-Mail-Fluss erforderliche Netzwerkports

Ausgehende Mail

25/TCP (SMTP)

Mailbox-Server

Internet (alle)

Standardmäßig erstellt Exchange keine Sendeconnectors, mit denen Sie E-Mails an das Internet senden können. Sie müssen die Sendeconnectors manuell erstellen. Weitere Informationen finden Sie im Abschnitt.

Postausgang (sofern über einen externen Transportdienst versendet)

25/TCP (SMTP)

Mailbox-Server

Internet (alle)

Ausgehende E-Mail wird nur dann über den externen Transportdienst gesendet, wenn die Einstellung für den Sendeconnector aktiviert ist Proxy über den Clientzugriffsserver in der Exchange-Verwaltungskonsole oder den Parameter -FrontEndProxyEnabled $true in der Exchange-Verwaltungsshell.

In diesem Fall wird der standardmäßige Empfangsconnector „Outbound Proxy Frontend " im externen Transportdienst überwacht ausgehende E-Mails vom Transportdienst auf dem Postfachserver. Weitere Informationen finden Sie unter .

DNS-Server für Mail-Next-Hop-Namensauflösung (nicht abgebildet)

53/UDP, 53/TCP (DNS)

Mailbox-Server

DNS Server

Zum Anfang

Ein abonnierter Edge-Transport-Server, der im Umkreisnetzwerk installiert ist, beeinflusst den E-Mail-Fluss auf folgende Weise:

Ausgehende E-Mails von der Exchange-Organisation durchlaufen niemals den externen Transportdienst auf Postfachservern. Es leitet immer vom Transportdienst auf dem Postfachserver des abonnierten Active Directory-Standorts zum Edge-Transport-Server um (unabhängig von der Version von Exchange auf dem Edge-Transport-Server).

Eingehende E-Mails werden vom Edge-Transport-Server an den Postfachserver des abonnierten Active Directory-Standorts umgeleitet. Dies bedeutet Folgendes:

• E-Mails von einem Exchange 2016- oder Exchange 2013-Edge-Transport-Server gelangen zuerst in den externen Transportdienst und werden dann an den Transportdienst auf dem Exchange 2016-Postfachserver weitergeleitet.

  E-Mails von einem Exchange 2010-Edge-Transport-Server gehen immer direkt an den Transportdienst auf einem Exchange 2016-Postfachserver.

Die für den E-Mail-Fluss in Exchange-Organisationen mit Edge-Transport-Servern erforderlichen Netzwerkports werden im folgenden Diagramm und in der folgenden Tabelle beschrieben.

Zweck	Häfen	Quelle	Zweck	Anmerkungen
Eingehende E-Mails – aus dem Internet an einen Edge-Transport-Server	25/TCP (SMTP)	Internet (alle)		Der standardmäßige Empfangsconnector mit dem Namen Standardinterner Empfangsconnector <имя пограничного транспортного сервера> " auf dem Edge-Transport-Server überwacht Port 25 auf anonyme SMTP-E-Mail.
Eingehende E-Mail – vom Edge-Transport-Server an die interne Exchange-Organisation	25/TCP (SMTP)	Edge-Transport-Server		Der standardmäßige Sendeconnector namens „EdgeSync – Inbound to " Leitet eingehende E-Mails an Port 25 an einen beliebigen Postfachserver am abonnierten Active Directory-Standort weiter. Weitere Informationen finden Sie unter . Standard-Empfangsconnector „Default Frontend " im externen Transportdienst auf dem Postfachserver überwacht Port 25 auf alle eingehenden E-Mails (einschließlich E-Mails von Exchange 2016- und Exchange 2013-Edge-Transport-Servern).
Ausgehende E-Mail – von einer internen Exchange-Organisation an einen Edge-Transport-Server	25/TCP (SMTP)	Postfachserver an einem abonnierten Active Directory-Standort		Ausgehende E-Mail umgeht immer den externen Transportdienst auf Postfachservern. E-Mails werden vom Transportdienst auf einem beliebigen Postfachserver an einem abonnierten Active Directory-Standort an einen Edge-Transport-Server weitergeleitet, indem ein impliziter und unsichtbarer organisationsinterner Sendeconnector verwendet wird, der E-Mails automatisch zwischen Exchange-Servern in derselben Organisation weiterleitet. Interner Standardempfangsconnector auf dem Edge-Transport-Server überwacht SMTP-E-Mail an Port 25 vom Transportdienst auf einem beliebigen Postfachserver am abonnierten Active Directory-Standort.
Ausgehende E-Mail – vom Edge-Transport-Server zum Internet	25/TCP (SMTP)	Edge-Transport-Server	Internet (alle)	Der standardmäßige Sendeconnector namens „EdgeSync – with <имя сайта Active Directory> to the Internet" leitet ausgehende E-Mails an Port 25 vom Edge-Transport-Server an das Internet weiter.
EdgeSync-Synchronisierung	50636/TCP (Sicheres LDAP)	Postfachserver am abonnierten Active Directory-Standort, die an der EdgeSync-Synchronisierung teilnehmen	Edge-Transport-Server	Wenn ein Edge-Transport-Server einen Active Directory-Standort abonniert hat, nehmen alle derzeit am Standort vorhandenen Postfachserver an der EdgeSync-Synchronisierung teil. Wenn Sie jedoch später weitere Postfachserver hinzufügen, nehmen diese nicht automatisch an der EdgeSync-Synchronisierung teil.
DNS-Server für die Namensauflösung des nächsten Hops (nicht gezeigt)	53/UDP, 53/TCP (DNS)	Edge-Transport-Server	DNS Server	Siehe Namensauflösung.
Sender Reputation Open Proxy Detection (nicht abgebildet)	siehe Anmerkungen	Edge-Transport-Server	Internet	Standardmäßig verwendet der Protokollanalyse-Agent die Open-Proxy-Erkennung als eine der Bedingungen für die Berechnung der Reputationsstufe des Quell-Messaging-Servers. Weitere Informationen finden Sie im Artikel. Die folgenden TCP-Ports werden verwendet, um die Quellnachrichtenserver auf einen offenen Proxy-Server zu überprüfen: Wenn Ihre Organisation außerdem einen Proxy-Server verwendet, um den ausgehenden Internetverkehr zu steuern, müssen Sie den Namen, den Typ und den TCP-Port des Proxy-Servers ermitteln, die für den Zugriff auf das Internet erforderlich sind, und einen offenen Proxy-Server erkennen. Sie können die Erkennung offener Proxys auch deaktivieren. Weitere Informationen finden Sie im Abschnitt.

Zum Anfang

Namensauflösung

Namensauflösung

Die DNS-E-Mail-Auflösung im nächsten Hop ist ein grundlegender Bestandteil des E-Mail-Flusses in jeder Exchange-Organisation. Exchange-Server, die für den Empfang eingehender E-Mails oder die Zustellung ausgehender E-Mails zuständig sind, müssen in der Lage sein, sowohl interne als auch externe Hostnamen aufzulösen, um E-Mails ordnungsgemäß weiterzuleiten. Alle internen Exchange-Server müssen in der Lage sein, interne Hostnamen aufzulösen, um E-Mails ordnungsgemäß weiterzuleiten. Da sind viele verschiedene Wege Entwicklung der DNS-Infrastruktur, aber das wichtige Ergebnis ist die Sicherstellung einer ordnungsgemäßen Namensauflösung für den nächsten Hop auf allen Exchange-Servern.