[doug]

Thanks. I suspect your issue is arising due to your group policy settings. Most likely it would be from the use of either the “No auto-restart with logged on users” policy OR possibly the use of option 4 setting in the “Configure automatic updates” policy OR possibly the combination of the two. I would suggest removing the “No auto-restart with logged on users” setting and also changing the “Configure automatic updates” setting from 4 to 3. After the machine has received the new/updated policy settings, try once again to run the feature update process from BP (you’ll probably need to run it again from scratch as if you had never run it previously). I think there is a good chance that the feature update will now apply without prompting you to schedule it. Let me know how it goes.

[doug]

If you’re interested in solving this I would ask you to please review my posting above about group policy objects, and please then let me know the answer to that question, as it might be what we need to figure out what is going on. Thanks.

[doug]

I just realized I never asked you which version of BatchPatch you’re using. Are you using a version of BP that was released prior to 20200425 ? If yes, that’s your problem. The ability to install Win 10 feature updates through the normal Windows Update actions in BatchPatch only arrived in 20200425.

If you’re already using 20200425 or newer, then I’m sorry to say at the moment I’m just not sure what is causing your issue. If you’re already using 20200425 or newer, then for now your best workaround is to instead just deploy the feature update with the method outlined here:

Deploying Windows Feature Upgrades Remotely to Multiple Computers

[doug]

@bweddell – .msu files can be installed remotely by BatchPatch. We do it all the time, and we have numerous tutorials posted on our website that demonstrate how to create a deployment for .msu files. It’s unclear to me what could be causing you to get an exit code 5 for your .msu deployment. I would suggest trying to install the .msu manually at the command prompt of the desired computer. Then see if it spits out a more useful error text that explains why it won’t install. Most likely if you can’t install it with BP, then it will also fail to install when you try to deploy it manually at the command prompt without using BatchPatch. It could be something like the .msu file that you are trying to deploy to the target is not compatible with the OS version or architecture.

[doug]

Can you check your group policy settings?

Which policies are enabled under these locations?

Computer Configuration > Administrative Templates > Windows Components > Windows Update

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

I’m especially wondering if you have configured “Select when Preview Builds and Feature Updates are received” and if you have the item inside that policy, “Pause Preview Builds or Feature Updates starting:“, configured with a date? However, I’d still also be interested to know which other policies are configured too in addition to this particular one. Thanks.

[doug]

Thanks for the additional info and screenshot. At the moment I don’t know if something has changed in 1909 as compared to the previous Win 10 versions, or if there is something specific to your environment that is causing this. We’ll do some testing here with 1909 to see what we come up with.

What is the version of Win 10 that is on the machines now? I know you are upgrading to 1909, but which version is running before 1909 is applied?

Also, which Windows Update group policies do you currently have applied to these targets?

-Doug

[doug]

Laurie – I’m actually not quite sure what you’re describing. When you use BatchPatch to download/install the feature update by selecting the ‘include upgrades’ option, it initiates the download/install process. The process does require a reboot before Windows will actually perform and complete the installation, so I’m not sure if you simply didn’t ever initiate the reboot or if you’re describing something different. Under normal circumstances when installing the feature updates with BP you would make sure that the update is showing in the “Check for available updates” and then you would select the “include upgrades” option to get BatchPatch to initiate the download/install when you select the BP action to ‘Download and install updates plus reboot if required’. Then upon reboot, the computer would complete the installation. And of course you can review the ‘Remote Agent Log’ column to ensure that BatchPatch executed the download/install of the feature update (or you can use ‘Actions > Windows Update > View BatchPatch.log’). If you don’t see the feature update in the list of updates that BP downloaded/installed, that would explain why you are not seeing it be installed by BP. I’m confused and unsure about what you are doing/experiencing.

The other way that you can use BatchPatch to deploy feature updates is described here: Deploying Windows Feature Upgrades Remotely to Multiple Computers

[doug]

This is peculiar. I don’t know anything about Baramundi, but if it’s installing a Windows KB, Windows would/should log it to Win32_QuickFixEngineering. Perhaps the behavior is different in Windows 8.1, but I would expect that to be due to Microsoft, not due to Baramundi. Also, it still almost seems like the update is not even installed because BP really should be able to uninstall it with one of the uninstall commands. Between the fact that you don’t see it in Wind32_QuickFixEngineering and that you can’t uninstall it with the default uninstall command in BP, I have to question if it’s truly even installed. I don’t know what to make of it. If you get to the bottom of it, please report back here what you learned and how you resolved it.

Thanks.

[doug]

How are you determining that the KB is, in fact, installed on the client?

BatchPatch has two methods for checking the update history on targets:

Generate consolidated report of update history (Windows Update Agent)
Generate consolidated report of update history (Win32_QuickFixEngineering)

Neither of the above actions show the KB that you say is installed on the targets?

And neither of the ‘Uninstall individual update’ commands in BatchPatch works successfully?

I’m sorry to say I don’t know what to suggest to you. It’s not clear to me what could be happening here. It seems like maybe the update is not actually installed despite the GUI appearing to indicate that it is installed. But if it is installed and BatchPatch is not able to uninstall it with the default uninstall commands, then I would suggest you either manually uninstall the update on each desired target computer, or write your own command to perform the uninstallation. Once you have a a command that works at the cmd prompt of a computer to remove the desired KB, you could port that command into a BatchPatch ‘remote command’ to then execute across the remaining targets.

-Doug

[doug]

Recurrence is not available for the multiple tasks schedule. It is only available for singular scheduled tasks. You have two options for accomplishing your goal:

1. Manually schedule in the multiple tasks schedule all of the desired run dates/times.

2. Add a new/separate row for each task that you want to be recurring. Create a singular scheduled task with recurrence for each row.

If you have a grid synchronization task that is being used to remove other rows, you can prevent desired rows from being removed by either using ‘Synchronize grid with directory (add hosts only)’ so that your synch task never removes any hosts, or if you want to remove hosts but just don’t want to remove particular hosts then use the ‘Exclude hosts from synchronizations’ option that is available in the lower right corner of the Grid Synchronization Settings window.

[doug]

Thanks, Rich. Please do reply to this thread if/when you have more info. I’m very curious to know if purchasing ESU does the trick.

-Doug

[doug]

Hi DJ –

1. We do usually post some notes on the website in a blog posting with each new version, depending on the nature of the particular release. We plan to post something this week for the version released on Friday. It just hasn’t been published yet. Usually the blog posting will follow the actual release of the new build by several days up to about a week.

2. We don’t publish file hashes. We *do* sign the BatchPatch.exe, which is superior to just publishing file hashes. Scott just wrote a posting, which is now also linked off of the download page, that explains why digitally signing a file is superior to publishing a file hash. You can see it here if you’re curious:

Verifying the Authenticity and Integrity of BatchPatch.exe

[doug]

I wouldn’t be surprised if certificates is one of the methods that Microsoft uses to prevent people who didn’t pay for ESU. I found a wsusscn2.cab from July 2019, and I was able to use it successfully to search for updates on a Windows 7 target. However, when I use the current wsusscn2.cab from Sept 2020, I get the same certificate error that you got.

0x800B0109 -2146762487 CERT_E_UNTRUSTEDROOT

A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider

I think there is a pretty good chance that if/when you pay for ESU, the first thing they do is give you an update that updates your certificate store so that you’re able to continue updating the OS. This is just an educated guess. I can’t say for sure.

[doug]

I don’t know if any of the client triggers will do what you want or not. We don’t use SCCM. We implemented all of the available SCCM client triggers as a convenience to SCCM users, but the details of what the client triggers actually do etc has nothing to do with BatchPatch, so it’s not something that we can provide support for.

[doug]

Triggering ConfigMgr (SCCM) Client Actions Remotely

[doug]

If they are fine when connected to the LAN and are only not working when using DirectAccess, then it seems pretty clear that the issue is with your DirectAccess configuration. I don’t have experience with DirectAccess, so I’m not able to provide much guidance, but based on some very quick and minimal research it appears you have to configure “Manage Out” capability for DirectAccess in order to be able to remotely manage clients from within the LAN. I wouldn’t be surprised if you also have to configure firewall rules specifically for when using DirectAccess.

Troubleshooting Common Errors in BatchPatch

[doug]

Please see this link:

Review the section under ‘Error -102: Failed to execute the search. HRESULT: -2147012867‘

[doug]

We’ll see what we can do.

[doug]

In that case then you should just keep the deployment files on the BP computer or in the same network as the BP computer so that when BP copies the files to target computers it only copies the files in one direction. There is not currently a better or more efficient option available.

[doug]

You don’t have to install BatchPatch on every target computer. The suggestion I made was to install a single instance of BatchPatch in the same geographic location as the target computers so that deployment stays local to the BatchPatch instance.

Alternatively if you keep the BatchPatch installation in a network that is remote to the target computer, then at a minimum you should also keep the deployment files in the same network as the BP installation so that when the deployment runs, it copies files only in a single direction. A better/faster option will be to do what I described previously, which is to install an instance of BatchPatch in the network where the target computers are located.

[doug]

Thank you for your feedback. At this time it is the BatchPatch computer that performs the copy, so for max performance in the scenario that you describe, you would need to run an instance of BatchPatch on the target network, and have that instance perform the deployment.

Thanks.

[doug]

