Remotely Execute a Script that Connects to a Third Remote Computer

PROBLEM:

In BatchPatch you want to deploy a script to target computers that will connect to a third remote machine when it’s executed. That is, BatchPatch is running on computerA, your target computer where the script will run is computerB, and the script will create a connection to computerC. How do you do this in BatchPatch?

You might have noticed that if you have multiple hops involved (e.g. BatchPatch computerA remotely executes a script on target computerB [HOP1], which then establishes a remote connection to server computerC [HOP2]), you might encounter an error or unexpected failure.

The issue in the example described above occurs as a result of how authentication is handled in Windows. If you were to perform a Google search for something like double hop authentication you’ll be able to find more on this topic. Essentially the issue is that when BatchPatch authenticates from computerA to computerB, it doesn’t mean that this authentication is then able to automatically cross another hop from computerB to computerC. However, it’s actually still possible to accomplish this in BatchPatch, but there are a few things that you need to consider first.

SOLUTION:

  1. Permissions: This might seem obvious, but first make sure that the account that is being used to execute the script has the necessary permissions to connect to both computerB and computerC.
  2. Execution context: In BatchPatch under Tools > Settings > Remote Execution > Remote Execution ContextSYSTEM will not have access to network resources. This is by design in Windows. The SYSTEM account is a highly privileged account for the local system, but it cannot authenticate across a network. So, when BatchPatch deploys ascript to target computerB under SYSTEM, when the script actually runs on computerB it will not be able to reach any network locations, so a script that attempts to connect to a path on computerC will never be able to do so. In order for it to be able to work properly and have access to network resources, the BatchPatch remote execution context setting needs to instead be set to Elevated token + Interactive.
  3. Integrated security vs alternate credentials: In addition to the remote execution context, there is a consideration regarding how you authenticate to the target computer. While we generally always recommend using integrated security for authentication whenever possible, in this double-hop scenario you’ll actually have to instead specify alternate credentials for authentication to be successful across the second hop. In the case of integrated security, when BatchPatch on computerA tries to connect to computerB to run a script that connects to computerC, it will fail because Windows doesn’t allow authentication to make that extra step from computerB to computerC after it has already allowed authentication from computerA to computerB. However, when you use alternate credentials, you get an extra hop, essentially, because those credentials are used directly on computerB to execute the script. With integrated security the first hop is to computerB and the second hop is to computerC. However, with alternate credentials it’s more like having two first hops. You can authenticate from computerA to computerB (first hop), but then the credentials can be employed directly on computerB to authenticate on computerC (also a first hop, essentially), thus allowing your script to complete successfully.
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Custom Local Command to Launch Explorer Window to Target Computer C$

If you want to hard-code into your BatchPatch menu a command that will launch \\targetComputer\C$ or similar, it’s pretty simple. Here’s all you need to do:

  1. Create a local command in BatchPatch by selecting Actions > Execute local process/command > Create/modify local commands
  2. The actual command syntax to use is:
    cmd.exe /c start \\$computer\c$
    cmd.exe /c start \\$computer\SomeOtherFolder

  3. Once the command has been saved you’ll see it appear in the BatchPatch menu under Actions > Execute local process/command > Execute local commands
  4. You can also add optionally add a toolstrip button with Tools > Customize visible toolstrip buttons. Just scroll to the bottom of the Customize Toolstrip window and check the box next to the local command that you created.

  5. After you select one of the execution methods, you’ll be prompted to confirm execution. When you click OK to proceed, BatchPatch will replace $computer in the command with the actual host name that is in the Host column for the row where the command is being executed, thereby opening Explorer to the desired location.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Remotely Deploy Windows Updates to Multiple Computers

BatchPatch provides an easy way for you to apply Windows Updates to numerous target computers, simultaneously. The BatchPatch interface is about as intuitive and straight-forward as it gets. The process to remotely install Windows Updates involves just a few simple steps.

  1. Load a list of computer names or IP addresses into a BatchPatch grid. You can either manually type your list (or use copy/paste) into the Grid > Add hosts window, or you can drag/drop a text list onto the BatchPatch window, or you can use File > Import to import your text file list, or you can import host names directly from your Active Directory with Grid > Add hosts from directory
  2. Highlight the hosts in the grid that you want to act on, then select the desired action to execute. Highlight/select the hosts in the grid that you want to include. Then either right-click on the selected/highlighted area or use the Actions menu to execute the desired action. In this case we’ll execute Actions > Windows updates > Download and install updates + reboot if required
  3. Click OK to proceed with execution.
  4. That’s all there is to it! If you are looking for instructions for updating offline computers, please see here. For a list of some of the many other features that BatchPatch offers, please see here.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Deploying Windows Defender Antivirus Definition Updates to Offline Computers

