[doug]

When using cached mode, the updates are downloaded by the computer that is running the BatchPatch console, not the target computers. That’s basically the whole purpose of cached mode. It sounds like maybe you’re just running out of space on your BatchPatch computer in the local update cache directory location. While I would expect it to throw an error if that were to happen, maybe it isn’t. At the moment I’m not sure exactly how it would behave in that situation, but I can’t think of anything else that could cause what you are describing.

[doug]

@dcri1 – The job queue already contains ‘Get pending reboot status + reboot if required (normal)’ and ‘Get pending reboot status + reboot if required (force)’.

[doug]

Please see: https://batchpatch.com/remote-software-deployment-hangs-indefinitely-how-to-resolve

[doug]

This is not currently an option. We’ll consider it for a future build.

Thanks,
Doug

[doug]

In some cases this could be caused by antivirus or other security software running on the target computer and preventing psexesvc from starting. The link below explains a possible way to get around that.

At the command prompt try using the -r switch like this and see if it works:
C:\Users\batchpatch>psexec \\Server01 -r bpexesvc IPCONFIG

Then try to enable the -r switch in BatchPatch per the instructions here:

what-to-do-when-psexec-is-blocked-by-your-anti-virus-software

If you still aren’t able to get psexec working with -r then next step would be try to disable all antivirus or similar security software running on the target, then test again.

However, it could be that there is some other type of issue with the target computer or the psexec computer. Does the issue happen with all targets or only one? Try running psexec from a different source computer and see if results are different. Else try rebooting the target computer and trying again.

If still no luck have a look at the possible resolutions explained at this link: error-1611-3-failure

[doug]

This is a generic error. We actually haven’t ever seen or heard of it before.

0x80240FFF -2145120257 WU_E_UNEXPECTED generic unexpected failure

It likely indicates an issue with Windows Update on the target computer. This is probably nothing to do with BatchPatch. I would suggest going to the computer directly without using BatchPatch, and then try to download/install Windows Update. I would expect that you’ll have the same issue. You’ll then need to address it. Once you get Windows Update working for the computer in question, then you should also be able to use BatchPatch without issues. However, if Windows Update isn’t working properly on the computer, then BatchPatch won’t be able to properly initiate the Windows Update process either.

[doug]

If you read the error message that you posted it describes the primary steps for resolution of this issue by placing psexec in the required location.

[doug]

I get what you’re saying. We are considering more conditional functionality. In the meantime I think you have at least a couple of options:

1. You could use a wait period of 20 minutes or 30 minutes instead of 10 minutes so that you always wait for long enough to give the machine enough time to completely reboot.

2. You could use ‘wait for host to go offline and come back online’ knowing that in cases where reboot is not actually required, the wait for host go offline will never be satisfied. It will wait until the global timeout for host/offline online detection is reached. At that point you can have the queue continue, if desired, or you can terminate the queue. The large majority of updates do require a reboot. But if no reboot is required then you can probably just terminate the queue because a subsequent check for updates at that point is not likely to reveal any new updates to be installed. Normally if one update would only become “available” after a different update is installed first, the update that is installed first will require a reboot. Furthermore, if you are going to be running this nightly or every other night, then I think you can probably simplify your queue to something more like:

queue option 1:
Download and install updates + reboot if required
Wait 30 minutes
Wait for host to be detected online
Start stopped automatic services
Check for available updates

or

queue option 2:
Download and install updates + reboot if required
Wait for host to go offline and come back online
Start stopped automatic services
Check for available updates

In this case for queue option 2 you could then set the global timeout for host offline/online detection to continue the queue after the timeout is reached. This way if reboot is NOT required after the download/install, then BP will wait for the timeout to be reached, and then at that point the next step in the queue will be executed.

Also, since you are planning to run the queue nightly or every other night, and since you have a “reboot if required” after the installation operation, I don’t see a reason to be checking the pending reboot status every time since you will have always rebooted if required the previous night. So realistically you can probably just eliminate that check pending reboot status. On the flip side, why would you run this nightly or every other night in the first place when updates are released monthly? Seems like overkill to me, but that’s just my opinion. Of course it’s your choice.

-Doug

[doug]

Thanks. Yes we are considering this. For the time being you can do something like this but it requires a bit of scripting. You can terminate a job queue (or not terminate it) based on the return value of a script that you integrate. The script can check for the existence of whatever you want to check for, and then return a value accordingly.

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

Here is a more complex example that involves contingent operations with multiple computers instead of all on a single target like in the example above:
https://batchpatch.com/advanced-multi-row-queue-sequence-contingent-operations-with-custom-scripts

[doug]

Thanks for bringing this to our attention. It’s a bug. We’ll have it fixed in the next release.

-Doug

[doug]

