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

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.

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 what they do or if they work as described.

In a future version of BatchPatch we will likely add some hard-coded options for UsoClient.exe to be easily executed, but in the meantime if you want to use BatchPatch to execute UsoClient.exe on target computers, you have a couple of options.

First, I would recommend that you hard-code the command (UsoClient.exe startscan) into your BatchPatch installation 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

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

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

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

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.
Posted in Blog, General, Tutorials | Tagged , , , , , | Comments closed

Deciphering “Dual Scan” Behavior in Windows 10

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 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. The simplest way that we have found to determine if “Dual Scan” is *actually* enabled is as follows:

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"

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

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

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’

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.


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:

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.

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

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


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

Understanding the ‘Local Downloader’ in BatchPatch ‘Cached Mode’ and ‘Offline Mode’

One of the questions we receive sometimes is about the local downloader. While using BatchPatch ‘cached mode’ and/or ‘offline mode’ to download and install Windows updates on target computers, it can appear sometimes that everything is queued unnecessarily. One row will be executing the local downloader while other rows sit in a queued state, apparently not doing anything. Below I will explain why this happens and why it’s intentional and also not problematic and not “slow.”

The first thing to consider is that when BatchPatch is operating in ‘cached mode’ and/or ‘offline mode’ all updates that are needed by target computers are downloaded by the computer running BatchPatch, not by the individual target computers. In contrast, when running in regular/normal mode, each target computer downloads its own updates, independently, from the source update server, whether that be a local WSUS or directly from ‘Windows Update’ or ‘Microsoft Update.’

When BatchPatch is operating in ‘cached mode’ you will see ‘Executing local downloader’ appear sometimes in one of the BatchPatch rows where you executed ‘Download available updates’ or ‘Download and install updates.’ You will usually *not* see this appear in every row, and in fact it usually won’t even appear in most rows. Additionally, while one row displays ‘Executing local downloader’ you will notice that other rows might be put into a ‘Queued…’ status.

This behavior is expected / intentional, and it will not slow down your process. The reason for this behavior is because when BatchPatch operates in ‘cached mode’ the BatchPatch computer is responsible for downloading all required updates to its local cache before it can push those updates out to target computers. We intentionally do not execute more than one local downloader at any given time because we do not want the BatchPatch computer to unnecessarily download the same update more than one time. After all, this is one of the primary purposes for using ‘cached mode’ in the first place. If you are downloading/installing updates on numerous computers, in most cases you are going to be applying the exact same update to more than one computer. If each row in BatchPatch executed the local downloader simultaneously, then in the large majority of cases each row would instruct BatchPatch to download many of the same updates that are already being downloaded by another row. The most effective way to handle this situation is to prevent more than one local downloader from executing at any given time.

Imagine that you have 100 computers all requiring mostly the same updates to be installed. It’s possible that the list of applicable updates is not identical for each computer, but generally speaking when dealing with a group of computers on a network, in most cases there will be a lot of overlap in terms of which actual updates are required for computers. If you select all 100 rows/hosts and then initiate ‘Download and install updates’ with ‘cached mode’ enabled, the first row that starts executing will be the one to execute the local downloader. Other rows will be queued while the local downloader executes. The BatchPatch local downloader will then download all of the updates needed for that particular host to the local cache directory. As soon as the local downloader completes for that row, the next row will check the cache directory to see if the updates it requires are already downloaded. If it finds the updates that it needs, then it will not execute the local downloader because the updates it needs are already downloaded to the cache. The process for it to check the cache and move on to the next step happens almost instantaneously if the updates already exist in the cache. However, if one or more updates has yet to be downloaded, then this row will also initiate the local downloader just as the previous row did, and then BatchPatch will download any needed updates that do not yet exist in the cache.

When the process outlined above is executing, typically what you see in the BatchPatch console is a period at the beginning of execution where most rows are doing nothing and show ‘Queued’ while just one row executes the local downloader. However, once the first row completes the local downloader process, all other rows will begin processing. This is the most efficient way to handle this process while ensuring reliability. So, while it may seem at first like things could take forever, since it appears at the onset that only one row is doing anything, in fact things will not take forever and will actually move quickly once the first local downloader completes. If you encounter this situation, please be patient and wait for the local downloader to finish downloading updates to the local cache. Once that process has been completed, in most cases you can expect everything else to move quickly from that point forward.

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

Remotely Upgrading Windows 10 to the ‘Creators Update’ version 1703 (or to the ‘Anniversary Update’ version 1607)

At the time of this writing Microsoft does not currently enable/allow remote silent deployment of Windows 10 feature upgrades (like the ‘Anniversary Update’ version 1607 or the ‘Creators Update’ version 1703) through the normal channel that BatchPatch uses to apply Windows updates. It’s true that if you use the normal Windows Update control panel interface to manually apply updates on an individual computer without the use of BatchPatch, then you will be able to successfully install the Windows 10 feature upgrades this way. However, using this method you would have to go to each target computer individually to manually apply the available updates through the control panel, which of course is far from optimal. If you want to use BatchPatch to remotely deploy Windows 10 feature upgrades, then you may use the method outlined below.

Deploying Windows 10 Feature Upgrades Remotely with BatchPatch

  1. The first thing that we need to do is obtain the installation media, ideally in ISO format. We accomplished this by running the Windows 10 Media Creation Tool, but if you have a volume licensing agreement with Microsoft then you ought to be able to obtain the ISO media through that channel, and then you can skip down a few steps in this tutorial for deployment instructions. With the Windows 10 Media Creation Tool you cannot select the specific version of Windows for which you want to obtain media. It seems that when you use the Media Creation Tool to create Windows 10 media you will always get the latest version of Windows 10 available, so keep that in mind. The Windows 10 Media Creation Tool is available here.
  2. To run the media creation tool you must be logged on to the computer as a local administrator. It is not sufficient to be logged on as a normal user and use ‘run-as’ to run the tool as an admin user. For whatever reason if you try to do that, the tool will not let you proceed until you actually log on to the computer as the admin user.
  3. When you run the tool you will have the option to either Upgrade this PC now or Create installation media (USB flash drive, DVD, or ISO file) for another PC. Select the Create installation media option, and then click Next.
  4. At the next prompt you will be able to select the language, edition, and architecture. Then click Next.
  5. Finally, select the option for ISO file and click Next.
  6. At this point you will be prompted to choose a location on disk to save the ISO file. Do that and then wait until the download has completed.
  7. Once the ISO file has been obtained, the next step is to extract its contents to a directory that you specify. I used 7-zip to accomplish this, but you can use whichever extraction tool you prefer.
  8. After you have extracted the ISO you should have a directory that contains the required installation files.
  9. At this point we can setup the BatchPatch Deployment. Select Actions > Deploy > Create/modify. In the Deployment interface, select the setup.exe (from the extracted contents of the ISO) as the file to deploy, and make sure to check the ‘Copy entire directory’ box and the ‘Leave entire directory’ box, so that when the target computer is rebooted multiple times during the upgrade/installation, it still has access to all of the files required for the upgrade. Additionally you need to add the following parameters:
    /auto upgrade /quiet

  10. When you are ready you can either save the deployment to execute later by using the double-right-arrow ‘>>’ button, or you can execute the deployment now for the currently selected rows in the BatchPatch grid by clicking the Execute now button. The deployment will take some time because BatchPatch has to copy multiple GBs of data to the target computers before it can execute the upgrade. When BatchPatch shows Exit Code: 0 (SUCCESS) for a given target computer you should expect that the target will still be working and will still reboot at least one time but possibly multiple times while Windows is upgraded and configured on the target, so be patient and let it do its thing!
Posted in Blog, General, Tutorials | Tagged | Comments closed