PowerShell

[PowerShell] Identifier les ordinateurs disposant du même SID

Bonjour à tous,

Voici un script permettant d’identifier parmi tous les ordinateurs d’un domaine, ceux qui disposent du même SID.

Pour rappel : Microsoft n’apporte pas son support dans le cas où vous disposez de systèmes clonés avec le meme SID (Lien officiel)

Notez que pour que ce script fonctionne :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

$Error.Clear()
Clear-Host
 # Initialize Computers List
$computerList = New-Object -TypeName System.Collections.ArrayList
 
# Retrieve ADCOmputers
Import-Module ActiveDirectory
$ADcomputers = @(Get-ADComputer -Filter * -Properties SamAccountName, SID)
 
# Create custom object for each computers
# Add information to this object (ComputerName, DomainSID, LocalSID)
# Add object to Result list
if ($ADcomputers.Count -gt 0)
{
    $i = 0
    foreach ($ADcomputer in $ADcomputers)
    {
        Write-Progress -Activity get-SID -Status Running -Id 0 -PercentComplete (($i/$ADcomputers.Count)*100) -CurrentOperation $computer.ComputerName
 
        $Computer = New-Object -TypeName psobject -Property @{
            "ComputerName"= ([String]$ADcomputer.SamAccountName).Replace('$','')
            "DomainSID"=$ADcomputer.SID
            "LocalSID"=$null
        }
 
        Invoke-Expression -Command ("PsGetsid.exe " + '\\' + $computer.ComputerName) -ErrorAction SilentlyContinue| Tee-Object -Variable out | Out-Null
        $Computer.LocalSID = ($out | Where-Object{$_ -like "S-1-5*"})
 
        $computerList.Add($Computer) |Out-Null
 
        $i++
    }
}
 
$computerList | Group-Object -Property LocalSID | Format-Table

Enjoy 😉

[PowerShell] Tester si un système est en attente de redémarrage

Bonjour à tous,

Voici une fonction permettant de tester si un système est en attente de redémarrage, en prenant en compte :

  • Les redémarrages en attente provenant de l’installation d’une fonctionnalité
  • Les redémarrages en attente provenant de l’installation de mises à jour logicielles
  • Les redémarrages en attente provenant de fichiers en attente de renommage (Mise à jour de .dll par exemple)
  • Les redémarrages en attente provenant du client SCCM

Si un de ces composants nécessite un redémarrage la fonction renverra la valeur $true.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

function Test-RebootRequired
{
    # Initialize result array    $result = @{
        CBSRebootPending = (Get-ChildItem "HKLM:Software\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending" -ErrorAction SilentlyContinue).CBSRebootPending
        WindowsUpdateRebootRequired = (Get-Item "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired" -ErrorAction SilentlyContinue).WindowsUpdateRebootRequired
        FileRenamePending = (Get-ItemProperty "HKLM:SYSTEM\CurrentControlSet\Control\Session Manager" -Name PendingFileRenameOperations -ErrorAction SilentlyContinue).FileRenamePending
        SCCMRebootPending = $false
	}
 
    # Complete result Array with SCCM client status
    try 
    { 
        $util = [wmiclass]"\\.\root\ccm\clientsdk:CCM_ClientUtilities"
        $status = $util.DetermineIfRebootPending()
        if(($status -ne $null) -and $status.RebootPending){
            $result.SCCMRebootPending = $true
        }
    }catch{}
 
    # Normalize Result Array
    if ($result.CBSRebootPending -eq $null){ $result.CBSRebootPending = $false }
    if ($result.WindowsUpdateRebootRequired -eq $null){ $result.WindowsUpdateRebootRequired = $false }
    if ($result.FileRenamePending -eq $null){ $result.FileRenamePending = $false }
 
    #Return Reboot required
    return $result.ContainsValue($true)
}

Enjoy 😉

[PowerShell] Comparer deux dossiers

Bonjour à tous,

