Error 1611:233 Failure

[sarnold2245]

I’ve searched on here for past articles and tried the solutions but they dont seem to work for my situation.
I am getting this error 1611:233 on every computer I try to use batchpatch with. I went through the getting started guide. I’ve placed PSexec in C:\windows and run it from command prompt once.
This is the full error log I am getting.
01/11 12:19:52> Windows Update: Error 1611: 233. Failure
01/11 12:19:52> Windows Update: Failed to obtain result. Could not find file ‘\\WLR-ACCCLRK.woodlands.dest1.com\C$\Program Files\BatchPatch\BatchPatchTempResult.log’.
01/11 12:19:47> Windows Update: Executing BatchPatchRemoteAgent.exe…
01/11 12:19:47> Windows Update: Attempting to initiate Windows Update (Action: Download and install updates: ‘ImportantAndRecommended’ | Server selection: Default / Managed) …
01/11 12:19:47> Windows Update: Establishing connection…
01/11 12:19:46> Windows Update: Initializing…
01/11 12:19:46> Windows Update: Queued… (Download and install updates)

[doug]

This is an indication that PsExec is not able to successfully complete its operations. The 233 is a Windows system error code:

ERROR_PIPE_NOT_CONNECTED
233 (0xE9)
No process is on the other end of the pipe.

If I’m understanding you correctly, you are experiencing this from one BatchPatch computer to any/all target computers. This would indicate that the issue is likely something related to the BP computer, so as a start it would be a good idea to test running BP from a different computer. If it works from a different computer, then you might just use that different computer until/unless you can locate the source of the issue on the original computer.

Presumably before you purchased a license you were running the evaluation version successfully, so what changed in between then and now? Were you using a different BP source computer when testing the eval vs now?

Another thing that you can try is under ‘Tools > Settings > Remote Execution’ if you enable the option to ‘Use PsExec -r switch to specify remote service name’. You can put any name there that you want, such as BatchPatchExeSvc. When PsExec is being blocked due to security restriction, it can cause the “No process is on the other end of the pipe” error. The setting mentioned above can sometimes bypass this type of issue.

If no luck, I would next test psexec at the cmd prompt from the BP computer to the problematic target computer by doing the following from the cmd prompt of the BP computer:

psexec \\targetComputer cmd

And then see if you are able to issue commands successfully. Check for the existence of the psexesvc process on the target computer.

In some cases where PsExec isn’t working quite right to a particular target computer, sometimes you can simply run it from a different computer, and similarly you can end up successfully running BP from a different computer, as mentioned previously.

In other cases switching the version of PsExec can seem to help. If you can find a copy of an old version (ideally v1.98), you might have luck using that instead. We’ve even heard of a couple of cases where switching to an old version of PsExec and then switching back to the latest version works for whatever reason. From a security perspective, using an older version of PsExec, indefinitely, is not optimal, especially if using ‘alternate credentials’ because those are passed in plain text over the network, whereas PsExec version 2.1 and newer encrypts credentials over the network. Note, this is only relevant for when you specify “alternate credentials” in BatchPatch. If using “integrated security” then credentials are not ever sent across the network regardless of the version of PsExec. More on this topic here.

Another option is to try PaExec (a free and open source clone of PsExec), and see if it works in place of PsExec. PaExec obfuscates but does not encrypt credentials sent across the network, so it’s similar to older versions of PsExec in that regard and isn’t optimal as compared to PsExec new versions (though older versions of PsExec don’t even obfuscate the credentials like PaExec does). To use PaExec then you would go to ‘Tools > Settings > Remote Execution’ and change the ‘Use psexec.exe custom filepath’ to point to the PaExec.exe on your computer.

We have only heard of the 233 error a handful of times over the past many years, so it’s rather obscure and doesn’t usually seem to have a definitive cause/solution.

What OS is the BatchPatch computer running on in your case?

What OS are your target computers?

-Doug

[doug]

Additionally… a while after writing the above response to you, I noticed that Microsoft had released a new version of PsExec today (version 2.3), and so I downloaded it to give it a try, and lo and behold I got the same ‘Error 1611:233 Failure’ that you got. It seems evident that something changed in between PsExec versions, though I don’t yet have a guess as to what. We are investigating.

[sarnold2245]

Thanks Doug
I was able to get working using PaExec.exe
I was using 2.3 so maybe that was it. I have a copy of 2.2 on my old computer so I’ll give that a try as well.
Thanks for your fast response. I’m up and running either way.

[doug]

Thanks. Please do let me know if your 2.2 version works too.

[doug]

Interestingly, in testing we just discovered that while psexec.exe v2.3 throws the aforementioned error on our test machines, psexec64.exe does not have the same issue. I would suggest you try psexec64.exe. Please let me know what happens.

[sarnold2245]

So I believe the issue we are having is due to our Sophos Anti-Virus. I tried using PSexec 2.2 as well PSexec64 2.3 and still got the same result. Whats interesting is with 2.3 we didnt receive any warning messages in the AV console, but the moment I dropped 2.2 it quarantined the file and removed it. I believe in the past I was able to use batchpatch by putting in a special exemption for PSexec. We are good running with PaExec.
Thank you for your help with this.

[doug]

Thanks. Also just FYI for anyone else who reads this thread, the 64/32 bit weirdness appears to be a bug in the new version 2.3 of PsExec. At the moment it seems that you have to use the 64 bit version for 64 bit targets, and the 32 bit version for 32 bit targets. We believe this is not a “feature” but rather is a bug, so we are anticipating a fix/update from Microsoft/Sysinternals.

[doug]

On January 12 2021 another PsExec update was published that fixes the 32/64 bug, so now the standard psexec.exe (32 bit version) works as expected.

[doug]

FYI we discovered that the Jan 12 PsExec update still has a couple of other bugs, so I’d suggest holding off on it still.

[doug]

OK so where things have been left is that PsExec v2.32, which is the current/new release, will work the same as previous versions of PsExec, when using SYSTEM remote execution context. However, when using ‘Elevated token’ in conjunction with alternate credentials in PsExec v2.32, you also have to now additionally use the -i (interactive) switch. In the next release of BP we will add this option as well.

Microsoft appears to be considering this change intentional, and not due to a bug after all. It’s unclear at this time if they will be making any additional changes in the near future, but all signs point to this being where things will be left, at least for now. It does not appear that they plan to release an update to replace v2.32 any time in the very near future.

[Author]

Posts