PI Services

Introduction

Cet article divisé en deux parties est un retour d'expérience sur une migration entre tenant Office 365. Il ne traitera pas de tous les services disponibles sur Office 365 mais seulement de ceux rencontrés lors de la migration (voir Contexte). La première partie traitera de la migration des licences, du SSO (ADFS version 3.0) et de Dirsync. La seconde partie sera consacrée aux autres services d'Office 365.

Contexte

• Yammer
• Office 365
• OneDrive
• Exchange Online
• Sharepoint Online

La synchronisation via Dirsync ainsi que le SSO (via ADFS 3.0) sont activés.

La société possédait deux tenants et souhaitait migrer les services de l'un des deux (nommé ici myenterprise1) vers le second (nommé ici myenterprise2).

Gestion des licences :

Premièrement, avant de commencer toute manipulation technique, il faut posséder des licences disponibles suffisantes afin que les utilisateurs migrés puissent posséder une licence, une fois le transfert effectué. Il n'est pas nécessaire d'ouvrir un second abonnement. Microsoft peut proposer l'attribution de licences d'évaluations, le temps de la migration. Lorsque la migration "technique" est terminée, il faut procéder à la migration de licences. Celle-ci se fait auprès du support Office 365 qui demande de répondre à quelques questions afin de procéder au déplacement des licences (attention cette opération peut durer plusieurs jours). De plus, la personne qui répondra à ce questionnaire par mail devra être la personne qui a souscrit au contrat Office 365.

Migration Dirsync et SSO via ADFS

Sauvegarde de la configuration Dirsync

Avant toute chose, il est nécessaire de sauvegarder la configuration de Dirsync afin de prévenir toute erreur de manipulation et de la restaurer lorsque nous reconfigurerons cet outil. Cela est notamment utile lorsque l'on a configuré des filtres de synchronisation spécifiques. Pour se faire, il faut lancer le client Dirsync nommé miisclient. Il est situé dans Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell du répertoire d'installation.

Il faut se rendre dans l'onglet Management Agents puis cliquer sur le connecteur Active Directory et enfin choisir Export Management Agent. Une fenêtre permettant d'enregistrer le fichier au format XML s'ouvre.

Conversion d'un domaine fédéré et de ces utilisateurs

La seconde étape concerne la conversion d'un domaine fédéré via ADFS en domaine standard (arrêt de la fédération). Cette opération est a réaliser sur un ordinateur possédant les outils Microsoft Online Services permettant de se connecter à un tenant Office 365 en Powershell.

S'il s'agit d'une ferme de serveur, il est préférable d'indiquer le serveur primaire (le premier serveur ADFS installé).

Le paramètre DomainName est le nom du domaine fédéré à convertir, tandis que PasswordFile défini un chemin qui contiendra tous les mots de passes des comptes utilisateurs qui seront convertis par l'opération (ces derniers ne s'authentifiant plus via le SSO).

Si cette manipulation réussie, la fédération nommée Microsoft Office 365 Identity Platform n'est plus visible dans l'onglet Relying Party Trusts.

Ensuite, il est possible de désactiver la synchronisation Dirsync via le portail d'administration Office 365.

Dans la section utilisateurs du centre d'administration, sélectionnez utilisateurs actifs. Il faut ensuite cliquer sur l'option Désactiver qui est situé au niveau du label Synchronisation Active Directory.

Il est ensuite précisé que la désactivation peut durer jusqu'à 72H (lors de notre migration, cela n'a duré que quelques minutes).

Un bandeau avertissant de la désactivation de la synchronisation apparaît.

Modification des utilisateurs

Une étape intermédiaire consiste à modifier les UPN des utilisateurs synchronisés via Dirsync. En effet ceux-ci possèdent encore un UPN avec le domaine qui était fédérés. Avant que ce domaine puisse être transféré sur le nouveau tenant, il ne doit plus y avoir de comptes utilisateurs l'utilisant.

Ces quelques lignes de scripting récupère tous les utilisateurs d'un domaine défini et change leur UPN pour qu'ils utilisent le domaine onmicrosoft.com du tenant.

