? Microsoft Teams Gouvernance – ?️Construction du back-end -Part 2

Ce post fait partie d’une série en cinq parties: La gouvernance Teams au sein de l’environnement Microsoft Office 365. Retrouver l’ensemble des articles : ICI ?

Nous avons pu voir dans la première partie : ? https://hadness365.wordpress.com/2019/08/21/microsoft-teams-gouvernance-vue-densemble/ la théorie et l’ensemble des concepts associés à cette solution de Gouvernance du service Microsoft Teams au sein d’un environnement Office 365. Nous allons voir dans cette seconde partie la conception et la mise en place des différentes briques qui composent le back-end de la solution.

tl;dr : Voici la liste des étapes à réaliser dans l’ordre pour mettre en place la structure fonctionnelle de la solution de Teams Governance.

1 – Création d’un site SharePoint basé sur le modèle : TeamsSite

⚠️Note importante : Je vous recommande de créer ce site via le modèle de site sans Groupe Office 365 associé.

Pour être en mesure de créer un site SharePoint sans que ce dernier repose sur un groupe Office 365 il est nécessaire de passer par la console d’administration de SharePoint : https://<tenantName>-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx . Cette dernière est accessible via le portail d’administration du tenant Office 365 : https://admin.microsoft.com .

⚠️ Note importante : Il est nécessaire de disposer du droit administrateur SharePoint sur le tenant pour accéder à cette interface.

2 – Ajout de la structure : métadonnées, colonnes de sites et types de contenus dans le site SharePoint.

Ces données et types de données seront utilisées dans le workflow avec Microsoft Flow ainsi que dans l’application PowerApps mais peuvent également être accessible via toute autre application ou composant de type webPart SPFx …

Nous utiliserons un site SharePoint pour stocker l’ensemble des informations et paramètres nécessaires au fonctionnement de la solution. Cette technique n’est pas nouvelle et les personnes qui pratiquent SharePoint depuis un moment me rejoindront sur cette utilisation. (Merci Greg ?).

SharePoint permet, part sa malléabilité, et son intégration native à Office 365 : de disposer d’une solution simple pour stocker et manipuler des données. Ces dernières sont accessibles aussi bien pour des concepteurs d’applications, que des Power Users ou Product Owner au sein de l’organisation qui doivent pouvoir modifier la configuration d’une solution sans avoir à recourir à du développement spécifique.

Pour garantir le maintient futur de la solution, rendre facile son évolution et dans une logique d’industrialisation : il est recommandé de respecter certaines bonnes pratiques dès le début pour la création des listes et colonnes dans SharePoint Online.

• Utilisation de types de contenus (Content Types) : Pouvoir associé un template et des métadonnés à des contenus de manière systématique. L’avantage pricnipal est d’avoir des ensemble de métadonnées différents en fonction du type de contenu.
• Utilisation de colonnes de sites (Site Columns) : A la différence des colonnes de listes, les colonnes de sites sont réutilisables au sein d’un site et de ces sous sites (collection de sites).
• Utilisation d’une nomenclature adaptée (pas de caractère spéciaux, espaces…) : Améliorer la visibilité et la maintenance. Dans le cas d’une solution déploiée chez un client je vous recommande d’utiliser un prefix devant chaque Content Types, Site Columns voir même devant le nom du site SharePoint back-end et des équipes Teams Template. Ceci afin de pouvoir très rapidement avoir une vue sur l’ensemble des ressources développées et déployées et ainsi ne pas se mélanger avec des solutions tierses. Enfin le fait d’utiliser un prefix sera un avantage lors de l’utilisation de scripts ou développement SPFx. ?

? Pour aller plus loin : Je vous recommande la lecture cet article ?de ShareGate qui explique dans le détail ces concepts liés à SharePoint : https://sharegate.com/blog/start-learn-sharepoint-basics ?

?Note : Je ne rentrerai pas dans le détail pas à pas pour la création des types de contenus ainsi que des colonnes de sites. Cela sera abordé dans un article futur.

Vous pouvez trouver ici un tableau récapitulant l’ensemble des informations qu’il est nécessaire de créer.

?Cette liste étant la version stable la plus récente, elle a donc été amené à évoluer au fur et à mesure des développements réalisés autour du WorkFlow et d’une manière plus large de la solution et ses fonctionnalités. N’hésitez pas à vous l’approprier et à la modifier à votre convenance.
⚠️ pensez à mettre à jour votre export xml avec vos modifications (voir suite)

Pour réaliser la configuration du back-end : l’ensemble des actions de créations des types de contenus, colonnes de sites et vues sont à réaliser manuellement la première fois lors de la phase de design de la solution.

Vous l’avez compris la démarche voulue lors de la conception de cette solution a été de la rendre évolutive et facile à adapter à ses propres besoins et/ou contraintes organisationnelle tout en garantissant un déploiement industriel.

Contrairement à ce que l’on peut penser : la réflexion autour de l’industrialisation de l’application au sein de l’environnement Office 365 a été réalisé des les premières versions de la solution.
L’idée a toujours été de rester dans le cadre de la licence Office365 et d’éviter l’utilisation de ressources Azure du type : LogicApps ou AzureFunction ce qui entrainerai une facturation (même ridicule) et donc une souscription Azure. https://docs.microsoft.com/fr-fr/azure/logic-apps/logic-apps-overview

Pour adresser ce sujet d’industrialisation, il est possible d’utiliser différentes méthodes. Celle qui a été privilégié dans le cas du back-end SharePoint est : l’utilisation de PowerShell PnP pour gérer l’import et l’export de la structure du site SharePoint, le tout modélisée dans un fichier de configuration au format XML. Cette méthode permet un déploiement simple et très rapide. Enfin ce mode de déploiement s’adapte bien dans le contexte d’une organisation tout en permettant de répondre aux standards que peuvent demander des prestataires de services ou des partenaires Microsoft qui délivrent du service managé et privilégie de la délégation d’administration via des accès de type CSP.

Pour réaliser l’export de la structure il est nécessaire d’utiliser le module PowerShell PnP pour SharePoint Online .

Pour installer le module je vous invite à vous reporter à la documentation ?de Microsoft sur le sujet : https://docs.microsoft.com/en-us/powershell/sharepoint/sharepoint-pnp/sharepoint-pnp-cmdlets?view=sharepoint-ps

Une fois le module installé (ou mis à jour ?) il est possible de se connecter à l’environnement et plus précisement au site SharePoint de back-end pour effectuer un export ou un import en fonction de votre besoin.

Export de la structure SharePoint :

Connect-PnpOnline -Url https://tenantSource.sharepoint.com/sites/siteSource
Get-PnpProvisioningTemplate -Out outPutFileName.xml -Handlers Lists,Fields,ContentTypes
Disconnect-PnPOnline

Import de la structure SharePoint :

Connect-PnpOnline -Url https://tenantDestination.sharepoint.com/sites/siteDestination
Apply-PnpProvisioningTemplate -Path sourceOutPutFileNamePath.xml
Disconnect-PnPOnline

Une fois l’import réalisé le site SharePoint dispose des liens dans le menu de navigation. Chaque liste a également sa vue par défaut qui est configurée pour afficher les métadonnées (via les colonnes de site)

3 – Création des équipes Teams qui seront utilisées comme des templates pour être clonées.

Pour compléter le back-end de la solution il est nécessaire de disposer d’une équipe Teams pour chaque modèle associé. Cette équipe Teams représentera l’objet à copier lors du provisioning par le workflow et permettra d’inclure la même configuration à la nouvelle équipe. Cela permet de disposer d’une solution simple pour ajuster le modèle source et impacter la création des équipes Teams basées sur ce dernier.

⚠️ Recommandation importante : Il est fortement déconseillé de travailler avec un compte nominatif pour l’ensemble de ces étapes de création. Je recommande l’utilisation d’un compte “de service“. Ce dernier devra être membre du groupe “Propriétaire” sur les Groupes Office 365, donc les équipes Teams ainsi que le site SharePoint back-end.

4 – Configuration du tenant pour la mise en place de la restriction de la création des Groupes Office 365 afin d’en contrôler la méthode de création et une liste de classification disponible au sein de l’environnement.

Dans toute gouvernance de Microsoft Teams le premier choix à faire et celui du mode d’accès au service : Est-il en libre accès ou soumis à validation ?

A noter que le mode “libre service” peut également être disponible d’une certaine manière même après avoir restreint l’accès à la création des Groupes Office 365. Cette approche permet de limiter la frustration des utilisateurs : le service n’étant pas bloqué. Toutefois, il convient de mettre en place une procédure simple et intuitive pour soumettre une demande d’équipe Teams et garantir que cette dernière puisse être disponible très rapidement (en moins de 5 minutes par exemple ?)

Le monde du Change et de l’Adoption est fortement impliqué pour les sujets de gouvernance dans Office 365. Il convient donc de s’appuyer sur de la communication, de la formation, ainsi que les Champions et/ou Key User de l’organisation.

Un outil qui est imposé n’en fait pas pour autant un outil qui sera adopté par les collaborateurs. Pour en apprendre plus sur ces concepts, je vous invite à suivre la formation en ligne gratuite de Microsoft, qui montre par des méthodologies simples à reproduire, comment adresser ces problématiques tout en fournissant un ensemble de ressources et de supports pour réaliser cette transformation à l’aide des Champions et Key Users : https://www.edx.org/course/microsoft-service-adoption-specialist-3

Pour réaliser cette configuration il est nécessaire de disposer du module PowerShell AzureADPreview.
⚠️ Note importante : ce dernier ne peut pas être installé si un module AzureAD est déjà présent. Il convient donc de désinstaller le module AzureAD afin de pouvoir installer le module AzureADPreview.

Get-InstalledModule
Uninstall-Module AzureAD
Install-Module AzureADPreview

La documentation de Microsoft ?est bien écrite et permet de suivre l’ensemble des étapes associées à la mise en place de cette configuration. Je vous recommande de vous y reporter pour comprendre le fonctionnement de ce paramètre pour gérer les personnes autorisées à créer des Groupes Office 365 : https://docs.microsoft.com/en-us/office365/admin/create-groups/manage-creation-of-groups?view=o365-worldwide ?

$GroupName = "<SecurityGroupName>"
$AllowGroupCreation = "False"

Connect-AzureAD

$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
if(!$settingsObjectID)
{
	  $template = Get-AzureADDirectorySettingTemplate | Where-object {$_.displayname -eq "group.unified"}
    $settingsCopy = $template.CreateDirectorySetting()
    New-AzureADDirectorySetting -DirectorySetting $settingsCopy
    $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
}

$settingsCopy = Get-AzureADDirectorySetting -Id $settingsObjectID
$settingsCopy["EnableGroupCreation"] = $AllowGroupCreation

if($GroupName)
{
	$settingsCopy["GroupCreationAllowedGroupId"] = (Get-AzureADGroup -SearchString $GroupName).objectid
}

Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy

(Get-AzureADDirectorySetting -Id $settingsObjectID).Values

La dernière ligne affiche les modifications réalisées par le script.

Une fois le module AzrureADPreview installé : Ajout de la classification

Get-AzureADDirectorySettingTemplate

$Template = Get-AzureADDirectorySettingTemplate -Id <Group.UnifiedID>
$Setting = $template.CreateDirectorySetting()
$Setting[“ClassificationList”] = “Internal,External,Global,Confidential”
New-AzureADDirectorySetting -DirectorySetting $Setting

(Get-AzureADDirectorySetting -id (Get-AzureADDirectorySetting | where -Property displayname -value "Group.Unified" -eq).id).values

Pour changer une classification déjà en place :

Get-AzureADDirectorySetting | select ID -ExpandProperty Values
$Template = (Get-AzureADDirectorySettingTemplate | where{$_.displayname -eq "Group.Unified"})
$Setting = $Template.CreateDirectorySetting()
$Setting[“ClassificationList”] = “Internal,External,Global,Confidential,BoardMembersOnly”
Set-AzureADDirectorySetting -id <ID> -DirectorySetting $Setting

5 – Création du Workflow avec Microsoft Flow :

Cette série d’articles présente la version stable de la solution. Cela signifie que les méthodes de l’API Microsoft Graph utilisées dans la solution, et par conséquence dans le workflow, sont en conformitées avec l’engagement de support que garantit Microsoft.
Je dispose d’une version plus avancée que je présenterai dans un autre article. Cette dernière utilise des méthodes en preview qui, dans le cas de leur utilisation sur un environnement de production, ne sont pas supportées par Microsoft. Disposer d’une version Preview est nécessaire pour rester en veille permanente sur les changements de l’API Graph et ainsi pouvoir adapter et améliorer la solution en adéquation avec les évolutions permanentes de l’éco-système Microsoft Office 365.

“Le prix à payer pour faire moins de travail et s’appuyer sur les géants est de devenir redevable à ces géants. S’ils bougent, on bouge avec eux. S’ils s’arrêtent ou s’effondrent, les ennuis ne seront pas loin.”

Source : https://www.lemondeinformatique.fr/actualites/lire-pourquoi-les-developpeurs-detestent-ils-le-low-code-76497.html

?Pour la partie Microsoft Flow et l’utilisation du workflow : il est nécessaire de disposer d’une licence Flow P1

⚠️ Note importante : Des changements sont à venir avec le nouveau modèle de licensing concernant la PowerPlatform : https://powerapps.microsoft.com/en-us/blog/new-licensing-options-for-powerapps-and-flow/ . Les modifications concernant le licensing ne sont pas encore effectives.

? Au vu des modifications prévues : ma recommendation est d’acheter au minimum une licence Flow/PowerApps P1/P2 par environnement pour augmenter le délai d’utilisation et garantir l’accès à ces licences jusqu’en Mars 2020 sur le tenant.?

? Pour aller plus loin dans le sujet je vous invite à regarder la session de Microsoft Ignite traitant de ces modifications à venir : Microsoft Power Platform business model and licensing updates – Session I-BAP215 ainsi qu’à suivre de près les annonces sur les blogs de Microsoft PowerApps/Flow.

?En cours de rédaction : Un article ?détaillé sur les modifications à venir et sur l’analyse de l’impact et le fonctionnement qu’impliquent ces changements sur le mode de licensing de la PowerPlatform : Analyses, Recommandations et calculette excel (voir application PowerApps…?) pour estimer les coûts et prés-requis.

Le workflow se décompose en plusieurs parties

Il est possible d’importer et d’exporter le workflow de manière indépendante. Toujours dans un objectif d’industrialisation, il a été choisi d’utiliser les “Solutions” du CDS de la PowerPlatform. Ces dernières permettent une méilleure gestion du workflow et offres des possibilités plus avancées sur la partie Import / Export. Tout en incluant des nouvelles fonctionnalités tels que les composants, et les variables d’environnement (à venir avec la prochaine mise à jour d’octobre 2019 … )

L’avantage majeure de l’utilisation des “Solutions” est de pouvoir intégrer dans un package le(s) workflow(s) Microsoft Flow et la/les applications PowerApps et ainsi disposer d’un seul package à déployer, mettre à jour et maintenir.
Pour en savoir plus je vous invite à lire mon article suivant : https://hadness365.wordpress.com/2019/08/01/powerplatform-une-nouvelle-console-dadministration-?/ ?

Voici les étapes à réaliser pour effectuer un import/export d’un workflow non associé à une solution

---

---

Voici les étapes à réaliser pour effectuer un import/export d’une solution Flow/PowerApps

Etapes pour effectuer l’import d’une Solution

La solution s’ajoutera automatiquement dans la liste après l’import

Mon retour d’expérience sur l’utilisation des Solutions et de l’import/export est plutôt positif : cela peut sembler difficile à appréhender au début mais dans la pratique : simple à l’utilisation .
Il y a un réel gain de temps à utiliser cette fonctionnalité. Toutefois, dans le cas d’un déploiement pour un partenaire et donc de l’utilisation de connections, variables et environnements Office 365 différents, l’import/export devient plus compliqué. Nativement il n’est pas possible de définir la connection de destination à utiliser pour les différents services. . C’est une des principales frustration car trop limitée nativement dans ce type de scénario MAIS il existe des possibilités de reverse engineering assez simple car les fichiers présents dans un export sont de type JSON… attention aux petites surprises lors de vos tests ?.

Le workflow et la solution ne sontt pas prêt actuellement pour être partagés de manière anonyme (= sans inclure mes connections, url sharePoint …) je travail sur ce point pour vous partager l’export le plus rapidement possible et vous permettre d’installer cette solution directement sur vos environnements. Les captures d’écrans de la structure du workflow sont déjà une piste pour les plus téméraires ?

Mais d’où provient cette idée de gouvernance de Microsoft Teams ?

Cette idée m’a été souflée lors d’un webinar de Tom Arbuthnot fin 2018 : https://tomtalks.blog/2018/10/webinar-measuring-the-value-of-microsoft-teams-digital-teamwork-14th-november/

Après avoir gentillement ?partagé cette information avec mon mentor sur la PowerPlatform : Est venu l’idée de se lancer dans l’utilisation de Microsoft Graph et de Microsoft Flow.

Pour se mettre pleinementdans le contexte : fin 2018, Microsoft Flow fait de plus en plus de bruit et la PowerPlatform par extension. Microsoft met en avant l’utilisation de Microsoft Teams auprès des partenaires et des clients via un ensemble d’opérations Marketing & Communication. Enfin les clients sont demandeurs d’accompagnement, de conseils et de solutions pour gouverner Office 365 aussi bien dans des phases d’activations de services, que lors de l’adoption, d’évolutions et d’adaptations aux besoins métiers avancés que peuvent avoir certaines populations et organisations.

Première idée après avoir vu ce webinar : Connecteur Microsoft Flow,
succès rapide mais des couacs à l’utilisation : des déconnexions non élucidées et une stabilité de cette méthode plus que douteuse à l’époque. Cette méthode n’a pas été essayée de nouveau depuis.

Seconde idée : Récupérer les rapports d’analyse pour constuire un dashboard personnalisé via PowerBI permettant de faire ressortir des indicateurs de performance et aider à la mise en place d’une gouvernance à posterioi de l’utilisation du service Microsoft Teams.
Succès rapide et premiers pas sur Microsoft Graph tout en se formant à l’aide des 30 jours sur Microsoft Graph : https://hadness365.wordpress.com/2019/08/13/?guide-microsoft-graph-comment-bien-demarrer-sur-l-api-de-microsoft-365/

Les clients n’avaient pas (et n’ont toujours pas pour la pluspart) de solution de gouvernance de Microsoft Teams. Ils sont donc confrontés aux problématiques que posent une utilisation en libre accès de l’ensemble des services associés aux Groupes Office 365 (Yammer, SharePoint, Planner, PowerBI, OneDrive, PowerApps, Flow, Outlook, Stream) en clair : l’ensemble des services de collaboration Microsoft 365 au sein de l’organisation.

Cette deuxième idée à donc permis d’approfondir les connaissances sur la structure, le fonctionnement et les rouages propres à la manipulation de l’ensemble de ces services et ressources au travers de l’API Microsoft Graph.
Cela a rendu possible une très rapide montée en compétence qui a eu pour résultat la construction d’un workflow ayant pour but d’automatiser la création d’équipes Teams avec un ensemble de paramètres qu’il est possible d’activer à la demande pour modéliser son équipe, en fonction d’un contexte d’utilisation.

Une équipe Projet pour le service R&D peut venir avec certaines options, service, tabs et applications quand une équipe Sales ou RH va souhaiter disposer d’autres options qui sont propres aux métiers et types de projets associés.

Enfin il est à noter que l’API Microsoft Graph permet également de modéliser la structure même de certains services dépendants de Microsoft Teams : il est par exemple possible de créer des structures de Planner avec des tâches et une organisation précise et d’inclure tout cela lors du provisioning de l’équipe Teams. Gain de temps pour l’ensemble des collaborateurs étant amenés à utiliser le service et donc, gain de productivité pour l’organisation.

Que ce soit pour simplement adresser un besoin d’automatisation du provisioning ou à l’inverse répondre à des problématiques et besoins métiers ou organisationelles : cette solution permet d’y répondre part son fort potentiel d’adaptation.

Note?: Le contenu est exact au moment de la publication. Toutefois, des mises à jour et des ajouts sont effectués quotidiennement par Microsoft, ce qui pourrait en modifier l’exactitude ou la pertinence. Veuillez garder cela à l’esprit lorsque vous utilisez mes articles.

N’hésitez pas à partager votre retour d’expérience dans les commentaires ou si vous avez des questions.

Ce post fait partie d’une série en cinq parties: La gouvernance Teams au sein de l’environnement Microsoft Office 365. Retrouver l’ensemble des articles : ICI ?