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

Creating Custom Email Notifications for the Job Queue

By Scott | Published: August 10, 2022

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

Use Actions > Email notification > Create/modify email notifications

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

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

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

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

By Scott | Published: July 26, 2022

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

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

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

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

  5. Finally, you’ll need to select the PowerShell query to execute.
    Get-AdmPwdPassword requires the Local Administrator Password Solution (LAPS) PowerShell module, AdmPwd.PS, to be installed on the BatchPatch computer.
    Get-ADComputer requires the Remote Server Administration Tools (RSAT) Active Directory module to be installed on the BatchPatch computer.

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

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

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

New Version of BatchPatch Released July 2022

By Scott | Published: July 6, 2022

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

  1. Custom email notifications that can be saved and added to job queues or scheduled tasks. Now you can have different email notification settings for different purposes. So, for example, if you need to have one email notification that goes to one group of users at the beginning of a maintenance period, while a different email notification goes to a different group of users in the event of a problem or error, now you can do that. You can create as many different email notifications as you want or need, and then you can insert whichever ones you want into your job queues and scheduled tasks as desired. See ‘Actions > Email notifications > Create/modify email notifications

  2. Local Administrator Password Solution (LAPS) integration is now available under Actions > Specify alternate logon credentials > Get LAPS password from Active Directory. If you are using LAPS, now you’ll be able to highlight a group of computers in your BatchPatch grid in order to query Active Directory for each computer’s administrator password all at one time. The username/password will then be auto-filled into the ‘Alternate Credentials’ column in your BatchPatch grid for each selected computer.

  3. A new Windows Update search setting for updates where ‘DeploymentAction = Installation’ is now available in the BatchPatch settings. Up until recently if you wanted to emulate the Windows automatic updates search for updates so that BatchPatch would display the same group of available updates as the Windows Update automatic updates control panel interface in Windows, you would have done that by selecting ‘Important’ and ‘Recommended’ in BatchPatch. However, recently Microsoft has made a change to which updates are displayed in the Windows Update control panel interface, and we have accordingly added a new search setting in BatchPatch to emulate how Windows is doing things now in the newer versions of Windows. If you notice that BatchPatch ‘Check for available updates’ is no longer displaying the exact same search results that appear in the Windows Update control panel on the target computer, try the new search setting under Tools > Settings > Windows Update > Search Preferences > Search for updates where ‘DeploymentAction = Installation’
Posted in Blog, General | Tagged , , , | Comments closed

‘Access is denied’ in BatchPatch After Installing the June 2022 Cumulative Windows Update

By Scott | Published: June 17, 2022

The problem: After installing the June 2022 cumulative Windows Update (2022-06 Cumulative Update for Windows) OR any future cumulative update that is released from this point forward, if the previous patch level of the system was some date prior to June 2022, and the newly installed patch level is June 2022 or newer, you might experience BatchPatch all of a sudden returning an error for no apparent reason: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

( For general ‘Access is denied’ issues that aren’t specific to the June 2022 cumulative update, please see https://batchpatch.com/troubleshooting-common-errors-in-batchpatch )

Why this is happening: Toward the end of 2021 (the specific date varies depending on the operating system – see below for details) Microsoft released an update that added security hardening to the Distributed Component Object Model (DCOM) remote protocol in Windows to address the security vulnerability CVE-2021-2614. The hardening was available for administrators to enable, but it was not enabled by default… until June 2022 when Microsoft flipped the switch and enabled it for everyone.

The specific dates of release are as follows:
Windows Server 2022 – September 27, 2021
Windows 10, version 2004, Windows 10, version 20H2, Windows 10, version 21H1 – September 1, 2021
Windows 10, version 1909 – August 26, 2021
Windows Server 2019, Windows 10, version 1809 – August 26, 2021
Windows Server 2016, Windows 10, version 1607 – September 14, 2021
Windows Server 2012 R2 and Windows 8.1 – October 12, 2021

Important reading: In the following posting, Microsoft explains the detail of KB5004442, which was released in June 2022. When the Aug/Sept/Oct 2021 update (date depends on OS, as noted above) is installed it makes available a new registry DWORD value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\RequireIntegrityActivationAuthenticationLevel, which when created and set to value data 1 will enable DCOM security hardening configuration that enables the administrator to test and see what, if anything, it breaks in their environment. In the June 2022 KB5004442 update, the DCOM security hardening configuration was then enabled by default, such that if you did not previously set the aforementioned registry value to 1, Windows would now begin behaving the same as if the value had been set to 1, which could cause some things to break. And now in order to disable the DCOM hardening changes you would have to create and set the value data to 0. Furthermore they note that in March 2023 the DCOM hardening changes will become permanent with no registry value available anymore to disable the configuration.

KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)

Temporary workaround: Use the registry value described in the link above (set to value data 0) to disable the DCOM hardening changes temporarily until March 2023. In March 2023 after installing the cumulative update for that month it will be permanently enabled with no further ability to be disabled anymore.

Permanent resolution: BatchPatch will only break and start producing the ‘Access is Denied’ errors described at the top of this posting in the case where the BatchPatch computer is running a Windows operating system at a patch version that is *older* than Nov 2021 AND when at the same time the target computers are running a Windows operating system at a patch version of June 2022 or newer (or if the aforementioned registry value data is intentionally set to 1 by the administrator, then the problem will manifest as soon as the target computer has the Aug/Sept/Oct 2021 update installed).

So, if you began to experience this problem after installing the June 2022 or newer cumulative update on target computers, the simplest resolution is to make sure your BatchPatch computer is updated to the latest Windows cumulative update (or at a bare minimum to a patch level of Aug/Sept/Oct 2021 or newer – The specific date is dependent on the particular version of Windows that you are running. Please refer to the OS version list above as well as the aforementioned link for the specific date for your particular version of Windows).

( For general ‘Access is denied’ issues that aren’t specific to the June 2022 cumulative update, please see Troubleshooting Common Errors in BatchPatch )

Posted in Blog, General | Tagged | Comments closed

Remotely Deploying Monthly Windows Updates to Multiple Computers

By Scott | Published: June 3, 2022

BatchPatch can do quite a few things, but at the core of the software is the functionality for managing Windows Updates on numerous computers without having to install any permanent remote agents, and with only minimal setup and configuration. In many environments BatchPatch will just work right out of the box, without any configuration. In other environments, minor initial setup/configuration will be required.

Once you have BatchPatch setup in your environment, it’s extremely simple to put it to work. Let’s say you want to start the Windows Update process on 100 target computers all at the same time so that you can download and install any applicable updates to those computers, then reboot the computers and monitor them while they go offline and come back online to make sure everything completes successfully… Here’s all you need to do:

  1. Add your computers to a BatchPatch grid by manually typing them in, importing a text file list (or just copy/paste it), or by adding computers directly from your Active Directory groups and OUs. Choose the option that you desire from the Grid menu. I’ve selected to just add mine manually for now. I’ve added just 9 computers, but you can add as many as you want.


  2. Once the grid contains your computers, to perform any action you just need to select/highlight the desired target computers, and then from the Actions menu pick the action that you want to execute. For the sake of this example we are going to use ‘Actions > Windows Updates > Download and install updates + reboot if required‘

That’s pretty much all there is to it. You can sit back and watch your computers through the entire process. The settings that control which types of updates are searched for, downloaded, and installed, are located under ‘Tools > Settings > Windows Update‘.

What else can BatchPatch be used for? Well, in general the most important thing to know is that whichever actions you desire to execute on a single computer can be executed just as easily across numerous computers. You can…

  • Deploy third-party software
  • Run scripts and commands
  • Retrieve inventory information
  • Schedule tasks (pretty much anything that you execute manually in BatchPatch can also be scheduled to run at a desired time)
  • Execute a multi-step job queue that includes numerous individual commands to be executed sequentially on each target system
  • Execute an advanced multi-host sequence where you not only execute a multi-step job queue on each target host, but you link the target hosts together in such a way that enables you to perform actions on certain computers before or after other computers. If you have machines that are dependent on one another, this is a great way to update them all with a single click, while still ensuring that they don’t all go offline at the same time
  • Deploy updates to offline computers

The list above only represents a portion of what BatchPatch can do. We have numerous tutorials posted to help you get going. If you think that BatchPatch should be able to do X, but you aren’t sure how to do it, search the tutorials because that functionality probably already exists. If you can’t find something or if you think it’s not available, feel free to ask us a question or submit a feature request.

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

Get the ‘Location’ Property of a Computer Object in Active Directory

By Scott | Published: May 19, 2022

Recently someone asked us how he could import the ‘Location’ property value on computer objects from Active Directory for a group of computers in a BatchPatch grid.

