Troubleshooting Office installation failures

This blog will cover techniques on how to identify and resolve Office installation failures. The techniques described can be applied to the installation of Office 2003-2010, and Office patches.

ENABLE VERBOSE LOGGING

The first thing to do when troubleshooting Office install failures is to ensure that MSI verbose logging is enabled. In Office 2007/2010 there is a setup.exe log file that gets created by default, but it does not give the amount of detail that is usually required to diagnose an installation failure. With verbose MSI logging enabled we will get a verbose log file for each component that Office 2007/2010 installs. We will have a verbose log for the install of the Word component, one for Excel, and so on.

To enable verbose logging you will want to set the following registry keys.

If you would prefer to automate the addition/removal of these keys rather than adding them manually via regedit you can use the fixit programs from the following KB article:

http://support.microsoft.com/kb/958052*note* This fix it will also enable verbose logging for the windows updates site but troubleshooting windows update will not be covered in this blog article.

We should also enable verbose logging for the setup.exe log as well. This is done by adding the following line to the config.xml that is in the .ww folder of the product you are attempting to install. (This does not apply to versions of Office that are earlier than Office 2007)

If you are running your installation manually on the machine as a logged in user by double clicking on setup.exe then the log files will get generated in the %temp% directory of the user performing the installation.

The easiest way to get there: Winxp-2003 = Click on start, then goto run, and type in %temp% and hit enter. Windows Vista-Win7 = Click on start, and the type in %temp% in the search field and hit enter.

If you are running your installation via a deployment mechanism that utilizes the system account during the install, then the log files will get generated in %windir%\temp.

Now that you have enabled verbose logging and know where to look for the logs, go ahead and reattempt your installation. It it failed previously, expect it to fail again but this time we are ready to capture log files that will be detailed enough to help us diagnose the failure point.

ANALYZING THE LOGS

After your install attempt you will find that you have somewhere between 1 and 20 logs from the installation attempt in your temp directory.

Here is a screenshot of the verbose logs from an install attempt from my machine.

When looking through the MSI logs we will typically want to look for a value 3 entry in the logs. Windows installer returns codes during the install which will indicate if a particular function was successful or not.

Value 1 = Success Value 2 = Cancel Value 3 = Error

In a good install, you would typically not see any value 3 entries in the logs. So there are a lot of logs here to look at. I would recommend that we start with the setupexe log. This log will usually have a value 3 in it when there is a failure, but will not always be clear enough to diagnose the issue. If it doesn’t have a value 3 look for the first instance of Rolling back package. Rolling back package indicates that the Office installation had failed and now is attempting to “roll back” the installation. You should be able to identify the failure immediately above that point. Once you find the value 3 or the Rolling back package in the setup.exe log you should be able to identify which component is failing, and from there look for the particular MSI log that corresponds with that component.

There will often be more than one value 3, or rolling back package. You should focus on the first one you find.

Below you will find a couple real life examples of office installation failures and how we were able to identify the failure point.

ANALYZE LOGS EXAMPLE 1 – Proplus 2010 install In this example, I will search the setup log for a value 3. It is not uncommon to not find a value 3 in the setup log. In this case I didn’t get a value 3 in the setup.exe log, so next I searched the setup.exe log for Rolling back package.

This does not tell me why it failed, but it does tell me that the failure occurred during the install of the ProPlusWW.msi. Now that I know that I want to find the verbose MSI log that correlates with ProPlusWW.msi.

*note* In cases where you know the failure is in the ProPlusWW.msi log but you don’t want to save time in finding which MSI log is for Proplus, it will usually be the largest log file.

If you don’t know which log is the correct log for the ProPlusWW.msi component, open each log one at a time and scroll to the bottom. It will indicate there what component it just attempted to install/rollback.

So this is the verbose MSI log for the Office Outlook MUI component and was from the rollback. (The install failure would have occurred earlier than this) Eventually I found the ProPlus log (it was the biggest one) and the log does indicates it is the proplus log here:

Again, this does not tell me why it failed, but it does tell me that the failure occurred during the install of the AccessRWW.msi. Now that I know that I want to find the verbose MSI log that correlates with the AccessRWW.msi.

When you do see a value 3 in the setup.exe log it will sometimes give you enough information to resolve the issue without needing to look at the verbose MSI log. In this case the verbose MSI log simply repeated what we found in the setup.exe log as seen below.

In this case we should consider updating .net framework, and verifying the permissions in c:\windows\winsxs\

-BELOW ARE A FEW KNOWN ERRORS FROM VERBOSE LOGS AND POSSIBLE RESOLUTIONS TO TRY-

*NOTE* Some of these suggestions discuss working with the registry. Important- Serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: 322756 (http://support.microsoft.com/kb/322756/ ) How to back up and restore the registry in Windows

-This most commonly occurs due to issues while upgrading Office. First thing to try is to remove the previous version of Office prior to installing new version. You can remove the previous version of Office automatically using the appropriate fix it from KB290301. After removing the previous version of Office, then attempt to install the newer version of Office.

Error 1714. Setup cannot remove the older version of Microsoft Office Product_Name 2007. Contact Microsoft Product Support Services (PSS) for assistance. For information about how to contact PSS, seeC:\DOCUME~1\<username>\LOCALS~1\Temp\Setup00000d64\PSS10R.CHM.

Possible solution(s)

-Remove the previous versions of Office first if you are attempting to perform an upgrade. (Office can be removed with the Fix Its from KB290301) -Perform a side-by-side installation rather than upgrading. (Customize button)

ERROR 1719

Error 1719. Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact support personnel for assistance

Possible solution(s)

-Reg keys could be corrupt or incorrect at

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSIServer

Export from a known good machine that uses the same OS and msiexec version. Backup and then delete existing msiserver key on the bad machine under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\msiserver Import the reg file from the known good machine. Reboot, and reattempt install

'Error 1406.Setup cannot write the value to the registry key \CLSID\{13DE4A42-8D21-4C8E-BF9C-8F69CB068FCA}. Verify that you have sufficient permissions to access the registry or contact Microsoft Product Support Services (PSS) for assistance. For information about how to contact PSS, seeC:\Users\ADMINI~1\AppData\Local\Temp\Setup00000e64\PSS10R.CHM.'

2. To resolve this issue, compare the rights on HKCR\APPID from a good machine, with the problem machine. Try granting “RESTRICTED” the following permissions: Query Value, Enumerate Subkeys, Notify, Read Control

This issue can occur because permissions have been incorrectly set on the folder: C:\Windows\System32\winevt\Logs Grant “everyone” full rights to that folder, and reattempt the install. If this is successful you can remove the everyone group afterwards.

This issue can occur if the Windows Event Log service is not running. Click on start, search and type in services.msc and hit enter. Scroll down to the Windows Event Log service, and ensure it is set to automatic. If it is not running right click on it and choose start. If you get an error like the following:

Error 4201: The instance name passed was not recognized as valid by a WMI data provider.

Then please check the permissions on "c:\windows\system32\logfiles\wmi\RTbackup"

If the system account doesn’t have full control, grant the system account full control and reboot. After reboot check and see if the Windows Event Log service is started in services.msc. If it now started correctly attempt your Office 2010 install again.

This is a living blog and will be updated with more known problems/solutions over time.

Q.Y. – Please re-read this blog post. As mentioned in this blog you should be searching for "value 3" from the top of the log. The first "value 3" you find will be immediately following the actual error that needs attention.