/build/static/layout/Breadcrumb_cap_w.png

In Windows Kscript, test "Run As"

I need a test I can use in a "Verify that..." step in the Verify section of a script task, that will succeed if the Kscript was "Run As Local System" and fail if "Run As ... User" (any of the three User Run As states). Or vice versa: fail as Local System and succeed when run as a user. This condition needs to work on Windows XP and Windows 7 (32- and 64-bit), and it needs to work with the legacy 5.1 KBOX agent and the new 5.3 KBOX agent.

Before the 5.3 KBOX agents, this worked:
Verify that the directory "%AppData%" exists.
It always succeeded when run as a user, and always failed when run as local system. But directory exists tests using environment variables no longer work with the latest 5.3.53177 agent, so I need to take a different approach.

Something in the registry, a key or value, exists or does not exist or has specific data? I've spent all day on this trying every difference I can identify (which is quite a few since I know Windows pretty well), and nothing works. Every test that succeeds as Local System also succeeds as a User, and vice versa. Probably not some directory or file in the file system, because Administrator-equivalents can get around most of those.

Any ideas that work would be greatly appreciated. Sande

0 Comments   [ + ] Show comments

Answers (3)

Posted by: snissen 12 years ago
Fourth Degree Green Belt
1
That's not quite what I'm going for. The script steps I'm about to run use %USERPROFILE%, %APPDATA%, HKCU, and other user-specific references. Before I use any of those references, I want to Verify that my script is indeed running in some user context, not as local System. This is all in one script.
Posted by: jverbosk 12 years ago
Red Belt
0
Not near my kbox right now, but if I'm not mistaken "verify that..." is the first part of the verify section, so I'm assuming you're running this as a follow-up to another script. Assuming this is the case, can you give an example of how you have the initial script setup - for example, what type of "run as" setup you're using and what kind of output is used.

My initial thought is that since system variables don't work, might it be possible to extend the initial script so that it "reports" on the account used for the process that runs when the script runs? In other words, if a script runs as SYSTEM (as listed in the Processes screen), could you possibly query the process list (i.e. reporting on the most recently invoked process or processes based on time running), report on the account used by that process (or processes), and output the results to a text file or registry key as a breadcrumb to be picked up by the "follow-up" script. I haven't tried capturing/reporting process activity, so I don't know if this would be feasible, but if nothing else hopefully it can help get things moving in the right direction.

John
Posted by: jverbosk 12 years ago
Red Belt
0
Now that I'm near my kbox, I re-read your post and it sounds like you are running multiple scripts with different "Run As" parameters. After the scripts run, you want to verify which "Run As" parameter (i.e. which account) was used when the script ran. Assuming that the "Run As Local System" uses the same account on all of the systems, one idea would be to include something in your scripts that are set with this parameter to write a file or reg entry (as a breadcrumb) which can later be targeted by another script to let you know which account was used - if it picks up the breadcrumb (via the Verify section), then the previous script ran under the system account, if not then it ran under the user account.

If I'm mis-reading this and you want to be able to determine the account used while the script is running, this may be helpful.

How Can I Determine Which Account a Script is Running Under?
http://blogs.technet.com/b/heyscriptingguy/archive/2006/02/16/how-can-i-determine-which-account-a-script-is-running-under.aspx

Hope that helps!

John
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