This content has been marked as final. Show 3 replies
if fastinstall works but autoinstall doesn't, that gives a few hints.
fastinstall working means that paths in the install script are correct and all the necessary files are where they should be. That is a good start.
The difference between fastinstall and an autoinstall on a testmachine is merely in the targetting. For Autoinstall, you need an autoinstall permission set and an autoinstall schedule, for fastinstall interactive permission and schedule are sufficient.
A common pitfall is also to test on the same machine that you already fastinstalled the same package on... (without reverting it) - if NetInstall has already marked the product as installed, Autoinstall won't install it again!
A look in the client's autoinstall logfile (niai32.log) should reveal details too. Make sure you have the clients logfile level set to "debug" (0), this can easiest be done using the netinstall monitor (nimoni.exe) on the client.
Oh, and its a bad idea to repackage MS Office (>2000) using spy. Though it is possible to repackage MSIs, its not recommended as it requires a lot of inside knowledge. The MSI works very nice, and it is best practice to pick for each product the method that works best...
Thanks for the response, but my issues with office 2007 are rather unique. With office 2003, you could target an MSI package and supply a transform file from the office resource kit. With office 2007, Microsoft chose to give each application a separate msi file and have the installing technician use the setup.exe with a supplied .msp file and config.xml for the correct suite (office 2007 enterprise for us).
Normally i would just use the MSI package tool in netinstall 5.8, but it can't target .exe files. As a work around, i decided to use the netinstall script editor to execute the .exe file using the service account. I then created an AD group with autoinstall and interactive install permissions. It is fast installing correctly, as well as, interactive installing correctly.
Is there a limitation with using autoinstall for scripts that have no other package data?
using the execute command with the setup.exe is absolutely the way to go.
There are no restrictions whatsoever for what commands you can use inautoinstall scripts. Only if you use the service to install, you can't have packages that try to interact with the user by message boxes etc.
please check the logfile to find out whether the package does not start at all, which would hint to
o autoinstall permisson
o autinstall schedule/package already installed; or does start but not end, which would hint to the setup trying to interact with the user (which doesnt work for the service).
As the logfiles are excellent, there's really no need to start a guessing game...