Does anyone know how to resolve this IIS error?

http://stackoverflow.com/questions/6390886/500-19-error-with-iis7-5

Lock violation

The only thing that it works is to go and remove manually "defaultPath" from "lockAttributes" attribute of xml node in the file %windir%\System32\inetsrv\config\applicationHost.config

 -user Ben Challenor

try setting the allowAbsolutePathsWhenDelegated to True for the server in Configuration Editor of IIS:

So I moved it to true, now i'm seeing the following:

HTTP Error 404.18 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

Which is totally fine, I'm just not sure how/what moved. We haven't moved anything recently and nothing on the server has changed or modified.

What should be showing here is data that is pulled from SAS through the website but as you can see the web component isn't finding what it's looking for

Have you confirmed C:\inetpub\custerr\en-US\404.htm exists and that no permissions have been changed?

Yes. It exists and no permissions have changed.



the strange thing is that all of the older portlets that were there prior to the error happening still work. But whenever we try to add a new one to the web page, it fails and we now get the
HTTP Error 404.18 - Not Found:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

http://forums.asp.net/t/1525194.aspx?HTTP+Error+404+0+Not+Found+The+resource+you+are+looking+for+has+been+removed+had+its+name+changed+or+is+temporarily+unavailable+

I solved my problem by adding IUSR in the trusted users on the ReportServer.

Make sure iusr has permissions to that absolute path.

I gave IUSR permissions to the whole D:, didn't resolve the issue. The 404.18 continues

I gave IUSR permissions to the whole D:, didn't resolve the issue

Do you know if the absolute path coded in the webpage is pointing to the 'D' drive or the local disk in the inetpub directory?

I thought it was on D: because the physical path which was listed on the error message was showing a location on the D:

I went ahead and gave iusr permission to inetpub and i'm still getting the same web error

C:\inetpub\custerr\en-US\404.htm"

As a test, locate the file above and add the IUSR with full permissions.

Gave IUSR full permissions on that file, issue is still occurring.

restart iis

I did that as I assumed it needs to be done on anything you modify that is IIS related

This goes back to the original error 500.19  https://blogs.msdn.microsoft.com/webtopics/2010/03/08/troubleshooting-http-500-19-errors-in-iis-7/

Delete the malformed XML element from the ApplicationHost.config file or from the Web.config file as indicated by the error message.

In one scenario, we had a virtual directory pointing to a UNC share content. This same above 500.19 error was caused because of wrong password specified in the “Connect as..” setting. So make sure to provide the right credentials under “Connect as..” .

Another instance where the error code remained “0x8007000d” but the “Config Error” didn’t complain the mal formed XML, rather was about Configuration section encryption.

So just to make sure I am reading that correctly I should:

1) Remove the XML file (404) from the applicationhost.config and/or from the web.config

2) Check to make sure all the virtual directories in IIS don't have a connect as setting

No, Step 1) take a backup or image of you IIS server... :D

then so on and so forth.

I have backups for the past two weeks so I'm good :)

The virtual directory (only 1) is using pass through authentication

So again just to make sure I'm just removing this line from the apphost.config and web.config? (I'm not an IIS guy)

<error statusCode="404" prefixlanguageFilePath="%systemDrive%\inetpub\custerr" path="404.htm"/>

https://support.microsoft.com/en-us/kb/942055


HRESULT: 0x80070005

The IIS_IUSRS group does not have the appropriate permissions for the ApplicationHost.config file, for the Web.config file, or for the virtual/application directories of IIS.

We may have been going about this wrong.  Have you validated that the IIS_USRS  GROUP  (THATS GROUP), not the user account, has access to the two files above?  It would make sense as they're trying to read and write configuration.



I've been working with IIS for 13 years and haven't run into an issue like this.  Something had to have been changed by an administrator for these errors to pop up.  The fact that the prior added worked and didn't throw an error, still leads me to believe this is a permissions issue.    

Sorry for going back and forth here...  Is there any scenario where you can imageoff this IIS server, a dns server and a workstation into a separate lab and test both?

Another thing.  Can you verify what the system variable %systemDrive% is and that it matches the actual location of the ..\inetpub\custerr folder?  

"<error statusCode="404" prefixlanguageFilePath="%systemDrive%\inetpub\custerr" path="404.htm"/>"

I cannot imageoff this IIS server into a separate lab unfortunately.

%systemdrive% variable is C: so it goes to the proper dir

In Windows Explorer, locate the folder that contains the ApplicationHost.config file that is associated with the Web site, or locate the virtual directories or the application directories that contain the Web.config file that is associated with the Web site.

So I was able to add read access to the IIS_USRS group on the applicationhost.config file and the web.config files in the sole virtual directory I have. Did an IIS reset and I still see the 404.18 as indicated above.

I'm wondering if something just got removed on the application side, and IIS just isn't seeing what is supposed to be there so that's why it's giving an error

So should I remove that 404 line from the applicatonhost.config and web.config files and see what happens?

That should get rid of the custom 404 error, but I don't know if you're in any better shape.  I would test.  All you're doing is remove a customized error page.  It should revert to the default 404 page installed with IIS.

I'll give it a shot.

Anything else?

What's weird is that we have other portlets of the same type, that were added before the break occured. They are still there, still exist, and still work properly. No IIS error.

But whenever we try to add any new portlet it's broken across the board and we see the IIS error

The error you're getting sound like when you're trying to deploy (read/write) the portlet, you're getting a permission deny somewhere.  Who wrote this application?  Is there not a log file or a way to enable verbose logging?  Have you investigated the IIS logs and event logs?

The application is SAS (Statistical Analysis System). I have a support case open with them. We haven't seen any errors on the application side (but of course you wouldn't, if something disappeared)

This whole thing was set up by someone who is no longer at the company unfortunately.

I even did a restore back to Wed night of the 16th (before the issue occured and we had verified emails that the portlet was working) and that didn't resolve the issue.

I looked through the IIS logs and Event Logs and nothing stood out.

Sounds like something external to IIS may have changed.  Perhaps Windows updates were installed?

That was my thinking as well. I have windows updates set to manual on this particular sever. No updates have been installed since 2/9/2016

I ended up figuring this out myself based on my current configuration and digging around my IIS environment