Perform Update and Reboot Actions Sequentially Across Numerous Hosts

One of the more powerful features that BatchPatch offers is the ability to automate basic or advanced sequences of actions across multiple target computers. For example, if you have a group of computers that have certain online/offline dependencies, such that they cannot all be rebooted at the same time, or maybe they have to be rebooted in a certain order, you could setup an automation sequence in BatchPatch to handle this process with just a single click. Or let’s say that you want download and install Windows Updates and reboot a total of 10 different target computers. However, the 10 different computers are configured in such a way where you only want to have one of those 10 computers be offline at any given time. Again, you could create an automation sequence in BatchPatch to handle this entire situation with a single click. Or what if you have many Hyper-V hosts, each containing numerous virtual machines guests. You are looking for a way to easily apply updates to all of the virtual guests, and then only after the guests are updated on a given host, you then want to apply updates to the virtual machine host and reboot it along with all the virtual machine guests. You don’t want to have to launch the process manually on every guest and host involved. Instead you want to create a way to automate the process with BatchPatch so that it can be boiled down to a single click action. You can do all this, and more, with the multi-row sequencing features in BatchPatch.

Basic Multi-Row Queue Sequence

The Basic Multi-Row Queue Sequence allows you to string together a sequence across multiple target computers such that each target computer executes a custom job queue one a time. The key with the Basic Multi-Row Queue Sequence is that only one host will process its actions at a given time.

Host1 is configured to download and install updates plus reboot.
Host2 is configured to deploy Firefox.
Host3 is configured to run a custom script.

If these three hosts are configured in a Basic Multi-Row Queue Sequence, then Host1 will perform its actions. Only when all actions for Host1 are completed will Host2 begin processing its actions. And only when Host2’s actions are completed will Host3 begin processing its actions.

For a detailed tutorial on using the ‘Basic Multi-Row Queue Sequence’ please follow this link: Using the Basic Multi-Row Queue Sequence

Advanced Multi-Row Queue Sequence

The Advanced Multi-Row Queue Sequence differs from the Basic Multi-Row Queue Sequence primarily in that it allows a sequence to process multiple hosts’ queues simultaneously, while still allowing those hosts to participate in a larger sequence with other hosts.

Host1 is configured to download and install updates plus reboot.
Host2 is configured to deploy Firefox.
Host3 is configured to run a custom script.
Host4 is configured to download and install updates plus reboot.
Host5 is configured to download and install updates plus reboot.
Host6 is configured to import a registry key.

With the Advanced Multi-Row Queue Sequence you can customize it completely. You could set it so that Host1 and Host2 perform their actions. Then when both Host1 and Host2 are complete, only then will Host3 and Host4 perform their actions. And only when they are both complete will Host5 and Host6 perform their actions. ALTERNATIVELY… since the Advanced Multi-Row Queue Sequence options are not limited you could instead configure it to execute Host1 at the same time as Host2, Host3, and Host4. Then when all four of the hosts are completed, only then would Host5 and Host6 begin execution. There is no limitation to the number of hosts that can participate in a sequence, and there is no limit to the number of hosts that can be active for any given step in the sequence. It is completely customizable and amazingly powerful.

For a detailed tutorial on using the ‘Advanced Multi-Row Queue Sequence’ please follow this link: Using the Advanced Multi-Row Queue Sequence

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

Deploying a Script with Relative Instead of Absolute Paths

In order for a custom deployment to be successful, you might not be able to use absolute paths inside of a script where those paths point to a location on a remote server. This is dependent upon the particular situation, but if you’re having problems successfully deploying a script that makes calls to other scripts or executables stored on a remote server, below I will show you how to ensure success.


Imagine you have a remote server folder:


The folder contains two files – MyCustomExecutable.exe and MyCustomScript.cmd:

The contents of the script are as follows. Note, the script makes a call to execute the MyCustomExecutable.exe using an absolute path to the server location where the exe file currently resides:

ECHO *** Executing My Custom Script With Remote Server Absolute Paths ***

You are attempting to deploy the script using the configuration in the screenshot below, but you are not having success:

If you are having problems getting the deployment to run successfully, you have a couple of options to try:

  1. You might be able to get the deployment to execute successfully simply by modifying the ‘Remote Execution Context’ settings. In the screenshot below you can see that I have launched the ‘Remote Execution Context’ settings window directly from the deployment configuration screen. However, you can also get to the ‘Remote Execution Context’ settings by clicking ‘Tools > Settings > Remote Execution.’

    The default configuration is set to use the SYSTEM account for remote execution. This is usually the best for most situations, but one drawback to this setup is that the SYSTEM account does not have access to network resources. Since the script that gets executed on the target system is currently set to make a call to a remote server location (“\\RemoteServer\SharedFolder\Example\MyCustomExecutable.exe”), the deployment will fail because the SYSTEM account on the target computer will not be able to reach that network resource. Try running your deployment with ‘Elevated token’ or ‘Normal’ and see if you have success. If not, set the Remote Execution Context setting back to ‘SYSTEM’ and go to the next step.
  2. With a simple adjustment to your script and your BP deployment configuration you can remove any network calls so that the entire deployment executes locally on the target system.

    A. Modify your script to remove the absolute path. See below for example:

    ECHO *** Executing My Custom Script WITHOUT Remote Server Absolute Paths ***

    B. Modify your deployment configuration by ticking the box that says “Copy entire directory contents in addition to the specified file”

    C. Now when you execute the deployment, the entire folder contents of (\\RemoteServer\SharedFolder\Example) will be copied to the target systems. Then when the script is executed, since it now contains a relative path to the MyCustomExecutable.exe, it will find that file in the same temp deployment directory as the script is being executed from. The deployment will complete successfully (unless, of course, the reason for it failing in the first place was due to some other unrelated issue).

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

Remotely Install Greenshot on Many Computers Simultaneously

Today let’s have a look at deploying Greenshot screen capture software to numerous computers simultaneously. The process is no different from other remote installations with BatchPatch. We will start by determining the appropriate installation parameters to use in order to trigger a “silent” or “quiet” installation on target computers. Next we will create the actual deployment in BatchPatch. Lastly we will execute the deployment.

  1. Download the version of Greenshot that you intend to install. In this case we are installing the latest version, downloaded from
  2. As is the case with any remote software installation, the installation must be triggered to run without any user interaction required on the target computer. The reason for this is because if the installation package pops up a window on the target system, asking the user to select configuration options such as installation directory, that popup window will be hidden from the administrator on the BatchPatch computer, and the deployment will consequently hang indefinitely without ever completing. So, before we deploy Greenshot we have to determine the appropriate switch to use in our deployment configuration to make sure that the installation occurs without any user interaction. This is known as a “silent” or “quiet” installation.

    To determine the correct silent parameter, we execute the installer package at the cmd prompt with the /? switch. See screenshot below for illustration.
  3. Running the command above causes the installation package to pop up the messagebox shown in the screenshot below. We are going to use the /VERSILENT and /NORESTART parameters for our deployment.
  4. To create the deployment in BatchPatch, select the target hosts that will receive the deployment, and then select ‘Actions > Deploy > Create modify deployment’
  5. In the Deployment form, click the browse button to browse to the Greenshot-INSTALLER- that you downloaded earlier. Then type /VERYSILENT /NORESTART into the ‘Parameters’ field, just as I have done in the screenshot below. Optionally give your deployment a title and save it using the >> button.
  6. At this point you can either execute the deployment now or close the window and execute it later. I’m going to simply click the ‘Execute now’ button.
  7. Exit code 0 indicates success. Greenshot is now installed on the target system(s).

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

Exporting the BatchPatch Grid

One of the features in BatchPatch that many users overlook is the export tool. Admins frequently desire to get BatchPatch grid information into a different format so that it can be consumed by people who are not using BatchPatch, whether it be for reporting or other purposes.

