Blog | BatchPatch - The Ultimate Windows Update Tool

Update Date Filtering: Skip Download / Installation of Recently Deployed Updates

By Scott | Published: September 22, 2015

In the most recent release of BatchPatch we added functionality that enables you to easily filter out recently published/approved updates during download and installation. In many environments there is a need or desire to be able to apply updates to computers only if the updates are at least X days old, where X is a value that is configured by the administrator. So, for example, it might be the case that during monthly maintenance in September the administrator desires to install all Windows Updates that were published or approved for August. And then in October the administrator would apply the updates released in September, and so on, so that the entire environment is always one month “behind” in updates that have been released. You can now do this using BatchPatch without adding any extra work.

You can see the setting called ‘Update Date Filtering’ under Tools > Settings > Windows Update in the screenshot below:

This filter instructs BatchPatch to compare the current date to the LastDeploymentChangeTime property of each update. The LastDeploymentChangeTime property is printed as a date (yyyy-MM-dd) next to each updated listed in the BatchPatch.log file. You can see this easily in the ‘Remote Agent Log’ column when performing a check for available updates in BatchPatch. In the below screenshot I’ve displayed the ‘Remote Agent Log’ column with the middle-click field viewer. For the sake of this tutorial I circled the date entries in green.

Important note about LastDeploymentChangeTime:
***When updates are obtained from ‘Windows Update’ or ‘Microsoft Update,’ the LastDeploymentChangeTime property is equivalent to the date the update was published by Microsoft. However, when updates are obtained from WSUS, the LastDeploymentChangeTime property is equivalent to the date the update was approved in WSUS.***

So, when you set the ‘Update Date Filter’ value to something greater than 0, BatchPatch will only download/install updates that were published / approved at least X days ago, where X is the value that you’ve input. For example, if you set this value to 30, updates that were published / approved any time between today and 29 days ago will *not* be installed by BatchPatch. Only updates that were published / approved 30 or more days ago will be installed. Once the setting has been saved, there is nothing else special that needs to be done. You would simply initiate the regular download and/or installation of Windows Updates using one of the options on the BatchPatch ‘Actions > Windows Updates’ menu, such as “Download and install updates + reboot if required.” This action will initiate the normal download/install process on selected computers, but updates will only be installed if they were deployed/approved more than 29 days ago.

Posted in Blog, General, Tutorials | Tagged date filters, Windows Updates | Comments closed

Executing PowerShell Scripts and Commands on Many Remote Computers

By Scott | Published: September 14, 2015

One of the things that BatchPatch does very well is remote script execution on many computers all at the same time. The ability to remotely execute a single script on numerous computers, simultaneously, with just a few clicks, is one of the awesome features of BatchPatch. No administrator wants to repeat a single process over and over on many computers. What about when the script you want to execute is written in PowerShell? How do you go about executing that single PowerShell script on all of your networked computers?

First, before you try to execute a single PowerShell script on numerous computer, you need to make sure that the script at least executes successfully on a single computer. One of the annoyances with PowerShell is that if you don’t have the same version of PowerShell on your computer, you might find that the syntax of certain portions of your scripts might only work on version 3 of PowerShell, which would obviously be a problem if some or many of computers are currently only on version 2 of PowerShell.

The first thing you’ll want to do is check to see which version of PowerShell is installed on your target systems. You can use the following PowerShell command to get the version information:

$PSVersionTable.PSVersion

If you want to use BatchPatch to check the version of PowerShell on all of your target systems, here’s what to do.

Highlight the target hosts in BatchPatch, and then select ‘Actions > Execute remote process/command > Create/modify remote command 3 (logged output)

In the command field we type or paste the following command exactly as it is written below:

cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "$PSVersionTable.PSVersion"