Attention, si un UPN existe déjà sur le domaine par défaut, il faudra le traiter manuellement en changeant le samaccountname de l’utilisateur.

Suppression du domaine

L'étape suivante est la suppression de l'ancien domaine fédéré. Cette manipulation peut être réalisée via le panneau d'administration Office 365 ou via Powershell (au travers d'une session connecté au tenant avec la commande Connect-MSOLService).

La commande Remove-MSOLDomain permet la suppression d'un domaine.

S'il existe des domaines enfants du domaine supprimé alors on rencontre l'erreur suivante :

“You cannot remove a domain that has subdomains. You must first delete the subdomains before you can remove this domain.”

Il faut d'abord supprimer le ou les domaine(s) enfant(s).

Aussi, si des utilisateurs empêchent la suppression du domaine, alors on rencontre l'erreur ci-dessous :

“Unable to remove this domain. Use Get-MsolUser –DomainName <domain name> to retrieve a list of objects that are blocking removal.”

Il suffit alors de récupérer la liste des utilisateurs problématiques avec la commande Get-MSOLUser -DomainName Nom_Domaine.

Ajout du domaine sur le nouveau tenant

Il est ensuite possible de réaliser la configuration du nouveau tenant en commençant par l'ajout d'un domaine. Il s'agit d'une configuration standard sur Office 365.

Création de la fédération

NB : Pensez à remplacer Serveur_ADFS par le nom de votre serveur primaire ADFS et myenterprise2.com par le nom du domaine AD que vous souhaitez fédérer.

Dans la console ADFS, on peut vérifier qu'un nouveau Relying Party Trusts a été créé (nommé Microsoft Office 365 Identity Platform).

Activation de Dirsync

Au même endroit que lors de la désactivation de Dirsync sur l'ancien tenant, il faut désormais activer cette fonctionnalité sur le nouveau tenant.

Reconfiguration de Dirsync

La migration d'un tenant à un autre de Dirsync n'est pas aisée puisqu'elle nécessite la désinstallation puis la réinstallation complète de l'exécutable.

Désinstallation sur l'ancien tenant :

Sur le serveur de synchronisation Dirsync, il faut arrêter les services Forefront Identity Manager Synchronization Service et Windows Azure Active Directory Sync Service. Il suffit ensuite de le désinstaller via le panneau de configuration. Enfin, il est nécessaire de supprimer la base SQL FIMSynchronizationService si vous avez utilisé un serveur SQL spécifique (par exemple en se connectant au serveur SQL via SQL Management Studio).

Installation sur le nouveau tenant :

L'installation de Dirsync est "classique". La session utilisateur doit être ouverte avec le compte de service qui exécutera Dirsync. Il faut lancer la commande dirsync.exe /fullsql depuis le répertoire de l'exécutable (le paramètre /fullsql n'est nécessaire que si la base SQL est présente sur une instance SQL déportée et non installée en même temps que le produit).

Les paramètres d'authentification à spécifier sont ceux du compte de service qui doit posséder les droits de créer la base de Dirsync (droits à affecter temporairement, le temps de l'installation). S'il s'agit d'une installation avec SQL Express alors la commande Install-OnlineCoexistenceTool n'a pas besoin de paramètre.

Au bout de quelques instants, l'exécutable se lance et il faut alors indiquer un compte administrateur général du tenant.

Puis un compte Active Directory membre du groupe Administrateur de l'entreprise (cela peut être temporaire, le temps de l'installation).

