BatchPatch Remote Command Execution Options

By Scott | Published: June 24, 2020

BatchPatch has a number of commands and actions that are built-in and come with the software… Windows update commands, reboot and shutdown commands, wake on LAN, commands to get information from target computers about disk space usage, uptime, logged-on users, file version information, registry values, commands to review/modify services and processes, and a lot more. But what if you want to execute a command that isn’t already built-in? Obviously not all commands are going to be useful for all users, and we can’t include every command that ever existed in the history of all commands 🙂 Inevitably you might find yourself wanting to hard-code some of your own commands into BatchPatch to execute on remote systems.

BatchPatch provides a few different places and ways to store and execute your own commands.

1. Under ‘Actions > Get information > Create/modify user-defined commands‘ BatchPatch provides and interface for you to add your own commands. Once a command is added in this interface, the command will appear in the BatchPatch menu under ‘Actions > Get information > Execute user-defined commands‘

2. Under ‘Actions > Execute remote process/command‘ there are several options. Remote command 1, 2, 3, 4 can be created and will be stored in the current grid and visible in the row under which they are created. Commands 1 and 2 do not attempt to capture output and will only report exit codes upon execution. Commands 3 and 4 attempt to capture output, so that you can display the output in the grid upon execution. Under the hood the logged-output commands (3/4) have to be executed differently from the standard commands (1/2), and in some cases this difference can cause failure, which is why we separate these completely. If a command fails to execute under 3/4 it might be successful under 1/2.

Additionally under ‘Actions > Execute remote process/command‘ we have ‘Create/modify remote commands‘ and ‘Create modify remote commands (logged output)‘ where you can create commands that won’t be tied to a particular grid and will instead be saved globally for all BatchPatch instances that you launch. Commands created under these interfaces appear hard-coded in the BatchPatch menu under ‘Actions > Execute remote process/command‘ as ‘Execute saved remote commands‘ and ‘Execute saved remote commands (logged output)‘, respectively.

More details on hard-coding custom commands into BatchPatch can be found here: How to Hard-Code Your Own Custom Commands in the BatchPatch Actions Menu

Once a command has been hard-coded into BatchPatch, not only is it available for direct execution on target computers, but now it can also be included in job queues or be executed by the Task Scheduler. You can see in the screenshot below that the Job Queue window shows all of my previously created hard-coded commands, deployments, copy jobs etc. I can add any of them to a job queue for automation.

Additionally, all job queues will appear along with all hard-coded commands, deployments, copy jobs etc in the Task Scheduler so that you can schedule any job queue or command that you have previously created.

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

There are no applicable updates in the filtered collection

By Scott | Published: June 15, 2020

Sometimes we’ll get an email from someone who is confused about the message ‘There are no applicable updates in the filtered collection‘. They’ll note that when they execute ‘Check for available updates‘, BatchPatch finds updates, but when they execute ‘Download and install updates‘, BatchPatch reports There are no applicable updates in the filtered collection. Below I’ll explain why this happens, how to understand what is going on, and how to get past it.

When you perform a search for updates using ‘Check for available updates‘, BatchPatch utilizes the search preferences that you have configured under ‘Tools > Settings > Windows Update‘. You can see in the screenshot below that my search preferences are set to search for software updates (we generally recommend selecting ‘Important‘ and ‘Recommended‘ to emulate the search that the Windows Update Agent performs when searching for updates directly at the Windows Update control panel of a computer without using BatchPatch, but in this case I happened to have my setting on ‘Search for software updates‘ while I took screenshots for this blog posting).

You’ll also notice in the screenshot above that I have all ‘Update Classification Filtering‘ boxes unchecked. This creates a situation where even though BatchPatch finds updates when it searches for them, BatchPatch does not download or install any updates because the ‘Update Classification Filtering‘ checkboxes only apply to download and installation operations, while the ‘Search Preferences’ checkboxes apply to the search. When the ‘Download and install updates’ operation executes, instead of updates downloading and installing, BatchPatch displays There are no applicable updates in the filtered collection.

If we then look at the contents of the ‘Remote Agent Log‘ column we can see the details of exactly what occurred:

Six updates were found, but since all ‘Update Classification Filtering‘ boxes were unchecked in the settings, when BatchPatch applied the filters to the collection of updates that were found in the search, all updates were excluded. If you look at the section between “::Begin filtering collection” and “::End filtering collection” you can see that updates were “skipped” for the reasons shown, such as “Reason: UpdateClassification-Upgrades“, which indicates that the ‘Update Classification Filtering‘ box for “Include ‘Upgrades’” was not checked when the operation was executed.

