BatchPatch Task Scheduler Recurrence Options

Most of you are probably well aware of the fact that Microsoft releases Windows Updates on the second Tuesday of each month. This recurring Tuesday has come to be known in the industry as ‘Patch Tuesday.’ One of the things that has always been annoying to many admins is the fact that while Patch Tuesday is always the second Tuesday of the month, the Wednesday that comes the day after Patch Tuesday is not necessarily always the second Wednesday of the month! For example, if the first day of a given month is a Wednesday, then the Wednesday that comes the day after Patch Tuesday will be the third Wednesday of the month, not the second.

Why does all this matter? Well, in terms of scheduling, it can be a bit tricky. Some companies choose to apply Windows Updates almost immediately after they are released on Patch Tuesday. For some this means that the Wednesday after Patch Tuesday is server maintenance day. For others it means that the Friday or Saturday after Patch Tuesday is server maintenance day. If you are scheduling any portion of your update process to run automatically, you need a good way to define the maintenance window. If you choose to have a recurring schedule that runs on the second Wednesday of every month, you’re going to miss your target in the months where the second Wednesday is not the day that comes after the second Tuesday.

In the most recent release of BatchPatch we added a new recurrence option to the Task Scheduler. So now if you want to schedule your tasks to run on the day after Patch Tuesday, you can do it more easily. For any recurring task you can now define a run time to come X days after a reference time. In the screenshot below you can see that I’ve set recurrence to be ‘Monthly (2nd Tuesday) + 1 days’ which means that no matter how the days fall, my schedule will always run on the day after Patch Tuesday.

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

Synchronize a BatchPatch Grid with Active Directory OUs and Groups

In the new version of BatchPatch that was published yesterday we added a new feature that people have been asking about for a while. You can now “link” a grid to any number of organizational units (OUs) or security groups in Active Directory, enabling you to synchronize the list of computers in the BatchPatch grid with the list of computers in the Active Directory OUs and / or groups.

Here’s how it works:

  1. Select ‘File > Synchronize grid with directory…’

  2. In the window that appears you enter the LDAP path to an OU or security group.

  3. After you enter the desired LDAP path, click ‘Verify path and add to list.’ BatchPatch will attempt to connect to Active Directory and list the computers in the specified OU or security group.

  4. The computers contained in the specified OU or group will be listed so that you can confirm you want to include this LDAP path in your configuration. Click OK to include this LDAP path. The path will be added to this grid’s configuration.

  5. Continue adding as many LDAP paths as you want to be included. For the sake of this example, I have added two LDAP paths. In my test domain here I have all of my computers in the OUs called ‘ComputersOU’ and ‘Domain Controllers.’

  6. The LDAP paths that have been added to the configuration will now be used for synchronization. Click ‘Synchronize BatchPatch grid now’ to have BatchPatch compare the list of computers in the OUs and groups that you specified with the list of computers in your BatchPatch grid. Any computers that exist in the OUs/groups that do no currently exist in the grid will be displayed. You then have the option to either add all of them to the grid, or you may optionally remove any from the list before adding to the grid. In my case, I don’t have any computers in my BatchPatch grid, so the synchronization results show me all 4 of my computers. I click OK to add them to the grid.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Advanced Multi-Row Queue Sequence – Video Tutorial

This video tutorial demonstrates how to use the Advanced Multi Row Queue Sequence in BatchPatch.

For written tutorials, please see the following links:

Advanced Multi-Row Queue Sequence – Written Tutorial 1
Advanced Multi-Row Queue Sequence – Written Tutorial 2

Advanced Multi-Row Queue Sequence – Video Tutorial:


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

Virtual Machine – Create Snapshot, Apply Windows Updates, Reboot, Remove Snapshot (Basic Multi-Row Queue Sequence Example)

Recently we were asked if BatchPatch can be used to automate a process to snapshot a virtual machine, apply Windows Updates to the virtual machine, reboot it, verify the VM is back online after reboot, and then finally remove the snapshot. Something like this is actually very doable with BatchPatch. The key thing to keep in mind here is that we will execute the commands to create and remove the snapshot on the virtual machine host computer, but we will be executing the download/install/reboot process on the actual guest virtual machine. Below I will show you how we are able to link this all together into a single one-click process using the BatchPatch feature called ‘Basic Multi-Row Queue Sequence‘.

  1. Let’s start by adding the commands for both creating and removing Hyper-V virtual machine snapshots. Select ‘Actions > Execute remote process/command > Create/modify remote commands (logged output)’
  2. We are going to use the following two PowerShell commands for creating and removing the snapshot:
    checkpoint-vm -Name VMGUEST -Snapshotname MyCheckpointTest
    get-vm VMGUEST | remove-vmsnapshot -Name 'MyCheckpointTest'

    However, to execute these PowerShell command in BatchPatch we have to modify them slightly, as follows:

    cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "checkpoint-vm -Name VMGUEST -Snapshotname MyCheckpointTest"
    cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "get-vm VMGUEST | remove-vmsnapshot -Name 'MyCheckpointTest'"

    In the ‘Remote Process’ User-Defined Commands (logged output) window we add those commands. See screenshot for example. Note, the title can be whatever you want it to be, but make sure the command is formatted as shown above. However, of course you will substitute your own VM names and snapshot names. In this example my virtual machine is called VMGUEST. The snapshot will be titled MyCheckpointTest.

  3. Now that we have created the VM snapshot creation and removal commands in BatchPatch, we can go ahead and setup the queue. Let me first outline the process clearly so that you can see exactly the steps that we are going to take to make this happen. We are going to setup a basic multi-row queue sequence, which enables us to tie together multiple hosts into a single sequence. For the sake of this example our VM host will be called VMHOST. Our VM guest will be called VMGUEST. Our snapshot will be called MyCheckpointTest.
    Step 1: Execute the command to create the VM snapshot.  This command will be executed remotely on VMHOST.
    Step 2: Execute the command to download and install updates + reboot the VM guest machine.  This command will be executed remotely on VMGUEST.
    Step 3: Wait a few minutes
    Step 4: Verify that VMGUEST is online
    Step 5: Execute the command to remove the VM snapshot.  This command will be executed remotely on VMHOST.
  4. To start, I have added our VMHOST and VMGUEST computers to the BatchPatch grid. Note that I have added the VMHOST computer two times, and the order of the hosts is:

    The reason for this is because our first command will be executed on the VMHOST, our second command (or set of commands) will be executed on the VMGUEST, and our third command will be executed on the VMHOST. When using the Basic Multi-Row Queue Sequence, the order of the hosts matters. When we actually execute the sequence, it will be executed in the order that we select/highlight the hosts in the grid. So for ease of operation we put the hosts in order so that we can easily select them in order. However, if the hosts were not in the grid in the correct order, we could still execute the Basic Multi-Row Queue Sequence in the correct/desired order by first selecting them in the desired order. However, putting them in the grid in the desired order just makes it a bit simpler. Also note, you could alternatively use the Advanced Multi-Row Queue Sequence to handle this task, and in that case the ordering would matter less.

  5. Next we need to apply a Job Queue to each row in the grid. Select the first host VMHOST and click ‘Actions > Job queue > Create/modify job queue’ In the job queue window use the ‘Saved User-Defined Commands and Deployments’ grid in the lower-left to select the command we input earlier to create the VM checkpoint.

    Then click ‘Apply queue to row(s) without executing.’ What we have done here is the first entry for VMHOST now has a job queue configured with just a single command, and this command will be responsible for creating the VM snapshot of our VMGUEST. Your BatchPatch window should look like this:

  6. Next select VMGUEST in the BatchPatch grid, and then click ‘Actions > Job queue > Create/modify job queue’ For this VMGUEST we need 3 steps as shown in the screenshot below.
    Download and install updates + reboot always
    Wait 3 minutes
    Wait for host to be detected online

    Once again click ‘Apply queue to row(s) without executing.’ Your BatchPatch grid should now look like this:

  7. Next select the third row in the BatchPatch grid (this is the second entry for VMHOST). Then click ‘Actions > Job queue > Create/modify job queue’ For this host our job queue will again contain just a single step to execute the command to remove the snapshot that we created earlier. Then click ‘Apply queue to row(s) without executing.’
  8. At this point the BatchPatch grid is ready for final execution of the entire process. Your grid should look like mine does in the screenshot below:
  9. We’re finally read to begin execution. Select/highlight the hosts in the grid in the order that the queue is to be executed. Since we deliberately created this grid to execute in sequential order from top to bottom, make sure to select the hosts from top to bottom. Once selected, choose ‘Actions > Job queue > Execute basic multi-row queue sequence’ When you do this what will happen is as follows:
    Step 1: Execute the command to create the VM snapshot.  This command will be executed remotely on VMHOST.
    Step 2: Execute the command to download and install updates + reboot the VM guest machine.  This command will be executed remotely on VMGUEST.
    Step 3: Wait a few minutes
    Step 4: Verify that VMGUEST is online.
    Step 5: Execute the command to remove the VM snapshot.  This command will be executed remotely on VMHOST.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

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