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.
      2016-11-23-14_43_23-batchpatch
    • 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’

      2016-11-23-15_04_06-win2012r2-virtual-machine-connection

    • 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

      2016-11-23-15_21_24-__win2012r2_-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

This entry was posted in Blog, General, Tutorials and tagged , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.