BatchPatch and the Windows Update Control Panel Report a Different Number of Available Updates

By Scott | Published: December 12, 2017

Why does BatchPatch sometimes report a different number of available updates when compared to what is being reported by the control panel Windows Update interface on the target computer? This might be the most common question we receive from BatchPatch users. Today I’m going to explain all of the possible reasons why this might occur.

  1. Search Preferences: Usually when someone is seeing a different number of available updates reported by BatchPatch for a particular target computer when compared to that same computer’s Windows Update control panel, it’s because of the search scope in BatchPatch. BatchPatch might be searching a broader scope or a more narrow scope than what the Windows Update control panel is searching for.

    Under ‘Tools > Settings > Windows Update‘ review the ‘Search Preferences’ section. If you want to see every possible update then set your search to include all software updates and all driver updates. That is what we recommend for WSUS users because your WSUS approvals will control which updates are presented to target computers, and you want to make sure that BatchPatch sees every update that is presented. However, if you are using Windows Update or Microsoft Update as your search source, then we instead recommend limiting the search to only ‘Important‘ and ‘Recommended‘ updates. This will most closely emulate what Microsoft presents in the Windows Update control panel interface.

    EDIT March 2022: HOWEVER, with regard to emulating which updates are presented in Windows, please note that starting in 2022 the newest versions of Windows (10/11/2016/2019/2022) now offer certain driver updates in the normal Windows Update control panel that do not appear in BatchPatch when selecting ‘Important’ and ‘Recommended.’ In previous versions of Windows, and in earlier versions of the aforementioned versions of Windows, driver updates were either excluded altogether from appearing in Windows Update, or they were shown in a separate tab/window categorized differently from the standard Windows Updates that Microsoft considered ‘Important’ and ‘Recommended.’ That said, at the time of this writing, driver updates that appear in the normal Windows Update control panel on a computer will still only show in BatchPatch if the ‘Search for driver updates’ checkbox is ticked in the BatchPatch ‘Search Preferences’. Driver updates will generally not be displayed in BatchPatch when selecting ‘Important’ and ‘Recommended’ in versions of BatchPatch released in or before March 2022. In the next release of BatchPatch we expect to offer a new search option that will emulate the new Windows Update control panel search settings.

  2. Server Selection: It’s possible that BatchPatch is instructing the target computer to search for updates from a different source than when the computer searches for updates without BatchPatch. If you want to make sure that BatchPatch is using the same source as the target computer’s Windows Update control panel then make sure to select ‘Default / Managed‘. Selecting one of the other options in the BatchPatch settings will instruct BatchPatch to override any settings on the target computer to instead use either Windows Update or Microsoft Update as the search source.

    Default / Managed: Uses the target computer’s existing configuration to determine where to search for updates.

    Windows Update: Bypasses the target computer’s configuration and searches for updates on Microsoft’s public server. Includes only Windows updates.

    Microsoft Update: Bypasses the target computer’s configuration and searches for updates on Microsoft’s public server. Includes Windows updates AND updates for other Microsoft products. Before using Microsoft Update, target servers must be opted-in to the service. See ‘Actions > Windows Updates > Opt-in…‘

  3. Stale Results: The Windows Update control panel interface on the target computer might be showing stale results. Particularly in newer operating systems, the update list in the interface is cached and can frequently show results that are no longer accurate, whereas BatchPatch always performs a fresh search and will therefore never show you stale results. You might want to force the Windows Update control panel to perform a new search to make sure it’s showing results that are accurate and up to date. You can also look at the Windows Update history to see if the updates in question have already been installed (‘Actions > Windows updates > Generate consolidated report of update history‘). See this posting for more details on refreshing stale search results.

  4. Offline Mode: If you have enabled offline mode you will likely notice a discrepancy between the available updates that are reported in BatchPatch as compared to the available updates reported in the Windows Update control panel. This is because offline mode is designed for offline scanning when no internet or WSUS is available. An offline mode scan relies on the WsusScn2.cab file that Microsoft releases each month. First, make sure that you are always using the latest WsusScn2.cab file that is available so that you can get the latest updates. However, please also note that while this file contains all security updates as well as various other updates that Microsoft decides to include in it, the WsusScn2.cab file does not contain every single update that is published on Microsoft’s public Windows Update and Microsoft Update servers. On the other hand it’s also the case that the WsusScn2.cab file will sometimes contain updates that are actually not offered through the online channels.

  5. Dual-Scan: Even if you did not specifically enable “Dual-Scan” it might already be enabled on your computers without you even realizing it, due to the way that Microsoft deployed this “feature”. In this case your Windows Update scans might be searching Microsoft’s public Windows Update servers instead of your own local WSUS server. See here for more:

    **Dual-Scan Difficulties with Windows Update on Windows 10 Versions 1607 Anniversary Update and 1703 Creators Update

    **Deciphering Dual-Scan Behavior in Windows 10

  6. SCCM: If you have SCCM in your environment you need to be aware of the fact that once SCCM takes control over a WSUS, that WSUS cannot be used by a non-SCCM application like BatchPatch to search for updates. So, if your target computers are configured via Group Policy to search for updates on a WSUS that is controlled by your SCCM server, then when BatchPatch initiates a scan for available updates it will always report ‘No applicable updates’. In order to use BatchPatch with a WSUS, the WSUS must be independent and cannot be linked to or controlled by SCCM.

  7. DNS: Make sure that BatchPatch is actually connecting to the machine that you think it is connecting to. After you use BatchPatch to check for updates, the ‘Remote Agent Log’ column will include, among other things, the actual computer name of the target computer, as reported by the target computer. It’s conceivable that your DNS server is returning stale results, and this causes you to connect to a different computer than you think you are connecting to, so make sure to verify that you are definitely connecting to the correct/desired computer.

  8. Optional / “Seeker” Updates: In Windows 10/2019 build 1809 or newer, if you go to the Windows Update control panel on a machine that was recently updated, you may find additional optional updates available if you use the ‘Check for updates‘ button. Microsoft releases these optional updates usually toward the end of the month. While the updates do not contain any new functionality they may contain fixes for specific outstanding issues. They are released through what is essentially a completely separate channel that is only available to “seekers” who use the ‘Check for updates‘ button. At the time they are made available to “seekers” as optional updates they are not yet released to WSUS nor are they released to the normal automatic updates channel in ‘Windows Update’ or ‘Microsoft Update.’ However, Microsoft moves them from optional status into the normal release channel in the following month after they are initially released to “seekers.”

    Starting with the October 2019 release, BatchPatch can find these optional updates by selecting the checkbox under ‘Tools > Settings > Windows Update > Search for only optional software updates‘

    Unless you have a specific need for one of these optional updates, we generally do not recommend installing them. We believe that unless you have a specific need for a fix that is included in one of these updates, it usually makes the most sense to wait until the following month when Microsoft moves them from optional status to the normal deployment channels.
Posted in Blog, General, Tutorials | Tagged | Comments closed

Understanding the ‘Special’ Items in the BatchPatch Job Queue

By Scott | Published: November 27, 2017

The BatchPatch Job Queue has a number of “special” items that you can use to control the behavior of the queue. You can see these options in the screenshots below. Today I’m going to explain each of these special actions.

    Wait X minutes

  • Wait X minutes – This action is pretty self-explanatory. You can add a wait period to your job queue if you need the queue to pause for a period of time before continuing execution. The most common reason an administrator uses a wait period is when rebooting a target computer to give it ample time to shutdown and restart before the next queue action is executed. You can string together multiple wait periods, if desired. Here is one possible way you might use a wait period in your job queue: 
    Step 1: Download and install updates + reboot always
Step 2: Wait 10 minutes
Step 3: Download and install updates + reboot if required

    • Wait for host to be detected online

  • Wait for host to be detected online – If you insert a ‘Wait for host to be detected online’ into your job queue, when the queue reaches this step it will check to see if it can ping the target computer and perform a successful WMI query. If it can do both of these, then the queue will advance to the next step. If it cannot do both, then it will wait a minute before trying again. The loop will continue until it is successful or until the global timeout is reached. When the global timeout is reached the queue will either terminate or continue, depending on how you have set your global timeout configuration. You can see the timeout configuration options in the screenshot below.

    IMPORTANT: ‘Wait for host to be detected online’ should generally not be placed immediately after a reboot action. The reason for this is because in that case the ‘Wait for host to be detected online’ will occur just a split second after the reboot is initiated, which means that the target computer will probably still be online, and so the check will complete successfully, and the next step in the queue will be triggered. The problem is that the machine will then probably go offline while that next step is executing, which will create undesirable results. Here is one possible way you might use ‘Wait for host to be detected online’ in your job queue.

    Step 1: Download and install updates + reboot always
Step 2: Wait 10 minutes
Step 3: Wait for host to be detected online
Step 4: Download and install updates + reboot if required

    • Wait for host to go offline and come back online

  • Wait for host to go offline and come back online – This special action provides you with an alternative way to wait for a computer to reboot before executing more actions. If this action is used immediately after a reboot step, BatchPatch will monitor the target computer until it goes offline and comes back online. The target computer is not considered online again until it is both pingable and responding to WMI queries. If the global timeout is reached before the computer goes offline and comes back online, the queue will either continue or be terminated, depending on how you have set your global timeout configuration. You can see the timeout configuration options in the screenshot below.

    IMPORTANT: ‘Wait for host to go offline and come back online’ should be used carefully. In particular, we do not recommend using this special action with virtual machine target computers. The reason for this is because virtual machines can often reboot within just a couple of seconds, which unfortunately can be too fast for BatchPatch to successfully detect. If the machine reboots so rapidly that BatchPatch does not know that it ever went offline, then ‘Wait for host to go offline and come back online’ will hang until the global timeout is reached, which will leave you with undesirable results. Additionally, note that if you use ‘Wait for host to go offline and come back online’ immediately after a ‘…reboot if required’ action, you’ll have a problem if reboot is NOT required because then ‘Wait for host to go offline…’ will wait indefinitely until it times out. Here is one possible way you might use ‘Wait for host to go offline and come back online’ in your job queue when the target computer is not a virtual machine.

    Step 1: Download and install updates + reboot always
Step 2: Wait for host to go offline and come back online
Step 3: Download and install updates + reboot if required

    • Wait for host to have zero logged-on users

  • Wait for host to have zero logged-on users – Just as it sounds, this special item will cause the BatchPatch job queue to wait until the target computer does not have any logged-on users before proceeding with the next step in the job queue. Here is one possible way you might use ‘Wait for host to go offline and come back online’ in your job queue when the target computer is not a virtual machine. 
    Step 1: Wait for host to have zero logged-on users
