Hey all, Before I file a bug (aka scream) I wanted to make sure other people were seeing this. Here's the scenario...client has a two EV server site (servers A, and B respectively). Both servers are online and functioning, with an SQL server hosting all db's. We'll call that SQL server A. A disaster occurs and the SQL server goes down and is never to be seen again. The two EV servers also went down, and rebooted. Upon reboot, they can not start the directory service (or others) since the SQL server is unavailable. So what I've noticed, and need confirmation on, is that if you try to start the directory service it will fail (which I sorta expected), and complain that it can't get to it's db's. In previous versions, you were able to start the VAC without pointing to a host by starting it up, cancelling out of the first association screen, and then hitting the "Change SQL server" button. I've noticed that this button does not appear...and just continues to prompt for the VAC to associate. So okay, i'm not dumb, so I figure "Screw the VAC" (i proudly said), and went to go manually change the odbc settings. I found the enterprisevaultdirectory system entry, changed the server name to point to the correct server\instance and port, and then tested it. All good. I try to start up the directory service,...and ta-da...no joy. I do a dtrace and see that it's still complaining about it's db missing. I go back to check my odbc settings...and yup, you guessed it, it changed. Long story short, I restarted the admin service and noticed that my changes are killed retroactively when I restart the admin server OR try to start the directory service. I also tried to find any new config file or something that's new in 7.0sp1 that's hidden somewhere in the EV program files directory, but I still couldn't find it. BTW, the only way I could actually fix this problem was to create a new sql server with the old name, mount the old db, connect the VAC...and then once I'm associated, hit the change sql server button. So in effect, this pretty much makes SQL server recovery to another named box, instance, or cluster broken. So can anybody else confirm this for me?
Micah, I will check my lab to see it that is the case, but wanted to ask have you ever thought of using DNS alias's for SQL? that way you don't need to go through all the updates and all you have to do is change the pointer.
Totally...and I always do. :) But we're doing a lot of 5.5 and 6.0 upgrades with clients who don't think as far ahead as we do. :) And yeah, I could see where the DNS alias would be a workaround in a simple environment, but in this case the instance name was different as well. Ug.
But anyhow, that button is really important and I hope it's still where it belongs and I'm just seeing an aberation.
Message was edited by: Micah WyennMessage was edited by: Micah Wyenn