I need more information, please. If you have active support, please contact us directly to work through the issue. That way we can have you send us log files and a grid export for review, which we can’t really do effectively through this forum. Then we should be able to determine exactly what’s happening. Otherwise I’ll just have to take a couple guesses:

The problem you are encountering may be the issue described here: Online Cached Mode Fails to Download Update: Illegal characters in path. HRESULT: -2146233079

I know you said that the issue occurs even when cached mode is disabled, which would indicate that the above link will not help you, but please make sure to read through it carefully and assess your situation before concluding that it’s not the issue that you’re having. However, if the above link does not describe the issue that you’re having, then in that case it might be that you just need to perform the download and install operations in a single action instead of in two separate actions. That is, perform the operation as the single “download + install” action in BP instead of executing “download” and then separately executing “install.” We have very occasionally seen where Windows Update behaves unexpectedly and needs to have these operations executed together instead of separately.

[doug]

Thanks. I just replied to your email. It really doesn’t make any sense to me how/why it would fail only when executed as part of the advanced sequence, but I’ll have a better sense of things after I get the requested items in the email. Let’s switch over to email from this point forward. I will come back and update this thread if/when we figure out what’s going on.

[doug]

Without being able to see the exact detail of everything that is happening, it’s hard for me to know what might be going on. If you have active support with us, you are welcomed to reach out to us directly for troubleshooting assistance. That way we would be able to view more details about what is happening. Otherwise my best suggestions are as follows:

1. You said you’re running a local command. Local commands execute on the BatchPatch computer, not on the target computer. It’s unclear to me exactly how your queue is structured, but if you are running a local command to execute the script, then I assume the script is making a remote call to the target computer. Since you’re using powershell, maybe check the powershell permissions and execution policy to make sure that what you’re doing is not being blocked.

2. Maybe just try a different method for stopping the service. For example instead of using a local command that calls a custom powershell script that makes a remote call to the target computer, maybe just try a remote command directly from BP with the following syntax, substituting the SQL service’s caption instead of ‘DNS Client’ (I don’t know what the exact SQL caption naming is off the top of my head):

WMIC SERVICE where caption='DNS Client' CALL stopservice

[doug]

See section on “RPC server is unavailable” here: Troubleshooting Common Errors in BatchPatch

[doug]

If the IP works but name does not work, it could be an issue with your DNS.

However, you need to look at the *reason* that is printed at the end of the error message to evaluate why the error occurred in the first place. When error 1601 appears it says *what* happened: “Failed to retrieve WMI info”, and then immediately after that it says *why* it happened. For example, here are just two of the possible ways it might appear:

Error 1601: Failed to retrieve WMI info: Access is denied (Exception from HRESULT: 0x80070005)

OR like this:

Error 1601: Failed to retrieve WMI info. The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

[doug]

I don’t think this is a common problem at all. In fact, maybe that’s one way to convince management. Explain to them that it’s highly unusual to have 200+ servers with no dedicated maintenance window. EVERY company needs a maintenance window to do maintenance. Just like you need to take your car to the mechanic periodically to do preventive maintenance. I have never heard of a company with 200+ servers and no maintenance window. They are asking for trouble.

[doug]

FYI we just tested this: You can use the following syntax inside of a single ‘Remote Command’ in BatchPatch:

NET STOP wuauserv & MOVE C:\Windows\SoftwareDistribution C:\Windows\SoftwareDistribution.old & NET START wuauserv

If you then save the command, you’ll be able to trigger it directly from the BatchPatch menu at any time.

[doug]

We have never seen nor had anyone report these two errors:

0x80244017 -2145107945 SUS_E_PT_HTTP_STATUS_DENIED Http status 401 - access denied

SUS_E_PT_HTTP_STATUS_DENIED seems like it would be a result of a permissions issue on your WSUS server’s IIS instance. I’m not sure how/why it would be fixed by resetting Windows Update on the target, but I’m glad that worked for you.

0x80244010 -2145107952 SUS_E_PT_EXCEEDED_MAX_SERVER_TRIPS The maximum allowed number of round trips to the server was exceeded

I don’t quite know what to make of SUS_E_PT_EXCEEDED_MAX_SERVER_TRIPS. It’s very peculiar. My guess is it would either be related to your WSUS server’s IIS configuration, or perhaps it could be the result of some weird network behavior or problematic routing configuration.

[doug]

We’ll consider this.

FYI you could also put this into a 3 line bat/cmd file. Then create a BP deployment to deploy that bat/cmd file whenever you want. Or you could make it a powershell script and either create a deployment for it the .ps1 file, or don’t even put it in a .ps1. Instead you could just combine the three lines into a single line with each command separated by a semi-colon. Then run it as a BP remote command.

-Doug

[Author]

Posts