BatchPatch enables you to run a script and view the output of the script, which is how we’ll accomplish this task. And while there is more than one way to write a script to retrieve the location value of computers in Active Directory, the simplest method is to use the Get-ADComputer PowerShell cmdlet that’s included with the Active Directory PowerShell module in the Remote Server Administration Tools (RSAT) for Windows, so that’s exactly what we’re going to do here.

  1. On the BatchPatch computer you’ll need to make sure you have installed the Active Directory PowerShell module so that we can take advantage of the Get-ADComputer cmdlet. Microsoft has installation instructions here.

  2. Test the Get-ADComputer cmdlet in a PowerShell prompt to ensure that you’ve installed the module successfully. I have a computer called WIN10_TEMP_TEST, so I’ll run the following command to get its Location value: 
    Get-ADComputer WIN10_TEMP_TEST -Properties location | select -ExpandProperty location

    You can see in the screenshot below that it worked.

  3. Now that we have a working command, we can essentially just insert that into BatchPatch so that we can use it to query for the location value of numerous computers simultaneously. In BatchPatch we’ll create a Local Command for this purpose. When you execute a Local Command for a given row (or group of rows) in your BatchPatch grid, the command will execute on the BatchPatch computer itself (whereas a Remote Command would execute on the target computer(s)). To create a Local Command in BatchPatch click on ‘Actions > Execute local process/command > Create/modify local commands‘

    The command syntax that we’re going to use in BatchPatch is:

    powershell.exe Get-ADComputer $computer -Properties location | select -ExpandProperty location

    However, note that depending on your OS and PowerShell version, if you have problems with the command above, try this instead:

    powershell.exe -ExecutionPolicy Bypass -command "Get-ADComputer $computer -Properties location | select -ExpandProperty location"

  4. Now that we’ve added the command, it’s simple to run it for the selected hosts in the grid. Just select the desired hosts, and click on ‘Actions > Execute local process/command > Execute saved local commands > Get location‘

    When the command is executed, the $computer variable in the command is replaced by the actual host name for the corresponding row. This way you can select a large number of rows to obtain this information for each row all at the same time. I only have two computers in my lab at the moment, but you can see that I was successfully able to obtain the location info for them:
Posted in Blog, General, Tutorials | Tagged , | Comments closed

Is it Okay to Install and Run BatchPatch on a WSUS Server?

By Scott | Published: April 27, 2022

First, let me start by saying that we have many customers who run BatchPatch on the same computer where they have the WSUS role installed (Windows Server Update Services). There is nothing inherently wrong about doing this. In many situations, it really isn’t a big deal if BatchPatch and WSUS are running on the same server. That said, it’s not what we prefer or recommend, especially as your number of target computers increases, and especially in cases where it’s important for you to be targeting many computers simultaneously. Here’s the deal…

Neither BatchPatch nor WSUS require a lot of computing/processing power to run. However, both applications can end up with many simultaneous remote connections processing at a given time, and BatchPatch can require a lot of processes and threads to be executed simultaneously. Considering that many administrators use BatchPatch in such a way that requires it to execute actions on a very large number of target computers at the same time, and considering that many of those actions might require the target computers to query and/or retrieve updates from a WSUS, we think it’s a good idea to separate BatchPatch and WSUS to produce the least potential for bottlenecks, especially considering that during a critical maintenance window administrators need everything to go as smoothly as possible.

Imagine for a moment that you have 100 target computers in your BatchPatch grid, and you initiate ‘Download and install updates’ on all 100 computers at the same time. BatchPatch now has to spin up 100+ new processes and 100+ threads, as well as at least one connection (sometimes more) to each target computer. If each target computer now begins to download updates from the WSUS, each target computer will then establish its own separate connection to the WSUS server. If the WSUS server is the same computer as the BatchPatch server, all of a sudden we have a quite lot of outbound and inbound communication taking place to many different target computers because BatchPatch is creating and maintaining many processes and threads that establish remote connections to target computers while those target computers then establish their own remote connections to the WSUS, and then WSUS then has to handle processing those requests and maintaining the connections. In many cases this won’t create any type of bottleneck or lag/delay, but in environments where you know you are going to be targeting a lot of computers at one time in BatchPatch and where you want your maintenance operation to complete as quickly as possible with as few hiccups as possible, then we think it’s a good idea to run BatchPatch on a computer that isn’t performing any other roles at the time that BatchPatch is being utilized. The goal here would be to simply minimize the amount of simultaneous connections/downloads/processes/threads on the BatchPatch computer in order to decrease the likelihood of any hiccups or bottlenecks during a critical maintenance window. You pretty much instantly halve the number of simultaneous connections required to be kept open simply by running BatchPatch on a computer that is NOT the WSUS server. And by the way, BatchPatch doesn’t even necessarily have to run on a server class machine. It can operate effectively from a standard workstation too, so that’s a consideration to keep in mind.