On peut ensuite activer les options de Mode Hybride et de Synchronization de mot de passe (s'il y a lieu)

Cela termine l'installation de Dirsync.

Enfin, il faut importer la configuration de Dirsync via l'export qui a été réalisé dans la section Sauvegarde de la configuration Dirsync.

Il s'agit de n'importer que le connecteur Active Directory en fournissant le fichier XML créé précédemment.

La reconfiguration des services Dirsync et du SSO via ADFS est terminée. Cependant, s'il y avait d'autres services actifs sur le tenant, il conviendra d'ajouter des actions avant, pendant, ou après ces étapes. Nous verrons cela avec Exchange, Sharepoint et Yammer dans la deuxième partie de cette série d'articles.

Cadre :

Dans le cadre actuel de l’amélioration des tâches planifiés chez un de nos client.

Périmètre :

Cette tâche devra être capable de tester les chemins de tous les serveurs en France et d'afficher un résultat sous forme de tableau HTML qui affichera uniquement les noms de villes.

Voici le script en tache planifié qui va permettre plus de clarté au niveau des tests des serveurs avec les noms des villes associé

# Date de Début de réplication
$DateStart = (get-date).ToString("dd/MM/yyyy : HH'H'mm")

# Log Robocopy + Loghtml contenant les noms de villes
$Loghtml ="C:\test\test.html"

# Listes des serveurs et de leurs situation géographique en l'occurrence nom de la ville
$LISTSRVCITY = @("SRV01","PARIS"),
("SRV02","LYON"),
("SRV03","MONTPELLIER"),
("SRV03","MARSEILLE"),
("SRV04","BORDEAUX"),
("SRV05","RENNES"),
("SRV06","LILLE"),
("KHOUA-DL-01","CREIL")

# Nombre de colonnes en relation avec la variable $LISTSRVCITY pour la première serveur et nom de villes pour l'autre
$Nbcolonne = "2"

# Tableau remplacant un fichier CSV en avec un bouclage sur la variable $LISTSRVCITY
# En mettant les serveurs dans la colonne LISTSRV et les nom de ville dans $LISTCITY
# c'est la variable $FileLineSRVCITY qui contiendra le tableau en question

$FileLineSRVCITY = @()
$rang = @("LISTSRV","LISTCITY")
Foreach ($LineSRVCITY in $LISTSRVCITY) {
 $MyObject = New-Object -TypeName PSObject
For ($i=0;$i -lt $Nbcolonne; $i++)

  {$MyObject | Add-Member -Type NoteProperty -Name $rang[$i] -Value $LineSRVCITY[$i]
  }
$FileLineSRVCITY += $MyObject
}

## La variable $style permet la construction de la page html avec cadres et couleurs
$style = @'
<style =type="text/css">
H1 {text-align: center;background-color: lightblue;}
H2 {text-align: center;background-color: yellow;}
BODY{background-color:PaleGoldenRod;}
TABLE{border-width: 1px;border-style: solid;border-color: black;border-collapse: collapse;}
TH{border-width: 1px;padding: 2px;border-style: solid;text-align: center;border-color: black;background-color:thistle}
TD{border-width: 1px;padding: 0px;border-style: solid;text-align: center;border-color: black"
</style>
'@

# La variable $Body permet la construction des titres et cadre supplémentaire dans le corps html

$Body = "<H1>Revue De Presse BI</H1><H2>Début de TEST : $DateStart</H2><br><center><table><tr><th><H3>Revue De Presse BI</H3></th></tr>"

# Il faut une seconde boucle pour insérer chaque ligne du tableau $FileLineSRVCITY avec condition vu ci-dessous

foreach ($LISTglobal in $FileLineSRVCITY) {

#Représente la liste des serveurs
$PATHSRV = $LISTglobal.listsrv

#Représente la liste des villes
$PATHCITY = $LISTglobal.listcity

# Test le chemin complet de tout les serveurs dans notre cas hormis le nom du serveur la fin du chemin \Users\kouasti\Downloads
# est identique pour tous les serveurs

$TESTPATHSRV= Test-Path \\$pathsrv\Users\kouasti\Downloads

# Condition si le chemin existe avec les droits de lecture au minimum alors le Nom de la ville apparait avec le fond de la cellule VERT et texte NOIR
# Sinon le Nom de la ville apparait avec le fond de la cellule ROUGE et texte BLANC

if ($TESTPATHSRV -eq "true")

{
$Body += "<td bgcolor=`"`GREEN`"><font color=`"`FFFFFF`">$PATHCITY</font></td>"
}
else
{
$Body += "<td bgcolor=`"`RED`"><font color=`"`white`">$PATHCITY</font></td>"
}

$Body +=  "</tr>"

}

# Fin de construction du corp html
$Body += "</table>"

# Date de Fin de réplication
$DateEnd = (get-date).ToString("dd/MM/yyyy : HH'H'mm")
$Body += "<H2>Fin de TEST : $DateEnd</H2>"
$Body += "</center>"

# Conversion du tableau complet avec les variables $style et $body en sortir fichier HTML

ConvertTo-HTML -head $style -body $Body | set-content "$Loghtml"

Voici le résultat en ouvrant le fichier TEST.HTML:

En Rouge: TEST échoué

En Vert: TEST réussi

Contexte

Depuis un serveur Exchange 2013, l’état du LowLogVolumeSpaceMonitor est en Unhealthy lors de l’exécution de la commande suivante :

Get-ServerHealth – Identity EXCHANGESERVER | ?{$_.AlertValue –eq "Unhealthy" }

Explications

Par défaut dans Exchange 2013 (CU6 ou plus récent), la valeur d'alerte pour le stockage des banques est paramétrée à 180 Go. Ce qui signifie qu'il faut au minimum 180 Go d'espace libre par banque.

Solution

Il est cependant possible de paramétrer cette valeur manuellement. Pour cela, ajouter la clé suivante au registre Windows :

Nom : SpaceMonitorLowSpaceThresholdInMB
Chemin : HKEY_LOCAL_MACHINE\Software\Microsoft\ExchangeServer\v15\Replay\Parameters
Type : DWORD
Valeur : L'espace libre voulu en Mo. Par exemple 50000 pour 50 Go.

Pour que la modification soit prise en compte il est nécessaire de redémarrer le service Microsoft Exchange DAG Management.

Contexte

Lors de la mise en place de DirSync dans une architecture, ce dernier envoie automatiquement des mails lors des problèmes de synchronisation.

Problème

L’adresse e-mail utilisée par DirSync n’est plus consultée et nous ne recevons plus d’alertes.

Solution

DirSync utilise l’adresse e-mail principale du tenant Office 365 (l’adresse enregistrée à la création du tenant). Il faut donc modifier cette adresse pour recevoir les alertes DirSync.

Une fois connecté au portail d’administration d’Office 365, il faut cliquer sur le nom de la société en haut à droite de la page. Puis il est possible de modifier les informations du compte principal, notamment l’adresse e-mail.

Note : cet article est inspiré et enrichi de la solution proposée par Jan Van Meirvenne sur son blog.

Une pratique assez courante en entreprise consiste à publier des informations sur les serveurs (rôle, site géographique…) dans des clés de registre « fiches d’identité » créées à cette fin.

Il est alors pertinent de créer des groupes SCOM correspondant à ces clés, afin de pouvoir créer des overrides, de cibler des rôles… en fonction de l’organisation logique déjà en place.

La solution la plus évidente, supportée nativement et réalisable aisément via la console SCOM consiste à étendre la classe Windows Computer à l’aide d’attributs personnalisés, peuplés à partir des clés de registre ; puis à créer des groupes contenant des instances de cette nouvelle classe étendue en filtrant en fonction du contenu de l’attribut étendu.

Cette solution reste cependant fastidieuse : dans le cas d’un grand nombre d’informations différentes (nombreux sites géographiques ou rôles serveur), créer puis maintenir à jour des dizaines de groupes s’avère complexe et peu fiable.

C’est pourquoi il est très intéressant de créer et peupler ces groupes automatiquement.

Commençons par revenir sur ce qu’est un groupe « normal » dans le modèle SCOM : contrairement à la plupart des objets qui sont des instances de classe créées automatiquement par des règles de découverte et hébergées au niveau de l’agent exécuté sur le serveur où se trouve l’objet (par ex une instance de la classe serveur windows, site IIS etc. ), les groupes sont créés de manière unique lorsque vous utilisez l’assistant correspondant et sont hébergés par les Management Servers : ils ne sont pas découverts, ils « commencent à exister » une fois l’assistant terminé.

Ce fonctionnement est propre aux classes qui possèdent l’attribut « singleton », ce qui en fait des classes qui sont également des objets.

Revenons maintenant à notre problème : nous souhaitons créer des groupes basés sur une règle de découverte classique, avec de multiples instances découvertes : il s’agit donc simplement de créer une classe qui dérive de la classe Microsoft.SystemCenter.InstanceGroup (comme tous les groupes), mais qui n’aurait cette fois pas l’attribut singleton.

Il est également nécessaire d’ajouter une propriété clé (key property) à notre classe : cela permet de ne créer qu’une seule instance de la classe même si la propriété est découverte à l’identique sur plusieurs agents ; autrement dit dans notre cas de ne créer qu’un seul groupe correspondant à un attribut géographique même si cet attribut géographique est retrouvé sur de multiples serveurs.

<ClassType ID="TEST.DynamicGroups.Group" Accessibility="Public" Abstract="false" Base="GroupLib!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="false" Extension="false">

<Property ID="Territory" Type="string" AutoIncrement="false" Key="true" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" />

</ClassType>

Maintenant que la classe est définie, nous allons pouvoir nous pencher sur la découverte qui découvrira ses instances. Et tant qu’à faire, nous en profiterons pour découvrir également les objets Windows.Computer qui peupleront ces groupes ainsi que la relation qui liera les groupes aux ordinateurs.

La découverte se fera à l’aide d’un script VBS, la seule possibilité pour découvrir à la fois le groupe, l’ordinateur et la relation : évitez donc de définir un intervalle d’exécution trop court pour ne pas surcharger vos agents!

Notez que pour que cette découverte fonctionne, il sera nécessaire d’activer le mode proxy pour tous les serveurs qui seront concernés.

Pensez à modifier la partie en jaune, elle concerne la clé de registre à interroger pour récupérer la valeur qui déterminera le nom du groupe.

<Discovery ID="TEST.DynamicGroups.Group.Discovery" Enabled="true" Target="Windows!Microsoft.Windows.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">

<Category>Discovery</Category>

<DiscoveryTypes>

<DiscoveryClass TypeID="TEST.DynamicGroups.Group" />

</DiscoveryTypes>

<DataSource ID="GroupDiscoveryDS" TypeID="Windows!Microsoft.Windows.TimedScript.DiscoveryProvider">

<IntervalSeconds>86400</IntervalSeconds>

<SyncTime />

<ScriptName>discoverdynamicgroups.vbs</ScriptName>

<Arguments>$MPElement$ $Target/Id$ $Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Arguments>

<ScriptBody>

SetLocale("en-us")

Dim oAPI
Set oAPI = CreateObject("MOM.ScriptAPI")

Dim oArgs
Set oArgs = WScript.Arguments

if oArgs.Count &lt; 3 Then

Call oAPI.LogScriptEvent("dynamicgroupdiscovery.vbs",101,1,"Script was called with fewer than three arguments and was not executed.")

Wscript.Quit -1

End If

Dim SourceID, ManagedEntityId, TargetComputer

SourceId = oArgs(0)

ManagedEntityId = oArgs(1)

TargetComputer = oArgs(2)

Dim oDiscoveryData, oInstManagedServer,oInstServerGroup,Territory,arrSubKeys

'Lecture de la clef d’identification dans la base de registre

Const HKEY_LOCAL_MACHINE = &amp;H80000002

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\localhost\root\default:StdRegProv")

oReg.GetStringValue HKEY_LOCAL_MACHINE,"SOFTWARE\TEST\ID_CARD","Territory",Territory

'Construction du nom du groupe et attribution d’une valeur par defaut si clef vide

If IsNull (Territory) Then Territory = "NA"

GroupName = "TEST - TERRITORY - " &amp; Territory

'Ajout de l’instance de l’objet Computer au propertybag

Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceID, ManagedEntityID)

set oInstManagedServer = oDiscoveryData.CreateClassInstance("$MPElement[Name='Windows!Microsoft.Windows.Computer']$")

call oInstManagedServer.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)

