IIS ADMIN service fail to start?

An issue that causes a lot of headache to Web Admins is when IISADMIN service does not start up for no reason.

Here are a quick troubleshooting steps you can do before you look around and yell for help or call into Microsoft Product Support services and shell out some $$.

-- Check and Make sure we have a Metabase.bin file (in IIS 5/5.1) or Metabase.xml file (in IIS 6) in C:\<%Windows%>\system32\inetsrv folder.

-- Check and make sure that we have a Machinekey starting with “C23” in the C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys folder.

-- Make sure that the MachineKeys folder has Full Control for both Administrators and System. Make sure that the “C23” key has "Administrators" and "System" Full Control permissions set on it.

IIS depends upon this key for encryption/decryption of metabase keys. If we do not have the required permissions IISADMIN won't be able to read the configuration from the metabase without this key and hence will fail to start.
(Just out of topic but, remember even for SSL you should have the above permissions because it too depends upon a machinekey in the same folder for cryptographic computations).

Ensure you have the necessary permissions according to the following KB https://support.microsoft.com/kb/278381/en-us

If the issue doesn't get resolved after checking the permissions continue reading further.

-- Check and see if you have multiple instances of the “C23” key identified above in the MachineKeys folder.

a. If you have only one instance, then check and make sure that the date on that key matches the date from the time when IIS was installed on the server. If the date is newer than the last IIS Install date, then the MachineKey that was used to encrypt the Metabase got lost and you would have to re-Install IIS (if you don’t have the MachineKey backed up anywhere).

b. Or else you can look at the suffix of the C23 key (the entire length that follows ‘_” in the C23 key) and check if it is different from any of the suffixes for other keys in the container. This means that the MachineKey (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGUID) for the machine
has changed since IIS was last installed on the machine. If you don’t have a second instance of the “C23” key (with an earlier date with a different Suffix) at this point, then you have lost the original MachineKey and would have to reinstall IIS. If you do have the earlier (older) key, then replace the suffix of the older key with the MachineGUID value found in the registry and delete the newer key. You should be able to restart IISADMIN at this point. For IIS 5 you can apply this fix (https://support.microsoft.com/default.aspx?scid=KB;EN-US;884872)
Remember that this does not fix the IISADMIN service startup problem, but prevents the C23 duplicate issue from happening again (which might be the cause of IISADMIN startup issue).

"When IIS starts it uses the registry value HKLB\software\microsoft\cryptography\MachineGUID to build the filename identifying the keyset file:
<%allusersprofile%\Application Data\Microsoft\Crypto\RSA\MachineKeys\c23***********************_machineGUID>
This keyset is then used to validate the SessionKey in the metabase(.bin\.xml) and later to En/Decrypt the applicable metabase entries.
These parts need to be in synchronization to get a successful IISAdmin startup"

-- Finally if the above steps do not help you can use MSCONFIG (Start->Run->MSCONFIG) to disable all the third party (Non-Microsoft) services and see if that helps in starting the IIS Services. If you can, then you need to start enabling the third party services one by one to figure out which one is the culprit here. If a 3rd party service is the cause you may get in touch with the vendors to get this addressed.

Additional Recommendations:

Ensure that you backup the metabase.xml (or metabase.bin) on a regular basis. A better way is to keep a transferable copy of the IIS 6.0 metabase backed up with a password. This allows the encrypted information to be decrypted and stored in a manner that allows for portability. The full procedure can be
found here:
https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/131b609d-ff3a-488f-a8dd-13044fa623a1.mspx?mfr=true

Ensure that the machine keys are also backed up in the full system backup jobs.
https://support.microsoft.com/kb/246459/en-us

Hope this helps....