For example, what if you want to prepare a simple report that shows the CPU information for a given list of computers?

  1. Start by adding the desired hosts to the BatchPatch grid. Then highlight the hosts and perform the desired action, which in this case is ‘Actions > Get information > Get CPU info’ The result should look similar to my screenshot below.
  2. For this mini-report I only want to include the actual CPU information for each host. I don’t need the information from the ‘All Messages’ column, so I’m going to hide that column by right clicking on the column header and then unchecking the ‘All Messages’ box.


  3. Now that I am displaying only the information that I’m interested in seeing in the report, I can go ahead and create the export file, which in this example will be an HTML file. Select ‘File > Export grid > Export current grid to HTML file’ and then choose a location to save the output .html file.
  4. You can now launch your .html report by double-clicking on it and opening it in your default browser. One of the nice things about the HTML export is that it shows the original grid with clickable elements that enable you to click on a field in the grid and immediately jump down to the corresponding location in the report. You can then use the ‘back to table’ option to jump right back to the top of the file. It’s actually a pretty convenient way to display the information, and you can get virtually any kind of information from target computers that you need whether it be a list of installed software or a list of currently logged-on users or a list of last bootup times. Even if BatchPatch does not have a built-in query for the information you desire, it’s simple to write your own query to retrieve custom information. More details on that here: how-to-hard-code-your-own-custom-commands-in-the-batchpatch-actions-menu
  5. You can also export to a delimited file in case you want to later import the data into a spreadsheet or database. To do this select ‘File > Export grid > Export current grid to delimited file’
  6. You’ll be prompted to select a custom delimiter. You have to be careful about which delimiter you select. For example, you might think to use the standard comma to create a .csv file. However, commas can appear in BatchPatch grid data, particularly if you are listing titles of Windows Updates. And if a comma appears in the grid data but is also used as a delimiter, you end up with problems with your output file. We usually like to use ‘?’ because it is generally unlikely to appear in grid data. However, you can also specify a custom multi-character delimiter, such as ‘$#$’ or ‘%%^^%%’ or whatever you like.

    I have launched the output text file in my default text editor. You can see what that looks like below.
  7. So now if I want to import my file into a spreadsheet, I can do so very easily using the spreadsheet application’s import feature.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Adding Hosts to BatchPatch from Active Directory

Even if you have been using BatchPatch for a while, you might have realized that you can import host names into a BatchPatch grid directly from Active Directory, if you desire.

In BatchPatch use the ‘File > Add hosts from directory’ option.


In most cases BatchPatch will automatically detect and retrieve the defaultNamingContext so that it can bind to your Active Directory domain. However, in some environments, it’s possible that you would manually have to input the domain controller name that you wish to connect to. For the sake of this example, I am on a computer that is *not* a domain member, and so in order to connect to an Active Directory domain in BatchPatch, I am required to both specify the domain controller name as well as the credentials of a user with permission to read from the directory. In the screenshot below you can see that I’ve done exactly that.


Once you have established the connection with Active Directory, you may browse through the tree to select computers to add to the BatchPatch grid. If you highlight a container or organizational unit (OU), BatchPatch will display all of the machine accounts (computers) that exist inside of that container or OU.


If you select only a single computer in the directory tree, then of course only that single computer will be displayed for addition to the grid.


If you tick the box in the lower left corner of the window for ‘Recursive search’ BatchPatch will find all machine accounts in the selected directory and all subdirectories.


If you would like to add a computer (or multiple computers) to the BatchPatch grid, first you click the >> button to move them to your staging list.


Next you have two additional options that you may select, if desired, before clicking ‘Add to grid.’ The first option ‘Import description field’ allows you to automatically import the description field for the computer from Active Directory into the ‘Description’ column in BatchPatch. The second option ‘Append DNS suffix to hosts’ allows you to automatically append the specified DNS suffix to the host name before adding the host name to the destination grid. So, for example, if you have host ‘Computer1’ on domain ‘,’ and you work in an environment where multiple domains exist, such that your DNS settings require you to generally use fully qualified names, then you can simply tick the ‘Append DNS suffix to hosts’ box and add the domain suffix that you wish to append. Then when you click ‘Add to grid’ all hosts will be added with the suffix you specified. So in the above-mentioned example, we would see ‘’ get added to the grid instead of just ‘Computer1.’

When you are ready to add all of your hosts to the grid, simply click ‘Add to grid.’ All hosts that are displayed in ‘Computers to add to BatchPatch grid’ list will be added to the BatchPatch grid.



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

BatchPatch Troubleshooting Guide

