Hello, I have an .exe file which updates an application on various clients. From my Application Server, I start a master script, and then this calls a second script which I use to execute commands on the client. The commands are to test for a directory, test to see if a process is running, write to a log, and if everything is good, I would then like it to kick off my .exe file located on each client to update the application. Everything works except for the execution of the .exe file. I have tried many things, usually I can see the background process in Task Manager, but it shows no CPU. It takes 2 hours to finish (where if I run it manually it is 5-10 minutes) and then none of my files were changed, so it basically does nothing.
I have also updated my master script, getting a list of machines in an array, starting a for loop, and for each item creating a session, followed by the various commands using Invoke-command -computername -session session -scriptblock. The results are the same.
I would like the process to avoid waiting for the first client to update before starting the next, otherwise it will take all night.
On my test client, I set the execution policy for currentuser, localmachine, and process to unrestricted. I can create a ps1 on my test client locally and run it using start-process command, but if I create a master on my client which calls this same test script, I have the same behavior, where either no process starts or a process starts but does nothing. Am I missing a step?
Let me know if a copy of the code would help.
Thanks
This all sounds very virus author like stuff — 8^}
Anyway, all that being said. Why not take a more direct route?
- Copy the script and the .exe to a file share that all users / computer have access to.
- Create a scheduled Task on the remote computer, which only runs once, if the use is logged on and calls the script from that file share.
- Capture the results to a log file and send that log file to yourself.
I have around 100 clients and as we onboard more employees, we will have more. I was hoping to not have to touch each client machine. The application needs to be run locally on the client machine. Shouldn’t I be able to have a master script, which calls a child script to run on multiple clients where the client script then executes some steps, such as testing the path, shutting down existing processes of the app, writing to a log file, and executing an application? Or is this not possible in PowerShell? or at least run a non-powershell script remotely?
I went to my test machine and created two simple scripts to open Notepad. The client script has the command to open Notepad and it works when running it individually (Start-Process -Filepath Notepad). But when I create a master to call this client, it fails (Invoke-Command -Computername computername -Filepath c:\scripts\client_script.ps1)
If your application/tools does not already exits on the remote host (as part of the image process) is not there, you are going to have to get it there, logically or physically, or the client must be able to reach it remotely, logically or physically.
When users onboard and you give them a system, on first logon, in normal cases a logon script runs to configure the new client for the domain. You tools can be pushed to the client at that time.
No reason for you physically to touch each client manually or even via some remote script on your workstation. BTW you remoting from one source to another is touching each client machine anyway.
Using this master child approach is really kind of moot as you can do this with one script in conditional logic / workflow way.
PowerShell is not meant to be able to runs scripts from a remote machine as the logged in user. That is a Windows security
boundary. If you are running script / exe on remote machine and you need it to run in the context of the current user, you
either have to use a logon script, scheduled task or other tools like SysInternals PSExec, or AutoIt. Now, you can use PS and PSexec together for there given benefits.
To use PSRemoting commands like Invoke-* and many others, you must be an admin on the remote machine. There are only a few commands / cmdlets you can ruin against a remote machine as non-Admin as documented on TechNet.
Otherwise, you could just use PSRemoting to as many clients as you see fit, call the script from your workstation and run it against the remote hosts. Yet, again that is running in your user context, not a remote user identity.