One of my areas of responsibility is the EV Outlook addin install, and a common subject I'm asked about is reboots. In this post, I'll explain a little about why reboots are sometimes required, how Windows Installer (the technology the Outlook Addin install uses) deals with this, and how we recommend you roll out the Outlook addin.
Why do installs need reboots?
The most common reason an install might need to ask for a system reboot is because it needs to replace a file which is in use by another application on the system. As a simple example, suppose have the EV Outlook addin installed, and Outlook is running. At that point, Outlook would have loaded Valkyrie.dll (which contains much of the client logic that makes the addin work) and locked the file. File locking is an intrinsic feature of the Windows file system designed to prevent critical files being changed while applications are in the middle of some (possibly sensitive) operation. If you upgrade the EV Outlook addin while Outlook is running, the install is unable to replace Valkyrie.dll because it's in use by Outlook.
There's a mechanism in Windows to deal with this - if a file could not be replaced because it was locked, that is recorded, a tempoary copy of the file is stored, and the replacement is done the next time the system starts up (for example, during a reboot). This is the only time that file is guaranteed to not be in use, because the applications using it haven't been allowed to start up yet. Until this happens, the application may not behave correctly as one of its files has not yet been updated properly - in this case the system should be rebooted at the earliest opportunity to bring everything into line.
Most installs have logic to deal with this in some way. These generally fall into 2 categories:
- Closing the application (or stopping the service) which is using the file. This may mean that a reboot is unnecessary.
- Accepting the fact that you might have to reboot, and if so ask for a reboot at the end of the install.
Some applications use techniques such as shadow copying to avoid locking files - this involves changes to the application, however. In our case, the files are often locked by applications we don't own (Outlook, or components of Windows) so this option doesn't apply in this case.
Why is XP different to Windows 7?
In the case of Windows Installer, the traditional (XP) method was to detect whether a file is in use by applications with visible windows (such as Outlook), and show the FilesInUse dialog to give the user the choice of closing the application (unlocking the file) then clicking Retry, or attempting to continue and reboot at the end. If an application without a visible window (such as a notification area application) has a file locked, then the user is not prompted and the install schedules a reboot.
Beginning with Vista, Microsoft introduced Restart Manager into Windows Installer, which offers to close applications for you then start them up when the install has finished. If the application has been developed to support this, it can save its state so the user can pick up where they left off.
Depending on the information Restart Manager is able to obtain about applications, it may also fall back to the XP-style logic and show the FilesInUseDialog. You can also disable Restart Manager by using the MSIRESTARTMANAGERCONTROL property (more on that later).
Why do odd applications appear in the FilesInUse and Restart Manager dialogs?
Occasionally, a file is locked by a component of Windows. If you see Outlook (or even OUTLOOK.EXE) in a list of applications the install wants you to close, you probably know what to do. Windows Explorer? Windows host process (Rundll32)? What are these, why are they locking our files, and what do we do about it?
In the context of the Outlook Addin, this happens most often with VaultCacheIndexer.dll, which is our Windows Search (previously Windows Desktop Search) integration.
| Application | Description of application | Why it might load our files |
| Outlook | Mail client and host for our addin | DLLs such as Valkyrie.dll and DesktopClientCache.dll provide much of the Outlook Addin functionality - Outlook has to load them for the client to work. VaultCacheIndexer.dll is also loaded for the Windows Search integration (the search bar at the top of the Inbox) |
| Windows Explorer | Standard Windows file manager | VaultCacheIndexer.dll is loaded for the Windows Search integration (the search bar in Windows Explorer and in the Start Menu) |
| Windows host process (Rundll32) | A utility used to call an arbitrary entry point function on a DLL from the command line | The Indexing Options control panel dialog is implemented as a call to this utility, and VaultCacheIndexer.dll is loaded in that context in order to correctly display the Virtual Vault index location in that dialog. |
| Windows Search Protocol Host | The process which hosts Windows Search plugins in order to provide search functionality | VaultCacheIndexer.dll is loaded to perform searches against Virtual Vault. |
| Windows Search Indexer / Windows Search service | A service which indexes content in the background for later searching | VaultCacheIndexer.dll is loaded to generate indexes for content in Virtual Vault. |
What are my options to control prompts and reboots?
The first thing you can do is run the MSI from the command line - if you are rolling the client out silently then this is probably how you are going about it. There are several options that are only available from the command line. Click Start > Run... and type the following:
msiexec /?
To suppress (almost) all prompts, use /qn - this will cause a sensible default to be picked in most cases. If the FilesInUse dialog is shown, the install assumes you would have clicked 'Ignore' and you're likely to get a reboot at the end (since there's no UI interaction, there's no warning either). To suppress the reboot, add REBOOT=ReallySuppress to the command line
I say 'almost all prompts' because Restart Manager prompts still show - they're not processed by Windows Installer's normal messaging system. You can add MSIRESTARTMANAGERCONTROL=Disable to the command to suppress this and force the FilesInUse behaviour.
So after all that, you will likely have something like this:
"Symantec Enterprise Vault Outlook Add-in-en.msi" /qn /l*v c:\temp\ev-add-in.log MSIRESTARTMANAGERCONTROL=Disable REBOOT=ReallySuppress
Now, if a reboot really is required, the user doesn't know this because you're suppressing all prompts, and the application could be in that broken state we talked about because you're suppressing reboots. That means you probably want to configure your rollout software (or whatever bootstrapper application you use) to check the exit code of msiexec. An exit code of 3010 would mean you should have that software prompt the user to reboot at their earliest convenience in order to fully complete the install.
