Lync Web Scheduler est une fonctionnalité plutôt méconnue de Lync qui néanmoins apporte de la valeur à votre infrastructure de conférence Web, puisqu'elle vous permet de planifier des réunions Lync directement depuis une interface Web. Dans cet article nous allons voir comment valoriser cette fonctionnalité en créant une SIMPLE URL spécifique pour cet usage à l'image du meet ou dialin.

Un peu d'histoire ...

Lync Web Scheduler est apparu en 2011 comme un composant additionnel à Lync Server 2010. Peu connu à l'époque il offrait déjà les fonctions suivantes :

• planifier une réunion ou un appel de conférence en ligne

• envoyer des invitations à des participants à des réunions

• personnaliser les rôles et autorisations d’une réunion en fonction des participants et du type de réunion

• rejoindre une réunion à partir de Web Scheduler

• afficher ou modifier leurs réunions existantes

• supprimer ou annuler une réunion.

Aujourd'hui

Le Web Scheduler est aujourd'hui inclus dans Lync Server 2013 comme une fonctionnalité à part entière. il offre les mêmes possibilités que son prédécesseur. Pour y accéder rien de plus simple, il suffit d'ajouter à l'adresse des webservices du pool l'intitulé "/scheduler" ainsi on obtient https://<LyncWebServicesURL>/Scheduler.

Vous obtiendrez alors la mire d'authentification du service Web Scheduler

Mire d'identification Web Scheduler

Une fois identifié le portail de réservation ressemble à ça :

interface de création d'une conférence

Vous pouvez également gérer vos réunions planifiées à partir de l'interface

interface de gestion des conférences planifiées

Reste qu'il est difficile de promouvoir une telle URL auprès de vos chers utilisateurs. C'est pourquoi, il existe une technique pour rendre cette URL plus simple du type https://planif.contoso.com

Pour se faire lancer depuis votre serveur Lync le Lync Server Management Shell

Une fois la modification faite et propagée à l'ensemble des frontaux, il sera nécessaire de relancer le bootstrapper sur ceux-ci.

Une fois la modification réalisée il reste quelques points à contrôler :

- Modifier les certificats pour que l'adresse spécifiée apparaisse dans les champs SAN (Dans l'exemple  https://planif.contoso.com)

- appliquer les nouveaux certificats sur tous les éléments nécessaires (Frontaux , Reverse Proxy, Director)

- Ajouter les règles de publication du reverse proxy pour cette nouvelle URL

- Ajouter les enregistrements DNS adéquats pour que le l'entrée planif.contoso.com pointe sur la bonne destination (Reverse Proxy, Front-End, Director selon les cas)

- Ajouter les exceptions sur le proxy de l'entreprise

Il ne vous reste plus qu'à communiquer à vos utilisateurs cette nouvelle adresse !

Et demain ? 

Avec Exchange 2013, demain c'est aujourd'hui :) En effet, lorsque l'intégration Lync Server 2013 et Exchange Server 2013 CU1 (ou supérieur) a été réalisée avec succès vous voyez apparaître lorsque vous créez une nouvelle réunion l'icône "online meeting"

Online meeting dans l'OWA Exchange 2013 CU1

Pour plus d'information à ce sujet je vous conseille l'excellent article de Jens Trier Rasmussen à ce sujet en attendant un article français sur notre Blog :)

Thomas BIDAULT, Consultant Universal Communication, Microsoft Consulting Service France  Après plusieurs années passées chez un partenaire, j'ais rejoins Microsoft Consulting Services en septembre 2011. J’interviens en mission de conseil auprès de multiples clients sur des projets de communication Universelle.

Passons en revue les différentes méthodes pour passer des commandes PowerShell à un serveur distant...

Méthode 1 : Sans l'environnement Exchange

Pour envoyer rapidement une commande sur un serveur distant, la méthode "Invoke-Command" est simple et rapide à utiliser :

1. Construire la commande dans un environnement PowerShell, elle sera directement exécutée sur le serveur distant spécifié sous l'identité de l'utilisateur qui l'a lancée :

Invoke-Command -ComputerName DISTANT_SERVER -ScriptBlock {COMMAND_TO_EXECUTE_REMOTELY}

2. Pour aller plus loin et envoyer des variables en paramètre de la commande à injecter, utiliser "ArgumentList" :

