[doug]

cpabert never got back to us on this, but we recently had another user report this same issue with a Windows 7 SP1 x86 target computer when trying to use offline mode to patch it. He ended up then trying standard/default/non-caching online mode, and he got this error:

-102: Failed to execute the search. HRESULT: -2147024882

…which translates to:

0x8007000E -2147024882 E_OUTOFMEMORY

He followed the suggestion at this link and installed KB3050265, which resolved the problem. After that he was able to use offline mode successfully to apply the remaining updates to that target computer.

[doug]

Another user recently reported this same error, and he confirmed that installing KB3050265 resolved it for him. The OS in question was Windows 7 SP1 x86.

[doug]

I can’t see a reason why disabling regedit would have any impact. I just tried disabling it via GPO but it didn’t seem to impact anything in my test lab. Still worked fine without issue.

I’m not sure what could be causing your issue (aside from the guesses in my previous message). At this time the ‘Get logged on users’ method in BP does not attempt to provide further detail about the error. What I can tell you though is no one has ever reported this before, and we have never seen it occur here, so it’s definitely unusual in that regard.

In the next version of BP we’ll plan to print out the failure/error code or message text, which maybe will help point you in the right direction here for what’s going wrong.

[doug]

The ‘NO OWNER’ result is obviously misleading/confusing. We’ll fix the language in the next release. However, essentially it means that BP was not able to successfully determine the logged on user, which it does by querying process ownership of explorer.exe. We actually have not ever seen this happen before in practice, but when the code returns “NO OWNER” it is because when BP queried the target computer’s OS for information, the returned info was empty/inaccessible/invalid. The likely reasons it could occur are, in no particular order:

1. Insufficient permissions to target computer
2. WMI corruption/error/failure on target computer
3. Memory issue on target computer, possibly/probably with WMI service
4. Other/unknown issue

If rebooting the target fixes the issue, then the cause is probably 2 or 3. You could also check the event log on the target and see if it has any relevant/helpful info, though I wouldn’t be surprised if it doesn’t.

-Doug

[doug]

It would imply that something changed either on that target computer or on the BatchPatch computer (most likely the target computer’s permissions are not the same now as they were before).

The only other thing that could cause this was a bug that existed in Windows 10 version 1803 (didn’t exist in 1709 and Microsoft fixed it in 1809), so if the computers involved are Win 10 1803, then that could be the reason. In that case the issue occurred when the computer that initiated the WMI connection (would be the computer you are running BatchPatch on) with alternate credentials, it would fail with ‘Access is Denied’. The issue did not exist when using integrated security — it only occurred when using alternate credentials, and it only occurred for Win 10 1803 as the computer initiating the WMI connection.

[doug]

‘Access is denied’ is a permissions problem. More here: Troubleshooting Common Errors in BatchPatch

[doug]

Create a remote command in BP to add the desired registry key/value. The command could be a ‘reg add’ command like described here:

Microsoft’s documentation for Reg Add

Create a second remote command in BP to stop the desired service, e.g.

WMIC SERVICE where caption='DNS Client' CALL stopservice

Create a third remote command in BP to start the desired service, e.g.

WMIC SERVICE where caption='DNS Client' CALL startservice

Create a fourth remote command in BP to check the value of the registry entry, e.g.

REG QUERY "HKLM\Software\Microsoft\.NETFramework" /v InstallRoot

Then create a BatchPatch Job Queue that executes all of the four commands sequentially, with whatever desired wait periods you want added in between any of the steps that you want to wait.

https://batchpatch.com/using-the-job-queue-in-batchpatch-for-multi-step-execution

[doug]

This is not currently supported. I can’t predict the future, but currently we don’t have plans to add such capability. This might change at some point.

Thanks,
Doug

[doug]

What version of BP is this? Check under ‘Help > About’

[doug]

I don’t know what is going on with that one system, but you might try using the system file checker to try to repair any issues. What OS is it?

[doug]

Strange. I would start by deleting the wsusscn2.cab file from the target computer’s BatchPatch folder (default location is C:\Program Files\BatchPatch). Then try again and see what happens. BP will copy a fresh copy of the file, and that might do the trick but probably not.

