Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

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.

PowerShell : Création Rapport HTML basé sur 2 colonnes Serveurs et Nom de Ville

 

 

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

image