Invoke-command -ComputerName DISTANT_SERVER -ScriptBlock {COMMAND_TO_EXECUTE_REMOTELY -Param1 $args[0] -Param2 $args[1]} -ArgumentList $Var1,$Var2

Dans ce cas, une association est créée entre la liste des arguments récupérés dans "ArgumentList" puis transmis dans le "ScriptBlock" selon leur position dans la liste (1,2,3,4, …) :

"$Var1" correspond ici l'argument numéro 0 nommé "$Args[0]"

"$Var2" correspond ici l'argument numéro 1 nommé "$Args[1]"

Méthode 2 : Avec l'environnement Exchange

La méthode suivante est la plus connue :

1. Enregistrer une paire de Login/Password chiffré dans une variable :

$Creds = Get-Credential

2. Inscrire dans une variable les paramètres d'une session PowerShell contenant ntoamment le FQDN du serveur distant et l'identité à utiliser :

$session = New-PSSession -ConfigurationName Microsoft.Exchange –ConnectionUri http://EXCHANGE_SERVER_FQDN/powershell -Credential $Creds

3. Enfin, importer la session distante contenue dans la variable précédente :

Import-PSSession $session

4. Vue d'ensemble :

Méthode 3 : Avec l'environnement Exchange

Pour initialiser un environnement Exchange PowerShell distant rapidement, la CmdLet "CreateOrGetExchangeSession" est elle moins connue. A noter toutefois que cette dernière vient avec l'environnement Exchange PowerShell et qui devient donc un prérequis indispensable localement. Vue détaillée...

1. Lancer une console Exchange PowerShell locale :

2. Construire une session distante :

3. Construire la commande à envoyer et l'injecter dans la session : 

Invoke-command -ScriptBlock {COMMAND_TO_EXECUTE_REMOTELY} -Session $Session

 Dans ce dernier exemple, il est aussi possible de passer des paramètres de la même manière qu'expliqué dans la méthode 1.

Méthode 3 bis : Pour aller plus loin avec l'environnement Exchange

Sur la même base que la méthode 3, essayons d'aller encore plus loin  ...

1. Lancer une console Exchange PowerShell locale

2. Construire une session distante :

3. Injecter dans la session un script complet : 

Invoke-command -ScriptBlock { Param($Param_1,$Param_2,$Param_3) Function Foo ($Param_Func_1,$Param_Func_2)    {     Write-host "param 1 is {0}" –f $Param_Func_1    }          Foo –Param_Func_1 $Param_1 }      -ArgumentList $Var_1,$Var_2       -Session $Session

Dans cet exemple, 3 variables de l'environnement local sont transmises dans la session distante : "$Var_1", "$Var_2" et "$Var_3".

Une correspondance directe est faite avec les "Param" transmis à l'intérieur du "ScriptBlock" et donc avec : "$Param_1", "$Param_2" et "$Param_3".

Une fonction "Foo" est transmise dans la session distante, cette dernière s'appuie sur des 2 paramètres "$Param_Func_1" et "$Param_Func_2".

Enfin, la fonction "Foo" est appelée à distance et le paramètre "$Param_1" lui est transmis. Ce paramètre provient donc lui même de la session locale transmis via la variable "$Var_1".

Si vous avez déployé le Service Pack 1 de Exchange 2013 vous avez peut-être rencontré des soucis en voulant changer de Witness Server ou de Witness Directory.

Unable to change the quorum for database availability group DAGNAME. The network path for witness server '\\server.fqdn.ad.domain\dagname.fqdn.ad.domain was not found. This may be due to firewall settings.

Vous avez vérifié plusieurs fois les prérequis du Witness Server qui sont détaillés ICI mais malgré tout, rien ne fonctionne ! Rappel des prérequis principaux :

• Ne peux pas être un membre du DAG
• Doit être dans la même foret AD que le DAG
• Doit être positionné sur un serveur Windows 2003 ou supérieur
• Si le firewall est activé, configurer une exception pour le "partage de fichiers et d'imprimantes"
• Si la machine n'est pas un serveur Exchange, ajouter le groupe de sécurité "Exchange Trusted Subsystem" dans le groupe des administrateurs locaux.

Dans ce cas il est fort probable que vous soyez dans un scénario de Disjoint Namespaces, c'est à dire que le nom NetBios de votre domaine AD ne correspond pas au nom court de votre domaine.

Exemple d'un FQDN de domaine :"DOMAINE.CONTOSO.COM"
et d'un nom NetBios associé mais différent : "FRANCE"

