Artikel
01/16/2015

Technische Anforderungen für die Mobilität

Letztes Änderungsdatum des Themas: 2013-03-05

Für mobile Benutzer müssen in den mobilen Anwendungen verschiedene Szenarien unterstützt werden, die eine besondere Planung erfordern. Ein Benutzer kann beispielsweise eine mobile Anwendung von außerhalb des Arbeitsplatzes aufrufen, indem er über das 3G-Netzwerk eine Verbindung herstellt, und dann beim Eintreffen am Arbeitsplatz wieder zum WLAN-Netzwerk wechseln. Beim Verlassen des Gebäudes kehrt er dann wieder zum 3G-Netzwerk zurück. Sie müssen die Umgebung entsprechend planen, um solche Netzwerkübergänge zu unterstützen und ein konsistentes Benutzererlebnis zu ermöglichen. In diesem Abschnitt werden die Infrastrukturanforderungen beschrieben, die Sie erfüllen müssen, um mobile Anwendungen und die automatische Ermittlung von Mobilitätsressourcen zu unterstützen.

Wenn Sie die automatische Ermittlung verwenden, suchen mobile Geräte über das Domain Name System (DNS) nach Ressourcen. Bei der DNS-Suche wird zuerst versucht, eine Verbindung mit dem vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) herzustellen, der mit dem internen DNS-Eintrag verknüpft ist (lyncdiscoverinternal.<sipdomain>). Wenn keine Verbindung mit dem internen DNS-Eintrag hergestellt werden kann, wird versucht, eine Verbindung mit dem externen DNS-Eintrag (lyncdiscover.<sipdomain>) herzustellen. Ein mobiles Gerät, das sich im Netzwerk befindet, stellt eine Verbindung mit der internen URL des AutoErmittlungsdiensts her. Ein mobiles Gerät, dass sich außerhalb des Netzwerks befindet, stellt eine Verbindung mit der externen URL des AutoErmittlungsdiensts her. Externe Anforderungen werden über den Reverseproxy geleitet. Der Microsoft Lync Server 2010-AutoErmittlungsdienst gibt alle Webdienste-URLs für den Home-Pool des Benutzers zurück, einschließlich der Mobilitätsdienst-URLs. Jedoch ist sowohl die interne Mobilitätsdienst-URL als auch die externe Mobilitätsdienst-URL dem externen Webdienste-FQDN zugeordnet. Daher stellt das mobile Gerät (egal, ob es sich innerhalb oder außerhalb des Netzwerks befindet) immer extern über den Reverseproxy eine Verbindung mit dem Microsoft Lync Server 2010-Mobilitätsdiensts her.

Hinweis:
Obwohl mobile Anwendungen auch eine Verbindung mit anderen Lync Server-Diensten wie dem Adressbuchdienst herstellen können, gilt die Anforderung, alle Webanforderungen mobiler Anwendungen an denselben externen Web-FQDN zu senden, nur für den Mobilitätsdienst. Für andere Dienste ist diese Konfiguration nicht erforderlich.

Das folgende Diagramm veranschaulicht den Ablauf der Webanforderungen mobiler Anwendungen an den Mobilitätsdienst und AutoErmittlungsdienst.

Ablauf von Anforderungen mobiler Anwendungen für den Mobilitätsdienst und den AutoErmittlungsdienst

cdb96424-96f2-4abf-88d7-1d32d1010ffd

Die internen und externen Web-FQDNs müssen einige Voraussetzungen erfüllen, um mobile Benutzer sowohl von innerhalb als auch außerhalb des Firmennetzwerks zu unterstützen. Zudem müssen möglicherweise andere Anforderungen erfüllt werden, je nachdem, welche Features implementiert werden sollen:

Neue DNS-CNAME- oder DNS-A-Einträge für automatische Ermittlung
DNS-SRV-Eintrag für den Partnerverbund mit dem Clearinghouse für Pushbenachrichtigungen
Neue Ports für interne Server
Neue Firewallregel, wenn Pushbenachrichtigungen über das WLAN-Netzwerk unterstützt werden sollen
Alternative Antragstellernamen für interne Serverzertifikate und Reverseproxyzertifikate für die automatische Ermittlung
Änderungen an der Konfiguration des Front-End-Server-Hardwaregeräts zum Lastenausgleich für cookiegestützte Persistenz
Neue Webveröffentlichungsregeln für den Reverseproxy für die automatische Ermittlung

Websiteanforderungen

