BatchPatch Forums Home › Forums › BatchPatch Support Forum › Error 1611: 233. Failure || Error 1620: 233. Failure
- This topic has 8 replies, 2 voices, and was last updated 3 years, 11 months ago by doug.
-
AuthorPosts
-
January 11, 2021 at 6:12 pm #12666dougModerator
On January 11, 2021 PsExec version 2.3 was released by Microsoft. We noticed that when using psexec.exe we encountered ‘Error 1611: 233. Failure‘ or ‘Error 1620: 233. Failure‘ in BatchPatch. At the command prompt when using psexec directly without BatchPatch we receive ‘Error communicating with PsExec service on XXX: No process is on the other end of the pipe.‘ Additionally, on the target computer the remote process would be left running, when normally it would/should be stopped and deleted automatically.
To delete the orphaned remote PsExec process on the target computer, launch the Services console on the target computer (Start > Run > Services.msc), and then locate the service and stop it. You can delete it at the command prompt (cmd.exe) by using this command:
sc delete PSEXESVC
However, if you have been using the setting ‘Use PsExec -r switch to specify a remote service name‘ then your command should use that name instead of PSEXESVC. So for example if you changed it to BatchPatchExeSvc then you would use this command:
sc delete BatchPatchExeSvc
RESOLUTION:
I switched from using PsExec.exe to using PsExec64.exe, and the problem went away.To tell BatchPatch that you are using PsExec64.exe, go to ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath’ and select the path to your PsExec64.exe.
January 12, 2021 at 2:33 am #12668KMEParticipantHello,
for me PSExec.exe V2.3 only works an 32bit and PSExec64.exe V2.3 only works an 64bit computers!?January 12, 2021 at 12:21 pm #12670dougModeratorThanks. 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.
January 12, 2021 at 6:30 pm #12673dougModeratorOn 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.
January 13, 2021 at 2:59 pm #12676dougModeratorFYI we discovered that the Jan 12 PsExec update still has a couple of other bugs, so I’d suggest holding off on it still.
January 15, 2021 at 5:10 am #12681KMEParticipantA new version of psexec (2.32) from 01/15/2021 is online.
January 15, 2021 at 6:49 am #12682dougModeratorThanks. 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.
January 15, 2021 at 12:37 pm #12684dougModeratorThere 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.
January 25, 2021 at 4:09 pm #12698dougModeratorOK 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.
-
AuthorPosts
- You must be logged in to reply to this topic.