Unsolved
This post is more than 5 years old
5 Posts
0
660
DCOM access denied error traced to CoSAA cluster translation
We have two Win2KAS SP4 servers running AAM/CoSAA 5.1.2 with Oracle for Windows module 3.1. Last weekend we applied 15 recent Windows patches to both servers and upgraded the EMC PowerPath software and HBA firmware for SAN on one server in the cluster (the other server has direct attached storage).
Following this, we could connect fine through Oracle SQLPLUSW, we could connect through SOME components of the application that accesses that database, but certain DCOM components generated the following error in the event log:
DCOM got error "General access denied error " from the computer xxxxxxxxx when attempting to activate the server:{ CLSID}, where xxxxxxxxx is the cluster name and the DCOM service is trying to start on the physical server that the cluster name is pointing to.
We tried it on both servers in the cluster, after failing over the database (to eliminate the Powerpath/HBA upgrades as the issue) and also after uninstalling all the Windows patches that had been installed, but neither of these made any difference.
We worked with the vendor for about 15 hours on this one, looking at DCOM settings to no avail. They eventually concluded that it was actually an issue with Legato translating the cluster name for DCOM services running on the active server. We concluded this because if we reconfigured the application to directly access the database using the server name rather than cluster name, everything worked fine.
Question to the experts here is therefore, what may have occurred to prevent DCOM services from being able to loopback onto the server via the cluster name (if that makes sense)?
Thanks
Tim
Following this, we could connect fine through Oracle SQLPLUSW, we could connect through SOME components of the application that accesses that database, but certain DCOM components generated the following error in the event log:
DCOM got error "General access denied error " from the computer xxxxxxxxx when attempting to activate the server:{ CLSID}, where xxxxxxxxx is the cluster name and the DCOM service is trying to start on the physical server that the cluster name is pointing to.
We tried it on both servers in the cluster, after failing over the database (to eliminate the Powerpath/HBA upgrades as the issue) and also after uninstalling all the Windows patches that had been installed, but neither of these made any difference.
We worked with the vendor for about 15 hours on this one, looking at DCOM settings to no avail. They eventually concluded that it was actually an issue with Legato translating the cluster name for DCOM services running on the active server. We concluded this because if we reconfigured the application to directly access the database using the server name rather than cluster name, everything worked fine.
Question to the experts here is therefore, what may have occurred to prevent DCOM services from being able to loopback onto the server via the cluster name (if that makes sense)?
Thanks
Tim
tribicic
157 Posts
1
May 24th, 2009 09:00
Please check the following Microsoft article for more info, I suspect you may be facing the similar problem:
http://support.microsoft.com/kb/926642
CookeTim
5 Posts
0
June 2nd, 2009 07:00
Thanks for the pointers. That article pointed me to looking at DisableLoopbackCheck registry entry, which was set to 0. For Windows 2000 it is specifically mentioned in this article http://support.microsoft.com/kb/957097 and we have that patch installed, so we will look at making the changes suggested.
Regards
Tim