DEV Community: Laurent LIENHARD

La validation des paramètres dans une fonction PowerShell

Laurent LIENHARD — Thu, 21 Apr 2022 09:56:53 +0000

La validation des paramètres

Dans cette article nous allons parler d'une option disponible dans Powershell : la validation des paramètres

Cette option a pour but, comme son nom l'indique, de valider qu'un paramètre passé à une fonction est bien celui que l'on attends.

Tout au long de cette article nous garderons le script suivant comme fil conducteur.

function Do-SomeThing {
    [CmdletBinding()]
    param (
        [String[]]$ComputerName,
        [Int]$Age
    )

    begin {
        #La valeur de computername ne doit pas être nul ou vide
        if (($null -eq $ComputerName) -or ($ComputerName -eq "")) {
            throw "La valeur de ComputerName ne peut pas être vide ou null"
        }
        #Test pour vérifier que le nom du computer ne dépasse pas 13 caractères
        If ($ComputerName.Length -gt 13) {
            Throw "Le nom du Computer ne doit pas dépasser 13 caractères"
        }

        #L'age de l'ordinateur doit-être compris entre 5 et 10 ans
        if (!(($Age -gt 5) -and ($Age -lt 10))) {
            throw "l'age doit-être compris entre 5 et 10 ans"
        }

    }

    process {
    }

    end {
    }
}

[ValidateNotNullOrEmpty()] and [ValidateNotNull()]

ValidateNotNull : vérifie uniquement si la valeur transmise au paramètre est une valeur null. Cela fonctionnera toujours s'il est passé une chaîne vide.

ValidateNotNullOrEmpty : vérifie également si la valeur transmise est une valeur null et s'il s'agit d'une chaîne ou d'une collection vide

Dans notre exemple nous pouvons remplacer le test suivant

if (($null -eq $ComputerName) -or ($ComputerName -eq "")) {
    throw "La valeur de ComputerName ne peut pas être vide ou null"
}

en modifiant simplement la déclaration de notre variable $ComputerName

Param (
    [ValidateNotNullOrEmpty()]
    [String[]]$ComputerName
)

[ValidateLength()]

Cette validation permet de définir une taille minimale et maximale attendue pour un paramètre.

Dans notre exemple nous voulons que le paramètre ComputerName fasse minimum 1 caractère et au maximum 13 caractères.

Nous pouvons donc remplacer le test :

    If ($ComputerName.Length -gt 13) {
        Throw "Le nom du Computer ne doit pas dépasser 13 caractère"
    }

par la déclaration de paramètre suivant :

Param (
    [ValidateLength(1,13)]
    [String[]]$ComputerName
)

Mais attendez ! Nous avions déjà modifié la déclaration de ce paramètre précédemment pour ajouter [ValidateNotNullOrEmpty()] ?

Effectivement les validations des paramètres peuvent être cumulées.
Dans notre cas nous déclarons le paramètre de cette façon :

    param (
        [ValidateNotNullOrEmpty()]
        [ValidateLength(1,13)]
        [String[]]$ComputerName
    )

ComputerName ne doit-être ni Null, ni vide et doit faire entre 1 et 13 caractères.

[ValidateRange()]

C'est en quelque sorte le pendant de [ValidateLength()] mais pour les chiffres.
Comme pour [ValidateLength()], il permet de définir une valeur minimale et maximale que peut prendre un paramètre.

Dans notre exemple l'age du PC doit-être compris entre 5 et 10 ans.
Nous avions donc le test suivant :

    if (!(($Age -gt 5) -and ($Age -lt 10))) {
        throw "l'age doit-être compris entre 5 et 10 ans"
    }

nous pouvons donc remplacer ce test par :

param (
    [ValidateRange(5,10)]
    [int]$Age
    )

[ValidateCount()]

Comme pour ValidateRange() il permet de définir le nombre minimal et le nombre maximal d'objet que peux prendre une collection passée en paramètre.

    param (
        [ValidateNotNullOrEmpty()]
        [ValidateLength(1,13)]
        [ValidateCount(1,3)]
        [String[]]$ComputerName
    )

Dans notre exemple le paramètre ComputerName ne doit-être ni Null, ni vide, doit faire entre 1 et 13 caractères et nous ne pouvons passer que 1 à 3 objects dans la collection.

[ValidateSet()]

Cette validation permet de fournir une liste de réponse possible pour la valeur du paramètre.

Cette validation peut-être rendu Case Sensitive, si à la fin de la déclaration, la valeur ignorecase est définie à $False

le test de validation suivant

        #Être sur que la valeur est l'une de celle que je veux
        if("SIEGE","AGENCE","STOCK" -notcontains $Site) {
            throw "Le site doit-être SIEGE,AGENCE ou STOCK"
        }

peut-être remplacer par la déclaration de la variable Site suivante

    param (
        [ValidateSet("SIEGE","AGENCE","STOCK",ignorecase=$true)]
        [String]$Site
    )

Dans notre exemple, la paramètre ne peut prendre qu'une des 3 valeurs définies.

Nous avons également demandé à ce que le valeur du paramètre ne soit pas Case
Sensitive donc SIEGE, Siege, sieGE sont toutes des valeurs corrects.

[ValidatePattern()]

Permet d'utiliser une expression régulière (REGEX) avant de tester la valeur d'un paramètre.

Dans notre script, nous avins le test suivant

        #Test pour savoir si le ComputerName correspond la nomenclature de l'entreprise
        if ($ComputerName -notmatch "^SRV-\D{6}\d{3}$") {
            Throw "Le ComputerName doit-être sous la forme SRV-LETTRE(6)CHIFFRE(3)"
        }

Nous voulons donc être sur que le paramètre ComputerName soit toujours sous la forme d'un string commençant par SRV- suivi de 6 lettres et de 3 chiffres.

Nous pouvons remplacer ce test par la validation

    param (
        [ValidateNotNullOrEmpty()]
        [ValidateLength(1,13)]
        [ValidateCount(1,3)]
        [ValidatePattern('^SRV-\D{6}\d{3}$')]
        [String[]]$ComputerName
    )

[ValidateScript()]

Cette validation permet de définir un script qui va être executer pour valider la valeur du paramètre.

Notre test pour valider l'existence du chemin

        #Savoir si le chemin passé en paramètre existe et est un répertoire
        IF (!(Test-Path $Path -PathType ‘Container’))
        {
            Throw "$($Path) n'est pas un dossier valide"
        }

peut-être remplacer par la validation suivante

    param (
        [ValidateScript(
            {IF (!(Test-Path -Path $_)) {
                Throw "$($Path) n'est pas un dossier valide"
            } else {
                $true
            }
            }
        )]
        [String]$Path
    )

Comme vous pouvez l'imaginer, le script peut-être quelque chose de plus compliqué qu'un simple test comme ici.

Conclusion

Pour conclure nous pouvons comparer simplement nos 2 versions de script.

Le script d'origine

function Do-SomeThing {
    [CmdletBinding()]
    param (
        [String[]]$ComputerName,
        [Int]$Age
    )

    begin {
        #La valeur de computername ne doit pas etre nul ou vide
        if (($null -eq $ComputerName) -or ($ComputerName -eq "")) {
            throw "La valeur de ComputerName ne peut pas être vide ou null"
        }
        #Test pour vérifier que le nom du computer ne dépasse pas 13 caractères
        If ($ComputerName.Length -gt 13) {
            Throw "Le nom du Computer ne doit pas dépasser 13 caractères"
        }

        #L'age de l'ordinateur doit-être compris entre 5 et 10 ans
        if (!(($Age -gt 5) -and ($Age -lt 10))) {
            throw "l'age doit-être compris entre 5 et 10 ans"
        }

    }

    process {
    }

    end {
    }
}

