Windows PowerShellRestez insérée !

Don Jones

Contenu

La solution
Voir It dans action
Accès distant un-à-plusieurs
Il placer de votre esprit
C'est la gestion à distance, établissement nouveau style

J'ai toujours été frustré par le message double parfois sort de Microsoft concernant la gestion de serveur : sur un côté, nous vous dit à juste titre pour installer les outils de gestion sur nos propres ordinateurs clients et utiliser ces outils pour gérer nos serveurs.Nous n'êtes pas censé pour aller dans le Centre de données, à l'aide du même Bureau à distance est techniquement triche car il en fait simplement va dans le Centre de données sans prendre le parcours.D'autre part, cependant, il existe nombreuses tâches de gestion de serveur ne peut pas être effectuées facilement à l'aide des outils à distance existants, modification des adresses ou rien avec la configuration du réseau, par exemple.

Windows PowerShell q & a

QUn script Windows PowerShell peut être utilisé comme un script d'ouverture de session ?

A Oui, mais peut ne pas être n'importe quel point cela.Vous ne faites glisser le script dans un objet stratégie de groupe (GPO) dans la même façon que vous un fichier VBScript.Au lieu de cela, vous devez en fait créer un fichier de commandes le Powershell.exe s'exécute, en passant le paramètre de ligne de commande qui lui indique quel script à exécuter.Il est difficile.Vous devez également installer Windows PowerShell sur chaque ordinateur où ce script d'ouverture de session sera exécuté.Au final, gardez à l'esprit que Windows PowerShell est un peu plus autonome que VBScript ou l'interpréteur de commandes cmd.exe.Par exemple, mappage d'un lecteur en utilisant le cmdlet New-PSDrive n'affecte l'Explorateur Windows, vous devrez revenir sur la commande NET utiliser réellement mapper un lecteur dans Windows et si vous allez faire pourquoi ne pas simplement utiliser un fichier batch traditionnelles, qui est plus facile à inclure dans un objet de stratégie de groupe ?

QScripts Windows PowerShell peuvent être planifiées ?

A absolue.Vous allez réellement planifier PowerShell.exe (qui se trouve dans votre dossier % racine_système % sous /WindowsPowerShell) et lui donner un paramètre de ligne de commande qui spécifie le script que vous souhaitez exécuter.Assurez-vous que la tâche est configurée pour utiliser un compte utilisateur disposant des autorisations nécessaires pour faire tout ce que le script effectue et assurez-vous que la stratégie de l'exécution du shell est configurée pour permettre l'exécution du script (je préfère la stratégie AllSigned moi-même, ce qui signifie que votre script vous devrez être signés numériquement ; exécuter "Aide about_signing" dans l'environnement de ligne de commande pour plus d'informations sur ce).

QExiste-t-il un moyen facile pour manipuler les autorisations de fichiers et dossiers dans Windows PowerShell ?

A que.Vous avez les commandes Get-ACL et Set-ACL, commencer, Get-ACL est très utile si vous avez besoin de faire état sur autorisations.Franchement, en utilisant ces commandes pour la modifier réellement les autorisations est peu pratique, autorisations de Windows sont choses assez complexes, et la programmation que vous avez à faire pour définir des listes de contrôle d'accès est tout aussi compliquée.Mais qui indique que vous devez utiliser les applets de commande ?Le shell est très utile à l'exécution des outils de ligne de commande plus traditionnelles, et les itérations différentes de l'outil Cacls.exe (y compris celles comme DSACLS pour Active Directory) fonctionnent bien à partir de Windows PowerShell.J'ai toujours les utiliser lorsque requis pour modifier ou définir des autorisations de fichiers et dossiers.

Paramétrez une nouvelle installation de Server Core est un autre excellent exemple.Ajout de rôles, la configuration du réseau, même activation de Windows doivent toutes être effectuées à partir d'une fenêtre de console locale ou via Bureau à distance, à l'aide des outils de ligne de commande.Quels outils existent actuellement sont des solutions de point d'écriture personnalisée qui gèrent une seule tâche ou solutions nécessitant expertise avec WMI (Windows Management Instrumentation).J'aime WMI, mais franchement, il est trop complexe pour la plupart des administrateurs de passer beaucoup de temps formation, et donc il souvent va inutilisé.