If you need to push Microsoft Windows Defender definition updates to offline computers, here’s how to do it:

  1. Download the version of the Microsoft security intelligence file that is appropriate for your target computers’ operating systems. On the following page Microsoft has links to all of the various flavors that this file comes in. At the time of this writing, those files cover updates for the following different products:

    • Microsoft Defender Antivirus for Windows 11, Windows 10, Windows 8.1, and Windows Server 32-bit | 64-bit | ARM
    • Microsoft Security Essentials 32-bit | 64-bit
    • Windows Defender in Windows 7 and Windows Vista 32-bit | 64-bit
    • Microsoft Diagnostics and Recovery Toolset (DaRT) 32-bit | 64-bit
    • System Center 2012 Configuration Manager 32-bit | 64-bit
    • System Center 2012 Endpoint Protection 32-bit | 64-bit
    • Windows Intune 32-bit | 64-bit
  2. After you download the appropriate security intelligence file, you’ll have one of the following three executeable files: mpam-fe.exe, mpam-feX64.exe, or mpas-fe.exe. The executable can be manually installed on a given computer by simply running it (double-click on it or execute it from the cmd prompt). However, to deploy this file to numerous offline computers through BatchPatch you need to setup a BatchPatch Deployment. For the sake of this example I will be using mpam-fe.exe. If you are using a file with a different name, please adjust the instructions below accordingly to match your filename.
  3. In BatchPatch select Actions > Deploy > Create/modify
  4. In the Deploy window, add a title, then browse to the path of the mpam-fe.exe file on your computer. Your deployment configuration should look similar to mine in the screenshot below. Note, the parameters field is empty because the mpam-fe.exe file is built to be executed as-is without any additional switches/parameters.
  5. Click the double-right arrow button to save the deployment. Then close the Deploy window.
  6. You’re now ready to execute your deployment. Highlight the desired target computers in your grid, and then select Actions > Deploy > Execute saved deployments > Defender Definitions. This will execute the deployment for all selected/highlighted hosts. When the deployment is executed, BatchPatch will copy the mpam-fe.exe file to each target computer and then execute it, remotely, to apply the update definitions contained in the file. That’s all there is to it.
Posted in Blog, General, Tutorials | Tagged , , , , , | Comments closed

BatchPatch Windows update: Error 1601

There are two primary flavors of error 1601:

Windows Update: Error 1601: Failed to retrieve WMI info. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

“Access is denied” means that you have a permissions problem. Please follow the steps outlined on the following page to rectify the issue: BatchPatch Authentication In Domains And Non Domain Workgroups

Windows Update: Error 1601: Failed to retrieve WMI info. The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

“RPC server is unavailable” is typically caused by one of the following things:

  1. The large majority of occurrences of “RPC server is unavailable” are due to a firewall blocking communication. If BatchPatch makes a query to a remote server but does not receive a response, this is the error that you will see. Windows firewall, a third-party software firewall, or a network firewall is likely preventing communication to the target host. Make sure your firewall is set to allow the appropriate communications to pass through. In the case of this particular error, WMI communications must be allowed. While you could, of course, disable the firewall altogether, this is generally not recommended in most cases unless it’s just to do a quick test to determine that the firewall is, in fact, the cause of the issue. Depending on your environment, it might be ok to briefly turn off the firewall as a test, but be mindful that there are many situations where a firewall should not ever be turned off even for a moment. For instructions on configuring Windows firewall to work with BatchPatch, see this page: Using BatchPatch With Windows Firewall
  2. The second most common reason why you might experience this “RPC server is unavailable” error is due to the remote computer being offline. This RPC error is what you’ll see if there is simply no response to the initial query that BatchPatch makes when you attempt a Windows Update action. Make sure the target computer is online. If the computer is online, try the IP address instead of the host name to ensure that isn’t some kind of name resolution issue. If the computer is definitely online but you’re still getting this RPC error even when using the IP address instead of the host name, refer back to the item above and check the firewall since this error is almost always due to a firewall blocking communications.
  3. Check to make sure that RPC (Remote Procedure Call) service is running on the target computer. The service should be started and set to ‘Automatic’. If the RPC service is not running on the target computer, not only will BatchPatch not be able to connect to it, but it’s likely that you’re going to be experiencing a lot more issues with that target computer in addition to BatchPatch not working. It’s highly unlikely that you’ll ever find this service NOT running since Windows needs it to be running for so many reasons, but do a quick check just to make sure.
  4. In rare cases this error might be caused by anti-virus or host intrusion prevention/protection software or some other similar security software suite blocking the connection.

