locked
HTTP Error 500.19 - Internal Server Error after re-installing CRM 2013 and browsing it in IIS RRS feed

  • Question

  • Hi there CRM Experts and experienced implementers,

    I have a CRM 2013 OnPrem VM Sanbox Server (running on Windows Server 2012 Standard), with a 1 box setup= CRM 2013 Full Server Roles+SQL Server.

    History today:

    I uninstalled CRM 2013 earlier today due to issues we had in our Claims Based Authentication configuration, where CRM 2013 and AD FS 2.1 were installed in the same server and when the Claims configuration failed, the CRM web started showing "Generic Error" messages every time you open a page.

    So I uninstalled CRM 2013 completely (made sure I manually deleted CRM DBs (MSCRM_Config & Organization_MSCRM)) and also uninstalled AD FS 2.1 completely because I'm going to install AD FS in a separate server for my next test deployment of claims and IFD (I've been using this guide to uninstall AD FS: http://blog.msresource.net/2012/06/15/uninstalling-ad-fs-2-0-and-deleting-the-databases/

    I have done this many times and I'd never had issues re-installing CRM 2013 until today. When I tried to install CRM, I couldn't proceed with the installation wizard on the "Select Website" page because the Default Web Site is missing and when I checked IIS, sure enough the Default Web Site is missing there for some reason. So I fixed this first by following a solution I found online: Remove/uninstall the roles 1) Web Server (IIS) and 2) Windows Process Activation Service (WAS), reboot and then re-install them back (using Administrator account of course). IIS should be installed with the Default Web Site; I proceeded with the CRM install.

    I installed CRM 2013 successfully (no errors) and rebooted the server. But when I try to browse the CRM website in IIS, I get this error:

    HTTP Error 500.19 - Internal Server Error

    The requested page cannot be accessed because the related configuration data for the page is invalid.

    <fieldset>

    Detailed Error Information:

    Module    IIS Web Core
    Notification    Unknown
    Handler    Not yet determined
    Error Code    0x8007000d
    Config Error    
    Config File    \\?\C:\Program Files\Microsoft Dynamics CRM\CRMWeb\web.config
    Requested URL    http://localhost:80/
    Physical Path    
    Logon Method    Not yet determined
    Logon User    Not yet determined
    </fieldset>
    <fieldset>

    Config Source:

       -1: 
        0: 
    
    </fieldset>


    I checked the "More Information" page --> and this is the link: http://support.microsoft.com/kb/942055/en-us

    and it says for error code 0x8007000d:

    Cause

    This problem occurs because the ApplicationHost.config file or the Web.config file contains a malformed XML element.

    Resolution

    Delete the malformed XML element from the ApplicationHost.config file or from the Web.config file.

    but it doesn't say what line or XML element to delete. I checked the web.config file (in C:\Program Files\Microsoft Dynamics CRM\CRMWeb) and I don't see any garbled XML characters in there.

    Error Page

    Any ideas on the solution? Please help; any input is greatly appreciated.

    Thanks.

    ProgCRM


    Thursday, May 8, 2014 9:10 AM

Answers

  • You say you ran this command:

    appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true

    As far as I can see, this is telling IIS to use the credentials of the AppPool account, presumably instead of the local computer account.This is what you would normally do if your CRM servers are behind a load-balancer, and then set SPNs to use the service account, which they all share.

    So what I think happened is this:

    You used setspn to set SPNs for the app pool user account. This did not work, because in kernel mode, IIS 7 is not using that account for authentication anyway.

    (Aside: If you are using a host header to access CRM by any name other than the actual server computer name, such as IFD-style OrgName.domain.com then you might need two SPNs:

    setspn –a HTTP/HostHeader  ServerName
    setspn –a HTTP/HostHeader.domain.com  ServerName

    You should not need SPNs to access CRM using the actual server host name, because when you join the IIS server to the domain, an SPN is set for the HOST service, which inlcudes HTTP)

    When this did not work, you told IIS to use the apppool credentials, so the previous SPN was now working for you.

    I think you could change your SPNs and set IIS back to kernel mode (-useAppPoolCredentials:false) and things should work that way instead.

    For production, I would really strongly advise installing ADFS on a port that is not 443 (by configuring the default web site to eg 444 before installing ADFS), and CRM on 443 so users don't have to worry about including the port number, and likewise in your configurations it is easier not to have to do this.


    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    UK CRM Guru Blog

    Wednesday, May 21, 2014 9:53 AM

