Conditions préalables techniques pour la mobilité
Dernière rubrique modifiée : 2013-03-05
Les utilisateurs mobiles font face à différents scénarios d’applications mobiles qui nécessitent une planification particulière. Par exemple, il se peut qu’un utilisateur commence à utiliser une application mobile lors d’un déplacement en se connectant par le biais du réseau 3G, qu’il bascule vers le réseau Wi-Fi d’entreprise à son arrivée au bureau et qu’il rebascule ensuite sur le réseau 3G à sa sortie du bâtiment. Vous devez planifier votre environnement de sorte qu’il prenne en charge ce type de transition de réseau et qu’il garantisse une expérience utilisateur cohérente. Cette section décrit les exigences d’infrastructure à satisfaire pour prendre en charge des applications mobiles et la découverte automatique des ressources de mobilité.
Lorsque vous utilisez la découverte automatique, les appareils mobiles utilisent le système DNS (Domain Name System) pour trouver les ressources. Lors de la recherche DNS, une tentative de connexion est d’abord effectuée vers le nom de domaine complet associé à l’enregistrement DNS interne (lyncdiscoverinternal.<domaineSIP>). Si aucune connexion ne peut être établie à l’aide de l’enregistrement DNS interne, une tentative de connexion est effectuée à l’aide de l’enregistrement DNS externe (lyncdiscover.<domaineSIP>). Un appareil mobile interne au réseau se connecte à l’URL du service de découverte automatique interne, alors qu’un appareil mobile externe au réseau se connecte à l’URL du service de découverte automatique externe. Les demandes externes passent par le proxy inverse. Le service de découverte automatique de Microsoft Lync Server 2010 renvoie toutes les URL des services web correspondant au pool d’accueil de l’utilisateur, y compris les URL du service de mobilité. Toutefois, l’URL du service de mobilité interne et l’URL du service de mobilité externe sont toutes deux associées au nom de domaine complet externe des services web. Par conséquent, qu’il soit interne ou externe au réseau, un appareil mobile se connecte toujours au service de mobilité de Microsoft Lync Server 2010 de manière externe, par le biais du proxy inverse.
.gif "note") Remarque : |
|---|
| Bien que les applications mobiles puissent également se connecter à d’autres services Lync Server, tels que le service de carnet d’adresses, cette exigence relative à l’envoi de toutes les demandes web d’applications mobiles au même nom de domaine complet web externe s’applique uniquement au service de mobilité. Cette configuration n’est pas nécessaire pour les autres services. |
Le diagramme suivant illustre le flux des demandes web d’applications mobiles pour le service de mobilité et le service de découverte automatique.
Flux des demandes d’applications mobiles pour le service de mobilité et le service de découverte automatique
.jpg "cdb96424-96f2-4abf-88d7-1d32d1010ffd")
Pour prendre en charge les utilisateurs mobiles internes et externes au réseau d’entreprise, vos noms de domaine complets web internes et externes doivent remplir certaines conditions. Par ailleurs, certaines conditions supplémentaires peuvent être requises, selon les fonctionnalités que vous choisissez d’implémenter :
nouveaux enregistrements DNS A ou CNAME pour la découverte automatique ;
enregistrement SRV DNS, pour la fédération avec le centre d’échanges de notifications Push (Push Notification Clearing House, PNCH) ;
nouveaux ports pour les serveurs internes ;
nouvelle règle de pare-feu, si vous souhaitez prendre en charge les notifications push à travers votre réseau Wi-Fi ;
autres noms de sujet sur les certificats de serveurs internes et les certificats de proxys inverses, pour la découverte automatique ;
modifications de configuration du programme d’équilibrage de la charge matérielle du serveur frontal pour la persistance basée sur les cookies ;
nouvelles règles de publication web sur le proxy inverse, pour la découverte automatique.
Conditions requises pour les sites web
Votre topologie doit remplir les conditions suivantes afin de prendre en charge le service de mobilité et le service de découverte automatique :
Le nom de domaine complet web interne du pool de serveurs frontaux doit être différent du nom de domaine complet web externe du pool de serveurs frontaux.
Le nom de domaine complet web interne doit uniquement être résolu vers et accessible depuis l’intérieur du réseau d’entreprise.
Le nom de domaine complet web externe (sauf pour l’URL du service de mobilité, qui est adressée par les demandes utilisateur internes et externes) doit uniquement être résolu vers et accessible depuis Internet.
Pour un utilisateur qui se trouve sur le réseau d’entreprise, l’URL du service de mobilité doit être adressée au nom de domaine complet web externe. Cette exigence concerne le service de mobilité et s’applique uniquement à cette URL.
Pour un utilisateur qui se trouve à l’extérieur du réseau d’entreprise, la demande doit parvenir au nom de domaine complet web externe du pool de serveurs frontaux ou du directeur.
Si vous avez un environnement DNS de type split-brain et que les clients d’appareils mobiles se connecteront sans fil, vous devez configurer le nom de domaine complet web externe dans le système DNS interne avec l’adresse IP publique.
Exigences relatives au système DNS
Votre topologie doit satisfaire les exigences DNS indiquées dans les sections suivantes pour prendre en charge le service de mobilité et le service de découverte automatique.
Exigence d’URL du service de mobilité
Dans une configuration par défaut, un utilisateur qui est connecté au réseau interne via Wi-Fi aura toujours l’URL de service de mobilité externe renvoyée pour son pool d’accueil. L’appareil de l’utilisateur doit pouvoir interroger la zone DNS interne et résoudre le nom de domaine complet des services web Lync externes en adresse IP de l’interface externe du proxy inverse. L’utilisateur effectue alors une connexion en épingle sortante vers le service de mobilité via le proxy inverse.
Exigences de découverte automatique et des notifications Push
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 afin de prendre en charge les utilisateurs qui se connectent depuis le réseau de votre organisation ;
un enregistrement DNS externe, ou public, afin de prendre en charge les utilisateurs mobiles qui se connectent depuis Internet ;
un enregistrement DNS externe ou public pour prendre en charge les notifications Push.
L’URL de découverte automatique interne ne doit pas être adressable depuis l’extérieur de votre réseau. L’URL de découverte automatique externe ne doit pas être adressable depuis votre réseau. Toutefois, si cette condition ne peut pas être remplie pour l’URL externe, la fonctionnalité du client mobile ne devrait pas être affectée car la première tentative porte toujours sur l’URL interne.
Les enregistrements DNS peuvent être des enregistrements CNAME ou des enregistrements A (hôte).
Vous devez créer l’enregistrement DNS interne suivant :
Enregistrements DNS internes
| Type d’enregistrement | Nom d’hôte | Résolu en |
|---|---|---|
A (hôte) |
lyncweb.contoso.com (exemple d’URL de services web externes) |
Enregistrement situé sur le DNS interne qui est résolu en adresse IP externe de l’URL des services web externes, par exemple https://lyncweb.contoso.com |
Et, l’un des enregistrements DNS internes supplémentaires suivants :
| Type d’enregistrement | Nom d’hôte | Résolu en |
|---|---|---|
CNAME |
lyncdiscoverinternal.<domaine_SIP> |
Nom de domaine complet interne des services web pour votre pool de directeurs, si vous en avez un, ou pour votre pool de serveurs frontaux si vous n’avez pas de directeur |
A (hôte) |
lyncdiscoverinternal.<domaine_SIP> |
Adresse IP interne des services web (adresse IP virtuelle [VIP] si vous utilisez un programme d’équilibrage de la charge) de votre pool de directeurs, si vous en avez un, ou de votre pool de serveurs frontaux si vous n’avez pas de directeur. |
Vous devez créer l’un des enregistrements DNS externes suivants :
Enregistrements DNS externes
| Type d’enregistrement | Nom d’hôte | Résolu en |
|---|---|---|
CNAME |
lyncdiscover.<domaine_SIP> |
Nom de domaine complet externe des services web pour votre pool de directeurs, si vous en avez un, ou pour votre pool de serveurs frontaux si vous n’avez pas de directeur |
A (hôte) |
lyncdiscover.<domaine_SIP> |
Adresse IP publique ou externe du proxy inverse |
| Remarque : |
|---|
| Le trafic externe passe par le proxy inverse. |
| Remarque : |
|---|
| Les clients d’appareils mobiles ne prennent pas en charge plusieurs certificats SSL (Secure Sockets Layer) de différents domaines. Par conséquent, la redirection CNAME vers différents domaines n’est pas prise en charge sur le protocole HTTPS. Par exemple, un enregistrement DNS CNAME pour lyncdiscover.contoso.com qui redirige vers une adresse director.contoso.net n’est pas pris en charge sur HTTPS. Dans une telle topologie, un client d’appareil mobile doit utiliser le protocole HTTP pour la première demande, de sorte que la redirection CNAME soit résolue sur HTTP. Les demandes ultérieures utilisent ensuite le protocole 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 de détails, voir « Pour créer une règle de publication web pour le port 80 » dans Configuration du proxy inverse pour la mobilité. La redirection CNAME vers le même domaine est prise en charge sur HTTPS. Dans ce cas, le certificat du domaine de destination couvre le domaine d’origine. |
| Type d’enregistrement | Définition | Résolu en | ||
|---|---|---|---|---|
SRV |
_sipfederationtls._tcp.<nom de domaine SIP> en enregistrement hôte A du service Edge d’accès |
par exemple _sipfedrationtls._tcp.contoso.com avec le port TCP 5061 défini à sip.contoso.com
|
.gif "important")
Important :Exigences relatives aux ports et aux pare-feu
Le service de mobilité requiert les deux ports d’écoute de services web suivants sur les serveurs frontaux ou les serveurs Standard Edition. Vous devez définir manuellement ces ports lors du processus de déploiement à l’aide de l’applet de commande Set-CsWebServer. Pour plus de détails, voir Définition des ports de serveurs internes pour la mobilité.
Vous devez également créer une règle d’autorisation pour TCP 5061 pour la fédération avec le fournisseur en ligne pour les notifications Push. Pour plus d’informations, voir Architecture de référence.
port 5086, utilisé pour écouter les demandes de mobilité émanant du réseau d’entreprise. Il s’agit d’un port SIP utilisé par le processus interne du service de mobilité ;
port 5087, utilisé pour écouter les demandes de mobilité émanant d’Internet. Il s’agit d’un port SIP utilisé par le processus externe du service de mobilité.
Si vous prenez en charge les notifications push et souhaitez que les appareils mobiles Apple reçoivent des notifications push par le biais de votre réseau Wi-Fi, vous devez également ouvrir le port 5223 sur votre réseau Wi-Fi d’entreprise. Il s’agit d’un port TCP sortant utilisé par le service APNS (Apple Push Notification Service). L’appareil mobile ou le service de notification peut initier la connexion, nécessitant une disponibilité de ports sortants sur le réseau Wi-Fi d’entreprise. Pour plus d’informations, voir http://support.apple.com/kb/TS1629?viewlocale=fr_FR?viewlocale=fr_FR et http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
Exigences en matière de certificats
Si vous prenez en charge la découverte automatique pour les clients mobiles Lync, vous devez modifier la liste des autres noms de sujet sur les certificats de manière prendre en charge les connexions sécurisées établies à partir de clients mobiles. Vous devez demander et assigner de nouveaux certificats, en ajoutant les entrées d’autres noms de sujet comme décrit dans cette section, pour chaque serveur frontal et directeur qui exécute le service de découverte automatique. L’approche recommandée consiste à modifier également les listes d’autres noms de sujet sur les certificats pour vos proxys inverses. Vous devez ajouter des entrées d’autres noms de sujet pour chaque domaine SIP de votre organisation.
La réémission de certificats à l’aide d’une autorité de certification interne est généralement un processus simple, mais l’ajout de plusieurs entrées d’autres noms de sujet à des certificats publics utilisés par le proxy inverse peut être une opération coûteuse. Si vous avez de nombreux domaines SIP, ce qui rend l’ajout d’autres noms de sujet très coûteux, vous pouvez configurer le proxy inverse de sorte qu’il effectue la demande initiale du service de découverte automatique sur le port 80 à l’aide du protocole HTTP, plutôt que sur le port 443 à l’aide du protocole HTTPS (configuration par défaut). La demande est alors redirigée vers le port 8080 sur le directeur ou le pool de serveurs frontaux. Lorsque vous publiez la demande initiale du service de découverte automatique sur le port 80, il n’est pas nécessaire de modifier les certificats pour le proxy inverse car la demande utilise le protocole HTTP plutôt que HTTPS. Cette approche est prise en charge mais non recommandée.
| Remarque : |
|---|
| Pour plus de détails sur l’utilisation du port 80 pour la demande initiale, voir « Processus de découverte automatique initiale à l’aide du port 80 » dans Configuration requise pour le service de découverte automatique, dans la documentation Planification des utilisateurs externes. |
| Remarque : |
|---|
| Si votre infrastructure Lync Server 2010 utilise des certificats internes émis par une autorité de certification interne et que vous prévoyez de prendre en charge la connexion sans fil d’appareils mobiles, la chaîne de certificats racine de l’autorité de certification interne doit être installée sur les appareils mobiles ou vous devez passer à un certificat public sur votre infrastructure Lync Server. |
Cette section décrit les autres noms de sujet requis pour les certificats suivants :
serveur Edge ou pool de serveurs Edge
directeur ou pool de directeurs
serveur frontal ou pool de serveurs frontaux
Proxy inverse
Description |
Entrée d’autre nom de sujet |
service Edge d’accès |
SAN=sip.<domainesip> |
Exigences relatives au certificat du pool directeur
| Description | Entrée d’autre nom de sujet |
|---|---|
URL du service de découverte automatique interne |
SAN=lyncdiscoverinternal.<domaine_SIP> |
URL du service de découverte automatique externe |
SAN=lyncdiscover.<domaine_SIP> |
| Remarque : |
|---|
| Vous pouvez également utiliser SAN=*.<domaine_SIP> uniquement pour les enregistrements de découverte automatique (lyncdiscover et lyncdicoverinternal). |
Exigences relatives au certificat du pool frontal
| Description | Entrée d’autre nom de sujet |
|---|---|
URL du service de découverte automatique interne |
SAN=lyncdiscoverinternal.<domaine_SIP> |
URL du service de découverte automatique externe |
SAN=lyncdiscover.<domaine_SIP> |
| Remarque : |
|---|
| Vous pouvez également utiliser SAN=*.<domaine_SIP> uniquement pour les enregistrements de découverte automatique (lyncdiscover et lyncdicoverinternal). |
Exigences relatives au certificat de proxy inverse (autorité de certification publique)
| Description | Entrée d’autre nom de sujet |
|---|---|
URL du service de découverte automatique externe |
SAN=lyncdiscover.<domaine_SIP> |
| Remarque : |
|---|
| Vous assignez ce certificat à l’écouteur SSL sur le proxy inverse. |
Exigences relatives aux Services Internet (IIS)
Nous vous recommandons d’utiliser les services Internet (IIS) 7.5 pour la mobilité. Le programme d’installation du service de mobilité définit certains indicateurs ASP.NET afin d’améliorer les performances. Les services Internet (IIS) 7.5 sont installés par défaut sur Windows Server 2008 R2 et le programme d’installation du service de mobilité modifie automatiquement les paramètres ASP.NET. Si vous utilisez les services Internet (IIS) 7.0 sur Windows Server 2008, vous devez modifier manuellement ces paramètres. Pour plus de détails, voir Installation des services de mobilité et de découverte automatique.
Exigences relatives au programme d’équilibrage de la charge matérielle
Si votre environnement comprend un pool de serveurs frontaux, les adresses IP virtuelles des services web externes sur le programme d’équilibrage de la charge matérielle utilisé pour le trafic des services web doivent être configurées pour la persistance basée sur les cookies. Celle-ci permet de s’assurer que plusieurs connexions issues d’un même client sont envoyées à un seul serveur pour maintenir l’état de la session. Les cookies doivent remplir des conditions spécifiques. Pour plus de détails sur les exigences relatives aux cookies, voirConfiguration requise pour l’équilibrage de charge.
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 persistance basée sur les cookies comme décrit pour les adresses IP virtuelles des services web externes. Dans cette situation, vous ne devez pas utiliser la persistance basée sur l’adresse source pour les adresses IP virtuelles des services web internes sur le programme d’équilibrage de la charge matérielle. Pour plus de détails, voir Configuration requise pour l’équilibrage de charge.
Exigences relatives au proxy inverse
Si vous prenez en charge la découverte automatique pour les clients mobiles Lync, vous devez créer une règle de publication web comme suit :
Si vous décidez de mettre à jour les listes d’autres noms de sujet sur les certificats de proxy inverse et d’utiliser le protocole HTTPS pour la demande initiale de découverte automatique, vous devez créer une règle de publication web pour lyncdiscover.<domaine_SIP>. Vous devez en outre vous assurer qu’il existe une règle de publication web pour l’URL externe des services web sur le pool de serveurs frontaux.
Si vous décidez d’utiliser HTTP pour la demande initiale du service de découverte automatique afin de ne pas être obligé de mettre à jour la liste des autres noms de sujet sur les certificats de proxy inverse, vous devez créer une règle de publication web pour le port 80 (HTTP).