Systems Management

Hi Regen

The setting you refer to about logon optimisation was already set at default domain level, so unfortunately, this is not why it's not installing. I agree with you about only using msis to deploy applications via AD, unfortunately, Ansys in their ultimate wisdom have decided to move away from msi to setup.exe. With licenses costing around £28,000 each, the vast majority of their users will probably only install the program on one machine. However, trying to deploy this application in a University environment (with University priced licences - 1400+ pcs) is causing huge headaches! I've been told that Ansys will provide an msi, but we'll have to pay for it!

Hi Jenny,
we all have this problems with non MSI installers. One of the easiest ways to deal with that, is an MSI wrapper.
This is why i put the link to WIWW in one of my earlier posts. You should really give that a try.
You can put an install and an uninstall string into it with a wizard.
Regards, Nick

Jenny,

If this package is being automated with a ISS file, try adding the command line argument -SMS to your setup command line. This is designed to have the setup wait until it is complete before continuing (or exiting) your batch script.

Bob

Hi Bob

I have previously tried the SMS argument, but it still didn't have any effect. The command line that I use works - when it feels like it! and that is usually only 1 time out of 10 !

I've tried the wrapper suggestion and this doesn't work either. [&:]

Jenny

Hi Jenny,
what means "doesn't work either"? Did you log the MSI and the setup.exe? Does it work from the command line?
Regards, Nick

Hi Jenny,
use: start /wait setup.exe

Your approach isn't very robust. Are you sure, a startup script has all the necessary privileges to install this app?
Regards, Nick

Hi Nick

Thanks for the quick response. I've tried the start /wait command, but the setup program still does not launch. There is a pause, but not long enough before the logon box appears.

Start up scripts in group policies are put in the Computer Configuration section and therefore have the highest privileges of all.

Jenny

Hi Jenny,
strange. Are you using a machine or user startup script?
You could do it with a few lines of vbscript. See:
http://support.microsoft.com/kb/296702
Or even better (IMHO): Use WIWW. See:
http://www.vinsvision.com/Articles/tabid/66/EntryID/15/Default.aspx
Regards, Nick

Hi Nick

Start up scripts by their definition are machine/computer startup scripts. (Login scripts refer to user scripts). It's not a problem with rights as other startup scripts work. I've actually got the damn thing to work, but it only works 1 times out of 10! For reasons that defeat me, I can get the script to run correctly and the software installs as planned. However, if I repeat the script on the same machine (rebuilt), it just sits there and does nothing! I'm going to go back to basics and recreat the .iss response file in case this has got corrupt.

Thanks for your help.

Jenny

Hi Jenny,
oh yes of course are the startup scripts per machine. Looks like, i was lost in space, when i read your post. :-)
Good approach, to check everything involved thoroughly. Do it with the network and the share too.
And log the beast. This should be possible with a installshield setup.
But as i wrote before: Would leave this method of deployment as soon as possible, because startup- and/or login-scripts are definitely not built to do full setups.
Regards, Nick

Hi Jenny,
I think the problem you are encountering is not so much about the package itself, but about how you have your domain setup. From what you are saying, I am guessing that your desktop machine is Windows XP or later. You have encountered the problem of "Fast Logon Optimization" that was introduced in Windows XP. Every System Administrator I know turns it off to avoid these sort of problems with logon scripts and startup scripts.

First some history. When Microsoft brought out Windows XP, they wanted to maintain the impression (to the end user) that it was booting in the fastest possible time. I think they were targeting 30 seconds as a boot time. Windows XP takes longer to boot than Windows 2000, so Microsoft changed the appearance of what is happening. In my opinion, they actually cheated rather than fixing the problem. They are counting the point at which the user can logon (type in their password) as the time it takes to boot. What they did is allow the end user to log on before the networking sub-systems are fully started. This means that they usually log on with cached credentials, don't get to run login scripts, don't process GPs etc. All over, it is just bad news for a managed domain. Microsoft admit that it causes problems. See http://support.microsoft.com/kb/304970/en-us. This is almost exactly the problem you are seeing. For details on Fast Logon Optimization, see http://support.microsoft.com/kb/305293/en-us.

To overcome this, you need to turn off "Fast Logon Optimization" in a GP that applies to all your desktop machines. I recommend configuring it in the "Default Domain Policy" at the root of the domain. The setting you need is: Computer Configuration > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon = Enabled.

Apart from the GP problem (which I have set to Enabled in my domain), I have also encountered problems with an Installshield install that I was trying to run as a startup script. My batch file (*.bat) ran perfectly when logged on and run as an administrator, but when I tried to run it as a startup script, it just hung and the Group Policy processing engine decided it was taking too long, timed it out, and cancelled it. In my case, I was trying to install OpenROAD 4.1 with SP3 from Computer Associates. This includes Ingres/Net client version 2.6. During the install, a dialog would show "Configuring Ingres". When run as an administrator this dialog would display for exactly 13 seconds and then proceed on from there. When run as a startup script, it would sit at this dialog for over 20 minutes before it was timed out and cancelled.

This was my first attempt to deploy software using the vendor's non-MSI installer. I have always repackaged to MSI in the past, but due to the complexity of this application (it created files where part of the filename is the hostname on which it is running, and has lines in the config files that contain the hostname) I thought I would give it a go. I just could not get this to work, so I gave up and repackaged it to a MSI. Group Policy is built to deploy software via MSI, so I went back to what I know works. I have not 100% finished this yet, but it should be finished in a couple of days. Then I will know how successful my repackaging is, but so far it is working perfectly. I had to script the parts where it has the hostname in the config files using an embedded VBScript, but I found that the first time the service starts, it creates the files with the hostname as part of the filename. I then only had to script the deletion of these files on uninstall.

In conclusion, I have lost faith in non-MSI deployments via GP after only one attempt. I think I will go back to repackaging everything to MSI when the vendor supplies it as a non-MSI package.