Note, if you think you might want to re-use the same command in BatchPatch more than once, then feel free to add the command to ‘Actions > Execute remote process/command > Create/modify remote commands (logged output), which will allow you to “permanently” hard-code any commands into the BatchPatch menu.
Click ‘execute’ to run the command on the selected hosts. You can see the results below from my quick run. I have one computer with version 3 of PowerShell, while the other still has version 2.
Now, let’s say you want to run a multi-line PowerShell script on your target machines. After verifying the PowerShell version that you have running on target computers and after making sure that your desired script works properly on at least one computer from each group (just to make sure that the syntax of your PowerShell script works on all versions of PowerShell being used in your environment, you now have two options for executing it from BatchPatch.
One option is to use the BatchPatch deployment feature. Please review this tutorial: Executing Powershell Commands On Remote Computers With BatchPatch You may also review the Software Deployment page to learn about BatchPatch deployments, in general. In this case instead of deploying a software package or an update, we want to deploy a PowerShell script. So, we would highlight the desired target computers, and then we’d select ‘Actions > Deploy > Create/modify deployment.’ In the window that appears we would select the script to be deployed, and then we would check the “retrieve console output’ if our script outputs anything to the console that we want to see. And then we can simply choose “Execute now” to execute the deployment and have BatchPatch copy the script to the target systems and subsequently execute it on each system.

A second option is to just run the script directly on target systems without doing a full deployment. In this case we would need to convert our script into the right format for it to be able to run in a single line. So, for example, let’s make up a very simple multi-line script to use for this example.
$version = $PSVersionTable.PSVersion $version | format-list
In order to execute this using the ‘Remote process/command’ feature of BatchPatch, we have to convert it into a single-line for execution. In PowerShell the semi-colon is used to separate multiple lines into a single line. So, in this case we would follow the same example that was given higher up in this tutorial, but note that this time we substitute in the above 2-line script.
Highlight the target hosts in BatchPatch, and then select ‘Actions > Execute remote process/command > Create/modify remote command 3 (logged output)

In the command field we type or paste the following command exactly as it is written below:

cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "$version = $PSVersionTable.PSVersion; $version | format-list"

In the results screenshot below you can see our 2-line script was successful, and now we see our version outputted in list format.

Posted in Blog, General, Tutorials | Tagged powershell, remote powershell execution | Comments closed

Using the Job Queue in BatchPatch for Multi-Step Execution

By Scott | Published: September 8, 2015

The ‘Job Queue’ feature lets you line up a sequence of multiple actions to execute on a target host. There are many different situations where you might want to execute a sequence of actions on a given host (or set of hosts). For example, maybe you want to string together multiple software deployments into a single click action. Or perhaps you want to create an update and reboot cycle that can be used to trigger your computers to run Windows Update, then reboot, then wait a few minutes, then run the update and reboot again, and so on. Or perhaps you want to have a single click action that will execute a script, then execute the update+reboot process, then execute another script. All of these examples (plus many more) are possible with the Job Queue. It’s extremely simple to operate. Here’s how it works:

Select the host(s) that you want to include in the job queue execution, and then click on Actions > Job Queue > Create/modify job queue
In the Job Queue window that appears you can either select a previously saved Job Queue, or you can create a new one. To select a previously saved queue, double-click the previously saved queue in the ‘Saved Queues’ grid. Or highlight the saved queue and use the ‘<<' button to load it. Once loaded, you can modify it however you like. However, if you want to create a new queue, you can simply double-click on each action you want to be included in the queue, one at a time. Or you can highlight each action one at a time, and use the '>‘ button to add that action to the queue. In the screenshot below you can see that I’ve created a simple queue that does the following:
A. Wait for host to have zero logged-on users
B. Download and install updates + reboot always
C. Wait for host to go offline and come back online
D. Wait 3 minutes
E. Download and install updates + reboot always
F. Wait for host to go offline and come back online
G. Wait 3 minutes
H. Start stopped automatic services
Now that the queue has been created, we have the option of either saving it or running it without saving it. If we just want to run it now without saving it, we can use the ‘Execute now’ button. If we want to apply the queue to the selected hosts to run later, we can use the ‘Apply queue’ button. Once a queue has been applied to a row/host, it can be executed later from the actions menu by selecting the hosts and choosing ‘Actions > Job queue > Execute job queue.’ However, we also have the option of saving the queue, which we do by adding a Queue Title and then using the ‘>>’ button to save it. Once a queue has been saved, it can be run at any time directly from the actions menu by selecting ‘Actions > Job Queue > Execute saved job queues > Title of job queue to be executed’

That’s all there is to it. When we execute the job queue, each action that was included in the list will be executed sequentially on the host(s) selected. We could also execute a job queue from within a scheduled task, so that it’s launched on a particular date and time, even if we are not in front of the BatchPatch window at the time. Or, if you need to execute a sequence of actions/tasks that involves multiple hosts in the same sequence, please have a look at the advanced multi-row queue sequence, which allows you to coordinate a sequence of actions across multiple hosts, with dependencies such as a particular reboot/shutdown order for a given environment.

Posted in Blog, General, Tutorials | Tagged job queue | Comments closed

Create a Consolidated Report of Available Updates for Numerous Computers

By Scott | Published: August 25, 2015

Some administrators might need a singular, consolidated report that lists all Windows Updates that are needed by computers in the organization. It would be nice if creating such a report didn’t require any manual work on the part of the administrator. The good news is that with BatchPatch you can create a consolidated report like this for all computers in just a few clicks. Usually it only takes a minute or two for all of the target computers to report back with results. However, the report is generated and displayed in real-time, so as target hosts complete their processing and report back to the main interface, the results are immediately visible in the report grid even if not all computers have reported back yet. The information displayed includes host name, update title, KB number (if applicable), update size, the published date or date of approval in WSUS, the update classification (Critical, Security, Definition, Updates, Update Rollups, Service Packs, Feature Packs, Drivers, Tools), whether or not the update has actually been downloaded to the target yet, and whether or not the update requires a reboot to complete installation.

Add target hosts to the BatchPatch grid by selecting ‘File > Add hosts’ and then inputting the names of the computers you want included in the consolidated report.
Select ‘Actions > Windows Updates > Generate consolidated report of available updates’
When you click OK to begin generating the report, you’ll see the report window appear. As individual hosts in the list are scanned and their scans complete, the available updates for those hosts will begin appearing in the report. In the screenshot below you can see we scanned a single host that had 12 available updates.
It should be noted that the ‘Date’ field is used to show the date the update was published, or in the event that a managed update server like WSUS is being used, it will show the date the update was approved by the WSUS administrator. The report can be exported to a delimited file by selecting the ‘Export report’ menu item in the upper left corner of the window, making it easy to import the report into your favorite spreadsheet application, such as Microsoft Excel.

Posted in Blog, General, Tutorials | Tagged report, Windows Updates | Comments closed

How to Remotely Initiate Windows Update on Numerous Computers Simultaneously

By Scott | Published: August 18, 2015

One of BatchPatch’s core features is the ability to remotely initiate the Windows Update search/download/install process on target computers. Not only does it allow you to execute this process on many computers at the same time, but it even lets you monitor the process in real-time so that you can see how far along each computer is. In a BatchPatch grid, one row is created per computer, and each row has its own progress bar, which enables you to see the overall completion percentage, the name of the currently downloading/installing update, as well as the current update completion percentage. I’ll do a run-through of the entire process below, so that you can see just how quick, simple, and painless it is to remotely apply Windows Updates to an entire network of computers.

We’ll start by adding some computers to a BatchPatch grid. Launch BatchPatch and then right click on the empty grid and select ‘Add hosts.’ Then input the host names of the computers you want to add. Finally click ‘OK’ to add the hosts to the grid.
Before we proceed, let’s double-check our Windows Update settings. Go to ‘Tools > Settings > Windows Update.’ In the window that appears you have the option of choosing ‘Windows Update,’ ‘Microsoft Update,’ or your local WSUS server. You can also select from a few different search preferences, and you can set download and installation filters too, if you want.
Now that the grid has been populated with some target computers, let’s go ahead and initiate a check for available updates. This check will show us which updates are available on each computer. Highlight the desired rows, and then select ‘Actions > Windows Updates > Check for available updates.’

We can see the results for one of the hosts in the screenshot below. This log is made visible by simply middle-clicking on the ‘Remote Agent Log’ column for the host in question. There are also a couple of other ways to view this information in BatchPatch, including the ability to get a consolidated list of available updates from all hosts in the grid.
Even though we first did a check for available updates in the previous step, if we had wanted we could have skipped straight to this step, where we’ll download and install the updates to our target computers. However, in some cases it’s nice to know ahead of time what updates are even available to the computers before initiating the download and/or installation process. To remotely initiate the Windows Update download and installation process on all the selected computers, all you have to do is select ‘Actions > Windows Updates > Download and install updates + reboot if required.’ If you don’t want the hosts to be rebooted automatically by BatchPatch, then instead go ahead and select ‘Actions > Windows Updates > Download and install updates.’
At this point it’s just a question of waiting a few minutes until the process is complete. The process can take anywhere from a few minutes all the way up to a couple of hours, depending on how many updates need to be downloaded and installed. A new installation of Windows will likely have more than a hundred updates available, whereas an older installation that has been maintained might only have a couple. However, it doesn’t matter how many hosts are in the grid or how many hosts are executed simultaneously. Each host will be handled in a separate thread, so you don’t need to factor in extra time for more hosts. If a host will take about 10 minutes on its own, then it will still take the same 10 minutes when its handled concurrently with numerous other hosts. You can imagine how much time this can save when executing the process across dozens or even hundreds of target computers!

Posted in Blog, General, Tutorials | Tagged remote windows update, remotely initiate windows updates | Comments closed

Copying files or folders to numerous computers using BatchPatch

By Scott | Published: August 11, 2015

BatchPatch provides the administrator with the ability to easily copy files and/or folders to numerous computers, simultaneously. If you simply need to push a file to target computers or you need to replace a file that already exists on target computers, here’s how to do it:

Select the target hosts that you want to copy files/folders to. Then select ‘Actions > Copy file / folder > Create/modify file or folder copy’
In the dialog that appears, let’s start by adding a title for our copy job. Note, a title is not required for one-off jobs. The title is only required if you plan to save the copy job to use again in the future. For the sake of this example, we’ll save the job.
Use the browse button to select the source file/folder to be copied. In the ‘Destination folder’ field, we manually type the path of the folder on target computers that we want to set as the destination for the copied files. Lastly, if we want to overwrite existing files with the same name, then we can check the ‘overwrite’ box. Optionally use the >> button to save the copy job for future use.
At this point we are actually ready to execute the copy. If we click on the button that says “Execute now,” the file copy job will be executed for each selected row. The file will be copied from our source folder to the specified destination folder on each selected computer in the BatchPatch grid. Alternatively, if we saved the copy job, then we can close this window and execute the copy job later. For the sake of this example, let’s close the window.
Now that the copy job has been created, let’s go ahead an execute it. Highlight the desired target hosts in the grid, and then select ‘Actions > Copy file/folder > Execute saved file/folder copy job.’ In this case since I’ve only saved one job, I’ll select it. You can see when I hover my mouse over the menu item, a tooltip window appears showing the details of the copy job configuration, so that I can verify that I’m executing the correct job.
Finally, I will complete the job by clicking the menu item for the job in question. I’m prompted to confirm the action, so I select OK to complete the copy.
We can see the successful copy in the screenshot below. That’s all there is to it!

Posted in Blog, General, Tutorials | Comments closed

Checking for Stopped Automatic Services with Exclusions

By Scott | Published: July 29, 2015

In the most recent release of BatchPatch we added a simple but very useful little feature to assist with reporting on stopped automatic services on a large number of target computers.

As sysadmins, we know that after rebooting a large number of computers, it’s extremely useful to be able to confirm that the services that have been set to ‘automatic’ have actually started properly. If you install updates on 100 SQL servers, but one of the updates somehow prevents the SQL Server service from starting properly after the machines are rebooted, you’re going to want to know about it immediately. The same goes for Exchange services, which commonly don’t all start properly after reboot, as well as many other services.

BatchPatch has always had the ability to retrieve from target computer the list of services that are set to ‘automatic’ but in the ‘stopped’ state. However, when working with a large number of target machines, this was less than ideal because there are some automatic services that we don’t care about that might regularly be in a stopped state. The perfect example is the Windows ‘Software Protection’ service. It’s generally going to be in the stopped state even though it’s set to automatic. It would be really nice if we could simply report on the services that we really care about, so that at a quick glance we can immediately determine which machines we need to investigate further, rather than having to read through separate a list of stopped automatic services for every single target computer.

In the latest release of BatchPatch we added an exclusions list that works in conjunction with the check for stopped automatic services. Using it is very simple. Go to ‘Tools > Settings > General’ and then click on the “exclusions list” button next to the label that says “Global exclusions list for automatic services in stopped state.”

You can see in the screenshot above that I’ve added a few services to exclude. In this list we require the service ‘Display Name’ not the actual service name. For example, the ‘Software Protection’ service corresponds to the sppsvc service. You can see the display name vs the actual service name of all services in the Services console. My favorite way to launch the services console is to go to ‘Start > Run’ and then type “services.msc” in the run box without the quotes.

In the Services console if we double-click the ‘Software Protection’ service entry, we can see the details where it shows us the ‘Service name’ and the ‘Display name.’

So, for the BatchPatch services exclusions list, make sure to always use the display name, not the actual service name. Enter one service display name per line. Any service that is included in the exclusions list will then be skipped/ignored if it is stopped on target hosts when you perform the check for stopped automatic services.

In the screenshot below I’ve executed ‘Actions > Get information > Get automatic services in stopped state.’ You’ll notice that the first host reports 2 stopped automatic services. In reality, the computer has 3 stopped automatic services, with that third service being ‘Software Protection.’ However, since ‘Software Protection’ is in our exclusions list, when we check for stopped automatic services, BatchPatch simply reports that 2 services are stopped, and we can see in the list of stopped services that ‘Software Protection’ is not included.

Posted in Blog, General, Tutorials | Tagged automatic services, exclusions | Comments closed

Running BatchPatch as a Service

By Scott | Published: July 21, 2015

In the latest release of BatchPatch we added functionality to run BatchPatch as a service, enabling you to execute scheduled tasks even when no one is logged on to the BatchPatch computer.

Go to Tools > Run BatchPatch as a service to reveal the run-as-service settings window.

The installation of the service requires BatchPatch to be running with elevation (as administrator). When running as admin you simply need to click the Install Service button. The service will be installed under the logon account that you’re currently using to run BatchPatch. In this way we allow multiple users on the same computer to each install their own instances of the BatchPatch service.

Once installed we can see 3 green check marks to indicate that the service is installed, the service is running, and the service instance is running. The BatchPatch service is responsible for starting the BatchPatch service instance (a dedicated/special instance of BatchPatch that runs as long as the service is running).

Once the service has been installed, you can select grids to be run by the service instance. You would create a BatchPatch grid and set the various scheduled tasks that you desire to execute on the hosts in the grid. Then save the grid to a .bps file. Once the file has been saved you can ‘send’ it to the service instance in two ways. Either right-click on the tab header and choose “Send grid to service instance”

Or use the run-as-service settings dialog + button to add .bps files:

Once a file has been added, we’ll see it appear in the list of currently active .bps files:

We can monitor this grid by launching it in the service instance .bps file viewer. Either double-click the filename in the list, or highlight it and choose the option to “Launch selected .bps file(s) in viewer.” Alternatively, you could even select “File > Open” and browse to the .bps file, or you could drag and drop the .bps file onto the BatchPatch window. Any of these actions will launch the grid in the service instance viewer.

The viewer will allow you to monitor the grid in real-time, but you will not be able to edit/modify it. If you desire to modify the grid, you’ll have to first remove the grid from the service instance. The removal process is similar to the process we used to add the grid in the first place. Only this time we’ll choose the “Remove grid from service instance” option. We can also just drag the grid from the service instance viewer into the regular/main BatchPatch window. Either action will prompt BatchPatch to display a confirmation dialog.

Don’t hesitate to contact us with comments, criticisms, and suggestions: Contact us

Posted in Blog, General, Tutorials | Tagged run as service, service | Comments closed

Enabling Microsoft Update instead of Windows Update on Target Computers with BatchPatch

By Scott | Published: July 13, 2015

The distinction between ‘Windows Update’ and ‘Microsoft Update’ has caused a significant amount of confusion for people over the years, so I’d like to take a moment to clarify the difference, as well as to explain how you can configure your target computers to use one or the other with BatchPatch.

First note that if you are using WSUS in your environment, then you probably aren’t going to be too concerned with the distinction. Your target computers will be receiving updates from your local WSUS server, and that’s all there is to it. However, for environments and users that are not using WSUS, the distinction is more important.

Defining ‘Windows Update’ and ‘Microsoft Update’

Generically, when we say ‘Windows Update’ or ‘Microsoft Update’ we are talking about software updates for computers. More specifically, when Microsoft uses the term ‘Windows Update’ they are referring to the update service that provides software updates to Windows operating systems. When they mention ‘Microsoft Update’ they are referring to the update service that provides software updates to Windows operating systems AND to individual software products that Microsoft has created, such as Office, Visual Studio, Exchange, and SQL.

By default all Windows computers today are subscribed to the ‘Windows Update’ service when a computer is first enabled for receiving software updates from Microsoft. When configured to use ‘Windows Update’ a computer will only ever detect available operating system updates. To enable the system also retrieve updates for individual Microsoft products, ‘Microsoft Update’ needs to be explicitly enabled on each computer.

Configuring ‘Windows Update’ vs ‘Microsoft Update’ on Individual Computers

If you launch the control panel Windows Update interface (Control Panel > Windows Update), you can determine which service a particular computer is configured to use.

When ‘Windows Update’ is enabled, you’ll see something like this:

To configure the computer to use the ‘Microsoft Update’ service instead of the ‘Windows Update’ service, click on the link that says “Find out more.”

When ‘Microsoft Update’ is enabled, you’ll see something like this:

Configuring ‘Windows Update’ vs ‘Microsoft Update’ on Numerous Computers with BatchPatch

You can use BatchPatch to determine which update service your target computers are configured to use, as well as to configure your target computers for a particular service.

Highlight the desired hosts in the BatchPatch grid and select ‘Actions > Windows Updates > Get Windows Update configuration’ (note, this is the same as ‘Actions > Get information > Get Windows Update configuration’).

After clicking OK BatchPatch will connect to the target computers to retrieve their current settings. You can see in the screenshot below that both of my test computers are currently set to use the ‘Windows Update’ service. If either were configured for ‘Microsoft Update’ we would see it in the screenshot. Additionally, if either were configured to use a local WSUS server instead of one of the Microsoft public services, we would see that here as well too.

To configure the target computers to use ‘Microsoft Update’ we select ‘Actions > Windows Update > Opt-in to Microsoft Update (enable updates for other MS products)’

Note, the Windows Update service on the target computer will be restarted as part of the ‘opt-in’ process. In the screenshot below you can see that I enabled the ‘Microsoft Update’ service on one of the computers.

In the same way that I just enabled ‘Microsoft Update’ I can easily disable it by using ‘Actions > Windows Update > Opt-out of Microsoft Update (disable updates for other MS products)’. That’s all there is to it.

Posted in Blog, General, Tutorials | Tagged microsoft update, windows update | Comments closed

Executing PowerShell Scripts and Commands (cmdlets) on Remote Computers with BatchPatch

By Scott | Published: July 2, 2015

Executing PowerShell commands and scripts remotely can be a bit tricky. BatchPatch currently has direct support for deploying PowerShell scripts to target computers, and we will be adding more PowerShell functionality in the not-too-distant future. However, today I’d like to take a few minutes to go over the current options you have for executing PowerShell commands through BatchPatch on target computers.

Executing PowerShell Scripts:

If you’ve written a powershell script that you simply need to execute on a set of target computers, your easiest option is to use BatchPatch’s deployment feature. BatchPatch will handle copying the file to target systems, executing the script, and then deleting the file.

In BatchPatch, select Actions > Deploy software/patch/script/regkey etc > Create/modify deployment
In the Deployment form set a title, browse and for the .ps1 script file. For ease of operation I’m going to save this Deployment using the double right arrow button >>. Once the Deployment has been saved, the Deployment form can be closed.
Highlight the hosts you want to deploy the script to. I titled my deployment “Execute PowerShell Script 1,” so I will now select Actions > Deploy software/patch/script/regkey etc > Execute saved deployments > Execute PowerShell Script 1. You can see in the screenshot below that when the mouse hovers over the menu item, the configuration of the actual deployment is displayed in a tooltip.
When you click OK you’ll be presented with a confirmation dialog which also displays the configuration of the deployment that is going to be executed. Click OK to continue.
When the script completes Exit Code: 0 (SUCCESS) is displayed in the ‘All Messages’ column. That’s all there is to it. However, if your script was specifically written to output messages to the console, you could select the “Retrieve console output” checkbox option in the Deployment form when configuring the deployment. However, this setting can cause a deployment to not execute in some cases, so proceed accordingly.

Executing PowerShell Cmdlets:

If you only need to execute a particular powershell cmdlet that’s already available/installed on the target computer, you can do that with a single command instead of deploying a whole script.

Select Actions > Execute remote process/command > Create/modify remote commands (logged output)
In the ‘Remote Process’ form, add a new row, give the cmdlet a title, and enter the actual cmdlet into the ‘command’ field. For the sake of this tutorial I’m just going to execute the ‘get-help’ cmdlet. Here’s the key part: Unfortunately you can’t simply enter ‘get-help’ like you would at the command line. In a future build of BatchPatch we will be adding direct support for PowerShell cmdlets so that will be able to execute cmdlets more intuitively, but for the time being you’ll need to enter the following syntax, substituting the cmdlet that you want to run for ‘get-help,’ of course:
cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "get-help"
Click OK after you’ve created the command.
Now highlight the hosts that you would like to execute the cmdlet on, and then select Actions > Execute remote process/command > Execute saved remote commands (logged output) > PowerShell Get-Help Cmdlet. Of course you’ll substitute your own title for ‘PowerShell Get-Help Cmdlet.’
The command completes and we see the output from the cmdlet in the ‘Remote Command Output Log’ column.

Posted in Blog, General, Tutorials | Tagged cmdlet, powershell, remote powershell, script | Comments closed