Exit code problems when attempting Windows Updates

[JayP]

I’m getting exit codes I haven’t seen before when using the “Windows Updates -> wuauclt.exe /resetauthorization /detectnow” command as part of my process to update a bunch of remote servers. There are two different behaviors:

• Running BatchPatch from my laptop under my regular user account, I specify my domain admin account as an alternate credential, run the above command, and get exit code 2250 on all the servers
• Running it under my domain admin account directly, I run the above command on the same servers and get exit code 193

The firewall is disabled on all servers and I can RDP to them with no issue.

Any ideas what the problem could be here?

[doug]

Jay – Those error translate to:

ERROR_NOT_CONNECTED

2250 (0x8CA)

This network connection does not exist



ERROR_BAD_EXE_FORMAT

193 (0xC1)

%1 is not a valid Win32 application.

It’s hard for me to say definitively what’s happening here. No one else has reported these errors, so I suspect it’s something that is specific to your environment. My best guess is that you have some type of anti-virus or host-intrusion-prevention or similar security related software on the target computer that is causing the problem. I think possibly what might be happening is that BatchPatch copies the necessary files to the target computer to execute, but then right before or during remote execution, the files are removed by the local security software on the target. This then manifests in BatchPatch as a 2250 or 193 error. I think specifically the most likely cause is related to PsExec because that is what is being used to execute the commands you mentioned.

See if you can whitelist psexesvc.exe in your antivirus/security software on target computers. I think that’s probably the one that your security software would be targeting. Another possibility is to change the name of that exe/svc in BatchPatch under

'Tools > Settings > General > Use PsExec -r switch to specify a remote service name: BatchPatchExeSvc'

After changing the above setting you might still need to whitelist BatchPatchExeSvc on target computer (or whatever name you used in that field, if not BatchPatchExeSvc).

Let me know how it goes.

-Doug

[JayP]

Thanks for the reply!

I had our security ops folks take a look and they say that these servers are not yet being managed by their systems (makes sense since these VMs are new), so that’s not it. These are Windows Server 2012 R2 VMs, btw.

I noticed an interesting behavior, though:

– I run the wuauclt.exe command from BP

– It fails with exit code 193

– On the remote machine, ‘PSEXESVC’ exists in services.msc

– I do ‘sc delete PSEXESVC’, which removes it successfully

– I try again from BP and get exit code 193 again

– I check services.msc on the remote machine again and ‘PSEXESVC’ is there once more

This doesn’t happen on my known good VM. That is, if my assumption is correct, when BP initiates the command, the ‘PSEXESVC’ service gets created on the remote machine and then deleted after it completed. IsS that correct?

Either way, this definitely appears to be a psexec issue, which makes me think it’s permissions related. But I can’t see how that could be since my domain admin account is a member of the local ‘Administrators’ group on all these VMs (including the known good test VM).

[doug]

OK – so yes you are correct that under normal operating circumstances, the psexesvc is removed after the command is executed. We have seen instances where it doesn’t get removed properly. Sometimes this is an issue and other times it is not an issue. And to be clear, I’m not sure that it’s an issue so much as a symptom of whatever the problem actually is. Over the years we have had a small handful of users experience problems with psexec, but they have always been strange. Here are the things we have observed and some things to try:

1. We have seen cases where the issue actually appears to be tied to the machine that is running BatchPatch and PsExec, *not* the target host. Even though the target host is where the failure appears to occur, in some cases the problem ceases to exist when BatchPatch is operated from a different computer but with the same target computers.

2. Test psexec at the command line without BatchPatch. So for example you could run

psexec \targetComputer wuauclt /resetauthorization /detectnow

Does it complete successfully? If it doesn’t complete successfully, then we’ll know for sure that it’s the source of the issue. However, note that it might complete successfully even if the problem still actually is related to PsExec. Let me know.

3. We have seen cases where switching to an older version of PsExec solves the problem. In particular I would suggest trying version 1.98 (or older) if you can find a copy. We can’t distribute it due to the way that it is licensed. In one of these cases the user was able to switch back to the latest version of PsExec once things started working, and then he never had a problem again. Also note that PsExec sends credentials in clear text with versions prior to 2.1, so ideally it’s best to use the latest version. However, this is only an issue when specifying ‘Alternate Credentials’ in BatchPatch. Additionally, even when specifying alternate credentials, on most switched networks this isn’t really a major concern because the only people who could conceivably monitor the network traffic on a single port are people who have administrator access to the switches.

4. Another option is to try the free PaExec https://www.poweradmin.com/paexec You can rename this to psexec.exe and then BP will use it. Note, in the alternate credentials use case, it sends the credentials obfuscated (not encrypted).

[Author]

Posts