If you’ve gone through each of the items above and you’re still having issues, please see Troubleshooting Common Errors in BatchPatch

If you’re seeing a different 1601 error message, such as Windows Update: Error 1601: Failed to retrieve WMI info. Invalid class, or Windows Update: Error 1601: Failed to retrieve WMI info. Invalid namespace, then you might have an issue with WMI on the target computer. The first best bet is usually just to reboot the target computer to ensure that the issue wasn’t transient. Assuming the reboot does the not resolve the problem, please review the various steps at this page for resolutions to many/most WMI failures: WMI: Missing or Failing WMI Providers or Invalid WMI Class

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

BatchPatch Custom Script Integration – Wait for Service to be Running Before Proceeding to Next Step in Job Queue

In the current version of BatchPatch there is not a built-in job queue method to wait for a particular service to be running on the target host before proceeding to the next step in the queue. However, it’s possible to still accomplish this by integrating a custom script. In a future version we will likely incorporate this kind of functionality into the app itself so that no custom scripts are required, but at the time of this writing, below is how you could do it in the current version of the app.

The Goal

Use a create a custom script deployment in your job queue to control when the job queue advances to the next step based on whether or not a particular service is running or stopped on the target computer.

  1. I’ve created a very simple vb script that returns 0 if the specified service is started, 1 if the specified service is stopped. The contents of my script are below:
    'Checks the status of the specified service and returns 0 if it's running, 1 if it's not running
    'Cocobolo Software LLC September 2022.
    
    'Usage: cscript.exe "C:\Your Script Repository\CheckServiceStatus.vbs" "Your service display name goes here"
    
    'The first argument from the command line is assigned to strServiceDisplayName
    
     
    strServiceDisplayName = WScript.Arguments(0)
     
    on error resume next
    Err.Clear
     
    Set objWMIService = GetObject("winmgmts:\\localhost\root\cimv2")
     
    Set colServices = objWMIService.ExecQuery("Select * from Win32_Service where DisplayName='" & strServiceDisplayName & "'")
    	For Each objService in colServices
    		If objService.Started = True Then
    			'wscript.echo 0		
    			wscript.quit(0)
    		Else		
    			'wscript.echo 1				
    			wscript.quit(1)
    		End If
    	Next
  2. Save the script. The contents of the script above need to be saved in a text file with a .vbs file extension. For the sake of this example my script is called “CheckIfServiceIsStarted.vbs”
  3. Create a deployment. The deployment will be used to copy the vbscript to the target computers, execute it, and retrieve the exit code. To create your deployment select Actions > Deploy > Create / modify.
  4. Browse to the location of your CheckIfServiceIsStarted.vbs file, and then give the deployment a title. Click the ‘>>’ button to save the deployment. The screenshot below shows the configured deployment. Note, the DisplayName of the desired service to be checked is in the Parameters field in quotes.
  5. With your deployment created and saved you can now setup your Job Queue. Go to Actions > Job Queue > Create / modify.
  6. Select the desired steps of the queue.
    Label:BEGIN
    Wait 1 minute
    Deployment (Check if DNS Client Service Is Started)
    If previous action failed/errored (returned non-0), goto label:BEGIN
    Download available updates
  7. All we have to do now is execute the queue. Click Execute now (or alternatively save the queue first and then execute it directly from the BatchPatch Job Queue menu or from within a scheduled task). When the queue executes, the effect is that if the ‘DNS Client’ service is not running on the target computer, then the queue loops back to the beginning and waits 1 minute before checking again. The queue will keep looping, waiting a minute, and checking the service again until the ‘DNS Client’ service is found to be running on the target computer, at which point the queue will advance to the next step to ‘Download available updates’. By the way, there is no special significance to the ‘DNS Client’ service. I have simply used it for the sake of creating this tutorial. You will, of course, specify the display name of service that you care about. Or you might alternatively modify the script slightly to check for multiple services at once.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Recommended Group Policy Settings for BatchPatch Standalone Usage with No WSUS