call oDiscoveryData.AddInstance(oInstManagedServer)

'Ajout de l’instance de l’objet Group au propertybag

set oInstServerGroup = oDiscoveryData.CreateClassInstance("$MPElement[Name='TEST.DynamicGroups.Group']$")

call oInstServerGroup.AddProperty("$MPElement[Name='System!System.Entity']/DisplayName$", GroupName)

call oInstServerGroup.AddProperty("$MPElement[Name='TEST.DynamicGroups.Group']/Territory$", Territory)

if Err.Number &lt;&gt; 0 Then

Call oAPI.LogScriptEvent("dynamicgroupdiscovery.vbs",104,1, "Script Error : Can't create ServerGroup (" &amp; Err.Number &amp; ") " &amp; Err.Description)

WScript.Quit -1

End If

call oDiscoveryData.AddInstance(oInstServerGroup)

'Ajout de la relation entre l’objet Computer et l’objet Group

Dim oInstWindowsComputer

set oInstWindowsComputer = oDiscoveryData.CreateClassInstance("$MPElement[Name='Windows!Microsoft.Windows.Computer']$")

call oInstWindowsComputer.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)

call oDiscoveryData.AddInstance(oInstWindowsComputer)

Set oRelationship = oDiscoveryData.CreateRelationshipInstance("$MPElement[Name='GroupLib!Microsoft.SystemCenter.InstanceGroupContainsEntities']$")

