PsExec v2.32

Are we saying that now in order to use -h you must also specify -i ?   You can no longer specify -h without -i ?    If this is the case then perhaps the actual help text inside of the app should be updated to note this, but it also then raises the question of why -i would be needed at all.  That is to say that when you execute -h, if -i is required then it should automatically execute -i under the hood, no? Or perhaps it should immediately spit out an error that "in order to use -h you must now also specify -i" or something like that.  This is just my immediate reaction/thought.  I'm confused about why all of a sudden in v2.32 -i would be a requirement for executing with -h, as they are two distinct operations.  Thanks.

MikeDiack thanks for the feedback, we'll do better with breaking changes going forward.

Thanks for this, I can confirm what foxmsft930 said, it's a shame the documentation / changelog didn't make it more obvious that this was a breaking change in 2.32.

With Psexec 2.32 (build of 15 Jan 2021):

psexec \\RemoteSystem -h -u administrator -p password c:\demoprogram.exe

fails with:
Logon failure: the user has not been granted the requested logon type at this computer

BUT (with the additional -i parameter before the -h), this works.

psexec \\RemoteSystem -i -h -u administrator -p password c:\demoprogram.exe

Note the change              ^

Thanks to all, but please make it obvious in future if introducing breaking changes in builds.

MikeDiack, siegfried_hello - also add the -i switch to get an interactive session.

SingularMark the Suite is now re-published, thanks for reporting!

Thanks for raising the issues, we are investigating.

Hi All,

Looks like the "master" .ZIP file "live.sysinternals.com/files/sysinternalssuite.zip" is missing?

Cheers,

 «M»

Sorry for my message, but I don't know another way how report a bug of "Junction" and "Streams" to Sysinternals team...

When I run "Junction" and "Streams" utilities (I am using Windows 10 build 1809 x64 Russian language), I saw the "?" symbols instead of russian (cyrillic) symbols in error-messages and files/folders names. Is this a bug of "Junction" and "Streams" utilities?

I run utilities like below:
junction64.exe -nobanner -accepteula -s C:\ > j.log
streams64.exe -nobanner -s C:\ > s.log

Files "j.log" and "s.log" are text-files with Codepage 1251 (ANSI) symbols.

For example, some output strings of "Junction" Utility (file "j.log"):

Failed to open \\?\C:\\pagefile.sys: ??????? ?? ????? ???????? ?????? ? ?????, ??? ??? ???? ???? ????? ?????? ?????????.

\\?\C:\\Program Files\windows nt\???????????: JUNCTION
Print Name : C:\Program Files\Windows NT\Accessories
Substitute Name: C:\Program Files\Windows NT\Accessories

\\?\C:\\ProgramData\???????: JUNCTION
Print Name : C:\ProgramData\Microsoft\Windows\Templates
Substitute Name: C:\ProgramData\Microsoft\Windows\Templates

and some output strings of "Streams" Utility (file "s.log"):

Error opening C:\pagefile.sys:
??????? ?? ????? ???????? ?????? ? ?????, ??? ??? ???? ???? ????? ?????? ?????????.

Error opening C:\swapfile.sys:
??????? ?? ????? ???????? ?????? ? ?????, ??? ??? ???? ???? ????? ?????? ?????????.

Error opening C:\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data\
Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\??????? ????\Programs\??????????\7-Zip:
??????? ?? ??????? ????? ????????? ????.

And Does "Streams" utility recognize and not process Junctions, Reparse Points, Symbolic Links in Folders?

I can confirm I see the same issue.  And worth noting that it's a problem both with -h and without -h, but only when specifying alternate credentials.  When using -s with alternate credentials, it does not occur.  Also, when using integrated security (no alternate credentials) it does not occur.

To be clear, both of these commands fail with the same error ( Logon failure: the user has not been granted the requested logon type at this computer. ):

psexec \\RemoteSystem -h -u administrator -p password c:\demoprogram.exe

psexec \\RemoteSystem -u administrator -p password c:\demoprogram.exe

However, this command does not fail:

psexec \\RemoteSystem -s -u administrator -p password c:\demoprogram.exe

Sorry to say psexec 2.32 is buggy also. The -h option to remotely run an elevated activity fails. It worked in 2.2.

eg. the following worked with 2.2 but fails on 2.32:

psexec \\RemoteSystem -h -u administrator -p password c:\demoprogram.exe

Failure on 2.32:
PsExec could not start c:\demoprogram.exe on RemoteSystem:
Logon failure: the user has not been granted the requested logon type at this computer.