Technische Anforderungen für die Mobilität in Lync Server 2013

  • Artikel

 

Letzte Änderung: 24.07.2014

Some information in this topic pertains to Cumulative Updates for Lync Server 2013: February 2013.

Mobile Benutzer treffen auf verschiedene Szenarien für mobile Anwendungen, die eine spezielle Planung erfordern. Beispielsweise kann jemand mit der Verwendung einer mobilen Anwendung beginnen, während er von der Arbeit weg ist, indem er eine Verbindung über das 3G-Netzwerk herstellt, dann zum Unternehmensnetzwerk Wi-Fi wechselt, wenn er bei der Arbeit ankommt, und dann wieder zu 3G wechselt, wenn er das Gebäude verlässt. Sie müssen Ihre Umgebung planen, um solche Netzwerkübergänge zu unterstützen und eine konsistente Benutzererfahrung zu gewährleisten. In diesem Abschnitt werden die Infrastrukturanforderungen beschrieben, die Sie benötigen, um mobile Anwendungen und die automatische Ermittlung von Mobilitätsressourcen zu unterstützen.

Hinweis

Obwohl mobile Anwendungen auch eine Verbindung mit anderen Lync Server 2013-Diensten herstellen können, gilt die Anforderung zum Senden aller Webanforderungen für mobile Anwendungen an denselben vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des externen Webs nur für den Lync Server 2013 Mobility Service. Für andere Mobilitätsdienste ist diese Konfiguration nicht erforderlich.

Die Anforderung der Cookie-Affinität bei Hardwarelastenausgleichsmodulen wird erheblich reduziert, und Sie ersetzen die TCP-Affinität (Transmission Control Protocol), wenn Sie das mit Lync Server 2013 gelieferte Lync Mobile verwenden. Cookie-Affinität kann weiterhin verwendet werden, dies wird von den Webdiensten jedoch nicht mehr benötigt.

Wichtig

Der gesamte Mobilitätsdienstdatenverkehr durchläuft den Reverseproxy, unabhängig davon, wo sich der Ausgangspunkt befindet – intern oder extern. Im Fall eines einzelnen Reverseproxys oder einer Farm mit Reverseproxys oder eines Geräts, das die Reverseproxyfunktion bereitstellt, kann ein Problem auftreten, wenn der interne Datenverkehr über eine Schnittstelle ausgeht und versucht, sich sofort auf derselben Schnittstelle einzuschalten. Dies führt häufig zu einer Sicherheitsregelverletzung, die als TCP-Paketspoofing oder nur Spoofing bezeichnet wird. Das Anheften von Haaren (der Ausgang und das sofortige Eindringen eines Pakets oder einer Reihe von Paketen) muss zulässig sein, damit die Mobilität funktioniert. Eine Möglichkeit, dieses Problem zu beheben, besteht darin, einen Reverseproxy zu verwenden, der von der Firewall getrennt ist (die Spoofing-Verhinderungsregel sollte aus Sicherheitsgründen immer in der Firewall erzwungen werden). Die Spitzkehre kann an der externen Schnittstelle des Reverseproxys anstelle der externen Firewallschnittstelle auftreten. Sie erkennen das Spoofing an der Firewall und entspannen die Regel am Reverseproxy, wodurch die Spitzkehre, die Mobilität erfordert, ermöglicht wird.
Verwenden Sie den DNS-Host (Domain Name System) oder CNAME-Einträge, um den Reverseproxy für das Spitzkehrenverhalten (nicht die Firewall) zu definieren, wenn überhaupt möglich.

Lync Server 2013 unterstützt Mobilitätsdienste für mobile Lync 2010 Mobile- und Lync 2013-Clients. Beide Clients verwenden den Lync Server 2013 AutoErmittlungsdienst, um den Einstiegspunkt für die Mobilität zu finden, unterscheiden sich jedoch bei dem von ihnen verwendeten Mobilitätsdienst. Lync 2010 Mobile verwendet den Mobilitätsdienst Mcx, der mit dem kumulativen Update für Lync Server 2010 eingeführt wurde: November 2011. Mobile Lync 2013-Clients verwenden die Unified Communications-Web-API ( UCWA) als Mobilitätsdienstanbieter.

Interne und externe DNS-Konfiguration

Die Mobility Services Mcx (eingeführt mit dem kumulativen Update für Lync Server 2010: November 2011) und UCWA (eingeführt im kumulativen Aktualisierungen für Lync Server 2013: Februar 2013) verwenden DNS auf die gleiche Weise.