The next thing to try is on the target computer stop the Windows Update service, then rename C:\Windows\SoftwareDistribution to C:\Windows\SoftwareDistribution.old . Then restart the Windows Update service and try again. Windows will automatically create a fresh C:\Windows\SoftwareDistribution folder. This process will wipe the Windows Update history database on the target computer because it is stored in that folder, which is not necessarily a huge deal, but it should be noted in case you care about it. If the process works to solve the issue, then you’ll just move forward with the new SoftwareDistribution folder that Windows will automatically create when you restart the Windows Update service. If the process does not work, then you can just stop the service again, rename the newly created C:\Windows\SoftwareDistribution folder to C:\Windows\SoftwareDistribution.old2 , and then rename your original C:\Windows\SoftwareDistribution.old back to C:\Windows\SoftwareDistribution. Then start the service again and you’ll be back to where you were before you started messing with that folder in the first place.

If still no luck, the next thing I would try is the solution outlined by @tinpot at this link. There is probably some file or registry corruption or some weird permissions issue on that target computer that is causing problems. The solution @tinpot posted might help you figure out what exactly is going on.

-Doug

[doug]

This bug was fixed in 2019.10.18. I assume you are using an older version. Try closing all instances of BP and then delete HKCU\Software\BatchPatch\Email\SMTPPassword or update to the latest version.

[doug]

‘Get RAM usage snapshot’ will open a column called ‘RAM Usage’ to print the result, and it will also print the same result to ‘All Messages’. Note, if you have your BatchPatch settings configured to *not* open new columns automatically, then you won’t see the ‘RAM Usage’ column appear. The result will still be printed to ‘All Messages’ in either case.

The ‘automatically unhide columns’ setting is under ‘Tools > Settings > Grid Preferences’ and by default is set to ‘allow BatchPatch to unhide columns automatically during action execution’

When you say that you’re trying to “get all my RAM data off my hosts” I’m actually not sure what you mean. BatchPatch will not retrieve the actual data that is currently sitting in the RAM… BatchPatch will retrieve the RAM usage measurement e.g. ‘11,960MB / 24,559MB’, which means that 11,960MB of RAM is being used out of a total of 24,449MB of RAM available in the machine.

[doug]

Excellent. Glad you got it worked out.

[doug]

Well I’d say you have a couple options…

OK so first I can tell you that we do not experience the same issue here with any of these files. That said, I suspect that the issue is being introduced either by the tool that you are using to extract the .iso file, or perhaps the permissions are somehow affected by the location where you are extracting the .iso file. I’d suggest trying one or more of the following things:

1. Maybe consider re-extracting the .iso from scratch. Maybe use a different tool? We use 7-zip and have no issues. Consider the location where you are extracting in case any permissions are being inherited at the time of extraction, due to the destination folder permissions.

2. Try deleting any/all files that cause this problem for you. Maybe it’s going to be the entire boot folder in your case. I’m not sure. I don’t think the boot folder is likely to be needed for the deployment to be successful.

3. Try to overwrite all the permissions/ownership on the files/folders that are causing issues for you.

[doug]

We have not encountered this issue, but I suspect you can probably just delete this file too, just like you did with the autorun.inf

[doug]

This could only occur if you had added a grid to the BatchPatch service instance (means you were using the run-as-service feature in BatchPatch), and then the service was stopped/disabled/uninstalled without ever removing the grid from the service instance. Then when you try to load that .bps file into the regular BatchPatch window, BatchPatch still thinks it is loaded in the service instance, so BatchPatch tries to connect to the service instance to load the file, but there is no service instance listening because it has previously been stopped/disabled/uninstalled.

The solution is to start/enable/install the service instance OR if you don’t plan on using the service instance then you may simply close all instances of BatchPatch, then delete this registry value: HKCU\Software\BatchPatch\Service\BpsFilesToLoad Then launch BatchPatch and load the .bps file.

[doug]

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

[doug]

Very odd, indeed. Not sure what to make of it. Glad you got things working.

-Doug

[doug]

When BatchPatch does a ping it really is the same kind of ping that gets sent at the cmd prompt. Assuming that you are saying that you can launch the cmd prompt on the same computer that is running BatchPatch to ping the target but in BatchPatch the same target being pinged is timing out there aren’t too many things that could cause that. The only things I can think of are some kind of typo or weird formatting issue when you added the target computer to BP, or maybe a weird DNS caching issue or DNS suffix issue. I would suggest trying the following things in no particular order:

reboot the BP computer
re-add the target computer to BP from scratch
add the target computer by IP instead of name
add the target computer by FQDN instead of short name

See if any of those gets you anywhere

[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

[Author]

Posts