Error 42d during Fail Over SQL 2000 Enterprise in a Server 2003 Ent. Cluster

Hi All,
I've been struggling with this issue for a few days now.
We have 2node Server 2003 Entprise cluster with a fresh install of
MSSQL 2000 SP3a. Everything works great until I attempt to simluate a
node failure. Node 2 starts every service fine with the exception of
the 3 SQL services:
SQL Server
SQL Server Agent
SQL Server Fulltext
When I check the event log I see the following twice:
Event ID : 17052 [sqsrvres] StartResourceService: StartService
(MSSQLSERVER) failed. Error: 42d
Event ID : 17052 [sqsrvres] OnlineThread: ResUtilsStartResourceService
failed (status 42d)
Event ID : 17052 [sqsrvres] OnlineThread: Error 42d bringing resource
online.
Now I've read prior posts and have found that the 42d when converted
from HEX means that it's a logon failure. However I'm using the
Administrator account, have re-entered the username and password 3+
times and have checked all the domain security policies against this
account. I've even added Administrator to the "logon as service" and
three other priv's that Microsoft recommends.
I have rebooted the server numerous times now after each change and I
am still experiencing the same problem. What could I be missing?
I appreciate your time in this matter.
~Chris
Christopher,
Are you using the local "administrator" account to startup the services? If
so you should create a special domain account to startup your sql server
servcies on both servers and add this account to the Administrators local
group or to any other group with the restricted privileges you want.
Try from the working node, on the Enterprise manager to change the startup
account to the one which is currently working, doing from the EM should
change the account on all the nodes on the cluster.
Hope this helps.
Regards.
FR
|||On May 16, 5:26 pm, Frivas <Fri...@.discussions.microsoft.com> wrote:
> Christopher,
> Are you using the local "administrator" account to startup the services? If
> so you should create a special domain account to startup your sql server
> servcies on both servers and add this account to the Administrators local
> group or to any other group with the restricted privileges you want.
> Try from the working node, on the Enterprise manager to change the startup
> account to the one which is currently working, doing from the EM should
> change the account on all the nodes on the cluster.
> Hope this helps.
> Regards.
> FR
Greetings Frivas,
Thanks for your response. I am using the "Domain Administrator"
account. The software vendor the cluster is assembled for required
that we use that account unfortunately. However I will give your
recommendation a try and let you know my findings.
Thanks again.
~Chris
|||Look for the location of the SQL agent log file and make sure it is a
clustered resource in the SQL group. There is a bug in the
install/configure routines that allows the log file to be placed in an
incorrect cluster location.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<christophercnewton@.gmail.com> wrote in message
news:1179350437.951320.310920@.p77g2000hsh.googlegr oups.com...
> Hi All,
> I've been struggling with this issue for a few days now.
> We have 2node Server 2003 Entprise cluster with a fresh install of
> MSSQL 2000 SP3a. Everything works great until I attempt to simluate a
> node failure. Node 2 starts every service fine with the exception of
> the 3 SQL services:
> SQL Server
> SQL Server Agent
> SQL Server Fulltext
> When I check the event log I see the following twice:
> Event ID : 17052 [sqsrvres] StartResourceService: StartService
> (MSSQLSERVER) failed. Error: 42d
> Event ID : 17052 [sqsrvres] OnlineThread: ResUtilsStartResourceService
> failed (status 42d)
> Event ID : 17052 [sqsrvres] OnlineThread: Error 42d bringing resource
> online.
> Now I've read prior posts and have found that the 42d when converted
> from HEX means that it's a logon failure. However I'm using the
> Administrator account, have re-entered the username and password 3+
> times and have checked all the domain security policies against this
> account. I've even added Administrator to the "logon as service" and
> three other priv's that Microsoft recommends.
> I have rebooted the server numerous times now after each change and I
> am still experiencing the same problem. What could I be missing?
> I appreciate your time in this matter.
> ~Chris
>
|||Chris you should know that there is no technical reason to a domain admin
account. Usually people want a domain account so that they can run things
against an other machine. If you do create a service account and make is
local admin on the system and other systems that is needs to talk to you will
be fine. We run all our servers with service accounts that are just normal
users on the domain and the network, in some special cases that account in
local admin.
Good Luck
John Vandervliet
"christophercnewton@.gmail.com" wrote:

> On May 16, 5:26 pm, Frivas <Fri...@.discussions.microsoft.com> wrote:
>
> Greetings Frivas,
> Thanks for your response. I am using the "Domain Administrator"
> account. The software vendor the cluster is assembled for required
> that we use that account unfortunately. However I will give your
> recommendation a try and let you know my findings.
> Thanks again.
> ~Chris
>
|||Also make sure that if you have removed the BUILTIN\Administrators group as
a valid login that you add back the service account that operates the
Cluster service.
It does not need any special rights, but it will need to log into the
server.
On both cluster nodes, make sure that the SQL Server service account is a
domain account and has the following User Rights assignments:
Act as part of the OS
Bypass Traverse Checking
Lock Pages in Memory
Log on as a Batch Job
Log on as a Service
Replace a Process Level Token
http://support.microsoft.com/kb/283811
Anthony Thomas

"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:utHVUXImHHA.4752@.TK2MSFTNGP04.phx.gbl...
> Look for the location of the SQL agent log file and make sure it is a
> clustered resource in the SQL group. There is a bug in the
> install/configure routines that allows the log file to be placed in an
> incorrect cluster location.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> <christophercnewton@.gmail.com> wrote in message
> news:1179350437.951320.310920@.p77g2000hsh.googlegr oups.com...
>