Wenn Sie die automatische Ermittlung verwenden, verwenden mobile Geräte DNS, um Ressourcen zu suchen. Während der DNS-Suche wird zunächst versucht, eine Verbindung mit dem FQDN herzustellen, der dem internen DNS-Eintrag (lyncdiscoverinternal) zugeordnet ist.< interner Domänenname>). Wenn mithilfe des internen DNS-Eintrags keine Verbindung hergestellt werden kann, wird mithilfe des externen DNS-Eintrags (lyncdiscover) versucht, eine Verbindung herzustellen.< sipdomain>). Ein mobiles Gerät, das intern im Netzwerk ist, stellt eine Verbindung mit der internen AutoErmittlungsdienst-URL her, und ein mobiles Gerät, das sich außerhalb des Netzwerks befindet, stellt eine Verbindung mit der url des externen AutoErmittlungsdiensts her. Externe AutoErmittlungsanforderungen durchlaufen den Reverseproxy. Der Lync Server 2013 AutoErmittlungsdienst gibt alle Webdienste-URLs für den Startpool des Benutzers zurück, einschließlich der Mobilitätsdienst-URLs (Mcx und UCWA). Sowohl die interne Mobilitätsdienst-URL als auch die externe Mobilitätsdienst-URL sind jedoch dem externen Webdienst-FQDN zugeordnet. Daher stellt das Gerät unabhängig davon, ob es sich um ein internes oder ein externes Gerät im Netzwerk handelt, immer über den Reverseproxy eine externe Verbindung mit dem Lync Server 2013 Mobility Service her.

Hinweis

Es ist wichtig zu wissen, dass Ihre Bereitstellung aus mehreren unterschiedlichen Namespaces für die interne und externe Verwendung bestehen kann. Ihr SIP-Domänenname unterscheidet sich möglicherweise vom Namen der internen Bereitstellungsdomäne. Ihre SIP-Domäne kann beispielsweise contoso.com sein, während Ihre interne Bereitstellung möglicherweise contoso.net ist. Benutzer, die sich bei Lync Server anmelden, verwenden den SIP-Domänennamen, z john@contoso.com. B. . Bei der Adressierung der externen Webdienste (im Topologie-Generator als externe Webdienste definiert) sind der Domänenname und der SIP-Domänenname konsistent, wie in DNS definiert. Bei der Adressierung der internen Webdienste (im Topologie-Generator als interne Webdienste definiert), ist der Standardname der internen Webdienste der FQDN des Front-End-Servers, Front-End-Pools, Director oder Director-Pools. Sie haben die Möglichkeit, den Namen der internen Webdienste außer Kraft zu setzen. Sie sollten den internen Domänennamen (und nicht den SIP-Domänennamen) für interne Webdienste verwenden und den DNS-Host-A-Eintrag (oder für IPv6 AAAA) definieren, um den überschriebenen Namen widerzuspiegeln. Beispielsweise kann der standardmäßige FQDN für interne Webdienste pool01.contoso.net sein. Ein überschriebener interner Webdienst-FQDN kann webpool.contoso.net werden. Die Definition der Webdienste auf diese Weise trägt dazu bei, sicherzustellen, dass die interne und externe Lokalität der Dienste und nicht die Lokalität des Benutzers, der sie verwendet, beobachtet wird.
Da die Webdienste jedoch im Topologie-Generator definiert sind und der Name der internen Webdienste außer Kraft gesetzt werden kann, können Sie die internen Webdienste mit einem beliebigen Domänennamen definieren, einschließlich des SIP-Domänennamens. Letztendlich wird die Auflösung für den Namen der IP-Adresse durch DNS-Hosteinträge und einen konsistenten Namespace bestimmt.
Für die Zwecke dieses Themas und der Beispiele wird der interne Domänenname verwendet, um die Topologie und die DNS-Definitionen zu veranschaulichen.

Das folgende Diagramm veranschaulicht den Fluss mobiler Anwendungswebanforderungen für den Mobilitätsdienst und den AutoErmittlungsdienst bei Verwendung einer internen und externen DNS-Konfiguration.

Mobilitätsdienst-Fluss mithilfe der AutoErmittlung

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

Hinweis

Das Diagramm veranschaulicht generische Webdienste. Ein virtuelles Verzeichnis mit dem Namen Mobility zeigt die Mobilitätsdienste Mcx und/oder UCWA. Wenn Sie die kumulative Aktualisierungen für Lync Server 2013: Februar 2013 nicht angewendet haben, ist möglicherweise das virtuelle Verzeichnis Ucwa für Ihre internen und externen Webdienste definiert. Sie verfügen über eine AutoErmittlung für virtuelle Verzeichnisse und möglicherweise über ein virtuelles Verzeichnis Mcx.
Die AutoErmittlung und die Ermittlung von Diensten funktionieren unabhängig von der bereitgestellten Mobilitätsdienstetechnologie auf die gleiche Weise.

