Video Screencast Help

Running a script/job as if you're the logged on user

Created: 28 Jun 2013 | 4 comments

Hi everyone - I have a question about running an application on a machine as if I am the console user.  There are two ways that this has been an issue for us.

One way; every month, we have a downtime scenario at our hospital.  There is a small piece of software on many of our clients that monitors the availability of our EMR (electronic medical record) system.  If someone closes the EMR, this program automatically re-opens it to a login prompt.  

During downtimes, we have to stop this, because when the Citrix farm becomes unavailable, this program throws dozens of errors on the screen.  SO, we push out a script that kills the process before the downtime begins, and this works great.

However, getting it to start back up is the challenge.  I have a VBS script that simply calls the process, and it starts it back up.  We were successful with it using our DS 6.9 environment and our 7.1 environment.  But then we tested it again a few days later, and it wouldn't work.  Finally realized that if the logged on user was a local admin, it would not work.  If they were not an admin, it worked fine.  I don't have that mixed up - it works when they're NOT an admin.  The process shows up in Task manager, but it never fully starts up.  I tried dropping the VB script and just calling the process with a batch file, but it has the same result. 

The other scenario is with a VB script that modifies the print queues.  It scans the existing print queues, compares them to the new print server queues, and creates new queues, deletes the old ones.  Anyway, when you run it on the workstation manually, you get prompted for each queue it is going to create, and then you click OK for it to continue.  

I need to call this script on Windows XP machines throughout the organization, and it must be run as the logged on user.  WHen I call the script from Altiris, I see the process running, but the user never gets any prompts, and the queues are not modified.  It eventually dies out on its own.

 

I have set the jobs to run as the logged on user in both scenarios.  

Is there some other way that I can call the scripts?  

Thanks for your help!

 

j

Operating Systems:

Comments 4 CommentsJump to latest comment

Klim_Belchev's picture

Maybe your local admin does not have access to a domain resource or something similar...

What user does your EMR monitoring software normally run as?

Another idea is to make your scripts run visibly through Altiris so your can see what is going on.

jbeale53's picture

Thank you for the response - the console user is the user that runs the EMR software.  

I can access and run the script on the console manually, and it works great.  It's just running it from Altiris where it doesn't work.  

 

I ran the script in Windowed mode instead of hidden, and I see a DOS box flash on teh screen for a split second.  I'll try adding a Pause to see if it will stay there long enough to get anything out of it.

 

j

Klim_Belchev's picture

In all cases you must see what is the result of your script that you run...

To do that,  in the advanced part of your script task check:

 - Run As: Current logged-on user

 - Show script:   In a normal window

And under Other also check:

 - Save script output with task status

 - Enable launch 64-bit process
 

Do a quick run to a test machine.

Then you can check the status of your job. Even if it fails it will still capture your script's output.

jbeale53's picture

The printer migration script is working now in 7.1.  Instead of inserting the VB code directly into Altiris, I placed it in a file ont he network and call it from a command script using cscript.exe.  Set it to show the window on the user's screen, and it runs in a DOS window , lets the user know which queues it is migrating, with a completion prompt.  So, that one is all set.

 

Still working on the EMR script.  I'll post details if I get somewhere with it; I can't recall now how much I had tried in 7.1 with it (many of our technicians still only have DS 6.9 acces, so we often have scripts running in both places). 

j