Step 2: Download and install updates + reboot if required

    • Terminate queue if previous ‘Check for available updates’ finds 0 updates

  • Terminate queue if previous ‘Check for available updates’ finds 0 updates – This special item works in conjunction with ‘Check for available updates’ to determine whether or not to continue the queue or terminate it. Here is one possible way you might use “Terminate queue if previous ‘Check for available updates’ finds 0 updates” in your job queue. As soon as a ‘Check for available updates’ finds 0 available updates, the queue will terminate. 
    Step 1: Check for available updates
Step 2: Terminate queue if previous 'Check for available updates' finds 0 updates
Step 3: Download and install updates + reboot always
Step 4: Wait 10 minutes
Step 5: Wait for host to be detected online
Step 6: Check for available updates
Step 7: Terminate queue if previous 'Check for available updates' finds 0 updates
Step 8: Download and install updates + reboot always
Step 9: Wait 10 minutes
Step 10: Wait for host to be detected online
Step 11: Check for available updates
Step 12: Terminate queue if previous 'Check for available updates' finds 0 updates
Step 13: Download and install updates + reboot if required

    • Terminate queue if previous action fails/errors

  • Terminate queue if previous action fails/errors – This option is typically used when incorporating custom scripts into your job queue. Failure of a script or action is determined by the return value of that script/action. Any non-zero return value will be considered a failure/error by the BatchPatch job queue. So if you want to run a custom script before downloading and installing updates, and you only want the download/install to occur if the script performs desired actions, then have your script return 0 when successful and some non-zero value when it’s not successful. Then you can setup a job queue similar to this: 
    Step 1: Execute your custom remote command here
Step 2: Terminate queue if previous action fails/errors
Step 3: Download and install updates + reboot if required

    • Abort basic multi-row sequence if previous action fails/errors

  • Abort basic multi-row sequence if previous action fails/errors – Unlike the aforementioned item to ‘Terminate queue if previous action fails/errors’ this action will not terminate the current job queue but will instead terminate the entire basic multi-row queue sequence that this job queue is running in. The current job queue will complete, but the basic multi-row queue sequence will stop there. No more rows will be triggered.

    IMPORTANT: If you want/need both the current queue *and* the basic multi-row queue sequence to be terminated if the previous action fails/errors, then you would need your job queue to look something like this. If you were to swap the order of steps 2 and 3, you would not get the desired behavior:

    Step 1: Execute your custom remote command here
Step 2: Abort basic multi-row sequence if previous action fails/errors
Step 3: Terminate queue if previous action fails/errors
Step 4: Download and install updates + reboot if required

    • Abort advanced multi-row sequence if previous action fails/errors

  • Abort advanced multi-row sequence if previous action fails/errors – Unlike the aforementioned item to ‘Terminate queue if previous action fails/errors’ this action will not terminate the current job queue but will instead terminate the entire advanced multi-row queue sequence that this job queue is running in. The current job queue will complete, but the advanced multi-row queue sequence will stop there. No more rows will be triggered.

    IMPORTANT: If you want/need both the current queue *and* the advanced multi-row queue sequence to be terminated if the previous action fails/errors, then you would need your job queue to look something like this. If you were to swap the order of steps 2 and 3, you would not get the desired behavior:

    Step 1: Execute your custom remote command here
Step 2: Abort advanced multi-row sequence if previous action fails/errors
Step 3: Terminate queue if previous action fails/errors
Step 4: Download and install updates + reboot if required
Posted in Blog, General, Tutorials | Tagged , | Comments closed

The Windows Update Control Panel in Windows 10/2016 is Not Up To Date After Using BatchPatch To Install Updates

By Scott | Published: November 16, 2017

After you install updates with BatchPatch (or with any third-party tool or script) you might notice that if you then look at the Windows Update control panel GUI on a Windows 10 or Windows 2016 target computer that it will not usually be up to date. Instead it will display stale, cached search results that are no longer accurate after applying the updates with BatchPatch. You can close and re-open the GUI over and over, you can restart the Windows Update service, and you can use the ‘check for updates’ option in the interface repeatedly, but still the GUI will display old search results that are no longer valid.

In reality this is just a cosmetic issue. However, we have some users who for one reason or another need or want this GUI to always reflect the current status of the available updates on the computer. In previous versions of Windows prior to 10/2016 this was not so much of an issue because you could initiate a new check for updates on-demand in the Windows Update control panel GUI. But starting with Windows 10 and 2016 it’s no longer an option. And if you tried using the command line action wuauclt.exe /detectnow or wuauclt.exe /resetauthorization /detectnow or wuauclt.exe /reportnow you would have noticed that those commands don’t seem to do anything in 10/2016.

In Windows 10/2016 there is a new command line utility UsoClient.exe that can be used to resolve this discrepancy. This Microsoft blog posting explains that we can use UsoClient.exe startscan from an administrator command prompt on Windows 10/2016 to effectively replace wuauclt.exe /detectnow.

EDIT 2025: Unfortunately in the more recent versions of Windows UsoClient.exe will not always trigger the GUI to update. Sometimes UsoClient.exe StartInteractiveScan works, but it seems to only allow itself to be run successfully periodically instead of every single time it is executed.

This posting exposes some other switches that apparently exist for UsoClient.exe, though at the moment I’m not sure how useful the other switches will be for most BatchPatch users, and I have not tested those other switches either, so I can’t comment on if they work as described. They are:

StartScan (Used To Start Scan)
StartDownload (Used to Start Download of Patches)
StartInstall (Used to Install Downloaded Patches)
RefreshSettings (Refresh Settings if any changes were made)
StartInteractiveScan (May ask for user input and/or open dialogues to show progress or report errors)
RestartDevice (Restart device to finish installation of updates)
ScanInstallWait (Combined Scan Download Install)
ResumeUpdate (Resume Update Installation On Boot)

Executing UsoClient.exe on target computers

BatchPatch has a built-in menu item to execute the StartScan option of UsoClient.exe: Actions > Windows updates > usoclient.exe /startscan This is the most commonly needed command, but you can also optionally hardcode any additional commands that you desire using the instructions posted here.

Once the command has been hard-coded into your BatchPatch installation you will be able to execute it on-demand for target computers in your grid at any time, but you can then also easily add it to job queues. If you are one of those users who really wants or needs the target computers’ Windows Update GUI to be accurate at every moment, then you might consider appending the UsoClient command to the end of a job queue that downloads/installs updates on your target computers. This way you could ensure that after updates are installed the GUI on the target computers will reflect the current state rather than showing stale information.

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

Remotely Apply Windows Updates from a Local WSUS Server to Multiple Computers

By Scott | Published: November 9, 2017

Today we’re going to take it back to the basics and review some of the core functionality that BatchPatch offers. Specifically we’re going to look at how you can use BatchPatch to download and install Windows Updates on numerous target computers, simultaneously, when those computers are configured to receive updates from a local WSUS server. BatchPatch can, of course, also be used to trigger the update process on computers that are not using a WSUS. In either case, BatchPatch can also monitor the process to completion and optionally execute a reboot, if required by the installation, and monitor the reboot too, to make sure that all computers come back online in a timely manner.

WSUS and Group Policy

If you are utilizing a Windows Server Update Services (WSUS) server then you are going to have a Group Policy (or the corresponding, underlying registry key/value) configured on each of the target computers that is pointing to the WSUS server. For more details on the Group Policy setting, please see BatchPatch Integration with WSUS and Group Policy

If you’re not sure whether or not your target computers are actually configured to use the WSUS, you can use BatchPatch to find out the value of the Group Policy setting mentioned above for your target computers. To do that highlight the desired computers in your BatchPatch grid and select ‘Actions > Windows updates > Get Windows Update configuration’ as shown in the screenshot below.

You can see the results below, which show that my targets are configured to use my local WSUS server, WIN2012R2, for their updating.

“Dual Scan” Considerations

It is important to note that in the case of Windows 10 and Windows 2016 target computers, having a value set for the aforementioned Group Policy actually does not tell the complete story of where those target computers will search for updates. Ever since the introduction of “Dual Scan” by Microsoft, which arrived in late 2017, things have become a bit more tricky. If you determine, using the above method, that your target computers are pointing to a WSUS server, it’s still possible that they will retrieve updates from Microsoft’s public Windows Update or Microsoft Update servers if “Dual Scan” is enabled. To determine, with certainty, whether or not Dual Scan is enabled and whether your machines are going to search for and retrieve updates from your local WSUS server or Microsoft’s public update servers, please review the following two posts carefully:

‘Dual Scan’ Difficulties with Windows Update on Windows 10 versions 1607 ‘Anniversary update’ and 1703 ‘Creators update’

Deciphering ‘Dual Scan’ Behavior in Windows 10

Applying Windows Updates Remotely

In BatchPatch you should first verify your Windows Update settings under ‘Tools > Settings > Windows Update’. If you want BatchPatch to respect the current configuration of your target computers, then make sure the ‘Server Selection’ value is set to ‘Default / Managed’ as it is in the screenshot below. The ‘Default / Managed’ setting tells BatchPatch to use the target computer configuration to determine where to search for and retrieve updates. If the target computer is configured to utilize your local WSUS, then BatchPatch will do that. If the target computer is configured to utilize Windows Update or Microsoft Update, then BatchPatch will do that.

However, if you want BatchPatch to ignore the target computer settings and search only against Windows Update or Microsoft Update, then you can change the Server Selection value as desired. So for example if you set the BatchPatch Server Selection to ‘Windows Update’ then it does not matter if your target computers are configured via Group Policy to utilize your local WSUS server because BatchPatch will tell them to use Windows Update when BatchPatch initiates its scans. Note, BatchPatch does not modify the target computer configuration in this case. It simply overrides the target computer configuration when actions in BatchPatch are initiated.

When you are finally ready to actually search for, download, and install updates on your target computers, highlight the desired computers in your BatchPatch grid, and then select ‘Actions > Windows updates…’ and the desired operation, whether that be to just check for available updates or to just download available updates or to download and install updates plus reboot etc.

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

Troubleshooting Errors 1611: 64 , 1620: 64 , 1611: 2250 , 1620: 2250

By Scott | Published: October 24, 2017

The following errors are probably some of the least common errors that BatchPatch users encounter, but they can also be the most difficult to understand and troubleshoot, so I want to take some time today to address them.

Error 1611: 64. Failure
Error 1620: 64. Failure
Error 1611: 2250. Failure
Error 1620: 2250. Failure

Generally speaking, all four of these errors typically have the same underlying cause, though their manifestation is slightly different. The 1611 and 1620 numbers simply indicate where in BatchPatch the errors occurred. However, the numbers that come after the 1611 and 1620 are the actual Windows system error codes being generated during the failure. In the case of this posting we are focusing specifically on Windows System Error Codes 64 and 2250.

The entire set of Windows system error codes and their meanings are available from Microsoft at this link: Windows System Error Codes

ERROR_NETNAME_DELETED
64 (0x40)
The specified network name is no longer available.

ERROR_NOT_CONNECTED
2250 (0x8CA)
This network connection does not exist.

In both cases BatchPatch is successfully establishing a connection with the target computer briefly, but then that connection is severed very soon after being established, which causes BatchPatch to display one of the above errors.

The primary question that needs to be answered when one of these errors is encountered is what could possibly be interrupting an existing connection between the BatchPatch computer and the target computer?

Likely Causes of Errors 64 and 2250

The most common/likely causes of an interruption to an existing connection are the following, in no particular order, but it’s certainly possible that something else is responsible for the issue. Below are only the things that we have ever seen cause this:

  • Host Instrusion Prevention/Protection Software (HIPS). This type of software may very well be the cause. It could be severing the network connection or perhaps more likely might be killing the remote psexesvc.exe process/service, which then causes the 64 or 2250 error to occur back at the BatchPatch console. Consider disabling any HIPS software to test. If disabling the software solves the problem, then consider re-enabling the software but whitelisting psexesvc.exe and psexec.exe. Alternatively, we have found that in these cases where HIPS or similar software is the culprit, using a custom remote service process name instead of psexesvc.exe is frequently sufficient to bypass detection. In BatchPatch under ‘Tools > Settings > Remote Execution > Use PsExec -r switch’ you can provide a custom name for the remote service. We recommend something like ‘BatchPatchExeSvc‘.

  • Anti-virus software or any other similar security related or endpoint protection type software. These apps can all cause similar behavior, and they would be addressed in the same way as described above for HIPS.

  • Firewall. A traditional firewall might be less likely to be the typical culprit for 64 and 2250, but it’s still possible that there is something going on with a firewall that could cause the issue. If all else fails, it would be worth re-examining your firewall configuration just to make sure. However, in most cases a security application (one that is *not* a traditional firewall application) installed on the target computer or on the BatchPatch computer, such as the type of software mentioned above, is more likely to be the culprit.

Additional considerations: It’s worth also trying FQDN or IP address instead of NetBIOS name. Additionally, consider trying integrated security instead of alternate credentials, or vice versa.

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

Deciphering “Dual Scan” Behavior in Windows 10

By Scott | Published: October 19, 2017

A few weeks ago I wrote about the relatively new “feature” from Microsoft that they are calling “Dual Scan.” You can (and should) read more about that here so that you understand, in detail, what they have done: ‘Dual Scan’ Difficulties with Windows Update on Windows 10 versions 1607 ‘Anniversary update’ and 1703 ‘Creators update’.

The quick summary is that Microsoft introduced new behavior to the Windows Update Agent (WUA) recently that has the potential to significantly impact your Windows update routine, especially if you are not aware of the change. If you’re aware of the change, then you should be able to digest it and determine what, if anything you want or need to do in your environment to make sure that your Windows update routine is not impacted negatively. If you are currently using a WSUS server in your environment, then you might be impacted. If you do not use WSUS and if you do not plan to use a WSUS, then you probably do not need to concern yourself too much with all of this stuff.

They describe “Dual Scan” as follows:

It is for the enterprise that wants WU to be its primary update source while Windows Server Update Services (WSUS) provides all other content. In this scenario, the WU client automatically scans against both WSUS and WU, but it only accepts scan results for Windows content from WU. Stated another way, anything on WSUS that resides in the “Windows” product family is ignored by the Dual Scan client. This is to avoid the “two masters” problem that can occur when there are multiple equally valid sources of truth for a given set of updates.

Problems with “Dual Scan”

I see three primary issues with “Dual Scan.”

  1. I have to question Microsoft’s motive with this change. I simply don’t believe that any enterprise that is currently using a Windows Server Update Services (WSUS) server wants to have two sources for updates. I honestly don’t think that enterprises are interested in getting Windows Updates from Windows while getting other update content from WSUS, so who is this change really for? Is it for Microsoft customers or does it actually somehow serve Microsoft in some yet to be understood or revealed way? Call me a cynic, but I’ve been working in the industry for a long time, and this is one of the most peculiar changes I recall ever seeing from Microsoft, and I have yet to really make sense of the motivation behind the decision to add the feature, and more importantly the decision for how to introduce it.

  2. The introduction of this new behavior left a lot to be desired. Essentially the way it was rolled out was after applying updates one month, all of a sudden the “Dual Scan” behavior was enabled on our systems without our knowledge or “consent.” I put “consent” in quotes because arguably we are consenting to everything that Microsoft does simply by using their products. All I mean when I say “consent” is that we did not enable the feature/functionality. It was simply enabled all of a sudden with no advance warning and no notification that anything had changed. And yet our computers, which are (and were) configured to use our local WSUS for their Windows update source, all of a sudden started scanning for updates against Microsoft’s public Windows update servers instead of our own WSUS. This was confusing, to say the least, and it required a number of hours to then figure out what was happening, why it was happening, and how to modify the behavior to suit our needs. Quite a bit of testing had to be done in order to make sure we fully understood the behavior. The problem here is that we (and many, many companies on the planet) use WSUS to control which updates are presented to our systems. And yet all of a sudden our systems could have been installing updates that we did not approve. And I can pretty much guarantee that in some organizations unapproved updates were installed on systems as a result of the way this change was introduced with no notification whatsoever.

  3. Determining if “Dual Scan” is enabled is easy to do only if you know how to do it. However, if you weren’t paying close attention, then you likely did not even know it was introduced/enabled, and you certainly would not know how to determine if it is enabled or not. And even if you were paying very close attention and discovered that the behavior was occurring, you still would have to go out of your way to find out the best way to determine if the behavior is affecting your systems or not. Microsoft did not provide any obvious way to see in Windows if the feature is enabled. Instead it requires the administrator to take it upon herself/himself to learn how to determine what’s happening “under the hood.”

