Pour plusieurs raisons, principalement liées à la sécurité, les scripts PowerShell ne sont pas aussi facilement portables et utilisables que les scripts batch. Cependant, nous pouvons regrouper un script batch avec nos scripts PowerShell pour contourner ces problèmes. Ici, nous allons vous montrer quelques uns de ces problèmes, et comment créer un script batch pour les contourner.

Pourquoi ne puis-je pas simplement copier mon fichier .PS1 sur un autre ordinateur et l'exécuter?

À moins que le système cible n'ait été préconfiguré pour permettre l'exécution de scripts arbitraires, avec les privilèges requis et en utilisant les bons paramètres, il est probable que vous rencontriez des problèmes lorsque vous essayerez de le faire.

1. PowerShell est non associé à l'extension de fichier .PS1 par défaut. Nous en avons d'abord parlé dans notre série PowerShell Geek School. Windows associe les fichiers .PS1 au Bloc-notes par défaut, au lieu de les envoyer à l'interpréteur de commandes PowerShell. Cela permet d'éviter l'exécution accidentelle de scripts malveillants en double-cliquant simplement dessus. Vous pouvez changer ce comportement de différentes façons, mais ce n'est probablement pas ce que vous voulez faire sur tous les ordinateurs sur lesquels vous dirigez vos scripts, surtout si certains de ces ordinateurs ne vous appartiennent pas.
2. PowerShell n'autorise pas les connexions externes exécution de script par défaut. Le paramètre ExecutionPolicy dans PowerShell empêche l'exécution de scripts externes par défaut dans toutes les versions de Windows. Dans certaines versions de Windows, la valeur par défaut n'autorise pas l'exécution de script. Nous vous avons montré comment modifier ce paramètre dans Comment autoriser l'exécution de scripts PowerShell sous Windows 7. Toutefois, vous ne voulez pas non plus faire cela sur n'importe quel ordinateur.
3. Certains scripts PowerShell ne fonctionneront pas sans Autorisations d'administrateur. Même si vous utilisez un compte au niveau administrateur, vous devez toujours passer par le contrôle de compte d'utilisateur (UAC) pour effectuer certaines actions. Nous ne voulons pas désactiver cela, mais c'est toujours agréable quand nous pouvons le rendre un peu plus facile à gérer.
4. Certains utilisateurs peuvent avoir des environnements PowerShell personnalisés.
   Vous ne rencontrerez probablement pas ce problème souvent, mais Lorsque vous le faites, cela peut rendre l'exécution et le dépannage de vos scripts un peu frustrants. Heureusement, nous pouvons contourner cela sans apporter de modifications permanentes.

Etape 1: Double-cliquez pour lancer

Commençons par aborder le premier problème - associations de fichiers .PS1. Vous ne pouvez pas double-cliquer pour exécuter des fichiers .PS1, mais vous pouvez exécuter un fichier .BAT de cette façon. Nous allons donc écrire un fichier batch pour appeler le script PowerShell depuis la ligne de commande pour nous.

Nous n'avons donc pas besoin de réécrire le fichier batch pour chaque script, ou chaque fois que nous déplaçons un script, il va utiliser une variable auto-référençant pour construire le chemin du fichier pour le script PowerShell. Pour que cela fonctionne, le fichier batch doit être placé dans le même dossier que votre script PowerShell et avoir le même nom de fichier. Donc, si votre script PowerShell s'appelle "MyScript.ps1", vous devrez nommer votre fichier batch "MyScript.bat" et vous assurer qu'il se trouve dans le même dossier. Ensuite, placez ces lignes dans le script batch:

@ECHO OFF PowerShell.exe -Command "& '% ~ dpn0.ps1'" PAUSE

S'il n'y avait pas les autres restrictions de sécurité en place, cela vraiment tout ce qu'il faut pour exécuter un script PowerShell à partir d'un fichier batch. En fait, la première et la dernière lignes sont principalement une question de préférence - c'est la deuxième ligne qui fait vraiment le travail. Voici la répartition:

@ECHO OFF désactive la commande en écho. Cela empêche que vos autres commandes n'apparaissent à l'écran lors de l'exécution du fichier batch. Cette ligne est elle-même masquée par l'utilisation du symbole at (@) devant elle.

PowerShell.exe -Command "& '% ~ dpn0.ps1'" exécute réellement le script PowerShell. PowerShell.exe peut bien sûr être appelé à partir de n'importe quelle fenêtre ou fichier batch CMD pour lancer PowerShell sur une console vide comme d'habitude. Vous pouvez également l'utiliser pour exécuter des commandes directement à partir d'un fichier batch, en incluant le paramètre -Command et les arguments appropriés. La façon dont ceci est utilisé pour cibler notre fichier .PS1 est avec la variable spéciale% ~ dpn0. Exécuté à partir d'un fichier de commandes,% ~ dpn0 évalue la lettre de lecteur, le chemin du dossier et le nom de fichier (sans extension) du fichier de traitement par lots. Étant donné que le fichier de commandes et le script PowerShell seront dans le même dossier et portent le même nom,% ~ dpn0.ps1 se traduira par le chemin complet du script PowerShell.

PAUSE interrompt simplement l'exécution du lot et attend la saisie de l'utilisateur. Il est généralement utile d'avoir à la fin de vos fichiers de traitement par lot, de sorte que vous ayez la possibilité d'examiner toute sortie de commande avant que la fenêtre ne disparaisse. Au fur et à mesure que nous testons chaque étape, l'utilité devient plus évidente.

Le fichier batch de base est donc configuré. À des fins de démonstration, ce fichier est enregistré sous "D: Script Lab MyScript.bat" et il y a un "MyScript.ps1" dans le même dossier. Voyons voir ce qui se passe quand on double-clique sur MyScript.bat.

Évidemment, le script PowerShell ne s'est pas exécuté, mais c'est à prévoir - nous avons seulement abordé le premier de nos quatre problèmes, après tout. Cependant, il y a quelques bits importants démontrés ici:

1. Le titre de la fenêtre montre que le script batch a lancé PowerShell avec succès.
2. La première ligne de sortie montre qu'un profil PowerShell personnalisé est utilisé. Il s'agit du problème potentiel n ° 4, répertorié ci-dessus.
3. Le message d'erreur indique les restrictions ExecutionPolicy en vigueur. C'est notre problème # 2.
4. La partie soulignée du message d'erreur (qui est faite nativement par la sortie d'erreur de PowerShell) montre que le script batch ciblait correctement le script PowerShell prévu (D: Script Lab MyScript.ps1). Nous savons donc au moins que beaucoup fonctionne correctement.

Le profil, dans ce cas, est un simple script d'une ligne utilisé pour cette démonstration afin de générer une sortie à chaque fois que le profil est actif. Vous pouvez également personnaliser votre propre profil PowerShell pour ce faire, si vous souhaitez tester ces scripts vous-même. Ajoutez simplement la ligne suivante à votre script de profil:

Write-Output 'Profil PowerShell personnalisé en vigueur!'

La méthode ExecutionPolicy du système de test est définie sur RemoteSigned. Cela permet l'exécution de scripts créés localement (comme le script de profil), tout en bloquant les scripts provenant de sources externes, sauf s'ils sont signés par une autorité de confiance. À des fins de démonstration, la commande suivante a été utilisée pour marquer MyScript.ps1 comme provenant d'une source externe:

Add-Content -Path 'D:  Script Lab  MyScript.ps1' -Value "[ZoneTransfer] 'nZoneId = 3 "-Stream" Zone.Identifier '

Cela définit le flux de données alternatif Zone.Identifier sur MyScript.ps1 afin que Windows pense que le fichier provient d'Internet. Il peut être facilement annulé avec la commande suivante:

Clear-Content -Path 'D:  Script Lab  MyScript.ps1' -Stream 'Zone.Identifier'

Étape 2: Déplacer ExecutionPolicy.

