Okay so full disclosure I am new to IIS and WCF so I bought a book and am stuck. I can develop on my dev box at work as it is Windows 7 with IIS 7 but at home on Windows 8 and IIS 8 I believe there are two issues and I just do not know which step is potentially causing the issue. I am developing on .NET 4.5 environment with Visual Studio 2012 Professional for both environments.
Basically I believe IIS to be set up wrong as I am following a book called 'Windows Communication Foundation 4, Step be Step'
http://www.amazon.com/Windows-Communication-Foundation-Step-Microsoft/dp/0735645566
I followed the set up instructions but they are a little different at home and am curious what to do to correct this error:
"The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 1024 bytes of the response were: ' "
This code occurs after I create a WCF service library web project, it is referencing an entity framework model. You create a console app that references the web service and it runs fine. You deploy that web service to IIS and change the config file to reference that location and it blows up with the error above ONLY on the windows 8 machine, the Windows 7 runs just fine.
I noticed two steps I could not do in the setup and believe they are the culprits but don't know how to adjust for Windows 8 yet.
From VS command prompt: 'aspnet_regiis -iru', this does not work AT ALL for IIS 8. Don't know what options when you open IIS to set for the generic okays for asp.net operations. - I did attempt to go into IIS and under 'Authentication' turn on Anonymous authentication and ASP.NET. Still did not fix anything.
The book came with a sql object that then registered two users to the database for 'Adventureworks'. Obviously I am guessing since part 1 did not work or due to Windows 8 settings these users do not exist, hence they cannot be registered. The code for the register users is:
'CREATE USER [IIS APPPOOL\DefaultAppPool] FOR LOGIN [IIS APPPOOL\DefaultAppPool]
GO
EXEC sp_addrolemember N'db_owner', [IIS APPPOOL\DefaultAppPool]
GO
GO
CREATE USER [IIS APPPOOL\ASP.NET v4.0] FOR LOGIN [IIS APPPOOL\ASP.NET v4.0]
GO
EXEC sp_addrolemember N'db_owner', [IIS APPPOOL\ASP.NET v4.0]
GO'
I know SQL code but I know that the users don't exist they are trying to reference so may I add them through IIS or through Control Panel? I was not sure so I did not know IIS so thought I should ask first.
Any help is much appreciated as I know this is probably just a simple method.
Okay I think I got it but not the way I would have hoped to. It seems that I need to run the service with Anonymous Access in IIS 8. Go to 'Authentication' under the default site 'disable' ASP.NET impersonation. But.... for some reason IIS8 and WCF options for .NET 4.5 were not enabled by default for Windows 8. So I found this: http://proq.blogspot.com/2012/09/wcf-on-iis-and-windows-8.html and enabled them.
Weird, anyways I know at some point I am going to have to register ASP.NET users on my local machine mimicking a server environment. But for the time being anonymous access seems to work. I am curious though if IIS knew it had two choices and anonymous was first why it failed? Does it take the most restrictive policy as the default for an access point binding at all times? I am completely new to IIS and it seems like I am going to have to learn it as well as the WCF.
EDIT: When running VS 2012 with some settings also be sure to run VS as ADMINISTRATOR or you may also have issues.
Related
On Windows Server 2012 R2, after installing update KB4340558 (update history) / KB4338424 (installed updates) we can no longer instantiate .NET .DLLs (interop) in classic ASP in 32-bit mode using server.createobject. We receive the error 0x800A01AD "ActiveX component can't create object"
When we uninstall the update, the error disappears. Despite my best efforts, I was unable to find an alternate solution to uninstalling. We would prefer to reinstall the update and make whatever changes were necessary to Windows Server and/or the DLL's to allow the COM objects to be instantiated properly. There are no clues in the system logs, no clues in the CVE database, and no clues in the errors ASP is generating. Please help!
We were affected with multiple customers too.
I ruled out invalid strong-name signing of our assemblies, since the .NET Assemblies from the Framework itself were affected by that access-denied error too.
Finally I managed to solve the issue by configuration.
Apparently the authenticating identity of the website has now to match the identity of the app-pool. Or IUSR has no longer enough permissions.
EDIT: 19.07.2018
Warning! This change also has a side-effect:
The asp-classic event "Session_OnEnd" was no longer called and therefore resources eventually could no longer be freed.
But there is a fix for that, too!
The ASP-Config-Property "system.webServer/asp/runOnEndAnonymously" has to be "false", then the event fires again.
EDIT 2: 23.07.2018
As Dijkgraaf pointed out, Microsoft now considers this "new behaviour" a bug. So i guess my "solution" should now be considered a workaround until a new patch comes to rescue.
We run our application pool under a specific identity, to enable a network share and database access. I too thought we were stuck after reading #keydon's answer above.
However, there are three places that we must configure the identity:
The Application Pool - should use the specific identity
The Website "Connect As" - should use the "Application pool identity"
The Anonymous Authentication option, under the Authentication feature - should use "Application pool identity"
That last one was the thing that we were missing - years of considering only the first two meant that we mis-read the great advice above.
Microsoft is aware of the issue and the relevant KB is "Access Denied" errors and applications with COM activation fail after installing July 2018 Security and Quality Rollup updates for .NET Framework
This has impacted BizTalk, SharePoint, IIS with classic ASP and .NET application that uses impersonation.
Workarounds for Classic ASP are as follows
IIS Hosted Classic ASP calling CreateObject for .NET COM objects may receive an "ActiveX component can't create object" error:
If your web site uses Anonymous Authentication: Change the Web Site Anonymous Authentication credentials to use the "Application pool identity".
If your site uses Basic Authentication or Windows Authentication: Log into the application once as the application pool identity, then create an instance of the .NET COM component.
Afterwards other site users will be able to active the .NET COM component without the failure.
Alternatively, if you are using Windows Authentication and accessing the web site from the console of the Windows Server where the ASP application runs: Creating an instance of the .NET COM component also resolves error for other site users.
We support a Classic ASP site running in IIS Anonymous Authentication. The application instantiates a DLL .NET object exposed as COM visible.
After applying recent security Windows Updates and reboot OS our application crashed with following error:
Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object: 'NameOfObjectInDLL'
In our case, this last advice fixed our problems.
IIS > Authentication > Anonymous Authentication - Edit > "Application pool identity"
screenshot1
This is only to confirm the solution provided by keydon, combined by the one provided by TimP. And give them thanks!!
In our case we've changed the following 3 parts (and an additional 4th for new permissions):
Web server Authentication properties: set Anonymous Authentication with "Application pool identity" instead of "Specific User".
Application Pool "Identity" property: set to "ApplicationPoolIdentity" instead of "LocalSystem".
Web Site "Connect As" for physical path: set to "Application user (pass-through authentication)" instead of "Specific User".
Add permissions for "Application Pool Identity user name" in the shared folder where the web application files are. Have a look to https://learn.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities#securing-resources
Thank you!!
(I'm sorry I can't vote your solutions because I'm starter and I don't have any reputation)
Our company ships an MVC based product (targeting v4.5) which has stopped working on a customer site for what appear to be environmental issues - a build which worked with no problems once upon a time now gives a 403.14 - The Web server is configured to not list the contents of this directory.
.
What I think is happening...
The user accesses http://server/AppName
Because it's an MVC app, the default route (Reports/Index) should be used.
Instead IIS is looking for a default document...
... and, not finding one, it assumes the user wants to list the contents of the directory...
...which is not enabled so it throws a 403.14.
.
What I've tried so far...
Accessing the route directly.. results in 404 error. So I'm pretty
sure IIS doesn't realise it should use routing.
Use aspnet_regiis to register ASP.Net with IIS. This was done from the Framework64 folder since...
OS is 64 bit - Windows Server 2008 (Standard without Hyper-V)
IIS is 64 bit - though Enable 32-Bit Applications is true
Checked AppPool is targeting v4 of the framework - it is.
Changed AppPool mode to Classic - was pretty sure it should be integrated but was worth ruling it out. It is now back to Integrated
Confirmed RunAllManagedModulesForAllRequests is set to true in the web.config.
Checked permission conditions defined in <system.webServer> section of web.config are met - they are.
Created the simplest of MVC applications and deployed it - same problem.
Running the command shell as Administrator unregistered ASP.Net using aspnet_regiis -ua and re-registered using aspnet_regiis -enable -i. We hit a couple of permission problems - and the Temporary ASP.NET Files directory was missing but once they were address we were back to the same error.
Added a simple default.htm - when present, this is served in response to the http://server/AppName request.
I'm clean out of ideas and all google hits suggest some combination of the above - or enabling directory browsing (which I think is just a symptom rather than the root cause).
Also, not sure if it's relevant but the amount of configurable elements available for the application in IIS seems a bit below what I would have expected...
Have you Checked the user the application pool process is running under? I think Your site needs to run with permissions to execute the .net libraries and I've seen this just change for seemingly no reason (probably related to an overzealous update to the system).
You can try with the Enabling directory browsing .
assuming you are under Windows Server 2012 or Windows Server 2012 R2
On the taskbar, click Server Manager.
In Server Manager, click the Manage menu, and then click Add Roles
and Features.
In the Add Roles and Features wizard, click Next. Select the
installation type and click Next. Select the destination server and
click Next.
On the Server Roles page, expand Web Server (IIS), expand Web
Server, expand Common HTTP Features, and then select Directory
Browsing. Click Next.
On the Select features page, click Next. On the Confirm installation
selections page, click Install. On the Results page, click Close.
if you using the Windows PC try this in your command prompt as follows:
go to C:\Program Files\IIS Express
then press Enter:appcmd set config
/section:system.webServer/directoryBrowse /enabled
Maybe this is your case https://forums.iis.net/t/1157304.aspx
SQL Server Reporting Services creates a folder called Reports by
default if you install it on IIS. If you install SQL 2008 then
Reporting Services doesn't need to use IIS and instead will try to
reserve the URL with the HTTP.Sys service.
I believe this is the cause of the conflict you are seeing. What you
could try is changing the URL that Reporting Services uses via the SQL
Server Configuration Wizard.
Also I found that
Report Manager of SQL Server can use reports path http://<server name>/reports
Configure a Native Mode Report Server for Local Administration (SSRS)
I think the problem is IIS features that are not installed yet. I have met this kind of problem frequently in Windows Pro. Make sure to turn on every feature under Internet Information Service -> World Wide Services because by default IIS is configured to use WebForms. So there might be some features that not installed yet to use MVC, especially ISAPI filters. In my case, that was the solution. I hope it helps.
Something similar i encountered using VS 2017 & ASP.NET MVC.
Was working on the project for long with no problems at all but suddenly the routing started misbehaving & stopped working.
So I changed the Port in Project Properties Page & it started working.
I really don't know what is the relation between a port & MVC routing modules. Someone else can enlighten if at all this helps.
I had the same problem and I just created an application pool out of the Default Web Site in IIS and stoped the default web site. With that difference you will not have the application pool's path
I know it's been a long time since this question but i've had the same problema recently. I've tried every single configuration, just like #amcdermott did, but the only action that solve the problem was reinstalling .NET Framework.
My app was built under .NET Framework 4.5.2. The application server had the version 4.6.1 and 4.5.2 installed. So, i uninstalled all framework versions and installed the one that i needed.
Please, make sure that no other applications use superior versions of .NET Framework if you going to try this solution.
Here are some quote I find on Microsoft official site which I think may help:
For site administrators
This problem occurs because the Web site does not have the Directory Browsing feature enabled, and the default document is not configured. To resolve this problem, use one of the following methods:
Method 1: Enable the Directory Browsing feature in IIS (Recommended)
To resolve this problem, follow these steps:
Start IIS Manager. To do this, click Start, click Run, type inetmgr.exe, and then click OK.
In IIS Manager, expand server name, expand Web sites, and then click the website that you want to modify.
In the Features view, double-click Directory Browsing.
In the Actions pane, click Enable.
Method 2: Add a default document
To resolve this problem, follow these steps:
Start IIS Manager. To do this, click Start, click Run, type inetmgr.exe, and then click OK.
In IIS Manager, expand server name, expand Web sites, and then click the website that you want to modify.
In the Features view, double-click Default Document.
In the Actions pane, click Enable.
In the File Name box, type the name of the default document, and then click OK.
Method 3: Enable the Directory Browsing feature in IIS Express
Note This method is for the web developers who experience the issue when they use IIS Express.
To do this, follow these steps:
Open a command prompt, and then go to the IIS Express folder on your computer. For example, go to the following folder in a command prompt:
C:\Program Files\IIS Express
Type the following command, and then press Enter:
appcmd set config /section:directoryBrowse /enabled:true
I am developing on my local machine (Windows 7), and using IIS 7. I usually create a new website by right clicking on sites -> Add New Site. Then do the usual stuff by pointing to the physical files, and I'd stop all other websites which I didnt need. I could then run the site on port 80 without any binding conflicts.
I then recently started doing some ASP.NET development. When I published from my VS 2010 to local host I could run the website, and it all worked great. I then stopped the site (asp.net) but I couldnt start any of the other sites (not even the default). I am not sure why.
I started to read about App Pools and someone said to remove all the application pools. So I removed all my application pools (except the default app pool), and I also removed all the websites (as they had a red x next to them).
I now cannot start the default site as the restart, start and stop are greyed out. I cannot find out any way to reset the IIS server. One error I have received is;
the object identifier does not represent a valid object iis7
I dont know really know what this means, and when I search for this error it seems that many people have come across this error but in different contexts.
Is there any way to reset IIS so I can build simple websites again? Do I need to uninstall IIS and reInstall?
Uninstall IIS and reinstall would probably be the easiest and fastest way to accomplish this.
Other than that check the event logs see if you can find any clues there.
You'll want to ensure there is a one-to-one relationship between the number of sites & the app pools that host them. If they are 32-bit apps hosted on a 64-bit server, you'll need to enable this property (set it to True) on the app pool you want to use for your site. You'll want to run:
C:\inetpub\AdminScripts>cscript adsutil SET W3SVC/AppPools/Enable32bitapponWin64 1
The .NET Framework obviously needs to be installed, but then the separate step of running the ASP installation command needs to be done (C:\Windows\Microsoft.NET\Framework\v2.0.xxxx\aspnet_regiis.exe -i). If it already is, re-install them - it could be malfunctioning/corrupt.
After all that, I noticed IIS 7 puts on this generic app pool identity account to run the app pool with. I created a service account, gave this account Admin rights just to see if the site would run, and added it onto the app pool as the "Custom account". I no longer get the HTTP 503 error. The account should have the "Log on as a service" and "Log on as a batch job" rights. If it will be using impersonation and going out to a SQL database, the "Impersonate client after authentication" and "Allow log on locally" rights are also needed (hence why I like just giving it admin privileges to see if it works, first).
Background: I support a classic ASP environment. I have a development setup locally on my machine as part of that support. I am running IIS7.
To access my environment, I use "http://localhost:99999/" (port # faked for privacy purposes). I have not had a problem with this -- until today.
I built an application that is intended to run in this environment. The app is ASP.NET v.4.0 (for sake of example, I'll say it's called "http://localhost:99999/DotNetApp/"). Of course, in order to run this, I had to set up my environment application pool to support it (which it now does).
Problem: after configuring this, I am now getting:
Server Error in '/' Application.
Access is denied.
Description: An error occurred while accessing the resources required to serve this request. You might not have permission to view the requested resources.
Error message 401.3: You do not have permission to view this directory or page using the credentials you supplied (access denied due to Access Control Lists). Ask the Web server's administrator to give you access to '[filepath]\SourceFiles'.
I did NOT get this before I set my IIS configuration. Why am I getting this now?
Note: this ONLY happens with "http://localhost:99999/"; this does NOT happen if I try "http://localhost:99999/default.asp" (the page comes up with no problem).
Anyone have any insight?
Thanks in advance . . .
Edit: Additional symptoms: I tried playing with the application pool settings. The problem goes away if I change the .NET Framework version to either 2.0.50727 or to "No Managed Code." Changing it to 4.0.31319 breaks it. Of course, if I use any of the other two versions, my ASP.NET app won't run.
Edit #2: This problem occurs on ALL links that go to a folder or directory (e.g. "http://localhost:99999/somefolder/"), not just the web root.
Edit #3: I have a workaround: set "http://localhost:99999/" and "http://localhost:99999/DotNetApp/" in separate application pools. The first runs in .NET 2.0, while the latter runs .NET 4.0. (I'll post this as an answer once my 8 hour limit is up.) Probably not the best answer -- I'd prefer something that isn't as much of a kludge -- but for the time being, it'll get the job done. However, if anyone has a solution that enables me to run everything in the same app pool, by all means, post away!
You probably must specify "default.asp" as allowed in your "Default Document" settings in IIS7
EDIT: Check if ASP has been installed: Control Panel -> Programs and features -> Windows Features -> Internet Information Services -> Www services ->Application Development Features-> ASP
EDIT Final solution: The IUSR account is missing from the folder the website is in.
Set the default page for your site in IIS.
Try to set permission "Everyone" for directory "[filepath]\SourceFiles/" or/and "Allow" for other user names and groups in folder properties.
I am developing an intranet ASP.NET web application that's configured to use Integrated Windows Authentication. My web app needs to check user entitlements using LDAP to get user memberships, etc.
The issue I noticed today is that, when I run my web app using IIS, sometimes the LDAP calls fail with strange errors, such as "Unable to contact the server..." ... or "...that domain doesn't exist..." (something along those lines, anyway). However, if I run my web app using Cassini, I don't get those errors.
If IIS is the issue, why would it fail some times and other times not? What does Cassini do different that IIS is not doing?
I'm using IIS 5.1 / Windows XP / Visual Studio 2008
Why is this happening, and how can I fix it?
Probably something to do with the fact that when you're running Cassini, it's your domain account that's querying the LDAP. It is strange that it would work in IIS sometimes though, and not others. Is the server registered on the network? What system account is IIS running under?
#James Johnson: I figured it out thanks to your comment, which got me thinking about my domain account... Finally, I found this post which points out that in order to connect to LDAP one needs to set Impersonation=True in web.config. It was working intermittently this morning, I think, because I was using Firefox instead of IE, which required me to enter my domain username and password.
The other strange thing was that my app worked fine in our development and stage environments even though my web.config is the same for all of them. I suppose the guys in the hosting group have this set at the machine.config level.