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).
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 :
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 :
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.
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.
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 :
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 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 :
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
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.
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:
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 :
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:
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.
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 :
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.
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
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 !
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
Dans beaucoup de déploiements ou de maquettes, on peut être confronté à l’erreur Office Communicator indiquant qu’il est impossible de télécharger le carnet d’adresses. Je vais essayer ici de donner quelques pistes assez simple pour trouver l’origine du problème.
Voici la liste des points que je vérifie en général :
Ces étapes sont des vérifications simples à réaliser et permettent de résoudre normalement 95 % des problèmes liés au téléchargement du carnet d’adresses.
Il faut aussi savoir que depuis quelques mois, le comportement d’Office Communicator a changé : il ne télécharge plus le carnet d’adresse dès son démarrage mais dans un intervalle aléatoire compris entre 0 et 60 minutes. Ce comportement peut être modifié par clés de registres. Pour plus d’informations : http://support.microsoft.com/kb/972403/en-us
Lorsqu’OCS est déployé avec les fonctionnalités de téléphonie, il se peut que le numéro de l’organisateur de la conférence ne soit pas pas présenté aux personnes appelées sur leur téléphone portable ou fixe connecté au PSTN.
Lorsqu’un utilisateur Office Communicator initie une conférence audio depuis OC et qu’il invite des personnes extérieures, le Mediation Server va servir à faire la passerelle entre le monde OCS et le réseau externe. Dans le cas d’une conférence, le Mediation Server recevra comme information que l’appelant est sip:Utilisateur.Appelant@contoso.com et non pas le numéro de l’appelant, par exemple +33122334455.
Cela peut avoir un effet non souhaité : la passerelle derrière le Mediation Server ne comprends pas le contenu du champ et n’effectue pas l’appel
Il peut y avoir plusieurs approches pour résoudre ce problème :
Dans Live Meeting, il est possible de partage le bureau, une application, d’utiliser un tableau blanc, partager une page Web…
Il faut savoir que le partage de page Web a quelques limitations. En effet, une page Web partagée dans Live Meeting est en réalité affichée sur tous les postes qui ont la console Live Meeting, et dans certains cas il se peut que certains liens ne fonctionnent pas. Par exemple, l’utilisateur qui partage la page Web clique sur un lien pour aller sur une autre page, va voir la nouvelle page mais il se peut que les autres participants restent sur la page initiale.
Ce problème se produit uniquement dans le cas où les liens ne sont pas de simples liens “A HREF” : si du JavaScript s’occupe de gérer la navigation, le lien ne fonctionnera pas.
Cela est lié au fait que le partage de page Web dans Live Meeting restreint l’utilisation du JavaScript : le code n’est pas exécuté sur les postes de travail de tous les participants, pour éviter des problèmes de sécurité. Par exemple, si l’organisateur prépare une page Web avec un script JavaScript réalisant une action mal intentionnée et la partage, le script ne sera pas exécuté sur les postes.
Conséquence de cela, pour partager une page Web de manière complète avec et être sûr du comportement, le plus simple est d’utiliser la fonctionnalité de Partage d’Application dans Live Meeting, en choisissant de partager le navigateur Web.
Après l’installation de l’Add-In Outlook permettant de planifier des réunions Communicator et Live Meeting, il y a un cas où Outlook peut planter en affichant les messages tels que :
Ce problème peut survenir si les outils d’administration Exchange Server 2003 sont installés sur le poste de travail. La solution est très simple : il suffit de désinstaller les outils d’administration Exchange Server 2003.
Il est possible que l’affichage des rapports du Monitoring Server OCS 2007 R2 se passe mal et qu’une erreur apparaisse à la place, du style :
En se connectant depuis le serveur SQL et en accédant à l’URL de Reporting Services, le message est intéressant:
La dernière ligne donne la solution : le problème vient du fait que le compte de service utilisé pour accéder à la base de données SQL n’ait pas les droits de se connecter localement au serveur SQL. Ce compte de service est normalement RTCReportPack.
Pour résoudre le problème, il suffit de se connecter sur le serveur SQL où Reporting Services est déployé, ouvrir la console Local Security Policy, et ajouter le droit “Allow log on localy” pour le compte RTCReportPack.
Une erreur classique aussi est d’avoir oublié de positionner l’option “Password Never Expires” sur le compte de service RTCReportPack, cela ayant pour conséquence d’avoir l’accès au CDR ou QoE ne fonctionnant plus quelques semaines après l’installation.
Lorsqu’on installe le Deployment Validation Tool d’OCS 2007 (disponible sur http://www.microsoft.com/downloads/details.aspx?FamilyID=3596a10d-65cc-4cca-8470-3f23d5ea55b2&DisplayLang=en) ou OCS 2007 R2 (disponible dans le Resource Kit sur http://www.microsoft.com/downloads/details.aspx?FamilyID=b9bf4f71-fb0b-4de9-962f-c56b70a8aecd&DisplayLang=en), il se peut que l’Auto Answering Agent ne fonctionne pas : lorsqu’on l’appelle, il est impossible d’entendre “Rita” parler.
Cela peut se produire si le compte utilisé pour faire fonctionner l’AAA a un profil qui n’a pas les Regional Settings au format en-US. Si tel est le cas, il suffit d’ouvrir une session sur la machine où est installée l’AAA avec le compte associé, et modifier les Regional Settings pour mettre English (United States). Il ne reste plus qu’à redémarrer le service associé au DVT et tout devrait fonctionner.
Cela est aussi valable pour les Agents et l’Organizer.
Après une installation de CWA 2007 R2 derrière un Load Balancer, une post-configuration doit être faite. En résumé, il suffit d’autoriser les accès anonymes à la page /cwa/AuthMainCommandHandler.ashx.
Dans les détails, voici la procédure :
Ouvrir IIS sur les serveur CWA, et aller dans Sites, Communicator Web Access, cwa :
Avec la souris, cliquer à droite de la barre d’adresses pour voir afficher tous les fichiers du répertoire cwa et sélectionnner AuthMainCommandHandler.ashx (faire Entrée pour le sélectionner) :
Configurer les paramètres d’authentification pour avoir Anonymous Authentication = Enabled.
La connexion à CWA derrière un répartiteur de charge devrait être fonctionnelle à présent.
L’infrastructure BlackBerry dispose d’un composant permettent d’avoir la présence OCS sur les téléphones du même nom par une interconnexion avec un serveur CWA. Si cela fonctionne bien dans un environnement OCS 2007, ce n’est pas la même chose avec OCS 2007 R2. En effet, les API Ajax de CWA 2007 n’ont pas été reconduites sur CWA 2007 R2. Il est donc, de base, impossible de configurer une intégration BlackBerry dans un environnement OCS 2007 R2.
Les solutions supportées par Microsoft sont les suivantes, en fonction de différents cas de départ:
Après une installation sur Windows Server 2008, il se peut que les services OCS 2007 R2 ne démarrent pas automatiquement et ralentissent donc le processus de démarrage du serveur.
Dans certains cas, il peut être nécessaire de configurer les services OCS pour qu’ils soient dépendants du service WMI Performance Adapter (WmiApSrv).
La résolution passe par deux étapes :
Pour rappel, la modifications des dépendances de fait dans la base de registres, dans KHLM\SYSTEM\CurrentControlSet\Services\<Service>, où il faut ajouter une ligne contenant WmiApSrv dans le paramètre DependOnService
Ces modifications permettront aux services OCS de démarrer sans problème à chaque démarrage.
Après une installation de Communicator Web Access 2007 R2, il se peut que lors de la connexion, un message du type "Your computer clock is not set correctly".
Ce comportement est lié à Kerberos et se produit si l'URL utilisée pour accéder à CWA 2007 R2 ne correspond pas au nom du serveur CWA.
Pour résoudre ce problème, il suffit d'ajouter un SPN au compte de service CWA pour le service http. Prenons un exemple :
Dans ce cas, il faut ajouter le SPN http/im.contoso.com au compte de service CONTOSO\CWAService. Pour cela, il faut exécuter la commande SetSpn -A http/im.contoso.com CONTOSO\CWAService.
Il faut faire de même pour les URL as.im.contoso.com et download.im.contoso.com, donc exécuter les deux commandes suivantes:
Pour information, les URL as.<URL CWA> et download.<URL CWA> permettent de faire fonctionner le Desktop Sharing dans CWA.
Le temps que la réplication Active Directory soit complète et après un redémarrage de IIS sur le serveur CWA, la connexion devrait être opérationnelle.
Pour faire suite à mon billet sur la publication des Web Components pour OCS 2007, voici la version pour OCS 2007 R2.
La règle de publication des Web Components sur ISA Server doit autoriser les chemins suivants :
- /Abs/Ext/*
- /AutoUpdate/Ext/*
- /Conf/Ext/*
- /DeviceUpdateFiles_Ext/*
- /Etc/*
- /GroupExpansion/Ext/*
- /PhoneConferencing/Ext/*
- /RequestHandlerExt/*
- /Rgs/Clients/*
En fonction des fonctionnalités mises en places, il est possible de restreindre l'accès (notamment ne pas ouvrir /Rgs/Clients/*) mais cela dépend après des possibilités offertes aux utilisateurs.