We are trying to configure OOF on an Exchange Server. We are talking about Outlook 2010 with Exchange server 2010.
If i navigate to https://mail.[server]/ews/exchange.asmx i see the following page:
Server Error in '/EWS' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "Off".
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's configuration tag to point to a custom error page URL.
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>
I already recreated EWS, OWA and OAB, without any effect.
There is no proxy active in the organisation.
There are no internet restrictions.
Help
What is the reason for the error page I get when I run my webapp in Visual Studio. The URL is http://localhost:5000/
HTTP Error 403.14 - Forbidden
The Web server is configured to not list the contents of this directory.
Reason: http://localhost:5000 refers to the root of the webserver. So, for the above request, it tries to read the root folder of the server. However, IIS (express) by default doesn't allow you to view the file system. Therefore it shows above error.
Most probably you don't need to access the root of the server, instead you might need to access your webapp (ex: http://localhost:5000/myapp).
However, if you know exactly what you are doing then you can enable IIS to show the root directory (file system) using the following config in the Web.config of your application
Important: Below config should not be activated in a production or any
publicly reachable environment which is obviously a high critical
security issue.
<system.webServer>
<directoryBrowse enabled="true" />
<modules runAllManagedModulesForAllRequests="true"></modules>
</system.webServer>
Two things are usually the issue when I get this error:
1st: I never defined a standard document and changed it at some point - therefore the standard document that is automatically defined by the IIS in this case, doesn't exist
2nd: I didn't enable index search
You might want to try this. You can change those settings in the IIS settings directly.
Works fine on the local machine, but when deployed this error message pops up:
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Detailed Error Information:
Module IIS Web Core
Notification BeginRequest
Handler Not yet determined
Error Code 0x80070021
Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".
Config File \\?\C:\inetpub\foo\web.config
Requested URL http://foo.net:80/
Physical Path C:\inetpub\foo
Logon Method Not yet determined
Logon User Not yet determined
Config Source:
71: </modules>
72: <handlers> <--- This part is highlighted on the error page.
73: <add name="CassetteHttpHandler" path="cassette.axd" preCondition="integratedMode" verb="*" allowPathInfo="true" type="Cassette.Aspnet.CassetteHttpHandler, Cassette.Aspnet" />
More Information:
This error occurs when there is a problem reading the configuration file for the Web server or Web application. In some cases, the event logs may contain more information about what caused this error.
Any ideas on what I can do to solve this issue?
The way I solved this error was by going into the IIS Management window and selecting Feature Delegation and setting Read/Write to Handler Mappings and Modules.
Everything is working fine now.
I created a blank MVC 3 application on VS2010 SP1, and set the app to use IIS Express. When I debug, I get error 500.0 (0x80070585)
I am able to succesfuly run the app using the VS dev server
I have set the app directory to Full Permissions for Everyone, just to eliminate all possibility of security issues. I have further verified that IIS express is able to hit the web.config by confirming it using SysInternals ProcMon. ProcMon does not show the IISExpress process attempting to read from any other files in my application directory.
I have followed the suggestions in the following question, but it does not give me any better information. HTTP 500 Internal Error - IIS websites
No logs are generated in the IISExpress directory in either the Logs or TraceLogs directory, but a log is created in Temp, however it is not very useful.
Successfully registered URL "http://localhost:62017/" for site "MvcApplication1" application "/"
Registration completed for site "MvcApplication1"
Request ended: http://localhost:62017/ with HTTP status 500.0
Request ended: http://localhost:62017/ with HTTP status 500.0
Request ended: http://localhost:62017/ with HTTP status 500.0
There are no messages I am able to find in the Event Viewer
**Updates : **
Disabled firewall, no change
Ran IISExpress via command line, no change
I had the same issue last week, the app running perfect in dev web server from VS Studio. But in IISExpress anytime HTTP Error 500. My solution on this time was:
close VS Studio - solution set with IISExpress
got to: /Document/IISExpress/config/ in your profile
rename or delete applicationhost.config
open your solution in VS Studio
a Dialog will fire up from IISExpress - this will set a fresh config.
try to run your web app
You may have some mime code in the Web.Config file like this:
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
if so, you should remove mimeMap before adding like this:
.
..
...
....
</system.web>
<system.webServer>
<staticContent>
<remove fileExtension=".svg" />
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
</staticContent>
</system.webServer>
....
...
..
.
This may be related to a conflict between the IIS Express applicationhost.config and your web.config.
A mimeType was added to my local web.config that was already present in the applicationhost.config and IIS Express started serving many 500 errors.
You may also notice this error in your Windows Event Log, "The directory specified for caching compressed content is invalid. Static compression is being disabled."
More info: http://blog.degree.no/2013/04/the-directory-specified-for-caching-compressed-content-is-invalid-static-compression-is-being-disabled/
I removed the mimeTypes from the web.config and the issue was resolved.
applicationhost.config location: C:\Users\[User]\Documents\IISExpress\config
reinstalling iis express appears to have resolved this problem
Are you using any PLINQ(.AsParallel) or Parallel.For or similar methods? I've found that the AggregateExceptions they throw aren't handled well by MVC (In my case, I got a blank 500 page and nothing in Logs/Event logs).
I identified the problem by paying attention to the "First Chance" exceptions which are logged in the Debug output window in VS. Try running the site, waiting for it to error, clearing the Debug window and the reloading the page. Do you see anything useful?
There might be a problem with your config files, specifically web.config and applicationhost.config.
The only way I know how to diagnose this, is to publish a build to regular IIS, and in IIS Manager check the "Error Pages" module of the Site. If it is indeed an issue with those config files, you'll get a popup here with something along the lines: "Cannot add duplicate entry of type …". Google accordingly.
If the "duplicate entry" is of type "error", you can try adding the following element below httpErrors:
<remove statusCode="404"/>
That is, assuming you have an Error element below the HttpErrors with statusCode 404. (I had once.)
In my case the issue was caused by using windows authentication + firefox + wrong domain login with insufficient permissions.
Details:
My dev machine is using windows domain "domA", the application will run in an environment accepting logins from domain "domA" and "domB". While on the webserver both will work, on my dev machine only my account in "domA" has sufficient permissions to access all files of the application. In IE "domA" is used by default while in FF I get a login dialog where I did login with my account from "domB".
Confusing issue I know, but maybe there is someone else having the same situation. At least it will help me the next time I run into it. :)
Just in case catches someone else out, I had similar error but the issue was I had updated my web.config and there was an extra ">" character where it should be.. so malformed web.config file can cause the same behaviour.
also this line was added automatically by Visual Studio:
Should I turn it to debug="false" in the release web.config?
Many thanks.
You should set customErrors to On or RemoteOnly. The latter would mean that anyone using the local machine will see the full error page, but any outside users won't. The less information outside users have about how your web application works, the better. You could do something like this:
<customErrors mode="On" defaultRedirect="~/ErrorPage.aspx"/>
You can also give a bit more specific information about the error users.
<customErrors mode="On" defaultRedirect="~/ErrorPage.aspx">
<error statusCode="404" redirect="~/404error.aspx" />
</customErrors>
For production, you should set Debug to false.
Reasons on why Debug should be set to false can be read about here.
1) The compilation of ASP.NET pages
takes longer (since some batch
optimizations are disabled)
2) Code can execute slower (since some
additional debug paths are enabled)
3) Much more memory is used within the
application at runtime
4) Scripts and images downloaded from
the WebResources.axd handler are not
cached