Le 8 mai prochain, la fédération avec les utilisateurs Lync de Microsoft change. En effet, l'adresse IP de notre cible de fédération sipfed.microsoft.com évoluera début mai pour accompagner les changements voulues par Microsoft. L'ajout de cette adresse sera achevé le 9 mai.

Que dois-je faire ?

Si vous avez réalisé une implémentation classique de la fédération, c'est à dire autoriser au niveau des pare-feu l'accès entrant et sortant de n'importe quelle adresse sur le port 5061 pour l'interface Access Edge, et, que vous définissez les partenaires de fédération avec un nom DNS, alors vous n'avez rien à faire ! Sinon lisez ce qui suit :

Tout d'abord il est nécessaire de mettre à jour les règles de pare-feu pour autoriser le flux entrant et sortant vers la nouvelle adresse de sipfed.microsoft.com (131.107.255.86)

Description	IP	PORT TCP	PORT UDP	Statuts
adresse SipFed courante	65.55.30.130	5061	N/A	Adresse existante
Future adresse SipFed	131.107.255.86	5061	N/A	adresse à ajouter

• Pour les entreprises ayant défini la fédération comme une fédération direct sur IP c'est à dire sans utiliser sipfed.microsoft.com, il est nécessaire de mettre à jour leurs configurations avec la nouvelle adresse IP
• Pour les autres entreprises seule la mise à jour des règles de pare-feu est nécessaire, puisque la cible de fédération étant un enregistrement DNS ce dernier sera mis à jour lors de la modification

Et si je veux être fédéré avec Microsoft ?

^{Vous pouvez faire une demande auprès de votre interlocuteur Microsoft (TAM, consultant, PAM...) qui réalisera la démarche nécessaire pour autoriser votre domaine SIP auprès de nos serveurs Edge. Néanmoins, avant de faire cette demande assurez-vous des points suivants :}

- Vous utilisez Live communication 2005 ou supérieur

- Un enregistrement SRV publique est créé sous la forme _sipfederationtls._tcp.sip_domain sur le port 5061 qui pointe vers un enregistrement A valide pour le service d'accès du serveur Edge.

- Le pare-feu de votre société autorise la communication avec les infrastructures Edge Microsoft

- Votre serveur Edge est activé pour la fédération

- Le certificat déployé sur votre interface externe est signé par une autorité publique et comporte les entrées requise pour le serveur Edge telles que définis dans le technet http://technet.microsoft.com/en-us/library/gg413010.aspx

- Votre serveur Edge fait confiance aux certificats émis par l'autorité publique Microsoft

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.