We deploy software using VBScripts under Active Directory. We specify programs to be executed in the script and set the script to run in a GPO during Computer Startup. Most programs run fine during this stage of the Windows boot process, but Setup programs created using Installshield hang up if executed during Computer Startup. The setup program just sits there with out any notifications until the Windows Startup Script section of the Windows boot process times out. If the setup program runs under the user environment, then it installs the product as expected. This problem definitely occurs with Windows 2000 with all Service Packs and all the computers I have tested. This issue involves other 3rd party programs we use on campus, but the problem itself is with the Setup program (Installshield) that is used to install the product. Is there a way of running Setup programs created by Installshield during the Computer Startup process when Windows loads?
0 Comments   [ + ] Show Comments

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.

Answers

1
I have seen problems with DCOM being set to run InstallScript as "interactive user" as opposed to "launching user". When this is the case and it runs during startup, it tries to run as local system and dies. If you change the launch identity of "InstallShield InstallDriver" to "Launching User" using DCOMCNFG.EXE you may see the problem go away. In my case, this was caught early enough to update the baseline image that was being deployed, if you have an established environment, you will have the fun task of automating this change. I did a quick look around and did not see any "friendly" solutions to automating this change.

See this FAQ item for more detail:

http://itninja.com/question/what-is-pxe?6

Whether or not this is your problem, I recommend turning on MSI logging and having a good look at the installation log for errors. Logging may be turned on through policy or by setting the registry entries documented here:

http://itninja.com/question/what-is-pxe?3

Good luck!
Answered 11/17/2003 by: bkelly
Red Belt

Please log in to comment
1
Thanks for the reply bkelly. I'll give that a try and post back on my findings.
Answered 11/18/2003 by: cuallen
Senior Yellow Belt

Please log in to comment
1
I have looked all through the DCOM list, but I can't seem to find anything related to Installshield, ISScript, or the InstallDriver. Can I create it? Might I be looking in the wrong place?
Answered 11/18/2003 by: cuallen
Senior Yellow Belt

Please log in to comment
1
You should not have to create it, if it is not there this is unlikely to be your problem. Turn logging on in the registry and have a good look at the log file generated when you attempt to run the installation during startup. This should expose the cause of the problem.
Answered 11/18/2003 by: bkelly
Red Belt

Please log in to comment
1
Well I found the Installation for the ISScript engine. After I installed it, I saw the two entries you mentioned in your post, and only the InstallDriver needed to be changed. I tried a test run and I still have the same problem. I enabled loggingn but I'm not sure where the log file is located. Where is the default location for the log?
Thanx
Answered 11/18/2003 by: cuallen
Senior Yellow Belt

Please log in to comment
1
Look in %TEMP% or %WINDIR%\TEMP
Answered 11/18/2003 by: bkelly
Red Belt

Please log in to comment
1
Please excuse my input however this is a topic I have a great deal of experience with.
I am presently on contract to Shell where we use AD to distribute applications via MSI. We however repackage virtually all of the vendor installs. I encountered this behavior with InstallShield installations the most recent was Landmark GeoGraphics 2002.1.

The application contains a great deal of COM and contains a custom setup dll file that will only run inside of their install. However the InstallShield msi will not run in a non-user shell thread. I ended up talking to one of the engineers at InstallShield who admitted that there is a known problem and their working on it.

There does not appear to be any work around for the problem and the problem would appear to apply to the InstallShield Engine version 7 and 8.

I hope you find some other cause for this. But your description matches our experience to closely.

Regards
Answered 11/19/2003 by: Robo Scripter
Orange Senior Belt

Please log in to comment
1
Thanx for all the info, I have an open support ticket with Installshield. They keeep bouncing me from support rep to another. I was hoping to repackage as little as possible. I was considering purchasing Installshield's AdminStudio, it has several nice features for repackaging, but if they may have a similar problem with their MSI packages then I'll have to scratch them off my list. Wininstall is even more worthless. Which repackaging utility would you guys recommend?

I have turned on the logging feature, but I can't find the log file. There were a couple of older logs in the %Windir%\Temp directory, but they were for other installations. I cleared all the temp files and tried running the setup program again at startup. Checked again for a log file, I even performed a text search, but no log file. I suppose the installation may not be getting far enough along to write any log info? I'm starting to believe that my attempts for an answer are futile.
Answered 11/19/2003 by: cuallen
Senior Yellow Belt

Please log in to comment
1
You are very welcome for the information.

We are Wise Shop and write all of our installs in Wise for Windows Installer 4.21. However with the evolution of the product we are about to convert to Wise Package studio.

Wise has various advantages dedicated for the repackaging of applications. InstallShield I have found is better designed for the support of the software developer.

Wise is more native to the Windows Installer and does not require any permanent installation of an external script engine.

Regards,
Answered 11/19/2003 by: Robo Scripter
Orange Senior Belt

Please log in to comment
1
If you snapshot making this change with dcomcnfg.exe, then it appears that it just deletes a registry setting. Perhaps you could write a VB script (or MSI?) to delete this registry setting.
Answered 02/05/2004 by: mrtap
Senior Yellow Belt

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