By the way, I was researching this task and here are some links (one for now)
The issue that I got is the step ‘I’ of moving-sql-server-to-different-domain
Reading carefully I see what I need to do… but I need to test it and research how to drop/change the Service Principle Names (SPNs).
What are best practices/important steps when the Windows Server machine hosting SQL Server 2008 R2 is moved to another domain? What steps definitely/might need to be done for SQL Server before and after the new domain is joined?
What do you need to take into account when migrating SQL Server to another domain?
The steps below presume:
IP address will also change
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.
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:
Change AD domain membership of a Server 2008 running MS SQL 08 - Server Fault
Microsoft supported products on Q&A | Microsoft Learn
More info: How to grant "Write ServicePrincipalName” and “Write validated SPN” rights to the directory for service account
How can I grant "Write ServicePrincipalName” and “Write validated SPN” rights to the directory for service account or computers?
Computers can already write thier own SPNs, you can use the following DSACLs snippet to grant a service account the right to write it’s own SPNs.
dsacls <DomainName_of_Service_Account> /G SELF:RPWP;"servicePrincipalName"
Right-Click on the OU and select Properties
Select the “Security” tab
Select the “Advanced” tab
Select the “Add” button
Enter the security principal name
security principal
Ok
Properties tab
Apply to:
Descendant User objects
Permissions:
Read servicePrincipalName - Allow
Write servicePrincipalName - Allow
Ok
Ok
Ok
I’m applying exactly what you describes in the above solution. I’m working on an Windows 2012 R2 with an AD and Forest Mode in Windows 2012. I’m logged on as Enterprise Admin. However, none of both, read or write serviceprincipalname are listed on the attribute sets?
I tried to add the SELF account, add the rights to a domain local group. I tried on the OU level and on the service account itself.
In my experience, you need to set:
Apply to: Descendant Computer objects
May be it would be useful for somebody. Read/write serviceprincipalnape are shown only for computers account using dsa.msc console. To set these acls for user account you need to use adsiedit.msc .
Use ADSIEdit.msc, you will find ServicePrincipalName for all descendant user
More to read:
https://everygreen4u.blogspot.com/2012/08/how-to-use-adsi-edit-adsieditmsc.html
or here How-to-Use-ADSI-Edit-adsieditmsc-05-10.
.
you got me there… I want to put 3 steps but … you see, that I hurry myself… let me fix it.
