Domain Name Change - SQL Server 2005 w/ SSRS and Mirroring. We are considering doing a Domain change, which, being a DBA, I am not familiar with in terms of how this will affect our SQL installation


We are getting two new domain servers, and along with this change, our network admin is considering changing the domain name and the groups of the SQL users currently loggin in with Domain accounts.  I am very concerned about this since the information I have been finding seems to differ from something as simple as "Just need to change the service accounts and logins" to "May need to resinstall SQL".   I looked through some articles here but could not find a solid resource which shows the steps necessary in order to succesfully carry out a domain name change which considers SQL Server 2005, Mirroring, and SSRS (SSIS?).  If anyone can point me in the right direction I would appreciate it.  It seems that if not done correclty,  this can have unintended, far-reaching implications to the SQL Server environments.  There are probably resources already out there that explain this but I have not found a "good" one yet.  Any help or advice would be greatly appreciated.  Details are SQL 2005 SP2 GDR1, Windows Server 2003, Mirroring, SSRS, SSIS.   Thank you,  Keith
Who is Participating?
From what I can read into your question and what I know; the issue with SQL is if you change the name of the server; not the domain; but that's an easy fix anyway.

I'm thinking that it would be a case of change the domain the server joins to in CompMgmt, reboot, fire up SQL and add the previous domain's users; but depending how quickly the migration is done; you may need to setup trusts between the two domains to allow users on the old domain access to your SQL Server...

Do you have a virtual environment you could play about with and hone the migration plan?
ecshadminAuthor Commented:

We are going to test it out first on one of our development servers.  The problem is, we do not have a test environment that exactly parallels our production environment, so even if things go well in test, I'm concerned there may be other issues we will encounter when moving to production.  Maybe that is where we should focus first, trying to get dev to match production, although this is a large effort in our case.  I have found some other resources also, but still nothing solid.  I'll keep this post open for a while and see if any others respond.  I'll post more informatoin when we start making the changes in development and see the results.

Jim P.Commented:
The one thing I would definitely look at is to script out your SQL Users at the the server level (sp_help_revlogin in the first link below) and then use the DB Pub Wizard to script the database logins.

Filter domain accounts at both levels and then drop and recreate them.

How to transfer the logins and the passwords between instances of SQL Server 2005

Microsoft SQL Server Database Publishing Wizard 1.1
ecshadminAuthor Commented:
Thank you, I've started looking into your suggestion.  Is DB Publishing wizard somehow different from the 'Generate Scripts" task?   The information you provided is much appreciated...
Jim P.Commented:
The generate scripts is more for one database. The pub wizard should be able to do it for all databases at the same time. Plus ownership rights and roles, etc.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.