Le script final

function Do-SomeThing {
    [CmdletBinding()]
    param (
        [ValidateNotNullOrEmpty()]
        [ValidateLength(1,13)]
        [ValidateCount(1,3)]
        [ValidatePattern('^SRV-\D{6}\d{3}$')]
        [String[]]$ComputerName,
        [ValidateScript({IF (!(Test-Path -Path $_)) {
            Throw "$($Path) n'est pas un dossier valide"
        } else {
            $true
        }
        })]
        [String]$Path,
        [ValidateSet("SIEGE","AGENCE","STOCK",ignorecase=$true)]
        [String]$Site,
        [ValidateRange(5,10)]
        [int]$Age
    )

    begin {
    }

    process {
    }

    end {
    }
}

Nous constatons assez clairement que nous avons diminué les lignes de code nécessaire pour valider les paramètres et de ce fait simplifier la compréhension du script.

Utiliser des jeux de paramètres pour simplifier les commandes PowerShell

Laurent LIENHARD — Thu, 21 Apr 2022 09:52:21 +0000

Définition

Les jeux de paramètres permettent de définir un ensemble de paramètre qui doivent être utiliser par une fonction.

Cela permet par exemple de définir pour une même fonction 2 paramètres différents en entrée. Dans cette article nous allons voir comment, par exemple, faire une fonction New-MyADUser avec comme paramètre soit un ensemble de nom soit un fichier.

Fonction avec utilisateur en entrée

Cette fonction est assez basique. Elle va prendre en paramètre d'entrée une liste de nom d'utilisateur a créer.

function New-MyADUser {
    param (
        [System.String[]]$UserName
    )

    foreach($User in $UserName) {
        New-ADUser -Name $User -GivenName ($User.Split(".")[0]) -Surname ($User.Split(".")[1])
    }

}

Ensuite je peux lancer la création de mes utilisateurs

New-MyADUser -UserName "Utilisateur1.Test","Utilisateur2.Test","Utilisateur3.Test"

Fonction avec un fichier en entrée

Dans ce cas nous allons reprendre la même fonction mais avec en entrée la liste des noms dans un fichier csv.

function New-MyADUser {
    param (
        [System.String]$FileName
    )

    $UserName = Import-Csv -Path $FileName

    foreach ($User in $UserName) {
        New-ADUser -name $User.UserName -GivenName ($User.UserName.Split(".")[0]) -Surname ($User.UserName.Split(".")[1])
    }

}

Ensuite je peux lancer la création de mes utilisateurs

New-MyADUser -FileName '.\Utiliser les Parameter Sets\Utilisateurs.csv'

Donc maintenant nous avons 2 fonctions différentes mais qui font sensiblement la même chose : créer des utilisateurs dans l'Active Directory

C'est la que rentre en jeu les jeux de paramètres. Nous allons immédiatement voir ca :-)

Fonction avec un fichier ou un utilisateur en entrée

ParameterSetName

Le but donc est de combiner ces 2 fonctions en une seule mais acceptant les 2 types de paramètre en entrée.

function New-MyADUser {
    [CmdletBinding(DefaultParameterSetName = "ByUserName")]
    param (
        [Parameter(ParameterSetName='ByUserName')]
        [System.String[]]$UserName,
        [Parameter(ParameterSetName = 'ByFileName')]
        [System.String]$FileName
    )
}

Première étape je combine les 2 paramètres en leur affectant un nom de jeux de paramètres (ParameterSetName).

Pour ce faire vous avez du remarquer l'ajout de CmdletBinding. Pour pouvoir utiliser la commande ParameterSetName il faut passer par une fonction avancée

Naturellement il faut donner un nom différent au 2 jeux de paramètres pour pouvoir, plus tard les différencier.

Si je fais

▶ Get-Command -Name New-MyADUser -Syntax

New-MyADUser [-UserName <string[]>] [<CommonParameters>]
New-MyADUser [-FileName <string>] [<CommonParameters>]

On peut voir que j'ai bien 2 façons d'appeler ma fonction avec le Username ou le FileName les 2 étant exclusif c'est a dire que je ne peux pas faire

▶ New-MyADUser -UserName $UserName -FileName $FileName

New-MyADUser : Parameter set cannot be resolved using the specified named parameters.
At line:1 char:1
+ New-MyADUser -UserName $UserName -FileName $FileName
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [New-MyADUser], ParameterBindingException
    + FullyQualifiedErrorId : AmbiguousParameterSet,New-MyADUser

La commande ne peut pas trouver quel jeu de paramètre elle doit executer.

Bon maintenant que je peux appeler ma fonction avec les 2 types de paramètre comment faire dans la fonction pour traiter chacun des paramètres.

$PSCmdlet.ParameterSetName

Grâce a cette ligne de commande nous pouvons récupérer le nom du jeu de paramètre utilisé, ByUserName ou ByFileName dans notre cas, et grâce a cela faire un traitement différent selon le paramètre passé à la fonction.

Ajoutons cette ligne de commande a notre fonction

function New-MyADUser {
    [CmdletBinding(DefaultParameterSetName = "ByUserName")]
    param (
        [Parameter(ParameterSetName='ByUserName')]
        [System.String[]]$UserName,
        [Parameter(ParameterSetName = 'ByFileName')]
        [System.String]$FileName
    )

    $PSCmdlet.ParameterSetName
}

Si je fait New-MyADUser -Username "Utilisateur.Test"

le résultat sera

New-MyADUser -UserName "Utilisateur.test"

ByUserName

Si je fait New-MyADUser -FileName ".\Utiliser les Parameter Sets\Utilisateurs.csv"

le résultat sera

▶ New-MyADUser -FileName ".\Utiliser les Parameter Sets\Utilisateurs.csv"

ByFileName

Effectivement le paramètre UserName fait bien parti du jeu de paramètre ByUserName et FileName du jeu de paramètre ByFileName

Ok donc maintenant nous savons différencier les 2 cas grâce à $PSCmdlet.ParameterSetName. Il ne nous reste plus qu'a effectuer le traitement adéquat en fonction du cas.

Pour ce faire nous allons simplement ajouter une commande switch dans notre fonction et copier le contenu de nos 2 fonctions précédentes

function New-MyADUser {
    [CmdletBinding(DefaultParameterSetName = "ByUserName")]
    param (
        [Parameter(ParameterSetName='ByUserName')]
        [System.String[]]$UserName,
        [Parameter(ParameterSetName = 'ByFileName')]
        [System.IO.DirectoryInfo]$FileName
    )

    switch ($PSCmdlet.ParameterSetName) {
        "ByUserName" {
            $PSCmdlet.ParameterSetName
            foreach ($User in $UserName) {
                New-ADUser -name $User -GivenName ($User.Split(".")[0]) -Surname ($User.Split(".")[1])
            }
         }
        "ByFileName" {
            $PSCmdlet.ParameterSetName
            $UserName = Import-Csv -Path $FileName
            foreach ($User in $UserName) {
                New-ADUser -name $User.UserName -GivenName ($User.UserName.Split(".")[0]) -Surname ($User.UserName.Split(".")[1])
            }
         }
    }
}

Cette fonction pourrait encore être simplifiée mais ce n'est pas l'objet de cet article

Voilà comment faire pour l'utilisation des jeux de paramètres

Si vous avez des questions ou ...

Attendez ! je suis sur que vous vous en posez une dès à présent !

Si! Si!

Vous savez la fameuse question : Comment je fais si un paramètre doit faire parti des 2 jeux de paramètres en même temps ?

Nous allons tenter d'y répondre ;-)

Un paramètre dans plusieurs jeux de paramètres

Bon la plus logique des approches si vous avez compris le principe serait de faire

