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.