Old server is windows 2000, and the original setup guy's answer to pretty much everything was C:\ --> Everyone --> Full Control. However, there WAS a setup doc, that seemed to work up to a point.
- Created a local admin com user
- Created COM+ applications referencing that user and some dll's supplied with the site
- Installed .net versions 1.0, 1.1, 2.0 (I've tried running under each version, no change in error)
Server object error 'ASP 0178 : 80070005' Server.CreateObject Access Error /Include/fnLookups.asp, line 10 The call to Server.CreateObject failed while checking permissions. Access is denied to this object.
Line 10 appears to be:
set objClient = Server.CreateObject("fooUser.CfooUser")
I trundle off to the System log and I have:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {280D5CF7-80A4-40AC-844C-FE3653F02FF1} to the user mydomain\myusername SID (mySID). This security permission can be modified using the Component Services administrative tool.
This is progress of sorts, it's picking up the COM app and my ID just fine. I added myself to the "Access Permissions" and "Launch & Activation Permissions" of the My Computer object in dcomdnfg - but my barking seems to be directed at the wrong tree.
I ran through mskb198432 as well as I could, though it seems directed at an earlier version, but no joy there, either.
Any ideas are welcome.
Edit - list of suggestions tried
- Ruled out the x64 difference, running in x32 with the same issue.
- ruled out file permissions
- "give Everyone Local Launch and Activation permissions to be sure it's a COM permissions issue" - done, no joy
- IIS5 Isolation mode enabled
Edit - Is there anything I can look into on the old windows 2k server that may lend some insight?
Have you tried adding the relevant user to the local DCOM Users group?
http://technet.microsoft.com/en-us/library/cc738214(WS.10).aspx
This error is the clue:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {280D5CF7-80A4-40AC-844C-FE3653F02FF1} to the user mydomain\myusername SID (mySID).
The COM object should not be running as you, it should be running as the IUSR_MachineName or Network Service user, the user that is running IIS. You don't want every user that accesses the site to be running the DLL as them - bad idea.
Make sure that the permission of the physical directory that your virtual directory points to have the user that is running IIS (IUSR_machinename) have the correct permissions, and the DLL that is registered in COM has the correct permissions for the IIS user.
Permissions are hard to debug in IIS, as security events are not always logged to the Security event log. The Authentication & Access Control Diagnostics 1.0 tool is a great tool for investigating permissions issues.
http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1285
For completeness sake, there is a difference between running a site as ASP.Net 1.0 and ASP.Net 2.0. Although the framework is backwards compatible, I would suggest trying to run the site as a Framework 1.1 site. This may require the loading of Framework 1.1.
However the code sample suggest that this is classic ASP. Therefore the problem is related to security on the COM Object. Ensure that the DLL has been registered, and there is also a possibility that the object you gave permission to is dependent on another DLL that you haven't given access to.
Also, restart IIS and also the Component itself in component server when changing security, or any changes for that matter. It often needs to be kick started, due to memory caching and other extended reasons.
According to the Microsoft Web Technology blog this is bug is caused by enhanced DCOM security that was introduced in SP1 or SP2 for Windows 2003.
This blog has a pretty detailed run down of this problem and how to solve it.
http://blogs.msdn.com/puneetgupta/archive/2008/01/19/server-createobject-failed-while-checking-permissions.aspx
Like some users complained, you weren't clear if this is classic asp or asp.net. That said, going with your subject line and error message, here is my 2 cents
Is this is a .NET application
It looks like your application is accesing a COM object so make sure the IIS worker process has access to that component. You can try running FILEMON and REGMON to find out exactly which component is the culprit. If the component is in the Program Files/Common folder, then make sure the correct permissions is set on that folder.
Accessing COM components in ASP.NET or even Classis ASP is usually a B.... to troubleshoot.
This is a classic ASP application, not an ASP.NET app. Make sure your IIS app pool hosting that app is running in the context of the user you created. Also, make sure that app is not in any other app pools that host ASP.NET apps.
There are 2 different security settings on My Computer - Limits and Defaults. You need to double check that you edited the Defaults, and that Limits is at least higher than your Defaults (though, IIRC, Everyone can have Local Activation).
You should also drill down to the component itself and make sure it is using the Default security. If it's Customized, then you need to edit that as well (keeping the Limits in mind).
For troubleshooting, I'd be sorely tempted to just give Everyone Local Launch and Activation permissions to be sure it's a COM permissions issue. IIRC, errors in the component startup can have misleading error messages that will keep you scratching your head for a while.
Edit: You should also make sure the GUID referenced in the event log is actually the component you think it is. Use Regedit to find the GUID, and check the AppName. It's possible that it's not the installed component, but a dependency instead.
As others have said, this is an classic ASP and COM issue - seems to have nothing to do with .NET.
All I can add to what's been said is don't forget to ensure that the user has access to the COM object DLL on the file system.
Try giving "Network Service" an access to the "Temp" directory (C:\WINDOWS\Temp)
I hope this helps ;-)
Are you running the Application Pool as your account (mydomain\myusername)? If so, you will need to add that account to the IIS_WPG.
You might also want to add IIS_WPG to the "Distributed COM Users" group or find the actual item in the Component Services and directly grant access to IIS_WPG