There are other filters, in addition to the update classification filter, that could be the reason for you to find the filtered collection is empty when you attempt to download or install updates. The two other ways that updates get filtered are by date (see ‘Update Date Filtering‘ section of ‘Tools > Settings > Windows Update‘) and by including or excluding individual updates (see ‘Actions > Windows updates > Filter which available updates are included or excluding when downloading/installing‘). In all cases, when you see ‘There are no applicable updates in the filtered collection’ all you have to do is check the ‘Remote Agent Log’ data (either by viewing it directly in the ‘Remote Agent Log‘ column after a Windows Update action or by using ‘Actions > Windows updates > View BatchPatch.log‘ which will retrieve the BatchPatch.log file from the target computer’s remote working directory. This file will include the log data for every BatchPatch Windows Update action that you have ever launched (unless you have ever deleted the file or directory that contains it)). The log data detail will point you to the particular reason your filtered collection is empty, and then you can adjust your filters, as desired.

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

Windows Offline Update for Multiple Computers

By Scott | Published: June 4, 2020

You can use BatchPatch to apply Windows security updates to numerous computers that do not have internet access. Many organizations will have a high-security network where no computer on that network may access the internet. Further, it’s common to have the network so protected that it cannot even house a WSUS for update delivery. If you don’t have a WSUS and you don’t have internet access, how do you keep computers up to date? Below I’ll explain how you can use BatchPatch to fill the void.

On the one hand when you don’t allow the computers to access the internet, you increase their security by making it impossible to remotely access anything on the network, but on the other hand you make it harder to install updates, which is something you generally would want to do in order to improve security of the computers and close vulnerabilities in the operating systems. This is definitely a balancing act, but if you have a simple, straightforward method for applying updates to all of the offline computers, you’re going to be in much better shape than simply leaving the computers as-is, without ever updating them or with having to manually handle the update process on a periodic basis.

How does BatchPatch enable administrators to download and install security updates on an entire air-gapped / segregated network of computers?

BatchPatch actually provides a handful of different modes and methods for getting updates installed on offline computers. The method that you select will be primarily dependent on how strict the security rules and requirements are for the offline network. For example if the offline network is not completely air-gapped, and if you’re able and allowed to put BatchPatch on a computer that has both internet access as well as access to the computers on the offline network, then you’re going to select a different method than if the network is truly air-gapped or at least truly segregated such that no computer that has internet access can ever have direct access to computers on the network. However, even when you’re dealing with a completely segregated network, there might still be different levels of security required for that network. For example, in some cases you might be able and allowed to remove files from the offline network when needed, whereas in other cases the rules might be so strict that you are never allowed to remove anything from the offline network… or perhaps in some cases you are technically allowed to do such a thing, but the bureaucracy involved when it comes to change management processes is so burdensome that it’s barely ever worth actually trying to remove a file. BatchPatch provides different methods for each different scenario. There is always a balance between security and convenience, and BatchPatch attempts to provide the administrator with as much flexibility as possible to choose the least painful, most convenient method for any given offline network environment.

At the following page we go through all of the different scenarios, with detailed explanations. Each different scenario has a tutorial that explains how to download and install updates on your network, depending on the details and rules of your environment.

Cached Mode And Offline Windows Update

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

Looping, Branching with Goto:Label in the BatchPatch Job Queue

By Scott | Published: May 21, 2020

The April 2020 release of BatchPatch has some new functionality in the job queue that we’re excited about. People have been asking for a while for more flexibility in the job queues, particularly to be able to create loops and have branching etc. We wanted the functionality to be as simple to use as possible while at the same time offering the most power and flexibility, and so we spent a lot of time working through the best way to incorporate these updates to meet those criteria. In the end we decided to use a combination of ‘Goto:Label’ with built-in ‘If/Then’ statements to accomplish that, and we’re happy with the results. Below I’ll give you some ideas of ways that you can use these new job queue entries. We have added the following entries to the ‘Special’ items list in the job queue:

'Insert label:X
'Goto label:X
'If previous action failed/errored (returned non-0), goto label:X
'If previous action was successful (returned 0), goto label:X
'If most recent 'Check for available updates' found 0 updates, goto label:X
'If most recent 'Check for available updates' found any updates, goto label:X
'If 'Get pending reboot status' returns FALSE, goto label:X
'If 'Get pending reboot status' returns TRUE, goto label:X
'If host is offline, goto label:X
'If host is online, goto label:X	
'If specified file exists, goto label:X'
'If specified file does not exist, goto label:X'
'If specified registry key exists, goto label:X'
'If specified registry key does not exist, goto label:X'
'If specified registry value exists, goto label:X'
'If specified registry value does not exist, goto label:X'
'If version of specified file is newer than Y, goto label:X'
'If version of specified file is older than Y, goto label:X'