Die Topologie muss die folgenden Anforderungen erfüllen, um den Mobilitätsdienst und AutoErmittlungsdienst zu unterstützen:

Der interne Front-End-Pool-Web-FQDN muss sich vom externen Front-End-Pool-Web-FQDN unterscheiden.
Auf den internen Web-FQDN darf nur von innerhalb des Firmennetzwerks zugegriffen werden. Zudem darf der interne Web-FQDN nur in eine Firmennetzwerkadresse aufgelöst werden.
Auf den externen Web-FQDN darf nur vom Internet aus zugegriffen werden (hiervon ausgenommen ist die Mobilitätsdienst-URL, die sowohl von internen als auch externen Benutzeranforderungen verwendet wird).
Für Benutzer, die sich innerhalb des Firmennetzwerks befinden, muss die Mobilitätsdienst-URL an den externen Web-FQDN adressiert werden. Diese Anforderung gilt für den Mobilitätsdienst und betrifft nur diese URL.
Für Benutzer, die sich außerhalb des Firmennetzwerks befinden, muss die Anforderung an den externen Web-FQDN des Front-End-Pools oder Directors gerichtet werden.
Wenn Sie über eine Split-Brain-DNS-Umgebung verfügen und die Clients der mobilen Geräte über WLAN eine Verbindung herstellen, müssen Sie den externen Web-FQDN im internen DNS mit der öffentlichen IP-Adresse konfigurieren.

DNS-Anforderungen

Die Topologie muss die in den folgenden Abschnitten erläuterten DNS-Anforderungen erfüllen, um den Mobilitätsdienst und AutoErmittlungsdienst zu unterstützen:

Anforderung an die Mobilitätsdienst-URL

In einer Standardkonfiguration wird einem über WLAN mit dem internen Netzwerk verbundenen Benutzer immer die externe Mobilitätsdienst-URL für seinen Home-Pool zurückgegeben. Das Gerät des Benutzers muss die interne DNS-Zone abfragen und den externen Lync-Webdienste-FQDN in die IP-Adresse der externen Schnittstelle des Reverseproxys auflösen können. Der Benutzer stellt dann über den Reverseproxy eine ausgehende Hairpin-Verbindung mit dem Mobilitätsdienst her.

Anforderungen für automatische Ermittlung und Pushbenachrichtigungen

Zur Unterstützung der AutoErmittlung müssen Sie für jede SIP-Domäne die folgenden DNS-Einträge erstellen:

Einen internen DNS-Eintrag zur Unterstützung mobiler Benutzer, die über das Netzwerk Ihrer Organisation eine Verbindung herstellen
Einen externen oder öffentlichen DNS-Eintrag zur Unterstützung mobiler Benutzer, die eine Verbindung über das Internet herstellen
Einen externen oder öffentlichen DNS-Eintrag zur Unterstützung von Pushbenachrichtigungen

Die interne AutoErmittlung-URL sollte nicht von außerhalb des Netzwerks adressierbar sein. Die externe AutoErmittlung-URL sollte nicht von innerhalb des Netzwerks adressierbar sein. Wenn Sie diese Anforderung für die externe URL nicht erfüllen können, sollte dies nicht die Funktionen des mobilen Clients beeinträchtigen, da immer zuerst versucht wird, eine Verbindung mit der internen URL herzustellen.

Bei den DNS-Einträgen kann es sich entweder um A-Einträge (Host) oder um CNAME-Einträge handeln.

Sie müssen den folgenden internen DNS-Eintrag erstellen:

Interne DNS-Einträge

Eintragstyp	Hostname	Auflösung in
A (Host)	lyncweb.contoso.com (Beispiel-URL für externe Webdienste)	Der Eintrag befindet sich auf dem internen DNS, das in die externe IP-Adresse der URL des externen Webdiensts auflöst. Beispiel: https://lyncweb.contoso.com

Und einen der folgenden zusätzlichen internen DNS-Einträge:

Eintragstyp	Hostname	Auflösung in
CNAME	lyncdiscoverinternal.<sipdomain>	Interner Webdienste-FQDN für den Directorpool, falls vorhanden, oder für den Front-End-Pool , wenn kein Director vorhanden ist
A (Host)	lyncdiscoverinternal.<sipdomain>	Interne Webdienste-IP-Adresse (virtuelle IP-Adresse bei Verwendung eines Lastenausgleichs) des Directorpools, sofern vorhanden, oder des Front-End-Pools, wenn kein Director vorhanden ist

Sie müssen einen der folgenden externen DNS-Einträge erstellen:

Externe DNS-Einträge

Eintragstyp	Hostname	Auflösung in
CNAME	lyncdiscover.<sipdomain>	Externer Webdienste-FQDN für den Directorpool, falls vorhanden, oder für den Front-End-Pool , wenn kein Director vorhanden ist
A (Host)	lyncdiscover.<sipdomain>	Externe oder öffentliche IP-Adresse des Reverseproxys

Hinweis:
Externer Datenverkehr wird über den Reverseproxy geleitet.

Hinweis:
Clients mobiler Geräte unterstützen nicht mehrere SSL-Zertifikate (Secure Sockets Layer) von verschiedenen Domänen. Daher wird die CNAME-Umleitung an verschiedene Domänen nicht über HTTPS unterstützt. Beispielsweise wird ein DNS-CNAME-Eintrag für "lyncdiscover.contoso.com", der eine Weiterleitung an eine Adresse von "director.contoso.net" vornimmt, nicht über HTTPS unterstützt. In einer solchen Topologie muss ein Client für ein mobiles Gerät HTTP für die erste Anforderung verwenden, sodass die CNAME-Umleitung über HTTP aufgelöst wird. Für die nachfolgenden Anforderungen wird dann HTTPS verwendet. Um dieses Szenario zu unterstützen, müssen Sie den Reverseproxy mit einer Webveröffentlichungsregel für Port 80 (HTTP) konfigurieren. Ausführliche Informationen finden Sie unter "So erstellen Sie eine Webveröffentlichungsregel für Port 80" in Konfigurieren des Reverseproxys für Mobilität. Die CNAME-Umleitung an dieselbe Domäne wird über HTTPS unterstützt. In diesem Fall deckt das Zertifikat der Zieldomäne die ursprüngliche Domäne ab.

Clients mobiler Geräte unterstützen nicht mehrere SSL-Zertifikate (Secure Sockets Layer) von verschiedenen Domänen. Daher wird die CNAME-Umleitung an verschiedene Domänen nicht über HTTPS unterstützt. Beispielsweise wird ein DNS-CNAME-Eintrag für "lyncdiscover.contoso.com", der eine Weiterleitung an eine Adresse von "director.contoso.net" vornimmt, nicht über HTTPS unterstützt. In einer solchen Topologie muss ein Client für ein mobiles Gerät HTTP für die erste Anforderung verwenden, sodass die CNAME-Umleitung über HTTP aufgelöst wird. Für die nachfolgenden Anforderungen wird dann HTTPS verwendet. Um dieses Szenario zu unterstützen, müssen Sie den Reverseproxy mit einer Webveröffentlichungsregel für Port 80 (HTTP) konfigurieren. Ausführliche Informationen finden Sie unter "So erstellen Sie eine Webveröffentlichungsregel für Port 80" in Konfigurieren des Reverseproxys für Mobilität.
Die CNAME-Umleitung an dieselbe Domäne wird über HTTPS unterstützt. In diesem Fall deckt das Zertifikat der Zieldomäne die ursprüngliche Domäne ab.

SRV

"_sipfederationtls._tcp.<SIP-Domänenname>" in Host A-Eintrag von Zugriffs-Edgedienst

Beispiel: "_sipfedrationtls._tcp.contoso.com" mit definiertem Port von TCP 5061 in "sip.contoso.com"

Wichtig:
Der SRV-Eintrag muss auf einen A-Eintrag in derselben SIP-Domäne zeigen

Port- und Firewallanforderungen

Der Mobilitätsdienst erfordert auf den Front-End-Servern oder den Standard Edition-Servern die folgenden beiden Webdienste-Listenerports. Sie legen diese Ports bei der Bereitstellung mit dem Set-CsWebServer-Cmdlet manuell fest. Ausführliche Informationen finden Sie unter Festlegen interner Serverports für Mobilität.

Sie müssen zudem eine Zulassungsregel für TCP 5061 für den Partnerverbund mit dem Onlineanbieter für Pushbenachrichtigungen erstellen. Ausführliche Informationen finden Sie unter Referenzarchitektur.

Port 5086 wird verwendet, um von innerhalb des Firmennetzwerks auf Mobilitätsanforderungen zu lauschen. Dies ist ein SIP-Port, der vom internen Prozess des Mobilitätsdiensts verwendet wird.
Port 5087 wird verwendet, um vom Internet aus auf Mobilitätsanforderungen zu lauschen. Dies ist ein SIP-Port, der vom externen Prozess des Mobilitätsdiensts verwendet wird.