Um mobile Benutzer sowohl innerhalb als auch außerhalb des Unternehmensnetzwerks zu unterstützen, müssen Ihre internen und externen Web-FQDNs einige Voraussetzungen erfüllen. Darüber hinaus müssen Sie möglicherweise andere Anforderungen erfüllen, je nachdem, welche Features Sie implementieren möchten:

  • Neue DNS-, CNAME- oder A-Einträge (Host, wenn IPv6, AAAA) für die automatische Ermittlung.

  • 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.

  • Die Konfiguration des Hardwarelastenausgleichs für den Front-End-Server ändert die Quellaffinität.

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

  • Der interne Web-FQDN des Front-End-Pools muss sich vom externen Web-FQDN des Front-End-Pools unterscheiden.

  • Der interne Web-FQDN darf nur innerhalb des Unternehmensnetzwerks aufgelöst werden und darauf kann zugegriffen werden.

  • Der externe Web-FQDN darf nur in das Internet aufgelöst werden und kann über das Internet aufgerufen werden.

  • Für einen Benutzer, der sich innerhalb des Unternehmensnetzwerks befindet, muss die Mobilitätsdienst-URL an den externen Web-FQDN adressiert werden. Diese Anforderung gilt für den Mobilitätsdienst und gilt nur für diese URL.

  • Für einen Benutzer, der sich außerhalb des Unternehmensnetzwerks befindet, muss die Anforderung an den externen Web-FQDN des Front-End-Pools oder Director gehen.

Wenn Sie die automatische Ermittlung unterstützen, müssen Sie die folgenden DNS-Einträge für jede SIP-Domäne erstellen:

  • Ein interner DNS-Eintrag zur Unterstützung mobiler Benutzer, die eine Verbindung aus dem Netzwerk Ihrer Organisation herstellen.

  • Ein externer oder öffentlicher DNS-Eintrag zur Unterstützung mobiler Benutzer, die eine Verbindung über das Internet herstellen.

Die interne URL für die automatische Ermittlung sollte nicht von außerhalb Ihres Netzwerks adressierbar sein. Die URL für die externe automatische Ermittlung sollte nicht in Ihrem Netzwerk adressierbar sein. Wenn Sie diese Anforderung für die externe URL jedoch nicht erfüllen können, ist die Funktionsfähigkeit des mobilen Clients wahrscheinlich nicht betroffen, da die interne URL immer zuerst versucht wird.

Die DNS-Einträge können entweder CNAME-Einträge oder A-Einträge (Host, wenn IPv6, AAAA) sein.

Hinweis

Clients für mobile Geräte unterstützen nicht mehrere SSL-Zertifikate (Secure Sockets Layer) aus verschiedenen Domänen. Daher wird die CNAME-Umleitung zu verschiedenen Domänen nicht über HTTPS unterstützt. Beispielsweise wird ein DNS-CNAME-Eintrag für lyncdiscover.contoso.com, der an eine Adresse von director.contoso.net umleitet, über HTTPS nicht unterstützt. In einer solchen Topologie muss ein Client für mobile Geräte HTTP für die erste Anforderung verwenden, damit die CNAME-Umleitung über HTTP aufgelöst wird. Nachfolgende Anforderungen verwenden dann HTTPS. Um dieses Szenario zu unterstützen, müssen Sie Ihren 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" unter Konfigurieren des Reverseproxys für Mobilität in Lync Server 2013.
Die CNAME-Umleitung zu derselben Domäne wird über HTTPS unterstützt. In diesem Fall deckt das Zertifikat der Zieldomäne die Ursprungsdomäne ab.

Ausführliche Informationen zu den für Ihr Szenario erforderlichen DNS-Einträgen finden Sie in der DNS-Zusammenfassung – AutoErmittlung in Lync Server 2013.

Port- und Firewallanforderungen

Wenn Sie Pushbenachrichtigungen unterstützen und möchten, dass mobile Apple-Geräte Pushbenachrichtigungen über Ihr Wi-Fi-Netzwerk empfangen, müssen Sie auch Port 5223 in Ihrem Unternehmensnetzwerk Wi-Fi öffnen. Port 5223 ist ein ausgehender TCP-Port, der vom Apple Push Notification Service (APNS) verwendet wird. Das mobile Gerät initiiert die Verbindung. Ausführliche Informationen finden Sie unter http://support.apple.com/kb/TS1629 .

Warnung

Ein Apple-Gerät, das den Lync 2013 Mobile-Client verwendet, erfordert keine Pushbenachrichtigungen.

Beachten Sie, dass die folgenden Ports erforderlich sind, wenn ein Benutzer in einer Survivable Branch Appliance (SBA) verwaltet wird:

  • UcwaSipExternalListeningPort erfordert Port 5088

  • UcwaSipPrimaryListeningPort erfordert Port 5089