Simple loop to update and reboot target computers until no more updates are found

1. label:YourCustomNameGoesHere
2. Download and install updates + reboot always
3. Wait 5 minutes
4. Wait for host to be detected online
5. Check for available updates
6. If most recent ‘Check for available updates’ found any updates, goto label:YourCustomNameGoesHere

Notify end users, hourly, to reboot, until the reboot has been completed

1. label:YourCustomNameGoesHere
2. Your custom notification message goes here, such as “Please reboot your computer as soon as possible.”
3. Wait 60 minutes
4. If ‘Get pending reboot status’ returns TRUE, goto label:YourCustomNameGoesHere

Execute a custom deployment only if a certain registry entry does not exist

1. If specified registry value does not exist, goto label:YourCustomNameGoesHere
2. Terminate queue
3. label:YourCustomNameGoesHere
4. Your custom deployment goes here, such as to install a particular piece of software

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

Error 1605: Failed to create remote working directory. HRESULT -2147024829: The network name cannot be found.

By Scott | Published: May 13, 2020

Today I’d like to take a moment to talk about an error that I haven’t addressed specifically in the past but that does crop up sometimes. It can appear in any of the following ways, but each has the same cause/resolution:

Windows Update: Error 1605: Failed to create remote working directory.  Please check permissions on the target computer and verify your working directory path in Tools > Settings. HRESULT -2147024829: The network name cannot be found.
Windows Update: Error 1614: Failed to create remote working directory.  Please check permissions on the target computer and verify your working directory path in Tools > Settings. HRESULT -2147024829: The network name cannot be found.
Deployment: Error: Failed to create remote working directory.  Please check permissions on the target computer and verify your target working directory path in Actions > Deploy > Create/modify deployment: The network name cannot be found.

IMPORTANT: You might see 1605 or 1614 appear with a different HRESULT value and different error text. However, in this particular example we are specifically looking at HRESULT -2147024829: The network name cannot be found. Any other HRESULT value and error text would have a different cause and resolution.

Troubleshooting this issue is pretty straightforward, as there are generally only a couple/few reasons why it could be occurring.

  1. As suggested in the error text itself, the first thing you should do is check the ‘remote working directory‘ and ‘deployment directory‘ values under ‘Tools > Settings > Remote Execution > Remote Working Directory‘ and ‘Actions > Deploy > Create/modify deployment > Target working directory‘, respectively, depending on whether you are encountering the error while executing a remote command or a Windows Update action, or if you are encountering the error while executing a deployment. The default values that we recommend for these two fields are:
    Remote Working Directory: C:\Program Files\BatchPatch
    Deployment Target Working Directory: C:\Program Files\BatchPatch\deployment

    If either of these fields references a drive letter that does not exist on the target computer, the ‘network name cannot be found‘ error will occur. So, for example, make sure you don’t have your remote working directory set to Q:\Program Files\BatchPatch, unless the target computer actually has a Q: drive. If the drive letter itself exists, then BatchPatch will be able to create the directory/folder without issues (unless there is some other problem, such as a permissions issue, but that would manifest with a different error message).

  2. If you have verified that the target working directories are set to a valid drive letter and path, then the next thing to look at it DNS. Instead of entering the host name into BatchPatch, try the IP address. If the IP address works but the host name does not work, then you know you have some kind of name resolution problem on that system.

  3. If neither the host name or the IP address works without throwing the ‘network name cannot be found‘ error, then you’re probably looking at a firewall issue. Check the firewall on the target computer because it’s probably the culprit.

  4. If after all of the above steps you are still getting ‘The network name cannot be found‘ you could have an issue with your network connection. Are you able to ping the target computer either by name or by IP address? Are you able to browse directly to the target computer shares in explorer? You can try clicking on ‘start > run‘ and then typing ‘\\targetComputer\C$‘ without the quotes. Substitute the actual target computer’s name in place of targetComputer, and substitute the actual drive letter that your target working directory values are configured to use, if they are not configured to use the C: drive.

Hopefully this helps you get to the bottom of the issue and find the root cause.

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

BatchPatch – New Version Released in April 2020

By Scott | Published: April 30, 2020

At the end of last week we released a new version of BatchPatch. Today I’d like to go over some of the new features available, some of which we think are going to be popular with our users. For a complete list of of changes, click on ‘Help > Check for updates > View changelog‘ inside the software.

Deploying Windows 10 Feature Upgrades with the Standard BatchPatch Windows Update Actions