We designed BatchPatch to be as easy to use as possible. However, of course it’s still possible to encounter problems or run into unexpected situations. The goal of this guide is to help direct your troubleshooting efforts, so that you can narrow down the potential causes of whatever issue it is that you’re experiencing.

  1. The first order of business is to make sure your environment is setup properly. Please review all of the steps in the ‘Getting Started‘ page, and make sure your environment has been configured properly to work with BatchPatch.
  2. Next, see if the issue that you are encountering is addressed here or here.
  3. If you’re still having an issue, let’s break down what BatchPatch tries to accomplish, so that you can determine where in the process your issue is occurring.

    ‘Get information’ actions

    Most ‘Get information’ commands, such as ‘Get last boot time’, ‘Get MAC address’, ‘Get computer model’, ‘Get CPU info’, and ‘Get OS version’ are retrieved by BatchPatch using simple WMI queries. In order for a WMI query to be executed successfully, the target computer must be able to receive and process it. This means the firewall has to be configured to allow WMI queries to pass through it, and the target computer has to have WMI enabled, and permissions have to be set properly so that the requesting account is allowed to retrieve the information requested. This page addresses the typical errors that one would encounter if not everything is setup properly to allow WMI queries to be processed.

    ‘Windows Update’ actions

    Most ‘Windows Update’ commands utilize a combination of WMI commands (mentioned above) as well as a remote executable (BatchPatchRemoteAgent.exe) that is executed by PsExec. The BatchPatchRemoteAgent.exe is responsible for communicating with the Windows Update Agent, in order to instruct it to search for updates, download updates, install updates etc.

    When you are having problems executing Windows Update actions through BatchPatch, here is what to look for when trying to determine specifically where the issue is occurring.

    • Make sure WMI is working first. Test a ‘Get information’ action such as ‘Get last boot time.’ If ‘Get last boot time’ is throwing an exception, then start with troubleshooting WMI setup/configuration before doing anything else.
    • If WMI is working properly and you are able to successfully run various ‘Get information’ actions such as ‘Get last boot time’ and ‘Get MAC address’, then your next step is to see if BatchPatch is successfully able to create the target computer remote working directory. In BatchPatch ‘Tools > Settings > Remote Execution’ there is a ‘Remote Working Directory’ setting, which by default is set to C:\Program Files\BatchPatch. This it the directory on the target computer that BatchPatch tries to create before it is able to execute any Windows Update actions. Please check the target computer for the existence of this directory. If the directory does not exist, then it means that BatchPatch is either not able to reach the target computer to create the directory, or BatchPatch is able to reach the computer but does not have the appropriate permissions needed to create the directory.
    • Assuming that BatchPatch has successfully created the remote working directory, the next step is to watch this folder during an attempted Windows Update action. Execute the desired action in BatchPatch such as ‘Check for available updates.’ Then monitor the remote working directory for activity. You should see ‘BatchPatchRemoteAgent.exe’ is copied to directory.
    • After ‘BatchPatchRemoteAgent.exe’ is copied to the target directory, PsExec is used to run the executable. In order to determine if PsExec is running the exe successfully, check Task Manager on the target computer for active processes. You should see ‘psexesvc.exe’ and ‘BatchPatchRemoteAgent.exe’ running on the target computer. However, please note that if you have modified the following setting in BatchPatch, then instead of seeing ‘psexesvc.exe’ you will see a process with the name that you specified in ‘Tools > Settings > Remote Execution > Use PsExec -r switch to specify a remote service name’


    • If you do not see ‘BatchPatchRemoteAgent.exe’ and ‘psexesvc.exe’ running on the target computer, then your next step should be to verify that PsExec is working as expected. Try running PsExec at the command line from the BatchPatch computer to the target computer *WITHOUT* using BatchPatch. For example, you could simply run the following command to see if works properly or if it throws an error:
      PsExec \\targetComputer cmd.exe


    • If PsExec is not working properly, then you’ll need to troubleshoot from that angle. Make sure you can ping the target computer. Make sure you can connect to the admin$ share on the target computer by going to ‘Start > run > \\targetComputer\admin$’ If you are not able to connect to the admin$ share, then you might need to take another look at your firewall and permissions: getting-started-with-batchpatch

    ‘Deployment’ actions

    For troubleshooting ‘Deployment’ actions, start by making sure that ‘Windows Update’ actions are working properly (see above). If you have Windows Update actions working, then everything that is needed for Deployment actions to work is already in place. The most common problem people encounter when executing a Deployment is that they forget the silent parameter, and then the Deployment hangs indefinitely. You can read more about understanding and discovering silent parameters for Deployment actions here: understanding-and-discovering-the-silent-parameters-required-to-remotely-deploy-software-with-batchpatch

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