Your script with the modified If/Then statement would try to remove the key from each of
.DEFAULT, S-1-5-18, S-1-5-19, S-1-5-20. If the key does not exist in at least one of those places then I would expect it to return 2. If you want to delete the key from specific locations, then modify the script to just delete from those locations rather than leaving the script to loop through all of the subkeys.

[doug]

1. Your modification to the script is wrong. You should either leave the original If/Then statement as-is, or you should remove the entire If/Then statement. However, your modification to the If/Then statement will produce a result that is not aligned with what you are aiming to do.

2. You can lookup the return code at this link. Note, the enum is zero based, so wbemNoErr == 0, wbemErrFailed == 1, wbemErrNotFound == 2, and so on: https://docs.microsoft.com/en-us/windows/win32/api/wbemdisp/ne-wbemdisp-wbemerrorenum?redirectedfrom=MSDN

You received a return code of 2, indicating that you are trying to delete a reg key that does not exist. This is not surprising because the way that you modified the script would cause the script to the look for the key in places where it would not likely exist.

[doug]

I’m not sure that the error you posted has anything to do with drivers failing to install in the way that I was suggesting. Error 59 is a network error. So if you were updating VMWare drivers remotely then it certainly makes sense that the VM would lose connectivity while those drivers were being updated. That’s a separate thing from what I was suggesting about drivers not installing successfully via Windows Update.

ERROR_UNEXP_NET_ERR
59 (0x3B)
An unexpected network error occurred.

Yeah also it seems that in the newer OSes Microsoft doesn’t even present the driver updates anymore in the normal Windows Update control panel. At least so far as we have seen it appears to be the case that they now hide these from the user, so I guess they recognize that the driver installations through Windows Update aren’t a great method for installation.

[doug]

Glad that worked. However, it’s also worth noting that the Windows Update Agent has a lot of trouble installing the driver updates that it advertises. We generally do not recommend installing drivers through Windows Update (or through BatchPatch which utilizes the Windows Update Agent). They will frequently fail to install.

[doug]

This link explains all of the possible reasons you could be seeing this:

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

[doug]

In the future we might provide other options. For now if you want to keep that rule enabled you should consider whitelisting psexec and psexesvc, or have a look at this link which provides instructions for modifying the remote service name, which might enable you to leave everything else as-is: what-to-do-when-psexec-is-blocked-by-your-anti-virus-software

[doug]

BatchPatch does not use Win32_Product, so it cannot be compared to your custom query. They are two completely different things. As I mentioned above, if you have problems running a query through BP, the first thing to do is try the query directly on the target computer at the command prompt *without* using BP. This is very simple to test. I’m confident that your issue is related to the snippet I posted above about Win32_Product doing quite a lot behind the scenes. For this reason you will find *lots* of people on the internet describing why they never use it. My recommendation to you is to not use Win32_Product.

[doug]

When in doubt you should execute the command directly at the command prompt of the target computer rather than through BatchPatch. This would help you determine if the issue is with the command or the issue is somehow being introduced by executing through BatchPatch. In this case your command syntax looks correct to me. However, note the following warning, which I suspect is part of your issue here, from https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/aa394378(v%3Dvs.85)

Warning Win32_Product is not query optimized. Queries such as “select * from Win32_Product where (name like ‘Sniffer%’)” require WMI to use the MSI provider to enumerate all of the installed products and then parse the full list sequentially to handle the “where” clause. This process also initiates a consistency check of packages installed, verifying and repairing the install. With an account with only user privileges, as the user account may not have access to quite a few locations, may cause delay in application launch and an event 11708 stating an installation failure. For more information, see KB Article 794524.

[doug]

Thanks. We’ll consider this.

[doug]

Thanks for the feedback. What about the ‘title’ field? Is this not sufficient? Let me know.

Thanks,
Doug

[doug]

You can get the local time on a target computer by using the following command inside a BatchPatch ‘Remote Command 3’ or ‘Remote Command 4’ (logged output):

time /t

[doug]

Help > check for updates > View changelog

[doug]

[doug]

CTRL-F or ‘Grid > Find in grid…’

[doug]

OK, great. Thanks for reporting back. I’m glad you got it working.

-Doug

[doug]

Thanks. Yes we are considering this.

[doug]

Ok thanks for letting me know. Yeah that makes sense. I think you’re right it’s very likely ThinApp. Keep me posted.

[doug]

OK thanks for reporting this. We’ll look into what’s going on.

[doug]

What exactly are you clicking to produce that? It’s not clear from your screencap.

[doug]

Please see:

https://batchpatch.com/forums/x/topic/update-installation-error-on-a-windows-xp-pro-machine-in-offline-mode/

https://batchpatch.com/forums/x/topic/error-1611-199-hresult-2147221164/

[Author]

Posts