PI Services

Il peut être nécessaire dans le cas d’un script insérant des données de performance de supprimer/recréer l’objet de performance

L’exemple ci-dessous montre la suppression ré-création d’un objet MyObject et d’un compteur de performance Mycounter1.

On vérifie l’existence de l’objet de performance via wmi et l’objet .net [Diagnostics.PerformanceCounterCategory]

On supprime MyObject

On recrée l’objet et son compteur  via Diagnostics.CounterCreationDataCollection et Diagnostics.CounterCreationData

On soumet la création de l’objet “global” via [Diagnostics.PerformanceCounterCategory]

Le compteur peut a partir de là être alimenté et interrogé.

L’outil gratuit de création de management pack de Silect Software a été mis  a jour en SP3

http://www.silect.com/mp-author 

Au menu:

- Amélioration de la visualisation et de l'édition des KB

- Amélioration de l’edition du XML

- Détection des oublis de champs DisplayName

- Possibilité d’utiliser les “Bases classes” a la place de LocalApplication en tant que cible d’une nouvelle classe.

- Affichage d’objets supplémentaires issus des MP

-  Ajout d’une liste dynamique de variable pour la customisation des messages d’alertes.

- Amélioration de la gestion de la mémoire utilisée.

PERIMETRE: Tâches planifiés qui permette la réplication de fichier d’un serveur vers un autre chez un de nos client.

FONCTIONNEMENT: Les tâches planifiées lancent des scripts PowerShell, la commande utilisé est la commande ROBOCOPY

Dans le cadre de la gestion des erreurs des commandes dites NON CMDLETS qui sont propre à powershell, la gestion des erreurs est différente.

SCRIPT D’ORIGNE:

#Listes des serveurs destinations +chemin
$Srvdestination = "\\orches1\tachep"
$srvdest1 = $Srvdestination.split("\")  
$srvdest = $srvdest1[2]

#Fichier Log avec nom du serveur.log
$Filelog = "$srvdest.log"

#repertoire de LOGS pour la derniere ligne du script powershell
$Folderlogs = "\\orches2\TACHEcollection2"

# Rapport Log Robocopy
$LOGS1 = "$Folderlogs"+"\"+"$Filelog"

#Option logs + chemin du rapport log
$LOGS = "/log:"+"$LOGS1"

#Liste de(s) fichier(s) à copier
$File = "*.*"

#Listes du dossier sources Réplication
$SourceFolder = "\\orches2\tachep2"

#Options de la commande robocopy
$optionstrings = "/XX,/E,/Z,/R:1,/W:2,/MT:64,/TEE"
$options = $optionstrings.split(",")

#Copie du fichier source vidéo vers le serveur de destination
$Robocopy = Robocopy $sourcefolder $srvdestination $file $options $logs

$LASTEXITCODE

Il faut savoir que dans la variable $Robocopy vous avez l’affichage du Log robocopy + la création du log $logs  grâce à l’option /TEE qui permet 2 sorties

Nous avons le log Robocopy sous cette forme :

-----------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows                             
-------------------------------------------------------------------------------

  Started : dimanche 8 mars 2015 16:40:16
   Source : \\orches2\tachep2\
   Dest : \\orches1\tachep\

    Files : *.*       

  Options : *.* /TEE /S /E /DCOPY:DA /COPY:DAT /Z /XX /MT:64 /R:1 /W:2

------------------------------------------------------------------------------

        New File          246.3 m    \\orches2\tachep2\tache.zip
  ------------------------------------------------------------------------------

               Total    Copied   Skipped  Mismatch    FAILED    Extras
    Dirs :         1         1         0         0         0         0
   Files :         1         1         0         0         0         0
   Bytes :  246.36 m  246.36 m         0         0         0         0
   Times :   0:00:59   0:00:14                       0:00:00   0:00:14
   Ended : dimanche 8 mars 2015 16:40:45

Nous voyons clairement que le log robocopy affiche le résultat de la copie Ok, mais lorsque la copie est un fichier ou répertoire identique  ou qu’il y’a des options au niveau du robocopy à ajouter ou modifier cela devient compliquer à gérer, de plus si nous voulons afficher une sortie simplifié du style Error ou Success en plus du log robocopy, il faudrait connaitre tout les retours sur ce qui est considérer comme Error ou Success , Sans oublier l’erreur de syntaxe de la commande robocopy qui n'apparait pas.

solution se baser sur  $LASTEXITCODE par contre le code de sortie de 0 à 16 cela ne nous dis pas si c’est une Erreur ou un Succès du déroulement de la copie

Voici le 2ème Script avec la gestion des erreurs qui inclura aussi l’erreur de syntaxe de la commande avec l’utilisation de TRY et CATCH. et le SWITCH pour les sorties $LASTEXITCODE.

2EME SCRIPT (le début et identique):

Pour info: Robocopy $LASTEXITCODE. :

- De 0 à 7 : Succès

- De 8 à 16 : Erreur

#Copie du fichier source vidéo vers le serveur de destination
$RoboSyntaxe = try {

      Robocopy $sourcefolder $srvdestination $file $options $logs | Out-Null

          Switch ($LASTEXITCODE) 
{   
"16" {$RobocopyJob = "Error Robocopy : Serious error. Robocopy did not copy any files. $srvdestination" }
"15" {$RobocopyJob = "Error Robocopy :OKCOPY + FAIL + MISMATCHES + XTRA. $srvdestination" }
"14" {$RobocopyJob = "Error Robocopy : FAIL + MISMATCHES + XTRA . $srvdestination" }
"13" {$RobocopyJob = "Error Robocopy :OKCOPY + FAIL + MISMATCHES. $srvdestination" }
"12" {$RobocopyJob = "Error Robocopy : FAIL + MISMATCHES. $srvdestination" }
"11" {$RobocopyJob = "Error Robocopy : OKCOPY + FAIL + XTRA. $srvdestination" }
"10" {$RobocopyJob = "Error Robocopy : FAIL + XTRA . $srvdestination" }
"9" {$RobocopyJob = "Error Robocopy : OKCOPY + FAIL. $srvdestination" }
"8" {$RobocopyJob = "Error Robocopy: Some files or directories could not be copied $srvdestination" }
"7" {$RobocopyJob = "Success Robocopy : Files were copied, a file mismatch was present, and additional files were present $srvdestination"}
"6" {$RobocopyJob = "Success Robocopy : Additional files and mismatched files exist, No files were copied $srvdestination" }
"5" {$RobocopyJob = "Success Robocopy : Some files were copied. Some files were mismatched $srvdestination"}
"4" {$RobocopyJob = "Success Robocopy : Some Mismatched files or directories were detected $srvdestination" }
"3" {$RobocopyJob = "Success Robocopy : Some files were copied. Additional files were present $srvdestination" }
"2" {$RobocopyJob = "Success Robocopy : Some Extra files or directories were detected $srvdestination "}
"1" {$RobocopyJob = "Success Robocopy : One or more files were copied successfully $srvdestination"}
"0" {$RobocopyJob = "Success Robocopy : No Change files successfully $srvdestination"}     
}
                           
    }catch{
          "Error : syntaxe command robocopy"
          } 
 

Dans ce script nous avons 2 types de sortie d’erreur :

- La 1ère s’effectue à l’aide du Try et catch, si on enleve le Y de ROBOCOPY on obtient :

- La 2ème s’effectue à l’aide du switch sur la variable $LASTEXITCODE mais commenter avec le chemin de destination et la variable qui permet d’afficher le résultat est $RobocopyJob :

Nous pouvons envoyer ses informations dans les journaux d’évènement dans un journal personnaliser APPLIMETIER par exemple plutôt que le log robocopy qui peut être trop long et pas pris en compte.

Introduction

Powershell 5.0 a bénéficié de plusieurs releases lors de l'année 2014, chacune d'entre elles apportant son lot de nouveautés/correctifs. Ce dernier est toujours en développement (la version finale n'arrivant qu'avec Windows 10) mais nous allons tout de même nous attarder dans cet article sur une nouvelle notion : la création de classes. Celle-ci n'était pas disponible nativement jusqu'en Powershell 5.0, ce qui pouvait paraître étrange pour un langage de scripting orienté objet. Je ferai un bref rappel sur les options disponibles avant cette version.

Dorénavant, nous pourrons créer nos propres objets personnalisés. Souvent, dans les scripts Powershell, on remarque l'utilisation de tableau ou de dictionnaire imbriqués et qu'il faut ensuite analyser pour récupérer la bonne valeur. Ces scripts obligent à avoir des algorithmes assez long et le script devient difficilement lisible en dehors du fait de ne pas être rigoureux. De plus, ils nécessitent souvent l'imbrication de multiples boucles de traitement influençant les performances générales du script.

Dans cet article, nous aborderons la création de classes d'objets en Powershell, l'ajout de propriétés et de méthodes ainsi que la façon d'instancier ("créer") nos objets. Pour certaines notions, une définition sera donnée (Cela permettra aux personnes non familières avec certaines notions de programmation objet de mieux appréhender le sujet).

Dans la suite de cet article, nous prendrons l'exemple d'une classe d'objet HRUser définissant un utilisateur dans le système RH pour illustrer la nouvelle syntaxe. Imaginons que cet exemple soit utilisé dans le cadre d'une interaction avec une base de données. L'objet utilisateur possédera les attributs suivant (nous ajouterons d'autres propriétés et des méthodes/fonctions ultérieurement) :

