domicile l'Internet

Lancez Bureau à distance. Accès au bureau à distance

Il y avait une tâche pour effectuer une opération en utilisant ligne de commande sur un autre ordinateur, bien sûr, allez à l'utilisateur pour exécuter la ligne de commande et entrer les commandes - pas notre méthode, nous devons démarrer la ligne de commande de l'ordinateur distant sans nous lever de la chaise et effectuer les actions nécessaires sur la commande ligne. Bien sûr, une telle action peut être effectuée à l'aide de programmes de connexion à distance, mais ce n'est pas toujours pratique et nécessite que vous et l'utilisateur (client-serveur) disposiez d'un programme similaire. La procédure de connexion à la ligne de commande d'un autre ordinateur peut être effectuée beaucoup plus simplement à l'aide de la commande PSEXEC.

psexec est un utilitaire de ligne de commande avec la capacité d'invoquer de manière interactive une interface de ligne de commande sur des systèmes Windows distants et d'exécuter diverses commandes à distance.

Cet utilitaire est installé uniquement sur l'ordinateur de l'administrateur. Pour l'installer, vous devez le télécharger, voici le lien vers Site officiel Microsoft . Après avoir téléchargé l'archive, vous devez la décompresser, trouver le fichier PsExec.exe dans le dossier décompressé. Cliquez deux fois dessus, une fenêtre avec un contrat de licence apparaîtra, cliquez sur " Accepter".

Analysons la syntaxe de la commande :

psexec [\\ordinateur[,ordinateur2[,...] | @fichier][-u utilisateur [-p mot de passe]][-ns][-l][-s|-e][-x][-i [session]][-c [-f|-v]] [-w répertoire][-d][-<приоритет>][-a n,n,... ] programme [arguments]

un ordinateur Indique à PsExec d'exécuter l'application sur le ou les ordinateurs spécifiés. Si le nom de l'ordinateur n'est pas spécifié, PsExec exécutera l'application sur le système local ; si le nom de l'ordinateur est un astérisque (\\*), PsExec exécutera l'application sur tous les ordinateurs du domaine actuel.

@fichier Indique à PsExec d'exécuter l'application sur tous les ordinateurs répertoriés dans le fichier texte spécifié.

-une Les processeurs sur lesquels l'application peut être exécutée sont séparés par des virgules et les processeurs sont numérotés à partir de 1. Par exemple, pour exécuter l'application sur les processeurs deux et quatre, tapez "-a 2,4"

-c Le programme spécifié est copié sur le système distant pour exécution. Si ce paramètre n'est pas défini, l'application doit se trouver dans le dossier système du système distant.

-ré Spécifie de ne pas attendre la fin de l'application. Ce paramètre ne doit être utilisé que lors de l'exécution d'applications non interactives.

-e Le profil de compte spécifié n'est pas chargé.

-F Le programme spécifié est copié sur le système distant, même si le fichier existe déjà sur le système distant.

-je Le programme exécuté accède au bureau de la session spécifiée sur le système distant. Si session n'est pas défini, le processus s'exécute dans une session de console.

-l Lorsque le processus démarre, l'utilisateur se voit accorder des droits limités (les droits du groupe Administrateurs sont révoqués et l'utilisateur ne reçoit que les droits attribués au groupe Utilisateurs). Sous Windows Vista, le processus commence par niveau faible fiabilité.

-n Permet de définir le délai de connexion aux ordinateurs distants (en secondes).

-p Vous permet de spécifier un mot de passe facultatif pour le nom d'utilisateur. Si ce paramètre est omis, vous serez invité à saisir un mot de passe et le mot de passe ne s'affichera pas à l'écran.

-s Le processus distant s'exécute à partir du compte système.

-u Vous permet de spécifier un nom d'utilisateur facultatif pour vous connecter au système distant.

-v Le fichier spécifié est copié sur le système distant au lieu de celui existant uniquement si son numéro de version est supérieur ou plus récent.

-w Vous permet de spécifier un répertoire de travail (chemin dans le système distant) pour le processus.

-X Affiche l'interface utilisateur sur le bureau Winlogon (système local uniquement).

-priorité(priorité) Vous permet de définir différentes priorités pour le processus : -low (faible), -belownormal (inférieur à la moyenne), -abovenormal (au-dessus de la moyenne), -high (élevé) ou -realtime (temps réel).

programme Nom du programme à exécuter.

arguments Arguments à transmettre (notez que les chemins de fichiers doivent être spécifiés en tant que chemins locaux sur le système cible).

Exemples de travail en équipe PSEXEC :

1) Pour démarrer la ligne de commande d'un autre ordinateur, vous devez entrer
psexec \\<имя компьюетра>commande

par exemple:
psexec \\WIN782 cmd

après cela, vous pouvez entrer les commandes dont vous avez besoin.

2) Pour exécuter un programme (test.exe dans cet exemple) sur un ordinateur distant, vous devez exécuter la commande (cette commande copie le programme test.exe sur le système distant et l'exécute de manière interactive).

psexec \\<имя компьютера>-c test.exe

par exemple:
psexec \\WIN782-c test.exe

3) Si un tel programme est déjà installé sur le système distant et ne se trouve pas dans le répertoire système, indiquez le chemin complet vers ce programme

psexec \\WIN782 c:\temp\test.exe

Dans les versions serveur précédentes de Windows, un administrateur devait utiliser les services Terminal Server pour gérer le serveur à distance. L'inconvénient de cette solution était la nécessité de déployer les services Terminal Server même lorsque l'administrateur n'avait besoin que d'une seule connexion à distance pour effectuer des tâches administratives de routine. Windows XP et Windows Server 2003 ont un mécanisme standard Bureau à distance pour l'administration, ou simplement Remote Desktop, qui permet de se connecter à distance et d'effectuer les opérations nécessaires à la gestion du serveur. Ce mécanisme est basé sur les services Terminal Server et prend en charge deux connexions distantes simultanées (sous Windows XP - une). Un administrateur peut administrer tous les serveurs exécutant Windows Server 2003 à partir de n'importe quel poste de travail en s'y connectant à distance.

Noter
Le mécanisme Bureau à distance pour l'administration n'est pas essentiellement le même que le mode d'administration à distance pris en charge par les services Terminal Server de Windows 2000. Dans Windows Server 2003, la tâche d'administration à distance est séparée des services Terminal Server et implémentée en tant que mécanisme distinct. La séparation du mécanisme d'administration à distance des services Terminal Server a permis de réduire au minimum la charge sur le serveur dans une situation où vous n'avez besoin de gérer le serveur qu'à partir d'un autre ordinateur.

Windows XP et Windows Server 2003 disposent également d'une fonction d'assistance à distance qui permet à l'utilisateur d'initier l'accès à son ordinateur et d'obtenir de l'aide dans des situations difficiles (voir la section suivante).

Noter
Par défaut, les fonctionnalités Bureau à distance et Assistance à distance sont désactivées.

De plus, si un serveur Web est installé sur un ordinateur exécutant Windows XP ou Windows Server 2003 dans le cadre d'Internet Information Services (IIS), vous pouvez accéder à distance à tout système Windows XP ou Windows Server 2003 qui se trouve sur cet ordinateur via cet ordinateur. même réseau local, à partir d'un navigateur Web (Internet Explorer 4.0 et supérieur) fonctionnant sur n'importe quel système d'exploitation. Cette fonctionnalité permet, par exemple, sur un ordinateur peu gourmand sous Windows 95 de lancer un navigateur et, en saisissant le nom d'un système distant Windows Server 2003 basé sur un processeur puissant, de travailler dessus en mode plein écran.
Toutes les sessions d'accès à distance sont cryptées pour empêcher tout accès non autorisé aux données et aux systèmes : le protocole RDP utilisé est crypté à l'aide de l'algorithme RC4.