For those of you who have used this BatchPatch deployment method to apply Windows 10 feature updates, note that you can now use the standard/normal Windows update actions in BatchPatch to install these feature updates. If you perform a ‘Check for available updates‘ and have a Windows 10 feature update showing in the list of available updates, now instead of using the deployment method, you may simply tick the ‘Include “Upgrades”‘ classification filter in the BatchPatch settings form. Then when you use the standard BatchPatch Windows update actions either to “Download and install updates” or “Install downloaded updates” (if the feature update has already been downloaded), that feature update will be downloaded/installed in the same way that other updates are. Note, this capability only exists in BatchPatch’s default operating mode. It will not work in BatchPatch ‘cached mode.’ If you are running exclusively in ‘cached mode’ then you’ll still need to use the deployment method described at the link above.

Job Queue Looping and Branching with Labels and Goto

For a while now people have been requesting even more flexibility with the job queue. In particular, users have been asking about looping and branching, so that they can effectively have a higher degree of control over their queues. We didn’t want to release such functionality until/unless we could make sure it would fit in with BatchPatch’s existing functionality in such a way that would enhance it without making any features more difficult to utilize.

In the BatchPatch job queue you can now set labels and create ‘goto’ commands that enable simple looping and branching in a very easy-to-use way. For example, one of the things that users like to do is repeatedly check for available updates, install any that are presented, then reboot and repeat the process until there are no more available updates. Yes, it would be great if you could simply install updates and reboot one time and be done with it, but all patching administrators know that sometimes Windows makes things a bit more tricky by not presenting certain updates until other updates have been installed first and the computer has been rebooted. So, sometimes it’s helpful to be able to repeat the download/install/reboot process a few times in a row. In BatchPatch you could always accomplish this, but it required you to manually set the number of iterations. However, now with the new label/goto functionality, you can create a single loop to perform the desired steps. Here is one possible way to do it (note, there are definitely other ways to structure your job queue to accomplish something similar, so don’t feel locked into this particular example)

Loop to download and install updates plus reboot until no more updates are found:
1. label:YourCustomNameGoesHere
2. Download and install updates + reboot always
3. Wait 5 minutes
4. Wait for host to be detected online
5. Check for available updates
6. If most recent ‘Check for available updates’ found any updates, goto label:YourCustomNameGoesHere

You’re also now able to goto a particular label based on whether or not the previous action failed or succeeded, the target computer is in a ‘pending reboot’ state, the target computer is offline or online, a particular file or registry key/value exists, a particular file version is newer or older than some number etc. Additionally, inside the job queue you can now set the row color or disable the row.

Other / Miscellaneous

The new version contains various other improvements and bug fixes. If you encounter any issues or have a suggestion for a future build, you can reach us here.

Posted in Blog, General | Tagged | Comments closed

Using the Job Queue to Clear ‘All Messages’ Before Executing a New Action

By Scott | Published: April 23, 2020

Some of our users launch a fresh instance of BatchPatch each time they use it, and they start with a brand new grid (or a set of grids) each time. They load their hosts and then begin patching. However, some of our users prefer to re-use the same grid file (.bps) over and over and over, so that each time they start patching, it’s really more like a continuation of the previous week or month. One downside to this approach is that the log data, particular in the ‘All Messages’ column, can become overwhelmingly large as it grows with each action that is executed. This is especially an issue for users who are automating virtually everything in BatchPatch. They often don’t even really want to interact with the application except to create new jobs, so at some point it makes sense to clear out the excess data that is no longer needed, but in such a way that requires no extra work from the administrator. To be clear, it’s not a lot of “work” by any means because it only takes a couple/few clicks, but for many sysadmins everything is all about automation. Today I’ll show you how to setup your scheduled tasks to execute a job queue, where the job queue’s first step is to clear column log data. The subsequent steps in the job queue can be whatever you need or want, but presumably they will involve actually patching the target computers or running scripts etc.

Create a Custom Command for Clearing Data in Desired Columns

  1. First let’s setup the selection list for which columns will be emptied. Click on ‘Actions > Clear column contents > Create/modify selections‘. You could choose to clear all columns (except for the Hosts column), or you could just selectively clear a couple/few columns. For this example let’s just setup an entry to clear only the ‘All Messages’ column. You can see in the screenshot below that I have selected the ‘All Messages’ column, and I have saved the entry by using the double-right-arrow button.

  2. With the entry you created above now saved, if you flip over to the Job Queue window (Actions > Job Queue > Create/modify job queue), you can see in the lower-left grid, titled ‘Saved User-Defined Commands and Deployments‘, that the entry you created a moment ago now appears.

  3. You can add that entry as the first step in a job queue. This way when the job queue is executed, the first thing it will do is clear out the ‘All Messages’ column. Then you can have it do whatever else you need or want, such as initiating Windows Update on target hosts. Then you can save the Job Queue by using the double-right arrow.

  4. With your job queue now created, you can setup a scheduled task for any target host that will execute the job queue. Click on ‘Actions > Task Scheduler > Create / modify scheduled task‘. In the Task Scheduler window, from the task drop-down menu, select the title of the Job Queue that you just created. Set a run date and time, and then click OK. Then make sure the scheduler is enabled by clicking the small red clock/timer icon in the upper right corner of the main BatchPatch window so that it turns from red to green.

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

Preventing Particular Updates from Installing on Target Computers

By Scott | Published: April 10, 2020

Under normal circumstances BatchPatch is used to initiate the download and/or installation of updates on a group of target computers. So long as you have setup your environment to work with BatchPatch as far as permissions and firewall settings are concerned, then BatchPatch can, if desired, be used without altering your existing Windows Update settings. That is to say that if you have your target computers configured to automatically install updates at a particular time each week, if you were to use BatchPatch at some other time in the week, BatchPatch would download/install updates at that time, assuming there were available updates to download/install at that time. However, most of the time when administrators are using BatchPatch, they want to use BatchPatch exclusively for the Windows update process, so they definitely do not want their computers to be automatically installing updates at other times. They essentially want to only ever have target computers download/install updates when they have initiated the process from within the BatchPatch console (either on-demand or via BatchPatch scheduled task). In this case, target computers must be configured to not automatically download/install updates on their own schedules.

Now, in BatchPatch it’s easy to choose to install only specific/particular updates, or to install certain categories of updates (such as ‘Security Updates’ or ‘Critical Updates’ etc), but how does one make sure that the target computers do not automatically install updates on their own at other times? And how does the administrator ensure that only the updates that he/she chooses to install via BatchPatch are the only updates that are installed on the target computers? There are a few things to consider. Let’s review them below.

First, if you’re going to be using BatchPatch as your primary method for initiating the update process on target computers, then it makes sense to start by telling target computers to *not* automatically install updates on their own schedules. There is a group policy object that you can enable on target computers that will instruct those computers to *not* download and *not* install updates on their own schedules. If you don’t know what group policy is, it’s essentially a mechanism that is built-in to Windows for controlling all sorts of settings for how Windows behaves in a domain environment. If your computers are not domain members but instead are running standalone or in a workgroup, you’ll still have access to all those same group policy settings, only instead of being able to control them from a single/central location in group policy (on the domain controller) you would instead control them individually on each target computer using the local policy editor. Local policy and group policy can be viewed as essentially the same things, except that group policy settings will control a group of computers, and is set on the domain controller for those member computers, whereas local policy settings are the same settings simply controlled and set on an individual per-machine basis.

The behavior of the following setting varies slightly depending on which operating system is running, but no matter which OS you are using you would want to open the group policy editor (or the local policy editor) and find the setting for Configure Automatic Updates which is available under Computer Configuration > Administrative Templates > Windows Components > Windows Update. Setting the value to either 2 Notify for download and notify for install or 3 Auto download and notify for install will prevent updates from installing on their own. This way you can instead initiate the installation process from the central BatchPatch console. If you want BatchPatch to perform both the download and installation, then set the value to 2. If you want the computers to auto-download the updates on their own but then use BatchPatch for the installation portion of the process, then set the value to 3. In either case, once this is set, the computer will no longer install updates on its own automatic schedule.

OK, so if you configure your target computers, via group policy or local policy, to *not* ever automatically install updates on their own, then effectively speaking if you only use BatchPatch to initiate the installation of desired/selected updates, you’re going to end up with only the updates that you want installed on those target computers. In a certain sense I think it’s fair to say that you have then also prevented the particular updates from installing that you never opted to install. However, in this case if you had, for example, a list of 100 available updates, and you chose to install 90 of those 100 updates, then you would still be left with 10 available updates on the target computers. The act of *not* installing them but still leaving them there in the “available updates” queue is not identical, conceptually, to actually preventing them somehow from ever being installed. So… what if you want to actually prevent them from ever installing? To be clear, if you set things up in the way that I described above, those updates would never install unless you chose to install them through BatchPatch, but it’s conceivable that you could forget that you didn’t want to install them, and then maybe at one point you would inadvertently choose to install all of the available updates on target computers instead of only a limited subset of the available updates, thereby causing those 10 leftover updates to get installed. Maybe you would want to do everything in your power to prevent such a situation from being able to occur in the first place… What are your options for actually *preventing* those 10 updates from ever being installed? You have two basic options…

