L'équipe Unified Communications c'est 20 consultants experts sur les technologies Exchange, Lync et Office 365. Les consultants de Microsoft Services France proposent à la communauté IT Française de partager sur ce blog leurs expériences.
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
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.
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 :
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.
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 :
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 :
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 :
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
3. Injecter dans la session un script complet :
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
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".
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 :
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
$urlEntry = New-CsSimpleUrlEntry -Url https://planif.contoso.com
$simpleUrl = New-CsSimpleUrl -Component “WebScheduler” -Domain “*” -SimpleUrlEntry $urlEntry –ActiveUrl https://planif.contoso.com
Set-CsSimpleUrlConfiguration -SimpleUrl @{Add=$simpleUrl} -Verbose
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 :)
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.
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
adresse à ajouter
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
Le client Mobile Lync 2013 pour Android vient d'être mis à jour et offre désormais le support des tablettes Android. Cette version propose un ajustement de l'interface notamment au niveau de la taille des icônes, images et vidéos pour tirer avantage des plus grandes résolutions offertes par ces périphériques. Cette mise à jour ajoute également les nouvelles fonctionnalités suivantes :
- Inviter des utilisateurs supplémentaires lors d'une conférence Lync
- Créer une conversation à plusieurs à n'importe quel moment
Vous trouverez plus d'informations ainsi que des captures à cette adresse
http://blogs.office.com/2014/05/12/lync-mobile-update-for-android-tablet-support-and-conversation-enhancements/
La mise à jour du client Lync 2013 de mai 2014 vient également d'être publiée.
Cette mise à jour cumulative apporte la correction suivante :
- Correction de l'insertion de mauvais émoticône dans une conversation après avoir installé Office 2013 SP1 ou ultérieur
- Correction d'un bogue où l'utilisateur n'entendait pas la voix dans un appel audio/vidéo en Lync 2013
- Mise à jour des indices MOS dans les rapports de QoE pour les appels entre un client Lync 2013 et un client Lync mobile
A l'instar des autres mises à jour cumulatives, cette mise à jour inclus l'ensemble des correctifs et ajouts des précédentes versions. Elle est disponible à l'adresse ci-dessous :
http://support.microsoft.com/kb/2880980
Le client Lync 2013 vous demande une authentification au réseau ? Dans ce cas, vous avez surement un problème de votre client Lync au niveau d’un proxy.
Cet article s’adresse aux utilisateurs Lync 2013 Office 365 et On Premise.
1. Mise à jour
Deux mises à jour corrigeant ce type de problème sur le client Lync 2013 sont sorties en septembre 2013. La première corrige une demande d’authentification lorsque le client Lync télécharge les photos des contacts externes à l’entreprise. Ce problème s’applique à tous types d’entreprises, qu’elles aient un proxy ou non. La demande d’authentification est en réalité liée au proxy de l’entreprise du contact dont vous téléchargé la photo. Cette mise à jour est décrite ici.La deuxième corrige aussi une demande d’authentification, mais cette fois-ci lorsque le client Lync télécharge une présentation Power Point. Cette mise à jour est décrite ici.Donc la règle d’or est d’avoir la dernière version du client Lync, qui est disponible sur le Lync Update Center.
2. Proxy et exception
La plupart des proxys requièrent une authentification. Cela génère une fenêtre d’authentification ou parfois bloque le client Lync.
1. Pour un environnement On PremisePour répondre à cet incident, ajoutez dans vos exceptions proxy les URLs suivantes :
2. Pour un environnement Lync OnlineSi vous ne voulez pas que votre client Lync passe par un proxy, vous devez ajouter dans les exceptions de votre proxy les URLs décrites sur ce lien http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh373144.aspx
3. Le proxy PACVous avez un proxy PAC renseigné dans Internet Explorer et une demande d’authentification au réseau du client Lync 2013 ?Il est possible que votre client Lync 2013 ignore les règles sur le fichier proxy PAC. Certains enregistrements sont respectés par Internet Explorer mais ne le sont pas par Lync 2013. Dans ce cas, Lync 2013 continue de passer par le proxy alors qu’il devrait aller directement sur l’adresse spécifiée. Si le proxy requiert une authentification, le client Lync reçoit alors une demande d’authentification au réseau.La solution de contournement dans ce cas, est de rajouter les lignes suivantes au début de votre script PAC. Cela permet de se connecter directement aux services web de découverte automatique Lync, sans utiliser de proxy.
Suite à cet ajout, le problème devrait être résolu.Pour vérifier que vous utilisez un proxy PAC, allez dans les options d’Internet Explorer, puis dans connexion et enfin dans les propriétés du LAN. Vous devriez avoir un adresse dans la configuration automatique d’un script comme ci-dessous.
Natacha MIKO, Premier Field Engineer, Microsoft France
Ingénieur Conseil Grands Comptes chez Microsoft depuis 2011. Je suis spécialisée sur les technologies de Communication Universelle (Lync/OCS). J'interviens pour des missions réactives et proactives de courtes durées dans toute la France sur des sujets d’expertises techniques pour les clients Premier. Je fais du conseil, des formations, des installations, de la résolution d'incident, des audits... J'ai suis en charge d'une dizaine de clients différents par mois.
Le client Lync pour Mac vient d’être mis à jour et passe désormais en 14.0.9. Il apporte de nombreuses corrections de Bug mais également des nouveautés fonctionnelles telles que :
Vous trouverez ce correctif à cette adresse :
http://support.microsoft.com/kb/2963369
Office 365 permet plusieurs gestions de l’identité pour les utilisateurs. Les évolutions étant régulières, il est intéressant de faire un point sur ces méthodes et leurs mécanismes. Cet article a pour objectif de décrire brièvement les trois méthodes disponibles, de rappeler les concepts de l’authentification multi-facteurs et présenter les deux solutions de Microsoft : Windows Azure MFA et MFA for Office 365.
1° Quelles sont les méthodes de gestion des identités avec Office 365 ?
Il existe plusieurs moyens de gérer les identités dans Office 365 :
Les trois modèles de gestion de l’identité dans Office 365 peuvent être décris comme suit :
2° L’authentification multi-facteurs, kézako ?Une description très académique de l’authentification multi-facteurs (MFA en anglais) peut être faite par : l’utilisation d’au-moins deux des éléments suivants :
La MFA est dite renforcée quand on utilise deux modes différents :
3° L’offre MFA de MicrosoftMicrosoft fournit un service d’authentification multi-facteurs à travers deux offres différentes :
Les deux services utilisent PhoneFactor, société acquise par Microsoft en 2012MFA for Office 365:
Il faut noter que MFA for Office 365 est disponible dans tous les plans de licences Office 365 et ne permet de sécuriser que les ressources Office 365.Windows Azure MFA:
4° Eléments de comparaison entre Windows Azure MFA et MFA pour Office 365
Globalement on peut noter que MFA for Office 365 est fourni gratuitement dans le cadre d’un plan de licence Office 365 et Windows Azure MFA est un service payant offrant un panel plus étendu de fonctionnalités. Voici un tableau comparatif des deux services :
La différence majeure entre les deux solutions est que Windows Azure MFA permet de fournir un service de multi-authentification pour les applications on-premises, qu’elles soient développées en interne ou commerciale (sous réserve de compatibilité bien-sûr). Alors que MFA for Office 365 est cantonné au cadre d’Office 365.
Voici quelques éléments de décision quant à la solution à adopter :
Cet article vous a présenté les méthodes de gestion de l’identité dans Office 365 et les solutions possibles pour implémenter une authentification multi-facteurs. Pour aller plus loin, je vous encourage à monter votre plateforme de tests et consulter la documentation disponible en ligne :
Windows Azure MFA :
http://technet.microsoft.com/en-us/library/dn249471.aspx
MFA for Office 365 :
http://technet.microsoft.com/en-us/library/7a9c56cf-72f1-4797-8e86-a9a2d9569ef6#whatareapp
Dans ce second article, je vous présente la mise en place et l'utilisation de "MFA for Office 365" :
Office 365 & Identités – Partie 2 – MFA pour Office 365
Jérôme BRUNELET, Consultant Communication Universelles, Microsoft Consulting Service France
Un début de carrière dans l’écosystème des partenaires Microsoft m’a naturellement conduit à intégrer MCS en 2012. Depuis j’interviens en tant que Consultant Communications Universelles, plus spécifiquement sur les solutions de messagerie on-premises et Cloud de Microsoft.
Dans un précédent article nous avons illustré les méthodes de gestion des identités dans Office 365 et introduit le concept de MFA. Les deux services proposés par Microsoft ont été présentés, Windows Azure MFA et MFA for Office 365.
Office 365 & Identités – Partie 1 – Solutions de MFA
Cet article présente l’utilisation de" MFA for Office 365", un rapide tutorial vous permettra de tester et comprendre cette fonctionnalité.
1° Mise en oeuvre de "MFA for Office 365"
Du point de vue administrateur Office 365, il est nécessaire d’activer le service "MFA for Office 365" pour les utilisateurs concernés.
Cliquer sur « Installer » face à « Définir une authentification à l’aide de plusieurs facteurs » :
Nous activons ici le service pour l’utilisateur "Robert Krakinovitch".
Note : il est bien évidement possible d’activer le service MFA en bloc, en utilisant un fichier ".csv" listant les utilisateurs et le statut désiré pour MFA.Cette opération est également réalisable en PowerShell, voir :
http://msdn.microsoft.com/en-us/library/7a9c56cf-72f1-4797-8e86-a9a2d9569ef6#enableuser
Du point de vue de l’utilisateur concerné, lors de sa première connexion il sera informé de la mise en place du MFA par son administrateur et des informations lui sont demandées. Le processus se déroule en trois étapes et uniquement lors de la première connexion consécutive à l’activation de MFA par l’administrateur :
L’utilisateur doit maintenant configurer le service pour se connecter. Il est important de noter qu’en cas d’activation généralisée de MFA pour Office 365, la gestion du changement sera un facteur déterminant dans l’adoption des utilisateurs. L’administrateur du Tenant Office 365 ne peut pas effectuer ces opérations en amont à la place des utilisateurs, il est donc nécessaire de prévoir un accompagnement des utilisateurs sous le format correspondant le mieux aux usages : guide de connexion, helpdesk, formation en séance, etc.
La première étape consiste à choisir le moyen utilisé pour l’authentification MFA : "SMS" ou "appel d’une messagerie vocale".
Note : Il est possible ici de spécifier par l’utilisateur un numéro de téléphone différent de celui renseigné dans Active Directory.
Note : Le numéro de téléphone professionnel inscrit dans Active Directory n’est ici pas éditable.
La seconde étape consiste à valider le numéro de téléphone renseigné (dans notre exemple cela se fait par l’envoi d’un SMS comportant un code de vérification à entrer) :
La troisième étape est ensuite relative aux mots de passe d’application. Il est demandé à l’utilisateur s’il se connecte à des applications sans navigateurs (typiquement les clients Outlook et Lync). Si oui, il lui faut générer un mot de passe d’application qui sera renseigné lors sa première connexion via ces applications :
Le mot de passe d’application est communiqué à l’utilisateur :
Cette étape conclut la configuration du service "MFA for Office 365" par l’utilisateur. Il est bien-sûr donné possibilité à l’utilisateur de modifier ces paramètres ainsi que d’autres par la suite, il lui suffit pour cela d’accéder aux options un fois connecté sur le portail Office 365.
Note : il est recommandé de créer un "app password" (mots de passe applicatifs) par périphérique et non par application. Par exemple un "app password" créé pour l’ordinateur portable d’un utilisateur permettra de renforcer l’authentification de ce dernier pour les applications concernées sur ce même ordinateur. Un autre "app password" pourra être utilisé sur le poste fixe du même utilisateur. L’idée est de ne pas avoir un "app password" par application, cela complexifierai le déploiement de "MFA for Office 365" et rendrai l’utilisation du service moins intuitive pour les utilisateurs. Les "app password" ne sont pas conçu pour être retenus par les utilisateurs mais renseignés dans les applications puis oubliés.
Les options de configuration possibles au niveau de l’utilisateur sont les suivantes :
--> Onglet Vérification de sécurité supplémentaire
Note : les options "Me notifier via l’application" et "Afficher un code unique dans l’application" nécessitent l’activation de l’option "Application Mobile". Dans ce cas, l’installation d’une application dédiée est nécessaire sur le smartphone de l’utilisateur :
Si l’utilisateur choisit cette option de vérification, lorsqu’il se connectera sur Office 365, au lieu de recevoir un SMS ou un appel, il validera son identité grâce à l’application mobile, soit par l’utilisation d’un code affiché dans l’application, soit en étant notifié dans cette dernière.
--> Onglet mot de passe d’application
L’utilisateur peut ici gérer lui-même ses mots de passe d’application en les créant ou en les supprimant. Il faut noter les points suivants qui sont importants :
- Le nom donné au mot de passe d’application ne sert que pour le tri, cela ne l’associe pas à proprement parler à l’application.
- Le mot de passe applicatif est ensuite affiché à l’écran mais il ne sera plus possible de le réafficher par la suite, l’option est donnée de le copier dans le presse-papier.
- "L’association" du mot de passe d’application avec l’application concernée se fait lors de son utilisation.
- Les mots de passe applicatifs n’expirent pas, lorsque le mot de passe Office 365 de l’utilisateur expire, les mots de passe d’application qu’il possède restent actifs et valides.
- Les mots de passe d’application sont à créer avant leur utilisation au travers des applications concernées.
- Le même mot de passe d’application peut être utilisé pour des applications différentes.
- Il est possible pour l’administrateur Office 365 du tenant concerné de forcer une suppression de tous les mots de passe d’application d’un compte utilisateur donné.
- Il est nécessaire de cocher la case « mémoriser ces informations » sur l’application lorsque l’on utilise les mots de passe applicatifs. L’idée est que l’utilisateur ne le renseigne qu’une fois et l’oublie ensuite.
Le mécanisme de double-authentification se fait par le principe que pour pouvoir créer un mot de passe d’application, l’utilisateur doit, au-préalable, s’être connecté à Office 365 avec son mot de passe utilisateur.
Une fois connecté, il créera les différents mots de passe applicatifs nécessaires qui seront utilisés pour se connecter aux applications connectées aux services Office 365 (Outlook, Lync, etc.).
2° Expérience utilisateur avec "MFA for Office 365" sur le client web
Une fois "MFA for Office 365" configuré par l’administrateur et par l’utilisateur, l’expérience sera la suivante.
L’utilisateur se connecte sur le portail Office 365 avec son mot de passe :
--> En cas d’option de vérification par SMS
Le menu suivant est affiché sur le navigateur et en même temps l’utilisateur reçoit par SMS (sur le numéro de téléphone qu’il a configuré) le code de vérification :
--> En cas d’option de vérification par code affiché sur l’application mobile
L’utilisateur ouvre l’application Multi-Factor Auth sur son téléphone et un code à 6 chiffres lui est présenté. Il doit le renseigner dans le navigateur :
3° Expérience utilisateur avec "MFA for Office 365" sur applications (Outlook & Lync)
Le mode de vérification est toujours le même, à savoir l’utilisation de mot de passe d’application. L’utilisateur a la possibilité de générer son mot de passe d’application et de le supprimer. Typiquement, le mot de passe à renseigner pour se connecter à Lync et Outlook n’est pas celui de l’utilisateur (de l’Active Directory local en cas d’utilisation de PasswordSync ou du Cloud) mais le mot de passe applicatif.
Note : dans le cas d’un nouveau déploiement où les profils Outlook ne sont pas encore configurés sur les boites aux lettres Office 365, une fois que Autodiscover aura trouvé les informations de configuration de la boite, l’utilisateur devra se connecter. Il faut garder à l’esprit que le mot de passe applicatif sera celui à renseigner et non pas celui du compte utilisateur.
Voici les écrans présentés lors de la configuration d’un profil Outlook pour un utilisateur qui a activé ses mots de passe d’application :
Le mot de passe que l’utilisateur doit renseigner ici est le mot de passe applicatif de son choix (il doit avoir été préalablement créé dans les options Office 365 du compte utilisateur). Il est nécessaire de cocher la case « Mémoriser ces informations », le mot de passe applicatif n’a pas vocation à être mémorisé par l’utilisateur.
Pour Lync, par exemple, le comportement est le même :
Un mot de passe applicatif doit être ici renseigné (il peut être le même que celui renseigné pour Outlook). Comme pour Outlook, il est nécessaire de cocher la case « Enregistrer mon mot de passe ». L’utilisateur se connecte ensuite à Lync :
Pour aller plus loin, je vous encourage à monter votre plateforme de tests et consulter la documentation disponible en ligne :
Avec le retour des vacances, il n’y a pas meilleur exercice que de mettre à jour ses infrastructures. Lync ne dérogeant pas à la règle, je vous propose une synthèse des mises à jour Lync disponible en ce mois d’aout.
Lync 2013 serveur CU5 :
Le CU5 de Lync 2013 est disponible au téléchargement à cette adresse http://support.microsoft.com/?kbid=2809243 parmi les corrections apportées on notera notamment :
Lync 2013 client :
La mise à jour d’aout disponible ici http://support.microsoft.com/kb/2881070 apporte notamment les corrections suivantes :
Lync 2013 pour Windows 8 (juin 2014) :
La mise à jour est à réaliser directement depuis le Windows store de votre machine Windows 8, elle comporte les éléments suivant :
Lync 2011 (juin 2014)
La mise à jour 14.0.9 est sortie en juin 2014. Et est disponible à cette adresse http://www.microsoft.com/en-us/download/details.aspx?id=36517 pour plus d’info vous pouvez voir le post du blog à cette adresse http://blogs.technet.com/b/frmcsuc/archive/2014/06/10/mise-224-jour-du-client-lync-pour-mac-en-14-0-9.aspx
Lync Phone Edition :
Lync Phone Edition passe en version 4.0.7577.4451 propose différente images en fonction du téléphone que vous utilisez :
Cette correction apporte notamment :
Un nouveau patch est apparu pour Lync client 2013 celui de septembre 2014.
Ce patch disponible à cette adresse http://support.microsoft.com/kb/2889860 corrige quelques problèmes :
Microsoft propose depuis peu Office 365 Message Encryption, une solution simple permettant l'envoi d'e-mails chiffrés à des contacts hors de votre entreprise. Quelle que soit la messagerie utilisée par le destinataire (Exchange, Outlook.com, Lotus Notes, Gmail…), il vous est désormais possible d'envoyer des informations sensibles de manière simple et sécurisée. Office 365 Message Encryption est une nouvelle version enrichie d'Exchange Hosted Encryption, et fonctionne avec Exchange Online et Exchange Server avec Exchange Online Protection. La solution est basée sur Azure Rights Management, inclut dans les plans Office 365 E3 et E4. Si vous ne disposez pas de licence, vous pouvez évaluer (version d'évaluation de 30 jours) et acheter Azure Rights Management (Gestion des droits Azure) en abonnement depuis le centre d'administration Office 365. Etudions en détail comment activer, configurer et utiliser Office 365 Message Encryption.
1° Activer Azure Rights Management et configurer Exchange Online
Avant de pouvoir utiliser Office 365 Message Encryption, il est nécessaire d'activer Azure Rights Management sur votre tenant puis de configurer Exchange Online pour Azure Rights Management. L'activation d'Azure Rights Management s'effectue depuis le centre d'administration Office 365 :
Il est à présent nécessaire d'utiliser Windows PowerShell pour configurer Exchange Online pour Azure Rights Management :
Il est à présent possible de configurer Office 365 Message Encryption.
2° Configurer Office 365 Message Encryption
La configuration d'Office 365 Message Encryption s'effectue depuis le centre d'administration Exchange en 3 étapes simples.
3. Cliquez sur enregistrer
3° Envoyer un message chiffré
Depuis le client de messagerie, créer un nouveau message en incluant CHIFFRER: dans l'objet.
4° Recevoir et répondre à un message chiffré
A la réception, un message chiffré se compose d'une courte instruction et d'une pièce jointe :
Pour consulter le contenu du message, il suffit d'ouvrir la pièce jointe et de s'identifier.Le destinataire doit s'identifier avec l'e-mail sur lequel il a reçu le message chiffré. 2 méthodes d'authentification sont supportées :
Une fois authentifié, le destinataire accède au message chiffré via une interface web basée sur Outlook Web App. Il peut alors en consulter le contenu et y répondre de manière sécurisée. Notez que la réponse ou le transfert du message est également chiffré. Une copie chiffrée de la réponse est également envoyée au destinataire initial.
5° Personnaliser Office 365 Message Encryption
Il vous est possible de personnaliser les messages envoyés par le service ainsi que le portail. Les éléments suivants peuvent être modifiés :• En-tête de l'e-mail• Disclaimer de l'e-mail• Titre du portail• Logo Pour ce faire, il est nécessaire d'utiliser Windows PowerShell et la cmdlet Set-OMEConfiguration (http://technet.microsoft.com/en-us/library/dn553406(v=exchg.150).aspx). En résumé…Office 365 Message Encryption a été conçu pour vous permettre d'envoyer des messages sensibles à des destinataires externes de façon simple et sécurisée, peu importe le système de messagerie du correspondant, en faisant abstraction des tâches d'administration nécessaires à l'implémentation de technologies similaires.
Julien Peigné, Consultant Office 365, Microsoft Consulting Services France
Ancien MVP Office 365, j'ai intégré Microsoft en janvier 2014 après avoir travaillé chez plusieurs partenaires en France et aux Etats-Unis. J'assiste nos clients dans leurs projets de migration vers Office 365 notamment..
Cette nouvelle mise à jour publiée le 23 septembre corrige un certain nombre de problème notamment :
Vous trouverez cette mise à jour à cette adresse http://support.microsoft.com/kb/2809243
Bonjour et bienvenue,
La plupart d'entre vous connaissent le sigle "MCS", non ce n'est pas le nom de code du clustering, c'est l'entité conseil de Microsoft : "Microsoft Consulting Services"
Nous sommes en France un peu plus de 160 consultants dans tous les métiers du conseil informatique, dont une trentaine personnes dédiées "UC".
UC c'est:
Notre mission est de conseiller et de mettre en place ces produits dans le respect des best-practices Microsoft ainsi que des besoins de chaque client.
Nous intervenons généralement chez les 100 plus gros clients de Microsoft France, dans le cadre de gros projets, associés ou non à des partenaires, mais aussi de temps en temps pour de l'expertise pointue de façon plus ponctuelle, ou pour des phases de "Vision & Scope" en début de projet.
Ce blog sera l'occasion pour la trentaine de consultants de s'exprimer sur les sujets qui leur tiennent à coeur, en français et en évitant si possible les annonces "pures" produits.
Vous y trouverez quelques news, mais surtout je l'espère des articles de fond qui reflètent notre expertise, ainsi que des trucs et astuces.
Enjoy,
Guillaume Bordier, Consultant UC.
Lors de l'installation de l'antivirus Forefront Security for Exchange Server (FSE) sur un cluster Single Copy Cluster Exchange 2007 (SCC) (http://technet.microsoft.com/en-us/library/bb892181.aspx) il peut arriver que FSE ne détecte pas le cluster et effectue une installation non cluster. Ainsi les fichiers de configuration (*.fdb) et de signatures seront stockés sur le disque local et non sur le disque partagé que vous aviez prévu d'utiliser. Si le problème persiste après plusieurs tentatives d'installation, vous pouvez appliquer la procédure suivante pour transformer l'installation en cluster-aware:
Ps: Vous êtes invité à vérifier que cette manipulation est toujours supportée!
Murat GUNYAR