oRelationship.Source = oInstServerGroup

oRelationship.Target = oInstWindowsComputer

Call oDiscoveryData.AddInstance(oRelationship)

if Err.Number &lt;&gt; 0 Then

Call oAPI.LogScriptEvent("dynamicgroupdiscovery.vbs",104,1, "Script Error : Can't create ServerGroup to Computer relationship (" &amp; Err.Number &amp; ") " &amp; Err.Description)

WScript.Quit -1

End If

call oAPI.Return(oDiscoveryData)

</ScriptBody>

<TimeoutSeconds>600</TimeoutSeconds>

</DataSource>

</Discovery>

Le gros de la problématique est maintenant couvert, il ne vous reste plus qu’à intégrer cela à vos propres management packs !

Une dernière note : vu l’utilisation qui sera en général faite de ce MP (overrides, délégations, ciblage pour des vues spécifiques…), il peut s’avérer judicieux de le sceller afin d’être en mesure d’y faire référence depuis d’autres MP.

Lorsque l’on développe ses propres Management Packs, il arrive fréquemment que l’importe échoue pour des raisons diverses (bout de code oublié, mal placé, mauvaise référence…).

Dans ces cas, l’assistant d’importation des MP retourne normalement une erreur plus ou moins explicite qui permet, après un peu de déchiffrage et avec l’habitude, de localiser assez efficacement la cause du problème.

J’ai par contre été confronté aujourd’hui à un cas inhabituel : après l’ajout manuel (en modifiant le code XML directement à l’aide d’un éditeur de texte) d’une règle à un MP pré-existant, l’assistant a refusé l’import avec une erreur “vide” (ou pour ainsi dire sans erreur ) :

Après quelques heures de questionnements existentiels, de relecture de mon code, de tests en recréant la règle dans un autre MP (là, ca fonctionnait!), j’ai fini par mettre le doigt sur le problème :

La règle que j’avais ajouté contenait un Consolidator (d’où la création manuelle et pas via la console de SCOM), qui était appelé via la ligne

<ConditionDetection ID=”CD” TypeID=”System!System.ConsolidatorCondition”>

Alors que dans mes déclarations de références, le MP System.Library était déclaré avec l’alias SystemLibrary7585010 et non pas System.

Visiblement, l’assistant d’import de MP n’a pas su me signaler cette simple erreur de référence dans ce contexte précis, alors qu’il en est normalement parfaitement capable…

Une erreur bête qui m’aura tout de même fait perdre plusieurs heures!