On an IIS6 server, some WCF services return the home page instead of a useful result.
In IIS, wildcard, axd and svc are all registered to aspnet_isapi.dll.
The site user has full permissions to everything.
Interestingly enough, when viewing the site through a local Cassini install, everything works fine.
Suggestions?
2 possible suggestions:
http://blogs.msdn.com/b/wenlong/archive/2006/09/10/748294.aspx may help.
Also, Under IIS Manager, open Web Service Extension and make sure that ASP.NET v2.0.5.0727 is set to Allowed. (or the ASP.NET v4.... one if thats what you're using)
In fact, WCF not running under IIS 6.0 has some helpful hints.
Related
I am having a problem setting up a website under IIS 7. I have created an application and the application pool for the application. Application pool is using .Net Framework 4.0 as my .net app is written in .Net Framework 4.0. Application pool is set to use classic Pipeline Mode. MIME Types have been automatically added to .asp & .aspx.
When I run the website windows explorer is showing me "View Downloads" and trying to download "application name localhost" when it downloads the file I notice that its the html of my default.aspx. I have checked Default Document and it contains Default.aspx.
If I remove .asp & .aspx MIME Types then I get an error: HTTP Error 404.17 - Not Found The requested content appears to be script and will not be served by the static file handler.
I have seen this problem many times. IIS is not serving aspx pages and most likely is not running for the entire server or that site.
For the entire server: Check to see if iis world wide web service is running.
For the site alone: Hit run inside IIS.
You can easily know if IIS is running properly by going to IIS and hit the browse option from inside a web site.
With the data you have put these are the things I would try in order if I were you:
Check in Server Manager/ Features if ASP.NET is installed (ServerManager/Roles/Web Server(IIS) look for ASP.NET
Check IIS Manager if everything is ok by:
Try to browse a test.html file to see if you are able to browse normal
Check Basic settings by clicking Test Settings
Check Handler Mappings to see if aspx is there.
Try to browse a sample test.aspx page with test data.
Check Application pool settings.
Reinstall Framework 4.0
Reboot machine ( a classical)
If you gave us more info and/or the ouput of my proposed tests maybe can help more. Good Luck :)
I had the 404.17 error happening on a server today. As you and cad mentioned, I checked the framework of the Application Pool that my site was using to make sure it was set to ASP.Net 4.0, and it was. What happened in my case is that my site was not using the application pool that I thought it was. My site was nested under another site, meaning my site pointed to a subfolder but another site was pointing to the root folder. Even though I had my site set to use the ASP.Net 4.0 Application Pool, the root site used a different Pool that had ASP.Net turned off, it was set to "No managed code". When I set the framework to 4.0 for the Pool the parent site was using, then my site started working.
In my case the solution was fixing the Handler mappings as explained here: http://forums.iis.net/post/1943489.aspx
IIS Manager->high-light you web site->click Handler Mappings icon on
the home pane->click Revert to Parent...
on the right Actions pane
I'm evaluating Telerik's Sitefinity CMS. On my dev box (Win7 x64/IIS7), everything works great.
However, when I deploy the site to our Win2k3/IIS6 server, the backend system doesn't work correctly. According to fiddler, anytime the browser makes an AJAX request to a WCF (.svc) service within the application, the home page is being returned.
Any suggestions?
I've tried:
re-registering ASP.net
Re-registering WCF with
\windows\microsoft.net\framework\v3.*\wcf\servicemodelreg -i
Made sure that the .svc extension is allowed
Deleted and recreated the site in IIS
Argh. Suggestions?
You can find installation information and other tips on getting Sitefinity up and running by visiting the documentation.
This turned out to be related to the IIS6 application pool identity, permissions on the web folder, and having multiple authentication methods checked in site properties. By playing with those things I was able to get it to work.
As a test, I ran the site through the Sitefinity project manager app (using its integrated Cassini server), and everything worked correctly.
I have an ASP.NET MVC 3 application, which runs on a IIS 7.5. Everything works great if i access the application locally from the Windows Server, but if i try to access it from a remote client the browser throws an error.
The HTML loads fine when i try to access the site remotely, but when it make AJAX calls it fails with this msg:
POST 403 (Forbidden: header 'Content-Type' value denied)
I have tried:
- using jQuery jsonp
- Granting webfolder accees to "Everyone" in Folder security and sharing
Do you have any other suggentions for a solution?
Check if the file global.asax exists.
I had get the same problem because I forgot to upload this file.
Does your web server have ASP.NET 4 installed? You may need to run this command:
%windir%\Microsoft.NET\Framework64\v4.0.30128\aspnet_regiis.exe -ir
Edit: OK, so this wasn't the problem... Security is the next thing to check: This article might help you... http://learn.iis.net/page.aspx/624/application-pool-identities/
Generally when I've seen stuff like this, IIS is running your site under it's limited user instead of the application pool user.
To check this configuration you need to access IIS Manager, expand the computer name, expand sites, expand the web site that contains your application, select your application in the tree view.
Under the IIS settings region, select Authentication (double click it, or click open feature)
Select Anonymous Authentication, click edit... from actions on the right. In the dialog that opens check the setting for Anonymous user identity: it should be set to application pool identity.
Original Answer by Mmerrell at Getting 404.0 error for ASP.NET MVC 3 app on IIS 7.0 / Windows Server 2008
You actually just reminded me that I needed to fix this issue in an
enviroment here. If your situation is the same as mine then it's a
simple fix.
Just add the following to your web config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
I have a ASP.NET 3.5 web site, which is password protected (form authentication). But yesterday I found I was able to browse the list of directories (which is unexpected).
I searched the web, one article said we need to config it in IIS. But I'm a developer and I'm working on my local machine (no IIS installed).
My question is: are there any way to hide them other than IIS configuration? like set web.config?
This must be configured in your webserver - you cannot handle this in the website itself. Since you are working locally it shouldn't matter that the root directory is browsable. If you need to be able to control the site in this way you really ought to set up a webserver.
if you don't have IIS, you're likely working on your local ASP.NET development server (called Cassini possibly?), in which it is only available locally, so no security worries there.
When you deploy your app, you will likely be on an IIS server, so the configuration will be available
Directory browsing in IIS is controlled in the virtual directory/site configuration.
When you deploy your application to a real server you can configure directory browsing there.
Directory browsing on your local machine shouldn't matter, but this may work for you.
In IIS6: http://blog.crowe.co.nz/archive/2006/03/18/603.aspx
In IIS7: http://technet.microsoft.com/en-us/library/cc731109(WS.10).aspx
In IIS - Website properties, Home Directory tab, untick Directory browsing.
In Cassini (the ASP.NET development server) I don't think it can be turned off. But the server only runs while your debugging.
I have code running in an ascx within PageLayout within SharePoint 2007 that accesses files on a remote server i.e. File.Create("\servername\sharename\folder\file.txt"). The code runs within a SharePoint web application that has CAS trust set to Full in the web.config. The File.Create throws the following exception:-
System.UnauthorizedAccessException
Access to the path '\\servername\sharename\folder\file.txt' is denied.
The share is shared to Everyone with Full Control and the NTFS permissions are set to Everyone with Full Control. The web application app pool is running under a domain account also with explicit permissions to access that resource (not that this should be needed).
I ran Process Monitor on the remote machine and no hits were being recorded on the server. This leads me to believe that it is an issue with the SharePoint Code Access Security settings. Like I've said above, the trust in the web.config is set to Full.
Is it possible that CAS is still blocking the remote access? Can anyone think of any other area to review?
Update
A bit more information...
I've tried making the app pool acct domain admin and the problem still occurs. When using the same method to access a drive on the local machine it works fine. Running the same code in SnippetCompiler outside of sharepoint using the app pool account works fine.
Hope this helps, let me know if you can think of any more avenues of investigation or tests I can try.
Update
Im not sure if this would affect the issue but the local server is running Windows Server 2003 and the remote server is running Windows 2000.
Update
I've just tried running the code through a web part and it works fine. The file structure I use in the project that is failing is as follows:-
wss
- VirtualDirectories
- SharePointWebApp
- ...sp web app files
- .
- .
- PageLayoutControls
- control.ascx
- .
- .
Then in IIS I have the following structure:-
IIS
- Websites
- SharePointWebApp (pointing to \wss\VirtualDirectories\SharePointWebApp)
- PageLayoutControls (virtual directory pointing to \wss\VirtualDirectories\PageLayoutControls)
Then within the PageLayouts I reference the controls using the following:-
<%# Register TagPrefix="TEST" TagName="MyControl" Src="~/PageLayoutControls/control.ascx" %>
<asp:Content ContentPlaceholderID="PlaceHolderMain" runat="server">
<TEST:MyControl id="myControl" runat="server"/>
</asp:Content>Let me know if you need more info.
Update
The mystery deepens...
When I access the sharepoint site from Internet Explorer (6 or 7) on the SharePoint web front end server I do NOT get the exception.
When I access the sharepoint site from Mozilla Firefox from the SP web front end server I DO get the exception.
When I access the sharepoint site remotely from ANY browser I get the exception.
Also, it makes no difference what user I use to log on to the site, as long as they have permissions to access the sharepoint site.
Any thoughts?
Update
Hmm, I've now found that if I access the sharepoint site remotely and the sharepoint site tries to do a File.Create() locally (i.e. File.Create("C:\temp\abc.txt")) then it works. If I access the sharepoint site from the sharepoint box and do a File.Create() remotely (i.e. File.Create("\ServerName\ShareName\FolderName\file.txt")) then it works.
It only fails when I access the sharepoint site remotely and have the sharepoint site try to do a File.Create() remotely as well. Kind of a double hop problem. This makes me think it may be an NTLM / Kerberos issue.
Currently, we are running using NTLM authentication.
Has anyone else experienced this sort of issue?
Update
Yep, I'm pretty sure this is an NTLM issue not allowing a double hop. I just changed the authentication on the sharepoint site to use Basic Authentication and its worked. Changed it back to Integrated Authentication and it failed.
Now to decide whether to move the farm to use Kerberos or find another way around the issue. :-/
Update
Just giving SPSecurity.RunWithElevatedPrivileges a shot now. One thing though, is RunWithElevatedPrivileges meant to be used in this context? Previously, I've only used it to get access to lists and libraries within SharePoint rather than accessing a file access the network.
Any thoughts?
Update
Yep, SPSecurity.RunWithElevatedPrivileges resolves the issue. :-)
I wonder if this is the double-hop issue and that your code is trying to access the resource as the impersonated user, but that fails because NTLM will not impersonate to another server (Kerberos would).
Have you tried SPSecurity.RunWithElevatedPrivileges? That would remove the impersonation (RevertToSelf) and then maybe the application pool owner can just act as himself (herself?) whereas maybe it couldn't before.
Just a thought and should be pretty easy to try out.