2003 and XP startup grief

October 31, 2007 3:28 PM

Windows 2003 startup scripts. I have a little program, I want to run it on startup, my administration has helped .. a bit. I can't make it work. I've tried everything, any fresh ideas?

Thanks for clicking, I'll try and be brief. I'm in a highly locked-down Windows XP and 2003 server environment run by techs who are too distracted and busy to help much. I have written a piece of management software for the workstations in VB.NET. I want to deploy it to 20 workstations as a beta test. It is an executable that needs to run on startup on a machine rather than a user basis (lots of different users on these few test machines). Installation is not a problem - it just needs to be called on startup, every time.

The techs have allowed me to run a batch file on startup which is called from the Win 2003 server logon scripts - which are themselves batch files that they run to set up shares etc. This is controlled from the group policy (here I get lost). Perfect, you would think, *but* - either my program runs and nothing else does (ie: because it doesn't terminate and 'go away' the workstation hangs and the user can't do anything until I kill my program) - or, if I try and shell - using shellexec from a program or 'start' or any other shell or spawn trick, nothing happens, my program appears to run and then just disappears - I can't see it and it can't see me.

I should add that manually, from the command prompt everything is fine, I can shell and return to the user with my program running perfectly.

Any ideas? The whole environment is somewhat over-managed - I can't go near the registry, can't write to important parts of the hard disk and there is no startup folder. I also need to keep things very simple for the techs, who at any minute might get fed up and just tell me to get lost. I don't want to get into deployment and policies with them, making official changes on the network takes months, if it happens at all (it very seldom does). They have quietly slipped me this batch file, this opportunity. How can I use it just to load a simple program?

I can of course make any change I like to the program. If there were an equivalent of the old 'Terminate and stay resident' call, that might do it. VB.NET 2005.

Sorry to go on. I've put a lot of work into this and am near despair. I've Googled to death. Any ideas?

posted by grahamwell to computers & internet (10 comments total)

Maybe you could use srvany to run your application as a service? Although if the environment is that locked down, I'd imagine you may get resistance from your IT folks.
posted by JaredSeth at 3:37 PM on October 31, 2007

Login scripts tend to work in sequential order. I imagine the problem is that the script is waiting for an exit code so it can procede to the next step. Example

echo this is a script
\\server\share\vbnet_app.exe
net send 127.0.0.1 hello

Well, if your app is going to sit there and run then the net command will never run.

In other words you dont want to run this in a login script, you want to copy it to the machine's startup folder or edit the registry to run it (which is almost the same thing). I think running it in the context of a login script is the problem.
posted by damn dirty ape at 4:11 PM on October 31, 2007

Ideally you want to use the login script to run an installer. Wrap you app in an installer and install it on the workstations. DOnt just run it from a batch file. Google for NSIS. Or AutoIT or anything that will let you install it.

If the login script runs under the context of system then you'll have full local admin privs to install this thing, so that means you can make your own startup folder, etc.
posted by damn dirty ape at 4:15 PM on October 31, 2007

In other words you want to tell your admin "I want you to install this app to all these computers." Not "I want you to run this app."
posted by damn dirty ape at 4:19 PM on October 31, 2007

i think if you start a program from a batch file and the program doesnt exit or tsr then the cmd window stays open. which might hang the login process. your batch needs to be run using a call cmd in the main login script. so that the main login script continues after "call"ing yours. in order to run an exe without holding up the batch file u have to use the start command.
posted by browolf at 4:52 PM on October 31, 2007

Hmmm... start, shellexec don't work? You can't just install it everywhere, all you get is an entry in the login script? This doesn't sound like a tech question, actually. It sounds like a social engineering question.

Buy your IT guys beer. Be friendly. Eventually you'll be able to get them to tell you what they've done that kills your program, or help you figure it out, or give you a better way to do it. Right now, you're just that annoying dude with the useless VB program they don't want or need. Become the guy who buys IT guys beer who has a neat program that will make things easier for the IT staff (that is ultimately what your program should do, right?).
posted by TeatimeGrommit at 9:33 PM on October 31, 2007

Stuff run from startup scripts (as opposed to logon scripts) runs with the credentials of the local SYSTEM account, which isn't allowed to do any interaction. There's a registry entry (and a group policy) called Run Startup Scripts Visible, which will at least let you see the console window your batch file is running in, but it still can't accept any form of input. If a startup script causes some kind of error that would normally require user input, it will just hang.

But if your techs have just given you a call to your own batch file in their existing logon scripts, which is where you'd typically do stuff like mapping drive letters to network shares, this doesn't apply. Logon scripts run with the credentials of the user who is logging on, and they can do interactive stuff.

Another logon script gotcha is that the current directory will usually be set to some bizarre UNC path, but cmd doesn't understand this and will set the current drive and directory to wherever Windows is installed instead. If you're relying on mapped drives, those might not be available yet, depending where the techs have called your batch file inside their own.

If you need to launch a program and keep it running after control returns to the script that launched it, the right way is

START "Label for start window" "drive:\path\to\your\program.exe"

or, if \path\to\your\program.exe has no spaces in it,

START drive:\path\to\your\program.exe

will work. The difference is that the second form has no quotes. Yes, that's right - START really is brain-dead enough to look for quotes around its first argument, and if it finds them, interpret it as a window label; if your code is installed in a subfolder of Program Files, this will bite you.

If I were in your shoes, the first thing I'd be doing is trying to launch Wordpad from my tech-enabled batch file, just to prove I could. Then I'd be using START to do the same thing, just to get START under control (wordpad.exe typically lives in "C:\Program Files\Windows NT\Accessories", which has lots of lovely script-embuggering spaces in it). Only then would I introduce the complexity of trying to launch something that, you know, actually does something.
posted by flabdablet at 9:52 PM on October 31, 2007

Another trick I've used for this kind of thing is launching whatever as a scheduled task. Set it to run every five minutes. It won't re-run if it's already running, and you even get to specify what credentials to run it with. If it's not vital that your app wakes up the instant a user logs on, this trick might work for you.
posted by flabdablet at 10:07 PM on October 31, 2007

I don't know what your program is trying to acomplish, but it seems like what you want here is a Windows Service. You can create these in VS 2005 with a Wizard. The relevent namespace here is: System.ServiceProcess

Yes, I realize I may have just said "Go re-implement you app" and perhaps there's a reason that you aren't doing this as a service but to me it really seems like that's what you should be doing here.
posted by mge at 3:10 AM on November 1, 2007

Lots of good advice, thanks to everyone. JaredSeth and mge, you are absolutely right, it ought to be a service and it will become a service in short order. The .exe route was an attempt to keep things simple and easily deployable for beta builds, that route is clearly going nowhere.

The route was taken because I was told that "we can only implement services across the whole site". The more I think about this the less likely it seems to be completely accurate, particularly given the mess of machinery on display.

None of the practical suggestions worked however. There is something strange going on with this batch file. It is as if, when the batch file finishes, all its child processes die as well. I suspect that this is actually a feature, but I'm surprised that I can find no reference to it, none at all - and believe me - it's not for want of looking. It does seem to me just impossible to do what I want by using this hook and I will have to find another way.

Teatimegrommet of course has it exactly right. It is a question of getting the techs on-side. The best course of action seems to be to press on and develop the service and go through official channels to get it implemented properly.
posted by grahamwell at 7:25 AM on November 1, 2007