March 25, 2024 at 9:54 am
Hi all. First post. I've got to migrate 187 databases from one domain to an availability group on another domain. I've read that I need to script out the logins but there seems to be a problem where-by it isn't so straight forward when moving them to a new domain. This article says that the new Domain must be specified in the CREATE LOGIN output script but I'm not sure where it goes.
Transfer logins and passwords between instances - SQL Server | Microsoft Learn
New to this, so any help is much appreciated.
March 25, 2024 at 10:20 am
Is there going to be a trust between the two domains? Or are you going to be destroying the old domain upon migration?
If there is no trust, then are all the names of the accounts going to be the same (with the exception of the domain of course)?
So OldDomain\DBAGroup will be NewDomain\DBAGroup or will you have a different mapping structure?
The link you referenced is only good if you are keeping the original domain / migrating within the domain, or having a trust between domains.
If it's all going to be all in a new domain with all new groups and account and all different SIDs then you'll need to get creative looking at DMV's and a lot of other things.
March 25, 2024 at 10:31 am
We'll be taking the old server offline once we migrate to the new servers. We have an availability group set up on the new cluster. So the DBs will be running exclusively on those. I'd like to keep the logins the same if possible and everything else that needs migrating also.
March 25, 2024 at 10:36 am
That doesn't answer the question.
What is happening to the old domain once you have migrated?
Not your old SQL AG cluster setup, the WHOLE domain?
Maybe you're domain sysadmins may shine more light here on that.
If that old domain is staying, then ask them will there be a trust between old domain and new domain.
If that old domain is being switched off or they will not put a trust in place, then you have a lot of work on your hands, as the domain people will need to recreate all your accounts in the new domain, and you'll need to look through and script the logins/users/permissions out from old, manipulate the scripts to make them work as new domain logins, and then recreate them.
You need to fully understand what is happening as a WHOLE to the old domain, and not just the SQL servers as you are reliant on AD which may or may not be undergoing migration and decommission also.
March 25, 2024 at 10:41 am
We're going to kill the old domain.
March 25, 2024 at 10:52 am
OK, then you cannot use that script to do what you need to do. Reason is all the SIDs will be different in the new domain, you're going to end up with orphaned AD accounts as the old domain SID is not the new domain SID, so you're going to have to start from scratch again with your user accounts.
What you are going to have to do, to make things a little easier for you is get a copy of DBATools and then you will want to use Get-DbaLogin with Get-DbaDbUser and Get-DbaPermission / Get-DbaUserPermission, this will allow you to script out the logins to SQL files.
Then you will need to perform a find and replace e.g. find OldDomain\DBAGroup and replace it with NewDomain\DbaGroup.
Rinse and repeat this until you have mapped all the OldDomain accounts to NewDomain accounts, then you will need to run that each time you restore the databases from Old to New as it will not carry to new permissions on a restore as it will be as it just came from Old.
March 25, 2024 at 1:00 pm
Many thanks for the advice. I'll look into DBATools.
March 25, 2024 at 5:16 pm
Many thanks for the advice. I'll look into DBATools.
You need to generate the scripts to create the logins, and do a find and replace of the old domain and the new domain.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply