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 http://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 (http://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.
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: http://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.http://support.microsoft.com/kb/246459/en-us
Hope this helps....
Thanks for awesome article.
I have a similar question. I want to run IISADMIN service uner domain user account instead "Local System". I tried to start the service with Domain Admin Account but it fails horrendously.
Can you please explain what user rights do I require and is it possible?
Thanks for reading this. I can be contacted on "firstname.lastname@example.org".
I don’t know the exact permissions required for IISADMIN to run on a domain admin account; but with that said Microsoft never recommends running this service with any other account except “Local System”. We have seen issues wherein giving all the so called assumed permissions etc still breaks the system.
Please remember that this is an unsupported scenario and Microsoft never recommends it.
Hope that helps.
For some days now we have been seeing support incidents where IISADMIN service is up and running, however other IIS related services like WWW, SMTP etc do not start.
In such a scenario please check the link mentioned in the post and here below if it justifies the symptoms related to duplicate c23 keys. If yes follow this article and you should be good.
you rock. You helped me fix this issue without a reinstall and i didnt have the disk! Thank you.
your solution regarding the multiple C23-keys applies to the "Reseal and IIS" issue, too.
After resealing and cloning my images the IIS is not starting because the MachineGUID has changed. Thank you
Wow, thanks so much for this. This happened on a client's computer and your article pointed me to the correct solution in little or no time. Was not looking forward to having to reinstall IIS to resolve.
I agree with Jason, YOU ROCK!
i was encrypting my web.config connection strings and i played around with the keys...
fortunately i did a backup of all the keys including the c23 one.
just placed the old one and now everything is fine.
Thanks for this superb info. my issues with IIS could not start has been solved. need to reinstall IIS though and reconfigure the whole app, but its better than wondering what to do. I can't find anything more complete than this on the whole web. Thanks a World!!! Thanks again.. and again and again...
This article was very helpful, it helps me to fix my problem. Our IIS server metabase was missing and was renamed as a bin file. Is there a known virus that will rename an filename.xml to filename.bin?
I suspect that it was renamed by a malicious so called "hacker???".
Thank you for this article. Have been looking for hours to find something to help with my situation. After, trying everyone else's, yours worked! Thanks so much!
The %SystemRoot%\system32\inetsrv\MetaBase.xml on my server appeared to be complete and valid XML. I restored the MetaBase.xml from around 4 hours prior to when issue occurred, did a comparison and found that whilst both files had identical lines, the long numbers on some lines were different.
I saved the current MetaBase, copied the backup copy into that folder and tried starting World Wide Web Publishing Service, which also starts IIS Admin Service. Worked perfectly, so restarted the server and now everything is running again.
So, just because MetaBase.xml looks valid, don't assume that it is valid.
I just wanted to say thank you. After about 4 hours I found your article and restored the C23* file from a backup and that resolved the issue. I think it was caused by a colleague installing Backup Exec.
Need help, when i checked security property of folder
C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
I see only administrator and everyone and both these has special permission inteas full permission and system does not exists in security tab.
My OS is Server 2008 and IIS 7, Everything is working fine, this is fresh installation.
Great, your suggestion of replacing the "MachineGUID" from the registry to in the filename worked. Thanks. Not sure what changed the MachineGUID value in the registry. Likely culprit is an AT&T vpn software.