Exchange your Mind

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archive for the ‘Lync 2010’ Category

Lync 2010 : SIP : Notions de base

Posted by Teruin laurent le février 9, 2013


Ce petit article détaille quelques éléments de base concernant le protocole SIP. Nous détaillerons également les principes de base via des exemples tirés de l’environnement Lync 2010.Pour plus de détails sur le protocole Sip, je vous invite à vous reporter à la source soit la RFC 3261 (http://www.ietf.org/rfc/rfc3261.txt)

Définition du protocole SIP (RFC 3261)

Le protocole SIP est un protocole appartenant à la couche applicative qui permet d’établir, modifier, et terminer des sessions multimédia (Conférence) tels que des communications téléphonique à travers Internet. Il permet en autre chose d’inviter des participants au sein de sessions déjà établie comme des conférences multidiffusion (Multicast). SIP permet la création d’infrastructure serveur (Proxy Sip) autorisant les clients à effectuer des opérations d’enregistrement, d’invitation etc… SIp ne constitue pas à proprement parler un environnement vertical mais se présente plutôt comme un composant pouvant servir de support a d’autre protocoles émanant de l’IETF permettant de bâtir une architecture complète multimédia.

Dans l’environnement SIP, on ne parle pas de client mais de d’agent Utilisateur (UA). Cet Agent Utilisateur ou plus communément appelé UA est généralement un programme permettant de créer ou de recevoir des messages au format SIP entretenant par la une « conversation ». Un UA ou User Agent client (UAC) envoi des requêtes vers un serveur SIP nommé souvent UAS ou Registrar. Dans l’environnement Lync ceci sera assuré par un serveur Lync 2010 frontal. Ce dernier recevant les requêtes client qui va soit y répondre soit les transférer. Les actions de ses deux acteurs UAC et UAS entretienne donc une conversation SIP lors par exemple d’un ‘un appel utilisateur. Une fois l’appel terminé le dialogue est interrompu.

Pour établir une conversation ses deux acteurs utilisent des méthodes et des formats de réponses codées. Le tableau suivant liste quelques méthodes fréquemment utilisés. (liste non exaustive)

Méthode

Réponses possibles

Invite 

1xx – Provisional 

ACK 

2xx – Successful 

BYE 

3xx – Redirection 

Cancel 

4xx – Request Failure 

Options 

5xx – Server Failure 

Register 

6xx – Global Failures 

 

Les requêtes sip sont généralement initialisées depuis un UAC ou UAS. L’intérêt du protocole Sip est qu’il est très explicite, d’autre diront qu’il est parfois un peu trop verbeux. Malgré, parfois certaine implémentation propriétaire, le protocole SIP est en réalité une suite de RFC validée et qui sont implémentées dans l’environnement Lync. Ces RFC font souvent référence au verbe dans le dialogue SIP et montre l’évolution de ce protocole.

Le tableau ci-dessous en précise quelque une

Méthode

Description

RFC en question

INVITE 

. Indique que un client est invite à prendre part a un appel

RFC 3261  

ACK 

Valide que le client a reçu le requête 

RFC 3261  

BYE 

Termine un call Terminates a call and can be sent by either the UAS or the UAC. 

RFC 3261  

CANCEL 

Annule tous les requêtes en suspens 

RFC 3261  

OPTIONS 

Queries the capabilities of servers.

RFC 3261  

REGISTER 

Registers the address listed in the To header field with a SIP server.  

RFC 3261  

PRACK 

Provisional acknowledgement. 

RFC 3262  

SUBSCRIBE 

Subscribes for an Event of Notification from the UAC. 

RFC 3265  

NOTIFY 

Notify the subscriber of a new Event.

RFC 3265  

PUBLISH 

Publishes an event to the Server. 

RFC 3903  

INFO 

Sends mid-session information that does not modify the session state. 

RFC 2976  

REFER 

Asks recipient to issue SIP request (call transfer).  

RFC 3515  

MESSAGE 

Transports instant messages using SIP.

RFC 3428  

UPDATE 

Modifies the state of a session without changing the state of the dialog. 

RFC 3311  

 

Pour illustrer notre propos, Voici quelques échanges de message avec deux Méthodes différentes utilisée dans l’environnement Lync 2010. Note : Pour qu’une requête SIP soit valide ils faut à minima quelle contiennent les entêtes suivantes : To, From, CSeq, Call-ID, Max-Forwards, and Via;

Le champ :

  • To : précise la destination
  • From : l’expéditeur
  • Cseq : un numéro incrémenté à chaque requête
  • Call- ID : Contient un numéro d’identification unique de l’appel
  • Max-Forwards : le nombre de saut maximum pour atteindre la destination. A chaque saut cette valeur est décrémentée de 1
  • Via : Contient l’adresse ou la personnes est sensée être capable de recevoir l’appel : Exemple Via: SIP/2.0/TLS 192.168.1.1:51344;ms-received-port=51344;ms-received-cid=4F900

Enregistrement SIP / REGISTER

L’enregistrement Sip est la première étape avant l’établissement d’une connexion de messagerie instantanée. Comme par définition un client Sip est mobile, un UAC peut s’inscrire auprès de différents serveurs. Dans le cas de Lync soit l’utilisateur est à l’intérieur et il fera sa connexion vers le serveur frontal, soit il est connecté sur Internet et celle-ci se fera vers les serveurs edge. Dans l’exemple suivant DavidP tente de se connecter vers le serveur IP 192.168.1.100 et négocie une connexion en TLS

Severity: information
Text: TLS negotiation started
Local-IP: 192.168.1.100:5061
Peer-IP: 192.168.1.1:51344
Connection-ID: 0x4F900
Transport: TLS

Dans le même temps Davidp envoi une demande de registration vers le serveur Lync en question. Vous trouverez ci-dessous une extraction du dialogue Sip en question

LogType: connection
Direction: Incoming
Peer: 192.168.1.1:51344
Message-Type: request
Start-Line: REGISTER sip:unifiedit.com SIP/2.0
From: <sip:DavidP@unifiedit.com>;tag=97152a1f83;epid=f4bced5b3a
To: sip:DavidP@unifiedit.com
CSeq: 1 REGISTER
Call-ID: 1b7168b487f5445c97d3674dc0d4c2ac

Contact: <sip:192.168.1.1:51344;transport=tls;ms-opaque=f6005201e2>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:E0233F84-0D8B-5465-8381-252C60B5B65C>"
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)