• firstname
• lastname
• isCollaborator (un booléan permettant de savoir si l'utilisateur est un collaborateur)
• salary (un nombre entier)

NB : Contrairement à la première beta, Powershell 5.0 est dorénavant disponible pour Windows 2012 et supérieur (qui n’était compatible qu’avec Windows 2012 R2 et supérieur). Le lien suivant vous mènera à la dernière beta sortie (Novembre 2014) :

http://www.microsoft.com/en-us/download/details.aspx?id=44987

Avant Powershell 5.0

Jusqu'à Powershell 4.0, il existait plusieurs méthodes pour créer des objets personnalisés en Powershell.

New-Object et NoteProperty :

La première méthode consiste à créer un objet de type PSCustomObject auquel on ajoute des propriétés de type NoteProperty.

Cependant, cette méthode ne permet pas d'ajouter des fonctions et le typage de nos attributs est dynamique. De plus, tout les objets personnalisés posséderont la même classe : PSCustomObject.

C# et Add-Type :

La seconde méthode était l'utilisation de code C#. Powershell pouvant interprété ce langage,  il est tout à fait possible d'écrire entièrement une classe en C# puis de l'ajouter dans une session Powershell via la commande Add-Type.

On peut ensuite créer l'objet grâce à la commande New-Object. Ce dernier possédera son propre type (HRUser) qui sera différent pour toutes les classes que vous créerez.

Il est aussi possible d'ajouter des fonctions statiques ou non à notre classe (nous reviendrons sur cette notion ultérieurement).

Cette méthode est complète mais nécessite de connaître le C#, ce qui complexifie aussi la lecture des scripts. Dans les prochains paragraphes, nous allons voir que Powershell offre dorénavant nativement les mêmes possibilités.

Les classes

Une classe contient la définition de nos objets ainsi que les traitements qui peuvent être effectués sur ceux-ci. Une nouveau mot clé apparaît dans Powershell 5.0 : “class” que l'on retrouve avant un scriptblock. Une classe se déclare de la façon ci-dessous :

Malheureusement, il n'existe pas encore de syntaxe pour gérer l'héritage de classe.

NB : Attention, les classes doivent obligatoirement être déclarées dans des scripts powershell. Une déclaration dans une invite de commande Powershell ne pourra donc pas être fonctionnelle.  De plus, lorsqu'une classe a été chargée, il est nécessaire d'ouvrir une nouvelle version avant d'en exécuter une version différente (elle ne peut pas être mis à jour dans une même session Powershell).

Les propriétés

Les propriétés contiennent tous les attributs de notre classe.

Celles-ci peuvent optionnellement contenir un type (comme dans l'exemple ci-dessus). Cela permet de réaliser de la validation sur les propriétés d'un objet.

Nous pouvons donc créer notre objet de type HRUser via la cmdlet New-Object en indiquant le type d'objet à créer.

On peut aussi créer un objet grâce à la méthode new qui existe dans chaque classe.

Toutes les propriétés sont initialisées avec une valeur par défaut (une chaîne vide, un booléen faux ou le chiffre 0 dans notre exemple).

On peut ensuite définir les propriétés de notre objet.

Attention, dans notre exemple, nos propriétés sont typées. On peut donc rencontrer une erreur si par exemple on définit une chaîne de caractères à la place d'un nombre pour la propriété “salary”.

Les constructeurs

Un constructeur permet de créer un objet en initialisant certaines ou toutes de ces propriétés avec des valeurs fournies en paramètres et éventuellement d'effectuer des traitements lors de la création d'objets. La méthode “new” que nous avons vu précédemment correspond au constructeur par défaut. Mais il est possible d'en ajouter un ou plusieurs autre, c'est ce qu'on appelle la surcharge.

La syntaxe d'un constructeur est la suivante (il faut la placer à l'intérieur de la définition de notre classe) : On peut créer l'objet en lui passant des paramètres pour utiliser notre constructeur :

Ou

Cependant, on rencontrera une erreur si on ne renseigne pas tous les paramètres :

Pour palier à ce problème, on peut imaginer un second constructeur sans le salaire :

Les méthodes

Les méthodes sont l'équivalent de fonctions qui permettant d'interagir avec un objet. Nous allons créer une fonction permettant de gérer l'augmentation de salaire d'un employé.

Le type indiqué devant la méthode nous indique ce qui est retourné (“void” correspond à une méthode ne retournant rien).

Exemple d'exécution incluant une augmentation de salaire pour une personne :

Si nous souhaitons récupérer le nouveau salaire, il faut modifier la méthode en utilisant le mot clé “return” et en modifiant le type de retour.

Méthodes et propriétés statiques

Il reste un dernier mot clé à définir : “static”. Il permet de définir des méthodes et des propriétés qui sont accessibles sans avoir à créer un objet. Pour illustrer cette notion, nous allons ajouter une propriété représentant le total des utilisateurs du système. De plus, nous allons modifier les constructeurs pour incrémenter le compteur quand un utilisateur est créé.

On définit la propriété count :

On peut y accéder via : [HRUser]::count

Voici le script contenant l'intégralité de la définition de  la classe HRUser :

Exemple d'exécution :

Il aurait pu être intéressant d'intégrer la modification du compteur lors de la suppression de l'utilisateur dans la classe. Cependant, il n'existe pas de destructeur (méthode permettant de détruire un objet) dans la version actuelle de Powershell 5.0.

Conclusion

Nous avons aborder la création de classes d'objets en Powershell qui nécessite d'avoir des connaissances en programmation orientée objet. Initialement, Microsoft a ajouté cette notion pour simplifier la création de ressources pour Desired State Configuration (exemple : https://technet.microsoft.com/en-us/library/dn820211%28v=wps.640%29.aspx). A noter que lorsque vous charger une classe et que vous créer des objets, toutes les propriétés et méthodes associées sont accessible via l'auto complétion. Les classes écrites en Powershell sont une nouveauté et il reste encore des améliorations à réaliser :

• l'héritage des classes.
• la portée sur les propriétés : en Powershell, elles sont toutes publiques et donc accessible/modifiable depuis n'importe quel endroit dans un script. Changer la portée permettrait de spécifier des propriétés qui ne seraient accessibles que dans une méthode de la classe.

Introduction

Powershell 5.0 est encore en beta mais de nombreuses nouveautés sont déjà présentes. Nous allons aborder dans cet article quelques unes d'entres elles. Elles peuvent concerner : Powershell, son éditeur (Powershell ISE) ou encore son paramétrage dans Windows. Certaines avaient déjà été évoquées dans l'article suivant lors de la première preview de Powershell 5.0 :
http://blog.piservices.fr/post/Powershell-V5-Preview-est-sorti-!-DSC-Switch-OneGet-et-du-chocolat.aspx

NB : Contrairement à la première beta, Powershell 5.0 est dorénavant disponible pour Windows 2012 et supérieur (qui n’était compatible qu’avec Windows 2012 R2 et supérieur). Le lien suivant vous mènera à la dernière beta sortie (Novembre 2014) :

http://www.microsoft.com/en-us/download/details.aspx?id=44987

Gestion des Archives

Un nouveau module permettant de gérer nativement les archives apparaît dans Powershell 5.0. Cette option n'était auparavant disponible qu'au travers de module réalisé par la communauté. Ce dernier permet de générer des archives (Compress-Archive) ou de les extraire (Expand-Archive). Seul le format Zip est actuellement géré. Un paramètre nommé “update” permet de mettre à jour une archive existante en ajoutant seulement les nouveaux fichiers et les changements sur les fichiers déjà présents dans l'archive. Le paramètre “path” peut définir un ou plusieurs fichiers ainsi qu'un dossier entier en utilisant le caractère “*” (wildcard). Enfin le paramètre “CompressionLevel” permet d'influencer le taux de compression et la taille finale de l'archive.

Support des raccourcis claviers

La console Powershell supporte désormais certains raccourcis clavier : copier (CTRL+C), coller (CTRL+V), tout sélectionner (CTRL+A).

Gestion des liens symboliques

Il est dorénavant possible de créer/supprimer des raccourcis via Powershell. Cette fonctionnalité est incluse dans la commande New-Item en spécifiant le type “SymbolicLink”.

Création d'un raccourci vers un fichier

Création d'un raccourci vers un dossier

On peut aussi lister des fichier via la commande Get-ChildItem en passant par un raccourci !

Event Viewer

Un nouveau journal de log est apparu dans l'observateur d'événements. Par défaut, ce dernier enregistre les lancements de console Powershell et les erreurs générales comme un échec de chargement de module. Ce nouveau journal est situé dans Applications and Services Logs\Microsoft\Windows\PowerShell\Operational. Il peut aussi enregistrer les exécutions de code Powershell. Cette fonctionnalité s'active via GPO.

Attention : Activer l'utilisation de ce journal pour les exécutions de code est très verbeux. Néanmoins cela peut être très utile pour obtenir rapidement des traces d'actions effectuées sur des serveurs via Powershell.

Il est possible d'activer cette fonctionnalité via GPO (voir paragraphe ci-dessous).

GPO

Les modèles d'administration possède désormais un ADMX permettant de gérer quelques paramètres Powershell. Ce dernier est situé dans Administrative Templates / Windows Components / Windows PowerShell. Il serait compatible avec les systèmes d'exploitation de la famille Windows 7 / Windows 2008 et supérieur (je ne l'ai personnellement testé que sur Windows 10 Server Technical Preview). Cette nouveauté n'est donc pas totalement liée à Powershell 5.0 puisqu'elle sera fonctionnelle sur les anciennes versions de Powershell.

Les paramètres configurables sont les suivants :

• Activer les traces dans l'observateur d'événements pour tout exécution de script.
• Activer les traces dans l'observateur d'événements pour les exécutions de module Powershell (il faut préciser les modules concernés).
• Définir la politique d'exécution des scripts (Set-ExecutionPolicy). Il s'agit d'une très bonne nouvelle car il n'existait pas de solution pour généraliser ce paramètre sur un grand nombre de serveur hormis en passant par une ressource DSC (ce qui représente un déploiement beaucoup plus lourd).
• Activer automatique du transcript : cela permet de ne pas avoir à lancer la commande “start-transcript”. Il est également possible de définir le chemin où doit être stocké le transcript. Par défaut le nom du fichier est horodaté, contient le nom de l'ordinateur et est stocké dans le répertoire “Mes documents” de l'utilisateur de la session Powershell.
• Définir la source de l'aide Powershell. Depuis Powershell 3.0, l'aide des cmdlets n'est pas entièrement incluse avec le package d'installation Powershell. Il est nécessaire d'utiliser la commande “Update-Help” pour la mettre à jour (par défaut, elle est récupéré depuis internet). Cela permet entre autre de récupérer l'aide avec la langue qui nous intéresse. Grâce à ce paramètre, on peut dorénavant spécifier une source comme un partage de fichier. Néanmoins, l'utilisateur a toujours la possibilité de changer le comportement en indiquant lui même une valeur lors de l'exécution de la commande via le paramètre “SourcePath”.

Tous ces paramètres sont disponibles dans la configuration ordinateur et utilisateur de la GPO.

Transcript

La génération de transcript n'était jusqu'à présent fonctionnelle que dans la console Powershell. Grâce aux cmdlets “Start-Transcript” / “Stop-Transcript”, il est désormais possible de générer des fichiers de traces aussi via Powershell ISE.

Powershell ISE avec Powershell 4 :

Powershell ISE avec Powershell 5 :

PSEdit

Une nouveauté fait son apparition dans Powershell ISE et le PSRemoting : PSEdit. Cet outil existait déjà et permettait d'ouvrir script dans un nouvel onglet dans Powershell ISE lorsque l'on exécutait la commande suivante : PSEdit chemin_de_mon_script.

Cependant, dans cette nouvelle version de Powershell ISE, il est possible d'ouvrir des fichiers à distances. Il n'y a donc plus besoin d'ouvrir Powershell ISE sur la machine où se trouve le script pour l'éditer. Il suffit d'ouvrir une PSSession puis d'exécuter PSEdit.

Cette fonctionnalité est facilement testable même en local en simulant une session distante :

Il n'y a pas besoin de connaître le chemin exact du script puisque l'auto complétion est disponible pour le retrouver.

Enumérations

La dernière nouveauté expliquée dans cet article est plus orientée scripting. Les énumerations font leurs apparitions dans Powershell. Pour cela un nouveau mot clé est disponible : “enum”. Celles-ci vont nous permettre de réaliser plus rapidement de la validation de paramètres.

Prenons le cas du paramètre ErrorAction disponible sur toutes les commandes Powershell. Il n'est possible de fournir qu'un certain nombre de valeurs : Continue, Ignore, Inquire, SilentlyContinue, Stop, Suspend. Ceux-ci correspondent à une énumération.

La syntaxe d'une énumération est la suivante : Pour utiliser cette dernière dans une fonction :

Nous pouvons remarquer que les choix disponibles sont proposés par le système d'auto complétion.

Enfin, si l'on souhaite récupérer les valeurs d'une énumération, il faut exécuter la commande suivante :

Conclusion

Powershell 5.0 et Windows 10 sont riches en nouveautés pour le langage de scripting de Microsoft. Certaines d'entre elles n'ont pas été abordées mais feront l'objet d'articles dédiées :

• La création de classes d'objets personnalisés.
• Les améliorations de Desired State Configuration comme la gestion des configurations partielles permettant de segmenter celles-ci en plusieurs fichiers (exemple : par fonctionnalité).
• PowershellGet : à l'instar de OneGet qui permet de récupérer des packages, ce dernier offre la possibilité de récupérer des modules depuis internet ou depuis sa propre source. Ainsi, une société peut créer sa bibliothèque de modules Powershell.

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.