Getting Started
The purpose of this page is to introduce how RemoteLaunch works, and some of its key concepts. There is also a section that walks you though a simple example to get you started.
Topics on this Page
Often, you are presented with the need to run a command, or collect a piece of data such as a registry entry, a file version, or a log file from multiple machines.
Sometimes you need to do something even bigger like set a registry entry, remove or install a piece of software, force a Group Policy update or WSUS update, or run a custom script.
To accomplish some of these tasks, you could of course take a manual approach. For some actions such as reading or changing a registry entry, you could remotely connect Regedit to
each machine, and make the change. For others, such as launching a script or MSI, you could go over to each machine and perform the action locally. This is fine when it's just
a few machines. However, if the number of machines is too large, the manual approach becomes prohibitive.
One step up from that is launching your command remotely. PSExec is the prefect tool for this, but is limited to performing your command on one machine. It also limits you
to running one command on one machine. If you need to run multiple commands, you now only need to write a script to run them, but write a wrapper script to copy your script
over to the remote machine first, and then have PSEXEC launch it.
RemoteLaunch picks up from there, and lets you run a command on multiple machines - any list that you paste in. It also lets you see progress, and results. Finally, it lets
you run your script directly, without worrying about copying it to the remote machine first. RemoteLaunch takes care of the logistics - you just provide the command or script
that you want to run.
In a nutshell, a wrapper command file is built around the command that you want to execute on the remote machine. It is completely transparent to you.
RemoteLaunch accomplishes all of the important tasks that make it possible to run your command successfully.
- Ensure connectivity to remote machine
- Copy wrapper to remote machine
- Launch wrapper using PSEXEC
- Wrapper connects to Network Paths
- Wrapper executes your command
- Clean up the wrapper command file and PSEXEC from the remote machine
So why is using Network Paths such a big deal? Why can't you just have PSExec run a script from the network on the remote machine?
For detailed explanations, you can Google why need trusted for delegation. In simple terms, even as a Domain Admin, you can only authenticate "one hop" away, i.e.
to the remote machine. Once there, you cannot continue to pass on your credentials "one more hop" away, to authenticate from there to a network resource.
One way to get around this problem is to grant your account to be trusted for delegation on all remote machines you'd like to manage. As you can see from the Google
search suggested above, this is not a trivial process.
The approach that RemoteLaunch takes is to work around delegation. Once your credentials have travelled one hop to the remote machine, they are no longer used. Instead,
RemoteLaunch establishes a fresh authentication to each Network Path that you have specified that you might use in your commands. The fresh authentication uses the credentials\
that you supply on the Options page. Now when it goes to launch your command from the network, or access other network resources, we are again in a "first hop" scenario,
and we've side-stepped the Delegation issue.
The Example Scenario
We need to update a service on a bunch of machines that are still running the old version. We have the list from inventory software.
The command script that will be required is going to need to run 3 commands:
net stop theService
copy \\server1\Apps\theService.exe "c:\program files\acme\theService.exe"
net start theService
Save the script as c:\temp\myScript.cmd.
Setting up Options
Run RemoteLaunch, and first, configure some Options to show the use of Network Paths. To get to the Options screen, click the menu wrench in the top right corner, then Options.
- Ensure you have downloaded PSExec.exe, and specify where it is.
- Add the two network paths that we need to access to run this command. The Apps share because the service files is copied from there, and the c$ share on your machine
since the .cmd file is there in this example.
- Provide your domain admin user name and password. It will be used to connect to the specified network paths.
You can keep a list of all paths that you use in various commands and scripts, and do not have to keep it confined only to paths that you are using in the current command.
The Command
Now we're ready to begin. Start on the Command Tab, and specify our command file as the command to run. Notice, I've also hit Save at this point,
and added it to my 'Previously used commands list'.
The Machines to Run It On
Next, on the Machines Tab, right-click in the empty box, and Paste in the list of machines.
Run Time!
Finally, on the Execute tab, click [Execute] to have the command run on each machine.
Ok, you caught me - these are all pretend machines here in my dev environment, but I hope this walk-through example has given you a good overview! Click [Reset and Start Over] to clear
the results and run again, or run a different command.
Enjoy!