I am working with a vendor that claims that you should not change an SQL servers domain.
The information they sent me is all over the place and not a direct link to this being an issue.
As stated earlier, I have an NT 4 domain running SQL servers using NT 4 Authentication and SQL authentication depending on the database server. I want to create an brand new domain running windows 2003 and create a trust relationship between the two domains. I then would like to migrate all the users and users computers (Using ADMT) into the new domain and allow users to continue accessing the resources in the old domain using SIDhistory. Then finally migrate the SQL servers into the new domain by removing them from the old domain and add them to the new domain. Finally clean up the SIDHistory and redo the permissions.
###########################################################
Here is the info I recieved from them.
We received a number of links and some input from Microsoft related to this issue. Migrating a server from one domain to another is possible but not recommended as there are a number of things that could go wrong, especially permission issues. There are a number of scripts that need to be created and a number of applications that need to be run in order to complete the entire migration process.
· “If you want to migrate the SQL Servers from one domain to another and you do not use a new server on the new domain. You could take the server out of the old domain and then join it to the new domain. However, please note that you shall add domain users of the new domain to the SQL logins after migration even if you have used ADMT to migrate users. This is because that SID history does not apply to SQL logins. If old domain has trust relationship with the new domain, the old domain users could still access the SQL Servers if the users exist. Also, you need create new database users to map to the new SQL logins for new domain users. If you want to use a new machine on the new domain and migrate databases from old domain to new domain. You may use backup/restore or detach/attach method to move user databases. You shall also migrate logins/passwords between new domain:
1) Script logins from old domain SQL by using "Q246133 HOW TO: Transfer Logins and Passwords between Instances of SQL Server”
2) Generate Permission script
3) Modify script to use new domain name (script result from Q246133)
4) Remove the old logins; Detach all the user DB
5) Run script on SQL Server to create the logins so that you will have new domain\users.
6) Use sp_Sidmap procedure to change domain name in sysusers to the one in sysxlogins per "Q240872
Note: These steps also apply to move server directly to new server situation if you do not want to keep the old domain users as SQL logins.”
· “It’s never "recommended" that you change a cluster’s domain, given the complexities involved” This is also true for a stand-alone SQL server.
“a wide variety of tools are used to perform the actual domain-level change (including security considerations, account migrations, sid mappings, and so forth). Often that’s the toughest part of the process, not the actual change itself” à
· “When you first install Microsoft SQL Server to run under a Microsoft Windows NT account, SQL Server sets for that Windows NT account various Windows user rights and permissions on certain files, folders, and registry keys” à
All the permissions on the files/folders and registry keys will have to be manually updated if a migration is to be done. Modifications to registry permissions can be a very time consuming, not to mention very sensitive task!
Here are a couple of articles forwarded by Microsoft as well.
314546 HOW TO: Move Databases Between Computers That Are Running SQL Server
240872 HOW TO: Resolve Permission Issues When You Move a Database Between
HOW TO: Transfer Logins and Passwords Between Instances of SQL Server
224071 INF: Moving SQL Server Databases to a New Location with Detach/Attach
###########################################################
The information they sent me is all over the place and not a direct link to this being an issue.
As stated earlier, I have an NT 4 domain running SQL servers using NT 4 Authentication and SQL authentication depending on the database server. I want to create an brand new domain running windows 2003 and create a trust relationship between the two domains. I then would like to migrate all the users and users computers (Using ADMT) into the new domain and allow users to continue accessing the resources in the old domain using SIDhistory. Then finally migrate the SQL servers into the new domain by removing them from the old domain and add them to the new domain. Finally clean up the SIDHistory and redo the permissions.
###########################################################
Here is the info I recieved from them.
We received a number of links and some input from Microsoft related to this issue. Migrating a server from one domain to another is possible but not recommended as there are a number of things that could go wrong, especially permission issues. There are a number of scripts that need to be created and a number of applications that need to be run in order to complete the entire migration process.
· “If you want to migrate the SQL Servers from one domain to another and you do not use a new server on the new domain. You could take the server out of the old domain and then join it to the new domain. However, please note that you shall add domain users of the new domain to the SQL logins after migration even if you have used ADMT to migrate users. This is because that SID history does not apply to SQL logins. If old domain has trust relationship with the new domain, the old domain users could still access the SQL Servers if the users exist. Also, you need create new database users to map to the new SQL logins for new domain users. If you want to use a new machine on the new domain and migrate databases from old domain to new domain. You may use backup/restore or detach/attach method to move user databases. You shall also migrate logins/passwords between new domain:
1) Script logins from old domain SQL by using "Q246133 HOW TO: Transfer Logins and Passwords between Instances of SQL Server”
2) Generate Permission script
3) Modify script to use new domain name (script result from Q246133)
4) Remove the old logins; Detach all the user DB
5) Run script on SQL Server to create the logins so that you will have new domain\users.
6) Use sp_Sidmap procedure to change domain name in sysusers to the one in sysxlogins per "Q240872
Note: These steps also apply to move server directly to new server situation if you do not want to keep the old domain users as SQL logins.”
· “It’s never "recommended" that you change a cluster’s domain, given the complexities involved” This is also true for a stand-alone SQL server.
“a wide variety of tools are used to perform the actual domain-level change (including security considerations, account migrations, sid mappings, and so forth). Often that’s the toughest part of the process, not the actual change itself” à
· “When you first install Microsoft SQL Server to run under a Microsoft Windows NT account, SQL Server sets for that Windows NT account various Windows user rights and permissions on certain files, folders, and registry keys” à
All the permissions on the files/folders and registry keys will have to be manually updated if a migration is to be done. Modifications to registry permissions can be a very time consuming, not to mention very sensitive task!
Here are a couple of articles forwarded by Microsoft as well.
314546 HOW TO: Move Databases Between Computers That Are Running SQL Server
240872 HOW TO: Resolve Permission Issues When You Move a Database Between
HOW TO: Transfer Logins and Passwords Between Instances of SQL Server
224071 INF: Moving SQL Server Databases to a New Location with Detach/Attach
###########################################################