Event: registration
Content-Length: 0
Message-Body: –

Dans ce type de dialogue et parce qu’il peut y en avoir plusieurs bien évidement, chaque dialogue est identifié par une chaine alphanumérique unique nommée TAG. Quant au client, il est identifié avec une autre chaque également numérique nommé epid. C’est ce que vous apercevez dans le dialogue ci-dessus.

Une fois que cette phase est terminée, le processus d’authentification peut commencer. Lync utilise pour cela trois méthodes d’authentification selon l’emplacement de l’utilisateur.

  • WWW-Authenticate: Kerberos
  • WWW-Authenticate: NTLM
  • WWW-Authenticate: TLS-DSK (Transport Layer Security – Derived Shared Key) / Par défaut.

Kerberos peut être utilisé en interne, NTLM & TLS-DSK en interne et en externe.

Comme la précédente demande était réalisée par le client sans préciser la méthode d’authentification, le serveur va répondre par un message lui précisant que la requête n’est pas autorisée et en présentant aux clients ses méthodes d’authentification. C’est ce que vous voyez dans le message suivant :

Direction: outgoing;source="local"
Peer: 192.168.1.1:51344
Message-Type: response
Start-Line: SIP/2.0 401 Unauthorized
From: <sip:davidp@unifiedit.com>;tag=97152a1f83;epid=f4bced5b3a
To: <sip:davidp@unifiedit.com>;tag=B69C844CB75A152A278AE2F0D9791097
CSeq: 1 REGISTER
Call-ID: 1b7168b487f5445c97d3674dc0d4c2ac

Date: Mon, 17 May 2010 14:09:40 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="LabPool.unifiedit.com", version=4
WWW-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/Lab-Pool.unifiedit.com", version=4
WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="Lab-Pool.unifiedit.com", version=4, sts-uri=https://int cspool.unifiedit.com:443/CertProv/CertProvisioningService.svc
Via: SIP/2.0/TLS 192.168.1.1:51344;ms-received-port=51344;ms-received-cid=4F900
Content-Length: 0
Message-Body: –

 