Plusieurs cas de Disjoint Namespaces sont supportés par Exchange 2013 et sont détaillés ICI. 

Dans mon lab, en exécutant la même CmdLet depuis un autre serveur Exchange CU3 dans l'Organisation, le changement de witness fonctionne, même si tous les membres du DAG en question sont en SP1.

Des nouveautés sont apparues avec le Service Pack 1 de Exchange 2013 au niveau de la couche Cluster. Il est probable que ces nouveautés induisent des changements dans la CmdLet du DAG. Il est maintenant possible, avec l'aide de Windows 2012 R2, de ne plus créer de CNO - Cluster Name Object dans l'AD. Cette fonctionnalité est appelée Cluster AAP pour Administrative Access Point qui est très bien expliquée par Scott Schnoll sur son blog, dans CET ARTICLE.

Bonjour,

J'ai dû faire face récemment à un problème récurrent (environ tous les 5 jours) dans une architecture spécifique. Si le Front-End d'un pool en Windows server 2012 ou 2012R2 est Active Master pour le rôle Central Management Store et que le filestore du pool auquel il appartient est sur un espace DFS on remarque qu'au bout d'une durée d'environ 5 jours ce dernier ne réplique plus la configuration. De plus, lorsque l'on se connecte sur le Front-End l'ouverture de  session reste bloqué sur le chargement du profile. Le seul moyen de remédier à la situation est de redémarrer électriquement le serveur impacté.

Identifier le serveur Active Master pour le CMS

get-CsManagementStoreReplicationStatus -CentralManagementStoreStatus

Quand le problème survient la réplication du CMS est en échec. Pour vérifier l'état de la réplication il suffit de lancer la commande suivante

Si vous êtes dans ce cas, pas de panique il s'agit d'un problème identifié. Ce problème est dû a un bogue du client DFS sur Windows Server 2012 ou 2012 R2. Afin de résoudre ce problème il est nécessaire de passer le correctif adapté :

         - update rollup Mars 2014 disponible à cette adresse http://support.microsoft.com/kb/2928678 (Attention: Cette mise à jour disponible sur Windows Update est catégorisée comme optionnelle)

         - Si vous désirez plus d'information sur le problème de client DFS rencontré allez à cette adresse http://support.microsoft.com/kb/2925981

Notez que l'application de cette mise à jour requiert un redémarrage.

Je tiens tout particulièrement à remercier Léo du support sans qui le problème n'aurait pas été résolu.

Thomas BIDAULT, Consultant Universal Communication, Microsoft Consulting Service France  Après plusieurs années passées chez un partenaire, j'ais rejoins Microsoft consulting service en septembre 2011. J’interviens en mission de conseil auprès de multiples clients sur des projets de communication Unifiée.

Vous aurez peut-être remarqué en jouant avec les groupes de sécurité Active Directory, en ajoutant des ACLs sur des OUs ou autre que des permissions sautent toutes seules sur des comptes …

Je m’apprête à parler ici de l’objet AdminSDHolder dans Active Directory

Cas de figure simple
Dans votre infrastructure, vous disposez d’une hot-line dédiée à la gestion des comptes AD verrouillés, des mots de passe oubliés ou expirés etc …
Les comptes admins de base en charge de cette tâche peuvent, par exemple, avoir été regroupés dans un groupe de sécurité, lui-même positionné sur une ou plusieurs OUs.
Ce groupe de sécurité peut, par exemple, disposer de droits basiques (mot de passe, compte, …)  sur l’ensemble des comptes utilisateurs contenu dans l’OU.
Oui mais voilà, dans cette OU, vous avez de nombreux comptes utilisateurs standard mais aussi les comptes de quelques administrateurs avancés voire administrateurs du domaine.
Il est ainsi facile pour un hot-liner de changer le mot de passe de ce fameux compte admin du domaine et de faire ce que bon lui semble….  

L’objet AdminSDHolder est là pour contrôler ce type de phénomène pas forcement prévu et qui peut potentiellement créer une faille de sécurité.

Concrètement de quoi s’agit’il ?
Cet objet est stocké dans la partition Système d’Active Directory et dispose d’une ACL stricte :

