When accessing the newly configured /CRTSRV service on a windows 2008 server, we were thrown the following error.
HTTP Error 500.19 – Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Module CustomErrorModule
Notification SendResponse
Handler Not yet determined
Error Code 0x80070003
Config Error Cannot read configuration file
Config File \\?\C:\Windows\system32\CertSrv\en-US\web.config
Requested URL http://localhost:80/certsrv/certfnsh.asp
Physical Path C:\Windows\system32\CertSrv\en-US\certfnsh.asp
Logon Method Not yet determined
Logon User Not yet determined
Browsing to the directory showed that:
Config File \\?\C:\Windows\system32\CertSrv\en-US\web.config
File is missing or does not exist.
This was somewhat frustrating because it was a fresh instance of Windows 2008 server and the service had just been added and configured without error.
The long and short of it all for us was that it related to the fact that the server was a 64 bit server, and in IIS by default, 32 bit applications are enabled.
To fix the problem we started IIS.
Browsed to the Application Pools and ensured that the application pool for the CRTSRV service had “Enable 32-Bit Applications” set to False
This made the site come alive!
(Can’t help but comment how sucky it is that this does not just work out of the box. Even if I cut MS some slack and acknowledge how many variables are in place for this type of configuration, it still SUCKS that the status error code thrown is as good as meaningless! – This is why I hate MS more and more every day!)
Thanks for this post, I’ve spent quite some time searching – who would have thought that the ‘enable 32-bit applications’ flag would kill certsrv!!
thank you very much
took a while to find this…but sure glad I did
Glad it helped.
Thanks it helped a lot
Glad
Thanks, head scratcher!!
No problemo
Thank you so much, this problem ‘ll kill me if i don’t find your article.
Once again thanks you
Note also that your Default Web Site physical path must be “wwwroot” (ie.- C:\inetpub\wwwroot).
Just fyi, it seems to also work if you create a .net 4.0 integrated app pool with “allow 32bit apps” disabled. .net 2.0 doesn’t seem to be required for it.
Interesting comment. Not sure why the path must be the wwwroot? Would it not work the same on any path on the server with the correct permissions set?
I had this problem with RPC over HTTP working for Exchange 2010 on a 2008 R2 server. I disabled 32bit applications for the defaultapppool and it fixed the problem. After doing searches relating to Exchange, I couldn’t find anything to fix my problem. Excluded Exchange from the search and I luckily found this. Goes to show you that you must think far outside the box when troubleshooting MS products. Thank you very much!
Thanks for the notes.
Thanks a lot for your article!
I have spent numerous hours researching this, have addressed ACL and appPools multiple times to no avail,
YOU NAILED IT…..
THANK YOU.
You are welcome. If you blog, please back link to this.
Thanks so much for sharing your solution to this annoying problem. I too was working on a freshly installed, fully patched WS08R2 system and was baffled as to why the default configurations weren’t working. Now I can move forward! 😀
You are welcome!
Hi,
It work for me to change the Application pool to 32Bit .
thank you