Voici une portion de script dérivant comment comparer le contenu de deux dossiers.
Le but ici est d’identifier :

  • les fichiers en commun
  • les fichiers présents uniquement dans le premier dossier
  • les fichiers présents uniquement dans le second dossier

Notez que dans la présente situtation, la comparaison se fait au niveau du nom du fichier (-Property Name), mais vous pouvez lancer la comparaison sur un ou plusieurs autres critères comme par exemple le nom et la date de modification.

1
2
3
4
5
6
7

$FolderContent1 = @(Get-ChildItem -Path "<FolderPath1>") | where {!$_.PSIsContainer}
$FolderContent2 = @(Get-ChildItem -Path "<FolderPath2>") | where {!$_.PSIsContainer}
$ComparisonResult = Compare-Object -ReferenceObject $FolderContent1 -DifferenceObject $FolderContent2 -Property Name -IncludeEqual 
$EqualFiles = $ComparisonResult | Where-Object{$_.SideIndicator -eq "=="}
$FilesOnlyInTheFirstFolder =  $ComparisonResult | Where-Object{$_.SideIndicator -eq "<="}
$FilesOnlyInTheSecondFolder = $ComparisonResult | Where-Object{$_.SideIndicator -eq "<="}

et le résultat si je ne souhaite afficher que les fichiers présents dans les deux dossiers :


Enjoy 😉

[PowerShell] Découverte et personnalisation de PowerShell ISE

Bonjour à tous,

Apparu depuis maintenant quelques années, PowerShell est aujourd'hui incontournable. Pour ceux qui le découvrent, c'est un environnement d'exécution de tâches conçu spécialement pour l'administration des systèmes. Il repose entièrement sur .NET Framework et reprend les fondamentaux de la programmation orientée objet. Il permet aux administrateurs de contrôler et d'automatiser l'administration des systèmes d'exploitation Windows mais aussi de nombreux autres produits comme VMware, SCCM, Exchange, Azure, etc... Bref vous l'aurez compris, il vous sera de plus en plus compliqué de gérer vos environnements tout en ignorant ce composant !

Vous pouvez aborder PowerShell de 2 manières différentes :

  • En lançant la console PowerShell puis en exécutant des commandes comme par exemple dresser la liste de tous les processus actuellement en cours d'exécution (get-process). Après avoir récupéré cette liste vous pouvez stopper certains de ces processus à l'aide de la cmdlet Stop-Process. Dans ce mode de fonctionnement les commandes s'exécutent à votre grés. Aucune préparation n'est nécessaire. On travaille ici à la volée et le travail n'est pas réutilisable
  • En créant un script PowerShell qui prendra en charge l'exécution de nombreuses commandes que vous aurez reliées entre-elles à l'aide d'outils d'algorithmique tels que des conditions, des boucles, des filtres, etc. Ce scénario est particulièrement adapté lorsque vous devez exécuter la même procédure à de nombreuses reprises. L'idée est de décrire la marche à suivre dans ce script puis d'exécuter ce script chaque fois que ce "processus" doit être exécuté.

La rédaction d'un script PowerShell peut être réalisée avec un outil aussi simple que Notepad.exe. Cependant vous conviendrez que ce n'est pas l'outil le plus efficace car il ne permet par exemple pas de débugger ce script ou de bénéficier de coloration syntaxique bienvenue dans tout environnement de développement.

