This is not ISA SERVER, but Microsoft Firewall Client. Confusing name, since it isn't a firewall at all, but an interface to ISA.

You say "Avoid servers & DCs" - do you plan to remove it if present? Or are you sure it isn't installed on any servers? (Installing MSFWC on servers is usually not a good idea.)

Installing from a UNC is not a good practice. The install path is often registered in the installation settings, and the application will look in that location for updates or additional components. Causes grief if you move your installation point. Mapping to a drive letter is better. Won't be an issue for MSFWC, but other applications are problematic. This is just FYI

For auditing, create a log file locally with /L * on your MSI install command line. Use a consistent file name on the local computer, so you and any other techs can quickly recognize the file - something like C:\TEMP\MSFWC\(UN)INSTALL.LOG. When the installation completes, you can
COPY 'C:\TEMP\MSFWC\UNINSTALL.LOG' '\\server\share\logs\@WKSTA_UNINSTALL.LOG'
and then repeat for the INSTALL.LOG. This gives you uniquely named logs on the server.

When I do these kind of upgrades, I generally create TWO scheduled tasks. The first task I define has an "At Startup" trigger, which runs right after the system reboots. It starts the INSTALL process. The second task has no trigger - I use it to start the installation process, and kick it off under script control rather than at a specific time. This runs the uninstall command and reboots the system. The install runs as soon as the system reboots. You can preload these two tasks on all workstations during the day, and trigger the uninstall script from your login script. Using the tasks allows you to employ elevated permissions for the (un)install command. tcLib and jt.exe can do this with minimal coding - copies are here and on my web site. BTW - the scheduled tasks on the computers are created from a central system - a server or my workstation, so credentials are never exposed. If you trigger the event from your login script, you'll need JT.EXE in your netlogon share.

Rather than figuring out how to run once, work on determining which process needs to happen. Something like:
 Code:
If @WKSTA "is a server"
  Exit 0 ; do nothing
EndIf

; create a function that checks for the presence
; of MSFWC and returns the version number. 
$MSFWC = DetermineMSFWCVersion()
If $MSFWC = '2004'
  Exit 0 ; current version is installed
EndIf

If $MSFWC = '2000'
  shell 'uninstall commands'
  reboot
EndIf

If Not $MSFWC
  Shell 'install comannds'
  If Exist('C:\TEMP\MSFWC\UNINSTALL.LOG'
   copy 'C:\TEMP\MSFWC\UNINSTALL.LOG' '\\server\share\logs\@WKSTA_UNINSTALL.LOG'
  copy 'C:\TEMP\MSFWC\INSTALL.LOG' '\\server\share\logs\@WKSTA_INSTALL.LOG'
EndIf

This general logic permits using the same script to uninstall and install, as appropriate. I don't use the MSFWC here at home (and we've removed it from 99% of the clients at work), so I can't give any samples to detect the installed version. You should be able to determine via a combination of registry read (version or file location) and GetFileVersion() commands.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D