[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.

[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.

[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.

[doug]

1. What version of PsExec are you using? If you have version 2.21 or 2.30, go get the latest v2.32 from Microsoft (or get previous version 2.20 if you have it saved somewhere). PsExec versions 2.21 and 2.3 contain bugs, so you should not use those versions.

2. Then on the target system, look in the services console (start > run > services.msc). If you see an orphaned PsExeSvc service, stop it. Then delete it. (If you previously were using the -r switch by enabling it in BatchPatch Tools > Settings > Remote Execution > Use psexec -r switch’, then look for orphaned services under the name that you specified there instead of under ‘PsExeSvc’). You can stop the orphaned service(s) using the GUI, but then you can delete it/them at an administrator command prompt with the following command:

sc delete psexesvc

or if you had specified a value for -r then it would instead be:

sc delete WhateverValueYouHadSpecifiedGoesHere

3. Then on the BatchPatch computer make sure you are using the new PsExec v2.32 (or use the older version 2.20 if you have it, but do NOT use the version 2.21 or 2.30.).

4. If you are using PsExec v2.32, in BatchPatch go to ‘Tools > Settings > Remote Execution’ and select ‘SYSTEM’ for all.

[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.

[doug]

For sales etc contact us directly at BatchPatch Contact Form

[doug]

If the cmd is giving you the proper result, then I’m sure BP is too. However, because of the column size in BP it is wrapping to the next line. You can view the entire column contents by using the middle click mouse button in the cell or right click on the cell and choose view cell contents. Then you will see the entirety of the result instead of just the top line.

[doug]

Thanks. What do you see if you run the wmic command at the cmd.exe command prompt *without* using batchpatch? What is the result in that case of just running the command manually?

[doug]

Have you examined the setting under ‘Control Panel > All Control Panel Items > System > Computer name, domain, and workgroup settings > Computer description’? Have you made sure it matches this text? “Surface Book 2 – Rene de Vries”

[doug]

The query you specified is the correct query to get the “Computer description” field from the target computer. This is the field that you see under “Control Panel > All Control Panel Items > System > Computer name, domain, and workgroup settings > Computer description.” This is *not* the same information that would appear in the Active Directory ‘Description’ field.

[doug]

There is still at least one bug in the v2.32 version, unfortunately. In BatchPatch if the remote execution context is set to “elevated token” or “normal” actions will fail with exit code 1385. If remote execution context is set to “SYSTEM”, actions are successful.

This setting is under ‘Tools > Settings > Remote Execution > Remote Execution Context’.

In v2.2 where this bug didn’t exist, you could usually use ‘SYSTEM’ and ‘elevated token’ interchangeably. However, there would be *some* cases where you would really need to use one over the other even though for the most part they would both be successful for most commands/scripts.

So for now while the bug in v2.3 exists, it would be fine to set the value to ‘SYSTEM’ and generally that will be ok for most things. However, for those rare times where ‘elevated token’ would be needed for success, ‘elevated token’ will currently not work with v2.3.

[doug]

Thanks. Yeah so far it looks like it resolves all the bugs, but we will also be testing it more thoroughly over the next day or two just to be sure.

[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]

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]

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]

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]

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]

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]

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]

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]

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 released on January 11 2021. 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]

Interestingly, in testing we just discovered that while psexec.exe v2.3 throws the aforementioned error on our test machines, psexec64.exe v2.3 does not have the same issue.

[doug]

Interestingly, in testing we just discovered that while psexec.exe v2.3 throws the aforementioned error on our test machines, psexec64.exe v2.3 does not have the same issue.

[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.

[doug]

Looks like on January 11 2021 PsExec version 2.3 was released. However, we don’t know at the moment if it fixes the issue, though we assume there is a good chance that it does. Also, in our initial test, and confirmed by one other user, PsExec 2.3 seems to not work properly. In BP it produces ‘Error 1611:233 Failure’. We don’t know yet if all BP users would experience this or only some. We are investigating. Not yet sure what to make of it.

[doug]

Looks like on January 11 2021 PsExec version 2.3 was released. However, we don’t know at the moment if it fixes the issue, though we assume there is a good chance that it does. Also, in our initial test, and confirmed by one other user, PsExec 2.3 seems to not work properly. In BP it produces ‘Error 1611:233 Failure’. We don’t know yet if all BP users would experience this or only some. We are investigating. Not yet sure what to make of it.

[doug]

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

[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.

[doug]

Please see: BatchPatch Troubleshooting Guide

[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

[Author]

Posts