[doug]

I’m sorry I hadn’t given you a more in-depth reply to the email. I think there was just a misunderstanding – I had replied thanking you for sharing the screenshot and resolutions/DPI settings, which we needed to see so that we could confirm that we understood what you were describing, and which we do now understand. It’s just a matter of having a large job queue + low screen resolution, so the confirmation dialog doesn’t fit on the screen. Nothing more to it. The way to work around it for now is to simply do what you are already doing and execute the queue directly from the job queue window or increase your screen resolution so that the window fits. We are considering the ways that we might address this in a future build. And as mentioned previously, we will consider your other suggestions for a future build. Thanks again.

[doug]

I’m happy to hear that you love the app! That’s great news.

You said “However, my Job queue is set to disable cached mode when the previous action (download + install) fails but its not caching it.”

It’s hard for me to decipher exactly what you mean here. My best guess is that you mean to say “it’s not catching it” (as opposed to “caching it”), and you mean that the ‘Label:disable-cache’ is never getting executed. Is that correct? If I’m understanding correctly, that would make sense to me. BP is looking for a failure where the action fails to execute altogether. In the case that you’re describing, BP executes the action successfully, but inside that action at least one update fails to install. We don’t consider a failure to install an individual update a failure to execute the action. A failure to execute the action would occur if, for example, the target computer was not reachable at all, or if the search for updates failed to execute. But in this case the overall process of checking/downloading/installing runs to completion, but one of the updates fails to download/install.

For your situation I would recommend that you simply do not use cached mode at all in the first place. If you’re going to be disabling cached mode for just that one update each month, there is little reason to use cached mode in the first place anyway, as that one update is the large, cumulative update. The issue with getting that particular update installed with cached mode enabled is not something we have any control over at this time. Microsoft would have to change the url structure in the metadata in order for that update to be installable under online cached mode. (more details about that situation here: cached-mode-and-updates-not-downloading-to-the-local-update-cache-directory)

Another option is to change your job queue to something like this:

(assuming you have cached mode enabled globally)
-Download and install
-Reboot
-Disable cached mode
-Download and install
-Reboot

This would give you what you want. It wouldn’t trigger based on a failure but it would effectively give you what you need because you’ll install the updates that are able to install with cached mode enabled, and then you’ll disable cached mode and install whatever updates are remaining.

As for anything that we can do/change in the code to cause the ‘If previous action fails’ method to detect the process as a failure when one of the updates fails to download/install even though the overall process itself executes successfully to completion… I’m not sure. We’ll have to discuss here to see if making any changes to this behavior is something that we think makes sense to do. Currently the behavior is expected/correct. I understand why it might not be what you were expecting to happen, but it isn’t a bug per se. We’ll talk about ways that we might be able to improve this experience or add more flexibility/control. Thanks for highlighting it.

-Doug

[doug]

Thanks. I’ve emailed you about the ‘execute queue’ situation, asking for you to send me a screenshot, because I’m not quite sure what you’re describing.

We’ll consider your feature suggestions for a future build.

-Doug

[doug]

Please see the following links. 99.99% of the time it’s due to a firewall. I know you said there is no firewall or AV blocking, but there isn’t a ton else that it could be. ‘RPC server is unavailable’ is the message that you would get if you put a non-existent host into the grid. It means that BP isn’t getting a response at all. It could be a DNS issue, but it’s almost always due to a firewall. Please review the following links carefully. Your test of port 135 indicates that it’s probably a firewall issue and that while 135 is allowed, that is not the only port that BP requires, so it seems likely that there is a firewall blocking one/some of the other ports that BP requires. Note, it doesn’t have to be a software firewall or AV running on the target computer. It could also be a network level firewall in between the BP computer and the target computer. The ports link below explains about WMI using dynamic ports.

https://batchpatch.com/troubleshooting-common-errors-in-batchpatch
https://batchpatch.com/batchpatch-troubleshooting-guide
https://batchpatch.com/using-batchpatch-with-windows-firewall
https://batchpatch.com/batchpatch-ports

[doug]

Great. Which update did you install to resolve? How did you determine which one to try?

[doug]

This is a Windows Update error, not a BatchPatch error:

-2145116137 == 0x80242017

0x80242017 WU_E_UH_NEW_SERVICING_STACK_REQUIRED The OS servicing stack must be updated before this update is downloaded or installed.

