I have recently deployed an MVC application to a new SQL/IIS server. While I knew it wouldn't be as simple as copy files, set as web app and go, it was more challenging than anticipated. Hopefully the learnings here will speed up the resolution for others with the same problem.
Of course, being an MVC app, you will need to install MVC 3 on the IIS server.
I used the Visual Studio 2010 "Publish" functionality to get the release on the server. This will be the subject of another article, as it took some setting up, but it is very convenient and supports web.config transformations per environment [debug, release, etc], which is a bonus.
Having got the files on the server, and appearing as an Application in IIS, I fired up IE and hit the URL - HTTP error 503 - Service Unavailable. Ok, first principles, what does this really mean? It means the web application has failed to start, or perhaps started and immediately failed.
So what happens when we hit a .Net MVC web app URL for the first time? The app needs to run as a user/identity in order to "do things" under Windows. The app user then has to read the web application directory/files, including the root web.config and continue from there. The web.config specifies the .Net runtime to use, the assemblies to use, both system and custom, and usually one or more connection strings to data resources [to which the app user must have access]. If all of these are working, your web application should work. Any errors encountered along the way will be in the IIS logs and Windows Event Logs [Application and System] as appropriate.
In IIS, the user/identity for the application to run as is configured under the Application Pool settings. Upon inspection of the app pools, there were just two, each configured for the .Net 2.0 Framework. This was puzzling, as the server had .Net 4.0 installed before it was given the IIS role.
The two highlighted app pools were not present initially.
To get the new ones to appear, I had to register the .Net 4.0 Framework with IIS:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319 > aspnet_regiis -ir
This gave me two new App Pools, labelled as .Net 4.0 Framework version. Unfortunately on closer inspection, one of them was actually pointing at the .Net 2.0 runtime; it always pays to check the default configuration of new objects!
For my scenario, using the new App Pool was appropriate, as there will only be one application on the server. For a server with multiple sites/applications consider creating more app pool identities in order to increase your security. It goes in to a lot more detail here.
Having introduced a new app pool identity, we need to set our site/app to use it via Advanced Settings:
Set the Application Pool from the available list.
On first glance, it looks like our permissions are correct.
While you're doing this, take the opportunity to review the file/folder permissions for the group. In our case we have "Read and execute", "Read" and "List folder contents", which is all we need. Avoid the temptation when things aren't working to simply click Full Control - bad idea. If your application identity is compromised, it could be used to delete your entire site.
Drilling down into the IIS_IUSRS group, our app pool identity was not present.
Using Server Manager, I browsed to Local Users and Groups and looked at the properties for the IIS_IUSRS group:
Our app pool identity is missing and needs adding.
I added the missing identity via the Add button.
Now we add the app pool identity to SQL Server to provide enough access to service the application's needs. We should only select the db_datareader and the db_datawriter on the target database, rather than just ticking the db_owner role. Again, that is a bad idea. If your app pool identity is compromised, it could be used to amend the schema and/or programmability [tables, SPs, functions, views, etc]. By limiting the user to only what is needed you are significantly adding to the security of your application.
Fingers crossed, and hit the URL once more - success! Only from this point forward would we expect meaningful application error messages in the IIS logs and Windows Event Logs, as we now have a running application.
For me, this was the end of the problem, but reading up, others have experienced application errors, or indeed still got a 503 at this point. The application errors should now be manifesting as meaningful error messages in the IIS Logs and Windows Event Logs [Application and System].
For some, the 503 remained due to them inadvertently using reserved URLs, or in one rare case, having previously reserved port 80 globally, such that it could not be re-used. To check this aspect, run the following command to interrogate the http.sys settings:
C:\> netsh http show urlacl
If the output shows a clash with your application's URL, you will need to change one or the other.
For one user, they were trying to use /Reports, which is reserved by SSRS.
Hope that's been useful.
References/further reading:
Troubleshooting 503 Service Unavailable errors
Troubleshoot IIS 7 errors like a pro
The IIS 7 team rocks (Error 503 resolution)
No comments:
Post a Comment