Weitere Details und Anleitungen zu Port- und Protokollanforderungen für die AutoErmittlung finden Sie unter Portzusammenfassung – AutoErmittlung in Lync Server 2013.

Zertifikatanforderungen

Wenn Sie die automatische Ermittlung für mobile Lync-Clients unterstützen, müssen Sie die Alternativen Namenlisten für Antragsteller in Zertifikaten ändern, um sichere Verbindungen von den 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. Der empfohlene Ansatz besteht darin, auch die Liste der alternativen Antragstellernamen in Zertifikaten für Ihre Reverseproxys zu ändern. Sie müssen alternative Antragstellernameneinträge für jede SIP-Domäne in Ihrer Organisation hinzufügen.

Das Erneute Aufstellen von Zertifikaten mithilfe einer internen Zertifizierungsstelle ist in der Regel ein einfacher Prozess, aber das Hinzufügen mehrerer alternativer Antragstellernamen zu öffentlichen Zertifikaten, die vom Reverseproxy verwendet werden, kann teuer sein. Wenn Sie über viele SIP-Domänen verfügen, was das Hinzufügen alternativer Antragstellernamen sehr teuer macht, können Sie den Reverseproxy so konfigurieren, dass die anfängliche AutoErmittlungsdienstanforderung über Port 80 über HTTP und nicht über Port 443 über HTTPS (standardkonfiguration) ausgeführt wird. Die Anforderung wird dann an Port 8080 im Director- oder Front-End-Pool umgeleitet. Wenn Sie die ursprüngliche Anforderung des AutoErmittlungsdiensts an Port 80 veröffentlichen, müssen Sie die Zertifikate für den Reverseproxy nicht ändern, da die Anforderung HTTP anstelle von HTTPS verwendet. Dieser Ansatz wird unterstützt, wird jedoch nicht empfohlen.

Internetinformationsdienste (IIS) – Anforderungen

Es wird empfohlen, IIS 7.5, IIS 8.0 oder IIS 8.5 für Mobilität zu verwenden. Der Mobilitätsdienst-Installer legt Flags in ASP.NET fest, um die Leistung zu verbessern. IIS 7.5 ist standardmäßig unter Windows Server 2008 R2, IIS 8.0 auf Windows Server 2012 und IIS 8.5 auf Windows Server 2012 R2 installiert. Der Mobilitätsdienst-Installer ändert automatisch die ASP.NET Einstellungen.

Anforderungen an das Hardwaregerät zum Lastenausgleich

Auf dem Hardwaregerät zum Lastenausgleich, der den Front-End-Pool unterstützt, müssen die externen virtuellen Webdienste-IPs (VIPs) für Webdienstedatenverkehr für die Quelle konfiguriert werden. Die Quellaffinität trägt dazu bei, dass mehrere Verbindungen von einem einzelnen Client an einen Server gesendet werden, um den Sitzungsstatus aufrechtzuerhalten. Ausführliche Informationen zu den Affinitätsanforderungen finden Sie unter Lastenausgleichsanforderungen für Lync Server 2013.

Wenn Sie be planen, mobile Lync-Clients nur über Ihr internes Wi-Fi-Netzwerk zu unterstützen, sollten Sie die internen Webdienste-VIPS für die Quelle konfigurieren, wie für externe Webdienste-VIPs beschrieben. In diesem Fall sollten Sie source_addr (oder TCP)-Affinität für die internen Webdienste-VIPs im Hardwarelastenausgleich verwenden. Ausführliche Informationen finden Sie unter Lastenausgleichsanforderungen für Lync Server 2013.

Reverseproxyanforderungen

Wenn Sie die automatische Ermittlung für mobile Lync-Clients unterstützen, müssen Sie die aktuelle Veröffentlichungsregel wie folgt aktualisieren:

  • Wenn Sie die Liste alternativer Antragstellernamen auf den Reverseproxyzertifikaten aktualisieren und HTTPS für die anfängliche AutoErmittlungsdienstanforderung verwenden möchten, müssen Sie die Webveröffentlichungsregel für lyncdiscover aktualisieren.< sipdomain>. In der Regel wird dies mit der Veröffentlichungsregel für die url der externen Webdienste im Front-End-Pool kombiniert.

  • Wenn Sie HTTP für die anfängliche AutoErmittlungsdienstanforderung verwenden möchten, damit Sie die Liste alternativer Antragstellernamen auf den Reverseproxyzertifikaten nicht aktualisieren müssen, müssen Sie eine neue Webveröffentlichungsregel für Port HTTP/TCP 80 erstellen, sofern noch keine vorhanden ist. Wenn bereits eine Regel für HTTP/TCP 80 vorhanden ist, können Sie diese Regel aktualisieren, um die lyncdiscover einzuschließen.< sipdomain-Eintrag> .