Wenn Sie Pushbenachrichtigungen unterstützen und möchten, dass mobile Apple-Geräte Pushbenachrichtigungen über das WLAN-Netzwerk empfangen, müssen Sie auch Port 5223 im WLAN-Netzwerk des Unternehmens öffnen. Port 5223 ist ein ausgehender TCP-Port, der vom Apple Push Notification Service (APNS) verwendet wird. Die Verbindung kann von dem mobilen Gerät oder dem Benachrichtigungsdienst initiiert werden. Hierfür muss der ausgehende Port im WLAN des Unternehmens verfügbar sein. Ausführliche Informationen finden Sie unter http://support.apple.com/kb/TS1629?viewlocale=de_DE?viewlocale=de_DE und https://developer.apple.com/library/ios/#technotes/tn2265/_index.html.

Zertifikatanforderungen

Wenn Sie die automatische Ermittlung für mobile Lync-Clients unterstützen, müssen Sie die Listen der alternativen Antragstellernamen für Zertifikate ändern, um sichere Verbindungen von mobilen Clients zu unterstützen. Sie müssen neue Zertifikate anfordern und zuweisen, und für jeden Front-End-Server und Director, auf dem der AutoErmittlungsdienst ausgeführt wird, die in diesem Abschnitt beschriebenen Einträge für alternative Antragstellernamen hinzufügen. Es wird empfohlen, auch die Listen der alternativen Antragstellernamen für die Zertifikate der Reverseproxys zu ändern. Sie müssen die Einträge für den alternativen Antragstellernamen für jede SIP-Domäne in der Organisation hinzufügen.

Das erneute Ausstellen von Zertifikaten durch eine interne Zertifizierungsstelle ist normalerweise ein einfacher Vorgang. Das Hinzufügen mehrerer Einträge für alternative Antragstellernamen zu öffentlichen Zertifikaten, die vom Reverseproxy verwendet werden, kann jedoch aufwendig sein. Wenn Sie über viele SIP-Domänen verfügen und das Hinzufügen alternativer Antragstellernamen daher sehr zeitaufwendig ist, können Sie den Reverseproxy so konfigurieren, dass die anfängliche AutoErmittlungsdienst-Anforderung über Port 80 mit HTTP erfolgt und nicht über 443 mit HTTPS (Standardkonfiguration). Die Anforderung wird dann an den Port 8080 auf dem Director oder Front-End-Pool umgeleitet. Wenn Sie die anfängliche AutoErmittlungsdienst-Anforderung an Port 80 veröffentlichen, müssen Sie die Zertifikate für den Reverseproxy nicht ändern, da die Anforderung HTTP anstatt HTTPS verwendet. Dieser Ansatz wird unterstützt, aber nicht empfohlen.

Hinweis:
Ausführliche Informationen zum Verwenden von Port 80 für die anfängliche Anforderung finden Sie unter "Anfänglicher AutoErmittlungsprozess über Port 80" in Anforderungen für den AutoErmittlungsdienst in der Dokumentation für die Planung für externe Benutzer.

Hinweis:
Wenn Sie in der Lync Server 2010-Infrastruktur interne Zertifikate verwenden, die von einer internen Zertifizierungsstelle (ZS) ausgestellt werden, und planen, eine WLAN-Verbindung für mobile Geräte zu unterstützen, muss entweder die Stammzertifikatkette von der internen ZS auf den mobilen Geräten installiert sein, oder Sie müssen für die Lync Server-Infrastruktur ein öffentliches Zertifikat verwenden.

Wenn Sie in der Lync Server 2010-Infrastruktur interne Zertifikate verwenden, die von einer internen Zertifizierungsstelle (ZS) ausgestellt werden, und planen, eine WLAN-Verbindung für mobile Geräte zu unterstützen, muss entweder die Stammzertifikatkette von der internen ZS auf den mobilen Geräten installiert sein, oder Sie müssen für die Lync Server-Infrastruktur ein öffentliches Zertifikat verwenden.

In diesem Abschnitt werden die alternativen Antragstellernamen beschrieben, die für die folgenden Zertifikate erforderlich sind:

Edgeserver oder Edgeserverpool
Director oder Directorpool
Front-End-Server oder Front-End-Pool
Reverseproxy

