BatchPatch March 2023 New Release

By Scott | Published: April 3, 2023

On Friday we published a new version of BatchPatch. In addition to numerous smaller fixes and improvements (you can view them in the app under Help > Check for updates > View change log), we added more grid encryption options which are all available under File > Protection Options. For those of you using the BatchPatch ‘Run-As-Service’ feature, you can now use it with grids that are encrypted with any of the key-based encryption options.

The protection options in this form control how the grid file is protected when it’s saved to disk. These protection options are particularly relevant for users who are specifying ‘Alternate Credentials’ in their grids.

The most secure way to operate BatchPatch is with ‘Integrated Security’, where the account that is used to run BatchPatch is the same account that is granted permissions on target computers for BatchPatch to perform actions. When integrated security is used there are no credentials involved because the BatchPatch application will run in the context of the permissioned user, so no credentials have to be specified in the application for it to work. However, for BatchPatch users who are specifying alternate credentials for any rows in their grids, those credentials are saved in the .bps grid file when you save the grid file to disk (using File > Save), so when using alternate credentials it’s very important to protect those files.

To read more about ‘Integrated Security’ vs ‘Alternate Credentials’, as well as the security ramifications of using ‘Alternate Credentials’ please see:
Using Alternate Logon Credentials in BatchPatch

==================================================================================

Grid Protection Options:

Obfuscation – Legacy password field obfuscation ( Deprecated ):

This legacy mode is deprecated and is only available now for backward compatibility with older versions. In this mode each password in a grid’s password column is individually obfuscated when saved to a .bps/.bpt file. This obfuscation mode does NOT provide any meaningful security. Proceed with caution. Use encryption over obfuscation whenever possible.

=============================================

Obfuscation – Standard credentials field obfuscation:

In this mode each username and password in a grid’s credentials columns are individually obfuscated when saved to a .bps/.bpt file. This obfuscation mode does NOT provide any meaningful security. Proceed with caution. Use encryption over obfuscation whenever possible.

=============================================

Encryption – Credentials field encryption:

In this mode each username and password in a grid’s credentials columns are individually encrypted with AES-256 when saved to a .bps/.bpt file. The encryption/decryption key is randomly generated by BatchPatch per-user, per-computer and stored locally on this BatchPatch computer, encrypted, using the Windows Data Protection API (DPAPI). Files saved in this mode are tied to both the user and the computer where they are created. That is, these files’ credentials fields cannot be decrypted/loaded into a BatchPatch instance that’s running under a different user account or on a different computer (unless you first export the encryption key from this instance of BatchPatch and then import the key into the other user’s/computer’s BatchPatch instance). Despite any encryption applied to the credentials in grids saved with this mode, we still always recommend exercising care and caution when handling files that contain sensitive passwords. Consider using additional layers of encryption as well as limiting access to these files. Also, consider making a backup of the encryption key and storing it securely (NOT on this computer). If there is a failure or accident of some kind that causes the stored key to be lost or corrupted, you will not be able to decrypt the credentials saved in the grid. Of course this isn’t necessarily critical since re-populating the passwords in the grid or creating a new grid will always be possible, but it may cause a loss in time and productivity. Proceed accordingly.

=============================================

Encryption – Whole file encryption:

In this mode the entire grid is encrypted with AES-256 when saved to a .bps/.bpt file. The encryption/decryption key is randomly generated by BatchPatch per-user, per-computer and stored locally on this BatchPatch computer, encrypted, using the Windows Data Protection API (DPAPI). Files saved in this mode are tied to both the user and the computer where they are created. That is, these files cannot be decrypted/loaded into a BatchPatch instance that’s running under a different user account or on a different computer (unless you first export the encryption
key from this instance of BatchPatch and then import the key into the other user’s/computer’s BatchPatch instance). Despite any encryption applied to the grids saved with this mode, we still always recommend exercising care and caution when handling files that contain sensitive passwords. Consider using additional layers of encryption as well as limiting access to these files. Also, consider making a backup of the encryption key and storing it securely (NOT on this computer). If there is a failure or accident of some kind that causes the stored key to be lost or corrupted, you will not be able to decrypt the grid. Of course this isn’t necessarily critical since creating a new grid will always be possible, but it may cause a loss in time and productivity. Proceed accordingly.