How To Confirm If “Dual Scan” Is Or Is Not Enabled

As mentioned in my previous posting about “Dual Scan”, “Dual Scan” is automatically enabled when a combination of Windows Update group policies or their underlying registry entries are configured. Please refer to the previous posting for more details about which combination of policies cause it to be enabled. The problem is that even if you have determined that you have or do not have the combination of policies enabled that would cause “Dual Scan” to be enabled, you still need a way of determining if it *actually* is enabled or not.

Automated method for determining if “Dual Scan” is enabled:

Beginning with the March 2019 release of BatchPatch there is an action Get ‘Dual Scan’ configuration available under Actions > Windows updates as well as Actions > Get information. BatchPatch essentially automates the manual process that is described below for determining whether or not “Dual Scan” is enabled on a given computer.

Manual method for determining if “Dual Scan” is enabled:

Note, if you are NOT using a local WSUS, then you probably do not have to worry about any of this, as the “Dual” part of “Dual Scan” refers to WSUS plus Windows Update. If you do not have a WSUS, then you will not have “Dual Scan” enabled because you simply cannot have dual scanning when there is only a single scan source available/accessible to your computers.

If your computers are configured via Group Policy (using the ‘Specify intranet Microsoft update service location‘ policy) to use a WSUS server as their update source, then the following PowerShell script, when run on a target computer, should reveal Windows Server Update Services as your Default AU Service for that computer.

$ServiceManager = New-Object -ComObject "Microsoft.Update.ServiceManager"
$ServiceManager.Services

You may also use BatchPatch to execute this script by inserting the following text into a BatchPatch ‘Remote command (logged output)’, which is available under ‘Actions > Execute remote process/command’

cmd.exe /c echo . | powershell.exe -ExecutionPolicy Bypass -command "$ServiceManager = New-Object -ComObject 'Microsoft.Update.ServiceManager';$ServiceManager.Services"

Now, if your computers are configured to use a WSUS (using the ‘Specify intranet Microsoft update service location‘ policy) but you notice in the script results that ‘Windows Update’ or ‘Microsoft Update’ is your Default AU Service, which means that ‘IsDefaultAUService’ will be set to TRUE for either ‘Windows Update’ or ‘Microsoft Update’, then you know that “Dual Scan” is enabled on the computer, which means that effectively speaking its update source for Windows updates will NOT be your local WSUS and will instead be Windows Update or Microsoft Update. To disable “Dual Scan” please refer back to my previous “Dual Scan” posting to see how to do that.

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

Creating Multiple Scheduled Tasks for a Single Computer

By Scott | Published: October 12, 2017

In BatchPatch sometimes you need to be able to schedule more than one task for a given computer or group of computers. There are a couple of ways to do this.

Multiple Tasks Scheduler

If you need to schedule multiple tasks to run at different days/times for a single computer, and if you do not need any recurrence, then you may decide to use the BatchPatch Multiple Tasks Scheduler. Configuration is very simple.

  1. Select the desired hosts/rows in the BatchPatch grid, and then select ‘Actions > Task scheduler > Create/modify scheduled task’
  2. In the ‘Task Scheduler’ window that appears, click on ‘Create Multiple Scheduled Tasks’
  3. Now you can go ahead and select the desired task from the drop-down menu along with the desired run time/date. Then click the arrow button to add it to the multiple tasks schedule. Do this for as many tasks as desired. They will be displayed chronologically, regardless of the order that you enter them. You will not be allowed to enter more than one task for the same run time/date. When you have finished entering all of the desired tasks and run times, click OK to apply these tasks to the selected rows in the BatchPatch grid.

  4. As always for scheduled tasks, if you want the tasks to run you need to also ensure that you have enabled the scheduler. The little clock icon in the upper right corner of the BatchPatch window is red when the scheduled is disabled and it’s green when the scheduler is enabled. Click on it to toggle from enabled to disabled and vice versa.

Singular Task Scheduler

The other way to have multiple scheduled tasks for a single host or group of hosts is to simply create more than one row in the BatchPatch grid (or in a separate BatchPatch grid) for each task that you want to create. If you need to create recurring tasks, then this is actually your only option anyway. The multiple tasks scheduler does not support recurrence.

  1. For each task that you want to create for a given host, enter that host name (or IP) into the BatchPatch grid. So in my example I’m going to create three different scheduled tasks for a single host, so I have entered the host name into the grid three times. If you cannot seem to get a single host name into the grid more than one time, make sure that you have not enabled the setting ‘Prevent duplicate host names from being added to grid.’ You can find that setting under ‘Tools > Settings > Grid Preferences.’

  2. Now to apply a scheduled task I select a single row and apply the desired task using ‘Actions > Task Scheduler > Create/modify scheduled task’ and optionally applying recurrence for the given task. I can then repeat that process for as many rows as desired until I have all of the scheduled tasks applied.

  3. In this example I have applied three different scheduled tasks to three rows in the grid, all of which will be executed on the same computer called ‘host1’. Now that I have my tasks applied, all I need to do is enable the scheduler by clicking on the small clock icon in the upper right corner of the BatchPatch window.