Le client va alors répondre avec le message suivant. On notera que le la valeur CSed est incrémentée au passage.

Direction: incoming
Peer: 192.168.1.1:51344
Message-Type: request
Start-Line: REGISTER sip:unifiedit.com SIP/2.0
From: <sip:davidp@unifiedit.com>;tag=97152a1f83;epid=f4bced5b3a
To: sip:davidp@unifiedit.com
CSeq: 2 REGISTER
Call-ID: 1b7168b487f5445c97d3674dc0d4c2ac

Contact: <sip:192.168.1.1:51344;transport=tls;ms-opaque=f6005201e2>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER,
BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:E0233F84-0D8B-5465-8381-252C60B5B65C>"
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)

Event: registration
ms-subnet: 192.168.0.0
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", targetname="sip/Lab-Pool.unifiedit.com", version=4, gssapi-data="…", crand="3f00eea3", cnum="1",
response="040400ffffffffff0000000000000000858957d8cf09fd1a4754d919"
Content-Length: 0
Message-Body: –

 

  • Proxy Authorization porte la signature du message sip et un jeton unique pour l’association de sécurité (SA)
  • Realm : identifie quelle information d’indentification est utilisée pour signer le message
  • Version : Précise la version du protocole utilisée.
  • Crand : valeur aléatoire utilisé pour renforcer le cryptage)
  • Cnum : Identifie une séquence de nombre et permet de pister quelles données ont été transmise. Cette valeur est augmentée à chaque nouvel échange avec le serveur.

Une fois le processus d’authentification réalisé, le client va se voir assigné un identifiant unique nommé Globally Routable User Agent URI (GRUU) et qui va formellement identifier le point de connexion client. La valeur Epid est utilisée pour construire la valeur GRUU mais ne sera plus utilisée pour identifier formellement le client.

SOUSCRIPTION (SUBSCRIBE)

Une fois que la connexion aux services est réalisée, DavidP va s’abonner à une liste de contact qu’il aura au préalable choisi.

C’est le dialogue que l’on voit dans l’exemple suivant :

Direction: incoming
Peer: 192.168.1.1:52848
Message-Type: request
Start-Line: SUBSCRIBE sip:davidp@unifiedit.com SIP/2.0
From: <sip:davidp@unifiedit.com>;tag=47d7d0882a;epid=f4bced5b3a
To: sip:davidp@unifiedit.com
CSeq: 1 SUBSCRIBE
Call-ID: e6befddced82439298f37b91333d7d54

Contact: sip:davidp@unifiedit.com;opaque=user:epid:hD8j4IsNZVSDgSUsYLW2XAAA;gruu
User-Agent: UCCAPI/4.0.7337.0 OC/4.0.7337.0 (Microsoft Lync 2010)
Event: vnd-microsoft-roaming-contacts
Accept: application/vnd-microsoft-roaming-contacts+xml

 

L’entête vnd-microsoft-roaming-contacts va permettre d’identifier qu’il s’agit d’une liste de contact.
L’entête application/vnd-Microsoft-Roaming-contacts+Xml précise le fichier attendu pour récupérer les données de contact que le serveur va renvoyer.

SIP comporte bien d’autre fonction beaucoup plus élaborée et si vous êtes intéressé rien ne vaut la lecture de la RFC.

Cordialement
Laurent Teruin

Posted in Lync 2010 | Leave a Comment »

Principe de connexion des clients Lync via des réseaux Natés (Partie 1)

Posted by Teruin laurent le février 8, 2013


Les fonctions de Nat sont un véritable problème dans l’environnement VOIP car ces dernières ne prennent pas en compte les spécificités du protocole SIP. Le problème est alors d’établir une connexion entre deux utilisateurs qui a travers une connexion nattée, tenteraient d’établir une connexion Audio-vidéo .Le principe est simple. Si l’utilisateur 1 possédant l’adresse Ip 192.168.1.1 est basé chez lui et qu’il utilise une connexion nattée en 61.1.1.1 à travers sa box internet il pourra sans problème se connecter sur le serveur Edge Lync. Même chose pour l’utilisateur 2 qui lui utilise l’adresse ip privée 192.168.1.2 d’entreprise natté également à travers une adresse IP 62.2.2.2 qui lui sera connecté sur le serveur Frontal Lync 2010/2013

