Well, I guess I shouldn’t really fault VirusScan, this is more of a Microsoft Installer issue than anything.
A little background: We run the campus site licensed VirusScan Enterprise on all our lab machines (and all of the admin machines as well). We started the year with version 7.0, then 7.1 came out. This is when things got wacky.
First, I built a custom install package with Installation Designer that had the same settings as we used before. Some workstations got the settings again, some defaulted back to the defaults (update weekly, Friday 5 pm), and a few even lost the scanner service completely!

The ones that lost the scanner service had the install fire off right as the machines rebooted. The installer would start up before the McShield services were completely started, stop them for the uninstall and the service manager would start it right back up, thinking it was a crash. When this happened, the files would be in use, so they couldn’t be replaced, but the upgrade would ‘succeed’. Not. I solved this by adding a 3 minute sleep before the package would install.
For the ones that went back to the default update schedule, I tried applying the same registry changes that changing the schedule in the GUI did, but that didn’t seem to work. So, off I go again, creating a new install package.
This time, I add a task to update on startup, just for good measure. Now, I try pushing this out to the workstations as a ‘reinstall’. No dice, the test machine goes back to the Friday at 5 pm schedule. Look at the log files, nothing worthwhile, it uninstalls the old install and reinstalls the new. One last thing, lets uninstall the package manually first (NAI KB article, add ‘ /qn’ to that to make it quiet and unattended) and then install the new package. Bingo, this works. Now, I get to roll this new package out to ~400 workstations and HOPE nothing goes wrong.
Arrgh.