Obtenir autour du paramètre ExecutionPolicy, à partir de CMD ou d'un script batch, est en fait assez facile. Nous modifions simplement la deuxième ligne du script pour ajouter un paramètre supplémentaire à la commande PowerShell.exe

PowerShell.exe -ExecutionPolicy Bypass -Command "& '% ~ dpn0.ps1'"

Le paramètre -ExecutionPolicy peut être utilisé pour modifier la stratégie d'exécution utilisée lorsque vous générez une nouvelle session PowerShell. Cela ne persistera pas au-delà de cette session, de sorte que nous pouvons exécuter PowerShell comme ça chaque fois que nous en avons besoin sans affaiblir la posture de sécurité générale du système. Maintenant que nous avons corrigé cela, essayons d'en faire un autre:

Maintenant que le script a été correctement exécuté, nous pouvons voir ce qu'il fait réellement. Cela nous permet de savoir que nous exécutons le script en tant qu'utilisateur limité. Le script est en fait exécuté par un compte avec des autorisations d'administrateur, mais le contrôle de compte d'utilisateur devient gênant. Bien que les détails sur la façon dont le script recherche l'accès administrateur dépassent la portée de cet article, voici le code utilisé pour la démonstration:

if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrateur")) {Write-Output 'Exécution en tant qu'administrateur!'} Else {Write-Output 'Running Limited!'} Pause

Vous remarquerez également qu'il y a maintenant deux opérations "Pause" dans la sortie du script - une du script PowerShell et une du fichier batch. La raison pour cela sera plus évidente à l'étape suivante.

Étape 3: Obtenir l'accès Administrateur

Si votre script n'exécute aucune commande nécessitant une élévation, et que vous êtes sûr que vous ne l'aurez pas Pour vous inquiéter des profils personnalisés d'un utilisateur, vous pouvez ignorer le reste. Si vous exécutez des cmdlets de niveau Administrateur, vous aurez besoin de cette pièce.

Malheureusement, il n'existe aucun moyen de déclencher le contrôle de compte d'utilisateur pour l'élévation à partir d'un fichier de traitement par lots ou d'une session CMD. Cependant, PowerShell nous permet de le faire avec Start-Process. Lorsqu'il est utilisé avec "-Verb RunAs" dans ses arguments, Start-Process essayera de lancer une application avec des permissions d'administrateur. Si la session PowerShell n'est pas déjà élevée, une invite UAC est déclenchée. Pour l'utiliser à partir du fichier batch pour lancer notre script, nous allons générer deux processus PowerShell: l'un pour lancer Start-Process et l'autre, lancé par Start-Process, pour exécuter le script. La deuxième ligne du fichier de commandes doit être remplacée par ceci:

PowerShell.exe -Command "& {Démarrer-Process PowerShell.exe -ArgumentList '-ExecutionPolicy Contourner -File" "% ~ dpn0.ps1" "' - Verb RunAs} "

Lorsque le fichier batch est exécuté, la première ligne de sortie que nous verrons provient du script de profil PowerShell. Ensuite, il y aura une invite UAC lorsque Start-Process essayera de lancer MyScript.ps1.

Après avoir cliqué sur l'invite UAC, une nouvelle instance de PowerShell apparaît. Comme il s'agit d'une nouvelle instance, nous verrons à nouveau l'avis de script de profil. Ensuite, MyScript.ps1 s'exécute et nous voyons que nous sommes en effet dans une session élevée.

Et il y a la raison pour laquelle nous avons aussi deux pauses ici. Si ce n'est pas le cas dans le script PowerShell, nous ne verrons jamais la sortie du script - la fenêtre PowerShell apparaîtra et disparaîtra dès que le script sera exécuté. Et sans la pause dans le fichier batch, nous ne serions pas en mesure de voir s'il y a eu des erreurs de lancement de PowerShell en premier lieu.

Etape 4: Contournement des profils PowerShell personnalisés.

