[doug]

The return code comes from the installer, not from BatchPatch. We have not seen that particular one before. The HEX representation is c190010d. For googling purposes, use the HEX value.

https://docs.microsoft.com/en-us/windows/deployment/upgrade/resolution-procedures

0XC190010d MOSETUP_E_INVALID_CMD_LINE The installation process was launched with an invalid command-line argument.

Invalid command-line argument seems very peculiar. Implies that the issue is with your deployment syntax. I would try creating the deployment from scratch in BatchPatch as a start. While I don’t know how/why there would be a problem with your existing deployment since you imported it from a working deployment, the error implies that there is something wrong with the actual syntax. So to ensure that there isn’t somehow something invalid or corrupt in the deployment config (we have never heard of this happening before from an export/import), follow the instructions here to create a brand new deployment from scratch: https://batchpatch.com/deploying-windows-feature-upgrades-remotely-to-multiple-computers

If that doesn’t work, my next suggestion is pick a computer that produces the error and then try to run the Windows 10 upgrade manually (without BatchPatch) from the same installation media that you are using for the deployment. See if you have success. This would tell us that the issue is related to the deployment process as opposed to the issue being with Windows not being able to perform the upgrade for one reason or another. Also, if Windows cannot perform the deployment, it might pop a better message to tell you why it cannot proceed/complete.

Additionally, you can check through the log files mentioned at the Microsoft link at the top of the page and see if anything is revealed about the cause of the problem.

Please report back with anything you learn.

Thanks.

[doug]

I didn’t realize you were only experiencing this on a single machine. That then obviously indicates a problem with the particular computer, not with the WsusScn2.cab. I would try rebooting that 2016 machine first, and assuming that doesn’t solve the issue I would try resetting the Windows Update components on it. The link below can help you with that. If still no luck, I unfortunately don’t have any other suggestions.

https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-resources

[doug]

0x80240031 -2145124303 WU_E_INVALID_FILE file is not of the right format

I don’t think we’ve seen this particular error before, but it’s saying that the Windows Update Agent doesn’t like the WsusScn2.cab file. When you run BP in offline mode, the first thing it does is download the most recent version of this file from Microsoft to the BatchPatch cache directory (you can see the path of this directory in ‘Tools > Settings > Windows Update’ at the bottom). My only guess is the file is somehow corrupt. However, normally the WUA does a signature check on the file before doing anything, and it throws a different error if the signature doesn’t check out, so I’m not sure how this error that you received could occur since a corrupt file would fail the signature check and presumably throw a signature verification error, like what we have seen before. Anyway though, if you right click on the WsusScn2.cab file you can check ‘Properties > Digital Signatures’. Check this on both the BatchPatch computer in the cache directory as well as on the target computer (in the remote working directory, which defaults to C:\Program Files\BatchPatch). If the file does not have a ‘Digital Signatures’ tab, that would indicate it is corrupted. This could happen during the initial download to the BatchPatch cache folder or when BatchPatch copies it to the target computer’s working directory. If both are missing the ‘Digital Signatures’ tab, delete both, and then initiate a fresh download of the file using ‘Tools > Download Microsoft offline scan file’. Check the file properties to make sure there is a digital signature before attempting again.

[doug]

There is no such bug. It seems evident that you executed the search with offline mode enabled, you pasted the log file from that search operation into this thread, and then you took a screenshot with the box unchecked and pasted that into the thread. Alternatively, it’s possible that you used a BatchPatch job queue, and inside the job queue you used the special item ‘Enable offline cached mode (override global settings for this queue only)’

I’m sure if you go back and test again you will find that what I have said is accurate. You can also review the ‘All Messages’ column for a history of what you have executed, which might help clarify any confusion that you may have about what exactly you executed at which times.

[doug]

The log you pasted says differently:

::Begin offline search

[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

[Author]

Posts