Removing Adobe Flash Player from Multiple Remote Computers

Last year we posted one method for removing / uninstalling Adobe Flash from multiple computers (uninstall-adobe-flash-player-from-multiple-computers), but there is another method that might be easier or work better, depending on your situation, so I’m going to explain that process below.

Adobe has a Flash player removal utility available from the following link that makes it simple to remove any Flash plugins. When you deploy that utility with BatchPatch you can quickly/easily handle numerous computers, simultaneously.

Adobe Flash Player Removal Utility

As noted on the top of the Adobe Flash Player Removal Help Page, the removal utility will not work for the Flash Player included with Microsoft Edge or Internet Explorer on Windows 8 and later or with Google Chrome on all supported operating systems. For those situations you would simply enable/disable Flash in the browser, as described here.

To remove the Adobe Flash Player Plugins using BatchPatch with the “uninstall_flash_player.exe” utility, here’s all you need to do:

  1. Highlight the desired hosts in the BatchPatch grid, and the select ‘Actions > Deploy > Create/modify deployment’
  2. In the deployment window you’ll need to select the file to deploy as the “uninstall_flash_player.exe” like in the below screenshot. Additionally, you must add the -uninstall parameter in order to execute this installation remotely, unattended and silently.
  3. Once you have the deployment configured, you can simply go ahead an execute it by clicking ‘Execute now.’ Any host that is selected in the grid will be affected. When the deployment completes, BatchPatch will display ‘Exit Code: 0 (SUCCESS).’
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

The Best Way to Patch an Isolated Network Environment

We have talked a lot about offline patch management with BatchPatch, and today will be no exception. We truly believe that BatchPatch provides the best, simplest, least expensive way to apply updates to machines on isolated networks. (We also happen to believe that BatchPatch is the best, simplest, and least expensive option for updating machines that are *not* on isolated networks!) Many organizations have at least one high-security network that is either completely offline or sometimes just minimally connected, which makes Windows Updates and patching the computers in said network much more challenging than it would otherwise be.

BatchPatch addresses the need for offline patch management of isolated networks by allowing the administrator to use an internet-connected computer to pre-download all updates that are required by computers on the offline network so that he/she can then copy the update files to the isolated network. From there BatchPatch is able to distribute the updates to all of the computers on that same offline network segment. This way the machines on the offline network do not ever have to connect to the internet nor to another online network segment. Furthermore, BatchPatch provides a couple of different methods for handling offline patch management, such that if you are not even able to remove a single text file from the offline network due to stringent security requirements, BatchPatch can still work by enabling the administrator to only move/copy files in one direction *to* the high-security network without ever having to remove any files *from* the high-security network.

The main page we have setup to discuss ‘Cached Mode’ and ‘Offline Updates’ is here:

Additionally, we address offline Windows Update options in more detail here:

If you aren’t sure about how well BatchPatch will work in your environment, the good news is that the evaluation is totally free and allows you to patch up to 4 computers, simultaneously. You can download it from

If you have any questions about the application, licensing, pricing, trials, quotes, invoices, POs etc, please reach out to us through the contact form at


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

How to Automate Windows Updates with Multiple Patch and Reboot Cycles

Anyone who has worked with Windows Updates for any length of time has encountered the situation where after downloading/installing updates and rebooting, all of a sudden after the computer comes back online there are new updates available, even though all available updates were installed before the reboot. This seems to be an unavoidable fact with Windows Updates some months where an update simply will not be “available” until after certain other updates have been installed. And while it certainly isn’t a big deal to just install the newly available updates and reboot a second time when you’re dealing with a single computer, if you’re dealing with a lot of computers or you have a brief maintenance window to work with, things tend to get complicated very quickly. Soon you find yourself at the end of the maintenance window with machines offline that need to be online, and confusion about which machines have been rebooted twice and which ones have only been rebooted once etc. Wouldn’t it be nice if you could have a one-click way to launch a cycle of multiple updates and reboots across many computers, simultaneously? BatchPatch to the rescue! Here’s how you can use BatchPatch to automate a sequence of multiple update plus reboot cycles.

