Depuis quelques temps Microsoft propose une nouvelle interface d'administration pour Skype for Business et Teams.
Pour y accéder vous pouvez utiliser le lien suivant : https://adminportal.services.skypeforbusiness.com/analytics/home
Pour le moment toutes les fonctionnalités annoncées ne sont pas encore actives. Cependant on peut déjà analyser les appels passés via Skype Online !
Sur un appel / une conférence de mauvaise qualité il est possible de voir quel utilisateur a eu des problèmes.
Tout comme dans Skype for Business OnPremise les rapports nous permettent d’avoir des informations précises sur l’incident (micro de mauvaise qualité, jitter trop élevé, nombre de paquet perdu…).
Vivement la suite des fonctionnalités !
Contexte
Dans un environnement Office 365 il peut être nécessaire de savoir quelles fonctionnalités (Exchange, Skype, Yammer...) sont actives sur les utilisateurs.
Script
J'ai écrit le script suivant afin de récupérer automatiquement ces informations :
Get-UsersO365Features.ps1 (6,44 kb)
Pré-requis :
- Avoir un compte administrateur dans Office 365
- Avoir un dossier C:\temp\ sur sa machine
Limites :
- Actuellement le script ne prend en compte que les licences E1, E3 et K1
Résultat :
Une fois le script exécuté, vous avez dans le dossier C:\temp\ un dossier Export contenant :
- Trois fichiers contenant l'ensemble des utilisateurs et leur utilisation
- Trois dossiers contenant chacun le nombre de fonctionnalités actives et inactives
Licence du script :
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
Contexte
Dans Exchange Online il est possible de créer des listes de distribution dynamiques en se basant sur l’attribut UsageLocation. Cet attribut est défini par l’administrateur lors de l’attribution d’une licence à un utilisateur.
Cependant lorsque vous créez une liste de distribution il se peut que le filtre ne fonctionne pas et que l’erreur suivante apparaisse lorsque vous tentez de lister les membres de la liste :
Explications
Lorsque l’on regarde le filtre via la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que la valeur pour l’attribut UsageLocation est en Français. Ceci est causé par le fait que l’outil Microsoft Sign-In Assistant a été installé en Français.
Même si l’on créé le filtre à l’aide de la norme ISO 3166 (comme décrit dans la KB suivante https://technet.microsoft.com/en-us/library/bb738157(v=exchg.160).aspx), l’outil remplace le code par le texte en Français avant de l’envoyer au serveur Exchange.
Après avoir contacté le support Microsoft, nous avons eu une confirmation de ce problème et une mise à jour doit être apportée dans le code source de l’outil.
Solution
La solution en attendant le fix est de supprimer la liste de distribution et de la recréer depuis une machine où l’outil est installé en anglais. Pour cela, lancez les commandes suivantes :
Remove-DynamicDistributionGroup “dl_language_it”
New-DynamicDistributionGroup "dl_language_it" -RecipientFilter {UsageLocation –eq “IT”}
La liste des codes ISO pour l’ensemble des pays sont disponibles au lien suivant : https://www.iso.org/obp/ui/fr/
Si l’on vérifie avec la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que l’attribut UsageLocation est maintenant en Anglais.
Si l’on utilise la commande suivante pour lister les membres, l’erreur n’apparait pas et les membres du groupes apparaissent.
$group = Get-DynamicDistributionGroup ‘”dl_language_it”
Get-Recipient –RecipientPreviewFilter $group.RecipientFilter
Contexte
Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant. La première partie traitera de l’architecture et des pré-requis à la migration. La seconde partie traitera du plan d’action et de la migration. Enfin la troisième partie traitera des problèmes rencontrés lors de celle-ci.
Architecture
L’architecture de cette migration est assez simple. Deux environnements similaires contenant chacun Active Directory, Azure AD Connect, ADFS et O365. Le but de la migration est de migrer l’ensemble des données du tenant A vers le tenant B. Les comptes Active Directory ne sont pas migrés et l’ADFS A sera toujours utilisé par les utilisateurs de l’Active Directory A. La synchronisation vers le tenant utilisera bien évidemment le serveur AD Connect B. Enfin les adresses emails garderont le même nom de domaine de la source vers la destination.
Figure 1 – Schéma source de l’architecture
Figure 2 – Schéma cible de l’architecture
Pré-requis
Le premier pré-requis est d’avoir une relation d’approbation inter-forêt entre les deux forêts AD.
La migration tenant-to-tenant nécessite également un outil tiers afin de migrer l’ensemble du contenu des boites aux lettres (emails, contacts, calendrier…).
Un nombre de licences suffisant dans le tenant B est également indispensable pour accueillir les comptes du tenant A.
Enfin il est important d'avoir un compte administrateur global utilisant le domaine par défaut de microsoft (@domaine.onmicrosoft.com).
Voilà qui conclut la première partie de mon retour d'expérience. Stay tuned!
Contexte
Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la seconde partie qui traitera du plan d’action et de la migration.
Plan d’action
Lors de la migration les noms de domaine des adresses emails étant conservés, une coupure de service est obligatoire. Il est donc primordial de bien préparer la migration et d’effectuer en avance de phase toutes les tâches pouvant être traitées pré-migration.
Le plan d’action sera le suivant :
- Avoir un export de l’ensemble des données du tenant A. Pour chaque compte connaître son adresse de messagerie, ses alias, ses droits… Idem pour l’ensemble des objets Exchange (boites partagées, listes de distribution, contacts...)
- Créer des utilisateurs cloud uniquement dans le tenant B correspondant aux utilisateurs du tenant A. Exemple : john.doe@domainea.com aura un compte john.doe@domaineb.onmicrosoft.com
- Assigner des licences aux utilisateurs dans le tenant B
- Créer le reste des objets Exchange (attention certains objets peuvent-être synchronisés avec l’AD et d’autre uniquement dans le cloud) du tenant A dans le tenant B
- Commencer les migrations via l’outil de migration. Exemple : l’ensemble des mails plus vieux que les 30 derniers jours
- Arrêter la synchronisation de l’ensemble des objets de l’Active Directory A vers le tenant A (supprimer la synchronisation des OU dans Azure AD Connect A). L’ensemble des comptes dans le tenant A sont à présent en Soft-Deleted
- Utiliser la commande suivante pour restaurer l’ensemble des comptes en tant que comptes cloud uniquement :
Get-MsolUser –ReturnDeletedUsers –All | Restore-MsolUser
- Supprimer l’ensemble des références aux noms de domaine présent sur le tenant A (alias, adresses SIP,…). Tous les objets doivent avoir uniquement des adresses avec l’adresse par défaut de Microsoft
- Supprimer les noms de domaine du tenant A
- Ajouter les noms de domaine sur le tenant B
- Modifier l’UPN des comptes cloud du tenant B pour qu’ils soient égaux aux UPN des comptes de l’Active Directory A.
- Créer un nouveau connecteur sur l’AD Connect B pour synchroniser les comptes de l’Active Directory A. Une fois la synchronisation terminée, les comptes cloud du tenant B ont fusionné avec les comptes de l'Active Directory A.
- Finaliser la migration via l’outil (attention, les adresses sources et destinations ont changé, il est peut-être nécessaire de les mettre à jour dans l’outil utilisé pour la migration)
- Mettre à jour l’ADFS A via les commandes suivantes :
Set-MsolDomainFederationSettings –domainname "domainea.com" –ActiveLogOnUri "https://<url ADFS A>/adfs/services/trust/2005/usernamemixed" –issuerUri "http://<domainea.com>/adfs/services/trust/" –logoffuri "https://<url ADFS A>/adfs/ls/" –metadataexchangeuri "https://<url ADFS A>/adfs/services/trust/mex" –PassiveLogOnUri "https://<url ADFS A>/adfs/ls/"
Update-MsolFederatedDomain –DomainName "domainea.com" –SupportMultipleDomain
Migration
La planification
La planification de la migration est importante. En effet lorsque l’on se réfère au plan d’action on remarque que beaucoup d’actions sont à faire pendant l’interruption de service (de l’étape 6 à l’étape 12). Il est donc important de bien planifier la migration sur un weekend et de vérifier qu’aucune autre action est prévue à cette date là (paye, bilan comptable…).
Il est également très important de communiquer avec les utilisateurs tout au long du projet. Expliquer pourquoi une telle migration (intégration de la messagerie dans la messagerie groupe par exemple), bien indiquer les dates de la migration, prévenir de l’interruption de service et informer des éléments qui ne sont pas pris en compte par cette migration (signature…).
Y penser !
Une fois la migration terminée, le support utilisateur peut être amener à avoir une surcharge de travail. Avoir une équipe renforcée lors des premiers jours post-migration aidera grandement à la résolution des problèmes et à la gestion du stress des équipes.
Les actions post-migrations
Une fois la migration terminée, certaines actions sont nécessaires côté utilisateur (création d’un nouveau profil sur Outlook par exemple) mais aussi côté administrateur (donner de nouveaux droits d’administration aux équipes sur le tenant B par exemple).
Mettre en place un fichier de suivi pour les problèmes rencontrés est fortement conseillé. Cela permet de centraliser et donc de faciliter la résolution des problèmes et de ne pas oublier certains points (notamment si c’est un problème mineur).
Voilà qui conclut la seconde partie de mon retour d'expérience. Stay tuned!
Contexte
Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la dernière partie qui traitera des problèmes rencontrés lors de la migration.
Problèmes rencontrés et solutions
Eléments de calendrier non-migrés
Un point important pour que la migration des calendrier se fasse, la time-zone de la boite aux lettres de destination doit être renseignée. La commande PowerShell suivante permet de mettre à jour cet attribut
Set-MailboxRegionalConfiguration –Identity "<UserPrincipalName>" –TimeZone "GMT Standard Time"
Les valeurs possibles de la time-zone sont indiqués ici : https://support.microsoft.com/en-us/help/973627/microsoft-time-zone-index-values.
Migration OneDrive
Tout comme la migration des éléments de calendrier, la partie OneDrive nécessite une initialisation des comptes cibles pour que la migration s’effectue.
Lors de cette migration j’ai utilisé le script présent à l’adresse suivante pour initialiser l’ensemble des comptes.
https://support.office.com/fr-fr/article/Comment-configurer-des-sites-utilisateur-dans-OneDrive-entreprise-ceef6623-f54f-404d-8ee3-3ce1e338db07
Mauvaise synchronisation des comptes Active Directory
Au moment de la synchronisation de l’Active Directory A vers le tenant B, il est possible que certains comptes ne fusionnent pas avec leur compte cloud correspondant et que des doublons soient présent.
Il peut y avoir diverses raisons à cela :
- Une erreur dans l’UPN du compte cloud
- Un contact déjà présent dans le tenant B avec l’adresse email du compte A
- Un compte invité dans le tenant B avec l’adresse email du compte A
Dans ce cas, il faut tout d’abord supprimer l’objet (le contact ou le compte invité) du tenant B (en le supprimant également de la corbeille O365). Ensuite il faut désynchroniser le compte AD (en déplaçant le compte dans un OU non-synchronisée). Une fois le compte désynchronisé il faut supprimer ce compte de la corbeille O365. Lancer une nouvelle synchronisation pour que la métaverse de l’AD Connect prenne en compte la modification. Enfin resynchroniser le compte AD. Il doit alors fusionner correctement.
Si ce n’est pas le cas, il est possible que le compte cloud ne récupère par l'attribut ImmutableID. Cet attribut est le "lien" entre le compte dans l'Active Directory (et donc celui de la métaverse AD Connect) et le compte cloud O365.
Pour modifier l'attribut il faut de nouveau désynchroniser le compte AD et le supprimer de la corbeille O365 puis il faut utiliser les commandes PowerShell suivantes.
Sur l’Active Directory A :
$adUser = Get-ADUser "<SamAccountName>" –Properties *
$id= $adUser.ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($adUser.ObjectGUID)).tobytearray())}
Sur le tenant B :
Set-MsolUser –UserPrincipalName "<UserPrincipalName>" –ImmutableID $id
Resynchroniser le compte AD.
Conclusion
Ce billet termine mon retour d'expérience sur cette migration tenant-to-tenant. J'espère qu'il vous a été utile.
Contexte
Dans Office 365 lorsque vous activez une fonctionnalité qui déclenche un mail automatique (exemple : activation de l’UM, activation du PSTN calling…) le mail est rédigé dans la langue du tenant et non dans celle de l’utilisateur.
Explications et solution
Par défaut l’ensemble des mails envoyés automatiquement utilise la langue sélectionnée lors de la création du tenant. Donc si votre tenant a été créé en Français l’ensemble des mails sont envoyé en Français.
Pour changer la langue, en anglais par exemple, il faut que l’utilisateur possède l’attribut PreferredLanguage de renseigné sur son compte Active Directory. Pour l’anglais il est possible de mettre “EN-US” ou “EN-GB”.
La liste des code possibles est disponible au lien suivant https://technet.microsoft.com/en-us/library/ee825488.aspx.
Une fois la valeur modifiée (et après avoir effectué une synchronisation AzureADConnect) le mail envoyé est en anglais !
Script de modification de l’attribut PreferredLanguage dans l’AD
Si vous souhaitez modifier en masse l'ensemble des utilisateurs vous pouvez utiliser le script PowerShell ci-dessous.
$users = Get-ADUser -Filter * -SearchBase "DC=MONDOMAINE,DC=COM" -SearchScope Subtree
$actual=1
$total = $users.count
foreach($user in $users)
{
$sam = $user.SamAccountName
Write-Progress -Id 1 -Activity ("Working...Please wait") -PercentComplete ($actual / $total * 100) -Status ("Working on {0} - {1} / {2}" -f $sam, $actual, $total)
Set-ADUser $sam -add @{PreferredLanguage="EN-GB"}
$actual++
}
Contexte
La téléphonie d'entreprise est une pièce importante du SI. La migration de celle-ci est un projet majeur qui doit être bien préparé. Cet article divisé en trois parties est un retour d'expérience sur la migration d'une téléphonie VOIP/TOIP vers une Skype for Business. La première partie traitera des possibilités qu'offre la solution Skype for Business. La seconde partie traitera des différents aspects qui doivent être pris en compte lors de la migration. Enfin la troisième partie traitera des solutions connexes à Skype for Business qui d'augmenter le catalogue de fonctionnalités de la solution.
Les architectures possibles
Le déploiement de la téléphonie à travers Skype for Business est possible de trois façon :
- Architecture OnPremise
- Cloud PBX
- PSTN Calling (à venir)
L'architecture OnPremise implique que l'ensemble de la solution soit hébergé en interne. L'architecture Cloud PBX correspond à une architecture Skype for Business Online (Office 365) et une sortie PSTN en interne. L'architecture PSTN Calling est quant à elle entièrement online. Cette architecture n'est pas encore disponible en France. Les différentes architectures sont définies au lien suivant : https://technet.microsoft.com/en-us/library/mt612869.aspx.
Mon retour d'expérience porte sur un déploiement entièrement OnPremise. L'ensemble de l'architecture déployée l'a été directement au DataCenter du client.
Une infrastructure redondée
La téléphone est un élément important dans une société, son architecture doit donc être hautement disponible. De plus, contrairement à la messagerie la voix est un service en temps réel, l'architecture doit également être réactive.
Ces deux contraintes (haute dispo et performance) compliquent le design de l'architecture.
Architecture physique ou virtuelle ?
Pour Skype for Business, Microsoft supporte une architecture composée de machines physiques ou virtuelles. Cependant Microsoft recommande fortement une architecture physique. Cette recommandation s'appuie sur le besoin de la performance et pour éviter tous problèmes liés à la couche de virtualisation.
Pool de serveurs et multi-sites
Skype for Business intègre nativement un système de pool de serveurs afin de gérer la haute disponibilité du service. Il est ainsi possible d'avoir une architecture redondée sur un seul site.
Bien sur cette haute disponibilité native n'est pas à toute épreuve si l'architecture est présente sur un seul site. Avoir une architecture multi-sites permet de se prémunir des risques tels que les inondations, les feux, les coupures de liens...
Les rôles à déployer
Pour pouvoir déployer la téléphonie, il est indispensable de déployer les rôles Skype suivants :
- Front-End : serveur principal où les clients se connectent, il est recommandé d'en avoir entre 3 et 12 dans un pool
- Back-End : serveur SQL qui contient la configuration (une mise en miroir de la base de données est recommandée)
- Médiation : serveur nécessaire pour la voix, il sert d'interconnexion entre Skype et le monde téléphonique
- Edge : serveur qui permet la communication avec et depuis l'extérieur
- Reverse Proxy (rôle non Skype) : serveur qui permet la publication de tous les services web
Il est possible également de déployer les rôles suivants :
- Directeur : serveur qui permet d'authentifier les utilisateurs avant de transmettre la demande de connexion au Front-End. Il permet de ne pas faire tomber les Front-End en cas d'attaque (type DDOS)
- Persistent Chat : serveur de conversations permanentes, il permet d'avoir des salles de conversations multi-utilisateurs
- Watcher Node : serveur qui exécute des transactions synthétiques afin d'avoir plus de rapport dans SCOM
- Office Web Apps (rôle non Skype) : serveur qui permet de partager des PowerPoint dans Skype
Enfin pour que la téléphonie fonctionne il est nécessaire d'avoir une passerelle PSTN.
Ce qu'il faut retenir
Il est possible de faire différentes architectures de Skype for Business. Celle-ci doit être faite en fonction des besoins.
Voilà qui conclut la première partie de mon retour d'expérience. A bientôt pour la suite !
Contexte
Cet article divisé en trois parties est un retour d'expérience sur la migration d'une téléphonie VOIP/TOIP vers une Skype for Business. Voici la seconde partie qui traitera des différents aspects qui doivent être pris en compte lors de la migration.
Préparer la migration
Choix des terminaux
Le choix des nouveaux terminaux est un élément important de la migration. De nombreux modèles de téléphones et de casques sont compatibles avec Skype for Business. Voici les principaux facteurs de décisions :
- Qualité du son (entrant et sortant)
- Qualité générale du produit : est-il solide ?
- Ergonomie / prise en main / confort
- Support : quelles parties du téléphone / casque peut-on changer (câble, coussinets, mousse...) ? peut-on changer facilement ces pièces ?
- Prix
- Possibilité d'approvisionnement du fournisseur
Ce choix doit être fait à l'aide d'utilisateurs et il est également conseillé de prévoir différentes gammes de produits en fonction des utilisateurs (utilisateur standard, VIP...).
Ne rien oublier !
Le monde de la téléphonie est vaste et ne se limite pas uniquement aux téléphones des utilisateurs.
De nombreuses autres solutions utilisent les lignes téléphoniques classiques tels que :
- Les fax ou les serveurs de fax
- Les timbreuses
- Les centres d'appel (Service Desk par exemple) et les groupements d'appels (cellule voyage par exemple)
- Les accueils
- Les relations entre patrons et secrétaires
Exceptions
Parmi les nombreuses solutions qui utilisent les lignes téléphoniques, certaines doivent utiliser des lignes classiques et ne doivent pas être migrées :
- Les ascenseurs
- Les alarmes
Maquette
Comme dans de nombreux projets, monter une architecture de recette est fortement recommandé. Celle-ci doit être le plus ressemblant possible à l'architecture de production. Cette maquette permettra d'effectuer différents tests : ajout/suppression d'un rôle, modification d'une option, tests de failover...
Conclusion
La migration de la téléphonie doit être bien préparée. Un grand nombre de décisions sont à prendre avant de lancer le projet. Certains choix prennent plusieurs semaines avant d'être validé (choix des terminaux par exemple). Ce temps d'analyse et de décisions est impératif pour éviter les problèmes durant la phase de migration.
Voilà qui conclut la seconde partie de mon retour d'expérience. A bientôt pour la suite !
Contexte
Cet article divisé en trois parties est un retour d'expérience sur la migration d'une téléphonie VOIP/TOIP vers une Skype for Business. Voici la troisième partie qui traitera des solutions connexes à Skype for Business afin d'augmenter le catalogue de fonctionnalités de la solution.
Solutions connexes
Skype for Business n'a pas par défaut une solution pour l'ensemble des besoins téléphonique d'une société. Il existe des solutions tierces qui s'intègrent avec Skype. En voici quelques-unes.
ACD
Les ACD (ou Automatic Call Distribution) sont des dispositifs (logiciels ou matériels) qui permettent la gestion d'un centre d'appels. Ces centres d'appels peuvent être des accueils, des relations patron / secrétaire, un service support...
Par défaut, Skype intègre les Response Groups. Cette fonctionnalité permet de faire des groupements d'appels. Malheureusement cette fonctionnalité est limitée et ne permet pas de répondre à tous les besoins.
J'ai pu tester deux solutions d'ACD lors de mes projets qui sont :
Logs et facturation
Il est possible d'activer dans Skype for Business les rapports de surveillance. Pour cela, il faut configurer le rôle SQL Reporting Services sur un serveur Back-End. Ces logs tracent l'ensemble des communications des utilisateurs (chat, partages, appels entrants, sortants...).
Bien que ces logs existent, pour faire de la facturation sur les appels sortants ils sont peu exploitables. Il y a alors deux possibilités, faire appel à une solution tierce (comme Periscope GC http://www.cvt.com.au/periscopegcskypefb ou UC Analytics http://www.mindcti.com/uc-analytics/) ou développer un rapport personnalisé dans SQL Reporting Services.
Conclusion
De nombreux éditeurs ont développés des solutions supplémentaires pour Skype for Business. Microsoft recense l'ensemble des applications tierces compatibles sur le site http://apps.skypeforbusiness.com/.
Ce billet termine mon retour d'expérience sur la téléphonie à travers Skype for Business. J'espère qu'il vous a été utile.