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


Please log in to comment

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


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.

Answered 03/15/2012 by: jverbosk
Red Belt

Please log in to comment
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?

Hope that helps!

Answered 03/16/2012 by: jverbosk
Red Belt

Please log in to comment
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.
Answered 03/19/2012 by: snissen
Fourth Degree Green Belt

Please log in to comment
Answer this question or Comment on this question for clarity