Powershell : listing et filtre des tâches planifiées sur de multiples serveurs

Ayant pu enfin appliquer par GPO un traitement que j’effectuais par script appelé par une tâche planifiée quotidiennement, j’ai dû procéder au listing complet des serveurs sur lesquels cette tâche était créée afin de pouvoir procéder à sa suppression. Ne pouvant pas me connecter un à un sur chaque machine pour vérifier la présence ou non, j’ai dû concevoir un script me permettant de lister les tâches planifiées qui portent mon compte d’utilisateur en auteur sur tout un scope de serveurs.

Voici le snippet que j’ai écrit :

$complist = Get-AdComputer -filter * -SearchBase "OU=SERVERS,DC=DUNDERMIFFLIN,DC=local"
foreach ($comp in $complist) {
Write-Host "`r`nServer:"$comp.DNSHostName
Invoke-Command -ComputerName $comp.DNSHostName -ScriptBlock { Get-ScheduledTask | Where-Object { $_.Author -eq "DUNDERMIFFLIN\mscott" } }
}

Ce script renvoie donc toutes les tâches planifiées que l’utilisateur mscott a créé sur chacun des serveurs présents dans la liste retournée par la requête AD. Il est possible de moduler ce que l’on souhaite obtenir en changeant le filtre ou le chemin LDAP dans la requête Get-AdComputer, sans oublier les propriétés des tâches planifiées dans la boucle Where-Object.

A noter que Get-ScheduledTask ne fonctionne qu’à partir de Windows Server 2012. Si jamais l’instruction Invoke-Command renvoie un message d’erreur propre à WinRM et que le contenu de l’instruction fonctionne en local, il vous faut activer l’administration Powershell à distance grâce à la commande Enable-PSremoting.

Powershell : désinstallation des hotfix Windows installés à une date spécifiée

J’ai développé pour le compte d’un collègue un script Powershell permettant de lister les hotfix Windows installés à une date spécifiée par l’utilisateur et proposant de les désinstaller, par exemple dans le cadre d’une campagne de patch mal déroulée sur une station ou un serveur.

Le script récupère la liste des patchs – Windows uniquement – installés le jour spécifié, extrait le numéro de KB et passe ensuite en argument de la ligne de commande de désinstallation de paquets Windows Update ce numéro en évitant un redémarrage.

Write-Host "Windows Operating System Hotfix KB remover"
Write-Host "==========================================`r`n"
$instdate = Read-Host "Please input the date KB were installed on."
$instdate = $instdate -as [datetime]
if($instdate -eq $null) { Write-Host "Please input a valid date.`r`nBye." ; exit }
$hotfixlist = Get-Hotfix | Where-Object { $_.InstalledOn -eq $instdate }
if($hotfixlist -eq $null) { Write-Host "No KBs installed for the specified date.`r`nBye." ; exit }
Write-Host "KB list for"$instdate
echo $hotfixlist
$choice = Read-Host "`r`nDo you want to uninstall those KBs ? (y to uninstall - any other input will cancel)"
if($choice -eq "y") {
foreach($kb in $hotfixlist){
$kbid = $kb.HotfixID.Substring(2,$kb.HotfixID.Length-2)
Write-Host "Uninstalling"$kbid
wusa.exe /uninstall /KB:$kbid /norestart
Write-Host "Please press ENTER only once the update wizard is closed because only one instance of it can be started at a time." -ForegroundColor "Yellow"
Read-Host
}
}
Write-Host "Bye."

Une pause marquée par le Read-Host est obligatoire après l’exécution de la commande de désinstallation sinon le script les exécute toutes à la suite, ce qui ne fonctionne pas puisque seule une instance de wusa.exe peut être lancée en même temps.

Powershell : harmonisation de la configuration DNS

Afin d’harmoniser la configuration DNS sur des serveurs situés sur différents sites géographiques, j’ai développé un script Powershell lié à une GPO qui l’exécute au démarrage.

Ce script récupère grâce au nom du serveur son emplacement et applique en fonction de ce dernier les bonnes adresses IP. Naturellement, il faudra adapter l’extraction de l’emplacement dans le nom de la machine en fonction de l’environnement sur lequel le script sera déployé ; de plus, le domaine sur lequel la carte est connectée sert d’identification de la carte réseau employée pour la résolution DNS.