Bien qu’il soit sur le même réseau IP domestique (192.168.1.x) le flux média point à point ne pourra pas s’établir pour des raisons évidentes puisque l’un est à la maison et l’autre au travail. Cependant comme vous pourrez le remarquer sur la figure suivante la signalisation SIP via TCP elle se fera correctement mais pas de flux Audio ou vidéo qui eux utilisent la couche de transport UDP.


Figure 1 :Media and nat

Dans le flux de signalisation ci-dessus, chaque partie indique son adresse IP dite Candidate. Une Adresse Candidate est une combinaison d’une adresse IP et d’un port de connexion. Pour l’utilisateur à la maison c’est la valeur a et pour l’utilisateur au sein de sa société c’est W. Cependant comme celles-ci sont cachées derrière une adresse Ip natté elles ne seront pas joignables directement par le flux média. La solution consiste donc à utiliser des protocoles qui vont aider à la publication de véritables adresses candidate des clients ou dans certain cas d’un serveur de relai de média. Dans notre cas de figure c’est effectivement le serveur Edge qui va assurer ce rôle Le serveur Edge comme son nom l’indique est un serveur de périphérie qui est joignable sur Internet via les enregistrements SRV des serveurs DNS. De ce fait, il va assurer ce que l’on appelle la fonction de proxy SIP pour les connexions provenant de l’extérieur. La figure ci-dessous illustre une connexion Sip vers un serveur Edge.


Figure 2 : Edge is a Sip Proxy serveur

L’utilisation des fonctions STUN (Simple Traversal Of UDP throught NAT) va permettre de transmettre les adresses IP Natée (b) and (e) et TURN de relayer les paquets média (c) (d) (x) (y) comme le montre la figure suivante.A propos du protocole STUN on notera que ce protocole est également utilisé en dehors du Protocole UDP et qu’on le trouve nommé de ce fait également comme Simple Traversal Utilities for Nat.


Figure 3 : Adresse Candidate

Quant au protocole ICE (Interactive Connectivity Establishement) ce dernier va déterminer le chemin optimal pour le flux média. Dans le schéma précédent, le client de la société va initier un flux de signalisation (en vert sur le diagramme) en SIP sur TCP et présenter une liste d’adresse candidate sur lesquelles il est potentiellement joignable. L’utilisateur de la maison va faire pareil. C’est ainsi que l’utilisateur Maison présentera les adresses A (comportant l’adresse IP réelle de son pc et son port de connexion), l’adresse B (Comportant l’adresse natée de sa box et son port de connexion) pour le flux média et l’adresse E pour la signalisation. D’une façon générale, nous allons trouver dans l’environnement Lync des clients dit client ICE dès lors qu’ils vont activer leurs fonctions audio – vidéo. Les clients Web de Lync 2010 à ce propose ne sont pas tout à fait des clients ICE sauf quand ces derniers se mettent à partager leurs bureaux (Desktop Sharing).

À propos de Ice

 

Pour établir une session média 5 phases seront nécessaires

  1. Provisionnement Turn et des informations de connexion (MRAS)
  2. Découverte des adresses
  3. Échange des adresses (SIP Invite /200 OK)
  4. Vérification la connectivité
  5. Promotion de la candidate

La figure suivante précise les différentes étapes de connexion lorsqu’un utilisateur distant se connecte vers un serveur Edge depuis le réseau Internet.


Figure 4 : Principe de connexion a travers un serveur Edge

Etape 1 et 2 : La première étape est représentée par la fonction sip register qui va se servir des enregistrements SRV pour localiser le serveur Access Edge. Le serveur Edge passera la requête au serveur frontal qui répondra par un message 200 OK et qui précisera les diverses stratégies, règle de normalisation et le paramétrage pour le client en question. Dans le message de retour du serveur Frontal via le serveur Edge, il est également préciser l’adresse du service d’authentification du serveur de relai média (MrasUrip) comme le précise la figure ci-dessus.

La figure suivante illustre le dialogue et l’annonce des fameuses « candidate »


Figure 5 : Adresse Candidate dans Sip invite

Etape 3 : L’étape suivante est l’envoi d’un paquet SIP précisant au serveur Lync frontal la localisation du client en question. Dans notre cas, le client est situé sur Internet et va donc avoir la nécessité de se connecter sur le serveur Audio-Vidéo pour établir un flux média.

