[doug]

Considering that you can see the IP in the ‘ping reply’ column when you ping a host, and that you can enter an IP directly into the host column if desired, could you elaborate on why it would be beneficial to have an additional column that displays the IP? What is your use case?

Also btw fyi you can put the following syntax into either a BatchPatch ‘local command’ or into a BatchPatch ‘remote command (logged output)’ to get the result as well:

powershell.exe "Test-Connection -ComputerName $computer -Count 1 | Select IPV4Address"

Thanks.

[doug]

No need to send a screenshot. We understand the behavior. It’s not a bug, per se, but we do understand why it’s not optimal, and we’re considering ways to improve the experience and give the user the ability to update the queue with changes that are made outside of the queue, such as to a deployment like you have done.

Thanks.

[doug]

The account that is used to launch BatchPatch will be the account that launches the process on the target computer unless you specify alternate credentials for the row in BatchPatch under ‘Actions > Specify alternate credentials’ in which case those alternate credentials will be used to launch the remote process.

To execute a remote process where the exe already exists on the target computer, you can create a remote command ‘Actions > Execute remote process/command’ > Create/modify remote command 1′ with the following syntax. In this example notepad.exe will be executed. You’ll see it appear in the Task Manager processes list:

"C:\WINDOWS\system32\notepad.exe"

For installing an agent on target computers, I would generally recommend that you create a BatchPatch deployment. There are many examples posted here: BatchPatch Software Deployment

-Doug

[doug]

Thanks for sharing!

[doug]

We have no plans to remove the wuauclt.exe commands in the near future because we still have many users who use those commands for their older operating systems.

We talk about usoclient for Windows 10/2016/2019 in this blog posting from Nov 2017.

We have a built-in usoclient command under ‘Actions > Windows updates > usoclient.exe startscan‘. This is the only usoclient.exe command that we have found to have any real value, as of yet, so it’s the only one that we have included. You are certainly welcomed to add your own additional ones. And if you think that any other usoclient commands are useful/valuable, we’d love to hear how and why, so please feel free to explain. It’s certainly possible that you know something that we don’t, and we make adjustments to the software all the time based on customer feedback.

However, we also make BatchPatch customizable so that it can be tweaked by the end-user because not all users have the same needs and desires, obviously. If you think there is a particular command that is not currently included out-of-box but should be included, let us know. If we think it’s a command that many users would find valuable, then we will add it. If not, then you can simply add it to your own BP installation.

You can hard-code your own remote commands as explained at the following link. Once you have added a command, it appears in the BatchPatch menu just like out-of-the-box commands do, so you don’t need to add it every time you launch the app: How to Hard-Code Your Own Custom Commands in the BatchPatch Actions Menu

[doug]

1. The saved queues are ordered by clicking on the column headers. You can order alphabetically by ‘Title’ or by ‘Queue’

2. We’ll fix this. Thanks.

[doug]

I just treat the BP system independently of all other systems. I don’t touch the BP system until everything else has been patched. Once everything else has been completely patched and rebooted, then I use BP to patch the BP system. I then manually reboot it.

[doug]

No. If you reboot the system that BP is running on you will kill everything that is currently happening in BP. Nothing will automatically resume after the machine comes back up. Using BP to reboot the BP machine is not a great idea. Also, depending on which method you use to initiate the reboot, and depending on which OS is running on the BP system, Windows will in most cases prevent the self-reboot from occurring in the first place.

[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.

[Author]

Posts