=============================================

PRIMARY vs AUXILIARY key / Sharing encrypted grids

When BatchPatch is first launched it randomly generates a PRIMARY encryption key plus an AUXILIARY encryption key. There is no functional difference in behavior between the PRIMARY and AUXILIARY versions of the same mode. However, we include an AUXILIARY key option for each encryption mode so that users who want to share encrypted grids can do so without sharing their PRIMARY keys. If you want to regularly share encrypted grids with a co-worker, you can do this by sharing your AUXILIARY key. Export it and then have your co-worker import it into his/her BatchPatch instance as his/her AUXILIARY key. After that you’ll both have identical AUXILIARY keys, and thus you’ll be able to share grids that you have encrypted with your AUXILIARY key. Grids that are intended to be kept private should be encrypted with your PRIMARY key so that they are only decryptable by your own logon account.

=============================================

Encryption – Whole file encryption – Password-based key derivation:

In this mode the entire grid is encrypted with AES-256 when saved to a .bps/.bpt file. The encryption/decryption key is derived per grid, using PBKDF2, from the password that you set for each grid that is saved in this mode. Despite any encryption applied to the grids saved with this mode, we still always recommend exercising care and caution when handling files that contain sensitive passwords. Consider using additional layers of encryption as well as limiting access to these files. Note, in this mode since the encryption key used to encrypt/decrypt the file is derived from a password that you specify, it’s important to choose a password wisely. Password-based encryption usually does not provide the same level of security as key-based encryption since the average person tends to create and/or use relatively weak passwords that are more easily guessable by brute-force (attempting a large number of passwords until finding the correct one that successfully performs decryption of the encrypted data). Since the strength of the encryption in password-based encryption is limited by the strength of the password, choosing a unique, long, unpredictable/random password provides the most protection against brute-force.

=============================================

Export/import key:

When using the PRIMARY/AUXILIARY key modes, consider exporting the encryption key as a backup and storing it securely (NOT on this computer) because if any situation arises where the locally stored key becomes damaged or lost (BatchPatch computer dies or is replaced, corruption occurs, user profile is deleted from this computer, etc) you won’t be able to decrypt anything that was encrypted with the key. In many environments this might not be critical since creating a new grid from scratch will always be an option, but it may cause a loss in time and productivity, so proceed accordingly. In the case of ‘Credentials field encryption’, only the credentials fields will be unable to be decrypted, but the rest of the file will remain as clear text. However, in the case of ‘Whole file encryption’, the entire file will be unable to be decrypted and will therefore be completely unusable.

=============================================

Windows Data Protection API (DPAPI):

BatchPatch uses the DPAPI to protect the locally stored keys on disk. The DPAPI provides a reversible form of encryption that is used to store secrets on disk. These secrets are generally protected by the credentials of the user logon account under which they are stored. If an attacker is able to run code in the context of a user that stored secrets using the DPAPI, the attacker will then also have the ability to decrypt those secrets if A, the attacker locates those DPAPI-protected secrets on disk, and if B, the attacker has enough prior technical knowledge of the specific application that performed the DPAPI-protect operations in order to be able to successfully decrypt those protected secrets.

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

Silently Install Patches Remotely and Automatically Reboot Many Computers

By Scott | Published: February 16, 2023

If you’re new to BatchPatch you probably arrived at this page after some web searching or maybe through a link posted by someone in an IT-related forum. Presumably you’re looking for a tool that will enable you to easily install Windows Updates as well as third-party software and patches on a group of remote computers quickly and efficiently. Well, you’ve come to the right place. BatchPatch makes it easy to do remote updates, remote deployments, remote installations, remote script executions, remote command executions, and pretty much any similar task that you can think of. BatchPatch is perhaps the simplest and least expensive option for executing a task on numerous computers all at the same time. It gives you a high degree of power and control without requiring a lot of overhead, resources, human-power, or time.