Débarrassons-nous de cette méchante avis de profil personnalisé maintenant, devons-nous? Ici, ce n'est même pas une nuisance, mais si le profil PowerShell d'un utilisateur modifie les paramètres, les variables ou les fonctions par défaut d'une manière que vous n'avez peut-être pas prévue avec votre script, ils peuvent être très gênants. Il est beaucoup plus simple d'exécuter votre script sans le profil, donc vous n'avez pas à vous en préoccuper. Pour ce faire, nous avons juste besoin de changer une seconde fois la deuxième ligne du fichier batch:

PowerShell.exe -NoProfile -Command "& {Démarrer-traiter PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File" "% ~ dpn0.ps1" "'-Verb RunAs}"

L'ajout du paramètre -NoProfile aux deux instances de PowerShell lancées par le script signifie que le script de profil de l'utilisateur sera complètement ignoré dans les deux étapes et dans notre script PowerShell fonctionnera dans un environnement par défaut assez prévisible. Ici, vous pouvez voir qu'il n'y a aucun avis de profil personnalisé dans l'un des shells générés

Si vous n'avez pas besoin de droits d'administrateur dans votre script PowerShell et que vous avez ignoré l'étape 3, vous pouvez vous passer de la seconde instance PowerShell la deuxième ligne de votre fichier batch doit ressembler à ceci:

PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '% ~ dpn0.ps1'"

La sortie ressemblera à ceci:

( Bien sûr, pour les scripts non-administrateur, vous pouvez également vous passer d'une pause de fin de script dans votre script PowerShell, puisque tout est capturé dans la même fenêtre de console et sera retenu par la pause à la fin du script.

Fichiers batch complétés.

Selon que vous ayez ou non besoin d'autorisations d'administrateur pour votre script PowerShell (et que vous ne devriez pas les demander si ce n'est pas le cas), le dernier fichier de commandes devrait ressembler comme l'un des deux ci-dessous.

Sans accès administrateur:

@ECHO OFF PowerShell.exe -NoProfile -ExecutionPoli cy Bypass -Command "& '% ~ dpn0.ps1'" PAUSE

Avec un accès administrateur:

@ECHO OFF PowerShell.exe -NoProfile -Command "& {Démarrer-traiter PowerShell.exe -ArgumentList '-NoProfile - ExecutionPolicy Bypass -File "% ~ dpn0.ps1 " '-Verb RunAs} "PAUSE

N'oubliez pas de placer le fichier séquentiel dans le même dossier que le script PowerShell pour lequel vous voulez l'utiliser, et donnez-lui le même nom . Ensuite, quel que soit le système sur lequel vous utiliserez ces fichiers, vous serez en mesure d'exécuter votre script PowerShell sans avoir à manipuler les paramètres de sécurité du système. Vous pouvez certainement effectuer ces modifications manuellement à chaque fois, mais cela vous évite ce problème et vous n'aurez plus à vous soucier de revenir sur ces modifications plus tard.

Références:

• Exécution de scripts PowerShell à partir d'un fichier batch - Blog de programmation de Daniel Schroeder
• Vérification des autorisations d'administrateur dans PowerShell - Hey, Scripting Guy! Blog

Comment "Trusted Devices" fonctionne sur Windows 10 (et pourquoi vous n'avez plus besoin de "faire confiance à ce PC")

Windows 8 vous a demandé de "Trust this PC" après vous être connecté avec un compte Microsoft. Ce message est parti dans Windows 10, remplacé par un nouveau système "Trusted Devices" qui fonctionne différemment. Comment "Trust This PC" fonctionnait sous Windows 8 Sous Windows 8, un message vous demandait de "Faites confiance à ce PC" après vous être connecté avec votre compte Microsoft.

(how-to)

Sauvegarde et restauration de votre téléphone Android avec Titanium Backup

Si vous voulez vraiment sauvegarder votre téléphone Android, y compris des données de l'application système aux nœuds Wi-Fi sauvegardés, Titanium Backup peut vous aider. Lisez la suite pour apprendre comment sauvegarder votre téléphone Android de A à Z. Pourquoi s'embêter avec une application de sauvegarde tierce?

(how-to)