Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Confusion over what userid a vbscript monitor component runs as.

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.

Find more posts tagged with

Accepted answers

aLTeReGo

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.

All comments

FormerMember

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

aLTeReGo

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.

Run Script under specified account.png

FormerMember

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?

FormerMember

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.

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.

aLTeReGo

FormerMember

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.