One of the questions that arises for some users who are using BatchPatch without a WSUS (Windows Server Update Services) server, is how should Group Policy be configured for target computers? The main detail here to consider is that if your computers are not setup to get their updates from a WSUS server then there is a good chance that you’re using the default Windows Update configuration where Windows Updates are automatically installed on target computers. However, if you’re now considering using an app like BatchPatch (or if you’re already using BatchPatch) to manage your monthly Windows Update process, you’re going to want to disable the automatic update functionality that your computers are currently using so that you can have BatchPatch initiate the download and/or installation of updates on all target computers. This is where Group Policy comes in. Or if you don’t have a domain environment and instead have all computers running standalone or in a Windows workgroup, then you’ll use Local Policy on each target computer instead of Group Policy since Group Policy is configured at the domain level. (Local Policy is configured on a given computer by launching the Group Policy editor locally by typing gpedit.msc in an administrator elevated command prompt)

  1. Create/edit a group policy that is linked to the OU containing your target computers. Or if there is no domain and you are just using Local Policy for non-domain computers, then simply launch gpedit.msc from an administrator elevated command prompt directly on the computer that you are configuring
  2. In Group Policy editor (gpedit.msc) go to Computer Configuration > Administrative Templates > Windows Components > Windows Update and set the Configure Automatic Updates setting to 2 = Notify for download and auto install. The effect of this setting is essentially to disable the Automatic Updates feature on the target computers. It doesn’t turn off the Windows Update service. It simply tells Windows to stop automatically downloading updates. Since you want to use BatchPatch to perform the download/install process on-demand on your target computers, you need to stop the target computers from automatically downloading and installing updates. Or if you prefer to have Windows automatically download updates but not install them until you initiate the installation process with BatchPatch, then select 3 = Auto download and notify for install. However, please note we typically do *not* recommend using setting 3 unless you are using a WSUS in your environment because if you use setting 3 with no WSUS, then you might end up with updates downloaded to target computers that you don’t intend to install. This is because with WSUS you would use the WSUS to filter which updates the target computers see as available, but with no WSUS you will use BatchPatch to control which updates are downloaded and installed. Since you might sometimes need or want to skip a particular update in a given month, if you are configured to use setting 3 instead of 2 then the update will still be automatically downloaded by the target computer even though you never plan to initiate the installation of that update through BatchPatch. While this isn’t the end of the world by any means, any such updates will waste bandwidth to be downloaded and will waste hard drive space when they sit downloaded in the Windows Update cache directory without ever getting installed. Having updates downloaded but not installed might also cause Windows to pop excess notifications about this fact at least until or unless the updates are deleted from the Windows Update cache manually or hidden so that they no longer appear as available for installation.

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

Creating Custom Email Notifications for the Job Queue

In the most recent release of BatchPatch we added a new form for custom email notifications so that instead of having a singular email notification as the only option for any time an email notification is sent in the application, you can now create as many custom email templates as you want, which enables you to have different emails go to different people at different times and based on different triggers in your job queues.

Use Actions > Email notification > Create/modify email notifications

If I then want to create an email notification that will only be used for database admins, perhaps in the cases when I am updating the SQL servers, then I can do that here with something like this:

Then once I’ve created a custom email notification I can use it a particular job queue:

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

Retrieving Logon Information from Active Directory Local Administrator Password Solution (LAPS) and inserting it into the BatchPatch Grid

In the July 2022 version of BatchPatch we added integration for Microsoft’s Local Administrator Password Solution (LAPS), so now you can easily highlight a group of target computers in your BatchPatch grid and then retrieve the LAPS password stored in Active Directory for each of the selected hosts/rows. The rows will then be automatically populated with the corresponding LAPS username/password for each selected host.

If you’re reading this tutorial then you probably already know what LAPS is, but in case you don’t… Microsoft describes that the “Local Administrator Password Solution” (LAPS) provides management of local account passwords of domain joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset. You can download LAPS here. Microsoft provides a complete configuration tutorial for LAPS here.

The installation and configuration process for LAPS is actually pretty quick and painless. Follow Microsoft’s instructions or pick another tutorial on the web (there are many). Once you have it working, it’s very easy to import logon account information from LAPS into BatchPatch.

  1. Highlight the rows in the BatchPatch grid for which you want to retrieve the LAPS password from Active Directory
  2. Select Actions > Specify alternate logon credentials > Get LAPS password from Active Directory…
  3. In the Get LAPS Password form you have to first enter the LAPS username. This is the name of the local administrator account being managed by LAPS for a given computer. When LAPS is configured for an organization, there is a Group Policy, Computer Configuration\Administrative Templates\LAPS\Name of administrator account to manage, that tells LAPS which local administrator account it should manage. Since LAPS only stores the actual password value in Active Directory, you need to tell BatchPatch the username so that when BatchPatch retrieves the password from Active Directory, it can then be inserted with the username into the Alternate Credentials field for a given row. It’s probably the case that in most environments the LAPS username will just be administrator, but of course it really all depends on your particular environment and how LAPS has been configured.
  4. You’ll also have to specify the credentials that BatchPatch should use to query Active Directory for the LAPS password values. When BatchPatch runs the PowerShell query to retrieve the LAPS password for a given computer, it needs to run under an account that has read/view permission on the ms-Mcs-AdmPwd attribute for that computer in Active Directory. If you choose Integrated Security instead of supplying credentials, BatchPatch will execute the query as the account being used to run BatchPatch. If you instead specify credentials here, note that these credentials are *not* saved to disk, but they will be remembered for the life of this BatchPatch.exe instance. When you close and re-open BatchPatch you will be required to re-enter the credentials.
  5. Finally, you’ll need to select the PowerShell query to execute.
    Get-AdmPwdPassword requires the Local Administrator Password Solution (LAPS) PowerShell module, AdmPwd.PS, to be installed on the BatchPatch computer.
    Get-ADComputer requires the Remote Server Administration Tools (RSAT) Active Directory module to be installed on the BatchPatch computer.

    Both of the above queries accomplish the same task, so you can simply pick the one for which you already have the required toolset installed.

  6. That’s pretty much all there is to it. When you click Execute BatchPatch will connect to Active Directory and retrieve the LAPS password for each of the selected rows in the grid, and then BatchPatch will insert the corresponding password along with the LAPS username into the Alternate Credentials field for each selected row in the grid.

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

New Version of BatchPatch Released July 2022

This week we released a new version of BatchPatch. Along with miscellaneous fixes and enhancements, the primary features/functionality we added are:

  1. Custom email notifications that can be saved and added to job queues or scheduled tasks. Now you can have different email notification settings for different purposes. So, for example, if you need to have one email notification that goes to one group of users at the beginning of a maintenance period, while a different email notification goes to a different group of users in the event of a problem or error, now you can do that. You can create as many different email notifications as you want or need, and then you can insert whichever ones you want into your job queues and scheduled tasks as desired. See ‘Actions > Email notifications > Create/modify email notifications
  2. Local Administrator Password Solution (LAPS) integration is now available under Actions > Specify alternate logon credentials > Get LAPS password from Active Directory. If you are using LAPS, now you’ll be able to highlight a group of computers in your BatchPatch grid in order to query Active Directory for each computer’s administrator password all at one time. The username/password will then be auto-filled into the ‘Alternate Credentials’ column in your BatchPatch grid for each selected computer.
  3. A new Windows Update search setting for updates where ‘DeploymentAction = Installation’ is now available in the BatchPatch settings. Up until recently if you wanted to emulate the Windows automatic updates search for updates so that BatchPatch would display the same group of available updates as the Windows Update automatic updates control panel interface in Windows, you would have done that by selecting ‘Important’ and ‘Recommended’ in BatchPatch. However, recently Microsoft has made a change to which updates are displayed in the Windows Update control panel interface, and we have accordingly added a new search setting in BatchPatch to emulate how Windows is doing things now in the newer versions of Windows. If you notice that BatchPatch ‘Check for available updates’ is no longer displaying the exact same search results that appear in the Windows Update control panel on the target computer, try the new search setting under Tools > Settings > Windows Update > Search Preferences > Search for updates where ‘DeploymentAction = Installation’
Posted in Blog, General | Tagged , , , | Comments closed