cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
654
Views
0
Helpful
5
Replies

Failed to replicate the SQL server after perfoming the Failover Wizard

raymond.lai
Level 1
Level 1

Hi,

I have helped my client to set up 2 Unity servers running with failover. After performing the failover wizard on both Unity servers, everything is working fine such as failover and failback. However, I found that the SQL server database between these 2 Unity servers are not replicated at all. Is there anything I have missed during the setting of the failover?

Thanks,

---

Ray

5 Replies 5

Hin Lee
Cisco Employee
Cisco Employee

Is your MsSql and SqlServerAgent services running with a domain account or local system?

H. M.

Hi H.M.

Both services are running with one common domain account with the local admin right on both Unity servers. In fact, I heard some of the rumours that this problem might be related to the suffix domain. As my Unity servers are using the client's local DNS server but I believe that both Unity servers are configured without the suffix domain. But both servers can ping with each other using the server name or computer name. Would this be the reason that causes both SQL databases on each Unity server not replicated?

Thanks,

---

Raymond

I'll make the assumption that you have implemented Unified Messaging into your DATACRAFT domain. That means that you must have joined the unity servers into the DATACRAFT domain. The Unity servers' ip address properties must point to a DNS server that has SRV records for DATACRAFT domain - usually that means the DATACRAFT domain controller. Hopefully you have config'd DATACRAFT's domain controller correctly by pointing back to itself for DNS.

On the question of suffix, I think you should leave it alone because if you joined DATACRAFT domain, then you get the DATACRAFT suffix automatically. I would not manually created suffix search unless you are clear on the proper config.

Fix the fundamental stuff and Unity will follow right behind it.

H. M.

Hi H.M.

Thanks for your information. However, if both the suffix and account for running the SQL services are not the cause, what are the other possibilities that would cause the failure of the replication of the SQL database?

For your information, previously someone posted some solutions on solving the problem very similar to mine by changing the suffix. Do you think this solution can solve my problem? If so, what do I need to do in order to implement it? Do I just need to add the "DataCRAFT.com" to the suffix of the DNS?

*********************************

I recently (yesterday) ran into a *very* similar problem trying to enable failover for a customer. The FOW would complete "successfully", however no SQL replication would be setup on either box. After doing some digging and investigating an interesting SQL startup error, I found my problem, yours may well have been very similar.

Proper replication between two SQL servers depends on proper authentication. The two machines both were statically registered in my customer's DNS, including a suffix domain. I verified this by doing a "ping -a x.x.x.x". However, neither machine had it's primary domain suffix configured on the boxes themselves. This is caused a problem with creation of correct SPN's in their Active Directory, preventing Kerberos credential sharing.. This will cause a problem with the SQL authentication necessary to establish replication, which I'm assuming in turn breaks some of the things the failover wizard is supposed to enable. Long string of events, but there it is. Bottom line, the machine's domain suffix needed to match what is configured in DNS, and then I needed to rerun FOW. If you want more information about some of the root cause stuff, this is a fun read: http://support.microsoft.com/?id=811889

A good test that I intend to do from now on *before* I run the FOW is to run SQL Enterprise manager on the primary, and try to add the failover server's SQL instance via machine name only (no DNS suffix, and should be able to select it from the offered SPN list) and use "Windows credentials for authentication". Then do the reverse procedure from the secondary. If either of these fails, you have some sort of authentication problem that needs to be solved before running FOW.

I honestly think this check should be integrated into FOW or made part of the failover configuration procedure.

****************************

Thanks,

---

Raymond

Thank you for your post. I had EXACTLY the same issue. FOW would run fine, but SQL replication was not working. Configuring the DNS suffix search order to be correct so that the servers could be pinged from each other fixed the issue.

Thanks,

-Baron

World Wide Technology, Inc.