To reiterate once again, there is nothing inherently wrong with running BatchPatch on the WSUS server. In many cases this won’t be an issue or create any problems, and we definitely have plenty of customers who do this. However, for environments where you need or want to minimize the likelihood for any difficulties during a critical patching maintenance, and in environments where there will be a lot of target computers operated on simultaneously by BatchPatch, we would suggest that you put BatchPatch on a computer that isn’t performing any other tasks/roles at the time of the patching maintenance. At the very least we recommend doing some test runs to get an idea of how well things are running in your particular environment. If you discover that all is running smoothly, then you probably don’t need to make any changes.

Posted in Blog, General | Tagged | Comments closed

Modifying the Scope of Windows Firewall Rules to Allow Connections Only From Selected IP Addresses

By Scott | Published: March 25, 2022

When configuring BatchPatch to work in your environment, you might have to modify your Windows Firewall rules on target computers to enable BatchPatch to work properly. As explained in this posting, BatchPatch will require inbound allowances on all target computer firewalls for File and Printer Sharing and Windows Management Instrumentation in order for BatchPatch to be able to connect to and execute actions on target computers.

In many or perhaps most network environments these allowances will already have been granted long ago because without them it’s very difficult for IT administrators to accomplish the tasks that they regularly need to accomplish. In many/most environments the necessary rules for BatchPatch to work are the same rules that are already in place for general network and system administration, so you might not need to make any changes. In fact, if you regularly ping computers on your network and/or copy files to and from them by connecting to \\targetComputer\C$ in Explorer, then these allowances likely already exist.

In the case where you don’t already have these allowances configured but you’re considering using BatchPatch, you might be wondering how to make the necessary firewall configuration changes so that *ONLY* the computer that is running BatchPatch can take advantage of them. That is, you might want to limit the IP address scope in any firewall rules that you create so that those firewall rules only apply to a particular IP address. The effect of doing this would be that after the rules are created in all target computers’ Windows Firewalls, BatchPatch will only be able to connect to those target computers if the computer running BatchPatch has a particular IP address (or is within a certain IP address range, depending on how you configure the scope).

Applying a particular IP scope to inbound rules in Windows Firewall is simple. First, make sure you have made allowances for File and Printer Sharing and Windows Management Instrumentation as described on this page. A quick review of that process is below in the first step of the tutorial. Note, you can perform this process on an individual target computer or you can make the changes via Group Policy to apply to a large group of computers on a domain. The concept is the same in both scenarios, but please note that in this tutorial my screenshots and specific instructions are based on making these changes on just a single machine, so if you’re making the changes in Group Policy there might be slight differences as compared to my notes and screenshots below:

  1. Go to Control Panel > Windows Defender Firewall > Allow an app or feature through Windows Defender Firewall and then tick the checkboxes next to File and Printer Sharing and Windows Management Instrumentation for the firewall profile(s) that you want to modify (private/public/domain)


  2. Once the initial rules have been created, then you can modify the scope of those rules to limit which IP addresses can utilize them. Go to Control Panel > Windows Defender Firewall > Advanced settings to launch the interface for Windows Defender Firewall with Advanced Security. Click on Inbound Rules on the left-pane of this interface. In the screenshots below you can see that I’ve highlighted all of the individual inbound rules that I will be modifying.


  3. At this point you are going to need to modify every individual inbound rule for File and Printer Sharing and Windows Management Instrumentation for the firewall profile(s) that you are using (private/public/domain). In my case I’m using the private firewall profile, so I’m only modifying the entries for the private profile. However, for your environment you might need to modify the domain profile. Unfortunately this process needs to be completed on each inbound rule one at a time. It’s not possible to perform the action in bulk on all of them at the same time. So go ahead and start at the top and highlight the first rule and then right-click on it and select Properties. In the Properties window, go to the Scope tab.


  4. In the Remote IP address section at the bottom of the window, highlight where it says Local subnet, and then click Edit. Select the radio button for This IP address or subnet, and then enter the IP address of the computer that you will be using to run the BatchPatch console. In my lab here it’s 192.168.1.37, so that’s what I’ve entered.


  5. Repeat the IP scope modification on all of the applicable inbound rules. When complete, File and Printer Sharing and Windows Management Instrumentation will be accessible on the target computer(s) from *ONLY* the IP address that you specified.
Posted in Blog, General, Tutorials | Tagged , , , | Comments closed

Remotely Deploying Windows Feature Update Version 21H2 to Numerous Computers

By Scott | Published: March 10, 2022

Standard Deployment Method for Windows Feature Update 21H2 (and other feature updates/upgrades such as 22H2 etc) in BatchPatch

Unless you are using a version of BatchPatch that was released prior to April 2020, you can usually deploy/install feature updates like 21H2 with the normal Windows Update actions in BatchPatch under ‘Actions > Windows updates‘. However, Microsoft continues to make a lot of changes to how feature updates are handled, so there are some cases where you might have to perform the deployment using the alternate method that’s explained further down in this tutorial.

For the standard deployment method, the first requirement is that the feature update that you desire to install must be offered to the computer and show as an available update when you select ‘Actions > Windows updates > Check for available updates‘ in BatchPatch. If you see the desired feature update in that list of available updates for a given target computer or group of computers, then all you need to do to download/install the update on those computers is modify the classification filtering in ‘Tools > Settings > Windows Update‘ so that the ‘Include “Upgrades”‘ box is ticked.

After the ‘Upgrades’ classification is selected you can simply use ‘Actions > Download available updates‘ with ‘Actions > Install downloaded updates‘ or you can just use ‘Actions > Download and install updates‘. As long as you are operating in standard, non-cached mode, feature updates will install (assuming, of course, that you currently have a feature update showing in the list of available updates for a given computer).

Feature Update Deployment Considerations – Update deferral policies, and when an update is only available for “seekers”

Please note there are a couple of things to consider when installing feature updates using the standard non-cached mode BatchPatch update method.

First, as mentioned above, the target computer needs to have the desired feature update showing as one of the available updates for the computer. If you’re expecting to see it but you don’t, it could be because the update is not approved on your WSUS yet, or it could be that you have a Group Policy or Local Policy setting configured for the target computer that is set to defer the installation of feature updates for a specified amount of time. Check your Group Policy configuration for any deferral policies enabled under the following locations:

Computer Configuration > Administrative Templates > Windows Components > Windows Update

Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business

Second, depending at what stage of the rollout Microsoft currently is at the time you attempt to deploy a given feature update, they might not yet be delivering the update through the normal Windows Update channel. They typically begin the rollout with delivery only to “seekers”. This is the name they give to people who manually click on the ‘Check for updates’ button in the Windows Control panel. “Seeker” updates are visible in BatchPatch when you click on ‘Search for only optional software updates‘

Third, over the past couple/few years Microsoft has made quite a few changes to how Windows Update works, particularly with regard to how feature updates are handled. It’s possible that there is some other reason that I didn’t mention above that is the cause for why you are not seeing the feature update available for installation through the normal Windows Update methods.

Alternate Deployment of Windows Feature Update 21H2 (and other feature updates/upgrades) with BatchPatch (can be used for deployment to offline target computers)

