Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Powershell 5.0 : Les classes

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”.

ERROR PROPERTY TYPE

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 :

ERROR CONSTRUCTOR 

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 :

EXEMPLE METHOD

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 :

EXEMPLE STATIC

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.

Powershell 5.0 : découvertes de quelques nouveautés

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.

 

Zip module

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.

Administrative Template 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 transcript v4

Powershell ISE avec Powershell 5 :

Powershell ISE transcript v5

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 :

PSEdit Remote file

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.

EnumEnfin, 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.

Retour d’expérience : Migration d’un tenant Office 365 Partie 1

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

L’entreprise dans laquelle a été réalisée cette migration utilise les services suivants :
  • 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.

1

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.

Tout d’abord il faut se connecter au tenant via la commande :

Il faut s’authentifier avec un compte ayant le rôle Administrateur général.
L’étape suivante consiste à définir le serveur ADFS sur lequel le décomissionnement de la fédération sera effectuée.

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

La conversion du domaine est réalisée via la commande Powershell ci-dessous :

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.

2

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

3

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

4

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.

On peut définir un nouvel UPN avec ces quelques lignes de scripts Powershell :

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.

5

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.”

6

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.”

7 bis

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

Pour activer la nouvelle fédération, il faut  lancer les commandes Powershell suivantes dans une invite de commande connecté au tenant Office 365 :

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).

8

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.

 9

10

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).

Ensuite, il faut poursuivre l’installation via Powershell :

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.

11

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

12

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

13 14

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.

15

La synchronisation peut être lancée via les commandes Powershell suivantes :

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.