Windows PowerShell a promis de faciliter tout cela, en rendant WMI un peu plus faciles à gérer, mais plus important encore, habillage des tâches administratives dans les applets de commande plus faciles à utiliser qui correspondent à peu près avec les utilitaires de ligne de commande pour les années, nous avons utilisé.Problème du shell est que, en dehors de WMI, il est essentiellement un shell local.Nombre de ses cmdlets de configuration du système d'exploitation principal ne proposent aucune prise en charge pour contacter un ordinateur distant.Le shell n'est pas également résoudre un des problèmes plus egregious de WMI : l'utilisation d'appels de procédure distante (RPC) pour la connectivité à distance.RPC sont un problème dans les environnements qui utilisent des pare-feu locales (et qui n'est pas ces jours?), souvent WMI rendre inutilisable pour n'importe quel type de gestion à distance.

La solution

Microsoft a connaissance de ces défauts tout à fait un certain temps, mais il est pris du temps pour tous les correctifs nécessaires à aligner dans un seul produit.Ce produit est Windows PowerShell v2, qui inclut une nouvelle version de Windows Remote Management (WRM).À la fois sera fourni pour la première fois dans Windows 7 et Windows Server 2008 R2 et les deux sera préinstallés sur ces systèmes d'exploitation par défaut.

Les technologies également seront disponibles pour les anciennes versions de Windows, probablement autant DOS que Windows XP.Mais comme la rédaction de cet article, aucune annonce officielle a été sur exactement quels systèmes d'exploitation plus anciens seront prises en charge (l'ancien système d'exploitation, tâche de Microsoft plus difficile, car des versions plus anciennes peuvent ne disposent pas des nécessaires base technologies de prise en charge).

WinRM est réellement la technologie clé qui rend tout ce possible.Il est une implémentation Microsoft de WS-MAN ou les Services Web pour la gestion et comme son nom l'indique, il utilise HTTP et HTTPS pour communiquer, ce qui signifie qu'il est facile d'obtenir le trafic à travers un pare-feu.Contrairement à RPC, qui démarre sur un seul point connu, puis déplacez leur conversation vers un port choisi au hasard, HTTP et HTTPS utilise un seul port, 80 et 443 par défaut, mais configurable si vous n'aimez pas ceux.WinRM permet de nombreuses applications différentes pour "écouter" Gestion des connexions et Windows PowerShell v2 est une application capable de faire.(Personnellement, je pense que WMI peut éventuellement migrer vers utiliser WinRM.)

En fait, vous asseoir sur votre ordinateur client et lui demander d'établir une connexion shell à un ordinateur distant.Qui active WinRM sur l'ordinateur distant, qui tourne à son tour une instance de Windows PowerShell v2 sur l'ordinateur distant.Cette instance du shell est capable d'exécution de vos commandes et la remise les résultats à votre ordinateur.

Voir It dans action

Les versions bêta publique de Windows 7 ont été la première fois le monde au grand de cette essayer : ouvrir une session Windows PowerShell sur le serveur, ou sur plusieurs serveurs, et exécutez Enable-PSRemoting pour configurer WinRM et démarrer le service WinRM.Puis, passez à l'ordinateur client — exécutant également Windows PowerShell v2, et exécuter $ session = Nom_Ordinateur nouveau PSSession, fournissant le nom du serveur que vous venez de configurer pour l'accès distant.La cmdlet New-PSSession peut également accepter autres informations d'identification, si nécessaire et peut être informé à utiliser les ports non standard si c'est ce que vous avez configuré.

Si vous voyez une longue message d'erreur comme celle illustrée dans Figure 1 , il est, en raison de la façon dont WinRM authentifie.Il utilise Kerberos par défaut, mais dans un environnement n'appartenant pas au domaine (tel que celui sur l'ordinateur de test illustrée), Kerberos n'est pas une option.Lorsque Kerberos n'est pas disponible, WinRM exige l'utilisation du transport HTTPS, qui requiert qu'un certificat SSL soit installé sur l'ordinateur serveur.Cela sert à fournir une authentification mutuelle entre vous et le serveur afin que vous savez que vous êtes connecté à l'ordinateur voulu.Même spécification authentification de base ou Digest dans le paramètre –auth n'aide, parce que WinRM veut utiliser HTTPS pour chiffrer ce trafic.La solution plus simple ?Être dans un domaine Active Directory !

La figure 1 authentifie une longue message d'erreur comme cela peut se produire because of le wayWinRM.

Avec votre session est activée, vous êtes prêt commencer l'utiliser.Entrez PSSession $ session va se connecter, direct, au serveur distant.Comme par magie, vous tapez dans son instance de Windows PowerShell.Commandes exécuter de manière interactive et vous constatez immédiatement les résultats, pas à la différence SSH ou des technologies similaires utilisés sur des ordinateurs UNIX.

Windows PowerShell même certains cryptage par défaut, donc si vous n'utilisez pas HTTPS, vous êtes toujours assez fiable contre les écoutes clandestines.Exécutez quitter-PSSession pour détacher la console distante et revenir à votre console locale.Le shell demander même des modifications lorsque vous êtes connecté à un ordinateur distant, pour vous rappeler où vous vous trouvez.

Accès distant un-à-plusieurs

Pouvoir exécuter des commandes sur un ordinateur est grande, mais la fréquence à laquelle vous dois faire une seule chose sur un serveur ?Je trouve plus couramment, que vous devez exécuter une commande ou un ensemble de commandes, sur un groupe entier d'ordinateurs.Ce que nous avons utilisé jusqu'ici dans Windows PowerShell v1 est appelé un-à-un accès distant (1: 1), ce qui signifie un seul administrateur gérer un seul ordinateur distant.Mais l'environnement offre également un-à-plusieurs (1: n) (remoting), où un seul administrateur peut gérer plusieurs ordinateurs.L'astuce est dans le paramètre-ComputerName de nouveau PSSession.

Je vais répéter ma commande antérieure, mais cette fois-ci vous allez réellement épeler le paramètre plutôt que de laisser le shell supposent qu'il : nouveau PSSession –computerName ordinateur.Parce que –computerName est un paramètre positionnel, je n'a pas devez spécifier le nom de paramètre réel précédemment, mais cela maintenant facilitera cette astuce comprendre : sessions $ = New PSSession –computerName (Get-Content c:\names.txt).En supposant que le fichier C:\names.txt contient une liste des noms d'ordinateur, un nom de l'ordinateur par ligne, le shell va créer une session à distance à chacun d'eux stockant la liste complète des sessions dans la variable de sessions $.

Par défaut, les sessions sont créées en utilisant les informations d'identification Windows PowerShell lui-même s'exécute sous, donc mon compte d'ouverture de session ou utilisé avec RunAs au démarrage de l'interpréteur de commandes.Un mot de prudence : Si vous disposez de contrôle (compte d'utilisateur) activé, veillez à démarrer explicitement l'interpréteur de commandes «as Administrator» en cliquant avec le bouton droit sur son icône.Sinon, vous pouvez spécifier un nom d'utilisateur différent pour les sessions à l'aide d'informations d'identification paramètre de la commande.

Une fois cette collection de commandes, vous pouvez continuer à travailler avec les dans la manière de 1: 1: entrez PSSession $ sessions [0] connecte vous à shell instance du premier ordinateur, par exemple.Mais la véritable puissance est en exécutant une commande contre toutes à la fois : Invoke-Command –scriptblock {ipconfig} –session 0 $ sessions.Qui s'exécute la commande Ipconfig sur chaque ordinateur auquel vous avez connecté une session et ramène le résultat à votre ordinateur.Il sera réellement connecté aux ordinateurs en parallèle, de 32 à la fois ; vous pouvez modifier qu'accélérateur de l'exécution en parallèle en utilisant le paramètre –throttlelimit.

Il placer de votre esprit

Bien entendu, parfois vous allez déclencher désactive les commandes qui prennent un certain temps à s'exécuter et vous ne souhaitez pas rester assis autour d'attendre tout Terminer.Dans ce cas, pourquoi ne pas laisser le shell de continuer à travailler dans l'arrière-plan ?Ajoutez simplement le paramètre –AsJob Invoke-Command et le shell créera un travail d'arrière-plan.

N'oubliez pas que votre copie de l'interface n'est pas vraiment effectuant ce volume de travail ; les commandes que vous avez spécifié sont exécutées sur des instances distantes de Windows PowerShell.Votre environnement simplement attend les terminer, et collecter les résultats qu'ils envoient au.Ces résultats sont stockés dans le cadre du travail.Exécutez Get-travail pour voir tous les travaux en cours et leur état (si ils sont toujours exécutés, par exemple).Utilisez réception projet pour récupérer les résultats out of un travail terminé.Par conséquent, tout ressemble à ceci :

$sessions = New-PSSession –computerName (Get-Content c:\names.txt)
$job = Invoke-Command –scriptblock { your command(s) } –AsJob
Get-Job (to check the status)
$results = Receive-Job $job

Vous pouvez afficher les résultats $, filtrer, trier et ainsi de suite. Chaque résultat aura des informations liées à vous voir l'ordinateur d'origine. J'aborderai des travaux en arrière-plan (qui peut avoir même sub-jobs que vous devrez traiter) dans un futur article.

C'est la gestion à distance, établissement nouveau style

Oublier la façon de l'école ancien de gestion «distante» impliquait une randonnée au centre de données ou un bureau à distance «tricher». Fonctionnalités d'accès distant de Windows PowerShell v2 constituent un moyen puissant et simple d'exécuter des commandes, toutes les commandes, sur des ordinateurs distants. Bien que mon personnel porte sur la gestion des serveurs, ces mêmes techniques sont idéal pour les tâches de gestion des postes de travail, ainsi, ce qui est une raison pourquoi Windows PowerShell v2 est préinstallé sur Windows 7, ainsi que Windows Server 2008 R2.

Don Jones est cofondateur de Technologie concentrée, où il blogs hebdomadaire sur Windows PowerShell, SQL Server, App-V et autres rubriques. Contacter via son site Web.