Server.CreateObject failed while checking permissions

  • Makale
         Server object, ASP 0178 (0x80070005)
        The call to Server.CreateObject failed while checking permissions. Access is denied to this object.
        /MathsLibrary.asp, line 3

This is one of the most common errors that I have come across when anyone over tries to use their newly developed DCOM or COM+ Components. The error will come only after you have applied sp1 or sp2 for Windows 2003 or any service pack post sp2 on Windows XP. This happens basically because of some enhanced DCOM security which is introduced in the service pack.

The COM+ Server and the client are on the same machine

If the both the client and the COM+ Server are on the same server, check if Enable Access Checks for this application is selected or not . If it is selected then the user under whose context the call to the COM+ component is made, should be a part of the Roles section for that COM+ Component. An easy way to find out the user under whose context the call to the COM+ Component is failing is to Enable extra logging as per the https://support.microsoft.com/?id=892500 and add ActivationFailureLoggingLevel and CallFailureLoggingLevel registry keys and you might get an event like this in the event viewer.

        Event Type:          Error
        Event Source:       DCOM
        Event Category:    None
        Event ID: 10016
        Date                   12/22/2006
        Time                   1:39:08 PM
        User                   DISTSVCINDIA\IUSR_W2003ENTSP1
        Computer            DISTSVCINDIA
        Description:
        The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
        {6AC14250-1C8C-48BC-AFBC-22378C3EC7CA} to the user DISTSVCINDIA\IUSR_W2003ENTSP1 SID <SID> This security permission can be
         modified using the Component Services administrative tool.

So if you want the COM+ Role based security, just add the user name that you determined in the above step to the Roles for the COM+ Application and that should take care of it, otherwise you can just uncheck the Enable Access Checks for this application option which will end up disabling the COM+ Role based security completely.

If this step alone doesnt fix the issue, that would mean that the user listed in the above error doesnt have proper DCOM permissions and to give that particular user proper DCOM permissions, you will have to add the user to the DISTRIBUTED COM USERS group (A group which was specifically introduced in Windows 2003 sp1 for this sole purpose only)

If the COM+ Server and the client are on a different server (and the client is basically a web server running IIS 6.0)

You have a COM+ Server and you have exported it into a proxy MSI. After exporting the proxy MSI you install it on your web server and then you get the above error. In this case a lot matter on whether your web server is a Windows 2003 machine or not. If it is a windows 2003 machine you can follow Method 2 of the KB 889830 to bring it to the same level as a Windows 2000 machine (IIS 6.0 changes the LogonMethod, before IIS 6.0 the user that would be used to active the remote COM+ application was ANONYMOUS LOGON. Post IIS 6.0 for anonymous account the LOCAL IUSR account is used. Since this IUSR account is a local account and not known to the remote COM+ server the logon fails and hence the COM calls fails.

You might also get a DCOM error like the above one in the event viewer of your machine. The USER name now will point to the IUSR account on the local server (web server). If you are getting that, go to COMPONENT SERVICES->My Computer. Right click and choose COM Security. Click on Edit Default (under launch and activation permissions) and then add the local IUSR account there and give it all kinds of activations. REBOOT THE BOX AFTER THIS

Ensure that you have fixed all errors on the web server’s machine and only then start looking for errors on the COM+ Server. If you changed the LogonMethod to 2 on your Windows 2003 machine (if it is Windows 2000 it is already 2), it is possible that your COM Call still fails on the remote server. The first thing to check in such a case is security audits on the Application Server. If you see the success audit in the event viewer and you are able to see the WORKSTATION name of the remote server, then it means that user from your web server is able to login to your application server. If you have not followed 889830 you will notice some failure audits here.

If AnonymousLOGON is having some problems an error like this can occur in the SYSTEM LOG on the application server.

         Event Type:       Error
        Event Source:    DCOM
        Event Category: None
        Event ID:          10027
        Date                12/22/2006
        Time                2:19:00 PM
        User                NT AUTHORITY\ANONYMOUS LOGON
        Computer         DISTSVCINDIA
        Description
        The machine wide limit settings do not grant Remote Activation permission for COM Server applications to the user NT AUTHORITY\ANONYMOUS 
        LOGON SID (S-1-5-7).  This security permission can be modified using the Component Services administrative tool.

As an easy fix add ANONYMOUS LOGON to Distributed COM Users (available on Windows 2003). For other OS you might want to add ANONYMOUS LOGON to both Edit Limits and Edit Defaults in the Activation Section and give full activation permission. I recommend rebooting the machine after making machine wide changes in DCOM settings

Comments

  • Anonymous
    October 12, 2014
    The comment has been removed
  • Anonymous
    August 14, 2017
    The comment has been removed