BatchPatch’s Job Queue Feature:

In BatchPatch we select the hosts that we want to update, and then we select ‘Actions > Job Queue > Create/modify job queue’

One option for a typical update + reboot cycle is illustrated in the screenshot below. The steps are as follows:

1. Download and install updates + reboot always
2. Wait 10 minutes
3. Download and install updates + reboot if required


A second option for a typical update + reboot cycle is illustrated in the following screenshot. In this job queue we utilize the BatchPatch built-in option to ‘Wait for host to go offline and come back online.’ A host is determined to be offline when X pings timeout/fail, where X is an integer defined under ‘Tools > Settings > Grid preferences > Hosts are considered offline after X ping timeouts.’ The default value for this setting is 3, and that works great for physical computers. We recommend a value of 2 for virtual machines that are able to reboot extremely quickly. A host is determined to be back online after it both responds to pings AND also responds to WMI queries.

The steps are as follows:

1. Download and install updates + reboot always
2. Wait for host to go offline and come back online
3. Wait 1 minute
4. Download and install updates + reboot if required


If you want, you can add even more steps to the job queue, whether that be for an additional update + reboot cycle or if you need to execute a custom script or retrieve some info from host computers. However, for our purposes, 2 cycles of update + reboot is sufficient.

Once you have a job queue created you execute it right away for the selected hosts in the grid using the ‘Execute now’ button, or you can save the queue using the ‘>>’ button for later execution. Once a queue has been saved, then to execute it for a given set of hosts/rows in a grid, you would simply highlight the hosts and select ‘Actions > Job Queue > Execute saved job queues > *Your job queue name*’

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

The Best Way to Patch an Isolated Network

One of our goals with BatchPatch is for it to be the best tool for patching isolated networks. We think it provides the simplest method for applying Windows Updates in bulk to computers on segregated and/or offline networks. When dealing with isolated/segregated networks, there are typically some additional challenges involved in keeping computers up to date. The computers typically will not have internet access, and usually the computers will also not have physical connectivity to other networks. This ‘air gap’ presents a significant obstacle for the administrators, especially in cases where the segregated network has very strict rules due to its high-security designation. After all, the purpose for an air-gapped network is usually to increase the over all security of the connected computers. On the one hand, keeping computers patched and up to date is paramount to maintaining security of the network, but other hand, how do you patch the computers if they are not connected to anything?

We describe, in detail, all of the cached mode and offline update options in BatchPatch at this link: Cached Mode and Offline Updates


There are two basic options that BatchPatch provides for patching an air-gapped network of computers

Option A: On an internet-connected computer, pre-download *all* Windows Updates for the operating systems that you plan to patch. Then bring all of those updates on a hard drive to the offline network and use BatchPatch to apply them to all of the computers.

The advantage of option A is that files never need to be transferred from the offline network to an online network. In high-security environments this might be particularly useful because change-management requirements might make it very difficult or perhaps impossible to remove files from the offline, high-security network.

The disadvantage of option A is that you have to download *all* available updates for a given OS, which might take some time.

Step-by-step tutorial for option A: Patching an isolated environment with strict security rules

Option B: First run BatchPatch on the offline network so that it can produce a report of all the updates that are needed by computers. Take the report to a computer that has internet access, and then use BatchPatch to download the needed updates from the report. Then bring the downloaded updates from the internet-connected computer to the offline network where you can then use BatchPatch to apply those updates to the computers that require them.

The advantage to option B is that you will only need to download the exact/specific updates that are required by computers on the offline network. This might be a significant time saver over option A.

The disadvantage to option B is that it requires taking a simple BatchPatch text file report from the offline network to an internet-connected computer. Security restrictions and/or change-management protocol may make this a very difficult or impossible task.

Step-by-step tutorial for option B: Patching an isolated environment with less stringent security rules

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