$location = (hostname).Substring(2,3)
switch($location){
"PAR" { $dnslist = '("192.168.1.1","192.168.1.2","192.168.2.1")' }
"BXL" { $dnslist = '("192.168.2.1","192.168.2.2","192.168.1.1")' }
"BER" { $dnslist = '("192.168.3.1","192.168.3.2","192.168.2.1")' }
"LDN" { $dnslist = '("192.168.4.1","192.168.4.2","192.168.3.1")' }
"NYC" { $dnslist = '("192.168.5.1","192.168.1.1","192.168.4.1")' }
}
$cards = Get-NetIPConfiguration
foreach($card in $cards){
if($card.NetProfile.Name -eq "dundermifflin.local") { $index = $card.InterfaceIndex }
}

$query = "Set-DnsClientServerAddress -InterfaceIndex $index -ServerAddresses $dnslist"
Invoke-Expression $query

Ce snippet fonctionne si par exemple mes serveurs ont une nomenclature de nommage comme celle-ci : <OS><Environnement><Emplacement><Rôle><ID>, qui pourrait donner par exemple pour un contrôleur de domaine de production WPLDNDC01 ou un serveur PostgreSQL de recette LRBXLPG03.

Utilisation de Get-ACL sur une arborescence ActiveDirectory

Cet article fait plus ou moins écho à celui d’hier où j’explique comment accorder des droits spécifiques à un utilisateur ou un groupe sur une OU ActiveDirectory. Get-ACL est une instruction Powershell permettant de retourner les permissions d’un fichier, répertoire ou même clef de registre. Par défaut, Get-ACL ne permet pas de retourner les autorisations d’un objet ActiveDirectory, mais il existe une technique de sioux permettant d’utiliser cette instruction sur un AD.

Sur une station ayant les RSAT d’installés ou bien directement sur un contrôleur de domaine, il suffit d’importer le module AD pour Powershell :

Import-Module ActiveDirectory

Ensuite, se placer dans l’arborescence AD :

Set-Location AD:

Un simple dir permet de retourner des informations nous confirmant que nous sommes bien dans l’AD.

Lancer un Get-ACL à la racine de AD: n’aura aucun effet. Il est tout de même nécessaire d’indiquer un chemin à la commande ; on utilisera alors le DistingushedName. Par exemple, pour récupérer l’intégralité des permissions à la racine du domaine (attention, ce n’est pas récursif !) :

(Get-Acl (Get-ADDomain).DistinguishedName).Access

Ainsi, il est possible de se concocter un petit snippet si l’on souhaite parcourir tout l’AD à la recherche de privilèges accordés à un groupe ou à un utilisateur sur des OU, par exemple :

Import-Module ActiveDirectory
Set-Location AD:
$oulist = Get-ADOrganizationalUnit -Filter * | select DistinguishedName
foreach($ou in $oulist){
$privileges = (Get-Acl $ou.DistinguishedName).Access | Where-Object { $_.IdentityReference -eq "DUNDERMIFFLIN\gclooney" }
if($privileges -ne $null) { Write-Host "OU:"$ou.DistinguishedName ; $privileges }
}

Par exemple, ayant accordé les droits à l’utilisateur gclooney sur l’OU End-Users, il récupère par héritage ces mêmes privilèges sur les 3 OU enfant.

Cela se vérifie avec le snippet plus haut :

Ce code peut naturellement être modifié pour interroger des groupes ou des utilisateurs. Par exemple, je vais octroyer des droits au groupe US-Presidents sur le groupe Actors. La capture suivante montre bien que le droit WriteProperty a été attribué.

En jouant sur la clause Where-Object de ce snippet, on peut modifier le filtre de recherche. Par exemple, afin rechercher tous les utilisateurs ayant le droit WriteProperty sur un objet défini, il suffit de modifier le snippet :

$grplist = Get-ADgroup -Identity "Actors" | select DistinguishedName
$privileges = (Get-Acl $grp.DistinguishedName).Access | Where-Object { $_.ActiveDirectoryRights -like "*WriteProperty*" }

Au final, la seule limite de Get-Acl et du code que l’on adapte autour, ce sont les informations que l’on souhaite récupérer et les actions éventuelles à mener pour cadrer au mieux les privilèges attribués au fil du temps !