Etape 4 : Le serveur Audio/Vidéo ne faisant pas partie du domaine Active Directory et n’ayant par conséquent pas accès à l’annuaire de l’entreprise, c’est alors le serveur Lync qui va demander au serveur Edge audio vidéo un compte et un mot de passe pour que notre utilisateur puisse l’utiliser afin de pouvoir se connecter. C’est l’échange que vous voyez en bas à gauche (Service / 200 OK)

Ci-dessous un contenu de l’échange capturé par snooper


Etape 5 : Une fois ce compte et ce mot de passe obtenu le serveur Frontal via le serveur Edge va établir une communication vers notre client sur Internet pour lui communiquer ses informations de connexion qui lui permettront de se connecter durant une période de 8 heures. (480 Minutes). Pour cela, il communiquera a notre utilisateur, le compte et le mot de passe mais également le port de connexion tcp et udp ainsi que le nom du serveur en question. L’intérêt de cette solution est quelle est rapide car à chaque fois que l’utilisateur externe va effectuer un appel il utilisera ce compte et ce mot de passe et s’adressera directement au serveur en question, et ce pour une durée de 8 heures.Pour ce qui est des conférences Anonymes on retrouve un peu se même comportement mais simplifié car l’utilisateur effectue une requête sip avec une connexion anonyme cette fois ci.

 


Figure 6 Principe de connexion avec une conférence


 

Posted in Lync 2010 | Leave a Comment »

The Lync Server Access Edge service terminated with service-specific error %%-2146762495

Posted by Teruin laurent le janvier 21, 2013


Bonjour

Un petit souci de bon matin. Plus de connexion sur un serveur Edge avec en prime une belle petite erreur. The Lync Server Access Edge service terminated with service-specific error %%-2146762495.

C’est limpide non ? Bon en fait si vous expérimentez ce genre de souci cela devrait être un problème de certificat qui a expiré sur un serveur Edge

 


 

Procédez au renouvellement et tout devrait revenir dans l’ordre.

Ci-dessous l’erreur générée

 

Cordialement

Laurent Teruin

 

 

 

Log Name: System
Source: Service Control Manager

Date: 1/21/2013 9:18:14 AM
Event ID: 7024
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: EDGE01.Unifiedit.com
Description:
The Lync Server Access Edge service terminated with service-specific error %%-2146762495.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"&gt;
<System>
<Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager" />
<EventID Qualifiers="49152">7024</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime="2013-01-21T08:18:14.699081000Z" />
<EventRecordID>98925</EventRecordID>
<Correlation />
<Execution ProcessID="540" ThreadID="11116" />
<Channel>System</Channel>
<Computer>EDGE01.Unifiedit.com</Computer>
<Security />
</System>
<EventData>
<Data Name="param1">Lync Server Access Edge</Data>
<Data Name="param2">%%-2146762495</Data>
</EventData>
</Event>


 

Posted in Lync 2010 | Leave a Comment »

Lync 2010 Edge Publication : Équilibrage de charge DNS ou répartition de charge matérielle ?

Posted by Teruin laurent le janvier 10, 2013


La publication des services Edge est une chose délicate car parfois incomprise par les services réseaux car impliquant des contraintes liées à la supportabilité de Nat et des flux Vidéo.

Dans l’environnement Lync deux solutions sont possibles pour publier des services Edge vers l’internet.

  • La première est de se baser sur les fonctions de répartiteur de charges matérielles déjà présentes au sein de l’entreprise.
  • La seconde est de ne pas recourir aux répartiteurs de charge pour utiliser des fonctions plus primaires que sont les fonctions d’équilibrage de charge DNS.

Mais avant de détailler les avantages et les inconvénients de deux solutions, petit rappel sur la technologie DnsLb souvent confondue avec DnsRoundRobin.

