Office 365: Monter une machine de management pour gérer Office 365

 Dans un précédent message, j’expliquais le cas particulier du client CSOM pour la gestion des site SharePoint:

• Office 365: Comment Gérer SharePoint Online avec Client Side Object Model (CSOM)

La question qui se pose à ce stade est comment faire pour gérer un Tenant 365.

---

Machine dédiée

Il est clair que l’interface graphique, même dans sa nouvelle version, reste limitée en fonctionnalités et très rapidement, le scripting devient obligatoire.

De part le mode d’exécution qui est à prévoir sur les différents modules de la plateforme, une machine dédiée est rapidement obligatoire:

• Tache planifiée
• Script de check ou contrôle
• Outil de provisionning
• Outil de migration
• …

De plus, un serveur permet de ne pas être attaché au développeur ou consultant en cas de remplacement.

Il n’est pas non plus nécessaire d’avoir le modèle objet de SharePoint, puisque tout se fait en Remote (via PowerShell), donc un simple serveur Windows 2012 R2 avec les FrameWork .NET nécessaires aux applications de gestion. Il faudra ensuite installer:

1. Office 365 PowerShell for SharePoint Online
2. SharePoint Online Client Components SDK (SharePoint Online)
3. SharePoint Server 2013 Client Components SDK (SharePoint 2013 si nécessaire)

---

Online et On-Premise ?

Attention, pour les environnements On-Premises, la version CSOM pour SP Online est un fork de la version On-Premise de SharePoint 2016, ainsi on ne peux pas installer la dernière version CSOM 2016 On-Premise une fois le module Online installé, on obtient d’ailleurs le message suivant:

Si vous devez gérer les deux environnnements (SP Online et SP 2016 On-Premise), il vous faudra deux serveurs de gestion. En revanche, gérer SP Online et SP 2013 On-Premise est bien possible depuis une seule et même machine, puisque les deux versions s’installent sans soucis:

• SharePoint On-Premise 2013: CSOM version 15.0.4711
• SharePoint Online 2016: CSOM version 16.0.4002

---

Comment charger CSOM dans les scripts PowerShell

Il est possible de faire la méthode “à l’arrache” pour cela, sans aucune certitude de la portabilité et de la version du modèle CSOM chargé (2013, 2016 Online ou 2016 On-Premise) via la commande LoadWithPartialName (qui est d’ailleurs Obsolète maintenant), comme suit:

function Add-SPOAssemblies {
     [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
     [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.Runtime") | Out-Null
}

Cette commande prendra la version qui est définie dans les assemblies de votre serveur, si on prend le cas d’une machine fraichement installée avec les deux CSOM (SP Online 2016 et SP On-Premise 2013) la commande suivante nous donne le résultat:

$loadInfo1 = [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client")
write-host $loadInfo1.FullName
>> Microsoft.SharePoint.Client, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

La version de l’assembly chargée est donc bien la SP Online 2016, ce qui peut poser des problème dans votre script.

Il est donc préférable d’utiliser le pointeur vers la DLL à charger directement:

SP On-Premise 2013:

Add-Type -Path "c:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.dll"
Add-Type -Path "c:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.Runtime.dll"

SP Online 2016:

Add-Type -Path "c:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.Client.dll"
Add-Type -Path "c:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.Client.Runtime.dll"

D’ailleurs une rapide comparaison des répertoires ISAPI indique de nombreux changements entre les deux versions:

SP On-Premise 2013	SP Online 2016

Ce qui pousse bien dans la direction d’utiliser CSOM pour toute la gestion de SharePoint à l’avenir.

---

Autres outils

Tout ceci dépendra de vos besoins en interne et de la fédération des équipes de gestion de votre tenant Office 365. Si vous êtes organisé en silot indépendant, il est préférable d’avoir un serveur par type de produit (Exchange Online, SharePoint Online, Skype, …). Si en revanche, votre équipe est bien organisée, vous pouvez mettre tout le monde sur le même serveur de gestion en définissant simplement des règles d’usage et de priorité.

Attention toutefois à ce que ce serveur soit bien considéré comme de la production sous peine d’y retrouver un fourre-tout ingérable très rapidement.

Romelard Fabrice [MBA Risk Management]