Run WinBatch remotely with PSEXEC

[hienpham]

Hi,
  I have a Winbatch program named test_bug.exe. (the wbt file is attached)

It runs fine if I run it locally  (please see the attached trace_log_local.txt)

But if I want to run remotely from another system using Psexec version v2.11 (just downloaded from Microsoft site.) that WinBatch program started fine but hung at: 
      objLocator = ObjectOpen("WbemScripting.SWbemLocator")
(please see the attached trace_log_remote.txt and the attached WBT file)
I have to go to the remote Task Manager and kill the test_bug process .

The Winbatch program and its extender are on the same folder on the remote system. The included batch file with the psexec.exe is on the system where I logged in to start the remote process.

  I think that we can duplicate this problem just by changing the <system_name> and the <account> in the batch file.

Please help.
Thanks so much for any input

hien pham

[td]

Although probably not the cause of your problem it is curious that you are using the old WinBatch COM Automation functions.  They were retired 10 years ago.

You attached a debug trace that is described as local.  Is this local on the system you are running Psexec from or the system that is the target of your Psexec run?  If it is from the system that you are running Psexec from, you may want to determine if WMI is even enabled on your target system.

You could also have a permission problem.  The account you are using with Psexec may not have sufficient privileges to use WMI and the Cmdkey settings may not be sufficient to grant remote access to WMI services.  MSFT considers WMI a security risk so the default system settings tend to be conservative. 

You might find MSFT's WMI administrative tools useful for diagnosing WMI related issues on your remote machine.  They can be found here:

http://www.microsoft.com/en-us/download/details.aspx?id=24045

[td]

Also, out of curiosity, why are you using cmdkey.exe instead of psexec's built in user name and password switched?

[hienpham]

Thanks TD for your reply.
1.  I have now WinBatch 2014B, but because I use WinBatch for over 17 years for all my scripts and I'm very lazy to reinvent the wheel unless I have to, I reuse my old coding. BTW what I love in WinBatch beside its user friendly is its capability to compile to an EXE, this allows me to hide my passwords, accounts, and prevent people to modify the script without my consent...
2. The debug trace named local is the one I got when I ran the script by itself on the system AAA that is the target of my Psexec. I ran psexec on the system BB, pointing to the WinBatch script resides on the system AAA, the remote trace log was created on C:\temp of the AAA system.
3. The account that I used is the Domain admin one, it's a domain that systems AAA and BB are in and I have -h in the Psexec command to "have the process run with the account's elevated token."
4. I will use the MSFT's WMI tools to debug the problem and will let you know the result.
5. BTW my target system AAA (target of the Psexec) is a VM (Virtual machine) Server 2008 R2 enterprise and my BB system (where I start the psexec) is a Windows 8.1 Enterprise
6. Originally I used the Psexec only with its user name and password switches and I got access denied. I did some research on Web and got the following document http://serverfault.com/questions/489822/psexec-is-not-connecting-to-machine-using-supplied-username-and-password/489845   that suggested that we use cmdkey to overcome the access denied. It works for me. 

Again thanks so much for your help TD.   
hien pham

[td]

The cmdkey.exe trick is a new one to me.   While I can understand that access to an administrative share is controlled by cached credentials because the Windows SMB service will use those credential,  I ever thought of using them to escalate the access token of  a process started with psexec.   Have to cache that idea away for future reference.

With regard to your WMI issue, you may want take a look at the event logs of your target machine.  They may provide some kind of clue to the root cause of your problem.  Also consider that even Domain Admins do not necessarily have full permissions to do everything on a system.  To loosely paraphrase Chopp, admins do not necessarily have a permission they just have the right to grant themselves a permission.