I would suggest that you manually download the latest servicing stack update for that OS and apply it directly (either manually on the target computer or by using the ‘Deployment’ feature in BatchPatch). It would also be worth checking if there is a more recent Windows Update Agent version for the OS too. Once you have updated both of those directly, you should be able to use BatchPatch (or the Windows Update control panel on the computer) to apply updates to the target.

-Doug

[doug]

OK thanks. Please post back to this thread with your findings.

-Doug

[doug]

The following link shows every possible reason that we have ever seen for why there could be a discrepancy between what the Windows Update control panel shows as compared to what BatchPatch shows.

Based on everything you’ve said, I wonder if you have GPO in place (mentioned in my previous posting above, and should definitely be checked by you to confirm if that’s the reason for what you’re seeing or not) that is deferring feature updates, and that Windows is presenting the feature update in the Windows control panel as an optional/”seeker” update. Optional “seeker” updates are described in item 8 of the link below. BatchPatch can find these updates too, if needed. If 1909 is being delivered as an optional update, then it implies that you *do* have GPO in place that’s set to defer feature updates.

batchpatch-and-the-windows-update-control-panel-report-a-different-number-of-available-updates

[doug]

The version of BatchPatch (evaluation vs full) has no bearing on which updates are visible. All versions of BatchPatch query the Windows Update Agent on the target computer to ask it which updates are available for download/installation. In your case the Windows Update Agent is not reporting the 1909 feature update as available for download/installation. What are you describing has nothing to do with BatchPatch. You would see the same if you looked at the Windows Update control panel directly on the target computer. There are a couple main reasons this could be happening. It’s possible that there could be some other reason, but these are the two primary reasons we would expect to see such behavior:

1. Are you using WSUS, and are your target computers pointing to it? If yes, then you’ll need to make sure that the WSUS has downloaded the update in question, and that the update is approved for installation on target computers. If not, then target computers pointing to that WSUS will not see it as an available update.

2. Group policy or local policy could be configured to defer receiving feature updates. The particular policy that controls this is under Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business > Select when Preview Builds and Feature Updates are received

[doug]

You can send a message to users that will pop up on their screens:

notify-users-of-upcoming-reboot-or-other-patching-activity
inform-users-before-applying-updates-and-rebooting

However, the popup message will not offer an option to reboot directly from the popup. The user would have to use the normal reboot method for the OS. The user will also be able to close the message.

One option would be that you can continue to pop the notification to the end user in a loop, at your desired time interval, until they perform the reboot. To do that you would create a job queue something like this:

1. label:YourCustomNameGoesHere
2. Send custom message to end user
3. Wait 60 minutes
4. If ‘Get pending reboot status’ returns TRUE, goto label:YourCustomNameGoesHere

using-the-job-queue-in-batchpatch-for-multi-step-execution

[doug]

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

[doug]

You may match on title text instead of KB ID. Matching is done by comparing the update title to the text of each item in the list. If the text of any item in the list is contained in the update title, the update will be excluded or hidden, depending on whether you are using the ‘exclude’ feature or the ‘hide’ feature.

To guarantee uniqueness, we recommend entering the KB IDs, but if your goal is to always exclude or hide any update with ‘preview’ in the title, then you may enter ‘preview’ into the exclude or hide list (without the quotes) instead of using the KB ID.

Excluding vs hiding:

Excluding an update means that it will just be skipped for the current action. However, it will continue to appear in the list of available updates every time you scan for updates.

Hiding an update means that it will become hidden on the target computer and will no longer appear in a search for available updates on that target computer. Caveat: Microsoft does have the ability to force a previously hidden update to become unhidden. This is not something that they do frequently, but they do it occasionally if they re-release an update under the same KB ID.

[doug]

Excellent. Glad you got it figured out.

[doug]

Thanks. We’ll consider these.

[doug]

Thanks. That makes sense… but can you explain to me why you need the IP in the first place if you already have the FQDN? In your original posting you mentioned that you want to be able to use the IP in local and remote commands, but I guess what I’m confused about is why you would need to use the IP in those commands as opposed to just using the short host name or FQDN, which you already would have in the hosts column and could use in local and remote commands as $computer?

[doug]