All replies

  • This may have something to do with the URLRewrite that happens in IIS.  My guess is that when installing CRM you installed to a different port.

    If there are no other web sites in IIS other than CRM, it may be easier to just uninstall CRM, uninstall and re-install IIS, then install CRM again.

    Or you could google how to update the URLRewrite.


    Jason Peterson

    Thursday, May 8, 2014 2:05 PM
  • Hi there CRM friends (and first thanks Jason for taking the time to review and help),

    Here's an update/solution to HTTP Error 500.19, and a new related issue:

    I was able to make CRM work, but there's still an issue: we can't access the CRM Org via clients - we can only access CRM inside the server (when logged into the server only).

    The solution that worked for the HTTP Error 500.19 - Internal Server Error is:
    1. Complete uninstall and reinstall of CRM and IIS 8
    o Uninstall CRM (manually delete CRM web site in IIS and manually delete CRM databases).
    o Remove the server role 1) Web Server (IIS) and also the service role 2) Windows Process Activation Service (WAS), reboot, and then re-install them.
    o Reinstall CRM
    2. Log in as the Administrator account, in IIS 8, go to the CRM Web Site and then open Authentication under IIS header. Enable Windows Authentication.
    3. Log in as CRM Installation Account, run the installer rewrite_1.1_amd64_rtw located in the UrlRewriteModule folder in the CRM 2013 Server Setup files. Perform a repair.
    4. Reset IIS & Restart CRM server.

    CRM can now be accessed in the server: http://localhost/CRMORGNAME/main.aspx , and at this point I was also still able to access it via my client using my windows account. However, other team members couldn’t access through their clients so I restarted the server. After the reboot, all users can’t access CRM via clients.

    Issue: Can’t access CRM through clients (can access inside the server only)

    When connecting to the CRM Org via client, you can supply the correct user credentials but you won’t be able to access, and it will show authentication error "HTTP Error 401. The requested resource requires user authentication". (Image below):

    HTTP Error 401

    Any ideas? Appreciate your time and help.

    Thanks.

    ProgCRM

    Friday, May 9, 2014 10:16 AM
  • Hi there MSCRM Community,

    Here's an update to my previous comment & last issue "Can't access CRM through clients": 

    The actual issue is: Turns out we do can access our Sandbox server CRM 2013 Organizations via clients BUT ONLY IF using the IP Address of the Sandbox server and not the Server Name in the Org URL. --> So we can only access CRM via clients using: http://IPAddress/crmorgname/main.aspx and NOT http://servername.domain.com/crmorgname/main.aspx (which we'd normally use to access CRM Orgs via clients). (By the way, the reason I was able to access CRM via my client using http://servername/crmorgname/main.aspx (without the domain.com in the URL) was that turns out that I've added the Sandbox server IP Address in my hosts file before.)

    Any ideas? Could somebody explain what happened and how to resolve this?

    Is this because of the URL Rewrite repair that we ran (that we used to solve the initial issue HTTP Error 500.19)?

    Will we have any issues configuring this server for Claims & IFD?

    Any input is greatly appreciated.

    Thanks!

    ProgCRM


    Tuesday, May 13, 2014 8:22 AM
  • Hi there MS CRM Community,

    UPDATE: This is now resolved and I thought I share the solution I found to help others in the future.

    CRM can now be accessed via clients using the default URL. But any ideas if we’re going to have issues configuring Claims and IFD in this server and how can we avoid issues related to this? Thanks.

    Solution I used:

    I found this: https://groups.google.com/forum/#!topic/microsoft.public.crm.deployment/xj2paBGK9ug

    And I tried the suggestion – I disabled “Enable Integrated Windows Authentication” in IE, rebooted it, and then I was able to access CRM via the default URL.

    And then I also found this and tried it: http://zupi.azurewebsites.net/ms-dynamics-crm-2011-http-error-401-1-unauthorized-access-is-denied-when-connecting-to-httpservername/

    I ran the command:

    appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true

    And it worked – we can now access CRM via clients using the default URL with Enabled Integrated Windows Authentication in IE (should be enabled by default)!

    Thanks.

    ProgCRM

    Friday, May 16, 2014 9:40 AM
  • Trying to piece together your two threads on here and your comments on various blog posts, it seems you have two things coming together here:

    1. You have set your SPNs for the AppPool user account, rather than the IIS server (CRM front-end Web Server) host name (=AD computer account).
    2. Then you have changed a setting so that IIS uses these AppPool credentials instead of the local computer account (this changed between IIS 6 and 7 IIRC, so you are effectively enforcing IIS 6 behaviour)

    I suspect that if you had set the SPN to use the IIS server name, this second step would have been unnecessary.


    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    UK CRM Guru Blog

    Monday, May 19, 2014 9:34 AM
  • Hi Adam,

    Thanks for the time and help. (Btw, I really liked your MB80542 course and your blog articles; very well presented and helpful.)

    Here are my comments:

    On no. 1) Yes, I think this was a mistake and the root cause of the problem. I got confused because both CRM & AD FS were installed in this server when I first tried configuring IFD, so I ran 2 set SPN commands using the CRMAppPool Account and I thought I must register both the AD FS and CRM servers. These were the 2 SPN commands I ran:

    1. setspn -s http/adfs.mydomain.com mydomain\crmapppoolaccountuser
    2. setspn -s http/hostnameofcrmserver.mydomain.com mydomain\crmapppoolaccountuser

    I think I was suppose to run command no. 1 only, and I realized in the official Claims & IFD guide instructed to run this: setspn -s http/adfs.contoso.com contoso\crmserver$ if CRM and ADFS are in the same server (which unfortunately I didn't follow initially). I tried this command in my other Test IFD deployment where CRM and AD FS are in separate servers and it works.

    on no. 2) I don't understand what you meant by this. What did I change in IIS?. ADFSAppPool was run by Network Service and CRMAppPool was run by a custom domain account by default in IIS. They're were installed on the same site in IIS even though I tried to install CRM on another web site using port 5555. I think this was the first root issue during my initial IFD configuration.

    Anyway, I still have to make sure everything is working perfectly in this server so I'm doing more trial and error troubleshooting and I have some more questions.

    So, I removed the SPN records created by the 2 commands ran initially (using setspn -d this time) because I want to try to set SPN using crmserver$. These are the actual commands ran to remove them:

    1. setspn -d http/adfs.mydomain.com mydomain\crmapppoolaccountuser
    2. setspn -d http/hostnameofcrmserver.mydomain.com mydomain\crmapppoolaccountuser

    Issue now: After running the delete commands above, I'm back to the issue where I can only access CRM using the server IP address (http://IPAddress/CRMOrgName/main.aspx) and can't access using the default URL. Also, I can access it in IE when I disabled the "Enable Integrated Windows Authentication".

    I think we need to run the correct SPN command to fix this, but I'm not sure of the exact syntax to use.

    My idea is to run this SPN command to fix this, and then I should be able to access CRM normally via default URL:

    setspn -s http/hostnameofcrmserver.mydomain.com mydomain\crmserver$

    Is this correct? If not, what's the correct syntax/solution?

    I actually don't run the SPN commands as I don't have the necessary permissions, I still have to request this to our Admin person, so I couldn't tell immediately.

    I'm going to use this CRM server (1 box setup; Full server roles) for our official IFD deployment so I'd like to make sure we don't have anymore problems with this server.

    Thanks for your time and help.

    ProgCRM


    Wednesday, May 21, 2014 4:20 AM
  • You say you ran this command:

    appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true

    As far as I can see, this is telling IIS to use the credentials of the AppPool account, presumably instead of the local computer account.This is what you would normally do if your CRM servers are behind a load-balancer, and then set SPNs to use the service account, which they all share.

    So what I think happened is this:

    You used setspn to set SPNs for the app pool user account. This did not work, because in kernel mode, IIS 7 is not using that account for authentication anyway.

    (Aside: If you are using a host header to access CRM by any name other than the actual server computer name, such as IFD-style OrgName.domain.com then you might need two SPNs:

    setspn –a HTTP/HostHeader  ServerName
    setspn –a HTTP/HostHeader.domain.com  ServerName

    You should not need SPNs to access CRM using the actual server host name, because when you join the IIS server to the domain, an SPN is set for the HOST service, which inlcudes HTTP)

    When this did not work, you told IIS to use the apppool credentials, so the previous SPN was now working for you.

    I think you could change your SPNs and set IIS back to kernel mode (-useAppPoolCredentials:false) and things should work that way instead.

    For production, I would really strongly advise installing ADFS on a port that is not 443 (by configuring the default web site to eg 444 before installing ADFS), and CRM on 443 so users don't have to worry about including the port number, and likewise in your configurations it is easier not to have to do this.


    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    UK CRM Guru Blog

    Wednesday, May 21, 2014 9:53 AM
  • Hi Adam,

    First, I wanna thank you for all your time and help. You make the MS CRM community a better place, and your explanations are clear and helps to better understand the topic.

    2nd, your suggestion worked! I set IIS back to kernel mode (-useAppPoolCredentials:false) and CRM now works! We can now access CRM via URL and not by server IP address.

    So conclusion is: the initially created SPNs set on the CRMAppPool user was the root cause why we couldn't access CRM by URL.

    I can now start re-configuring this server for IFD and I'll set the SPN this time using the adfs server (setspn -s http/adfs.contoso.com contoso\crmserver$) and not the crm service account anymore.

    (Btw, I was away for couple of days thus I was able to test only today.)

    Thanks again,

    ProgCRM

    Monday, May 26, 2014 9:34 AM