Bonjour,

Aujourd'hui, jeudi 10 février 2011, se déroulera la session sur la migration OCS vers Lync aux TechDays, salle 242A.

Je co-animerai cette présentation avec Pascal Creusot, MVP Lync.

Stefan

Ca y est, j'ai reçu le mail qui m'indique que j'ai réussi l'exam et le lab pour être MCM Lync !

Aujourd'hui, c'est officiel, SQL Server 2008 R2 est supporté pour Lync Server 2010 ! Le groupe produit Lync a testé SQL Server 2008 R2 et n'a pas constaté de dysfonctionnement avec cette version, ce qui fait que les nouvelles installations de Lync pourront bénéficier de SQL Server 2008 R2.

La publication de l'équipe produit est disponible ici : http://blogs.technet.com/b/nexthop/archive/2011/04/20/lync-server-2010-support-for-sql-2008-r2.aspx

Note : je publie à nouveau de billet suite à une suppression de celui-ci.

Lors de fédération OCS entre sociétés, on trouve de temps à autres le besoin d’avoir la liste de tous les contacts de la société fédérée. Cela se produit par exemple lorsqu’une société et sa filiales, qui ont deux infrastructures séparées, sont fédérées. Alors qu’une simple synchronisation des comptes utilisateurs en contacts via IIFP/MIIS/ILM ou autre permet de peupler de manière simple la GAL Exchange, il s’avère que le peuplement du carnet d’adresses Office Communicator peut être plus délicat.

En effet, une solution consiste à synchroniser l’attribut msRTCSIP-PrimaryUserAddress. Or, dans ce cas, il apparaîtra un problème : l’ouverture de l’onglet Communications dans les propriétés du contact dans Active Directory affichera une erreur, puisque du point de vue OCS, l’état du contact ne sera pas cohérent. Cela tout simplement parce que le contact aura l’attribut msRTCSIP-PrimaryUserAddress de configuré mais pas les autres attributs utilisés par OCS.

Pour éviter ce problème mais néanmoins avoir la liste des utilisateurs de la société fédérée dans le carnet d’adresses OCS, la solution est de synchroniser le contenu de msRTCSIP-PrimaryUserAddress (en source) dans un attribut tel que extensionAttribute15 (en cible), et de configurer ensuite OCS pour qu’il prenne en compte le contenu de cet attribut. De cette manière, lors de la synchronisation du carnet d’adresses, les contacts dans Active Directory seront peuplés dans le carnet d’adresses OCS. Un utilisateur OC pourra donc facilement rechercher un contact depuis la zone de recherche dans OC et communiquer avec lui.

Pour modifier la configuration du carnet d’adresses, il faut modifier une table SQL dans l’instance où sont hébergées les bases de données du pool OCS.

La procédure est la suivante :

1. Se connecter à l’instance SQL qui contient les bases de données du pool
2. Selectionner la base “rtc” comme base active : USE RTC;
3. Ajouter une ligne à la table indiquant de prendre en compte le contenu de l’attribut extensionAttribute15: INSERT INTO AbAttribute VALUES (254, ’extensionAttribute15’, 0x08020800);

Ensuite, lancer une génération complète du User Replicator à partir d’un Front End, en exécutant la commande ABServer –RegenUR. L’outil ABServer se trouve par défaut dans C:\Program Files\Microsoft Office Communications Server 2007 R2\Server\Core.

Dans le cas d’un serveur OCS Standard Edition, il est possible d’utiliser l’outil en ligne de commandes OSQL pour se connecter à la base de données.

Si pour certains tests audio/vidéo vous n’avez pas la possibilité de disposer des fonctions audio/vidéo, il est possible d’utiliser ces 2 outils gratuits:

• Audio : Virtual Audio Cable (http://software.muzychenko.net/eng/vac.htm). Prendre la version d’évaluation, qui n’est pas limitée dans le temps mais qui d’après les notes du site Web ajoute une voix indiquant que c’est une version d’évaluation périodiquement.
• Vidéo : Manycam (http://manycam.com). Cela permet de disposer d’un driver vidéo dans une machine, donc bien pratique pour simuler de la vidéo dans une machine virtuelle par exemple.

L’objectif avec ces outils n’est pas de tester tous les scénarios audio/vidéo, mais au minimum de pouvoir lancer un appel audio ou audio/vidéo depuis Lync, même si le son ne sera pas entendu.

RGS Agent Live est un outil du Resource Kit de Lync Server 2010. Il permet de lister les Response Groups et de voir le nombre d’appels dans la file d’attente.

Pour faire fonctionner cet outil, il faut respecter les conditions suivantes:

• Avoir Lync d’installé sur le poste de travail et avec sa session Lync d’ouverte
• Etre membre du ou des Response Groups à superviser
• Exécuter l’exécutable RgsAgentLive.exe depuis la machine locale, et non pas depuis un partage réseau

Dans la configuration de l’outil, il est demandé de renseigner l’adresse de l’hôte : il doit s’agir de l’URL Web Services pour le pool, à savoir :

• Dans le cas d’un pool Enterprise Edition, spécifier l’URL Web Services du pool, cela étant soit l’interne ou l’externe en fonction du lieu où se trouve le poste de travail
• Dans le cas d’un pool Standard Edition, spéficier l’URL Web Services du serveur, cela étant soit le FQDN du serveur Lync soit l’URL externe pour les Web Services associée à ce serveur

Si RGS Agent Live est exécuté depuis une machine 32-bit, on observe que l’application crashe au démarrage. L’explication est toute simple : la DLL CommunicatorAPI.dll a été compilée pour un environnement 64-bit, ce qui fait que lorsque RGSAgentLive.exe tente de la charger, ça ne fonctionne pas.

Il faut donc utiliser RGS Agent Live depuis une machine 64-bit.

Lors de l’installation de Lync Server 2010, plusieurs groupes de sécurité CS* sont créés dans Active Directory. Ils permettent par défaut de segmenter les rôles des administrateurs Lync. De plus, il est possible de créer des rôles personnalisés : cela permet de modifier le périmètre d’application du rôle mais ne permet pas d’ajouter, modifier ou supprimer des commandes PowerShell. Plus d’informations sur la personnalisation sont disponibles sur http://technet.microsoft.com/en-us/library/gg425917.aspx.

Lors de la validation du fonctionnement de RBAC, il se peut que le résultat ne soit pas celui attendu : autrement dit, l’utilisateur aura peut-être des erreurs de droits suite à l’exécution de certaines commandes. L’explication est la suivante : RBAC ne fonctionne que lorsqu’on réalise une session Remote PowerShell. RBAC est appliqué dans Lync Server Control Panel mais pas lorsqu’on exécute Lync Server Management Shell. Ce dernier exécute une session PowerShell classique.

Pour pouvoir réaliser des scripts et utiliser Remote PowerShell, il convient d’ouvrir une session en utilisant les commandes New-PSSession et Import-PSSession. Le site suivant propose un script permettant de faire la connexion simplement : http://blogs.technet.com/b/csps/archive/2010/08/03/scriptremotedesktopicon.aspx

Dans certains cas, une erreur DCOM peut apparaitre lors du déplacement d’utilisateurs depuis OCS vers Lync Server 2010, principalement lorsque la répartition de charge sur le pool Front End Lync n’est pas faite en utilisant du DNS Load Balancing.

Cela signifie que le Load Balancer pour le pool Lync Server 2010 est configuré pour gérer les ports 5061, 135… et pas seulement les ports HTTP/HTTPS (80, 443, 8080 et 4443).

Si le problème survient, il faut suivre la procédure suivante :

• Lancer Regedit.exe sur les Front End du pool Lync
• Aller jusqu’à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
• Editer le contenu de BackConnectionHostNames
• Ajouter dans la liste la VIP du Pool Front End Lync (le champ BackConnectionHostName doit déjà contenir le nom du pool Lync et le nom des Web Services interne du pool s’il est différent du nom du pool lui-même)
• Redémarrer les serveurs Front End du pool Lync
• Déplacer les utilisateurs

Lync Server 2010 propose des commandes PowerShell pour créer les CSR pour les certificats. Cependant, ces commandes ne peuvent être utilisées que créer des CSR pour les serveurs ayant des rôles Lync.

Pour créer un CSR pour le reverse proxy, la méthode suivante peut être utilisée :

1. Renseigner les informations du certificat dans un fichier INF, y compris les entrées SAN
2. Utiliser CertReq pour créer le CSR
3. Utiliser CertReq pour importer le certificat émis

L’exemple ci-dessous donne le contenu du fichier Cert.inf :

[NewRequest]
Subject = "CN=join.contoso.com,OU=IT,O=Contoso,L=Paris,S=IDF,C=FR"
Exportable = TRUE
KeySpec = 1
MachineKeySet = True
KeyLength = 2048

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=join.contoso.com&"
_continue_ = "dns=dialin.contoso.com&"
_continue_ = "dns=meet.contoso.com&"
_continue_ = "dns=lyncpoolws.contoso.com&"

[RequestAttributes]
CertificateTemplate =WebServer

Les éléments à modifier sont :

Pour créer le CSR, il faut exécuter la commande suivante sur une machine Windows Server 2008, Windows Server 2008 R2, Windows Vista ou Windows 7 :

CertReq -New Cert.inf Cert.txt

Le fichier Cert.txt est le résultat de la commande, c’est-à-dire le CSR à fournir à l’autorité de certification pour obtenir le certificat.

Une fois le certificat généré par l’autorité de certification (fichier ayant le nom Cert.cer par exemple), il faut lance la commande suivante sur la même machine qui a servi à créer le CSR :

CertReq -Accept Cert.cer

Le certificat avec sa clé privée apparaitra ensuite dans le magasin personnel du conteneur de la machine et pourra être exporté en PFX si besoin.

La méthode est présentée ici pour le reverse proxy pour Lync Server 2010 mais peut être utilisée pour créer des CSR pour d’autres usages.

Dans le cas par exemple d’une migration OCS 2007 R2 vers Lync, il faudra à la fin désactiver les services sur les Front End OCS. Cela se fait tout simplement avec la console d’administration OCS où il faut désactiver les composants un à un sur les Front End.

Il se peut que la désactivation de certains composants échoue, avec le message suivant : “A call to a subtask failed.: The call to subtask AppServer.GetAppState failed. Pool is not ready.”

La cause de ce problème peut être liée au fait que le Conference Directory du pool a déjà été déplacé. Pour pouvoir correctement désactiver les composants, il faut donc re-déplacer le Conference Directory pour qu’il soit à nouveau sur le pool OCS. Ensuite, il faut désactivers tous les composants sauf le composant Front End.

Une fois tous les composants désactivés à l’exception du composant Front End, il faut déplacer le Conference Directory vers le pool Lync et ensuite désactiver le composant Front End des serveurs OCS.

Lors de la migration de comptes depuis OCS vers Lync via le Control Panel, il peut y avoir des comptes qui rencontres des erreurs. Dans ce cas précis, le Lync Server Control Panel reporte le message “Unable to update destination pool”, ce qui signifie que le serveur Lync n’a pas les permissions nécessaires pour mettre à jour les propriétés AD de l’utilisateur qui doit être déplacé.

Ce problème apparait généralement sur des comptes qui n’héritent pas des permission appliquées par Lync au moment des étapes Forest Prep et Domain prep. Cependant, on distingue 2 cas :

1. L’héritage des permissions sur l’objet utilisateur a été désactivé, et il s’agit d’un utilisateur normal
2. L’héritage des permissions sur l’objet utilisateur est désactivé car il s’agit d’un compte qui est ou qui a été membre d’un groupe d’administrateurs (Domain Admins, Print Operators…)

Dans le premier cas, il suffit d’éditer les paramètres de sécurité de l’objet utilisateur pour réappliquer l’héritage des permissions.

Dans le second cas, l’héritage des permissions est désactivé automatiquement et périodiquement par Active Directory parce que le compte est ou a été membre d’un groupe d’administrateurs. Cela est en rapport avec le mécanisme AdminSDHolder (pour plus d’informations, voir http://technet.microsoft.com/en-us/query/ee361593).

Pour éviter tout problème pour ces comptes utilisateurs, la méthode consiste à autoriser certains groupes de sécurité Lync à lire ou écrire des propriétés particulières directement sur l’objet AdminSDHolder : en effet, le fait d’appliquer des permissions sur cet objet fera qu’Active Directory les “répliquera” sur les objets utilisateurs sur lesquels il supprime l’héritage.

Il est possible d’utiliser DSACLS pour appliquer les bonnes permissions sur l’objet AdminSDHolder. Il faut indiquer le chemin LDAP de l’objet AdminSDHolder, par exemple CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com) pour appliquer les permissions suivantes :

Voici les commandes à passer :

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalServerReadOnlyGroup:RCLCRPLO

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserReadOnlyGroup:RCLCRPLO

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCHSUniversalServices:CA;"Replicating Directory Changes"

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G "Authenticated Users":RP;RTCUserSearchPropertySet

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserAdmins:WP;RTCUserProvisioningPropertySet

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserAdmins:WP;msExchUCVoiceMailSettings

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserAdmins:WP;RTCUserSearchPropertySet

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserAdmins:WP;RTCPropertySet

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserAdmins:WP;proxyAddresses

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserReadOnlyGroup:RP;RTCUserProvisioningPropertySet

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserReadOnlyGroup:RP;"Personal Information"

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserReadOnlyGroup:RP;RTCUserSearchPropertySet

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserReadOnlyGroup:RP;RTCPropertySet

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserReadOnlyGroup:RP;"Public Information"

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserReadOnlyGroup:RP;"General Information"

dsacls CN=AdminSDHolder,CN=System,DC=corp,DC=contoso,DC=com /I:P /G CONTOSO\RTCUniversalUserReadOnlyGroup:RP;"Account Restrictions"

Attention : ces informations et commandes sont données à titre d’information. Il est obligatoire de conserver une copie des droits en place sur l’objet AdminSDHolder avant l’exécution de ces commandes pour être en mesure de rétablir les permissions d’origine en cas de problème.

La mise à jour Cumulative Update 4 de Lync Server apporte une fonctionnalité indiquée sur http://support.microsoft.com/kb/2621840 : An update is available to enable the control of the file transfer through the Access Edge service in a Lync Server 2010 environment.

La méthode pour bloquer le transfert de fichiers est la suivante :

• Mettre à jour l’environnement Lync Server 2010 avec le CU4 – pas seulement sur les serveurs Edge
• Utiliser la commande Lync PowerShell suivante : Set-CsImFilterConfiguration -Identity <Edge> -BlockFileExtension $True
• Avec <Edge> valant le paramètre Identity retourné par Get-CsService -EdgeServer
  

Bien que ce ne soit pas mon habitude de poster pour mentionner la sortie d'une mise à jour, celle-ci est un peu particulière car elle apporte la possibilité de ne plus afficher l'information appelée LastActive dans le client Lync 2010. Cette information est en fait la durée affichée à côté de l'état de présence des utilisateurs dans Lync lorsqu'ils sont connectés et inactifs ou alors hors ligne. On voit généralement quelque chose comme "Hors ligne - 1 heure".

En appliquant la dernière mise à jour de Lync Server 2010 (http://support.microsoft.com/kb/2698370/en-us) et en appliquant la méthode indiquée dans la KB http://support.microsoft.com/kb/2684128/en-us, il est possible de dire aux Front End Lync de ne pas propager l'information d'inactivité, ce qui a pour effet de ne plus l'afficher dans le client Lync.

Pour le moment, cette mise à jour de Lync Server n'est disponible qu'en faisant une demande au support (via l'article de la KB http://support.microsoft.com/kb/2698370/en-us).