I have a dev and prod Windows 2008 R2 servers with IIS7 and siteminder, which as far as I can tell are setup the same. Issue being the production websites work but the development ones do not.
Issue being that when I navigate to any dev website, it says "the page cannot be displayed because an internal server error has occured." I do not get a challenge in dev (which I believe is the cause of the issue), but I do in prod. This goes for classic ASP pages or ASP.NET pages.
Some findings :-
- IIS has Windows authentication enabled and all others disabled
- Windows Authentication Provider is Negotiate (tried Negotiate:Kerberos, same result)
- WindowsAuthentication and WindowsAuthenticationModule (Native) are both present in Modules
- WindowsAuthentication is installed under Server Manager -> IIS -> Roles
- Upon receipt of the above error message, IIS logs shows the access with error 401 2 5
All the solutions I found online either do not have the right setup as I do above, or suggests I disable Windows authentication and enable Anonymous Authentication. If I do so, all works fine but the only issue being my websites require Windows authentication to identify the user. I'm at my wit's end and am just short of reinstalling something in hope it works. Any possibilities or log files that I have overlooked?
After screwing around a bit I finally solved my problem ... hope this helps someone.
I realized in fact ASP pages were working but ASP.NET pages were not working
When I had turned on Anonymous Authentication, the ASP.NET pages were now giving 500 0 or 500 19 errors in IIS logs, instead of 401 2 5 with Windows Authentication
I tried to launch a ASP.NET page from within the localhost and got then 500 error with a more detailed error saying I should use relative path in httpErrors under web.config (??)
At this point I realized I had earlier changed the 403 error to a custom file at the default website level, then changed it back. Despite changing it back to it's previous value, What this ended up doing was adding a "remove" then an "add" tag, both for 403.htm, under httpErrors in the wwwroot/web.config. After I deleted the entire httpErrors segment, my websites started working again.
Reverting back to Windows Authentication at this point also worked.
So some take aways is to test websites locally first and keep in mind the existing of the wwwroot/web.config giving near untraceable errors ...
Related
I have a site that is a mix of both MVC and WebForms that is utilizing forms authentication. Recently there was a need to switch from using WebForms to handle the authentication to MVC so I created an Account controller with a Login method and created the corresponding view. If someone was already authenticated and tried to visit "account/login", I wanted them to be redirected to the Index page of the controller so I have the following if statement at the top of the action:
if(User.Identity.IsAuthenticated)
There are no issues with this statement on my development machine; however, when I deploy this to the server, the User object is always null. I've searched on stackoverflow and the rest of the internet and have not yet found anything that has resolved the issue.
I should mention that the server this is running on is Windows Server 2008 Standard running IIS7.
Anyone have any ideas on why the User object is always null? I did see a stackoverflow post that mentioned it is because of the way IIS handles extensionless routes; however, when I tried to install the KB mentioned in that post it said the KB didn't apply to my server.
Okay - I finally figured out the issue.
I found a post here (http://forums.asp.net/t/1689878.aspx?HttpContext+Current+User+always+null+on+IIS+) that said the issue was because they didn't have runAllManagedModulesForAllRequests set to true. I don't want that set to true so I did a little more searching and ran across this stackoverflow posting: <modules runAllManagedModulesForAllRequests="true" /> Meaning
I checked my entry in the applicationHost.config file and found that it had the precondition of "managedHandler". Once I took that precondition off, then everything started working as expected. The odd thing is that in my development environment the precondition was there, yet it worked without issue. Perhaps it is because my dev box uses IIS 7.5 while the server uses IIS 7.0.
I have tried all of the solution out there and have resolved nothing. It's a MVC 4 site on IIS 7 that I'm tryuing to get set up. Local browsing of the site won't display detail error information. Does anyone have any other suggestions?
So far I have done...
Checked MachineConfig for for .net 4 both 32 and 64 bit. It was not there so it shouldn't interfere.
Set customErrors mode="Off" in all config files.
Changed settings for DefaultErrorPages in the Site Settings to always display details.
Conducted an IISReset
Enabled failed request logging. Nothing was logged.
Checked the site error logs.=. Nothing indicated an error.
Checked Windows Logs. No errors logged under the IIS section.
Checked that the App Pool was running under .Net 4 and that it was set to integrated mode.
Turned off friendly errors in the setting for the browser
PS this is a production web server running Windows 2008R2 and IIS 7.0
I found the problem. One of the system admins had cloned the original production site intending for it to be used for the production beta, which was what I was setting up. Of course there was no communication as to what was needed to be kept in the copied site. Well it turns out there was a web.config in the original code that was doing a redirect to another location. Thus none of the new site configs were even being accessed. I removed all of the old code and it started working.
At the very outset I would like to state that this is my first ASP classic page that I have created which since the first deployment on IIS is giving me server 500 error. I have searched the entire web and have done almost everything possible to get this right, but all in vain.
I have created a classic ASP page using Web Matrix. This is a web based dashboard which connects to MSSQL server and fetch necessary information. I have a similar app in php which is working perfect, but I wanted to learn ASP hence was trying to make a similar web app on ASP. This app works absolutely fine on Web Matrix. When I run this app from within web matrix (both on chrome as well as IE) it connects to the required database and I can browse the details as expected. The problem starts when I host this on IIS (localhost on my windows 7 pc). This is the exact procedure that I have followed :
Created a new Site on IIS named "YCube"
Using basic settings I have given the following Physical path for the app (D:\YVXS\Personal\ASP\SSTool\Ycube) {the project output folder}
In the bindings page I have assigned port 81
IIS authentication is set to "Anonymous Auth"
Application pool for asp is set to classic (as IIS first stated it cannot perform the task in integrated mode)
After this when I tried browsing localhost:81/menu.asp, it given me server 500 error. The 21 days research starts now (bullet points below)
To get the descreptive errors on the web page I did following but the error description did not change IIS->asp->Compliation->send error to browser =true, friendly http error on IE = disabled
IIS log files, not sure if iam not able to understand the error but am getting follwing on the log file (C:\inetpub\logs\LogFiles\W3SVC1
2013-02-23 08:07:44 ::1 GET /menu.asp |-|ASP_0147|500_Server_Error 80 - ::1
On the IIS forum only I underatood at time global.asa file can cause this problem, I deleted this file and tried, all in vain
The folder and files permission for my site is read only, however I have tried the same with read and write access also, this also did not help
On the error pages in IIS, i have changed the "Edit feature settins" to "Detailed error", this also didnot give me any futher error desc.
24 times i have uninstalled IIS and installed back, nothing has happend
Someone suggested to created a dummy asp file and try hosting the same of IIS, so I used a small code
<HTML> <BODY> This page was last refreshed on <%= Now() %>. </BODY> </HTML>,
this is giving correct output (This page was last refreshed at 18:88:22....), however with my original asp page I still get server 500 error
A friend of mine suggested to delete all other hosted web pages from IIS and try (I had one PHP on the IIS), hence I deleted the same and tried, no changes at all
Event log file is showing nothing pertaining the ASP (only few files are there which tells about unexpected shutdown of my PC)
I created a second ASP file which had MS access at the backed, this only is also giving me same server 500 error
Other things that I have tried is changing the web.config file to send detailed error, (thouh i forgot the exact line) but that also did not help me
Here are my system config and other details Windows 7 professional, IIS7.5.7600, MSSQLR2express. Also please note that I have tried hosting this on two othe pc's that I have(both windows 7) and in office server 2003, but all are giving me same server 500 error.
Never thought learning a classic asp will put me into all this Jazz...please help..
Couple of Things u need to take care of while configuring ASP site in IIS
1) Enable parent path = true
2) if you have 64 bit machine need to set your Application pool for 32 bit.
this are default settings which we need to take care.
My host is having issues getting my MVC3 app to work on their server, so I though I'd check it out myself. Until now I've been too busy developing under the built in server to worry about IIS, but today I tried my first deployment to the host with no joy. Then I tried one to my local IIS, with no joy. Then I tried telling VS to use IIS for debugging, to maybe resolve some local issues, with no joy.
What steps and configuration are required to use local IIS 7.5 to debug an MVC3 application?
EDIT: Going through a browser, after clearing up a permission problem for my Windows user on Temp ASP.NET Files, I now site with a I get a HTTP Error 403 (Forbidden), but the occassional basic auth login dialogue. Here I have tried a Forms auth user, my normal Windows user, and my Windows admin user, all to no avail.
When I try and debug under VS, I get a 500, internal error.
THE PLOT THICKENS: When I enable directory browsing on the site, I get a proper directory listing for the site root url. This suggests the the MVC3 routing is not working, but why not?
If you're getting a directory listing that means there's not a default file set (for IIS6). It usually means the request wasn't routed to IIS to deal with. thing are slightly different with II7 & it's integrated pipeline.
Simon
We are in the process of migrating an ASP Classic/ASP.NET application from IIS 6 to IIS 7.5. Most things run just fine in classic mode but we are having alot of problems with how errors are handled by IIS 7.5. We do our error reporting using a classic ASP page where we capture the error information here then redirect to a page to display the error. Based on our testing both Server.GetLastError and Request.ServerVariables("SCRIPT_NAME") when accessed from the logging page do not return the error details and source. Are there other ways we should retrieve the error information on IIS 7.5 or perform the logging?
In case this helps, using freb we have noticed that IIS appears to generate a completely new request then begins executing our error capturing.
Thanks in advance.
#smaclell: See http://dylanbeattie.blogspot.com/2008/12/fun-with-servergetlasterror-in-classic.html for a potential solution for you.
Here's the relevant paragraph from the article:
There was a very similar known bug in Vista which was supposedly fixed
in SP1, but it looks like the same fix isn't part of Windows 2008
Server yet. There is a workaround, though - if you set the site's
default error property (under IIS settings -> Error Pages -> Edit
Feature Settings...) to the custom page, IIS will invoke
this page whenever an error is not handled by an explicitly configured
status-code handler (so your 404, etc. handlers will still work) - but
for some reason, handling the error this way means
Server.GetLastError() still works properly.