2009-02-06 7 views
4

J'ai essayé d'amener psexec à exécuter des exécutables sur des machines distantes à partir de tâches de construction personnalisées dans Visual Studio. Toutes ces commandes fonctionnent à partir de la ligne de commande mais l'exécuter à partir d'une application semble être un problème. Certaines commandes fonctionnent, sur d'autres psexec se bloque et par conséquent aussi msbuild et Visual Studio 2005. J'appelle stsadm.exe de SharePoint dans ce cas, mais ce problème se produit avec beaucoup de programmes, lors de l'exécution de psexec à partir d'une application. Il y a beaucoup de gens qui ont ce problème, mais il semble qu'il n'y ait pas de solution, alors ma question est: Est-ce que quelqu'un sait une alternative de travail à psexec?psexec inside visual studio

+0

Pouvez-vous nous montrer exactement * comment * vous l'exécutez depuis "dans une application"? – bzlm

+0

Pouvez-vous élaborer sur "Il y a beaucoup de gens qui ont ce problème"? – bzlm

Répondre

0

Il y a toujours RCE.

Remcom est un petit (10KB upx emballé) remoteshell/de remplacement telnet qui permet d'exécuter des processus sur les systèmes Windows à distance, copie des fichiers sur à distance des systèmes, processus, il y a sortie et flux en arrière. Il permet l'exécution de commandes shell à distance directement avec la console interactive complète sans avoir besoin d'installer de logiciel client pour . Sur les machines locales, il est également possible d'usurper l'identité donc peut être utilisé comme un remplacement silencieux pour la commande Runas.

+0

merci pour la réponse. En ce moment je travaille avec mon propre client WMI, mais il échoue de temps en temps – benzhi

+0

Nous échouons tous de temps en temps. Ne t'en fais pas pour ça. – bzlm

0

Vous pouvez essayer d'appeler psexec un programme chauve-souris qui exécute ce dont vous avez besoin sur la machine distante. J'ai rencontré ce problème avec installutil.exe. Un simple fichier bat sur la machine distante l'a résolu.

Vous devriez également partager votre expérience sur le forum sysinternals. Il peut y avoir quelque chose qu'ils peuvent faire dans une future révision.

+0

merci. C'est ainsi que je l'ai résolu en premier, mais le traitement se déroule rapidement et se termine, donc je ne suis pas capable de lire l'info. – benzhi

+0

Est-ce que "pause" ne remédie pas à cela? – bzlm

+0

bien - vous auriez à faire une pause dans le fichier chauve-souris je suppose. – rifferte

1

J'ai vécu 'fige lors de l'exécution PSEXEC contre un système distant, mais je toujours attribué au contexte de sécurité dans lequel le processus à distance a été exécuté sous.

De PSEXEC aide:

Si vous omettez un nom d'utilisateur le processus distant exécute dans le même compte de que vous exécutez PsExec, mais parce que le processus à distance emprunte l'identité, il aura pas accès pour mettre en réseau les ressources sur le système distant. Lorsque vous indiquez un nom d'utilisateur le processus à distance s'exécute dans le compte spécifié, et aura accès à toutes les ressources réseau le compte a accès à. Notez que le mot de passe est transmis en texte clair au système distant .

Si votre exécution d'un processus à distance, qui doit ensuite accéder à la base de données (stsadm.exe), il pourrait alors ne pas essayer d'accéder à la ressource réseau, selon la façon dont PSEXEC a été exécuté. Si c'est le cas, j'imagine que cela finirait par expirer et donner une sorte de message d'indisponibilité de ressource.

Il y a deux choses qui fait généralement lors de l'exécution des étapes de déploiement contre une machine distante pour empêcher le comportement de votre description:

  1. Comme rifferte mentionné, assurez-vous que tous les actifs nécessaires pour Deploy sont locaux à la télécommande machine (fichiers de copie, etc.) avant en utilisant PSEXEC pour exécuter le script (* .bat, .vbs *, * .ps, etc.) - pour que tout fonctionne 'local' à la machine distante.

  2. Run PSEXEC en utilisant un nom d'utilisateur domaine/mot de passe lors exécuter - Notez que ces informations est transmis en clair au serveur distant.