[doug]

Yes, this can be done with a job queue.

[doug]

An offline search will not necessarily find identical updates to an online search. The offline search occurs against the WsusScn2.cab file that Microsoft releases each month. Offline mode is designed for offline scanning when no internet or WSUS is available. While this WsusScn2.cab file contains all security updates as well as various other updates that Microsoft decides to include in it, it does not contain every single update that is published on Microsoft’s public Windows Update and Microsoft Update servers. Offline mode is not recommended for computers that have internet access or access to a local WSUS.

[doug]

Create a job queue with the following steps:

1. Check for available updates
2. Terminate queue if previous ‘Check for available updates’ finds 0 updates
3. Send email notification

Then set that job queue to run as a scheduled task. When it runs it will send you an email notification if/when there are 1 or more updates available. In the next version of BatchPatch there will be additional conditional options available for the job queue to enable this task to be created in a couple of different ways, but in the current version you would need to do it like stated above.

The multiple tasks scheduler does not allow recurrence. Your options are either create a separate recurring scheduled task for each row (you can create more than one row per host, if desired), or use the multiple tasks scheduler and manually create all of the desired datetimes to run the task.

[doug]

You cannot trigger BatchPatch actions from cmd/powershell. However, if you want to automate the update process you can schedule BatchPatch actions to run at a desired datetime by using the Task Scheduler inside of BatchPatch:

How to Automate Monthly Windows Patching and Updates for Numerous Computers

If you want to be able to run BatchPatch scheduled tasks without having to be logged on with BatchPatch running, you can run BatchPatch as a service:

Running BatchPatch as a Service

[doug]

I’m glad you got it worked out, @Johan. Thanks @mmccar for pointing to the solution. For anyone else who might read this thread, here are some things to be aware of:

1. Remote Execution Context:
https://batchpatch.com/remote-execution-context

If BatchPatch is set to SYSTEM, if you execute a deployment to run a .bat file on a remote computer, when the .bat file runs it will not have network access. So, if that .bat file contains a call to a network share, as was the case with @Johan’s .bat file, it will not be able to run to completion successfully.

Set the remote execution context to ‘Elevated token’ to resolve this issue, as @mmccar pointed out.

2. Integrated security vs alternate credentials
If you continue to have problems after setting the remote execution context to ‘Elevated token’ the next thing that you should do is specify alternate credentials for the row(s) in BatchPatch (Actions > Specify alternate logon credentials). Even if the alternate credentials that you specify are for the same exact logon account that you are already running BatchPatch under, you should still do this. It’s complicated to describe why this makes a difference, so I’m not going to get into a lot of detail on the topic right now. Suffice it to say that when there are multiple hops of authentication (from the BatchPatch computer to the target computer, and then from the target computer to the network share that is called inside the .bat file), there is a difference between using integrated security as compared to when you specify alternate credentials. When you specify alternate credentials you essentially end up removing one of the hops, and this can be the difference between the deployment completing successfully vs failing.

[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

[Author]

Posts