Windows PowerShell : Pensez commandes, pas scripts
Ne pas être intimidés par la mention “ script ”, parce que vous pouvez faire beaucoup avec Windows PowerShell à l'aide des commandes simples.
Don Jones
Perception a été parmi les plus importantes difficultés que Windows PowerShell a été en termes d'acceptation de l'administrateur. Il y a une perception en attente que l'interpréteur de commandes est un “ langage de script ” équivaut à VBScript. Bien que beaucoup d'administrateurs t'aime ce qu'ils peuvent faire avec un langage de script, plein plus sont désactivées par la perception de complexité et d'une courbe d'apprentissage abrupte.
Il est dommage. L'interpréteur de commandes prend en charge une approche basée sur le script robuste, mais il tout aussi bien à une approche plus simple, orientée sur la commande. L'avantage réel de l'interpréteur de commandes est que vous pouvez utiliser les deux approches pour réaliser un grand nombre des mêmes tâches.
Il vous suffit d'un script
La fonction suivante accepte des noms d'ordinateur à partir de la ligne de commande sous forme de chaînes ou de la propriété “ ComputerName ” d'un objet d'entrée ;Elle récupère également les informations de BIOS et du système d'exploitation de chaque ordinateur à l'aide de WMI (Windows Management Instrumentation) :
function Get-Inventory
{
[CmdletBinding()]
Param(
[Parameter(Mandatory=$true,
ValueFromPipeline=$true,
ValueFromPipelineByPropertyName=$true)]
[string] $computername
)
Process {
$os = gwmi win32_operatingsystem -computername $computername
$bios = gwmi win32_bios -computername $computername
$obj = new-object psobject
$obj | add-member noteproperty ComputerName $computername
$obj | add-member noteproperty OSBuild ($os.buildnumber)
$obj | add-member noteproperty SPVersion ($os.servicepackmajorversion)
$obj | add-member noteproperty BIOSSerial ($bios.serialnumber)
Write-output $obj
}
}
Remarque que les parenthèses forcent l'interpréteur de commandes pour exécuter des expressions, telles que l'obtention de la propriété BuildNumber à partir de l'objet dans la variable de système d'exploitation $ et retournent le résultat de cette expression en tant que la troisième valeur de paramètre de membre de l'ajouter.
Je peux également exécuter cette fonction par des conduites dans les noms d'ordinateur statique :
'localhost','server2' | Get-Inventory
Ou, en envoyant le contenu d'un texte de fichiers contenant un nom d'ordinateur par ligne :
Get-Content names.txt | Get-Inventory
Ou encore en récupérant des objets de l'ordinateur à partir de Active Directory, la modification de la propriété Name pour Nom_Ordinateur et de tuyauterie ceux :
Import-Module ActiveDirectory
Get-ADComputer –filter * | Select-Object @{Label='ComputerName';Expression={$_.Name}} | Get-Inventory
À propos, j'utilise les accolades pour encapsuler le code exécutable. L'espace réservé de $ _ représente l'objet transmis dans la cmdlet Select-Object. Les résultats d'un d'entre eux sont un tableau de quatre colonnes soigneusement mis en forme. Je peux facilement rediriger cette sortie vers un fichier, imprimante ou une grille, ou même filtrer et trier les résultats avant de les afficher. Par exemple :
Get-Content names.txt | Get-Inventory | Where { $_.BuildNumber –eq 7600 } | Sort ComputerName
Une fois de plus, les accolades encapsulent un bloc de code exécutable, l'expression que vous voulez filtrer, et l'espace réservé de $ _ représente l'objet transmis dans.
Performances de la commande
Il est tout à fait correct à l'aide d'un script comme celui, mais il fonctionne assez difficile. Il s'agit d'une approche de type scripteur ou programmeur que beaucoup d'administrateurs trouver intimidant. Vous pouvez procéder de la même chose dans une commande unique et un peu complexe. Accolade vous-même :
Get-WmiObject Win32_OperatingSystem -computername (get-content names.txt) |
Select-object @{Label="ComputerName";Expression={$_.__SERVER}},
@{Label="OSBuild";Expression={$_.BuildNumber}},
@{Label="SPVersion";Expression={$_.ServicePackMajorVersion}},
@{Label="BIOSSerial";Expression={(gwmi win32_bios -comp $_.__server).serialnumber}}
Il y a beaucoup sur cet emplacement. Voici une ventilation :
- Commencez par exécuter Get-WmiObject pour récupérer l'objet de Win32_OperatingSystem dans les noms d'ordinateur spécifié. Si vous êtes un lecteur normal de cette chronique, vous savez peut-être que les objets retournés par Get-WmiObject incluront toujours une propriété __SERVER que contient le nom d'ordinateur provenant d'objets WMI.
- Les objets WMI sont redirigées vers Select-Object. J'utilise quatre tables de hachage pour définir les quatre propriétés : Nom_Ordinateur, OSBuild, SPVersion et BIOSSerial. Chaque table de hachage spécifie une étiquette, qui sera ensuite utilisé comme l'en-tête de colonne pour la sortie et une expression. La table de hachage est construite en utilisant le @ opérateur de tableau, suivie de la définition d'étiquette/expression à l'intérieur d'accolades. Les accolades mettez le code exécutable qui définit la portion expression de la table de hachage.
- Pour les trois premières colonnes, l'expression fait simplement référence à une propriété existante de l'objet ;Je suis en gros changez simplement le nom de propriété.
- Pour la quatrième colonne mon expression s'exécute en fait une deuxième requête WMI sur le même serveur. Il est tirant sur le nom d'ordinateur à partir de la propriété __SERVER. Voir la rubrique Comment les appels WMI complète est placé entre parenthèses ? Ceux forcer l'expression pour être exécutée en premier. Quelle que soit l'objet résultant de cette expression sera inséré à la place de la partie entre parenthèses. Le point après les parenthèses fermantes me permet d'accéder aux propriétés de cet objet qui en résulte, donc je suis l'accès à la propriété SerialNumber (Numéro_série) pour mon quatrième colonne.
Dans une certaine manière, cette syntaxe est plus difficile à lire que le script avec qui j'ai commencé. Il est compact et utilise beaucoup de signes de ponctuation. C'est le type d'un élément, vous pouvez utiliser en tant que modèle et le modifier en fonction de vos autres besoins. Si vous ne comprenez pas pourquoi il ne fonctionne pas, poser une question sur mon blog à ConcentratedTech.com et je vous aiderai à déterminer.
Il n'est pas appeler un script
Le point est que Windows PowerShell ne doit pas être utilisé comme un langage de script. La commande que j'ai démontré peut être complexe, mais il est n'est plus complexe que certaines commandes avant-gardiste, j'ai vu des administrateurs écrire pour l'ancien interpréteur de commandes Cmd.exe. Une fois que vous habituer à la syntaxe, qui prend il est vrai que certains exercices pratiques, la commande est beaucoup moins compliquée que l'écriture complet-sur script ou une fonction.
Par conséquent, ne laissez pas le terme “ langage de script ” vous activer à partir de l'interpréteur de commandes. Il n'est que “ scripty ” lors du choix.
.jpg)
Don Jones est le fondateur de concentré de technologie et les réponses aux questions sur Windows PowerShell et d'autres technologies à ConcentratedTech.com. Il est également un auteur pour Nexus.Realtimepublishers.com que la plupart de ses livres rend disponible en tant que libres éditions électroniques par le biais de son site web.