Greetings! My name is Keith Newham. 

As a software developer in test for the Forefront Client Security (FCS) team, it’s important to ensure for every component I test, troubleshooting problems during the installation of a product is deterministic and preferably pain free.  In particular, FCS uses Microsoft Installer (MSI) for most of its components.   MSI is built into the operating system, and is known to us as ‘MSIEXEC.EXE’.   From a command line you can run this program and you’ll see the offering of parameters in a dialog box.   It works primarily on files with a MSI extension, amongst others.

Of interest here are the logging options.   Whenever I perform an installation, my preference is to append ‘/l*v install.log’ to the command line or similar to ensure a fully verbose output.  

For example, one of the MSI specific steps for upgrading from FCS Eval to FCS 1.0 (see http://technet.microsoft.com/en-us/library/bb625082.aspx) is:

‘Msiexec /i filelocation\ FCScs-kb-939366-x86-enu.msi /qn REBOOT=ReallySuppress’

For my testing, I adapt it to the following:

‘Msiexec /i filelocation\ FCScs-kb-939366-x86-enu.msi REBOOT=ReallySuppress /l*v FCS939366.log‘

Without the verbose logging option, installation problems can be hard or impossible to track.   With the option, the installer logs EVERYTHING.   In fact it’s so verbose, it can be somewhat overwhelming.  I also chose to eliminate the quiet ‘/qn’ option which otherwise suppresses installer user interfaces.  It’s good to watch the installer show its progress.

This brings me to the real goal of this post – how to interpret that log.   Memorize this phrase:  ‘Return value 3’ (be sure to substitute for the language specific version of the phrase if you’re running on a non-English OS).  Searching for this phrase in your log will generally pinpoint the cause of any major issue.   Or, at least, it will put you near a section of the log where problems led up to this failure.   This works most of the time.   Otherwise, patience will prevail here.   Since all installer logs, however verbose, contains a similar set of internal ‘stages’, with experience you will gather a better feel for where the problem is rooted.   Other phrases might come in handy, such as ‘error’ or ‘fail’.   That said I’ve found the best method is to maximize your text editor’s window of choice and page-up until you see a grouping of log output lines that are suspect.

Also, for FCS, during server installation, be sure to check for any other logs that get populated under ‘…\Program Files\Microsoft Forefront\...’, since these get embedded in deeper subdirectories depending on the sub system being installed.

I hope this gives you a running start on installer troubleshooting, both for FCS and any other product you encounter.   

Hi Folks,

Here’s a FCS Best Practice from the Engineering team for those of you that have deployed or will deploy multiple FCS deployments across an enterprise.

Best Practice:  As indicated in the FCS v1.0 Release Notes, each FCS deployment should be given a unique Management Group name during FCS Server setup.

We would like to hear from customers who have multiple FCS deployments with identical Management Group names by emailing mcpfdbck@microsoft.com

To find the FCS Management Group name:

1.       At the Management Role machine for a given deployment:

a.       Click StartàAll ProgramsàMicrosoft Operations Manager 2005àAdministrator Console.

b.      In the MOM Administrator Console, click on Console RootàMicrosoft Operations Manager(<servername>) and record the name of the Management Group in the main window.

c.       Repeat for the next FCS deployment.

2.       If you find any identical names, let us know!

Thanks,

Eduardo Villasenor

Program Manager

Forefront Client Security