Tuesday, March 27, 2012

Cluster Resource replacing physical server

We are replacing an existing SQL 2000 EE server with a clustered
resource by the same name. We have done this before, but are running
into an issue on this install. Here are the steps we have performed:
* Migrate databases as files
* Shut off original server
* Delete original computer account and replicate to all domain
controllers.
* Create cluster resource (third resource in this cluster)
We are having problems though with cluster recognizing the old server
account. We are getting Event ID 1210 on Clussvc on the install.
"Cluster resource 'SQL Network Name(ITSQLEE)' failed to go online
because its associated computer account (ITSQLEE) exists in Active
Directory and the Kerberos authentication is not enabled for the
resource. Client applications that are using Kerberos based
authentication (either directly or through the Negotiate security
package) will fail to authenticate when contacting a service by this
network name.
To bring the resource online, either enable Kerberos authentication or
delete the computer account."
In a prior event message, we get 1119 - Clussvc - Bad DNS Key. I have
tried this multiple times after waiting for Active directory to
synchronize and verifying with replmon. Any ideas? Thank you.
Hi Bowulf
The reason for this could be that the changes in Active Directory isn't
replicated around to all Domain Controllers. You could initiate Force
Replication but if you are in an enterprise environment this could cost in
terms of bandwith. Hence when you delete the computer account and it's not
replicated you would get this message.
Any help?
"Bowulf" wrote:

> We are replacing an existing SQL 2000 EE server with a clustered
> resource by the same name. We have done this before, but are running
> into an issue on this install. Here are the steps we have performed:
> * Migrate databases as files
> * Shut off original server
> * Delete original computer account and replicate to all domain
> controllers.
> * Create cluster resource (third resource in this cluster)
> We are having problems though with cluster recognizing the old server
> account. We are getting Event ID 1210 on Clussvc on the install.
> "Cluster resource 'SQL Network Name(ITSQLEE)' failed to go online
> because its associated computer account (ITSQLEE) exists in Active
> Directory and the Kerberos authentication is not enabled for the
> resource. Client applications that are using Kerberos based
> authentication (either directly or through the Negotiate security
> package) will fail to authenticate when contacting a service by this
> network name.
> To bring the resource online, either enable Kerberos authentication or
> delete the computer account."
> In a prior event message, we get 1119 - Clussvc - Bad DNS Key. I have
> tried this multiple times after waiting for Active directory to
> synchronize and verifying with replmon. Any ideas? Thank you.
>
|||Thanks for the reply. I had ensured with replmon that the 11 Domain
Controllers had all been synchronized with the each other, and that the
ADUC on each domain controller showed the computer as removed. The
entry was of course still present but tombstoned. I would hate to
think I would have to wait 90 days though.
ipconfig2 wrote:[vbcol=seagreen]
> Hi Bowulf
> The reason for this could be that the changes in Active Directory isn't
> replicated around to all Domain Controllers. You could initiate Force
> Replication but if you are in an enterprise environment this could cost in
> terms of bandwith. Hence when you delete the computer account and it's not
> replicated you would get this message.
> Any help?
>
> "Bowulf" wrote:
|||It is my understanding that this would be the behavior if DDNS did not
properly delete the entry, regardless of the status of the AD replication.
A simple ping of the name for the A record and reverse for the PTR would
indicate if it were still present.
Delete the DNS records manually.
Install the installation.
Create the virtual computer account manually if the Cluster service account
does not have sufficient rights.
Manually apply the SPN registrations for the SQL Server service account.
Then connect to cluster administrator to Enable Kerberos on the network name
resources.
Sincerely,
Anthony Thomas

"Bowulf" <bowulf@.gmail.com> wrote in message
news:1165709800.241227.11990@.79g2000cws.googlegrou ps.com...[vbcol=seagreen]
> Thanks for the reply. I had ensured with replmon that the 11 Domain
> Controllers had all been synchronized with the each other, and that the
> ADUC on each domain controller showed the computer as removed. The
> entry was of course still present but tombstoned. I would hate to
> think I would have to wait 90 days though.
> ipconfig2 wrote:
in[vbcol=seagreen]
not
>

No comments:

Post a Comment