Autorisation d'accès à distance

Pour contrôler le mode d'accès à distance (ne le confondez pas avec l'accès à distance via une connexion commutée !) Utilisez l'onglet Remote (Utilisation à distance) de la fenêtre System Properties (Fig. 10.9). (Pour accéder rapidement à cette fenêtre, vous pouvez utiliser les touches +.)
Pour permettre aux utilisateurs d'autres ordinateurs d'accéder à votre système, cochez la case Autoriser les utilisateurs à se connecter à distance à cet ordinateur. En cliquant sur le bouton Sélectionner les utilisateurs distants, vous pouvez spécifier explicitement quels utilisateurs sont autorisés à accéder à distance (Figure 10.10) : ces utilisateurs seront inclus dans le groupe local Utilisateurs du Bureau à distance. Par défaut, seuls les administrateurs ont accès à distance à l'ordinateur.
Vous ne pouvez pas utiliser de comptes sans mot de passe pour l'accès à distance. S'il existe de telles entrées sur l'ordinateur, lorsque vous cochez la case Autoriser les utilisateurs à se connecter à distance à cet ordinateur, un avertissement apparaît, comme illustré à la Fig. 10.11.

Riz. 10.9. Fenêtre de contrôle du Bureau à distance et de l'Assistance à distance

Riz. 10.10. Les utilisateurs spécifiés dans cette fenêtre seront autorisés à accéder à distance au bureau de l'ordinateur

Riz. 10.11. Un rappel que les comptes sans mot de passe ne peuvent pas être utilisés pour accéder à distance à un ordinateur

L'utilitaire Connexion Bureau à distance permet d'initialiser une session d'accès à distance (il se lance depuis le sous-menu Démarrer | Tous les programmes | Accessoires | Communications ou à l'aide de la commande mstsc depuis la ligne de commande). Entrez le nom ou l'adresse IP de l'ordinateur distant et cliquez sur le bouton Connecter (Figure 10.12) - et dans quelques instants, vous verrez une fenêtre vous invitant à vous connecter au système distant !

Attention

Riz. 10.11. Un rappel que les comptes sans mot de passe ne peuvent pas être utilisés pour accéder à distance à un ordinateur

Démarrage et configuration d'une session d'accès à distance

L'utilitaire Connexion Bureau à distance permet d'initialiser une session d'accès à distance (il se lance depuis le sous-menu Démarrer | Tous les programmes | Accessoires | Communications ou à l'aide de la commande mstsc de la ligne de commande). Entrez le nom ou l'adresse IP de l'ordinateur distant et cliquez sur le bouton Connecter (Figure 10.12) - et dans quelques instants, vous verrez une fenêtre vous invitant à vous connecter au système distant !

Riz. 10.12. Depuis cette fenêtre, vous pouvez initier une session avec un ordinateur distant

Attention

Sur les systèmes Windows XP, la connexion à l'aide du Bureau à distance "expulse" l'utilisateur actuel du système sans fermer la session en cours. Si un utilisateur distant se connecte avec le nom d'un utilisateur déjà enregistré, il obtient alors l'environnement de travail - fenêtres ouvertes, programmes en cours d'exécution - de cet utilisateur, qui à son tour peut se reconnecter et repousser "l'étranger". Ce n'est qu'en utilisant l'assistance à distance qu'il est possible pour deux utilisateurs de travailler dans la même session en même temps. Cela ne se produit pas dans Windows Server 2003 car ils autorisent deux sessions pour l'administration à distance. Cependant, si vous utilisez la commande mstsc /console, vous pouvez obtenir le même mode de fonctionnement que dans Windows XP, c'est-à-dire avec "push".
Dans la fenêtre Connexion Bureau à distance, cliquez sur le bouton Options et examinez attentivement tous les onglets qui définissent les options de connexion à distance. Vous pouvez, par exemple, définir la taille de l'écran, la profondeur de couleur (jusqu'à 24 bits), la vitesse de connexion, etc. Faites attention à l'onglet Ressources locales (Fig. 10.13).

Riz. 10.13. Onglet qui contrôle la réaffectation des appareils locaux

Par défaut, le son de l'ordinateur distant est redirigé vers l'ordinateur local et vous pouvez imprimer sur l'imprimante locale tout en travaillant sur l'ordinateur distant. Si vous cochez la case Lecteurs de disque, vous pouvez utiliser les disques des deux systèmes en même temps. C'est très pratique, par exemple, pour copier des fichiers: "d'un coup de poignet" dans la fenêtre de l'Explorateur Windows (où les disques des deux ordinateurs seront affichés), vous pouvez copier n'importe quelle information d'un ordinateur distant vers votre disque local .
L'onglet Expérience (Fig. 10.14) vous permet d'adapter la session d'accès à distance aux paramètres de connexion : vous pouvez désactiver certaines fonctionnalités graphiques pour les canaux à faible débit et activer toutes les fonctionnalités lorsque vous êtes connecté via un réseau local.

Riz. 10.14. Configuration des paramètres d'accès à distance en fonction de la vitesse du canal de communication

Pour passer la fenêtre de la session du plein écran à l'écran à taille fixe et inversement, utilisez les touches ++

Les systèmes Windows Server 2003 utilisent le composant logiciel enfichable Bureaux à distance pour accéder aux services Terminal Server. Il peut également être utilisé pour l'accès à distance aux ordinateurs. Sur la fig. La figure 10.15 montre un exemple de connexion à deux ordinateurs distants (serveur distant et contrôleur de domaine) en même temps. Chaque session est pré-créée et configurée (voir Racine du composant logiciel enfichable et arbre de session d'accès à distance), après quoi elle peut être facilement lancée en pointant sur le curseur dans la liste. Vous pouvez également basculer facilement entre différentes sessions.

Riz. 10.15. Fenêtre du composant logiciel enfichable Bureaux à distance avec deux sessions d'accès à distance simultanées

Quitter une session

Lorsqu'il travaille dans une session d'accès à distance à un ordinateur, l'administrateur dispose de trois options pour mettre fin à la session (dans tous les cas, il doit ouvrir le menu Démarrer (Démarrer) et cliquer sur le bouton Arrêter (Fin du travail)) :