Posted in Blog, General, Tutorials | Tagged , | Comments closed

Remotely Starting and Stopping Services on Numerous Computers

By Scott | Published: September 26, 2017

Today’s posting is going to be pretty quick. Every systems administrator at one time or another has needed to stop, start, or restart a service on numerous remote computers quickly and painlessly. I’m sure many of you have spent the time to write scripts that do this kind of thing, but even in those cases you usually have to wait for each target to be touched, sequentially. With BatchPatch you can very quickly and easily execute a service restart on many remote computers, simultaneously.

Let’s use the Windows Update service as our primary example today because after all BatchPatch is the ultimate Windows Update tool. 🙂

Let’s start by having a look at the services console in Windows. To do this select ‘Start > Run’ and then type ‘services.msc’ into the ‘Run’ command line.

Now we can view the entire list of services for a given computer along with their functions and their current statuses.

We can get the same information in BatchPatch for numerous target computers, if needed, using ‘Actions > Services / Processes > List all services’

In BatchPatch if we want to restart a service on many remote computers, the first thing we need to do is identify the ‘DisplayName’ of the service that we want to restart. If we go back to the services.msc console and double-click our ‘Windows Update’ service, we can see that while the ‘Service name:’ is listed as “wuauserv”, the ‘Display name:’ is listed as “Windows Update.”

Now that we have that information, if we want to restart the Windows Update service on target computers, all we need to do is highlight the desired computers in our grid, and then select ‘Actions > Services / Processes > Restart service by name…’

We are prompted to enter the DisplayName value for the desired service, which in this case is just “Windows Update.”

We enter “Windows Update” without the quotes into the form field that is displayed…

After clicking OK the restart service macro is executed. When it completes we see Remote Command (logged output): Exit Code: 0 (SUCCESS). Additionally if we double-click on a row (or middle-click on an individual cell) we can see the contents to confirm what has actually taken place. We can see the successful ‘stop’ command followed by the successful ‘start’ command. That’s all there is to it.

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

“Dual Scan” Difficulties with Windows Update on Windows 10 versions 1607 ‘Anniversary update’ and 1703 ‘Creators update’

By Scott | Published: September 19, 2017

There is new required reading from Microsoft for all systems administrators who are managing Windows Updates in their organizations. We *strongly* recommend that all of you carefully read the following two articles so that you are aware of this new (and unexpected) behavior of the Windows Update client:

Demystifying “Dual Scan”
Improving Dual Scan on 1607

Microsoft has recently modified the behavior of Windows Update such that if you currently have your clients configured via group policy to point to an internal managed WSUS, it’s possible, depending on how things are configured, that scans for Windows Updates for your target computers might now be bypassing your WSUS and utilizing Microsoft’s public Windows Update servers instead. They describe “Dual Scan” as follows:

It is for the enterprise that wants WU to be its primary update source while Windows Server Update Services (WSUS) provides all other content. In this scenario, the WU client automatically scans against both WSUS and WU, but it only accepts scan results for Windows content from WU. Stated another way, anything on WSUS that resides in the Windows product family is ignored by the Dual Scan client. This is to avoid the ‘two masters’ problem that can occur when there are multiple equally valid sources of truth for a given set of updates.

IMPORTANT:

Dual Scan is automatically enabled when a combination of Windows Update group policies [or their MDM equivalents, or the underlying registry keys corresponding to either set of policies] is configured:

  • Specify intranet Microsoft update service location (i.e., WSUS)
  • Either of the policies belonging to Windows Update for Business
    • Select when Feature Updates are received
    • Select when Quality Updates are received

The group policies mentioned above are located in group policy:

Computer Configuration\Administrative Templates\Windows Components\Windows Update\Defer Windows Updates

In my particular case I have ‘Configure Automatic Updates’ and ‘Specify intranet Microsoft update service location’ enabled. These are the two standard/typical policies that any organization will have enabled if they are using a WSUS instead of Windows Update or Microsoft Update.

These two policies are located in group policy:

Computer Configuration\Administrative Templates\Windows Components\Windows Update

Additionally, I also have the ‘Defer feature updates’ setting enabled on my Windows 10 computers. This setting is visible in the ‘Advanced options’ for Window Update Settings control panel, and it’s similar to the group policy ‘Select when Feature Updates are received’ mentioned above.

Note: The ‘Defer feature updates’ UI setting has an underlying registry entry, which will be set to 1 if the ‘Defer feature updates’ box is checked. If the box is unchecked then the value will either be set to 0 or will not exist at all:

Hive: HKEY_LOCAL_MACHINE
Key Path: Software\Microsoft\WindowsUpdate\UX\Settings
Value name: DeferUpgrade

The behavior that resulted from having the combination of policies described above enabled on my computer is that all of a sudden my scans for Windows Updates were being performed on Microsoft’s public Windows Update server instead of my internal managed WSUS server. Frankly, I was absolutely *shocked* at this change in behavior. We believe that this behavior should not have been automatically enabled by Microsoft but rather should only have been enabled if/when the administrator turned on this capability. However, we obviously have no control over Microsoft, which means that now we instead must just focus on understanding how to effectively disable this behavior.

IMPORTANT: In late 2017 Microsoft actually removed the UI option checkbox for ‘Defer feature updates’ but it is still possible for the underlying registry entry that controls the actual behavior in Windows to be enabled. In fact, if you had the ‘Defer feature updates’ box checked in the past, then you will likely encounter this very same situation where the UI checkbox disappears even though the underlying registry value is still configured/enabled. This means that you could unknowingly have ‘Dual Scan’ enabled even if you think your settings are all correct. I encountered this issue on my 1607 test computer, and I had to manually alter the registry value since the UI option was removed. The ‘DeferUpgrade’ registry value must be either set to 0 or deleted altogether. If you delete it, make sure to only delete the ‘DeferUpgrade’ value. Do not delete the entire registry key path.

Hive: HKEY_LOCAL_MACHINE
Key Path: Software\Microsoft\WindowsUpdate\UX\Settings
Value name: DeferUpgrade

How to Disable “Dual Scan”

Option 1:
One quick and simple way to disable “Dual Scan” so that your computers will only reach out to your internal WSUS and will not perform scans on the public Windows Update servers is to simply disable ‘Defer feature updates’ or set both of the following two policies to ‘Not configured’

‘Select when Feature Updates are received’
‘Select when Quality Updates are received’

Additionally, make sure that the aforementioned registry value for ‘DeferUpgrade’ is not set to 1. You may either set it to 0 or delete the value altogether.

Option 2:
If you want or need to leave one of the policies mentioned in ‘Option 1’ enabled, then you may instead enable a new policy ‘Do not allow update deferral policies to cause scans against Windows Update’. You can find it in group policy:

Computer Configuration\Administrative Templates\Windows Components\Windows Update

If you don’t see this policy in your list of available policies in the Group Policy console then you most likely just need to apply the latest cumulative update for your OS, after which you should see the option. For version 1607 it arrived in August 2017, while for version 1703 it arrived in October 2017.

Additional Notes

  • More details on how to determine where your computers are *actually* searching for updates: Deciphering Dual-Scan Behavior in Windows 10

  • In April 2018 Microsoft posted a new blog entry on the topic of ‘Dual Scan’ that has some helpful information and is definitely worth reviewing:
    Windows 10 Updates and Store GPO behavior with DualScan disabled and SCCM SUP/WSUS managed

  • If you try to enable the ‘Computer Configuration\Administrative Templates\System\Internet Communications Management\Internet Communication settings\Turn off access to all Windows Update features’ group policy then you might start seeing:

    Error -102: Failed to execute the search. HRESULT: -2145124306 in BatchPatch.

    0x8024002E -2145124306 SUS_E_WU_DISABLED non managed server access is disallowed
  • If you try to enable the ‘Computer Configuration\Administrative Templates\Windows Components\Windows Update\Do not connect to any Windows Update Internet locations’ you might start seeing:

    Error -102: Failed to execute the search. HRESULT: -2145103860 in BatchPatch.

    0x8024500C -2145103860
  • If your targets are configured to point to your WSUS but your WSUS is not online then you will likely see one of the following errors:

    Error -102: Failed to execute the search. HRESULT: -2145107924

    0x8024402c -2145107924 WU_E_PT_WINHTTP_NAME_NOT_RESOLVED

    Error -102: Failed to execute the search. HRESULT: -2145123272

    0X80240438 -2145123272
Posted in Blog, General, Tutorials | Tagged , , | Comments closed

Some of the “Fun” Features You Didn’t Know About in BatchPatch

By Scott | Published: September 13, 2017

Custom Row Selection Color:

You are probably already aware of the fact that you can modify the row selection color in BatchPatch. To do this you would select ‘Tools > Row selection color…’ or you could click on the color palette image in the menu strip.


However, what you might not be aware of is that you can choose a custom row selection color instead of having to use one of the pre-configured color options. To do this you must first launch the Row Selection Color form using one of the methods described above. Then inside the Row Selection Color form click on the color palette image at the bottom.


Then you can use the ‘Define Custom Color’ button in the Windows color palette control to set your own custom color.


Now you can have that ‘lime green’ row color option that you’ve been dreaming about. 😉


Alternating Rows Back Color Intensity:

BatchPatch comes out of the box with a pre-configured alternating rows gray back color, but the intensity of this gray color is actually user-configurable. See the following two screenshots for the extreme examples, but note that you can also select any intensity in between these examples.


To modify the intensity, click on the tiny arrow icon in the lower left corner of the BatchPatch main form. A slider appears that allows you to adjust the intensity of the alternating rows back color.


Grid Borders:

The BatchPatch grid borders can be set in four different positions. Use CTRL-B to change the setting to one of four options:

1. Vertical and horizontal borders

2. Vertical borders only

3. Horizontal borders only

4. No borders

Transparency:

And finally in the category of “Why would you ever need this?” we have the transparency option. We added this in the original version of BatchPatch simply because we could and it seemed kind of fun at the time, so why not! Clicking on the tiny arrow icon in the lower right corner of the BatchPatch main form will reveal a slider that can be used to control the level of transparency in the BatchPatch window.

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