Vista Logon Scripts - Launchapp.wsf
Posted by Jarvis on March 27, 2008
After switching to Vista (18 months ago…beta 2), I realized that my logon script wasn’t running anymore, but I didn’t really pay attention to it until this week…I’m needing to roll out Vista computers to some users at the office…so I need the logon scripts to work. In doing some research I found out why they don’t work. I won’t do a full write up of the reason, but basically it has to do with User Account Control and whether or not the user is a local admin on the computer. You can read a decent description of the issue here.
To get the logon script to work in this instance, you need to use a script named launchapp.wsf (scroll all the way to the bottom of that link) that you can get from the Technet site. That script is one that you use to launch your logon script. It schedules the script to run as a task as the interactive user. It works well…but there are a few issues that I read about and experienced personally.
First, launchapp.wsf does not work for an XP client. So…if a user logs in on a Vista computer and an XP computer…the logon script will work on one or the other…but not both. Or if you are using a GPO to assign your logon script, then it will only work for either XP computers or Vista computers.
Second, if you run multiple scripts (or the same script multiple times), the first will run, but the others will fail. This is because launchapp.wsf creates a scheduled task with a name of “Launch App As Interactive User”. It fails because it can’t create the second task with the same name.
So, I set out to fix those two issues. First, let me say that I am not a great scripter. I understand VBScript. I can write it…I’m not great, but I am adequate. One aspect of script writing that I am very good at is copying something that someone else wrote and massaging it to fit my purpose. That is what I did to fix these problems…a combination of massaging others’ code and writing some of my own.
To fix the issue of launchapp not working with XP, I added a section of code that determines the OS. If the OS is XP, it runs the logon script normally. If it is Vista, it runs it via scheduling the task.
Fixing the multiple scripts / multiple runs issue was more difficult. What I was able to deduce is that the issue is a missing setting in the original launchapp.wsf that you can copy off of the Technet site. Basically when the task is scheduled, it doesn’t expire. I dug through and found the property to set (EndBoundary). I set the script to make the task expire in two minutes. To do that I had to find a way of adding two minutes to the current time and format the date/time to fit the way that EndBoundary requires. Once adding that to the launchapp script, it wasn’t a problem.
You can download my modified version of Launchapp (PDF…my hosting provider restricts what kind of files I can upload…TXT is not one of them.). The pages that I used as reference material, or that I copied code from can be found here, here, here, here, here, here, here and here.
Let me know if it helps or if you have suggestions of how to improve it.
April 16, 2008 at 2:46 pm
Do you know how to have the launchapp.wsf to schedule with “Highest Privileges”? I KNOW it’s a weird request, but it will fix a long, complicated problem that I’d rather not go into right now.
April 16, 2008 at 3:04 pm
I think the info you are looking for can be found on this page.
That page says that to do this you need to set the runlevel property to “TASK_RUNLEVEL_HIGHEST”.
I’ll let you figure out how to add that to the script. Once you get the answer, if you could post back what you find it would be appreciated!
April 16, 2008 at 3:48 pm
Yeah, I found that page, and have been messing round for awhile. But, since I don’t really know VBScript, all I’ve added is this, following the format of other things in other examples:
‘********************************************************
‘ Set the principal for the task
‘********************************************************
Dim principal
Set principal = taskDefinition.Principal
principal.RunLevel = TASK_RUNLEVEL_HIGHEST
Or, instead of TASK_RUNLEVEL_HIGHEST, I think it may be 1. The former creates the task, the latter doesn’t, but neither actually have the checkbox marked for “Run with highest privileges.” If I could also just edit it to call from an XML file (which IS possible), would be great, but, even though I see the page on that site for it, I don’t understand it, and they give no examples.
April 16, 2008 at 3:51 pm
Yeah, I also had a hard time finding information on this as well. It is definitely not well documented…or at least not in such a way that those of us who don’t know what we are doing can do something useful!
April 16, 2008 at 4:37 pm
Apparently that does work — however, it requires admin privileges now to run the script, which, of course, defeats the purpose. *sigh* Now if I could find the way to import an XML file, THAT might work.
April 16, 2008 at 4:37 pm
Oh, and it works with the principal.RunLevel = 1, instead of TASK_RUNLEVEL_HIGHEST