This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.

You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Confusion over what userid a vbscript monitor component runs as.

FormerMember over 9 years ago

I am writing a vbscript component monitor which needs to run an external exe as a specific local user on the Orion server. So far I've found that although my credential for monitoring is set as that specific local user, my script, in fact, runs as the machine account instead. To test further I put together the following script to explicitly report the userids in use.

For the record, the machine name is copernicus, and the local user is copernicus\musr_mqadmin. The component credential is set to this userid. The test code is as follows and is executed passing ${USER} as the one and only argument.

Set lstArgs = WScript.Arguments

orion = trim(lstargs(0))

Wscript.Echo "Message.Orion:says I am " & orion

Wscript.Echo "Statistic.Orion:0"

set wshShell = createobject("wscript.shell")

Set wshEnv = wshShell.Environment("PROCESS")

Wscript.Echo "Message.Environment:says I am " & wshEnv("USERNAME")

Wscript.Echo "Statistic.Environment:0"

When I test run this script I get the following output...

Output Result:

Message.Orion:says I am copernicus\musr_mqadmin

Statistic.Orion:0

Message.Environment:says I am COPERNICUS$

Statistic.Environment:0

Because the wshshell environment reports the wrong userid, my wshshell.exec in the real script fails to execute the command properly. So two questions, have I gone about this the right way, and am I right in assuming that the 'credential for monitoring' should be being used as the user the monitor is run as?

Note, I have not yet investigated the possibility of doing this successfully in powershell instead. I'm barely new to vbscript.

Thanks for any help.

Top Replies

aLTeReGo over 9 years ago +1

VBscripts are always executed under the Local System account on the Orion server itself. The credentials options are only used for variables within the script if your script requires the use of credentials…

0 FormerMember over 9 years ago

Quick update. Powershell does the same... Again, ${USER} as arg.
$iam=$args[0]
write-host "Message.Orion:says I am " $iam
write-host "Statistic.Orion:0"
$iam = $env:username
write-host "Message.Environment:says I am " $iam
write-host "Statistic.Environment:0"

Output Result:
Message.Orion:says I am copernicus\musr_mqadmin
Statistic.Orion:0
Message.Environment:says I am COPERNICUS$
Statistic.Environment:0
Cancel
Vote Up 0 Vote Down

Cancel
0 aLTeReGo over 9 years ago

VBscripts are always executed under the Local System account on the Orion server itself. The credentials options are only used for variables within the script if your script requires the use of credentials. To execute a VBscript under a different user account you would need to incorporate impersonation into your script. Alternatively you can use the PowerShell Script Monitor which natively supports impersonation through use of the "Run the script under specified account" option.
Cancel
Vote Up +1 Vote Down

Cancel
0 FormerMember over 9 years ago in reply to aLTeReGo

Thanks, I'll give that a go tomorrow and convert my proper script to PS. My PS test as above still reports the computer account from the environment, but I'll try properly with the bits that need the different authority and see if that makes any difference. I'm more familiar with unix, but I suspect that impersonation doesn't necessarily change userid, just rights?
Cancel
Vote Up 0 Vote Down

Cancel
0 FormerMember over 9 years ago in reply to aLTeReGo

Hi,
I'm afraid that the "Run the script under specified account" is not working for me. I have converted the relevant part of my task into PS and run as my test script under Orion, with that option on, and the required credential in the component. The script reports the environment, and it still reports the machine account is being used ( gci env:username ). The command in the PS which needs the different authority fails because it doesn't have that authority.
If I run the exact same script in a PS session runas the required user, the env:username reports correctly, and the command in the PS works correctly.
I can only categorise this as the "Run the script under specified account" option not working as advertised. I'm on the verge of raising this as a bug report unless anyone has any further info.
My next option is to switch on Orion debugging and see if that offers any clues.
Cancel
Vote Up 0 Vote Down

Cancel
0 FormerMember over 9 years ago in reply to FormerMember

I've also tried setting the template to 64-bit as per previous notes read on the subject. The PS is running, just not impersonating as requested.
Cancel
Vote Up 0 Vote Down

Cancel
0 aLTeReGo over 9 years ago in reply to FormerMember

You will not see the user PowerShell is impersonating populated in the "$env:username" variable because the process is still executed under the local system process. You will instead see the username being impersonated when you display the [System.Environment]::UserName variable.
Cancel
Vote Up 0 Vote Down

Cancel
0 FormerMember over 9 years ago in reply to aLTeReGo

Thank for that hint. Seems my original problem was not one of authority after all. The client program my script is calling had some sort of internal API error which I'd misinterpreted as authority. My misunderstanding of the impersonation added to my problem.
Mysteriously the API problem 'went away by itself' the other night, so my script is now working. I'm stumped as to what the original problem was though.
Thanks for your help.
Cancel
Vote Up 0 Vote Down

Cancel