Some of the basic functionality that BatchPatch offers includes options for remotely checking which Windows updates are needed by your computers, or downloading and/or installing Windows updates across an entire network of computers with a single click. BatchPatch also provides capability for retrieving information from computers into a consolidated grid view. For example, if you need to quickly identify which of your computers has a particular registry value set, or which computers have a particular OS version installed, or if you just need to see the last bootup time of your computers, BatchPatch provides functionality for that. If you need to deploy a 3rd-party application to your network of computers, you can use BatchPatch to do that very easily too. All of the actions in BatchPatch can also be scheduled to execute when you’re asleep, if desired, for maximum convenience. However, for networks with critical uptime requirements we generally still recommend watching over your jobs in real-time because even if everything goes smoothly in BatchPatch, you just never know if you reboot a computer if it might get stuck somewhere along the way. As great as Windows is, it’s not immune from problems from time time. Scheduled tasks are great, but they are not appropriate for every environment or every situation.

You can see a more comprehensive list of available features on our home page, or better yet download the free evaluation version of BatchPatch and just start experimenting with it yourself. It’s known for being very quick and painless to learn how to use. We have spent a lot of time keeping the functionality as intuitive as possible for sysadmins, so most users will “just know” how to use it right from the start without having to think about it or study documentation. Additionally, many users feel an immediate sense of empowerment when they start using the app because it provides so much control so quickly and easily.

One of the more powerful features that BatchPatch offers is the automation. In particular, not only can you use BatchPatch’s Job Queue feature to execute a sequence of steps on a given target computer or on a group of target computers, but what’s really cool and amazingly powerful is the functionality that BatchPatch provides for executing a sequence of operations that involves multiple computers. That is, you can use the BatchPatch Advanced Multi-Row Queue Sequence feature to orchestrate complex sequences where multiple steps are executed on multiple computers, where the computers and sequence steps are dependent upon one another. So for example if you have 10 target virtual machine guests running on a single virtual machine physical Hyper-V host, you could use this sequencing feature to initiate with a single click the download and install of updates on all virtual machines, and then after the installation process has completed on all 10 machines the sequence could be configured to auto-trigger the VM host to download and install updates and then reboot. So with a single click you get all of the VM guests and hosts updated while you just sit back and watch in real-time (or while you sleep, if desired). You could also do more complex sequences that involve many computers and many dependencies… for example if you want to execute job queue A on target computer A, job queue B on target computer B, and job queue C on target computer C, and then when all of those machines have completed executions of their respective job queues, the sequence can automatically trigger computers D, E, and F to run their job queues. And so on. There isn’t really any kind of limitation to the types of queues or sequences that can be put together. Sequences are able to wait until machines/groups complete any task or reboot etc before the next group proceeds, so if you have 100 computers that all need to be updated and rebooted, but only 10 of them can be offline at any one time, you could use a BatchPatch sequence to configure the entire process to run in a single click (or at a scheduled time). The functionality is a bit difficult to explain in a way that really captures how powerful it is, so I would encourage you to watch a video demonstration to see how it works here, or check out a written tutorial here.

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

BatchPatch Stuck Searching for Available Updates on a Windows 8.1 or 2012R2 Target

By Scott | Published: January 13, 2023

This isn’t really a BatchPatch problem per se, but it’s come up a couple of times in the past handful of months, so I want to take a moment to discuss it here today.

The issue is that when you have a Windows 8.1 or 2012R2 target computer, the search for available updates seems to go on forever. It may never return, or it may return many hours later and not find any updates (or it may also possibly find updates).

If you’re having this problem it’s likely due to an issue with the Windows Update client for those operating systems that was resolved in KB3138615

To resolve the issue, download the update directly from Microsoft, and then install it on your Windows 8.1 or 2012R2 target host.

You can either manually install the update by double-clicking the Windows8.1-KB3138615-x86.msu on the target computer’s desktop, or if you want to push the update from BatchPatch to one or more target computers, you can do that as well by following the instructions at this link: Deploying .msi, .msu, and .msp Files Remotely to Numerous Computers

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

Remotely Execute a Script that Connects to a Third Remote Computer

By Scott | Published: December 21, 2022

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 Context… SYSTEM 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$

By Scott | Published: November 29, 2022

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

By Scott | Published: October 26, 2022

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

By Scott | Published: October 5, 2022

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

By Scott | Published: September 23, 2022

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 some 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

By Scott | Published: September 9, 2022

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

By Scott | Published: August 29, 2022

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