Hiding Updates on Target Computers

If you’re using BatchPatch standalone without any WSUS server involved, then you can use the ‘Hide Updates‘ feature in BatchPatch. What this action enables you to do is tell a target computer (or a group of target computers) to take an update (or group of updates) that is currently showing as available for installation, and to then effectively “hide” it so that it no longer even appears as available for the computer. In the example that I gave above with 100 updates, if you install 90 of them, you could then hide the remaining 10. Once hidden, if you were to then initiate a “check for available updates” or “download updates” or “install updates” action, the hidden updates would be excluded altogether, as if they never existed. This option is simple and quick to use, but it does come with one drawback, unfortunately. Let’s say that on January 1, 2020 Microsoft published update KB1234567. Then in the middle of January or at some point after that you decided to hide the update on the target computers so that it no longer appeared available. The problem is that Microsoft is capable of re-publishing that same update ID KB1234567 at a later date. If they do that, then KB1234567 will all of a sudden show up again in the list of available updates. However, note that just because Microsoft publishes the same update KB ID again in the future does not necessarily mean that the update is identical to what it was when you first hid it. In fact, it’s probably the case the update is definitely not the same as it was. So in a sense you could view it as Microsoft updating the update, so that the update itself functions better or behaves a bit differently or what have you, and in that case even though the update is being published under the same KB ID, in a certain sense it really wouldn’t be much different from Microsoft publishing the same update or ever-so-slightly different update under a different KB ID. The truth is that at any time Microsoft publishes a new update (or re-publishes and old update) the administrator should be evaluating from scratch if that update is one that he/she wants to install. So realistically the fact that Microsoft might sometimes re-publish a previously hidden update, such that the hidden update becomes unhidden and moved back to a status of “available” really shouldn’t be a major drawback for the administrator. It probably makes more sense for the administrator to simply view it as he/she would view a new update, and then simply decide if it is an update that he/she wants to install. If not, then it can just be hidden again.

Using a WSUS Server to Control Which Updates are Presented to Target Computers

The other option you have is to use WSUS to control which updates are ever even presented as “available” on target computers. In this case instead of using BatchPatch as a standalone tool, you would instead use BatchPatch in conjunction with WSUS. I should note that WSUS is free and simple to install and use, so it’s certainly a good option for many administrators. To see how to configure BatchPatch to work in conjunction with WSUS, check out this link: BatchPatch Integration with WSUS and Group Policy.

Once you have configured your target computers to work with the WSUS and BatchPatch, then instead of relying solely on BatchPatch to control which updates you install on target computers, you get an additional layer of control. Inside of WSUS you can configure it so that no updates are ever approved for distribution until you have gone into the console and selected them for approval. So, each month when Microsoft releases new updates, after your WSUS synchronizes with Microsoft’s public servers, you would then go to your WSUS and choose which of the available updates you would want to approve for distribution to your target computers. The target computers are configured to retrieve their updates from your WSUS instead of directly from Microsoft (as described previously), and this way the target computers only ever even know about the updates that you have first selected for approval on the WSUS. If you want to prevent a particular update from being able to be installed on the target computers, don’t ever approve it in the WSUS. In fact, you can actually use the “decline” option in WSUS so that not only is it not approved but actually it is officially declined for installation at that point. Target computers that are pointed at the WSUS (via Group Policy, as explained in the link above), will only ever “see” updates that have been approved. When you then use BatchPatch to download/install updates on those target computers, BatchPatch will only ever be able to install those approved updates… UNLESS you were to configure BatchPatch to bypass your WSUS and pull updates directly from Windows Update or Microsoft Update. If you wanted to do that, in BatchPatch you’d go to ‘Tools > Settings > Windows Update > Server Selection’, and then you would change the setting from ‘Default/managed’ to ‘Windows Update’ or ‘Microsoft Update’ instead.

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

Incorporating Custom Scripts in BatchPatch – Get Local Administrators Group Membership

By Scott | Published: March 19, 2020

Let’s have a look at how to incorporate a custom script into BatchPatch. In this case we’ll use BatchPatch to run a script that will retrieve the list of users who are members of the local administrators group on each target computer, and then optionally write it all to a text file.

If you would instead like to modify group members of a local group on target computers, or if you want a quick way to retrieve group membership on target computers without using a custom script and without being able to write the results to a file, take a look at this posting: Using BatchPatch to Modify Local Group Membership on Multiple Remote Computers