Pete – Did you know that you can just enter an IP address into the hosts column? Then you can use ‘Get host name’ to populate the ‘Get Host Name’ column, which would give you what I think you are looking for, which is one column with host names and one column with IP addresses, both of which are sortable.

-Doug

[doug]

It’s not an issue with the version. There must be something else going wrong. We would need the complete, verbatim error message text (not just the 1601… there is additional error text to go along with the 1601 that would explain the reason for the problem) to know what the problem is.

-Doug

[doug]

Currently, there can only be one recurring task per row. Your options are either to use the multiple tasks schedule with specific days/times scheduled (not using recurrence), or you can create 2 rows per host, with each row holding 1 recurring task.

Thanks,
Doug

[doug]

Windows 10 does not auto-refresh its check for available updates, so you would either have to wait until it eventually refreshes (unclear how long this could take, maybe even days), or you can use ‘usoclient.exe startscan’ to refresh Windows 10. More details here: https://batchpatch.com/the-windows-update-control-panel-in-windows-102016-is-not-up-to-date-after-using-batchpatch-to-install-updates

Yes you may use WSUS with BP. We have many customers using WSUS with BP, and we generally recommend it. https://batchpatch.com/batchpatch-integration-with-wsus-and-group-policy

[doug]

I believe OOBE would only ever be relevant when installing Win 10 from scratch or when upgrading to Win 10 from a different OS. I do not think OOBE is ever presented when applying a feature update to an existing Win 10 installation, regardless of the method that is used to apply it.

[doug]

Would you be willing to email us a copy of the text file? I can’t imagine how this issue could manifest under any circumstances, but it would be interesting for us to test your exact text file just to rule out any problems with that particular file.

[doug]

For many years now BatchPatch has an activity indicator in each tab header, so when activity begins in any tab, a yellow orb image/icon is displayed in the tab header next to the name of the tab. It turns red if/when hosts in the tab go offline. When activity stops in a tab, the image/icon disappears.

[doug]

You can use the option/checkbox ‘Run task immediately upon detecting target computer online‘ which is inside the BatchPatch task scheduler.

Alternatively, you could use the job queue to create your own custom loop with ‘If host is offline, goto label:X‘. Note, this item only exists in the most recent version of BatchPatch, which was released just a couple of days ago.

[doug]

This is not a BatchPatch issue. The -102 error occurs when the target computer has a problem connecting to the update server. The HRESULT value is the “reason” code. From Microsoft’s documentation:

0x80244007 -2145107961 WU_E_PT_SOAPCLIENT_SOAPFAULT
a SOAP Fault was returned by the server. See the more specific WU_E_PT_SOAP_xxxx mappings when a SOAP fault was returned by the server.
SOAP client failed because there was a SOAP fault for reasons of WU_E_PT_SOAP_* error codes.

This issue occurs because Windows cannot renew the cookies for Windows Update.

Review KB2883975 for instructions to resolve the issue.

If Microsoft’s documentation and patch at the link above link don’t resolve the issue, you should then examine your WSUS, and perhaps more specifically IIS on your WSUS.

[doug]

In BatchPatch you don’t have to do anything else for the Office updates. I don’t think you would need to do anything in Group Policy either.

The various counts that the WSUS maintains will virtually never be accurate unless you are extremely closely managing your WSUS. This is not a BatchPatch issue. You’ll find in almost any WSUS environment, regardless of which other tools are being used (or even when no other tools are being used at all), that the counts in the WSUS aren’t generally going to reflect any reality that the administrator cares about.

[doug]

Thanks. Unfortunately we aren’t able to reproduce it even on the same OS that you are using (Win 2016 build 14393.3564).

[doug]

Unclear what the cause is, but it’s pretty much gotta be something with your system/environment because we cannot reproduce it and have had zero reports from anyone else about it. My first suggestion is to update Windows. Looks like you’re still using build 1607, which for Windows 10 is very old. Second recommendation is to look at disabling any type of anti-virus or HIPS or other security software that is running on the computer. It could be the reason for the issue.

[doug]

Strange.

What is the app version under ‘Help > About’ ?

Additionally you should see an event logged in the Windows application log (in the event viewer). Please paste the entire crash/problem/error event details for me to review.

[doug]

@Jack.Roberts – yes.

[doug]

It’s a 24-hour clock.

[Author]

Posts