Il se manifeste par un processus d’arrière plan qui tourne par défaut toutes les heures sur le DC qui héberge le rôle “PDC Emulator”. Ce processus est en charge de comparer l’ACL de l’objet AdminDSHolder avec celle de tout les comptes appartenant à des “groupes protégés”.
Si l’ACL est différente, elle est écrasée et remplacée par celle de l’objet AdminDSHolder.

Il est important de noter que cette ACL est très restrictive et qu’elle a pour effet secondaire de désactiver l’option d’héritage d’ACL qui proviendrait d’un niveau supérieur.
C’est de cette manière qu’il est possible d’observer que des permissions “sautent” périodiquement sur certains comptes.

Quels sont ces “groupes protégés” ?
Cette liste était composée de 4 groupes en Windows 2000 Server RTM. Elle a peu à peu évoluée jusqu’à en contenir 13 dans Windows 2008 R2 :

Quelle est cette ACL “restrictive” ?
Cette ACL est différente de celle appliquée au domaine.

On note que l’objectif de ce processus est de sécuriser des objets, il est donc normal que l’ACL en question soit plus restrictive qu’une autre. Celle du domaine par exemple.

Ces restrictions se manifestent par :
- L’héritage de permissions désactivé.
- Le propriétaire par défaut est positionné sur le groupe “Admins du domaine” à l’instar de la plupart des objets AD qui sont positionnés sur le groupe “Administrateurs”. Le propriétaire d’un objet est le seul à pouvoir prendre pleinement le contrôle et réinitialiser complètement ses permissions.
- Enfin, les groupes “Admins du domaine”, “Administrateurs” et “Admins de l’entreprise” sont les seuls à pouvoir modifier les attributs de l’objet “AdminDSHolder”. La plupart des objets/attributs AD nécessitent des privilèges moins élevés pour être modifiés.

Est-il possible de modifier la fréquence de détection ?
Par défaut, ce processus s’exécute toute les 60 minutes.
Il est possible de régler ce temps via la clé de registre :

AdminSDProtectFrequency (DWORD) en secondes

Dans le conteneur suivant :

Exemple de commande pour une exécution toutes les 10 minutes :

Est-il possible de modifier son comportement ?

Il est possible de modifier dans une certaines mesure toutefois les groupes protégés par AdminDSHolder. Ceci est possible grâce à une KB pour Windows 2000 et 2003 Server et nativement depuis Windows 2008 toutes versions.

Il est ainsi possible d’exclure du contrôle les groupes suivants :

Account Operators – Server Operators – Print Operators -Backup Operators

Cette information est contenue dans le dernier caractère de l’attribut “dsHeuristic” de la partition de Configuration du domaine. Cet attribut est partagé au sein d’une même forêt.

Ce caractère, codé en Hexadecimal, correspond au tableau suivant :

Une fois la valeur définie, il est possible de procéder à la mise à jour de l’attribut “dsHeuristic”. Suivre le KB817433.

ATTENTION - Ces modifications peuvent avoir des conséquences irrémédiables dans votre Organisation et doivent impérativement être réalisées en plateforme de test au préalable. D'une manière générale, sauf besoin explicite, il n'est pas conseillé de modifier le comportement de ce mécanisme.

Comment savoir si un compte est protégé par AdminSDHolder ?
La méthode la plus fiable pour savoir si un compte est protégé par ce processus est de regarder l’attribut Active Directory  ”adminCount”. Si ce dernier est positionné à “1″, l’objet a été modifié par AdminSDHolder.

La requête PowerShell/LDAP suivante permet de retourner la liste des utilisateurs concernés :

La requête PowerShell/LDAP suivante permet de retourner la liste des groupes concernés :

Qu’est ce que la notion d’objets AdminSDHolder Orphelins ?

Lorsqu’un utilisateur ne fait plus partie d’un groupe protégé, il est important de savoir que l’attribut “adminCount” reste positionné sur la valeur “1″. 

De plus, l’option d’héritage d’ACL parentes qui pouvait être cochée avant, ne sera pas re-cochée. L’objet ne recevra donc plus d’ACL et passera ainsi dans un mode dit “orphaned AdminSDHolder objects”.

Ces objets devront donc, après extraction d’un groupe protégé, être traités manuellement. Un script VB fourni par Microsoft permet d’aider à ré-activer cet héritage sur ces comptes. Suivre la KB817433.

Conclusion

J’espère que ces quelques lignes vous aurons permises de comprendre un peu mieux ce mécanisme de sécurité assez peu connu.
 

Pour aller plus loin :

http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx