Evolving Windows Installer Error 0x80110414 Nightmare

This blog post will evolve as I progress through this Windows Installer error 0x80110414 nightmare I find myself in. Please keep in mind this is a work in progress BUT I would WELCOME any input, battle scars, references, suggestions, questions in the spirit of working towards an acceptable solution.

Problem

A Windows Installer error Error 26105. Failed to create web application. (-2146368492 /LM/W3SVC/1/Root ) which does not happen consistently is rolling back out installation. Using Wix 3.5.2519.0, the package installs one IIS Web Site and configures a Virtual Directory under the new web site created. Running the Windows Installer again no error occurs, installs successfully. I can only reproduce this the very first time the Windows Installer is run, all subsequent installs run fine. Basically we are rolling back a VM to be able to reproduce the installation error otherwise it does not occur again.

Error Messages

The error messages below are the very first errors that Wilogutl picks up leading me to believe this is the root cause of the downstream errors with a few custom actions. This error message has been the focus of my investigation the last day or so.

1
2
3
4
5
6
7
8

(UNKNOWN)     WriteMetabaseChanges: failed to open '/LM/W3SVC/AppPools/MyClientAppPool/' key, retrying 30 time(s)... 
  (UNKNOWN)     WriteMetabaseChanges: Error 0x80110414: failed to create web application: /LM/W3SVC/1/Root 
  (SERVER)     MSI (s) (B8!24) [11:07:20:553]: Product: My Client Application (MCA 02.00.01) -- Error 26105. Failed to create web application. (-2146368492 /LM/W3SVC/1/Root ) 
  (UNKNOWN)      
  (UNKNOWN)     WriteMetabaseChanges: Error 0x80110414: failed to create ASP App 

  NOTE: Look at few lines above for clues on error
  (ERROR)      Action ended 11:07:20: InstallFinalize. Return value 3.

Reference Similar Issues

Just a summary, in case anyone has the similar issues in future:

The initial problem was: if you try to create an iis:WebApplication with
isolation="medium" or isolation="high", the installation failed and
rolled back logging the error "0x8004E00F: COM+ was unable to talk to
Distributed Transaction Coordinator (DTC)".
The attempt to start DTC service manually failed with the same error.
This was fixed by resetting msdtc log:
http://windowsitpro.com/article/articleid/75902/jsi-tip-4593-you-receive
-an-error-when-opening-the-component-services-mmc.html

Next, it became to fail with the error 0x80110414. This was fixed by
synchronizing the ISUR and IWAM users passwords in system security
storage and IIS metabase: http://support.microsoft.com/kb/297989

User names and passwords for the IUSR_ComputerName and IWAM_ComputerName accounts are stored in three locations:

Internet Information Server (IIS) metabase
User Manager for Domains (Windows NT) or Local Users and Groups (Windows 2000)
Microsoft Transaction Server (Windows NT) or Component Services (Windows 2000)
If the user names and/or passwords are not synchronized among these three locations, you receive the above-mentioned error messages.

Debugging Sessions

One of the major challenges the errors can not be reproduced in our internal environments BUT can be replicated at the client testing site by rolling back to a VM snapshot. The snapshot contains our prior version of the application which is uninstalled prior to installing the new version. Additionally, both the prior version and new version both exhibit the same error when run against the VM snapshot. Again, both install fine the second run. The team built a NEW clean VM environment, installed the new version and received the same errors as before.

It is important to note the web site and web applications are both running under Medium trust. This means each have their own COM+ application, i.e. IIS COM+ application package that run out-of-process.

  1. Verified all permissions and assumptions for server installation have been met.
  2. Confirmed the client is indeed changing the IUSR_ pwd for the machine.
  3. Ruled out MSDTC and Component Services preventing installation.
  4. Removing the COM+ Applications Programmatically created for the medium trust applications.
  5. Install and Uninstall with verbose logging, then analyze the logs with Windows Install Log Parser Tool.

TODO

  1. Review failing custom actions.
  2. Uninstall is failing, not sure why yet. However, a few manual removal steps allow the site to be installed without error.

Possible Solutions

  1. VM Environment ( ruled out at this point )
  2. Install again, ignoring initial error and continue on our way. I doubt this is an option.
  3. Ensure IUSR and IWAM accounts are synchronized among the three locations they are stored, mentioned below in MSDN KB Article – Configured Identity Is Incorrect for IWAM Account.
  4. Get a copy of the VM installation is failing on and debug this process further.
  5. Rewrite installation guide for a manual install and update the MSI to simply xcopy files.
  6. Rewrite the Wix installation.
  7. Rewrite installation using default deployment project within VS.

Checking IUSR and IWAM password in IIS Metabase

  1. Open C:\Inetpub\AdminScripts\adsutil.vbs in notepad
  2. Update line 2592 as seen below. IsSecureProperty = False
  3. Save the file.
  4. Open command prompt and change the directory to Open C:\Inetpub\AdminScripts cd C:\Inetpub\AdminScripts
  5. Request the password for the IUSR at the command prompt by running below line. cscript adsutil.vbs get w3svc/anonymoususerpass
  6. The return will look something like below but with the password in your system.
  7. anonymoususerpass : (STRING) “password”
  8. Please verify the password you receive above is the same or different password set for the IUSR on machine in Users.
  9. Request the password for the IWAM at the command prompt by running below line. cscript adsutil.vbs get w3svc/wamuserpass
  10. Please verify the password you receive above is the same or different password set for the IWAM on machine in Users.
  11. Go back to adsutil.vbs in notepad
  12. Update line 2592 as seen below. IsSecureProperty = True
  13. Save the file.
  14. Do steps 4-5
  15. Verify the password coming back is now masked. ** Double check the line for IsSecureProperty as the file may have been updated since ( do search for all instances ).

Setting IUSR and IWAM password in IIS Metabase to match the machine Users

  1. Open C:\Inetpub\AdminScripts\adsutil.vbs in notepad
  2. Update line 2592 as seen below. IsSecureProperty = False
  3. Save the file.
  4. Open command prompt and change the directory to Open C:\Inetpub\AdminScripts cd C:\Inetpub\AdminScripts
  5. Set the password for the IUSR at the command prompt by running below line. cscript adsutil.vbs set w3svc/anonymoususerpass “MyPasswordThatMatchesMachinceIUSRPwd”
  6. Verify update, request the password for the IUSR at the command prompt by running below line. cscript adsutil.vbs get w3svc/anonymoususerpass
  7. Set the password for the IUSR at the command prompt by running below line. cscript adsutil.vbs set w3svc/wamuserpass “MyPasswordThatMatchesMachinceIWAMPwd”
  8. Request the password for the IWAM at the command prompt by running below line. cscript adsutil.vbs get w3svc/wamuserpass
  9. Go back to adsutil.vbs in notepad
  10. Update line 2592 as seen below. IsSecureProperty = True
  11. Save the file.
  12. Verify the password coming back is now masked. ** Double check the line for IsSecureProperty as the file may have been updated since ( do search for all instances ).

Sync MTS or Component Services

Synciwam.vbs file to update the starting identity of all IIS COM+ application packages that run out-of-process. You may need to restart IIS for all changes to take effect. To restart IIS, from the Start menu, click Run, type iisreset, and then click OK.

To use Synciwam.vbs, type the following command at a command prompt: cscript.exe synciwam.vbs -v

Note Using Synciwam.vbs resets all out-of-process applications (Medium and High isolation) to IWAM_ComputerName.

IIS Metabase Explorer

Installed the IIS 6.0 Resource Kit Tools to enable the use of a few tools, Metabase Explorer and Permissions Verifier. The Metabase Explorer provides the ability to review the entire IIS Metabase data including the secure data. There is a good article by rafelo here. I leveraged the GUI to verify the password I received from the .vbs scripts above were indeed not encrypted and matched. There is a wealth of information in the explorer at your finger tips.

Actual Solution

TBD.

References

Comments