Dès la sortie de PowerShell Microsoft a intégré à Windows un éditeur de script : PowerShell ISE (Integrated Scripting Environment). Cet environnement vous permet de rédiger des scripts PowerShell tout en bénéficiant de nombreuses fonctionnalités :

  • IntelliSense qui vous proposera de compléter automatiquement ce que vous avez commencé à saisir
  • Des snippets ou extraits de code que vous pouvez insérer rapidement et ainsi réduire vos erreurs de saisie
  • Un enregistrement automatique de vos scripts toutes les 2 minutes (et croyez-moi c'est très utile !!)
  • Un debugger vous permettant d'exécuter tout ou partie de vos script en appliquant des points d'arrêt

Dans un premier temps cet environnement vous sera suffisant. Mais PowerShell ISE est un outil particulièrement personnalisable. C'est d'ailleurs son grand point fort. A tel point que plusieurs développeurs se sont "amusés" à ajouter des fonctionnalités supplémentaires qui peuvent être très utiles.

Cet article a pour objectifs de vous donner un aperçu de la personnalisation de l'éditeur PowerShell :

  • Dans un premier temps nous verrons qu'ISE est avant tout un environnement que nous chargeons qui est tout à fait personnalisable
  • Dans un second temps, nous nous focaliserons sur la création de nos propres snippets
  • Enfin je vous présenterai un Add-on permettant de littéralement doper votre ISE :  ISESteroids

Lire la suite[PowerShell] Découverte et personnalisation de PowerShell ISE

[PowerShell] Tester si un périphérique est connecté

Bonjour à tous,

Voici une fonction qui vous permettra de tester si un périphérique est connecté sur un poste de travail.
Cette fonction retourne les caractéristiques du périphérique si il est trouvé, sinon elle ne renvoie rien.
Le critère de recherche est un ID plug’n’play ou une liste d’IDs plug’n’play compatibles avec ce périphérique.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

function Search-Device
{
    Param
    (
        [Parameter(Mandatory=$true,ValueFromPipeline=$false,Position=0)][String[]]$PnpIDs
    )
 
    $devices = $device = $FoundDevice = $null
 
    # On dresse la liste des pépriphériques connectés 
    $devices = Get-WmiObject -Class Win32_PnpEntity | Sort-Object -Property Caption
 
    # On cherche dans cette liste si un périphérique contient l'ID plug'n'play recherché
    foreach ($device in $devices)
    {
        # On construit la liste des IDs plug'n'play compatibles
        $CompatibleIDs = $null
        if ($device.HardwareID.Count -gt 0)
        {
            $CompatibleIDs = $device.HardwareID
        }
        if ($device.CompatibleID.Count -gt 0)
        {
            $CompatibleIDs += $device.CompatibleID
        }
 
        # On cherche l'ID plug'n'play parmi la liste 
        if ($CompatibleIDs -ne $null)
        {
            foreach ($PnpID in $PnpIDs)
            {
                if ($CompatibleIDs.Contains($PnpID) -eq $true)
                {
                    $FoundDevice = $device
                    break
                }
            }
        }
    }
 
    if ($FoundDevice -ne $null)
    {
        Write-host "Périphérique trouvé" -ForegroundColor Green
        Write-Output $FoundDevice
    }
    else 
    {
        Write-Host "Périphérique non trouvé" -ForegroundColor Yellow
        Write-Output $null
    }
}

Exemples d’utilisation :

1

$Device = Search-Device -PnpIDs @('PCI\VEN_8086&DEV_0166&REV_09','PCI\VEN_8086&CC_030000')

Enjoy 😉

[Windows] Modifier l’ordre des emplacements source des pilotes

Vous avez déjà pu constater que lors du branchement d’un nouveau périphérique la recherche d’un pilote compatible pouvait prendre un certain temps … et même un temps certain. Ce délai est dû au fait que le processus de recherche de pilote Windows tente d’abord de localiser un pilote à partir du site Windows Update avant de rechercher un pilote localement.

Depuis Windows 7, vous avez la possibilité de modifier cet ordre de recherche.

Cet article vous présente où et comment modifier ce paramètre.

Lire la suite[Windows] Modifier l’ordre des emplacements source des pilotes

[Windows 10] Obtenir la clé OEM stockée dans le BIOS

Bonjour à tous,

Voici une portion de code PowerShell vous permettant d’obtenir la clé OEM Windows de votre système. Cette fonction renvoie la clé si le BIOS contient une clé Windows sinon elle ne renvoie rien:

1
2
3
4
5
6
7
8
9
10
11
12

Function Get-OriginalProductKey
{
    $ProductKey = (Get-WmiObject -Class SoftwareLicensingService).OA3xOriginalProductKey
    if (-not [string]::IsNullOrEmpty($ProductKey))
    {
        Write-Output $ProductKey
    }
    else
    {
        Write-Output $null
    }
}

Plus globalement, la classe WMI SoftwareLicensingService expose les propriétés d’activation d’un produit ainsi que les méthodes et propriétés liées au Service d’activation (date de fin de grâce, méthode d’activation, etc.). Vous trouverez le détail de cette classe ici.

Dernière information, il semblerai que cette classe soit disponible à partir de Windows 7 / 2008 R2.

Enjoy 😉

[PowerShell] Tester si le compte qui exécute le script est administrateur

Bonjour à tous,

Voici une portion de code intéressante qui vous permettra d’améliorer la qualité générale de vos scripts, particulièrement lorsque ces derniers nécessitent des droits d’administration être exécutés convenablement :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

try
{
    $User = [Security.Principal.WindowsIdentity]::GetCurrent()
    $Role = (New-Object Security.Principal.WindowsPrincipal $user).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
    if(!$Role)
    {
        Throw "Le compte qui exécute ce script ne dispose pas de privilèges élevés"
    }
    Write-Host "Le compte dispose de privilèges élevés"
}
catch
{
    Write-Host $_.Exception.Message -ForegroundColor Red
}

Note : Ce test fonctionne dans toutes les langues.

Enjoy 😉

[PowerShell] Créer un compte administrateur local

Vous n’êtes pas sans savoir qu’une des meilleures “best practices” concernant la sécurisation des postes de travail réside dans deux critères :

  • Désactiver le compte “administrateur” local
  • Eviter de créer un compte local sur tous les postes de travail, avec le même mot de passe

Par défaut, le compte “administrateur” est désactivé sous Windows 7.

Il ne nous reste donc plus qu’à créer un nouveau compte local respectant les bonnes pratiques.

Pour se faire, j’ai écrit un script PowerShell qui créé un nouveau compte local, l’ajoute au groupe “Administrateurs” et configure son mot de passe.

Ce script peut être intégré à une séquence de tâches. Pour davantage de détails sur l’exécution d’un script powershell dans une séquence de tâches, c’est par ici.

Lire la suite[PowerShell] Créer un compte administrateur local

[PowerShell] – Module de gestion des pilotes

Une des opérations les plus fastidieuses lors de la conception et la mise en œuvre d’un banc de déploiement/migration de poste de travail consiste à réaliser l’inventaire des pilotes utilisés par ces équipements, réaliser leur sauvegarde ou les télécharger, puis de les intégrer dans ce banc. Aujourd’hui les systèmes d’exploitation Windows ne permettent pas de sauvegarder les pilotes utilisés (à l’exception de Windows 8.1) et encore moins de les importer dans MDT ou SCCM. Des outils existent tels que DriverBackup! (Je vous en ai d’ailleurs parlé lors dans mes précédents articles). Cependant j’ai pu remarqué que la sauvegarde de certains pilotes n’était pas réalisée correctement (notamment les pilotes graphiques et Bluetooth).
Par conséquent déclarer les pilotes Windows 8 x64 pour un dell Latitude E6420 dans SCCM ou MDT est une opération qui peut nécessiter quelques heures de travail. Imaginez donc lorsque vous avez plusieurs modèles et plusieurs systèmes d’exploitation à déployer.

Ce module PowerShell a pour objectifs de vous simplifier la sauvegarde et la gestion des pilotes utilisés dans votre parc, mais également l’importation dans les produits MDT et SCCM.

Lien de téléchargement : ICI.

N’hésitez pas à m’envoyer vos remarques et commentaires (Bugs ou fonctionnalités à ajouter) et de noter ce module 😉

Lire la suite[PowerShell] – Module de gestion des pilotes