function New-MyADUser {
    [CmdletBinding(DefaultParameterSetName = "ByUserName")]
    param (
        [Parameter(ParameterSetName = 'ByUserName')]
        [System.String[]]$UserName,
        [Parameter(ParameterSetName = 'ByUserName')]
        [System.String]$Password,
        [Parameter(ParameterSetName = 'ByFileName')]
        [System.IO.DirectoryInfo]$FileName,
        [Parameter(ParameterSetName = 'ByFileName')]
        [System.String]$Password
    )
}

mais l'execution de ce code retourne l'erreur

Duplicate parameter $Password in parameter list.
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : DuplicateFormalParameter

Donc on ne peut pas mettre 2 fois le même nom de paramètre !

Soit! Je ne peux pas définir 2 paramètres identiques dans 2 jeux de paramètre distinct, mais est-ce que je peux définir 1 paramètre qui sera disponible dans les 2 jeux ?

et si on essayait cela

function New-MyADUser {
    [CmdletBinding(DefaultParameterSetName = "ByUserName")]
    param (
        [Parameter(ParameterSetName = 'ByUserName')]
        [System.String[]]$UserName,
        [Parameter(ParameterSetName = 'ByFileName')]
        [System.IO.DirectoryInfo]$FileName,

        [Parameter(ParameterSetName = 'ByUserName')]
        [Parameter(ParameterSetName = 'ByFileName')]
        [System.String]$Password
    )
}

Déjà l'execution de ce code ne retourne pas d'erreur : un bon point !

Regardons la syntaxe de la fonction maintenant

Get-Command -Name New-MyADUser -Syntax

New-MyADUser [-UserName <string[]>] [-Password <string>] [<CommonParameters>]
New-MyADUser [-FileName <DirectoryInfo>] [-Password <string>] [<CommonParameters>]

Le paramètre password se retrouve bien dans les 2 jeux de paramètres : VICTOIRE !

En extrapolant un peu, on peu s'imaginer avoir plusieurs jeux de paramètres pour une fonction. il semble évident que cela va être compliqué de mettre un paramètre dans tous les jeux de paramètres de cette façon.

Et si pour simplifier nous le mettions tous simplement dans aucun !

function New-MyADUser {
    [CmdletBinding(DefaultParameterSetName = "ByUserName")]
    param (
        [Parameter(ParameterSetName = 'ByUserName')]
        [System.String[]]$UserName,
        [Parameter(ParameterSetName = 'ByFileName')]
        [System.IO.DirectoryInfo]$FileName,

        [System.String]$Password
    )
}

Le résultat est le suivant :

Get-Command -Name New-MyADUser -Syntax


New-MyADUser [-UserName <string[]>] [-Password <string>] [<CommonParameters>]

New-MyADUser [-FileName <DirectoryInfo>] [-Password <string>] [<CommonParameters>]

Le paramètre password est toujours membre des 2 jeux de paramètre.

Il suffit donc de n'affecter un paramètre a AUCUN jeux de paramètres pour qu'il soit commun à TOUS les jeux de paramètres.

Conclusion

Nous avons donc vu dans cet article :

Qu'est-ce que c'est qu'un jeu de paramètres
A quoi sert un jeu de paramètres
Comment affecter un paramètre à plusieurs jeux de paramètres
Comment affecter un paramètre a tous les jeux de paramètres

Si vous avez des questions, si je me suis trompé sur un point ou simplement échanger avec moi n'hésitez pas à me contacter sur les réseaux sociaux.

Montre moi ton profile !

Laurent LIENHARD — Thu, 21 Apr 2022 09:36:39 +0000

Information

Cette article a été rédigé pour une présentation du French Powershell UserGroup.

Cette présentation peut-être vu sur Youtube sur la chaîne du FRPSUG

C'est quoi un profile ?

Évidement c'est la première question que l'on peut se poser ;-)

Un profile PowerShell est simplement un script :

avec un nom spéciale
qui se trouve dans un répertoire spécial
qui s'execute au démarrage de PowerShell

Le (ou plutôt les) profile sert à customiser votre environnement :

ajouter des alias
ajouter des fonctions
connecter des drive
...

Les différents types de profile

Dans le point précédent, je fais allusion à plusieurs profiles, effectivement il existe un profile pour chaque hôte :

Windows Powershell
Powershell (core)

mais il y a également une profile qui s'applique à tous les hôtes

Comme pour les profiles d'hôte, Il existe un profile pour tous les utilisateurs d'une machine ou pour l'utilisateur courant.

Donc en résumé un profile s'applique :

à l'hôte actuellement utilisé (CurrentHost) ou à tous les hôtes (AllHosts)
à l'utilisateur actuellement connecté (CurrentHost) ou à tous les utilisateurs (AllUsers)

Les combinaisons possibles sont donc :

* AllUsers, AllHosts
* AllUsers, CurrentHost
* CurrentUser, AllHosts
* CurrentUser, CurrentHost

L'ordre ci-dessus n'est pas anodin, il s'agit de l'ordre dans lequel les profiles sont chargés au démarrage d'une console

Pour adresser ces différents profiles on utilise la variable $PROFILE de la façon suivante :

* AllUsers, AllHosts       => $PROFILE.AllUsersAllHosts
* AllUsers, CurrentHost    => $PROFILE.AllUsersCurrentHost
* CurrentUser, AllHosts    => $PROFILE.CurrentUserAllHosts
* CurrentUser, CurrentHost => $PROFILE.CurrentUserCurrentHost

Par défaut quand on parle de la variable $PROFILE on parle de la variable $PROFILE.CurrentUserCurrentHost

Chaque combinaisons est stocké dans un répertoire particulier (cas de Windows PowerShell et PowerShell Core) :

* $PROFILE.AllUsersAllHosts       => $PSHOME\Profile.ps1
* $PROFILE.AllUsersCurrentHost    => $PSHOME\Microsoft.PowerShell_profile.ps1
* $PROFILE.CurrentUserAllHosts    => $Home\[My]Documents\PowerShell\Profile.ps1
* $PROFILE.CurrentUserCurrentHost => $Home\[My]Documents\PowerShell\Microsoft.PowerShell_profile.ps1

$PSHOME fait allusion au repertoire d'installation de PowerShell : C:\Windows\System32\WindowsPowerShell\v1.0
pour Windows PowerShell C:\Program Files\PowerShell\7-preview pour PowerShell Core

Dans le cas des autres environnements (ISE, VSCode) les chemins sont identiques mais les noms de fichiers peuvent être différent

Comment créer un profile ?

La première étape est de vérifier si un fichier profile n'est pas déjà existant

Test-Path -Path $PROFILE
False

Si le résultat est False, il suffit de créer le fichier

New-Item -ItemType File -path $PROFILE -force

Ensuite il suffit de l'éditer avec n'importe quel éditeur de texte (notepad, notepad++, VSCode)

notepad $PROFILE

Mais on mets quoi dans un profile ?

Comme nous l'avons vu le profile PowerShell est un script comme les autres. Nous pouvons donc y mettre tous ce qui peut se trouver dans un script "normal"

Par exemple dans le profile $PROFILE.AllUsersAllHosts sur ma machine j'ai cette fonction

#region <Admin or Not>
function IsAdmin
{
    $CurrentUser =
    [System.Security.Principal.WindowsIdentity]::GetCurrent()
    $principal = New-Object System.Security.principal.windowsprincipal($CurrentUser)
    $principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)
}

# Personalized greeting
#
if (isAdmin)
{
    $ElevationMode = 'Privilegie'
    $host.UI.RawUI.BackGroundColor = 'DarkRed'
    Clear-Host
}
else
{
    $ElevationMode = 'Non Privilegie'
    #$host.UI.RawUI.BackGroundColor = 'DarkMagenta'
    Clear-Host
}

