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)
Related
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.
I have two websites which are more or less identical, both running on the same server, but under different app pools. The app pools are both configured to run with "NETWORK SERVICE" credentials.
On one website - call this the development copy, I receive the infamous "validation of view state MAC failed" error. This happens when a postback occurs after the page is idle for 20 minutes. I've been informed this is because I don't specify the machine key in the web.config or the machine config file. Manually recycling the app pool reproduces the error as expected. So my question is not about how to stop the issue, but rather I want to know why the error happens in dev but not production. The only difference between the setup of the two sites is the authentication method.
In the "basic settings" section of the IIS config, the dev version of the site is set to connect using a service account, while the production version is using "application user" (pass through authentication). Under authentication settings, both pages are configured with impersonation and windows authentication.
This is the only difference I can see. My knowledge of how IIS handles authentication at the site and app pool level is fairly limited. Is there a specific reason why one setup should result in the machine key being refreshed but the other does not?
After installing .NET 3.5 SP1 you may get Validation of viewstate MAC failed exceptions when doing post backs on ASP.NET pages.
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.
After deployment of new version of our ASP.NET 2.0 application, it started to raise security exception: „System.Security.SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.“.
After quick research on internet we were able to resolve this isse by setting „Load User Profile“ to True in IIS 7.5 application pool. This solution is also mentioned several times here on stackoverflow:
Strange ASP.NET error !
System.Web.AspNetHostingPermission Exception on New Deployment
Running a asp.net web application project on IIS7 throws exception
However we were unable to find reason why it has to be true. We reviewed all changes in new version (gladly there were only a few), but didn’t find anything suspicious (no access to registry or temp data as some articles suggested etc). Could anybody give us hints when an ASP.NET application hosted in IIS 7.5 needs „Load User Profile“ option set to True?
Details:
Application pool: .NET 2.0; Managed Pipeline Mode - Classic; Identity – custom domain account
In IIS 6.0 (W2K3): Old and new
version of application work fine
In IIS 7.5 (W2K8-R2): Old version of
application works fine; new version
of application raises security
exception – it starts to work after
setting „Load User Profile“ to True
Thank you!
EDIT:
We have finally found the cause of this problem! Our admin used different technique to copy the new version of application from staging environment to production environment. He used web server as intermediary. After donwloading zipped release build artifacts to production environment and then unzipping the files, they were still marked as "blocked" because they came from different computer. See also https://superuser.com/questions/38476/this-file-came-from-another-computer-how-can-i-unblock-all-the-files-in-a. ASP.NET then logically executes these binaries in partial trust instead of full trust and that was actually causing mentioned security exceptions in our application.
Setting "Load User Profile" to True fixed the security exceptions as a side-effect. If "Load User Profile" is set to False, then our application (not our code, maybe some .NET BCL or external assembly) is trying to query basic info about directory "C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\Temporary Internet Files" which the identity of application pool is not allowed to:
With full trust: access denied to this query operation doesn't raise any exception
With partial trust: access denied to this query operation raises security exception
If "Load User Profile" is set to True, then temporary profile in Users directory is created every time when application pool starts. Our application is then trying to query info about "Temporary Internet Files" directory of this profile, which the identity of application pool is allowed to. Thus no exception is raised even with partial trust.
Really nice troubleshooting session! :)
One more example when "Load User Profile" setting could helps you is usage of temporary files. Sometime this usege can be indirect. SQL Express for example can do this in some situations.
So my advice. Switch off "Load User Profile" and examine %TEMP%. Then try to give domain account used for application pool the full access (or change access) to the directory from %TEMP%. Probably it fix your problem.
One more advice is usage of Process Monitor (see http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) to locale which parts of user profile will be used (or receive "access denied" error) at the moment when you receive "System.Security.SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission" exception.
Another area where LoadUserProfile might help is when configuring a trusted MSMQ binding in WCF. If the app pool is running under a trusted account, this won't load the SID unless the Application pool load user profile setting is set to true, and hence authentication will fail.
I also ran into the same problem and could resolve the problem by setting load user profile=true. However i have reverted the load user profile = false and restarted the app pool but now i dont get any exception.
I have gone through all the relavents posts on stackoverflow and also on Asp.net and iis forum pages.
We're seeing an odd pattern in our QA Lab. We have two ASP.NET applications, each deployed on the same Windows 2008 SP2+ box. We have our App Pool running in a Domain Account, and set to never re-cycle. The same 1 App Pool is used by both applications.
After several hours of running fine, new users surfing to a page in our application get the IIS7 Error Page, with a 500.21 error.
If we do nothing but:
1) IISRESET
2) Change folder to c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files and "rd" the 2 applications.
And then surf to our web applications, all is fine.
Then several hours later, however, the 500.21 errors return.
What strikes me as odd is the seeming relationship between clearing the "Temporary ASP.NET Files" folders and the problem going away. I've a practice of clearing the "Temporary ASP.NET Files" folders when installing a new version of our application(s), but not otherwise.
Does this relationship ring familiar to anyone? Is there some new-ish IIS7 feature at work here?
Text of Error:
Server Error in Application "DEFAULT WEB SITE/PAIS"
Internet Information Services 7.0
Error Summary
HTTP Error 500.21 - Internal Server Error
Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list
Detailed Error Information
Module IIS Web Core
Notification ExecuteRequestHandler
Handler PageHandlerFactory-Integrated
Error Code 0x8007000d
Requested URL http://localhost:80/PAIS/Admin.aspx
Physical Path C:\0_Georgia\GA_IS_100142\PortfolioArchiveImageServer\Admin.aspx
Logon Method Anonymous
Logon User Anonymous
Most likely causes:
• ASP.NET is not installed or incompletely installed.
• A configuration typographical error occured.
• Unfavourable pre-condition evaluation exists.
Things you can try:
• If ManagedPipelineHandler is missing, ensure that:
o ManagedEngine is in .
o ManagedPipelineHandler is in , with correct pre-conditions.
• Install ASP.NET.
• Ensure all system.webServer/handlers#modules are in system.webServer/modules#name.
• Review pre-conditions in the and sections.
Links and More Information IIS core does not recognize the module.
View more information »
Thanks in advance,
Howard Hoffman
Faced the same problem and the fix was easy.
1) Open visual studio 2010 command prompt.
2) Run the command aspnet_regiis.exe -i
We found the actual problem, with MS ASP.NET support's help. It's pretty subtle. I think MS has said they will fix the issue in a follow on to the App Fabric release (which is now RTM). Fingers crossed.
The problem consistently occurs in this scenario:
1) ASP.NET web application not yet running. It includes WCF Net.Pipe and / or Net.Tcp bindings. I think the same would occur for NetMsmq but did not try it.
2) An inbound NetPipe or NetTcp WCF Windows Activation Service request is the initial request that starts the App Domain.
3) Application uses an 'Integrated' IIS App Pool (IIS7 or IIS 7.5)
4) The application uses HttpServerUtility.Execute during that 1st request.
It turns out that our application was firing an ASP.NET Health Monitoring event during the very 1st WCF operation -- the very operation that caused Windows Activation Service (WAS) to start our application. Our Health Monitoring configuration includes the TemplatedMailWebEventProvider.
Our application is using an 'Integrated' IIS App Pool.
The TemplatedMailWebEventProvider is implemented to create an email message body as HTML. It uses the System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean) overload.
For this use case that overload does the wrong thing -- it initializes a 'Classic' IIS App Pool based HTTP pipeline. Because that's the wrong pipeline for an 'Integrated' IIS App Pool the pipeline gets corrupted with the next HTTP request -- which is actually the first inbound HTTP request.
So you get the 500.21 error for all future HTTP requests until the application is re-cycled. You don't need to perform the relatively drastic steps of IISRESET, clearing Temporary ASP.NET cache to clear up the error -- just restart the app via saving web.config and avoid the particular startup path that causes the error.
MS suggested a workaround for us -- use the SimpleMailWebEventProvider instead of the TemplatedMailWebEventProvider. That does work, since it takes HttpServerUtility.Execute out of the code path for the first request.
I'd suggested that MS introduce a new web.config <system.web> boolean setting -- UseIntegrated -- that let's the application specify the typeof App Pool to initialize with. Evidently IIS does not forward the App Pool type to ASP.NET, so my sugggestion is a work-around to that.
The TemplatedMailWebEvent provider is much more user friendly than the SimpleMailWebEventProvider, and we do hope MS addresses the issue.
Thanks all for reading,
Howard Hoffman
1. IIS 7 throws an exception as shown in below
2. Open visual studio 2010 command prompt in Administrator mode and execute aspnet_regiis.exe -i
3. Problem fixed, as shown below ASP.Net Application and ASP.Net MCV Application are running smoothly.
The problem more likely is in the application code. The Temporary ASP.NET Files folder contains pre-compiled copies of your app and will be refreshed every time the applications files are accessed. You can pre-compile these files with aspnet_compiler.exe in the \Windows\Microsoft.NET\Framework\v2.0.50727\ folder. Use the -errorstack option allow for more information to be generated about the error you are getting. Long running applications that don't recycle will run into problems if they use a lot of memory or retain large amounts of data in an inproc session state. if your sessions contain large amounts of information, consider using a sqlserver-based session manager.