vous pouvez éteindre l'ordinateur en sélectionnant l'option Arrêter dans la fenêtre Arrêter Windows ;
vous pouvez vous déconnecter du système en sélectionnant l'option Déconnexion ;
vous pouvez mettre fin à la session en cours en sélectionnant l'option Déconnecter - dans ce cas, lors de la reconnexion à cet ordinateur avec le nom précédemment utilisé, l'administrateur recevra le même environnement de travail (fenêtres ouvertes et programmes en cours d'exécution) qu'il a "laissé" lors de la déconnexion de la session.

Accès à distance via Internet

Pour accéder à votre ordinateur via Internet, entrez http:// dans le champ d'adresse de votre navigateur.<имя_cepвepa>/TSWeb , où nom_serveur est le nom DNS du serveur Web (ordinateur avec IIS installé) ou son adresse IP.

Riz. 10.16. Fenêtre de connexion Internet ordinateur distant

Une fois connecté au serveur, la page Web Connexion Web Bureau à distance apparaîtra (Figure 10.16), où dans le champ Serveur vous devez spécifier le nom ou l'adresse de l'ordinateur auquel vous souhaitez vous connecter, puis cliquez sur le bouton Connecter. Veuillez noter que les noms du serveur Web et de l'ordinateur cible peuvent différer : c'est-à-dire que vous vous "connectez" au réseau via un ordinateur, mais que vous vous connectez à n'importe quel autre.

Attention
Pour que le mode décrit fonctionne, le composant Connexion Web Bureau à distance doit être installé sur le serveur dans le cadre du service WWW (World Wide Web Service).

La première fois que vous suivez cette procédure, le serveur télécharge le composant ActiveX que vous devez installer sur votre ordinateur local. Sa fenêtre est illustrée à la Fig. 10.17. Cliquez sur le bouton Oui.

Riz. 10.17. Avertissement concernant l'installation d'un composant ActiveX sur un ordinateur local

Après cela, une connexion est établie avec l'ordinateur sélectionné (cible) et la fenêtre d'enregistrement traditionnelle apparaît. Sur la fig. 10.18 par exemple, une fenêtre de navigateur Internet Explorer s'affiche, qui affiche une session sur un ordinateur distant. Veuillez noter que la fenêtre d'adresse affiche l'adresse IP d'un ordinateur (par lequel nous sommes entrés dans le réseau) et que la connexion est établie avec un autre ordinateur - son adresse est indiquée en bas de l'écran. Rappelez-vous qu'une telle image peut être obtenue dans n'importe quel système d'exploitation sur lequel Internet Explorer version 4.0 et supérieure est installé. En mode plein écran, les panneaux du navigateur ne sont pas du tout affichés et nous ne verrons que le bureau de l'ordinateur distant.

Riz. 10.17. Avertissement concernant l'installation d'un composant ActiveX sur un ordinateur local

L'une des tâches les plus courantes pour les administrateurs système consiste à exécuter une commande sur un ordinateur distant. Cela peut être nécessaire pour installer un programme ou un utilitaire, modifier des paramètres, etc. On parle rarement d'un seul ordinateur, plus souvent une commande est nécessaire exécuter sur plusieurs postes de travail ou serveurs.

Étant donné que ce problème est populaire, il existe de nombreuses façons de le résoudre. À partir des stratégies de groupe (dans lesquelles vous pouvez utiliser des scripts de connexion ou de démarrage à cette fin), et se terminant par des systèmes puissants gestion, comme System Center Essentials ou System Center Configuration Manager. Mais dans cet article, je veux considérer les méthodes qui sont disponibles immédiatement à partir de la ligne de commande ou des fichiers de script, et qui ne nécessitent pas non plus de pré-installation d'agents et d'autres tracas. Cependant, il y a bien sûr quelques prérequis. Par exemple, vous devez disposer de privilèges administratifs sur l'ordinateur sur lequel vous souhaitez exécuter la commande (sauf pour le scénario "proxy", mais nous y reviendrons plus tard).

L'un de mes moyens préférés pour accomplir cette tâche est l'utilitaire de ligne de commande PsExec.exe écrit par Mark Russinovich, que vous pouvez télécharger gratuitement à partir du site Web Windows SysInternals. Vous trouverez un lien vers celui-ci à la fin de l'article. Il ne nécessite pas d'installation sur le système, vous pouvez simplement le copier dans l'un des dossiers contenus dans la variable d'environnement %path% et l'appeler depuis n'importe quel shell de ligne de commande : Cmd ou PowerShell.

L'utilisation de PsExec est très simple. Par exemple, pour exécuter ipconfig /flushdns sur la machine principale, exécutez simplement la commande suivante :

psexec \\main ipconfig /flushdns

La commande ipconfig sera exécutée sur l'ordinateur principal sous vos informations d'identification. Une fois ipconfig terminé, toutes les sorties de texte seront envoyées à votre ordinateur, plus le code de sortie de la commande (code d'erreur) sera renvoyé. Si la commande a réussi, ce sera 0.

Bien sûr, les possibilités de PsExec ne s'arrêtent pas là. En appelant l'utilitaire sans paramètres, vous pouvez voir les autres options disponibles. Je vais me concentrer sur quelques-uns d'entre eux.

Le commutateur -d indique à PsExec qu'il n'est pas nécessaire d'attendre que la commande soit exécutée, mais simplement de l'exécuter et de l'oublier. Dans ce cas, nous ne recevrons pas de données de sortie de l'utilitaire de console, mais nous pourrons en exécuter d'autres sans attendre la fin de la commande précédente. Ceci est très utile si vous devez exécuter, par exemple, un programme d'installation sur plusieurs ordinateurs.

Par défaut, PsExec exécute les commandes en mode furtif, c'est-à-dire qu'aucune fenêtre ou boîte de dialogue ne sera affichée sur le système où la commande est exécutée. Cependant, il est possible de modifier ce comportement en utilisant l'option -i. Après cela, vous pouvez spécifier le numéro de la session dans laquelle afficher les fenêtres, ou vous ne pouvez pas le spécifier, puis l'interface sera affichée dans la session de la console.

Donc, pour faire apparaître une fenêtre avec des informations sur la version système opérateur sur la machine principale, vous devez exécuter PsExec comme ceci :

psexec -i \\main winver.exe

Si vous souhaitez exécuter une commande sur plusieurs ordinateurs à la fois, vous aurez besoin de pouvoir lire leurs noms à partir d'un fichier texte de liste.

psexec @c:\comps.txt systeminfo.exe

Eh bien, l'une des fonctionnalités les plus utiles de PsExec est la possibilité de rediriger de manière interactive les entrées / sorties entre ordinateurs, ce qui nous permet d'exécuter, par exemple, cmd.exe sur un serveur distant, de lui donner des commandes et d'obtenir des résultats sur le local l'ordinateur.

Comment fonctionne Psexec ?

Tout ingénieux est simple. Les ressources de l'exécutable PsExec.exe incluent un autre exécutable, PSEXESVC, qui est un service Windows. Avant d'exécuter la commande, PsExec décompresse cette ressource dans un dossier partagé administratif caché sur l'ordinateur distant, dans le fichier : \\ComputerName\Admin$\system32\psexesvc.exe. Si vous avez indiqué avec le commutateur -c que vous souhaitez copier des fichiers exécutables sur ce système, ils seront également copiés dans ce dossier.

Une fois les étapes préparatoires terminées, PsExec installe et démarre le service à l'aide des API Windows Service Management. Après le démarrage de PSEXESVC, plusieurs canaux sont créés entre lui et PsExec pour transférer des données (commandes d'entrée, résultats, etc.). Une fois terminé, PsExec arrête le service et le supprime de l'ordinateur cible.

Instrumentation de gestion Windows (WMI)

La prochaine façon d'implémenter cette tâche populaire dont je veux parler consiste à utiliser Windows Management Instrumentation. WMI est présent dans tous les systèmes d'exploitation Microsoft depuis Windows 2000, et même sur Windows 9x, il peut être installé à partir d'un package séparé. WMI est activé par défaut et ne nécessite aucune configuration supplémentaire. Pour l'utiliser, les droits d'administration sont suffisants, et le protocole DCOM autorisé sur le pare-feu. WMI fournit une multitude d'options pour la gestion des systèmes, mais nous ne nous intéressons qu'à l'une d'entre elles pour le moment.

Pour démarrer des processus, nous avons besoin de la méthode Create de la classe Win32_Process. C'est assez facile à utiliser. Dans PowerShell, cela se fait comme ceci :

$Ordinateur = "principal"
$Command = "cmd.exe /c systeminfo.exe >
("\\$Ordinateur\root\cimv2:Win32_Process").create ($Command)

Ici, j'ai spécifié cmd.exe comme processus à lancer, et je l'ai déjà passé en arguments commande désirée. Cela est nécessaire au cas où vous auriez besoin d'utiliser les variables d'environnement de l'ordinateur distant ou des instructions cmd.exe intégrées telles que ">" pour rediriger la sortie vers un fichier. La méthode Create n'attend pas la fin du processus et ne renvoie aucun résultat, mais nous indique à la place son ID - ProcessID.

Si vous utilisez un ordinateur sur lequel PowerShell n'est pas encore installé, vous pouvez également appeler cette méthode WMI à partir d'un script VBScript. Par exemple comme ceci :

Liste #1 - Démarrage d'un processus à l'aide de WMI (VBScript)

Ordinateur="PC3"
Commande = "cmd.exe /c systeminfo.exe > \\server\share\%computername%.txt"
Set objWMIService = GetObject("winmgmts:\" & Computer & "\root\cimv2:Win32_Process")
Résultat = objWMIService.Create("calc.exe", Null, Null, intProcessID)

Mais il est beaucoup plus facile d'utiliser l'utilitaire de ligne de commande wmic.exe, qui fournit une interface assez pratique pour travailler avec WMI et est inclus dans les systèmes d'exploitation à partir de Windows XP. Dans celui-ci, pour exécuter, par exemple, une calculatrice sur l'ordinateur principal, il suffit d'exécuter la commande suivante :

wmic /node:appel de processus principal créer calc.exe

Bien entendu, les capacités de WMI ne se limitent pas au démarrage de processus. Si vous souhaitez en savoir plus sur cette technologie, je vous recommande de lire les articles de Konstantin Leontiev sur WMI, dont vous trouverez les liens à la fin de l'article.

Script distant WSH

Oui, curieusement, Windows Script Host a également la possibilité d'exécuter des scripts sur d'autres ordinateurs. Certes, cette fonction n'a pas reçu beaucoup de popularité, et très probablement en raison du fait qu'elle nécessite trop d'activités préparatoires et offre en retour très peu d'opportunités. Mais je vais quand même parler de cette méthode, car elle peut être utile.

Ainsi, pour exécuter le script sur un autre ordinateur à l'aide de WSH, nous devons procéder comme suit :

Droits d'administrateur sur l'ordinateur distant. Cela va sans dire et est requis pour presque toutes les autres méthodes de démarrage répertoriées dans cet article. Activez WSH Remote Scripting en définissant la valeur de la chaîne Remote sur « 1 » dans le registre système dans la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings wscript –regserver command Si un pare-feu est utilisé sur les ordinateurs, il doit autoriser l'accès à DCOM. De plus, cela doit être fait non seulement sur l'ordinateur géré, mais également sur celui à partir duquel vous souhaitez exécuter le script. Sur les systèmes Windows XP avec Service Pack 2 et versions ultérieures, vous devez modifier les paramètres de sécurité DCOM. Cela peut être fait en utilisant la stratégie de groupe. Sous Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Politiques locales\Options de sécurité, définissez les autorisations comme suit : DCOM : Restrictions d'accès à la machine dans la syntaxe SDDL (Security Descriptor Definition Language)
Accordez aux groupes Connexion anonyme et Tout le monde les autorisations Autoriser l'accès local et Autoriser l'accès à distance DCOM : Restrictions de lancement de la machine dans la syntaxe SDDL (Security Descriptor Definition Language)
Accordez au groupe Administrateurs les autorisations Autoriser le lancement local, Autoriser le lancement à distance, Autoriser l'activation locale, Autoriser l'activation à distance
Groupe Tout le monde - Autoriser le lancement local, Autoriser l'activation locale

Eh bien, après toutes ces procédures, vous pouvez essayer d'exécuter votre script sur un autre ordinateur.

Un exemple de script utilisant cette technologie :

Liste #2 - Script distant WSH (VBScript)

Set objController = CreateObject("WshController")
Set objRemoteScript = objController.CreateScript("C:\test.vbs", "PC5")WScript.ConnectObject objRemoteScript, "remote_"
objRemoteScript.Execute
Faire pendant que objRemoteScript.Status 1
WScript.Veille 1000
boucle
MsgBox "Script terminé"
Sous-télécommande_Erreur
Dim objErreur
Définir objError = objRemoteScript.Error
WScript.Echo "Erreur - Ligne : " & objError.Line & _
", Car: " & objError.Caractère & vbCrLf & _
"Description : " & objErreur.Description
WScript Quitter -1
fin sous

Sur sa deuxième ligne, en tant que paramètres de la fonction CreateScript, le chemin d'accès au fichier de script qui sera exécuté sur l'ordinateur distant et le nom réel de cet ordinateur sont indiqués.

Planificateur de tâches

Le planificateur de tâches peut être contrôlé à partir de la ligne de commande à l'aide de deux utilitaires - at.exe et schtasks.exe. Ces deux utilitaires vous permettent de spécifier le nom d'un ordinateur distant pour créer un travail, et vous permettent donc de résoudre notre problème. Mais en détail, nous ne considérerons que schtasks.exe, car il offre beaucoup plus de fonctionnalités.

Bien que l'exécution de commandes sur d'autres ordinateurs ne soit pas l'objectif principal du planificateur, il vous permet néanmoins de mettre en œuvre de nombreux scénarios intéressants. Par exemple, il peut être utilisé pour activer l'installation Logiciel pendant la pause déjeuner. Ou si vos utilisateurs dînent à temps différent, le lancement peut être effectué après une certaine période d'inactivité de l'ordinateur.

schtasks /create /s server6.td.local /tn install /tr \\main\data\install.cmd /sc once /st 13:00 /ru system

Il est important de comprendre pour le compte de quel compte la tâche sera exécutée. Dans cet exemple, j'ai spécifié le paramètre /ru à la valeur système, par conséquent, pour terminer l'installation du compte d'ordinateur, vous aurez besoin d'un accès en lecture au dossier réseau avec le kit de distribution du programme.

Une autre solution utile, me semble-t-il, consiste à planifier une action pour une exécution quotidienne et à ne supprimer la tâche que lorsque son succès est confirmé. Autrement dit, vous pouvez créer un fichier de commandes simple qui exécute d'abord le programme d'installation du programme, attend qu'il se termine et vérifie si le programme a été installé avec succès. Si c'est le cas, il supprime la tâche du planificateur sur cet ordinateur. Un exemple d'un tel fichier :

Liste #3 - Installation du programme puis suppression de la tâche (Windows Batch)

msiexec /qn /package \\server\share\subinacl.msi
s'il existe "c:\program files\Windows Resource Kits\Tools\subinacl.exe" (
subinacl /tn Install_Subinacl /f
)

WinRM (gestion WS)

WinRM est l'implémentation par Microsoft du standard ouvert DMTF (Distributed Management Task Force) qui permet de gérer les systèmes à l'aide de services Web. Je n'approfondirai pas le dispositif de la technologie, mais ne décrirai que brièvement ce qui est nécessaire à son utilisation.

WinRM version 1 et supérieure est inclus avec les systèmes d'exploitation commençant par Windows Vista et Windows Server 2008. Pour Windows XP et Windows Server 2003, vous pouvez installer WinRM en tant que package séparé (voir liens).

Afin de configurer rapidement un ordinateur pour les connexions à celui-ci en utilisant des ports standard et en autorisant les connexions aux comptes administratifs, exécutez simplement la commande :

configuration rapide winrm

Pour empêcher winrm de demander une confirmation, vous pouvez ajouter le commutateur -quiet à l'appel. Pour plus d'informations sur le réglage fin, consultez l'aide intégrée de winrm :

configuration de l'aide winrm

Si l'ordinateur géré exécute un serveur Web, WinRM n'interférera en aucune façon avec lui, même s'il utilise des ports HTTP standard par défaut. Il n'interceptera que les connexions qui lui sont spécifiquement destinées.

Bien sûr, vous n'avez pas besoin d'exécuter cette commande manuellement sur chaque ordinateur que vous souhaitez gérer. Tous les paramètres nécessaires peuvent être facilement définis à l'aide de stratégies de groupe. Pour cela, vous avez besoin de :

Configurez le service WinRM (Windows Remote Management) pour qu'il démarre automatiquement Configurez l'élément Configuration ordinateur \ Modèles d'administration \ Composants Windows \ Gestion à distance Windows (WinRM) \ Service WinRM \ Autoriser la configuration automatique des écouteurs GPO. Ici, vous devez spécifier les plages d'adresses IP à partir desquelles les connexions sont autorisées. Bien sûr, vous devrez également autoriser les connexions sur les ports appropriés (80 par défaut) dans le pare-feu Windows.

Que le port HTTP (80) ou HTTPS (443) soit utilisé, le trafic transmis par WinRM est crypté (sauf si vous désactivez cette option, bien sûr). Le protocole d'authentification par défaut est Kerberos.

Mais assez parlé des réglages, il vaut mieux passer directement à l'utilisation. Bien que l'utilitaire winrm vous permette de configurer le service WinRM, ainsi que d'exécuter des requêtes WMI, par exemple, nous sommes plus intéressés par un autre - winrs. Les lettres RS signifient ici Remote Shell. WinRS fonctionne de manière très similaire à PsExec, bien qu'il utilise la technologie WinRM. Le nom de l'ordinateur est spécifié avec le commutateur -r, suivi de la commande à exécuter. Voici quelques exemples:

winrs -r:Core ver.exe

Étant donné que winrs utilise déjà cmd.exe comme shell distant, vous pouvez facilement accéder aux variables d'environnement distantes dans les commandes ou utiliser d'autres commandes cmd.exe intégrées :

winrs -r:Core "répertoire c:\temp > c:\temp\list.txt"

Comme PsExec, l'utilitaire winrs permet d'ouvrir une session interactive sur un poste distant :

winrs -r:main cmd.exe

Cette fonction est similaire à une session telnet, mais l'utilisation de winrs est nettement meilleure que telnet et même PsExec, du point de vue de la sécurité. Que le port HTTP (80) ou HTTPS (443) soit utilisé, le trafic transmis par WinRM est crypté (sauf si vous désactivez cette option, bien sûr). Le protocole d'authentification par défaut est Kerberos.

Accès à distance Windows PowerShell 2.0

Bien que la deuxième version de Windows PowerShell soit encore en test bêta au moment de la rédaction, à propos de ses capacités dans le domaine exécution à distance les équipes valent vraiment la peine d'être évoquées en ce moment. Vous pouvez l'essayer vous-même en téléchargeant la version d'aperçu (voir liens) ou dans le cadre de la version bêta de Windows 7 ou Windows Server 2008 R2.

L'infrastructure PowerShell Remoting est basée sur WinRM version 2.0, et hérite donc de tous les avantages de cette technologie, comme le chiffrement des données transmises, et la possibilité de travailler sur des ports HTTP/HTTPS standards. Mais grâce à la richesse du langage Windows PowerShell et à sa capacité à travailler avec des objets, nous avons encore plus d'opportunités. Sur le ce moment WinRM2.0 est également en version bêta et n'est disponible en téléchargement que sur les systèmes Windows Vista et Windows 2008. Il sera intégré aux systèmes Windows 7 et Windows Server 2008R2 prêt à l'emploi, avec PowerShell 2.0.

Mise à jour : Au moment où l'article a été publié sur ItBand.ru, les versions finales de PowerShell 2.0 et WinRM 2.0 sont déjà disponibles pour toutes les plateformes prises en charge. Ils sont déjà inclus dans Windows Server 2008R2 et Windows 7 en tant que composants intégrés du système, et pour Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, tous les composants nécessaires peuvent être obtenus sous forme de package appelé Windows Management Framework.

Avant de pouvoir profiter pleinement de ces avantages, PowerShell Remoting doit être activé à la fois sur le gestionnaire et sur les ordinateurs gérés. Ceci est facile à faire en exécutant l'applet de commande (commande Windows PowerShell) Enable-PSRemoting. De plus, si vous ajoutez la clé -Force, aucune confirmation ne vous sera demandée. Cette applet de commande appellera winrs quickconfig si nécessaire et créera des exceptions dans le pare-feu Windows, donc aucune autre action n'est requise.

Vous pouvez ensuite facilement exécuter des commandes sur d'autres ordinateurs à l'aide de l'applet de commande Invoke-Command (ou son alias icm) :

Invoke-Command -ComputerName Main -ScriptBlock (vidage de l'interface netsh > c:\ipconfig.txt)

Bien sûr, la commande peut être placée dans une variable à l'avance, et pour le paramètre -ComputerName, spécifiez les noms non pas d'un, mais de plusieurs ordinateurs à la fois. La séquence suivante vous permet d'afficher la version du fichier Explorer.exe à partir de trois ordinateurs à la fois.

$Command = ((get-item c:\Windows\explorer.exe).VersionInfo.FileVersion)
Invoke-Command -ComputerName Main, Server7, Replica -ScriptBlock $Command

Comme vous pouvez le constater, vous pouvez transmettre plusieurs commandes à la fois dans un bloc, placer leurs résultats d'exécution sur plusieurs ordinateurs dans une variable, puis les traiter sur le poste de travail à l'aide des fonctionnalités de gestion d'objets de Windows PowerShell.

Cependant, les possibilités de PowerShell Remoting ne font que commencer. Vous pouvez utiliser l'applet de commande Enter-PSSession pour ouvrir une session Windows PowerShell interactive sur un ordinateur distant. Vous pouvez quitter une telle session à l'aide de l'applet de commande Exit-PSSession ou simplement quitter.

L'applet de commande New-PSSession crée des sessions sur des ordinateurs distants, des pointeurs vers lesquels peuvent être placés dans une variable, puis passés en argument à Invoke-Command pour exécuter des commandes sur plusieurs ordinateurs à la fois, dans un environnement persistant. Vous pouvez voir un exemple dans la capture d'écran, où j'exécute une séquence de commandes sur plusieurs ordinateurs à la fois à partir de la liste c:\computers.txt.

Proxy

Cette méthode diffère de tout ce qui précède et remplit des tâches complètement différentes, mais non moins pertinentes. Lorsque la délégation d'autorité n'est pas possible, ou fournit trop de pouvoir, elle permet à un utilisateur normal d'exécuter une commande qui nécessite des privilèges administratifs sans accorder d'autorité supplémentaire de quelque manière que ce soit ni compromettre le mot de passe administrateur.

Le plus souvent, les gens résolvent ces problèmes en utilisant des utilitaires comme cpau.exe (voir liens) qui créent un fichier avec un mot de passe de compte administratif crypté qui vous permet d'exécuter un certain programme. Le problème, cependant, est que même si le mot de passe est chiffré, l'utilitaire devra le déchiffrer avant d'exécuter le programme. Et en conséquence, l'utilisateur peut utiliser un utilitaire qui répète l'algorithme de déchiffrement du mot de passe et le découvre, afin de l'utiliser ensuite pour lancer d'autres programmes ou obtenir des privilèges supplémentaires. En pratique, c'est bien sûr assez difficile pour les utilisateurs ordinaires qui n'ont pas de connaissances particulières, mais, néanmoins, c'est tout à fait possible. Encore une fois, je préciserai que ce n'est pas le problème d'un utilitaire particulier, mais le problème de cette approche en général.

Il peut également sembler que l'option /savecred de l'utilitaire runas convient pour résoudre le problème. Mais il y a même deux problèmes ici. Premièrement, comme dans le cas décrit ci-dessus, le mot de passe est stocké sur l'ordinateur de l'utilisateur et peut donc être déchiffré, bien que dans le cas des runas, cela nécessitera des droits d'administrateur local. Deuxièmement, runas enregistre les informations d'identification sans les lier à une commande spécifique et, par conséquent, l'utilisateur pourra exécuter avec des droits élevés non seulement la commande à laquelle vous vouliez lui donner accès, mais également toute autre.

Pour éviter ces problèmes, mais tout en permettant l'exécution d'une commande particulière, une technique appelée "proxying" peut être utilisée.

Cela fonctionne comme suit. Un script avec des privilèges élevés s'exécute en permanence sur l'ordinateur. Par exemple, dans notre cas, il sera lancé depuis un compte disposant des droits d'administrateur sur le serveur de fichiers. Au signal de l'utilisateur, il exécutera une commande prédéfinie. Dans cet exemple, fermez tous les fichiers ouverts sur le réseau.

Pour organiser ce système, nous placerons sur le serveur, par exemple, dans le dossier c:\scripts\, les fichiers batch Server.cmd et Action.cmd .

Liste #4 - Server.cmd (Windows Batch)

set trigger=c:\commandShare\trigger.txt
définir action=c:\scripts\action.cmd
définir log=c:\scripts\log.txt
:démarrer
s'il existe %trigger% start %action% & echo %time% %date%>>%log% & del %trigger%
sleep.exe 5
aller commencer

Liste #5 - Action.cmd (Windows Batch)

for /f "skip=4 tokens=1" %%a in ('net files') do net files %%a /close
sortir

Server.cmd attendra un signe de l'utilisateur (création d'un fichier dans Un certain endroit), et après l'avoir reçu, exécutez le fichier avec les commandes - Action.cmd. Bien sûr, les utilisateurs ne doivent pas avoir accès à ce dossier. Le lancement automatique de Server.cmd au démarrage de l'ordinateur peut être organisé en créant simplement la tâche appropriée dans le planificateur :

schtasks /create /ru domaine\administrateur /rp /sc onstart /tn ProxyScript /tr c:\scripts\server.cmd

Après le paramètre /ru, le compte sous lequel le script sera exécuté est indiqué (dans notre cas, il a des droits d'administrateur sur le serveur), puisque le mot de passe n'est pas spécifié après le paramètre /rp - il sera demandé lors de la création du tâche. L'option /sc vous permet de spécifier quand le script s'exécutera, dans notre cas, lorsque l'ordinateur est allumé. Eh bien, /tn et /tr permettent de spécifier le nom de la tâche, et le fichier exécutable.

Maintenant, pour que l'utilisateur signale le script, nous allons créer un dossier c:\commandShare et le rendre disponible sur le réseau. Seuls les utilisateurs qui exécuteront la commande doivent avoir un accès en écriture à ce dossier.

Après cela, il suffira de placer le fichier Run.cmd sur le bureau de l'utilisateur.

Liste #6 - Run.cmd (Windows Batch)

test d'écho > \\server\commandShare\trigger.txt

Lorsqu'il est exécuté, au nom de l'utilisateur, le fichier \\server\commandShare\trigger.txt sera créé. Le script Server.cmd, l'ayant remarqué, exécutera le fichier Action.cmd avec ses privilèges, ajoutera une entrée au fichier c:\scripts\log.txt à propos de l'heure actuelle, puis supprimera le trigger.txt afin de ne pas pour exécuter à nouveau la commande jusqu'au prochain signal utilisateur .

Le script Server.cmd utilise l'utilitaire Sleep.exe pour interrompre l'exécution du script pendant une période spécifiée en secondes. Il n'est pas inclus dans le système d'exploitation, mais il peut être extrait des outils du kit de ressources (voir liens) et simplement copié sur n'importe quel ordinateur.

Utile

Vous avez décidé d'apprendre une langue étrangère ? précepteur langue Anglaise vous aidera avec cela. Vous pouvez également vous entraîner avec d'autres utilisateurs.

L'une des tâches les plus courantes des administrateurs système consiste à exécuter une commande sur un ordinateur distant sans quitter votre siège. Cela peut être nécessaire pour installer un programme ou un utilitaire, modifier certains paramètres ou toute autre chose. Et bien sûr, il s'agit rarement d'un seul ordinateur, le plus souvent la commande doit être exécutée sur plusieurs postes de travail ou serveurs.

Étant donné que ce problème est populaire, il existe de nombreuses façons de le résoudre. En partant des stratégies de groupe (qui peuvent utiliser des scripts de connexion ou de démarrage à cette fin) et en terminant par de puissants systèmes de gestion tels que System Center Essentials ou System Center Configuration Manager. Mais dans cet article, je veux considérer les méthodes qui sont disponibles immédiatement à partir de la ligne de commande ou des fichiers de script, et qui ne nécessitent pas non plus de pré-installation d'agents et d'autres tracas. Cependant, il y a bien sûr quelques prérequis. Par exemple, vous devez disposer de privilèges administratifs sur l'ordinateur sur lequel vous souhaitez exécuter la commande (sauf pour le scénario "proxy", mais nous y reviendrons plus tard).

Psexec.exe

L'utilisation de PsExec est très simple. Par exemple, pour exécuter ipconfig /flushdns sur la machine principale, exécutez simplement la commande suivante :

psexec \\main ipconfig /flushdns

Clé -ré indique à PsExec qu'il n'est pas nécessaire d'attendre l'exécution de la commande, mais simplement de l'exécuter et de l'oublier. Dans ce cas, nous ne recevrons pas de données de sortie de l'utilitaire de console, mais nous pourrons en exécuter d'autres sans attendre la fin de la commande précédente. Ceci est très utile si vous devez exécuter, par exemple, un programme d'installation sur plusieurs ordinateurs.

Par défaut, PsExec exécute les commandes en mode furtif, c'est-à-dire qu'aucune fenêtre ou boîte de dialogue ne sera affichée sur le système où la commande est exécutée. Cependant, il est possible de modifier ce comportement à l'aide de la touche -je. Après cela, vous pouvez spécifier le numéro de la session dans laquelle afficher les fenêtres, ou vous ne pouvez pas le spécifier, puis l'interface sera affichée dans la session de la console.

Ainsi, pour afficher une fenêtre avec des informations sur la version du système d'exploitation sur l'ordinateur principal, vous devez exécuter PsExec comme ceci :

psexec -i \\main winver.exe

Si vous souhaitez exécuter une commande sur plusieurs ordinateurs à la fois, vous aurez besoin de pouvoir lire leurs noms à partir d'un fichier texte de liste.

psexec @c:\comps.txt systeminfo.exe

Comment fonctionne Psexec ?

Tout ingénieux est simple. Les ressources de l'exécutable PsExec.exe incluent un autre exécutable, PSEXESVC, qui est un service Windows. Avant d'exécuter la commande, PsExec décompresse cette ressource dans un dossier partagé administratif caché sur l'ordinateur distant, dans le fichier : \\ComputerName\Admin$\system32\psexesvc.exe. Si vous avez indiqué avec le commutateur -c que vous souhaitez copier des fichiers exécutables sur ce système, ils seront également copiés dans ce dossier.

Une fois les étapes préparatoires terminées, PsExec installe et démarre le service à l'aide des API Windows Service Management. Après le démarrage de PSEXESVC, plusieurs canaux sont créés entre lui et PsExec pour transférer des données (commandes d'entrée, résultats, etc.). Une fois terminé, PsExec arrête le service et le supprime de l'ordinateur cible.

Instrumentation de gestion Windows (WMI)

Pour démarrer des processus, nous avons besoin de la méthode Create de la classe Win32_Process. C'est assez facile à utiliser. Dans PowerShell, cela se fait comme ceci :

$Ordinateur = "principal"
$Command = "cmd.exe /c systeminfo.exe >
("\\$Ordinateur\root\cimv2:Win32_Process").create($Command)

Ici, j'ai spécifié cmd.exe comme processus à lancer et j'ai déjà passé la commande nécessaire en tant qu'arguments. Ceci est nécessaire si vous avez besoin d'utiliser les variables d'environnement de l'ordinateur distant ou les instructions cmd.exe intégrées telles que " > ' pour rediriger la sortie vers un fichier. La méthode Create n'attend pas la fin du processus et ne renvoie aucun résultat, mais nous indique à la place son ID - ProcessID.

Si vous utilisez un ordinateur sur lequel PowerShell n'est pas encore installé, vous pouvez également appeler cette méthode WMI à partir d'un script VBScript. Par exemple comme ceci :

Liste #1 - Démarrage d'un processus à l'aide de WMI (VBScript)

Ordinateur="PC3"
Commande = "cmd.exe /c systeminfo.exe > \\server\share\%computername%.txt"
Set objWMIService = GetObject("winmgmts:\\" & Computer & "\root\cimv2:Win32_Process")
Résultat = objWMIService.Create("calc.exe", Null, Null, intProcessID)

wmic /node:appel de processus principal créer calc.exe

Script distant WSH

Ainsi, pour exécuter le script sur un autre ordinateur à l'aide de WSH, nous devons procéder comme suit :

Droits d'administrateur sur l'ordinateur distant. Cela va sans dire et est requis pour presque toutes les autres méthodes de démarrage répertoriées dans cet article.

Activez WSH Remote Scripting en créant le paramètre de chaîne Remote égal à "1" dans le registre système dans la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings

En raison du bogue décrit dans l'article 311269 de la base de connaissances Microsoft, sur les systèmes Windows XP, vous devrez peut-être exécuter wscript –regserver

Si un pare-feu est utilisé sur les ordinateurs, il doit autoriser l'accès à DCOM. De plus, cela doit être fait non seulement sur l'ordinateur géré, mais également sur celui à partir duquel vous souhaitez exécuter le script.

Sur les systèmes Windows XP avec Service Pack 2 et versions ultérieures, vous devez modifier les paramètres de sécurité DCOM. Cela peut être fait en utilisant la stratégie de groupe. Dans le nœud Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité, définissez les autorisations comme suit :

DCOM : Restrictions d'accès à la machine dans la syntaxe SDDL (Security Descriptor Definition Language)
Accorder aux groupes Connexion anonyme et Tout le monde Autoriser les autorisations locales et Autoriser l'accès à distance

DCOM : Restrictions de lancement de machine dans la syntaxe SDDL (Security Descriptor Definition Language)
Accordez au groupe Administrateurs les autorisations Autoriser le lancement local, Autoriser le lancement à distance, Autoriser l'activation locale, Autoriser l'activation à distance
Groupe Tout le monde - Autoriser le lancement local, Autoriser l'activation locale

Eh bien, après toutes ces procédures, vous pouvez essayer d'exécuter votre script sur un autre ordinateur.

Un exemple de script utilisant cette technologie :

Liste #2 - Script distant WSH (VBScript)

Set objController = CreateObject("WshController")
Set objRemoteScript = objController.CreateScript("C:\test.vbs", "PC5")WScript.ConnectObject objRemoteScript, "distant_"
objRemoteScript.Execute
Faire pendant que objRemoteScript.Status<> 1
WScript.Veille 1000
boucle
MsgBox "Script terminé"
Sous-télécommande_Erreur
Dim objErreur
Définir objError = objRemoteScript.Error
WScript.Echo "Erreur - Ligne : " & objError.Line & _
", Car: " & objError.Caractère & vbCrLf & _
"Description : " & objErreur.Description
WScript Quitter -1
fin sous

Un article plus détaillé sur cette technologie se trouve dans l'article VBScript avancé pour les administrateurs Microsoft Windows – Chapitre 6 : Script à distance(voir liens).

Planificateur de tâches

Bien que l'exécution de commandes sur d'autres ordinateurs ne soit pas l'objectif principal du planificateur, il vous permet néanmoins de mettre en œuvre de nombreux scénarios intéressants. Par exemple, il peut être utilisé pour permettre l'installation du logiciel pendant la pause déjeuner. Ou si vos utilisateurs déjeunent à des heures différentes, vous pouvez lancer après une certaine période d'inactivité de l'ordinateur.

schtasks /create /s server6.td.local /tn install /tr \\main\data\install.cmd /sc once /st 13:00 /ru system

Liste #3 - Installation du programme puis suppression de la tâche (Windows Batch)

msiexec /qn /package \\server\share\subinacl.msi
s'il existe "c:\program files\Windows Resource Kits\Tools\subinacl.exe" (
subinacl /tn Install_Subinacl /f

WinRM (gestion WS)

configuration rapide winrm

Pour empêcher winrm de demander une confirmation, vous pouvez ajouter le commutateur -quiet à l'appel. Pour plus d'informations sur le réglage fin, consultez l'aide intégrée de winrm :

configuration de l'aide winrm

Configurer le service WinRM (Windows Remote Management) pour qu'il démarre automatiquement
Configurez l'élément de stratégie de groupe Configuration ordinateur \ Modèles d'administration \ Composants Windows \ Gestion à distance Windows (WinRM) \ Service WinRM \ Autoriser la configuration automatique des écouteurs. Ici, vous devez spécifier les plages d'adresses IP à partir desquelles les connexions sont autorisées.
Bien sûr, vous devrez également autoriser les connexions sur les ports appropriés (80 par défaut) dans le pare-feu Windows.

winrs -r:Core ver.exe

winrs -r:Core "répertoire c:\temp > c:\temp\list.txt"

Comme PsExec, l'utilitaire winrs permet d'ouvrir une session interactive sur un poste distant :

winrs -r:main cmd.exe

Accès à distance Windows PowerShell 2.0

Bien que la deuxième version de Windows PowerShell soit encore en test bêta au moment d'écrire ces lignes, ses capacités dans le domaine de l'exécution de commandes à distance valent vraiment la peine d'être évoquées maintenant. Vous pouvez l'essayer vous-même en téléchargeant la version d'aperçu (voir liens) ou dans le cadre de la version bêta de Windows 7 ou Windows Server 2008 R2.

L'infrastructure PowerShell Remoting est basée sur WinRM version 2.0, et hérite donc de tous les avantages de cette technologie, comme le chiffrement des données transmises, et la possibilité de travailler sur des ports HTTP/HTTPS standards. Mais grâce à la richesse du langage Windows PowerShell et à sa capacité à travailler avec des objets, nous avons encore plus d'opportunités. WinRM2.0 est également actuellement en version bêta et n'est disponible en téléchargement que sur les systèmes Windows Vista et Windows 2008. Il sera intégré aux systèmes Windows 7 et Windows Server 2008R2 prêt à l'emploi, tout comme PowerShell 2.0.

Mise à jour : Au moment où l'article a été publié sur le site, les versions finales de PowerShell 2.0 et WinRM 2.0 sont déjà disponibles pour toutes les plateformes prises en charge. Ils sont déjà inclus dans Windows Server 2008R2 et Windows 7 en tant que composants intégrés du système, et pour Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, tous les composants nécessaires peuvent être obtenus sous forme de package appelé Windows Management Framework.

Vous pouvez ensuite facilement exécuter des commandes sur d'autres ordinateurs à l'aide de l'applet de commande Invoke-Command (ou son alias icm) :

Invoke-Command -ComputerName Main -ScriptBlock (vidage de l'interface netsh > c:\ipconfig.txt)

$Command = ((get-item c:\Windows\explorer.exe).VersionInfo.FileVersion)
Invoke-Command -ComputerName Main, Server7, Replica -ScriptBlock $Command

Proxy

Pour éviter ces problèmes, tout en permettant à une commande particulière de s'exécuter, une technique appelée "mandat" peut être utilisée.

Pour organiser ce système, nous placerons sur le serveur, par exemple, dans le dossier c:\scripts\, les fichiers batch Server.cmd et Action.cmd .

Liste #4 - Server.cmd (Windows Batch)

Liste #5 - Action.cmd (Windows Batch)

for /f "skip=4 tokens=1" %%a in ('net files') do net files %%a /close
sortir

Server.cmd attendra un signe de l'utilisateur (créer un fichier à un certain endroit) et, après l'avoir reçu, exécutera le fichier avec les commandes - Action.cmd. Bien sûr, les utilisateurs ne doivent pas avoir accès à ce dossier. Le lancement automatique de Server.cmd au démarrage de l'ordinateur peut être organisé en créant simplement la tâche appropriée dans le planificateur :

schtasks /create /ru domaine\administrateur /rp /sc onstart /tn ProxyScript /tr c:\scripts\server.cmd

Après cela, il suffira de placer le fichier Run.cmd sur le bureau de l'utilisateur.

Liste #6 - Run.cmd (Windows Batch)

test d'écho > \\server\commandShare\trigger.txt

Vous souhaiterez probablement tirer parti de la prise en charge multi-moniteurs intégrée à l'outil Windows Vista (Remote Desktop). Cette fonctionnalité vous permet d'étendre le bureau d'un ordinateur distant sur tous les moniteurs connectés au système local.

Cependant, il n'est pas facile de le trouver - il n'est pas accessible depuis l'interface utilisateur graphique de l'outil, mais depuis la ligne de commande.

Restrictions

La prise en charge de plusieurs moniteurs lors de la connexion à un poste de travail distant est une fonctionnalité très pratique, mais elle présente deux limites :

1. Tous les moniteurs connectés au système doivent avoir la même résolution.

2. La résolution d'écran de tous les moniteurs, y compris ceux du système distant, ne doit pas dépasser 4096 x 2048 pixels.

Ligne de commande

Pour lancer la connexion Bureau à distance avec prise en charge multi-écrans, vous devez ouvrir une invite de commande et saisir la commande suivante :

Après cela, la boîte de dialogue standard Connexion Bureau à distance s'ouvrira, dans laquelle vous devrez configurer les paramètres de connexion (voir Fig. A).

Figure A Lors du démarrage d'une connexion Bureau à distance à partir de la ligne de commande, les paramètres de connexion devront être renseignés manuellement.

Une fois la connexion établie, le bureau du système distant apparaîtra sur tous les moniteurs connectés au système local. Si vous avez besoin à la fois d'un bureau local et d'un bureau distant, vous pouvez limiter la taille de ce dernier à un seul moniteur en cliquant sur le bouton "Restaurer vers le bas" dans la fenêtre du bureau distant. Vous pouvez également utiliser des raccourcis clavier pour cela.

Une fois que la fenêtre du bureau à distance apparaît sur le moniteur, elle peut être étirée avec la souris pour remplir tout l'écran. Gardez à l'esprit que si vous réduisez la taille de la fenêtre étendue du bureau à distance, vous devrez utiliser les barres de défilement horizontales et verticales pour voir l'intégralité de l'écran, comme illustré à la Fig. B. Mais il peut toujours être restauré en cliquant sur le bouton Agrandir.

Figure B Lorsque vous réduisez la taille de la fenêtre étirée du poste de travail distant, vous devez utiliser les barres de défilement horizontale et verticale pour voir l'intégralité de l'écran.

Créer un raccourci

Bien sûr, lancer Connexion Bureau à distance à partir de la ligne de commande à chaque fois n'est pas très pratique. Si vous disposez déjà d'un fichier de paramètres de connexion Bureau à distance RDP enregistré, vous pouvez créer un raccourci Windows standard pour vous connecter à l'aide de ce fichier et des options de ligne de commande.

Cliquez sur clic-droit souris n'importe où sur le bureau et sélectionnez Nouveau | Raccourci" (Nouveau | Raccourci). Dans la boîte de dialogue Créer un raccourci de l'assistant, entrez la commande mstsc /span et le chemin d'accès au fichier RDP, comme illustré à la figure 1. C. S'il y a des espaces dans l'adresse du fichier, assurez-vous de l'inclure entre guillemets doubles. Cliquez maintenant sur "Suivant" (Suivant), attribuez le raccourci nom approprié, par exemple, "Saturne - Connecter. avec plusieurs moniteurs" et cliquez sur "Terminer".

Figure C Vous pouvez créer un raccourci Windows standard pour vous connecter à l'aide d'un fichier RDP et d'options de ligne de commande.

Maintenant, en utilisant ce raccourci, vous pouvez vous connecter à un ordinateur distant en utilisant tous les moniteurs disponibles. Bien sûr, lors de l'ouverture de plusieurs fenêtres, le bureau étendu se comportera différemment que lorsque vous travaillez avec plusieurs moniteurs sur le système local - vous devrez faire preuve d'imagination et redimensionner les fenêtres afin qu'elles tiennent toutes confortablement sur le bureau distant.

Qu'est-ce que tu penses?

Combien de moniteurs sont connectés à votre ordinateur ? À quelle fréquence utilisez-vous Connexion Bureau à distance ? Utiliserez-vous la prise en charge multi-écrans de la connexion Bureau à distance de Vista ? Partagez votre opinion avec nous dans les commentaires !