Exigences techniques pour la mobilité dans Lync Server 2013
Rubrique Dernière modification : 2014-07-24
Some information in this topic pertains to Cumulative Updates for Lync Server 2013: February 2013.
Les utilisateurs mobiles rencontrent différents scénarios d’application mobile qui nécessitent une planification spéciale. Par exemple, une personne peut commencer à utiliser une application mobile pendant son absence en se connectant via le réseau 3G, puis basculer vers le réseau Wi-Fi d’entreprise en arrivant au travail, puis revenir à la 3G en quittant le bâtiment. Vous devez planifier votre environnement pour prendre en charge ces transitions réseau et garantir une expérience utilisateur cohérente. Cette section décrit les exigences d’infrastructure que vous devez avoir pour prendre en charge les applications mobiles et la découverte automatique des ressources de mobilité.
Remarque
Bien que les applications mobiles puissent également se connecter à d’autres services Lync Server 2013, l’obligation d’envoyer toutes les demandes web d’application mobile au même nom de domaine complet (FQDN) web externe s’applique uniquement au service Mobilité Lync Server 2013. Les autres services de mobilité ne nécessitent pas cette configuration.
La nécessité d’une affinité de cookie dans les équilibreurs de charge matérielle est considérablement réduite, et vous remplacez l’affinité TCP (Transmission Control Protocol) si vous utilisez Lync Mobile fourni avec Lync Server 2013. L’affinité de cookie peut toujours être utilisée, mais les services web n’en ont plus besoin.
Important
Tout le trafic du service Mobilité passe par le proxy inverse, quel que soit l’emplacement du point d’origine ( interne ou externe). Dans le cas d’un proxy inverse unique ou d’une batterie de serveurs de proxys inverses, ou d’un appareil qui fournit la fonction de proxy inverse, un problème peut se produire lorsque le trafic interne quitte une interface et tente d’entrer immédiatement sur la même interface. Cela entraîne souvent une violation de règle de sécurité appelée usurpation de paquet TCP ou simplement usurpation d’identité. L’épinglage de cheveux (la sortie et l’entrée immédiate d’un paquet ou d’une série de paquets) doit être autorisé pour que la mobilité fonctionne. Une façon de résoudre ce problème consiste à utiliser un proxy inverse distinct du pare-feu (la règle de prévention de l’usurpation d’identité doit toujours être appliquée sur le pare-feu, à des fins de sécurité). L’épingle à cheveux peut se produire à l’interface externe du proxy inverse au lieu de l’interface externe du pare-feu. Vous détectez l’usurpation sur le pare-feu et assouplissez la règle au niveau du proxy inverse, ce qui permet l’épingle à cheveux nécessaire à la mobilité.
Utilisez l’hôte DNS (Domain Name System) ou les enregistrements CNAME pour définir le proxy inverse pour le comportement de l’épingle à cheveux (et non le pare-feu), si possible.
Lync Server 2013 prend en charge les services de mobilité pour les clients mobiles Lync 2010 Mobile et Lync 2013. Les deux clients utilisent le service de découverte automatique Lync Server 2013 pour trouver son point d’entrée de mobilité, mais diffèrent quant au service de mobilité qu’ils utilisent. Lync 2010 Mobile utilise le service Mobilité appelé Mcx, introduit avec la mise à jour cumulative pour Lync Server 2010 : novembre 2011. Les clients mobiles Lync 2013 utilisent l’API web communications unifiées, ou UCWA, comme fournisseur de services de mobilité.
Configuration DNS interne et externe
Mobility Services Mcx (introduit avec la mise à jour cumulative pour Lync Server 2010 : novembre 2011) et UCWA (introduit dans les mises à jour cumulatives pour Lync Server 2013 : février 2013) utilisent DNS de la même façon.
Lorsque vous utilisez la découverte automatique, les appareils mobiles utilisent DNS pour localiser les ressources. Lors de la recherche DNS, une connexion est d’abord tentée au nom de domaine complet associé à l’enregistrement DNS interne (lyncdiscoverinternal.< nom> de domaine interne). Si une connexion ne peut pas être établie à l’aide de l’enregistrement DNS interne, une connexion est tentée à l’aide de l’enregistrement DNS externe (lyncdiscover.< sipdomain>). Un appareil mobile interne au réseau se connecte à l’URL interne du service de découverte automatique, et un appareil mobile externe au réseau se connecte à l’URL du service de découverte automatique externe. Les demandes de découverte automatique externe passent par le proxy inverse. Le service de découverte automatique Lync Server 2013 retourne toutes les URL des services Web pour le pool d’accueil de l’utilisateur, y compris les URL du service Mobilité (Mcx et UCWA). Toutefois, l’URL interne du service Mobilité et l’URL du service mobilité externe sont associées au nom de domaine complet des services web externes. Par conséquent, qu’un appareil mobile soit interne ou externe au réseau, l’appareil se connecte toujours au service mobilité Lync Server 2013 en externe via le proxy inverse.
Remarque
Il est important de comprendre que votre déploiement peut se composer de plusieurs espaces de noms distincts pour une utilisation interne et externe. Votre nom de domaine SIP peut être différent du nom de domaine de déploiement interne. Par exemple, votre domaine SIP peut être contoso.com, tandis que votre déploiement interne peut être contoso.net. Les utilisateurs qui se connectent à Lync Server utilisent le nom de domaine SIP, par john@contoso.comexemple . Lorsque vous traitez les services web externes (définis dans le Générateur de topologie en tant que services web externes), le nom de domaine et le nom de domaine SIP sont cohérents, comme défini dans DNS. Lors de l’adressage des services web internes (définis dans le Générateur de topologie en tant que services web internes), le nom par défaut des services web internes est le nom de domaine complet du serveur frontal, du pool frontal, du directeur ou du pool d’administrateurs. Vous avez la possibilité de remplacer le nom des services web internes. Vous devez utiliser le nom de domaine interne (et non le nom de domaine SIP) pour les services web internes et définir l’enregistrement A de l’hôte DNS (ou, pour IPv6, AAAA) pour refléter le nom substitué. Par exemple, le nom de domaine complet des services web internes par défaut peut être pool01.contoso.net. Un nom de domaine complet des services web internes substitué peut être webpool.contoso.net. La définition des services web de cette façon permet de s’assurer que la localité interne et externe des services, et non la localité de l’utilisateur qui les utilise, est observée.
Toutefois, étant donné que les services web sont définis dans le Générateur de topologie et que le nom des services web internes peut être remplacé, tant que le nom des services web résultants, le certificat qui le valide et les enregistrements DNS qui le définissent sont cohérents, vous pouvez définir les services web internes avec n’importe quel nom de domaine(y compris le nom de domaine SIP) souhaité. En fin de compte, la résolution du nom de l’adresse IP est déterminée par les enregistrements hôtes DNS et un espace de noms cohérent.
Pour les besoins de cette rubrique et des exemples, le nom de domaine interne est utilisé pour illustrer la topologie et les définitions DNS.
Le diagramme suivant illustre le flux des demandes web d’application mobile pour le service Mobilité et le service de découverte automatique lors de l’utilisation d’une configuration DNS interne et externe.
service Mobility flux à l’aide de la découverte automatique
.jpg "cdb96424-96f2-4abf-88d7-1d32d1010ffd")
Remarque
Le diagramme illustre les services web génériques. Un répertoire virtuel nommé Mobility représente les services Mobilité Mcx et/ou UCWA. Si vous n’avez pas appliqué les mises à jour cumulatives pour Lync Server 2013 : février 2013, il se peut que le répertoire virtuel Ucwa soit défini sur vos services Web internes et externes. Vous disposez d’une découverte automatique de répertoire virtuel et d’un mcx de répertoire virtuel.
La découverte automatique et la découverte des services fonctionnent de la même façon, quelle que soit la technologie des services de mobilité que vous avez déployée.
Pour prendre en charge les utilisateurs mobiles à l’intérieur et à l’extérieur du réseau d’entreprise, vos noms de domaine complets web internes et externes doivent respecter certaines conditions préalables. En outre, vous devrez peut-être répondre à d’autres exigences, en fonction des fonctionnalités que vous choisissez d’implémenter :
Nouveaux enregistrements DNS, CNAME ou A (hôte, si IPv6, AAAA) pour la découverte automatique.
nouvelle règle de pare-feu, si vous souhaitez prendre en charge les notifications push à travers votre réseau Wi-Fi ;
Soumettez d’autres noms sur les certificats de serveur internes et les certificats proxy inverses, pour la découverte automatique.
La configuration de l’équilibreur de charge matériel du serveur frontal modifie l’affinité source.
Votre topologie doit répondre aux exigences suivantes pour prendre en charge le service Mobilité et le service de découverte automatique :
Le nom de domaine complet web interne du pool frontal doit être distinct du nom de domaine complet web externe du pool frontal.
Le nom de domaine complet web interne doit uniquement être résolu et accessible à partir du réseau d’entreprise.
Le nom de domaine complet web externe doit uniquement être résolu et accessible à partir d’Internet.
Pour un utilisateur qui se trouve dans le réseau d’entreprise, l’URL du service Mobilité doit être adressée au nom de domaine complet web externe. Cette exigence concerne le service Mobilité et s’applique uniquement à cette URL.
Pour un utilisateur qui se trouve en dehors du réseau d’entreprise, la demande doit accéder au nom de domaine complet web externe du pool frontal ou du directeur.
Si vous prenez en charge la découverte automatique, vous devez créer les enregistrements DNS suivants pour chaque domaine SIP :
Un enregistrement DNS interne pour prendre en charge les utilisateurs mobiles qui se connectent à partir du réseau de votre organisation.
Un enregistrement DNS externe ou public pour prendre en charge les utilisateurs mobiles qui se connectent à partir d’Internet.
L’URL de découverte automatique interne ne doit pas être adressable à partir de l’extérieur de votre réseau. L’URL de découverte automatique externe ne doit pas être adressable à partir de votre réseau. Toutefois, si vous ne pouvez pas répondre à cette exigence pour l’URL externe, le client mobile fonctionnellement ne sera probablement pas affecté, car l’URL interne est toujours essayée en premier.
Les enregistrements DNS peuvent être des enregistrements CNAME ou A (hôte, si IPv6, AAAA).
Remarque
Les clients d’appareils mobiles ne prennent pas en charge plusieurs certificats SSL (Secure Sockets Layer) provenant de différents domaines. Par conséquent, la redirection CNAME vers différents domaines n’est pas prise en charge via HTTPS. Par exemple, un enregistrement CNAME DNS pour lyncdiscover.contoso.com qui redirige vers une adresse de director.contoso.net n’est pas pris en charge via HTTPS. Dans une telle topologie, un client d’appareil mobile doit utiliser HTTP pour la première requête, afin que la redirection CNAME soit résolue via HTTP. Les demandes suivantes utilisent ensuite HTTPS. Pour prendre en charge ce scénario, vous devez configurer votre proxy inverse avec une règle de publication web pour le port 80 (HTTP). Pour plus d’informations, consultez « Pour créer une règle de publication web pour le port 80 » dans Configuration du proxy inverse pour la mobilité dans Lync Server 2013.
La redirection CNAME vers le même domaine est prise en charge via HTTPS. Dans ce cas, le certificat du domaine de destination couvre le domaine d’origine.
Pour plus d’informations sur les enregistrements DNS requis pour votre scénario, consultez le résumé DNS - Découverte automatique dans Lync Server 2013.
Exigences en matière de port et de pare-feu
Si vous prenez en charge les notifications Push et souhaitez que les appareils mobiles Apple reçoivent des notifications Push sur votre réseau Wi-Fi, vous devez également ouvrir le port 5223 sur votre réseau Wi-Fi d’entreprise. Le port 5223 est un port TCP sortant utilisé par le service de notification Push (APNS) Apple. L’appareil mobile lance la connexion. Pour plus d’informations, consultez http://support.apple.com/kb/TS1629 .
Avertissement
Un appareil Apple utilisant le client Lync 2013 Mobile ne nécessite pas de notifications Push.
Notez que si un utilisateur est hébergé sur un survivable Branch Appliance (SBA), les ports suivants sont requis :
UcwaSipExternalListeningPort nécessite le port 5088
UcwaSipPrimaryListeningPort nécessite le port 5089
Pour plus d’informations et de conseils sur les exigences en matière de port et de protocole pour la découverte automatique, consultez résumé du port - Découverte automatique dans Lync Server 2013.
Exigences en matière de certificat
Si vous prenez en charge la découverte automatique pour les clients mobiles Lync, vous devez modifier les autres listes de noms de sujet sur les certificats pour prendre en charge les connexions sécurisées à partir des clients mobiles. Vous devez demander et affecter de nouveaux certificats, en ajoutant les autres entrées de nom d’objet décrites dans cette section, pour chaque serveur frontal et directeur qui exécute le service de découverte automatique. L’approche recommandée consiste également à modifier les autres listes de noms de sujet sur les certificats de vos proxys inverses. Vous devez ajouter d’autres entrées de nom d’objet pour chaque domaine SIP de votre organisation.
La rééditation des certificats à l’aide d’une autorité de certification interne est généralement un processus simple, mais l’ajout de plusieurs entrées de nom alternatives de sujet aux certificats publics utilisés par le proxy inverse peut être coûteux. Si vous avez de nombreux domaines SIP, ce qui rend l’ajout de noms alternatifs de sujet très coûteux, vous pouvez configurer le proxy inverse pour effectuer la demande de service de découverte automatique initiale sur le port 80 à l’aide de HTTP, au lieu du port 443 à l’aide de HTTPS (configuration par défaut). La demande est ensuite redirigée vers le port 8080 sur le pool d’annuaires ou frontaux. Lorsque vous publiez la demande de service de découverte automatique initiale sur le port 80, vous n’avez pas besoin de modifier les certificats pour le proxy inverse, car la requête utilise HTTP plutôt que HTTPS. Cette approche est prise en charge, mais nous ne la recommandons pas.
Configuration requise pour Internet Information Services (IIS)
Nous vous recommandons d’utiliser IIS 7.5, IIS 8.0 ou IIS 8.5 pour la mobilité. Le programme d’installation du service Mobilité définit des indicateurs dans ASP.NET pour améliorer les performances. IIS 7.5 est installé par défaut sur Windows Server 2008 R2, IIS 8.0 sur Windows Server 2012 et IIS 8.5 sur Windows Server 2012 R2. Le programme d’installation du service Mobilité modifie automatiquement les paramètres de ASP.NET.
Configuration requise pour l’équilibreur de charge matérielle
Sur l’équilibreur de charge matériel qui prend en charge le pool frontal, les adresses IP virtuelles (VIP) des services web externes pour le trafic des services web doivent être configurées pour la source. L’affinité source permet de s’assurer que plusieurs connexions à partir d’un seul client sont envoyées à un serveur pour conserver l’état de session. Pour plus d’informations sur les exigences d’affinité, consultez Les exigences d’équilibrage de charge pour Lync Server 2013.
Si vous envisagez de prendre en charge les clients mobiles Lync uniquement sur votre réseau Wi-Fi interne, vous devez configurer les adresses IP virtuelles des services Web internes pour la source, comme décrit pour les adresses IP virtuelles des services Web externes. Dans ce cas, vous devez utiliser l’affinité source_addr (ou TCP) pour les adresses IP virtuelles des services Web internes sur l’équilibreur de charge matériel. Pour plus d’informations, consultez les exigences d’équilibrage de charge pour Lync Server 2013.
Configuration requise pour le proxy inverse
Si vous prenez en charge la découverte automatique pour les clients mobiles Lync, vous devez mettre à jour la règle de publication actuelle comme suit :
Si vous décidez de mettre à jour les autres listes de noms de sujet sur les certificats proxy inverses et d’utiliser HTTPS pour la demande de service de découverte automatique initiale, vous devez mettre à jour la règle de publication web pour la découverte lync.< sipdomain>. En règle générale, cela est combiné avec la règle de publication pour l’URL des services web externes sur le pool frontal.
Si vous décidez d’utiliser HTTP pour la demande de service de découverte automatique initiale afin de ne pas avoir à mettre à jour la liste des autres noms d’objet sur les certificats proxy inverses, vous devez créer une règle de publication web pour le port HTTP/TCP 80, s’il n’en existe pas déjà. Si une règle pour HTTP/TCP 80 existe déjà, vous pouvez mettre à jour cette règle pour inclure la découverte lync.< entrée sipdomain> .