Les fonctions d’équilibrage de charge DNS (Dnslb) se basent sur la publication multiple d’une ressource de quelque nature que ce soit, (dans notre exemple nous considérons pour Lync, les ressources sip.unfiedit.com, Webcon.unifiedit.com, Av.unifiedit.com) au sein d’un DNS. Dans le cas d’un environnement Round Robin possédant deux enregistrements inscrits pour la même ressource, le serveur DNS reverra aléatoirement soit le premier soit le second enregistrement au client. Ce dernier tentera ensuite de se connecter à l’adresse Ip renvoyée par le serveur DNS et ce, même si le service en question est offline. Si le serveur Lync frontal ou Edge correspondant à cette adresse ip est hors service, alors le client Lync renverra une erreur de connexion. L’utilisateur aura peut-être la chance, une fois que le cache DNS client se soit vidé de cet enregistrement, de peut-être, tomber sur le second enregistrement et de facto se connecter alors sur le second serveur Lync qui lui est en fonction. Mais rien n’est moins sûr…. C’est le principe de la roulette.

Dans l’environnement d’équilibrage de charge DNS (Dnslb), le principe est un peu différent car dans ce cas le service DNS va renvoyer aux clients les deux enregistrements correspondants au service demandé et seul le client va décider de choisir aléatoirement telle ou telle adresses IP. C’est donc le client qui va effectuer la répartition de charge en lieu et place d’un répartiteur de charge ou d’un service DNS Round Robin. Dans l’environnement Lync sachez que les fonctions de Dnslb sont supportées pour les pools frontaux, les pools de serveurs Edge, les pools directeurs et les pools de serveurs de médiation autonomes mais pas pour la répartition de charges http. Pour celle-ci vous devrez obligatoirement passer par une répartition de charge matérielle.

Publication des Edge à travers un Équilibrage de charge DNS

Pour déployer l’équilibrage de charge DNS Dnslb sur l’interface externe de votre pool de serveurs Edge, vous avez besoin des entrées DNS suivantes et si vous comptez correctement, vous devrez dans le cas d’une publication de deux serveurs Edge recourir à 6 adresses IP publiques:

  • SIP : Pour le service Edge d’accès, vous avez besoin d’une entrée pour chaque serveur dans le pool. Chaque entrée doit résoudre le nom de domaine complet du service Edge d’accès (par exemple, sip.unifiedit.com)
  • Webconf : Pour le service Edge de conférence web, vous avez besoin d’une entrée pour chaque serveur dans le pool. Chaque entrée doit résoudre le nom de domaine complet du service Edge de conférence web (par exemple, webconf.unifiedit.com)
  • AV : Pour le service Edge audio/vidéo, vous avez besoin d’une entrée pour chaque serveur dans le pool. Chaque entrée doit résoudre le nom de domaine complet du service Edge audio/vidéo (par exemple, av. unifiedit.com)

Dans ce cas de figure 6 adresses IP publique seront nécessaires est devront être natées de l’extérieur vers les adresses IP externes de vos deux serveurs Lync Edge. C’est ce qu’illustre le schéma suivant issue de la documentation Microsoft.


Intérêts de la publication par Équilibrage de charge DNS des services Edge

L’intérêt de cette solution est quelle est relativement simple à mettre en place et permet de traverser un Firewall qui va effectuer de la translation d’adresse vers le réseau interne. Dans le cas de notre réseau par exemple, l’adresse IP publique 131.107.155.10 sera natée vers la 10.45.16.10 et la 131.107.155.11 vers le second serveur Edge répondant sur l’adresse 10.45.16.11.

Simple efficace mais…. Mais …vous avez dit mais ?

Cette solution a quelques limitations notamment dans le cas de la fédération avec des anciennes versions OCS (Ocs & OCS R2) et les messageries publiques qui elles, ne savent pas gérer les fonctions de DnsLB. L’objectif et vous l’aurez compris, est de faire de la répartition de charge a pas cher et en toute simplicité mais à la seule condition que les clients se connectant à cet environnement Lync soient en mesure de tirer profit des fonctions de DNSLB ce qui, encore une fois, n’est pas le cas des anciennes versions OCS. (Limitation présente également sur Exchange UM).

L’autre limitation que j’ai trouvée est l’impossibilité de faire une configuration en actif passif via cette technologie.

L’autre point de configuration que vous devez prendre en compte, est le fait que si vous voulez être supporté par les équipes technique de Microsoft, la répartition de charge des Edge Internes et Externes doit identique de part et d’autre des serveurs Edge. C’est-à-dire que si vous utilisez de la répartition de charge par équilibre de charge DNS coté Internet sur les serveurs Edge alors vous devez le faire également pour les cartes internes des Edges concernés.

Publication des Edge à travers des répartiteurs de charges Matériel

Dans le cas de l’utilisation de la répartition de charge les choses sont un peu plus compliquées…. car dans ce cas de figure, votre scénario de déploiement vous demandera de mettre en place 9 adresses IP publiques et de porter ces deux adresses IP directement sur des équipements que l’on aimerait voir …..un peu plus protégés.

Si vous regardez bien le schéma ci-dessous issu de la documentation Microsoft vous constaterez que les répartiteurs de charges mais aussi les cartes externes des serveurs Edge en place, portent directement les adresses IP publiques. Cette configuration si vous la présentez à votre RSSI préféré ne tardera surement pas de le faire réagir….. d’autant plus qu’il vous faudra annoncer dans un deuxième temps la liste des ports de communications à ouvrir ;-)

Pour information nous avons monté cette solution tout à fait fonctionnelle sur deux sites et nous avons pu observer grâce aux Firewall de périphérie que les clients Lync se connectaient aux HLB mais également directement vers les serveurs Edge via leurs connexions externes.


Intérêts de la publication des Edge à travers des répartiteurs de charges Matériel

L’intérêt de la publication des services Edge à travers des répartiteurs de charges matériel est à mon sens très limité, car consommateur d’adresses IP publiques, compliqué, et offrant un niveau de sécurité limité. Le seul intérêt est de fournir un seul point de connexion coté internet et permettant de facto une solution de répartition de charge pour les anciennes fédérations et les messageries publiques. Je vous laisse juge si le jeu en vaut la chandelle.

Cordialement
Laurent Teruin

 

 

 

Posted in Lync 2010 | Leave a Comment »

Lync 2013 Client : Forcer le téléchargement du carnet d’adresses (GalDownloadInitialDelay)

Posted by David ANDRE le décembre 18, 2012


Bonjour,

Nombre d’entre vous ont déjà du rencontrer le fameux message « Address book synchronizing. Result may be not current » lors d’une recherche de contact sous Lync 2010/2013. En effet, le carnet d’adresses peut parfois mettre jusqu’à 1 heure pour descendre sur le client.

Tout comme sous Lync 2010, il est possible de forcer son téléchargement sous Lync 2013 via la clé registre GalDownloadInitialDelay. Cependant, quelques changements sont à noter.

Cette clé registre se situe maintenant dans HKLM\Software\Policies\Microsoft\Office\15.0\Lync. Adieu donc au fameux conteneur Communicator !

Pour désactiver le délai de téléchargement, exécuter simplement : reg add HKLM\Software\Policies\Microsoft\Office\15.0\Lync /v GalDownloadInitialDelay /t REG_DWORD /d 0 /f

A noter aussi que le chemin de la GAL a aussi changé. Vous trouverez maintenant GalContacts.db sous : C:\Users\<Utilisateur>\AppData\Local\Microsoft\Office\15.0\Lync\<adresseSIP@domain>

Une fois la clé registre changée et le client Lync 2013 redémarré, vous devriez pouvoir effectuer des recherches sans attendre J.

Have Fun !
David ANDRE

Posted in 2- LYNC-2013, 5-Lync-2010, Lync 2010, Lync Client, Microsoft Lync | Leave a Comment »

La fin de Lync Public IM Connectivity (PIC) programmée ?

Posted by David ANDRE le décembre 17, 2012


Bonjour à tous,

Comme vous le savez sans doute, Lync 2010 propose une fédération avec plusieurs fournisseurs d’IM à savoir AOL, Yahoo! et Windows Live Messenger. Pour utiliser la fédération Yahoo!, il était nécessaire de se prémunir de la licence PIC USL (Lync Public IM Connectivity User Subscription Licence). Cette dernière n’est plus commercialisée depuis le 1er septembre 2012.

Microsoft vient donc d’annoncer la fin de la fédération avec les services Yahoo! Messenger. Le service sera définitivement clos vers Juin 2013. Il n’y a pas eu de communication concernant les services AOL/WLM pour le moment.

Cependant, Microsoft a aussi annoncé lors de la sortie de Lync 2013 une fédération avec les services Skype (racheté par Microsoft en 2011). Cette dernière, au même titre que WLM et AOL, ne devrait pas nécessiter de licence supplémentaire et donnant donc plus de perspectives avec ses 600 Millions d’utilisateurs !