I’m not going to get into the details of the actual script that we’re going to use for this tutorial since this posting is not intended to be a scripting lesson but rather is meant to demonstrate one possible way to incorporate a custom script into BatchPatch. There are also other custom scripting examples on our website, if you’re interested, that you can find by searching ‘script’ in the search box on the upper right area of this page.

Here is the script:

Dim strFilePath, strComputer
strComputer = WScript.Arguments(0)
strFilepath = "C:\Temp\results.txt"
 
Sub GetAdministrators(strComputer)
    Dim objWMIService, strQuery, colItems, Path, strMembers
    Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
    strQuery = "select * from Win32_GroupUser where GroupComponent = " & chr(34) & "Win32_Group.Domain='" & strComputer & "',Name='Administrators'" & Chr(34)
    Set ColItems = objWMIService.ExecQuery(strQuery)
    strMembers = ""
    For Each Path In ColItems
        Dim strMemberName, NamesArray, strDomainName, DomainNameArray
        NamesArray = Split(Path.PartComponent,",")
        strMemberName = Replace(Replace(NamesArray(1),Chr(34),""),"Name=","")
        DomainNameArray = Split(NamesArray(0),"=")
        strDomainName = Replace(DomainNameArray(1),Chr(34),"")
        If strDomainName <> strComputer Then
            strMemberName = strDomainName & "\" & strMemberName
        End If
	WScript.Echo strMemberName
        Set oFSO = CreateObject("Scripting.FileSystemObject")	
	If oFSO.FileExists(strFilepath) Then
	    oFSO.OpenTextFile(strFilepath,8).WriteLine(strComputer & ": " & strMemberName)
	Else 
	    oFSO.CreateTextFile(strFilepath).WriteLine(strComputer & ": " & strMemberName)
	End If
    Next
End Sub
 
GetAdministrators strComputer
  1. The first order of business is to copy the script text into notepad. Modify the filepath in the third line of the script to point to whatever location you want to use to save the results. Then save the script to somewhere on your computer as GetLocalAdmins.vbs

  2. If you only want to get the group membership and don’t care to log the results to a file, then you may delete or comment out the following section. In that case BatchPatch will just get the group membership so that you can view the result for each target computer inside the BatchPatch grid. However, if you really just want to get group membership without logging to a file, then you can use a simpler method that doesn’t involve incorporating a custom script. See the link provided near the top of this posting for details on that method. That said, if you are going to be using the script method that I’m demonstrating in this tutorial but you don’t want to log the results to a text file, then you should delete this section from the script:

    '
'Set oFSO = CreateObject("Scripting.FileSystemObject")	
'If oFSO.FileExists(strFilepath) Then
'    oFSO.OpenTextFile(strFilepath,8).WriteLine(strComputer & ": " & strMemberName)
'Else 
'    oFSO.CreateTextFile(strFilepath).WriteLine(strComputer & ": " & strMemberName)
'End If
'

  3. If you want to run this script one-off to get group membership on a target, just copy and paste the following syntax, modifying the path as needed to match wherever you have the script stored, into a BatchPatch local command under ‘Actions > Execute local process/command > Create/modify local commands‘. Then after you have clicked OK to save the command, you’ll see that it appears in the menu. See screnshots below for reference: 
    cscript "C:\SomeFolder\GetLocalAdmins.vbs" $computer

    IMPORTANT:
    There is a key element that we need to address. If you are going to use the script as-is and have it write the results from all target computers to a single file, you need to pay attention to thread synchronization issues. The specific problem here is that if you execute the script on numerous targets simultaneously, BatchPatch will launch a separate thread for each target, and each of those threads will try to write to the same text file at the same time. This is a problem that could result either in missing data or an error being thrown, so we need to set things up so that each row runs one at a time, sequentially, instead of having all rows run at the same time, simultaneously. This way only one BatchPatch thread at any given time will be accessing the text file and writing results to it. Note, if you have removed the section of code from the script that writes the results to a file, then you don’t need to worry about this issue at all.

  4. To resolve the threading issue we’re going to use the Basic Multi-Row Queue Sequence. This feature will enable us to force each BatchPatch row to execute sequentially, one at a time, until all rows have executed. First, select all rows in the grid and then click on ‘Actions > Job queue > Create/modify job queue‘

  5. In the Job Queue window, find the Local command that you created earlier in the lower left grid for ‘Saved User-Defined Commands and Deployments‘. The ‘Type’ will be shown as ‘Local’ with whatever title you gave to your command. Double-click it to add it as the only step in your job queue. Then click ‘Apply queue to row(s) without executing‘. See the following screenshots for reference:

  6. Now we’re ready to execute. With all rows selected, click on ‘Actions > Job Queue > Execute basic multi-row queue sequence‘ What this will do is instruct BatchPatch to launch the job queue in each row, one at a time, in the order that the rows were selected. As soon as one row finishes running the script and writing the results to the text file, the next row will commence, and so on until all rows have executed the script and written to the file. The results will also be displayed for each row in the ‘Local Command Output Log’ column.
