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

[doug]

Thanks for the suggestion. We’ll consider this for a future build. In the meantime one option that you can use that you probably weren’t aware of to reduce the white glare is the transparency slider. It’s not exactly what you’re looking for of course, but perhaps it will help a bit. In the lower right corner of the BP main window you’ll see a small arrow icon. Click that to reveal the slider, and then adjust to make the BP window more or less transparent.

[doug]

This below link has another possible resolution for this error: -102: Failed to execute the search. HRESULT: -2145107921

https://serverfault.com/questions/741083/unable-to-update-windows-server-2012

[doug]

Thanks. We’ll see what we can find.

-Doug

[doug]

Thanks. Do you know were you using CTRL-A to select all rows, then initiate the action, then click on the next grid tab and repeat? Or were you only selecting some rows in each grid? Or were you selecting all rows in each grid but using the mouse to select them instead of using CTRL-A? And what about rotating between grids? Were you doing that with the mouse by clicking on each grid tab header or were you using some other method?

Thanks

[doug]

Thanks. We are looking into it. If you figure out how to reproduce it, please share those steps here.

[doug]

I would direct you to the Microsoft documentation that describes the behavior of this policy:

https://docs.microsoft.com/en-us/windows/deployment/update/waas-wu-settings#do-not-connect-to-any-windows-update-internet-locations

Do not connect to any Windows Update Internet locations

Even when Windows Update is configured to receive updates from an intranet update service, it will periodically retrieve information from the public Windows Update service to enable future connections to Windows Update, and other services like Microsoft Update or the Microsoft Store.

Use Computer Configuration\Administrative Templates\Windows Components\Windows update\Do not connect to any Windows Update Internet locations to enable this policy. When enabled, this policy will disable the functionality described above, and may cause connection to public services such as the Microsoft Store, Windows Update for Business and Delivery Optimization to stop working.

Note

This policy applies only when the device is configured to connect to an intranet update service using the “Specify intranet Microsoft update service location” policy.

I’m not sure why you are experiencing it only on your 2016 machines. It might be the specific combination of policies applied. I would start by evaluating every single applied policy to see if any one or combination of policies is causing the discrepancy.

If you have the “Specify intranet Microsoft update service location” policy set, then you should not need the “Do not connect to any Windows Update Internet Locations” policy. However, I would suggest that you pay attention to the possibility of “Dual Scan” being enabled on your 2016 computers. I would suggest that you consider enabling “Do not allow update deferral policies to cause scans against Windows Update”.

More on Dual Scan:

dual-scan-difficulties-with-windows-update-on-windows-10-versions-1607-anniversary-update-and-1703-creators-update

deciphering-dual-scan-behavior-in-windows-10

[doug]

You can create a custom remote command in BatchPatch ( how-to-hard-code-your-own-custom-commands-in-the-batchpatch-actions-menu ) with the following syntax:

taskkill /IM notepad.exe

Then create a job queue that executes this remote command in the step before your deployment is executed. Then when you execute the job queue it will first run the taskkill command to kill your app (maybe firefox.exe or whatever), and then it will run the deployment.

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

I hope this helps.

-Doug

[doug]

A fix has now been published.

-Doug

[doug]

Thanks. We are working on it.

-Doug

[doug]

Makes sense. I would suggest you try to switch back to using PsExec (unless for some reason you aren’t able to get it working). There are two possible ways PAExec would have been in use… Either it would have been renamed to PsExec.exe and just swapped in, or it would have been specified under ‘Tools > Settings > Remove Execution > Use psexec.exe custom filepath’

-Doug

[doug]

Thanks. We are not currently able to reproduce this.

Can you tell me does the error occur every time you click OK in that window, or did it happen one time and no longer happens?

Did you update your service instance in addition to your main batchpatch.exe?

Does the software crash or does it continue to function normally despite that particular message?

[doug]

BatchPatch is generally used with PsExec, not PAExec. In rare cases if a user is having issues with PsExec he might instead try using PAExec. I’m not sure in your case why you are using PAExec over PsExec, but I assume it’s because you had problems with PsExec functioning properly. That said, I’m not completely surprised to hear that there are PAExec services hanging around on some systems… the reason I’m not surprised is because there is likely something in your environment that was creating an issue for PsExec, and it’s conceivable that the same issue that was causing an issue for PsExec is also preventing PAExec from successfully and completely removing itself from targets where it is being used. BatchPatch does not remove PsExec or PAExec. They remove themselves immediately after they complete execution, but there can be cases where they fail to remove themselves completely/successfully.

You can manually delete a service with the following syntax at the cmd prompt on the server where the service remains:

sc delete ServiceName

[doug]

For all other -102 HRESULT values, please see batchpatch-error-102-failed-to-execute-the-search-hresult-xxxxxxxxxx

[doug]

For deploying Windows 10 feature updates/upgrades, I would generally recommend following the method outlined here:

https://batchpatch.com/deploying-windows-feature-upgrades-remotely-to-multiple-computers

[Author]

Posts