$CurrentUser =


Write-Host '+---------------------------------------------------+'
Write-Host ("+- Bonjour {0} " -f ($CurrentUser.Name).split('\')[1])
Write-Host '+---------------------------------------------------+'
#endregion <Admin or Not>

Cette fonction permet d'afficher dans le titre de la fenêtre quand je lance la console en administrateur

ou en utilisateur normal

j'ai également une fonction d'installation de module

$private:AutoLoad = @{
    Modules = @(
        'Plaster',
        'Psake',
        'PSDepend',
        'PSDeploy'
    )
}

Write-Host "=> loading modules from AllUsersAllHosts"
Foreach ($private:M in $AutoLoad.Modules)
{
    if (!(Get-Module -ListAvailable -Name $m))
    {
        Write-Warning "$($m) not found => installation launch "
        Install-Module -Name $m -AllowClobber -Force -ErrorAction SilentlyContinue -Scope CurrentUser
    }
}

Il s'agit de module que j'utilise pour la compilation de mes builds lorsque je code.

Pour plus d'exemple sur les profiles vous pouvez faire une recherche google.

Credential : How to use them ?

Laurent LIENHARD — Fri, 19 Jul 2019 18:06:47 +0000

DISCLAIMER :
This article is translated by myself.
I do this to train but my level of English is not great so I apologize for any mistakes they might have.
If really it's not understandable at all thank you for pointing it out so that I can improve myself ;-)

Information

This article was written for a French Powershell UserGroup presentation.

You can find this presentation on Youtube : FRPSUG Channel

The different ways to use Credential ...

Initial request

Since I started on PowerShell, I very quickly asked the question of the management of credentials in my scripts

From the simple need that may be handled in a basic way to the use of credentials in automatic scripts I looked for the best way to do it.

Processing the request

1. Get-Credential

The easiest way to use credentials is to use the basic PowerShell command

$cred = Get-Credential -Message "Message show in the Popup" -UserName MyUser

the result is

PS > $cred

UserName                           Password
--------                           --------
MyUser System.Security.SecureString

This variable $cred can be used for example in the following command

Enter-PSSession -ComputerName MyComputer -Credential $cred

2. ConvertFrom-SecureString : storage on disk

An another solution, a bit more advanced, is to store password in a file on your computer.

Naturally this storage must be done in a secure way.
As before, the first step is create the $Credobject

$cred = Get-Credential -Message "Message show in the Popup" -UserName MyUser

Second step is store the password in file but encrypted
For this we used the ConvertFrom-SecureStringcommand

$Cred.Password | ConvertFrom-SecureString | Out-File C:\temp\password.txt

In my file c:\temp\password.txt, my password is seen like this

01000000d08c9ddf0115d1118c7a00c04fc297eb0100000057670149ac674a41ad9d185a8a82724b0000000002000000000010660000000100002000000093aaaf1ed598a69bbfb4cc77e81dfeb2786f26db6184538833af18054ef1a8a3000000000e800000000200002000000098c97f4f344d0159f337966d55060ad3297cae7515938457a713ddd9eaac5cdf200000003d986891fb27cb3983f798082083ac734d97d6235a186d3cc43db26f63bd44684000000018620d4739c0a26a6261e8c9867e94605cd35c61090c982999d5bb09fb54ec7d9a3499ebeb304c67720edfa37a34fe7fd4bce8fd8468dbee5081f56c81f4ce46

To use this encrypted password, you must first decrypt it.
For that we will used the ConvertTo-SecureString command
After that, with the decrypted password, we can make a new PSCredential object and use it

$Username = "MyUser"
$SecurePassword = Get-Content c:\temp\password.txt | ConvertTo-SecureString
$Cred = New-Object System.Management.Automation.PSCredential -ArgumentList $Username,$SecurePassword

PS > $cred

UserName                           Password
--------                           --------
MyUser System.Security.SecureString

As in point 1, we have a object $Cred that we can use in the follow script

Enter-PSSession -ComputerName MyComputer -Credential $cred

3. Export-Clixml : storage on disk

The advantage of this method is that you can leverage the versatility of PowerShell to ensure that data is not only exported, but also stored securely using secure strings. It should be noted that these credentials files can only be opened by the same user on the same system.

To create the export file, we will used the Export-Clixml command

get-credential -message "User's Password ?" -UserName MyUser | Export-Clixml -Path "c:\temp\user.xml"

In the file c:\temp\user.xml we can see the following information

<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <Obj RefId="0">
    <TN RefId="0">
      <T>System.Management.Automation.PSCredential</T>
      <T>System.Object</T>
    </TN>
    <ToString>System.Management.Automation.PSCredential</ToString>
    <Props>
      <S N="UserName">MyUser</S>
      <SS N="Password">01000000d08c9ddf0115d1118c7a00c04fc297eb0100000057670149ac674a41ad9d185a8a82724b00000000020000000000106600000001000020000000dadd8864c9b930a2eb07a6745ac4fb5711912c318c401f7e35bb91d4d1cc180b000000000e8000000002000020000000b5a862ba266c236357445b773ca38d73ed124cf82d863ac4c11e2b48d57fca4b2000000054180930ba9fd53a6c4bdd9d7f69c044c88072b0d411486bccc1ca3cca417bf440000000d6197eafe8a133235bd1b44e376c3ff02e94da9f39b7d24b9a68ef5dbd629e44180ce15c3e67830d758fa1296f60a98cb2371ef915990c921e728f44c72c4cbd</SS>
    </Props>
  </Obj>
</Objs>

To use this information, we must use the reverse command Import-Clixml

 $Cred = Import-Clixml -Path "c:\temp\user.xml"

again we are recovering an object $Cred

PS > $cred

UserName                           Password
--------                           --------
MyUser System.Security.SecureString

Today my preference is the third solution with the use of XML files

La portée des variables

Laurent LIENHARD — Thu, 18 Jul 2019 19:32:15 +0000

Information

Cette article a été rédigé pour une présentation du French Powershell UserGroup.

Cette présentaton peut-être vu sur Youtube sur la chaine du FRPSUG

La portée des variables en Powershell

Plusieurs scopes sont possibles pour l'utilisation des variables en fonctions du besoin

Quelques régles de base :

Un élément que vous incluez dans une étendue est visible dans l'étendue dans laquelle il a été créé et dans toute étendue enfant, à moins que vous ne le rendiez explicitement privé
Si vous créez un élément dans une étendue et que l'élément partage son nom avec un élément d'une autre étendue, l'élément d'origine peut être masqué sous le nouvel élément. Mais, il n'est pas remplacé ou modifié.

Attention à la fin de l'article nous parlerons d'un cas particulier se présentant dans les modules PowerShell.

Global

les variables de ce type ce déclare le facon suivante :

$global:MaVariable

Les variables définies dans ce scope on une visibilité étendue à TOUS les scripts qui s'executent à ce moment là mais aussi après leur fin d'execution.

Prenons un script qui ne fait que définir une variable globale MaVariable

$Global:MaVariable = "Mon Numéro de carte bancaire :-) "

Lancons ensuite un second script avec une fonction qui va lire cette variable (noté bien que le script précédent est terminé)

function DoSomething {
    Clear-Host
    Write-Output "Je suis dans DoSomething !"
    Write-output $Global:MaVariable
}

DoSomething

Le résultat est

Je suis dans DoSomething !
Mon Numéro de carte bancaire :-)

Cette variable va continuer d'exister tant que vous ne quittez pas le context Powershell dans lequel vous l'avez créée.

Par exemple les variables présentent au démarrage de Powershell, telles que les variables automatiques et les variables de préférences, sont dans cette étendue afin de pouvoir être utilisées partout.

Local

La portée Local est la portée par défaut, une variable sans modificateur est créée ou référencée
dans la portée Local. Sont considérées comme des variables locales celles qui ne précisent pas de
modificateur et celles qui précisent le modificateur Local ou Private.

Vous trouverez un exemple dans le point suivant sur le scope Script

Script

les variables de ce type ce déclare de la facon suivante :

$script:MaVariable

C'est une étendue créée lors de l'execution d'un script et qui disparait avec la fn de l'execution du script.

Les variables définies dans ce scope sont visibles que dans le script et pendant l'execution du script.

function DoSomething {
    $Script:MaVariable = "Créée dans le scope script"
    $MaVariable1 = "Créée dans le scope de la fonction"
    Clear-Host
    Write-Output "Je suis dans la fonction"
    $Script:MaVariable
    $MaVariable1
}

DoSomething

Write-Output "Je suis dans le script"
$Script:MaVariable
$MaVariable1

Le résultat est

Je suis dans la fonction
Créée dans le scope script
Créée dans le scope de la fonction
Je suis dans le script
Créée dans le scope script

La Variable


 est une variable locale à la fonction

 ```DoSomething```

 elle n'est donc pas visible dans l'étendue du script contrairement à la variable

 ```$Script:MaVariable```



## Private



```powershell
$private:MaVariable

Les éléments dans la portée privée ne peuvent pas être vus en dehors de la portée actuelle. Vous pouvez utiliser une portée privée pour créer une version privée d'un élément portant le même nom dans une autre portée.

$MaVariable = "mon adresse mail !"

function DoSomething {
    $Private:MaVariable = "Mon numéro de CB !"

    function DoSomething2 {
        Write-Output "je suis dans DoSomething2 et MaVariable vaut $MaVariable"
    }
    DoSomething2
}
DoSomething

Le résultat est

je suis dans DoSomething2 et MaVariable vaut mon adresse mail !

Du fait que la variable $MaVariable dans la fonction DoSomething le soit en tant que private, elle n'est pas visible dans la fonction DoSomething2 qui utilise donc la variable $MaVariable défini au début du script dans le scope Local

Numeroted

Vous pouvez faire référence à des portées par leur nom ou par un numéro décrivant la position relative d’un champ à l’autre.

La portée 0 représente la portée actuelle ou locale.

L'étendue 1 indique l'étendue parent immédiate.

L'étendue 2 indique le parent de la portée parent, etc.

Les étendues numérotées sont utiles si vous avez créé de nombreuses étendues récursives.

Prenons le script suivant

Clear-Host
$x = "testvar"

function fun1{
    Write-Output "Fun1"
    Write-Output "L'heritage permet de récupérer la valeur de X dans la fonction Fun1 => $x"
}

fun1

function fun2{
    Write-Output ""
    Write-Output "Fun2"
    Set-Variable -Name x -Value "testvar2" -Scope 0
    Write-Output "la notation scope 0 modifie la valeur de X dans cette fonction => $x"
    Write-Output "La notation Scope 1 permet de récupérer la valeur de la variable dans le parent => $((get-variable -Name X -Scope 1).Value)"
}

fun2

function fun3{
    Write-Output ""
    Write-Output "Fun3"
    Set-Variable -Name x -Value "testvar3" -Scope 1
    Write-Output "la notation scope 1 modifie la valeur de X dans la fonction parent => $x"
    Write-Output "La notation Scope 1 permet de récupérer la valeur de la variable dans le parent => $((get-variable -Name X -Scope 1).Value)"
}

fun3

le résultat est le suivant

Fun1
L'heritage permet de récupérer la valeur de X dans la fonction Fun1 => testvar

Fun2
la notation scope 0 modifie la valeur de X dans cette fonction => testvar2
La notation Scope 1 permet de récupérer la valeur de la variable dans le parent => testvar

Fun3
la notation scope 1 modifie la valeur de X dans la fonction parent => testvar3
La notation Scope 1 permet de récupérer la valeur de la variable dans le parent => testvar3

Cas Particulier : Les modules

Dans le cas des modules il y a une subtilité au niveau des variables dans le scope Script.

Une variable script définie dans un module est accessible par tous les fonctions, scripts composant le module mais également à partir du contexte du script qui a ammené à la création de cette variable.

Cela parait compliquer mais nous allons voir avec un petit exemple de quoi il retourne.

Imaginons le module suivant : Demo5_ModuleScope.psm1

function Set-MrVar {
    $PsProcess = Get-Process -Name PowerShell
}
function Set-MrVarLocal {
    $Local:PsProcess = Get-Process -Name PowerShell
}
function Set-MrVarScript {
    $Script:PsProcess = Get-Process -Name PowerShell
}
function Set-MrVarGlobal {
    $Global:PsProcess = Get-Process -Name PowerShell
}
function Test-MrVarScoping {
    if ($PsProcess) {
        Write-Output $PsProcess
    }
    else {
        Write-Warning -Message 'Variable $PsProcess not found!'
    }
}

Il est assez simple il créé une variable $PsProcess dans les divers scope que nous avons vu précédement.

Pour appeller ce module faisons un petit script : Demo5_ModuleScope.ps1

#Importer le module Demo5_ModuleScope.psm1

#Définition la variable sans contrainte de la portée dans une fonction du module
Set-MrVar

#Vérifiez la valeur de la variable $PsProcess à partir d'une autre fonction du même module
Test-MrVarScoping

#Vérifiez la valeur de la variable $PsProcess à partir de la portée actuelle
$PsProcess

#Définissez la variable sur la portée locale à partir d'une fonction du module.
Set-MrVarLocal

#Vérifiez la valeur de la variable $PsProcess à partir d'une autre fonction du même module
Test-MrVarScoping

#Vérifiez la valeur de la variable $PsProcess à partir de la portée actuelle
$PsProcess

#Set the variable to the script scope from within a function in the module
Set-MrVarScript

#Vérifiez la valeur de la variable $PsProcess à partir d'une autre fonction du même module
Test-MrVarScoping

#Vérifiez la valeur de la variable $PsProcess à partir de la portée actuelle
$PsProcess

#Définissez la variable sur la portée globale à partir d'une fonction du module.
Set-MrVarGlobal

#Vérifiez la valeur de la variable $PsProcess à partir d'une autre fonction du même module
Test-MrVarScoping

#Vérifiez la valeur de la variable $PsProcess à partir de la portée actuelle
$PsProcess

Ce script execute à tour de rôle la création de la variable $PsProcess dans chacun des scopes, et vérifie si la variable est visible dans le contexte du module (psm1) et/ou du script (ps1)

Dans la plupart des cas le scope se comporte exactement comme il le devrait sauf pour le scope Script.

On commence par instancier la variable de scope Script

Set-MrVarScript

Ensuite testons la valeur de cette variable à partir de la fonction Test-MrVarScoping nous sommes donc dans le contexte du module

PS > Test-MrVarScoping

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    599      27    65608      74188       0,83   1580   2 powershell
    783      41   135132     133900       6,59   9564   2 powershell

Logiquement nous avons un retour puisque la variable est dans le scope Script et que la fonction Test-MrVarScoping se trouve également dans le même fichier.

Tentons la même chose dans le contexte du script Demo5_ModuleScope.ps1

PS > $PsProcess

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    599      27    65608      74188       0,83   1580   2 Powershell
    783      41   135132     133900       6,63   9564   2 Powershell

Surprenant :-)

Effectivement bien que définie en tant que script dans le module, la variable $PsProcess est également disponible dans le contexte du script ps1 qui utilise ce module.

Voilà j'espère vous en avoir appris un peu plus sur cette notion de scope de variables en Powershell.

Credential : comment les utiliser ?

Laurent LIENHARD — Thu, 18 Jul 2019 19:10:00 +0000

Information

Cette article a été rédigé pour une présentation du French Powershell UserGroup.

Cette présentaton peut-être vu sur Youtube sur la chaine du FRPSUG

Les différentes façons d'utiliser les credentials…

Demande Initiale

Dès mes débuts sur powershell, je me suis très vite posé la question de la gestion des credentials dans mes scripts

Du besoin simple qui est peut-être géré de façon basique à l'utilisation des credentials dans des scripts automatiques j'ai longtemps cherché le meilleur moyen de faire.

Traitement de la demande

1. Get-Credential

La façon la plus simple d'utiliser les credentials et d'utiliser la commande de base

$cred = Get-Credential -Message "Message affiché dans la popup" -UserName MonUtilisateur

Le résultat est le suivant

PS > $cred

UserName                           Password
--------                           --------
MonUtilisateur System.Security.SecureString

Cette variable $cred peut-être utiliser par exemple dans la commande suivante

Enter-PSSession -ComputerName MonComputer -Credential $cred

2. ConvertFrom-SecureString : Stockage sur le disque

Une autre solution, un peu plus avancée, est de stocker le mot de passe dans un fichier sur le PC.
Naturellement ce stockage doit se faire de facon sécurisée.
Comme précédement il faut d'abord créer l'objet $Cred

$cred = Get-Credential -Message "Message affiché dans la popup" -UserName MonUtilisateur

Dans un second temps nous allons stocker le mot de passe de facon crypté sur le disque dur

$Cred.Password | ConvertFrom-SecureString | Out-File C:\temp\password.txt

Dans le fichier c:\temp\password.txt le mot de passe se trouve sous cette forme

01000000d08c9ddf0115d1118c7a00c04fc297eb0100000057670149ac674a41ad9d185a8a82724b0000000002000000000010660000000100002000000093aaaf1ed598a69bbfb4cc77e81dfeb2786f26db6184538833af18054ef1a8a3000000000e800000000200002000000098c97f4f344d0159f337966d55060ad3297cae7515938457a713ddd9eaac5cdf200000003d986891fb27cb3983f798082083ac734d97d6235a186d3cc43db26f63bd44684000000018620d4739c0a26a6261e8c9867e94605cd35c61090c982999d5bb09fb54ec7d9a3499ebeb304c67720edfa37a34fe7fd4bce8fd8468dbee5081f56c81f4ce46

Pour pouvoir utiliser ce mot de passe stocké de façon sécurisé, il faut d'abord le décrypter. Pour ce faire nous allons procéder de la façon suivante

$Username = "MonUtilisateur"
$SecurePassword = Get-Content c:\temp\password.txt | ConvertTo-SecureString
$Cred = New-Object System.Management.Automation.PSCredential -ArgumentList $Username,$SecurePassword

PS > $cred

UserName                           Password
--------                           --------
MonUtilisateur System.Security.SecureString

Comme dans le point 1 on se retrouve avec une variable $Cred utilisable dans la commande

Enter-PSSession -ComputerName MonComputer -Credential $cred

3. Export-Clixml : Stockage sur le disque

L'avantage de cette méthodologie est que vous pouvez exploiter la polyvalence de PowerShell pour vous assurer que les données ne sont pas seulement exportées, mais également stockées de manière sécurisée à l'aide de chaînes sécurisées. Il convient de noter que ces fichiers d’informations d’identification créés ne peuvent être ouverts que par le même utilisateur sur le même système.

Pour créer le fichier d'export il faut procéder de la façon suivante

get-credential -message "mot de passe utilisateur ?" -UserName MonUtilisateur | Export-Clixml -Path "c:\temp\user.xml"

Le fichier c:\temp\user.xml contient les informations suivantes

<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <Obj RefId="0">
    <TN RefId="0">
      <T>System.Management.Automation.PSCredential</T>
      <T>System.Object</T>
    </TN>
    <ToString>System.Management.Automation.PSCredential</ToString>
    <Props>
      <S N="UserName">MonUtilisateur</S>
      <SS N="Password">01000000d08c9ddf0115d1118c7a00c04fc297eb0100000057670149ac674a41ad9d185a8a82724b00000000020000000000106600000001000020000000dadd8864c9b930a2eb07a6745ac4fb5711912c318c401f7e35bb91d4d1cc180b000000000e8000000002000020000000b5a862ba266c236357445b773ca38d73ed124cf82d863ac4c11e2b48d57fca4b2000000054180930ba9fd53a6c4bdd9d7f69c044c88072b0d411486bccc1ca3cca417bf440000000d6197eafe8a133235bd1b44e376c3ff02e94da9f39b7d24b9a68ef5dbd629e44180ce15c3e67830d758fa1296f60a98cb2371ef915990c921e728f44c72c4cbd</SS>
    </Props>
  </Obj>
</Objs>

Pour récupérer les informations il faut utiliser la commande

 $Cred = Import-Clixml -Path "c:\temp\user.xml"

encore une fois on récupére bien notre variable $Cred

PS > $cred

UserName                           Password
--------                           --------
MonUtilisateur System.Security.SecureString

Aujourd'hui, personnellement, j'utilise la méthode 3.

Découper un fichier Word en plusieurs PDF…

Laurent LIENHARD — Thu, 18 Jul 2019 18:32:02 +0000

Demande Initiale

La demande initiale qui m'a amené à réfléchir sur ce sujet provient d'un collègue.

Mon collègue réceptionne un gros document Word de son ERP contenant sur chaque page une lettre pour un destinataire différent.

Afin de pouvoir l'intégrer dans la GED (Gestion électronique de document) il avait les besoins suivant :

Découper le gros fichier en plusieurs fichiers (1 page = 1 fichier)
Récupérer une donnée dans les documents pour nommer le PDF
Sauvegarder les nouveaux documents en PDF

Ne connaissant pas grand-chose (c'est un euphémisme :-) ) dans la manipulation de Word via PowerShell j'ai découpé, comme d'habitude, ma réflexion en petites étapes.

Traitement de la demande

L'ouverture et le découpage du fichier

La première étape est donc d'ouvrir le document Word en question. Pour cela il faut instancier un objet Word et ouvrir le document

$word = New-Object -ComObject word.application
$word.Visible = $True
$doc = $word.Documents.Open($inputFile)

Je laisse "$word.Visible" à True le temps du debug ensuite je le mettrais en False pour que le traitement soit totalement transparent.

$ImputFile est une variable qui contient le chemin vers mon fichier Word à traiter.

Une fois le document ouvert on entre dans le vif du sujet : Comment découper ce document de X pages en X documents d'une page?

J'ai cherché pas mal sur le net avant de trouver une solution qui, n'est peut-être pas la plus élégante, mais qui a le mérite de fonctionner ;-).

Le principe est assez simple en fait : on prend une page après l'autre du document et on fait un copier/coller dans un nouveau document que l'on enregistre.

$pages = $doc.ComputeStatistics([Microsoft.Office.Interop.Word.WdStatistic]::wdStatisticPages)
$rngPage = $doc.Range()

for ($i = 1; $i -le $pages; $i += $pageLength)
{

    [Void]$word.Selection.GoTo([Microsoft.Office.Interop.Word.WdGoToItem]::wdGoToPage,

        [Microsoft.Office.Interop.Word.WdGoToDirection]::wdGoToAbsolute,

        $i #Starting Page

    )

    $rngPage.Start = $word.Selection.Start


    [Void]$word.Selection.GoTo([Microsoft.Office.Interop.Word.WdGoToItem]::wdGoToPage,

        [Microsoft.Office.Interop.Word.WdGoToDirection]::wdGoToAbsolute,

        $i + $pageLength #Next page Number

    )

    $rngPage.End = $word.Selection.Start

    $marginTop = $word.Selection.PageSetup.TopMargin
    $marginBottom = $word.Selection.PageSetup.BottomMargin
    $marginLeft = $word.Selection.PageSetup.LeftMargin
    $marginRight = $word.Selection.PageSetup.RightMargin

    $rngPage.Copy()
    $newDoc = $word.Documents.Add()

    $word.Selection.PageSetup.TopMargin = $marginTop
    $word.Selection.PageSetup.BottomMargin = $marginBottom
    $word.Selection.PageSetup.LeftMargin = $marginLeft
    $word.Selection.PageSetup.RightMargin = $marginRight

    $word.Selection.Paste() # Now we have our new page on a new doc
    $word.Selection.EndKey(6, 0) #Move to the end of the file
    $word.Selection.TypeBackspace() #Seems to grab an extra section/page break
    $word.Selection.Delete() #Now we have our doc down to size
}

Je ne rentrerais pas dans le détail mais le code est assez compréhensible. J’ai récupéré ce bout de code et je l'ai un peu adapté à mon besoin. J'avoue que je ne comprends pas forcément tout ce qu'il fait (mais il le fait :-) )

Nous verrons l'enregistrement un peu plus loin dans la suite de l'article

Récupérer le nom du fichier dans le document Word

Chaque nouveau document Word créé correspond à une lettre pour un destinataire.
S'agissant de lettre pour des locataires, le numéro unique que je dois récupérer dans le document Word et le numéro de bail qui se présente sous la forme d'une suite de 10 nombres commençant toujours par 0.

Pour rechercher ce nombre j'ai utilisé les Regex.

$FileNamePattern = ".*de bail.*(0\d{9})"
$regex = [Regex]::Match($rngPage.Text, $fileNamePattern)

if ($regex.Success) {
    $id = $regex.Groups[1].Value
}
else {
    $id = "patternNotFound" + $i
}

Je définis mon pattern qui recherche n’importe où dans le document la chaîne "de bail" suivi de n'importe quel caractère puis suivi d'un groupe de 9 nombres précédé par un 0.

J'applique mon pattern et je récupère le résultat dans la variable $regex.

Si tout se passe bien je récupère le numéro de bail dans la variable $id avec laquelle je formerais mon nom de document.

Enregistrer chaque document en PDF

$path = $outputPath + $id + ".pdf"
$newDoc.saveas([ref] $path, 17)
$newDoc.close([ref]$False)

$OutputPath est une variable qui contient le chemin vers le répertoire de destination de mes fichiers PDF.

Voici la fonction dans son intégralité

function Convert-Docx2Pdf {

[CmdletBinding()]
param (
    [Parameter(Mandatory = $False)][string]$FileNamePattern = ".*de bail.*(0\d{9})",
    [Parameter(Mandatory = $False)][string]$pageLength = 1,
    [Parameter(Mandatory = $true)][string]$InputFile ,
    [Parameter(Mandatory = $False)][string]$outputPath = $env:temp + "\Outputdir\"
)

BEGIN {
if (Test-Path $outputPath) {
    Remove-Item -Path $outputPath -Recurse -Force -Confirm:$false
}
New-Item -Path $outputPath -ItemType Directory -Force -Confirm:$false
}

PROCESS {
$word = New-Object -ComObject word.application

$word.Visible = $False



$doc = $word.Documents.Open($inputFile)

$pages = $doc.ComputeStatistics([Microsoft.Office.Interop.Word.WdStatistic]::wdStatisticPages)



$rngPage = $doc.Range()



for ($i = 1; $i -le $pages; $i += $pageLength)
{

    [Void]$word.Selection.GoTo([Microsoft.Office.Interop.Word.WdGoToItem]::wdGoToPage,

        [Microsoft.Office.Interop.Word.WdGoToDirection]::wdGoToAbsolute,

        $i #Starting Page

    )

    $rngPage.Start = $word.Selection.Start



    [Void]$word.Selection.GoTo([Microsoft.Office.Interop.Word.WdGoToItem]::wdGoToPage,

        [Microsoft.Office.Interop.Word.WdGoToDirection]::wdGoToAbsolute,

        $i + $pageLength #Next page Number

    )

    $rngPage.End = $word.Selection.Start



    $marginTop = $word.Selection.PageSetup.TopMargin

    $marginBottom = $word.Selection.PageSetup.BottomMargin

    $marginLeft = $word.Selection.PageSetup.LeftMargin

    $marginRight = $word.Selection.PageSetup.RightMargin


    $rngPage.Copy()

    $newDoc = $word.Documents.Add()


    $word.Selection.PageSetup.TopMargin = $marginTop

    $word.Selection.PageSetup.BottomMargin = $marginBottom

    $word.Selection.PageSetup.LeftMargin = $marginLeft

    $word.Selection.PageSetup.RightMargin = $marginRight



    $word.Selection.Paste() # Now we have our new page on a new doc

    $word.Selection.EndKey(6, 0) #Move to the end of the file

    $word.Selection.TypeBackspace() #Seems to grab an extra section/page break

    $word.Selection.Delete() #Now we have our doc down to size



    #Get Name

    $regex = [Regex]::Match($rngPage.Text, $fileNamePattern)

    if ($regex.Success) {
        $id = $regex.Groups[1].Value
    }
    else {
        $id = "patternNotFound" + $i
    }


    $path = $outputPath + $id + ".pdf"

    $newDoc.saveas([ref] $path, 17)

    $newDoc.close([ref]$False)
}
}

END {
[gc]::collect()
[gc]::WaitForPendingFinalizers()
}
}

Avoir un état de la synchronisation entre son inventaire et sa supervision

Laurent LIENHARD — Thu, 18 Jul 2019 16:21:22 +0000

Besoin Initial

J'utilise tous les jours les outils suivants :

Centreon pour la supervision
Glpi pour mon inventaire

Malheureusement je ne suis pas le seul à gérer et créer des serveurs par contre je suis le seul à gérer la supervision.
Naturellement comme toujours dans ce genre de cas il arrive souvent que des serveurs soient créés sans que je n'en sois informé et du coup une dé-corrélation entre la supervision et l'inventaire apparaît.

L’agent d'inventaire Fusion Inventory est poussé par GPO sur tous les serveurs mis dans le domaine donc, normalement, mon inventaire doit être à peu près à jour.

Le but était donc de faire un outil qui récupère les informations serveurs présents dans mon GLPI et de les comparer avec mes objets présents dans la supervision.

Les étapes sont les suivantes :

Se connecter aux bases Mysql
Exporter les informations des 2 bases
Comparer les informations avec un rendu lisible pour l'utilisateur

Étape 1 : La connexion à une base MySql

Pour pouvoir se connecter à une base de données MySql il est nécessaire d'installer au préalable le connecteur .net suivant : Connector/NET

Il faut ensuite, dans un premier temps, charger ce connecteur pour pouvoir l'utiliser en ajoutant la commande suivante au début de notre script.

[void] [system.reflection.Assembly]::LoadWithPartialName("MySql.Data")

Comme d'habitude, on positionne quelques variables pour simplifier l'utilisation du script

$ServGLPI = "srv-glpi01" #Adresse du serveur GLPI
$UserGlpi = "root"  #Nom de l'utilisateur utilisé pour se connecter
$PasswordGlpi = "sdfghjkl" #Mot de passe de l'utilisateur
$DbGlpi = "glpidb" #Nom de la base de donnée MySql

$ServCentreon = "srv-centreon01" #Adresse du serveur Centreon
$UserCentreon = "root"  #Nom de l'utilisateur utilisé pour se connecter
$PasswordCentreon = "sdfghjkl" #Mot de passe de l'utilisateur
$DbCentreon = "centreondb" #Nom de la base de donnée MySql

$port = "3306"  #Port d'écoute du serveur MySql

Il faut ensuite créer une chaîne de connexion vers nos serveurs Mysql

$ConnInventaire = “server=$ServGlpi;uid=$UserGlpi;password=$PasswordGlpi;database=$DbGlpi;Port=$Port"
$ObjMysqlInventaire = New-Object MySql.Data.MySqlClient.MySqlConnection($ConnInventaire)
$ObjMysqlInventaire.Open()

$ConnSuperviser = “server=$ServerCentreon;uid=$UserCentreon;password=$PasswordCentreon;database=$DbCentreon;Port=$Port"
$ObjMysqlSuperviser = New-Object MySql.Data.MySqlClient.MySqlConnection($ConnSuperviser)
$ObjMysqlSuperviser.Open()

À partir de cet instant nous avons 2 connexions $ConnInventaire et $ConnSuperviser ouvertes respectivement vers les bases de données sur les serveurs SRV-GLPI01 et SRV-CENTREON01.

Nous allons pouvoir utiliser ces connexions pour passer à la seconde étape.

Étape 2 : Requêter les bases de données

$ReqInventaire = "SELECT `glpi_computers`.name AS `Name`, `glpi_states`.`completename` AS `State`, `glpi_computertypes`.name AS `Type`, `glpi_computermodels`.name AS `Modele`, `glpi_locations`.`completename` AS `Localisation`
FROM `glpi_computers`
LEFT JOIN `glpi_entities` ON (`glpi_computers`.`entities_id` = `glpi_entities`.`id` )
LEFT JOIN `glpi_states` ON (`glpi_computers`.`states_id` = `glpi_states`.`id` )
LEFT JOIN `glpi_manufacturers` ON (`glpi_computers`.`manufacturers_id` = `glpi_manufacturers`.`id` )
LEFT JOIN `glpi_computertypes` ON (`glpi_computers`.`computertypes_id` = `glpi_computertypes`.`id` )
LEFT JOIN `glpi_computermodels` ON (`glpi_computers`.`computermodels_id` = `glpi_computermodels`.`id` )
LEFT JOIN `glpi_operatingsystems` ON (`glpi_computers`.`operatingsystems_id` = `glpi_operatingsystems`.`id` )
LEFT JOIN `glpi_locations` ON (`glpi_computers`.`locations_id` = `glpi_locations`.`id` )
LEFT JOIN `glpi_items_deviceprocessors` ON (`glpi_computers`.`id` = `glpi_items_deviceprocessors`.`items_id` AND `glpi_items_deviceprocessors`.`itemtype` = 'Computer' )
LEFT JOIN `glpi_deviceprocessors` AS `glpi_deviceprocessors_7083fb7d2b7a8b8abd619678acc5b604` ON (`glpi_items_deviceprocessors`.`deviceprocessors_id` = `glpi_deviceprocessors_7083fb7d2b7a8b8abd619678acc5b604`.`id` )
LEFT JOIN `glpi_ipaddresses` AS `glpi_ipaddresses_0cc35feab42e5909929ff742b4834540` ON (`glpi_computers`.`id` = `glpi_ipaddresses_0cc35feab42e5909929ff742b4834540`.`mainitems_id` AND `glpi_ipaddresses_0cc35feab42e5909929ff742b4834540`.`mainitemtype` = 'Computer' AND `glpi_ipaddresses_0cc35feab42e5909929ff742b4834540`.`is_deleted` = 0 )
WHERE `glpi_computers`.`is_deleted` = '0' AND `glpi_computers`.`is_template` = '0' AND ( (`glpi_computertypes`.`id` = '22') AND (`glpi_states`.`id` = '1') ) GROUP BY `glpi_computers`.`id`
ORDER BY `Name` ASC "

Premièrement je crée une variable $ReqInventaire qui va contenir ma requête. Dans ce cas-là je récupère tous les machines de type serveur.

Petite astuce : pour trouver cette requête je passe GLPI en mode debug ;-)

$SQLCommand = New-Object MySql.Data.MySqlClient.MySqlCommand($ReqInventaire,$ObjMysqlInventaire)
$MySQLDataAdaptater = New-Object MySql.Data.MySqlClient.MySqlDataAdapter($SQLCommand)
$MySQLDataSet = New-Object System.Data.DataSet
$RecordCount = $MySQLDataAdaptater.Fill($MySQLDataSet)
$ServersInventorier = $MySQLDataSet.Tables
$ObjMysqlInventaire.close()

Ensuite je passe cette requête dans ma connexion $ObjMysqlInventaire, je l'exécute, récupère les données dans un DataSet et enfin de ce DataSet j'exporte les informations qui m'intéresse dans la variable $ServersInventorier

Pour plus d'information sur cette partie, je vous laisse faire un tour sur Google

Je fais de même pour la requête dans Centreon

$ReqSuperviser = "SELECT nagios_hosts.display_name AS Name FROM nagios_hosts ORDER BY Name ASC "
$SQLCommand = New-Object MySql.Data.MySqlClient.MySqlCommand($ReqSuperviser,$ObjMysqlSuperviser)
$MySQLDataAdaptater = New-Object MySql.Data.MySqlClient.MySqlDataAdapter($SQLCommand)
$MySQLDataSet = New-Object System.Data.DataSet
$RecordCount = $MySQLDataAdaptater.Fill($MySQLDataSet)
$ServersSupeviser = $MySQLDataSet.Tables
$ObjMysqlSuperviser.close()

A ce stade, on se retrouve donc avec 2 variables $ServersInventorier et $ServersSupeviser contenant respectivement la liste des serveurs inventoriés dans GLPi et la liste des serveurs supervisés dans Centreon.

Étape 3 : Comparer les 2 listes

Pour comparer ces 2 listes j'ai utilisé la commande Compare-Object (tout simplement ;-) )

The Compare-Object cmdlet compares two sets of objects. One set of objects is the "reference set," and the other set is the "difference set."
The result of the comparison indicates whether a property value appeared only in the object from the reference set (indicated by the <= symbol), only in the object from the difference set (indicated by the => symbol) or, if the IncludeEqual parameter is specified, in both objects (indicated by the == symbol). extrait de la doc en ligne

Donc comme l'extrait ci-dessus l'explique il nous faut :

reference set = $ServersInventorier
difference set = $ServersSupeviser
IncludeEqual : car je veux quand même savoir si ma machine est inventoriée et supervisée

$Servers = Compare-Object -ReferenceObject $ServersInventorier.name -DifferenceObject $ServersSupeviser.name -IncludeEqual
ForEach ($server in $Servers)
{
    Switch ($server.SideIndicator)
    {
        "==" {Write-Host $server.SideIndicator $server.InputObject "est Inventorié et Supervisé" }
        "<=" {Write-Host $server.SideIndicator $server.InputObject "est Inventorié mais PAS SUPERVISE"}
        "=>" {Write-Host $server.SideIndicator $server.InputObject "est Supervisé mais PAS INVENTORIE"}
    }
}

Pour ce faire je récupère le résultat de ma commande compare-object dans une variable $Servers.
Ensuite je boucle sur cette variable pour faire afficher une phrase claire en fonction du cas.

La sortie résultant de cette boucle est du genre

== Serveur01 est Inventorié et Supervisé
=> Serveur10 est Supervisé mais PAS INVENTORIE
<= Serveur20 est Inventorié mais PAS SUPERVISE

Voilà avec çà il ne me reste plus qu'a mettre à jour mon inventaire et ma supervision selon le cas.