Posted in Blog, General, Tutorials | Tagged , , , , | Comments closed

Remotely Uninstalling Windows Updates

By Scott | Published: March 10, 2020

Let’s face it… even though we all wish Microsoft’s quality assurance and testing was better, it really seems to have gotten worse in recent years… significantly worse. There are a few primary ways that systems administrators can reduce the likelihood of encountering problems after installing Windows updates each month. First, have a testing lab setup with machines that largely resemble production computers, so that updates can be deployed into the testing environment before they are deployed to the production environment. If the testing environment’s computers are actually prepared with similar applications and services as production computers, then there is a good chance that the testing environment will reveal any major issues with Windows updates *before* those updates are ever deployed to production machines. However, it’s often difficult or even impossible to accurately configure testing servers to resemble the production servers closely enough to guarantee that update issues will be discovered in testing before they are deployed to production, so this isn’t the only step that should be taken. We also recommend designating certain production machines to be the first to receive updates, so that if any problems are identified, they can be addressed before deploying the same updates to an entire production network. Additionally, we think it’s important in most cases to *not* install updates within the first few days of their release. We believe that most organizations should be waiting at least a week after Patch Tuesday before they deploy new updates to production systems. This gives the rest of the world a chance to test the updates and report any problems, so that you can then decide if you need to postpone a maintenance window until Microsoft re-issues a fixed version of the update, or to perhaps do additional testing in your environment to confirm whether or not you might be affected by any problems that have been reported with the updates. However, while we do think that waiting a week or so is a great idea for most organizations, you shouldn’t wait too long, especially in cases where the updates to be installed are fixing critical issues that are actively being exploited in the wild. A balance will need to be struck, depending on the details, setup, and requirements of each particular environment, so that updates can be installed soon enough to protect computers while also waiting long enough to minimize any potential problems that might be encountered by installing a problematic update.

What happens if you install an update that is causing problems on your computers?

It’s going to depend on the nature of the problem, of course, because if the update is so destructive that computers won’t even boot, then you’re obviously going to have to manually address each affected computer in order to resolve the problems. However, in most cases when a problematic update has been deployed, simply uninstalling it is sufficient to make the problem go away until a fixed version of the update is published by Microsoft. If you find yourself in a situation where you need to remove a Windows update that you previously installed on numerous computers, you can use BatchPatch to execute the removal/uninstallation process.

Using BatchPatch to Execute the Update Removal/Uninstallation Command

First, note that there are two different commands built-in to BatchPatch for removing Windows updates. You’ll need to execute the command that corresponds to the particular operating system that you will be removing the update from. In BatchPatch you can see the two different menu items in the screenshot below:

  1. Highlight the rows in the grid for the computers that have the update installed that you want or need to remove/uninstall.

  2. Click on the relevant menu item, depending on which OS is installed on your target computers… either ‘Actions > Windows updates > Uninstall individual update (requires KB ID) – Windows 7/2008/2012‘ or ‘Actions > Windows updates > Uninstall individual update (requires KB ID) – Windows 10/2016/2019‘

  3. Enter the KB ID of the update that you want to remove, and tick or untick the ‘/norestart’ option, depending on whether you want the command to prevent the update process from rebooting the computer or not. If the computer needs to be rebooted in order to complete the update removal, and if you tick the ‘/norestart’ option, you’ll need to execute the reboot separately in order for the update removal process to be completed. We generally prefer to check ‘/norestart’ and then separately initiate the reboot in BatchPatch. In this way BatchPatch can monitor the reboot through its normal process. If the removal command itself performs the reboot (this happens if /norestart is un-ticked and the update removal process requires a reboot), BatchPatch won’t monitor it. Note, the command to execute is different, depending on which menu item you selected in the previous step. The screenshots below show the difference:

    wusa.exe /uninstall /KB:1234567 /quiet /norestart


    cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "$SearchUpdates = dism /online /get-packages | findstr 'Package_for'; $updates = $SearchUpdates.replace('Package Identity : ', '') | findstr 'KB1234567'; DISM.exe /Online /Remove-Package /PackageName:$updates /quiet /norestart"

  4. Lastly, click OK to execute the process.
Posted in Blog, General, Tutorials | Tagged , | Comments closed