Run Vbs File From Cmd Group

1. Run Vbs File From Batch File
2. Run Vbs File From Powerbuilder

If you manage a Terminal Server Farm, a Citrix farm or any bunch of uniform machines, whether physical or virtual, you probably have a set of management scripts that help you get your work done with a minimum effort. Often the need arises to perform some maintenance tasks on several remote machines, and you face a common sysadmin’s dilemma – do I just log into all these machines one by one (may be good enough if you only have a few machines to handle) or should I find some way to group these multiple remote tasks into one local task? Method 1: Use Sysinternals' PSExec The most common way to invoke commands remotely is by using PSExec.

This is a classic command line tool by SysInternals, that can easily invoke a command on a remote computer/s and redirect the output to your local command shell. You will need to download to your computer. The next step would be to prepare a simple TXT file with the names of the computers on which you want to run the command, one name per line. In this example, we will use a plain text file named 'CompList.txt' which looks like this: Complist.txt. C: Windows system32net stop spooler /y The Print Spooler service is stopping. The Print Spooler service was stopped successfully. C: Windows system32del C: Windows system32 spool PRINTERS.

Run Vbs File From Batch File

/f /q C: Windows system32net start spooler The Print Spooler service is starting. The Print Spooler service was started successfully. C: Windows system32net start cpsvc C: WINDOWS system32net stop spooler /y The following services are dependent on the Print Spooler service. Stopping the Print Spooler service will also stop these services. Citrix Print Manager Service The Citrix Print Manager Service service is stopping. The Citrix Print Manager Service service was stopped successfully.

Run Vbs File From Powerbuilder

The Print Spooler service is stopping. The Print Spooler service was stopped successfully.

C: WINDOWS system32del C: WINDOWS system32 spool PRINTERS. /f /q C: WINDOWS system32net start spooler The Print Spooler service is starting. The Print Spooler service was started successfully. C: WINDOWS system32net start cpsvc The Citrix Print Manager Service service is starting.

The Citrix Print Manager Service service was started successfully. The Citrix Print Manager Service service was started successfully. As you can see, it's fairly easy to run the command, but analyzing the output can be a pain. While your script may run successfully on some computers, you might want to spot those machines on which the service could not be restarted, or on which the script could not terminate successfully for any other reason.

Especially if the command you're running produces several output lines, it may take a while to spot these errors as the output is spilled continuously on your command prompt. Another thing that might prove time consuming, is preparing the list of servers.

Assuming your servers are named CTXSRV150 to CTXSRV274 (with several skips), you would have to create a script that creates the list, rather than manually copying and pasting it over and over. On the other hand, if your computer names follow a continuous numeric pattern, you might prefer to leverage the good old FOR command like this. For / l% i in (150,1,274 ) do psexec CTXSRV% i c: temp cleanspool. Bat This way, your command will be executed one-by-one on all servers within the above numeric range. (Tip: if you want to use the FOR statement within a batch file, use%% instead of%).

Method 2: Use WMI to run remote commands As you probably know, Microsoft has integrated WMI (Windows Management Infrastructure) on all of its operating systems. In few words, WMI is a framework that allows you to retrieve management data and invoke functions, while abstracting the API level. Creating a script which uses WMI is a bit more difficult, but once your script is ready, you can re-use it over and over with minor changes. The major advantage in using a WMI script is that your flexibility is almost infinite. You can analyze the output within the script, notify upon failures and even run corrective actions. The disadvantages, however, is that you have to work hard for each change, test it thoroughly and only then run it on your production environment.

Here is a little script I made for generic execution of remote commands. OError = objWMIService. Create ( sCommandLine, null, null, iProcessID ) It tells the remote WMI namespace (initialized using the Set objWMIService statement) to execute the process. I saved the best (and my favorite) for last: Method 3: Use ControlUp to run remote commands If writing a script is not for you, or if you're simply short of time and you want to get things done as quickly as possible, you should really give (by Smart-X) a try. Not only that you don't have to write even a line of code, ControlUp analyzes the output for you and shows you exactly which servers need further attention.

After you download the product, the first step would be to select the remote computers on which you want to run the command. You can select the computers from a text file, from an IP subnet, or by selecting them from any Active Directory domain to which you have access, even those with no trusts with your own domain: ControlUp – Select computers Similar to PSExec, ControlUp launches a small service on each of the computers. This service will be automatically removed once you close the application. After you added the computers, simply select them from the main grid, and select 'Run As' from the context menu. Use ControlUp to run remote commands On the 'Run As' screen, you can specify alternative credentials (If not specifying any credentials, the command will run under the system account of the remote computer) Run As with ControlUp Once you click OK, the requested program or script will be executed on all of the target machines you selected, in a way similar to PSExec, except for the fact that your commands will run in parallel, without keeping you waiting for each target to be completed before proceeding to the next one. You will also see a progress window, showing you a summary of the command’s success and failure outcomes on all your target machines: ControlUp – Progress window As you can see, some computers have encountered errors during the attempt to invoke the command.

You can now fix the problem and use the 'Run Again' button to retry. Another nice thing about ControlUp is that it's shipped with a set of tools that spare the need to write batch files, such as manipulating Windows Services, Registry, policy and Terminal Services sessions, but that’s a different story. Conclusion I made a small comparison chart that summarizes the differences between these three methods, which will hopefully help you select the most suitable solution for your purposes: Three ways to run remote Windows commands 1 Requires WMI + RPC connectivity for agent distribution. Once the agent is distributed, no RPC/WMI connectivity is required 2 Up to 50 servers concurrently. I would seriously consider WMIC as an option with powershell. So to uninstall a application remotley it would be: wmic /node:computertarget product where name='Google Earth' call uninstall.

Batch file example: @echo off cls echo - set /p target=Whats the name of the Target Machine: echo Dumping list of install software from%target% wmic /node:'%target%' product GET name sort echo - set /p software=Ok which software would you like to uninstall: echo Ok, attemtpting to uninstall%software% from%target% echo Please note if you get a -ReturnValue = 0;- string it has worked. Wmic /node:'%target%' product WHERE (name like '%software%') call uninstall /nointeractive echo - echo Doing search patter to determine uninstallation success! Wmic /node:'%target%' product GET name find /i '%software%' echo Done. But all of these have requirement, either on the client (your computer) or on the server, on so you have to prepare in advance, which you probably haven't since you ended up in this situation.

My favorite tool for this is scheduling the execution with AT. AT is on EVERY windows computer and can schedule program execution on remote hosts like this: AT remote-host 10:50 my-silent-installer.exe Ofcourse you will have to wait for the execution for up to a whole minute, and you won't get any output unless you pipe stdout to some file or something. But to me that is easy out weighted by the fact that I don't have to install anything. This is a tiring and frustrating topic. PSExec is great for arbitrary commands or running batch files that can be copied and run directly to a list of machines as indicated. But when the file that needs to be copied is a Powershell script, and.ps1 files are not associated on the remote machines with Powershell, trying to get PSExec to start a shell on a remote machine and then run powershell while feeding it the file name is an exercise in futility. Files not found, miscellaneous errors with identity and authentication, and syntax where escaping names for commands and files is concerned.

Powershell remoting isn't any better. Turning it on remotely is one thing. But then getting credentials to it is something else altogether. Nothing but problems with it. And in both instances, trying to get a Powershell script to actually output back to the client screen for things like checking for and installing updates on multiple machines is infuriating. Best I can ever do is run Start-Transcript and then pipe that to a file I can read after the fact.

Trying to get that info to a client during runtime? Don't know what's going wrong but I am growing really tired of the whole idea.