[doug]

Have a look at the details printed in the ‘Remote Agent Log’ column. You can also view this info in the BatchPatch.log file in the remote working directory on the target computer (default location is C:\Program Files\BatchPatch\BatchPatch.log). This will show the details of what installed successfully and what didn’t. Normally if some updates are successfully installed but others fail, then BatchPatch reports “Succeeded with errors” not “Succeeded” and not “Success”. If BP reported “Succeeded” or “Success” without mentioning any errors, then probably what you are seeing on the computer is not related to the work that BP performed.

[doug]

This will be fixed in the next release. In the meantime you can avoid that issue by launching the queue differently. Go into the Job Queue window, select the desired queue, and then select ‘Execute now.’ The confirmation window that appears will not contain the entire queue contents, so it will fit on the screen without issues.

[doug]

Thanks for the feedback and suggestions.

[doug]

Yes. In the grid synchronizations window there is an option in the lower-right corner to ‘Exclude hosts from synchronizations’

Host names included in the exclusions list will be excluded from synchronizations executed for the current BatchPatch grid.

This means that if a host name exists in an OU or group that is linked to the current BatchPatch grid, and if the host name is also included in the exclusions list, then that host name will be ignored during synchronizations. It will not be added to the BatchPatch grid.

Similarly, if the host name exists in the current BatchPatch grid, and if the host name is included in the exclusions list, then that host name will be ignored during synchronizations. It will not be removed from the BatchPatch grid.

[doug]

Yes, you can use the ‘Row Template Configurator’ for that.

https://batchpatch.com/using-a-row-template-to-automatically-apply-tasks-to-new-rows-in-a-batchpatch-grid

https://batchpatch.com/using-the-row-template-configurator-to-automatically-apply-job-queues-and-scheduled-tasks-to-new-rows-when-they-are-added-to-the-grid

https://batchpatch.com/automatically-apply-scheduled-tasks-job-queues-deployments-and-commands-to-new-rows-with-the-row-template-configurator

[doug]

https://batchpatch.com/batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx

[doug]

You found a bug. Thank you for reporting this. We will have all four of those job queue items fixed in the next release.

In the meantime we have a few custom script integration examples posted at the following links. These examples are written in vbscript, not powershell, but they might help give you some ideas for how you could accomplish your goal. For example if you want to have the job queue check for file existence or file version on a file that is currently failing due to the parenthesis bug/issue you described above, you could use a script that checks for the existence of the file and then returns 0 or 1 depending on whether or not it finds the file. Then in BatchPatch you could create a Deployment job to execute the script, and then insert that Deployment job in the Job Queue right before using the step ‘If previous action failed/errored (returned non-0), goto label:X’ or ‘If previous action was successful (returned 0), goto label:X’

https://batchpatch.com/advanced-script-integration-with-batchpatch

https://batchpatch.com/batchpatch-custom-script-integration-install-windows-updates-only-after-stopping-a-specified-service

https://batchpatch.com/advanced-script-integration-with-batchpatch-part-2

[doug]

My guess is that probably when you modified the XML directly the issue was created due to line breaks or spaces. Either you accidentally created a space or line break without realizing, or your text editor uses a different line break format than what BatchPatch is anticipating, causing things to appear correct to you as the viewer, but in the actual data of the text file it’s coded differently (for example ‘\n’ vs ‘\r\n’).

I would suggest that instead of creating a brand new job queue from scratch, you simply use your existing job queue as a template for the new queue. So if you go into the job queue window and load your saved queue by double-clicking the saved queue in the list of saved queues (or by clicking the double-left-arrow), you can then give it a new title, and you can replace just the specific steps/lines that you care to replace. Then save it. This way the old queue will still be there, and now the new queue will also exist. This should be quicker than exporting to XML, modifying, importing. And it will also ensure that things work properly in the new queue.

[doug]

Thanks for the suggestion. Indeed it’s something that we have considered, but there are some significant concerns that it raises with regard to permissions and security, so I don’t know if it’s something that we will implement in the future or not. There likely isn’t a “safe” way to do it, as the executing user will still ultimately have local admin permission on all target computers.

[doug]

Oh ok, so you mean the column name is ‘Host’ but the variable name is $computer, not $host? Yeah, I can’t remember off the top of my head why we did this, but I think there was a good reason for it. I’ll follow up with the team to see if we can add an alias for $host, but I’m not sure if it will be doable or not.

$notes2 works for the ‘Notes2’ column in the same way that $notes works for the ‘Notes’ column. I’m not quite sure what you mean when you say “$notes2 just outputted 2”.

The icons used on the toolstrip can not be customized. There is a different icon for ‘local command’, ‘remote command’, ‘remote command (logged output)’ etc, but if you have two of the same type of command they cannot currently have different icons. We have been discussing adding the ability to customize per command, but it’s not currently possible, and I’m not sure if/when it will become possible. One thing you can do now that help eliminate the confusion is use ALT-LeftClick drag to move icons around on the toolstrip, so that you can customize the order of icons however you want. This way you can separate the buttons to help eliminate the confusion of having two same icons right next to each other.

[doug]

Deployment, Remote Command, and Local Command all support $notes, $notes2, $description, $category, and $location in addition to $computer

When you say “Tried $notes however it’s not standardised as BP that pulls hosts across as $computer” I’m not quite sure what you mean.

-Doug

[doug]

I think you are correct that the only release channels for “Security Only” updates for .NET are the Microsoft Update Catalog and Windows Server Update Services (WSUS). SCCM gets these updates because SCCM is installed with and uses its own WSUS. To get these updates with BatchPatch you have two options.

1. Install a WSUS to use in conjunction with BatchPatch. BatchPatch can utilize any existing WSUS *except* for a WSUS that is currently in use with SCCM. This is because SCCM basically completely takes over the WSUS, so it can no longer be used as a standard stand-alone WSUS. However, you can install a new WSUS, if desired, and you can use that with BatchPatch. The problem with this approach is that if you are already using SCCM, your computers are going to be pointed to it in group policy, and to then have your computers utilize the separate WSUS just for ‘spot cleanups’ would require you to modify the group policy (or the underlying registry values) temporarily on those computers. This probably isn’t the greatest approach.

2. You can manually download the desired updates from the Microsoft Update Catalog, and then using the BatchPatch ‘Deployment’ feature you can easily deploy those updates to the target computers as needed. This is what I would recommend, and you can use the following two tutorials to see how it’s done:

Remotely Deploy a Standalone .MSU Update to Multiple Computers

Remotely Install Multiple .MSU Files (or .MSI and .MSP files) to Numerous Computers

[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

[Author]

Posts