Am Sonntag, 11. Juli 2010, 19:20:33 schrieb David Petterson: > Mike Morawski wrote: > > Thanks for the continued support. I have it working, somewhat.. I did > > > > what you said and no change, I also got rid of everything and just tried > > the install line (and put install files locally and nothing else). After > > that didn't work I looked for some debugging logs the program might > > output. Found them, and it was trying to launch another install from > > it's own install (instmmc.exe and hhupd.exe) > > I had a lot of problems with missing %COMSPEC% /C <command> >nul 2>&1 > Every time I run a manual install it worked, but when I run it with the > wpkg client it failed. Now I use %COMSPEC% /C and >nul 2>&1 to most of > my commands that is not MSI-packages. You need %COMSPEC% for any command built into cmd.exe, i.e. mkdir, copy, start, del etc. You don't need it for anything else, especially commands that resolve to executables, i.e. anything ending in .exe, whether the .exe extension is explicitly given or not. > Don't know if it helps, but in XP you can force start a CMD to run as > system, very handy while debugging and testing packages. > In a CMD, run "at xx:xx /interactive cmd" where xx:xx is the time you > want it to start. It has to be %TIME%+00:01 or it will start the next day. That's very handy for simple tests. You might also have a look into psexec[1]'s -s command line switch which allows to run a process as SYSTEM right now. "psexec -s cmd" yields a nice system shell on localhost. With that you can easily verify the usual problems: missing permissions to the wpkg and/or %SOFTWARE% shares, installers that fail when they can't interact with the desktop etc. > > I can't get it to NOT install those files. I was hoping I could skip it > > and try installing that file manually but there is no config to disable > > that file from being installed. So what I did is compiled an EXE to > > return code 0 and put it in the files place. After that, it goes > > through. I don't think I need those particular programs (it looks like > > an update for win98 computers) so... so far so good. > > > > I would still like to know why it seized up when getting to that file > > through the service call and not otherwise. However I've put so many > > hours into figuring this out (mostly personal time) that I'm going to > > call it a day with what I have. Thanks again. Although the situation's much improved over the last decade or so, there are still some installers that somehow fail when they don't have access to the interactive desktop as is the case when started by a non-interactive service. One example is the DirectX installer, which apparently needs a desktop session. In this case the solution is to copy the files directly and not leave the setup program alone. You've found a very different solution to your specific problem .exes. But there's no general advice how to solve such a problem and it can take quite some time to find a viable workaround. Cheers, Malte [1] http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx |