UNSOLVED
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