Sources : http://blogs.technet.com/b/lync/archive/2012/11/26/lync-and-yahoo-federation-end-of-life.aspx

Pour plus d’informations sur la fédération PIC en générale, voici quelques liens utiles :
https://pic.lync.com/provision/Logon/FAQ.htm
http://technet.microsoft.com/en-us/library/ff945947(v=ocs.14).aspx

Have Fun !
David ANDRE

Posted in 2- LYNC-2013, 5-Lync-2010, Lync 2010, Microsoft Lync | Leave a Comment »

CU LYNC 2010 Décembre 2012

Posted by Teruin laurent le décembre 12, 2012


Microsoft vient de sortir une mise à jour cumulative pour le pack d’administration Lync 2010 pour System center Opération Manager 2007 R2 Afin de corriger l’erreur suivante : "

"Secure Reference Override Failure warnings after you install Monitoring Management Pack in System Center Operations Manager in a Lync Server 2010 environment"

Cette mise à jour s’applique aux versions suivantes :

  • Microsoft Lync Server 2010 Standard Edition
  • Microsoft Lync Server 2010 Enterprise Edition
  • Microsoft System Center Operations Manager 2007 R2

Elle est récupérable sur l’url Suivante : http://support.microsoft.com/kb/2742265

Cordialement

Laurent Teruin

Posted in Lync 2010 | 1 Comment »

LYNC 2013 : Prochaine disponibilité de la version 2013

Posted by Teruin laurent le octobre 12, 2012


A en croire Microsoft, Lync 2013 sera bientôt disponible en version RTM. C’est en tous les cas ce que présente un article sur un blog officiel précisant que depuis le 11 octobre 2012 la version de code est passée en RTM. (http://blogs.technet.com/b/lync/archive/2012/10/11/lync-2013-is-finished.aspx). LAaversion définitive est prévue pour le premier trimestre 2013.

Une bonne nouvelle pour ceux qui ont projeté un prochain déploiement

Cordialement

Laurent Teruin


 

Posted in Lync 2010 | Leave a Comment »

LYNC 2010 : Cumulative Update Octobre 2012

Posted by Teruin laurent le octobre 11, 2012


Microsoft vient de publier les nouveaux Cumulative Update d’Octobre 2012

Au programme

 Product

 Version

KB

Download

Lync 2010 (64bit client)

4.0.7577.4356

2737155

MS download

Lync 2010 (32bit client)

4.0.7577.4356

2737155

MS download

Lync 2010 Attendee (User Install)

4.0.7577.4356

2752157

MS download

Lync 2010 Attendee
(Admin Install)

4.0.7577.4356

2752160

MS download

Lync Server 2010

4.0.7577.205

2493736

MS download

 

Cordialement

Laurent Teruin
Lteruin@hotmail.com

Posted in Lync 2010 | Leave a Comment »

Lync Firewall Rules Viewer

Posted by David ANDRE le juillet 4, 2012


Bonjour à tous,

Aujourd’hui, l’équipe de NextHop (plus précisément Rui MaximoThomas Binder) vient de publier un outil vraiment intéressant : Lync Firewall Rules Viewer ! Cette application (pour Windows 7) vient vraiment compléter le fameux poster que nous connaissons tous : Lync Server 2010 Protocol WorkLoad.

En effet, Lync Server utilise de nombreux protocoles différents et il est parfois difficile de correctement paramétrer les différents firewalls lors de la mise en place d’une infrastructure Lync. L’avantage de cet outil réside surtout dans son exhaustivité. On pourra facilement sélectionner une source et directement visualiser les destinations possibles ainsi que la configuration associée.

Après avoir sélectionné une destination, un tableau récapitulatif des règles s’affiche, précisant les différents ports à configurer ainsi qu’un lien direct vers l’article TechNet concerné.

Voici quelques screenshots de l’application :

 

Pour le télécharger gratuitement c’est ici.

Sachez qu’une application Windows Phone 7 semblable avait été proposée sur le MarketPlace il y’a quelque temps déjà. Il s’agit de Lync Protocol&Ports.

Voilà de quoi faciliter un peu plus la configuration, toujours délicate, des firewalls.

Have Fun J

David ANDRE

Posted in 5-Lync-2010, 6 - Reverse-Proxy-Forefront, Lync 2010 | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 224 autres abonnés