This is a common VBScript, WScript, or IIS error mesage.
Introduction to Error Code 80070005
My gut feeling is
that 8070005 is a catch-all error code for any number of database / DCOM
connection problems. If I had to stick my neck out, I would say that it's a permissions problem. Thanks to readers sending in information on this error code, we are slowly building up a library
of problems, and even more importantly, solutions.
What I can offer is general principles, such as, pay close attention to the
line number and the precise wording of the error message.
Following the line number, I would turn my attention to permissions, are you logged on as an
administrator? What is the script trying to achieve? Does the file or folder referenced need admin rights?
This is often caused because you are not an Administrator, or do not have
administrator priveleges. A well phrased problem is half of the cure, and in
this case just make sure tht your account has the 'top dog' administrator
priveleges, and is using them.
Once you have logged off an logged on again (as Admin) just re-apply the
Windows Update or hotfix. Incidentally, insufficient rights or
priveleges is a common thread of other types of Access Denied problems in
general, and code 80070005 in particular.
Registry Fixes for Error Code 80070005
To be frank, I think that most people offering to sell you a registry
cleaner that will cure your 80070005 error are scam merchants. If I am
wrong, and you want to go down that route at leaset pay with card, that way
there is a chance that you can get a refund if I am right and the tool does
nothing useful.
1. Start -> Control Panel -> Administrative Tools -> Local Security Policy 2. Navigate to Security\Local Policies\Security Options
a. Network Access: Let everyone permissions apply to anonymous users - Set to Enabled c. DCOM: Machine Access Restrictions - Add Anonymous, Everyone, Interactive, Network, System with full rights options
set. d. Network Access: Let everyone permissions apply to anonymous users - Set to Enabled e. Network Access: Sharing security model for local accounts - Set to Classic
The "Sharing Security model"
is the real offending item I believe, and setting the above should fix the problem. If not then I went as far as setting the following in DCOMCNFG.
DCOM Configuration
1. Click Start -> Run 2. Enter
DCOMCNFG and press OK. This will open the DCOMCNFG window. 3. Browse down the tree to Console Root -> Component Services -> Computers -> My Computer 4. right-click on "My Computer" and select
properties 5. Select the "Default Properties" tab a. Enable Distributed COM on this computer - Option is checked b. Default Authentication Level - Set to Connect c. Default Impersonation Level -
Set to Identify 6. Select the "COM Security" tab 7. Click on Access Permissions ' Edit Default a. Add "Anonymous", "Everyone", "Interactive", "Network", "System" with Local and Remote access
permissions set. 8. Click on Launch and Activation Permissions ' Edit Default a. Add "Anonymous", "Everyone", "Interactive", "Network", "System" with Local and Remote access permissions set. 9.
Click on OK 10. Close the DCOMCNFG window
This was done with some trial and error on four identical HP Workstations running small vbs programs. Once one was working, I just had to figure out why
the others weren't. Guy says this is
Guy Recommends: A Free Trial of the Network Performance Monitor
(NPM)
SolarWinds'
Orion performance monitor
will help you discover what's happening on your network. This
utility will also guide you through troubleshooting; the dashboard will
indicate whether the root cause is a broken link, faulty equipment or
resource overload.
What I like best is the way NPM suggests solutions to network
problems. Its
also has the ability to monitor the health of individual VMware
virtual machines. If you are interested in troubleshooting, and creating
network maps, then I recommend that you try NPM now.
About This paper highlights the steps involved in
configuring an ASP.NET web application to work with a traditional COM
component when deployed on IIS 5.0 and therefore avoid the well-known error:
Retrieving the COM class factory for component with CLSID
{000209FF-0000-0000-C000-000000000046} failed due to the following error:
80070005.
I'm sure that there are different solutions to this problem. This one
will serve as one more addition to the long list of solutions which
developers just like me have recorded over their experiences.
Recommended: Solarwinds' Permissions Analyzer - Free Active Directory Tool
I like the
Permissions Analyzer because it enables me to see WHO has permissions
to do WHAT at a glance. When you launch this tool it analyzes a users effective NTFS
permissions for a specific file or folder, and takes into account network share
access, then displays the results in a nifty desktop dashboard!
Think of all the frustration that this free SolarWinds utility saves when you are
troubleshooting authorization problems for user's access to a resource.
Give this permissions monitor a try - it's free!
The situation I faced was including the LogParser.dll in a ASP.NET
project. Every attempt to use the component inside the IIS resulted in
the error being thrown, while using it from my unit tests presented no
issues. After attempting a number of the solutions given on your page,
I allowed the Application pool to run 32-bit applications. This solved
the problem: see screenshot below. [Kindly sent in by Henrik Aasted
Sorensen]
Project Overview - Access Denied 80070005
The project solution in discussion consists of 3 parts as shown in the
following screen shot:
1. An ASP.NET 2.0 Web application 2. A VB.NET Class library project
added to the solution 3. A third-party COM Component InterOp file
(highlighted in red)
The solution is developed using VS.NET 2010 that has a built-in web
server. In addition, the dev environment hosts IIS5.0 that rides on Windows
XP Professional SP3.
Note that, the third-party component is added as a reference to the
VB.NET library project and not the web project. When the solution is built,
the dependencies are moved to the \bin folder of the web application. This
may look trivial at first, but is enough to make you scratch your head when
you deploy the project to your local IIS Server.
As seen on the left, what is added to the \bin folder of the Web
application is not the physical DLL for the 3rd party component. Rather, it
is the Interop file that is added as a dependency. The Interop file is a
wrapper class that the .NET runtime generates and uses to connect to the
actual COM component. Overlooking this trivial fact is the reason why I'm
penning this paper.
COM file and InterOp file locations: Most of the hard work is done by the
ASPNET user account when it comes to handling a request sent to IIS 5.0.
Although this account is privileged to handle most of the stuff,
instantiating and using COM components is not one of them.
Therefore, it is important to note the differences between the Interop
file and the underlying COM library file. The following screen shot in
comparison to the one above illustrates this. The underlying native COM DLL
is located in an entirely different location.
It is possible that you've already configured your system to allow the
ASPNET account full permissions to the InterOp file. But this does not mean
that the ASPNET account can access the underlying native COM component. Most
probably it can't and this is where the catch is!
This
Engineer's Toolset v10 provides a comprehensive console of 50 utilities
for troubleshooting computer problems. Guy says it helps me
monitor what's occurring on the network, and each tool teaches me more about how the
underlying system operates.
There are so many good gadgets; it's like having free rein of a
sweetshop. Thankfully the utilities are displayed logically: monitoring,
network discovery, diagnostic, and Cisco tools. Try the SolarWinds Engineer's Toolset now!
Setting File Permissions to the Class Library Project Folder
The ASPNET account must have at least 'Read' permissions to your VB.NET
project folder. As seen from this screen shot, I've assigned read
permissions to the physical file folder of my VB.NET class library project.
You may ask me why the project folder and why not the files copied by
VS.NET into the \bin directory of the web application (as seen in the first
screen shot). That is because, if you set the right file permissions at the
original source locations, they will be copied over when the entire solution
is compiled. After you've completed this exercise and go back into the bin
folder of the web application, you will see that the file permissions
assigned to the ASPNET account are same as the ones that you assigned at the
original location.
Read Permission to the InterOp File:
Make sure that the InterOp file inside your class library project has
read permission as well. In my case, for some reason, the InterOp file did
not have read permission despite assigning read permission to the parent
folder (previous screen shot). Therefore, I had to add it explicitly like
so:
Read Permission to the native COM Library:
Before you assign permissions, make sure that you've registered the COM
library on the IIS machine using regsvr32. Then, locate the physical file
and assign Read & Execute permissions to it. It is important to note that
your application will err out if ASPNET does not have permissions to the
underlying native DLL even if it has full access permissions to its InterOP
file. This can easily escape ones attention!
Guy
Recommends: Permissions Analyzer - Free Active Directory Tool
I like the
Permissions Monitor because it enables me to see quickly WHO has permissions
to do WHAT. When you launch this tool it analyzes a users effective NTFS
permissions for a specific file or folder, takes into account network share
access, then displays the results in a nifty desktop dashboard!
Think of all the frustration that this free utility saves when you are
troubleshooting authorization problems for users access to a resource.
Give this permissions monitor a try - it's free!
Special Note of 80070005 Error on IIS 6.0 and Higher
IIS versions 6.0 and higher do not have the ASPNET worker process (aspnet_wp.exe).
Unlike versions before it, IIS 6 assigns ASP.NET requests directly to the
worker processes via local procedure calls (LPCs).
These steps above may need modifications based the type of IIS user
account that is used in your environment.
We had similar error 80070005 problem in our team. The problem was with IIS server in XP Professional environment. FoxPro 9 (foxisapi) was used for dynamic creation of the web pages.
It is
strange, but the problem was resolved by changing the value in the 'User Name' field in the Authentication Method popup window (Control Panel > IIS > Default Web Site > Properties > page Directory Security >
Anonymous Access - Edit button). The value was changed to 'EVERYONE' and the error has disappeared. However, "everyone" is not the only possible word. Seems that all words, which are different than the
names of the existing IWAM_* and IUSR_* users are OK.
My error 80070005 was down to a setting within IIS for my website. The default application is set to "default application pool", whereas I have changed this is "Exchange Application" and it now works fine.
Guy
Recommends: WMI Monitor and It's Free!
Windows Management Instrumentation (WMI) is one of the hidden
treasures of Microsoft operating systems. Fortunately, SolarWinds
have created the
WMI Monitor so that you can examine these gems of
performance information for free. Take the guess work out of which
WMI counters to use for applications like Microsoft Active Directory,
SQL or Exchange Server.
In this instance you are managing Users with Active Directory Users and Computers. Most likely, you try and update a subset of attributes on user objects. In particular, this problem occurs when
you try to update the values for users who have mailboxes enabled.
When you browse to an Active Server Page (ASP) database results page, you receive an error
message saying:
Server object error 'ASP 0178 : 80070005'
Server.CreateObject Access Error
/_fpclass/fpdbrgn1.inc, line 83
The call to Server.CreateObject failed while checking
permissions. Access is denied to this object.
This error can be caused by incorrect NTFS permissions for your "%ProgramFiles%\Common Files\System" folder.
Solution: To solve
this problem change the NTFS permissions on the "%ProgramFiles%\Common Files\System" folder. Add Everyone to the existing permissions, give at least Read permissions to Everyone, remember to apply
these new settings to all files and subfolders.
Another Solution: Try logging on as administrator.
Summary of Error Code 80070005 Access Denied
My gut feeling is
that 8070005 is a catch-all error code for any number of database / DCOM
connection problems. If I had to stick my neck out, I would say that it's a permissions problem. Thanks to readers sending in information on this error code, we are slowly building up a library
of problems, and even more importantly, solutions.
Therefore, if you have a screen shot and a code then send it to me,
Thus utility makes it easy to check the health of a router or firewall. Check the real-time performance and availability statistics for any device
on your network.