If you need to deploy feature update version 21H2 (or any other feature update) to target computers that don’t have internet access and don’t have WSUS access and therefore cannot be targeted in standard, non-cached mode (that is to say, you are using either online cached mode or offline cached mode with those target computers, and you are not able to disable cached mode and switch to standard mode for whatever reason), then you may use the method outlined below to deploy the feature update to those computers.

  1. Download (from Microsoft) the Windows 10 Media Creation Tool. Use this link to download the media creation tool directly from Microsoft. The media creation tool web page contains two options: ‘Update now’ and ‘Download tool now’. Do NOT click on ‘Update now’ because doing so would begin the update process on your computer. Since your goal is to deploy the upgrade to remote computers, instead please click on ‘Download tool now’ to save the tool to your computer. Important: When you run the media creation tool per the next step, you will not have a choice to select which Windows 10 version is used to create the media. This means that if Microsoft releases a new version of Windows 10 when you follow this tutorial, you’ll end up with that version as opposed to the specific version 21H1 that is available today at the time of this writing. If you have another channel for obtaining media for a particular Windows 10 version, such as with a Microsoft volume licensing agreement, you may use that instead of obtaining the media through the steps outlined in this tutorial.

  2. Open the Windows 10 Media Creation Tool that you saved to your computer a moment ago. IMPORTANT: It is NOT sufficient to run the tool as administrator (using right-click, run-as) from an account that is logged on without admin privileges. For reasons that aren’t fully clear, Microsoft requires that you *must* actually be logged on to the computer with an account that is a member of the local administrators group. Otherwise the tool will not allow you to run it to completion. We don’t know why Microsoft made the tool work this way, but it’s what they did, and presumably it’s for a good reason. So go ahead and log on to your computer as a local administrator, and then launch the tool and follow the rest of this tutorial.

  3. Create installation media with the Windows 10 Media Creation tool. When the tool is running you’ll have to choose between two options to either ‘Upgrade this PC now’ or ‘Create installation media (USB flash drive, DVD, or ISO file) for another PC. Choose the option to ‘Create installation media…’ and then click ‘Next’.

  4. Choose your language / edition / architecture, and then click ‘Next’.

  5. Choose the media type. For the sake of this tutorial please select ISO as the type of media. After clicking the ‘Next’ button you will be prompted to choose a location on your computer to store the ISO file that will be downloaded/created. Select a directory/location to store the file, and then do something else until the download finishes. Depending on your connection speed it could take some time because it’s something like 4GB in size.


  6. Extract the ISO contents to a location on your local disk. After the download in the previous step is complete you’ll have to locate the file on disk and then extract the contents of the ISO to another folder. I like to use the free 7-zip for this process, but you may use whichever tool you prefer: 7-zip. After the ISO has been extracted you’ll have all of the installation files for the feature update in a single folder.

  7. Configure a deployment in BatchPatch. In BatchPatch click on Actions > Deploy > Create/modify. In the window that pops up for the Deployment configuration, click on the ‘…’ button to browse to the location where your ISO contents have been extracted to, and then choose the ‘setup.exe’ file as the file to deploy. Make sure to check the boxes for ‘Copy entire directory‘ and ‘Leave entire directory‘ . After the initial deployment phase is complete, the target Windows operating system will end up rebooting itself at least once but usually more than once while it completes the setup and installation for the feature update. As the process runs it needs to have access to all of the files that BatchPatch will deploy. Having both of the aforementioned boxes checked will ensure that when the upgrade process runs on the target computer that it has all of the files it needs for the installation. After the feature update has completed 100% you may delete the files from the target computer(s). However, please make absolutely sure that the upgrade process is 100% completed before you delete any files. In your BatchPatch deployment configuration screen you will also need to add the following parameters: 
    /auto upgrade /quiet

  8. Execute the feature upgrade deployment. In the deployment configuration that you created in the in the previous step you can execute the deployment immediately for the currently selected rows in the grid by just clicking on the ‘Execute now’ button. Alternatively you may save the deployment for future usage by clicking the double-right-arrow button ‘>>’. If you choose to save the deployment instead of executing it immediately, then when you are ready to deploy the feature update to your remote computers, you can begin the process by selecting those computers in the BatchPatch grid and then clicking on Actions > Deploy > Execute deployment, and then choose the deployment that you just created/saved.

    You should expect that the entire process will take a bit of time to complete. BatchPatch has to copy the whole installation directory to the target computer(s), which contains several gigabytes, before it can execute the upgrade process on the target(s). IMPORTANT: After the BatchPatch deployment completes for a given target computer BatchPatch will show Exit Code: 0 (SUCCESS). However, this just means that the BatchPatch deployment component is finished. The Windows feature update/upgrade process will take additional time. Please be patient and let the target computer continue upgrading and rebooting as many times as is needed. It might take a little while with multiple automatic reboots before everything is 100% finished.

    NOTE: We have had a couple of reports from users who received the following error:

    Deployment: Error: Access to the path '\\TargetComputer\C$\Program Files\BatchPatch\deployment\autorun.inf' is denied.

    We don’t know the exact cause of this issue, but it seems likely to somehow be related to the way that permissions were applied or inherited during the ISO extraction process. If you encounter this error it can be resolved quickly and easily by just deleting the autorun.inf file from the source directory after extracting the ISO contents but before executing the actual deployment for any target computers. This will prevent the problematic file from ever being copied to target computers. As such, the error will not occur.

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