Moving SQL Server to different domain

What do you need to take into account when migrating SQL Server to another domain?

The steps below presume:

1. IP address will also change

2. SQL Server is NOT clustered
Steps:

A. Backup:

 BEFORE: backup the datases off-machine

B. Services:

 BEFORE: depending on the nature of the change/move, you may want to set service start to
Manual for all SQL Service
 AFTER: Once things or up and running properly, return service start to its original setting
C. SA account:

 BEFORE: If all administrator accounts are domain accounts or groups, temporarily enable the 'sa'
account with a strong password
 AFTER moving: once the domain-based accounts are setup in the new domain, 'sa' can be
disabled again
D. Service Windows account:

 BEFORE moving: for each SQL-Server-related Windows service, change the service to use a
LOCAL windows account or one of the built-in accounts
 AFTER moving: grant the necessary privileges to the service new domain accounts. When special
permissions are not needed, the SQL Service Configuration Manager can be used to change the
service account
E. Windows domain accounts used to login to SQL Server

 Re-create the needed accounts or use corresponding accounts in the new domain.
 BEFORE moving, script out permissions for OLD domain accounts, including SQL permissions,
Windows folder and file permissions, Windows permissions, etc.
 AFTER moving, apply these scripts to the corresponding NEW domain accounts so they will have
the same permissions
F. IP Address: SQL Server (unless clustered) will use the new IP address

 AFTER: Client applications that reference the service by IP address will need to be configured
with the new IP address.
G. Firewall:

 AFTER: OLD firewall openings that are no longer used will need to be closed, NEW firewall
openings may need to be created for SQL Server, OLAP services, SSRS between servers and
clients
H. DNS entries:

 AFTER: verify DNS has correctly updated

 AFTER: Clients and services that reference by DNS name, may need to be restarted AND/OR
their host systems may need their DNS cache flushed. For windows workstations, this can be
done with "ipconfig /flushdns"
I. Service Principle Names (SPNs). Some standalone (and all clustered) instances use SPNs.

 AFTER: The OLD SPN must be dropped and a NEW SPN must be created. Although it's not
recommended to use a SQL Server service account to manage (its own) SPNs, if this is the case,
the NEW domain service account will need to be granted WriteServicePrincipalName" privilege
J. Client Network Utility Alias.

 AFTER: Update any clients that use these will need to updated
K. Client application and service connection configuration:

 AFTER: Data Source Names (DSNs), connection strings, config files, Oracle TNS names for
connections - will need to be udpated and applications and services may need to be restarted
L. Internal machine name.

 AFTER: If the machine name is also changing, SQL Server's internal machine name entry may
need to be udpated

sp_dropserver 'MyOldMachineName' go sp_addserver 'MyNewMachineName','local' go

M. Merge Replication - If merge replication is in use, it will also need to be reconfigured.

 BEFORE: ensure all replicas are up-to-date

 AFTER: re-configure merge replation
Attributions - some information added from these sources:

https://serverfault.com/questions/49681/change-ad-domain-membership-of-a-server-2008-running-ms-
sql-08

http://social.msdn.microsoft.com/Forums/en-US/sqlsecurity/thread/f3e8ff83-8fcd-4335-87fe-
ea5641ae6b88

SQL Server Services

 Depending on the nature of the change/move, you may want to set service start to Manual for all SQL
Service.
 Once things or up and running properly, return service start to its original setting.

SA account

 If all administrator accounts are domain accounts or groups, temporarily enable the 'sa' account with a
strong password.
 Once the domain-based accounts are setup in the new domain, 'sa' can be disabled again.

Service Windows account

 For each SQL-Server-related Windows service, change the service to use a LOCAL windows account or one of
the built-in accounts.
 Grant the necessary privileges to the service new domain accounts. When special permissions are not
needed, the SQL Service Configuration Manager can be used to change the service account.

Firewall
  OLD firewall openings that are no longer used will need to be closed, NEW firewall openings may need to be
created for SQL Server, OLAP services, SSRS between servers and clients.

DNS entries

 Verify DNS has correctly updated.

 Clients and services that reference by DNS name may need to be restarted AND/OR their host systems may
need their DNS cache flushed. For windows workstations, this can be done with "ipconfig/flushdns"

Service Principle Names (SPNs). Some standalone (and all clustered) instances use SPNs. (Need to be
checked with windows team whether they will do it or not)

 The OLD SPN must be dropped and a NEW SPN must be created. Although it's not recommended to use a
SQL Server service account to manage (its own) SPNs, if this is the case, the NEW domain service account will
need to be granted Write Service Principal Name" privilege

Client application and service connection configuration

 Data Source Names (DSNs), connection strings, config files, Oracle TNS names for connections - will need to
be updated and applications and services may need to be restarted.

Internal machine name (Optional)

 If the machine name is also changing, SQL Server's internal machine name entry may need to be updated.

sp_dropserver <old_name>;

GO

sp_addserver <new_name>, local;

GO

Restart the SQL server after renaming it and use below query to find the new name of the server.
       Select @@SERVERNAME

Replication

If replication is in use, it will also need to be reconfigured.

 Ensure all replicas are up-to-date

 Re-configure merge replication

1. Stop all services of SQL server not to automatically start

2. Create new service accounts and update it for the SQL services using configuration Manager.
3. Create a Logins with new domain account: Take a backup of existing Logins which are created from Windows
and create a new one with new domain account.
4. Change the users with new Logins: Take backup of all the above Logins and update the login name and user
name and create new users.
5. Change memory location for the new User: Enable Lock Pages in Memory in Group Policy Editor:

  On the Start menu, click Run. In the Open box, type gpedit.msc
  On the Local Group Policy Editor console, expand Computer Configuration, and
then expand Windows Settings.
   Expand Security Settings, and then expand Local Policies.
  Select the User Rights Assignment folder.
  The policies will be displayed in the details pane.
  In the pane, double-click Lock pages in memory.
  In the Local Security Setting – Lock pages in memory dialog box, click Add User
or Group.
  In the Select Users, Service Accounts, or Groups dialog box, add an account with
privileges to run sqlservr.exe.
  Log out and then log back in for this change to take effect.
1)      And finally start the services.

2)      Owner of jobs with DOMINE_OLD \ USERS need to be changed to DOMINE_NEW \ USERS

SQL Server Integration Services

Update the service account for SQL Integration services using SQL Server Configuration Manager.

SQL Server Reporting Services

     To update the password, do the following:

  On the Start menu, point to Control Panel, point to Administrator Tools, and click
Services.
  Right-click SQL Server Reporting Services, select Properties.
  Click Log On, and type the new password.
  After you update the password, start the Reporting Services Configuration tool and
update the password in the Service Account page. This additional step is necessary to
update the account information that is stored internally by the report server.
  Need to change the Role assignments to new user accounts.