Beschreibung	Eintrag für alternativen Antragstellernamen
Zugriffs-Edgedienst	SAN=sip.<sipDomäne>

Directorpool-Zertifikatanforderungen

Beschreibung	Eintrag für alternativen Antragstellernamen
Interne URL des AutoErmittlungsdiensts	SAN=lyncdiscoverinternal.<sipdomain>
Externe URL des AutoErmittlungsdiensts	SAN=lyncdiscover.<sipdomain>

Hinweis:
Alternativ können Sie "SAN=*.<sipDomäne>" nur für AutoErmittlung-Einträge (lyncdiscover und lyncdicoverinternal) verwenden.

Front-End-Pool-Zertifikatanforderungen

Beschreibung	Eintrag für alternativen Antragstellernamen
Interne URL des AutoErmittlungsdiensts	SAN=lyncdiscoverinternal.<sipdomain>
Externe URL des AutoErmittlungsdiensts	SAN=lyncdiscover.<sipdomain>

Hinweis:
Alternativ können Sie "SAN=*.<sipDomäne>" nur für AutoErmittlung-Einträge (lyncdiscover und lyncdicoverinternal) verwenden.

Reverseproxy-Zertifikatanforderungen (öffentliche ZS)

Beschreibung	Eintrag für alternativen Antragstellernamen
Externe URL des AutoErmittlungsdiensts	SAN=lyncdiscover.<sipdomain>

Hinweis:
Sie weisen dieses Zertifikat dem SSL-Listener auf dem Reverseproxy zu.

IIS-Anforderungen (Internetinformationsdienste)

Es wird empfohlen, IIS 7.5 für die Mobilität zu verwenden. Der Mobilitätsdienst-Installer legt zur Leistungsverbesserung einige der ASP.NET-Kennzeichen fest. IIS 7.5 ist standardmäßig unter Windows Server 2008 R2 installiert, und der Mobilitätsdienst-Installer ändert die ASP.NET-Einstellungen automatisch. Wenn Sie IIS 7.0 unter Windows Server 2008 verwenden, müssen Sie diese Einstellungen manuell ändern. Ausführliche Informationen finden Sie unter Installieren des Mobilitäts- und AutoErmittlungsdiensts.

Anforderungen an das Hardwaregerät zum Lastenausgleich

Wenn die Umgebung einen Front-End-Pool enthält, müssen die virtuellen IPs (VIPs) der externen Webdienste auf dem Hardwaregerät zum Lastenausgleich, das für den Webdienste-Datenverkehr verwendet wird, für cookiegestützte Persistenz konfiguriert werden. Cookiegestützte Persistenz stellt sicher, dass mehrere Verbindungen von einem einzelnen Client zur Beibehaltung des Sitzungsstatus an einen einzigen Server gesendet werden. Die Cookies müssen bestimmte Anforderungen erfüllen. Ausführliche Informationen zu den Cookieanforderungen finden Sie unter Anforderungen an den Lastenausgleich.

Wenn Sie mobile Lync-Clients nur über das interne WLAN-Netzwerk unterstützen möchten, sollten Sie die internen Webdienste-VIPs für cookiegestützte Persistenz konfigurieren, so wie oben für externe Webdienste-VIPs beschrieben. In dieser Situation sollten Sie keine Quelladressenpersistenz für die internen Webdienste-VIPs auf dem Hardwaregerät zum Lastenausgleich verwenden. Ausführliche Informationen finden Sie unter Anforderungen an den Lastenausgleich.

Reverseproxyanforderungen

Wenn Sie die automatische Ermittlung für mobile Lync-Clients unterstützen, müssen Sie wie folgt eine neue Webveröffentlichungsregel erstellen:

Wenn Sie sich entscheiden, die Listen der alternativen Antragstellernamen in den Reverseproxyzertifikaten zu aktualisieren und HTTPS für die anfängliche AutoErmittlungsdienst-Anforderung zu verwenden, müssen Sie eine neue Webveröffentlichungsregel für lyncdiscover.<sipdomain> erstellen. Zudem müssen Sie sicherstellen, dass eine Webveröffentlichungsregel für die externe Webdienste-URL auf dem Front-End-Pool vorhanden ist.
Wenn Sie HTTP für die anfängliche AutoErmittlungsdienst-Anforderungen verwenden möchten, damit die Liste der alternativen Antragstellernamen in den Reverseproxyzertifikaten nicht aktualisiert werden muss, müssen Sie eine Webveröffentlichungsregel für Port 80 erstellen (HTTP).