sp_help_revlogin is now old enough to drive a car
By now in your career, you may have needed to migrate a few databases and logins. The process isn’t as bad as it could be, after all Microsoft published sp_help_revlogin over 15 years ago to help migrate logins with their passwords and SIDS. Unfortunately, there has been no notable progress since this stored procedure was first released.
Why is this an issue? Well, by using sp_help_revlogin, you are required to do the following, as demonstrated in the painfully boring 41 second video below:
- Find the stored procedure somewhere on your hard drive/the Internet
- Install sp_help_revlogin and sp_hexadecimal on the source server
- Execute it on the source server
- Copy the resulting SQL output
- Paste it into the query pane of the resulting server
Now you’ve migrated the logins with their passwords, SIDs, and a few default properties. But you don’t have the logins’ server roles, server permission sets, database roles or database permission sets. So now you gotta find and use someone’s modified version of sp_help_revlogin, but you’re still left with manually executing the procedure against your source and destination servers.
Oh, and don’t forget different versions of SQL Server use different hashing algorithms, so you’ll need to use one of the many different versions of sp_help_revlogin if you have a mixed environment.
Let’s hope you only have one or two SQL Servers to migrate and not hundreds.
Introducing Copy-SqlLogin and Export-SqlLogin
Copy-SqlLogin and Export-SqlLogin are the PowerShell answers to performing SQL Server login migrations. These commands are not part of Microsoft’ official SQL Server module, SQLPS, but they do help illustrate how PowerShell can make our lives easier.
Want to export all of your logins to a file, complete with SID, hashed password, roles, permission sets, securables and all that? Just install the dbatools module then execute
Export-SqlLogin -SqlServer sql2005 -FileName C:\temp\sql2005-logins.sql
By default, Export-SqlLogin exports all logins, but you can also choose which logins you want to include or which you want to exclude by using auto-populated parameters.
Want to see sample output? Here’s sql2005-logins.sql on Gist.
Or what if you want to do a live login migration from SQL Server 2000 to SQL Server 2016? I’ve done it a ton of times (in a lab of course. SQL2k doesn’t exist in my prod ;).
Copy-SqlLogin -Source sqlsvr2000 -Destination newsql2016
Copy-SqlLogin works on SQL Server version 2000-2016. It takes care of the hashing algorithm differences. It works on clusters, named instances, all editions from Express to Enterprise and it copies both Windows and SQL Logins. It copies the default database, default language, password policy settings, securables, permissions sets (server & db), and roles (server & db). And it does so in just a few seconds.
If you’d like a walk-through, check out the video below where I go a bit more into depth about Copy-SqlLogin, create a login, migrate the login, then log into SQL Server as the newly migrated account.
Need to sync your login permissions for your availability groups? Sync-SqlLoginPermissions was created by request, just for that. Unlike Copy-SqlLogin, Sync-SqlLoginPermissions doesn’t add new logins. It just syncs the server & db permission sets, as well as the server & db roles and job ownership.
Sync-SqlLoginPermissions -Source sql2005 -Destination sql2016
Need to copy jobs for you availability groups, too? Copy-SqlJob has you covered.
In 2016, DBAs will begin to fully adopt PowerShell
The year 2016 is an especially exciting time for the SQL and PowerShell community.
It’s no secret that prior to SQL Server 2016, the SQL Server team didn’t invest much in PowerShell. SQLPS was slow, rude, and didn’t conform to standard PowerShell practices. The SQL Server community was given a module with less than 50 commands, which left us needing to create solutions of our own. Meanwhile the Lync, Exchange and SharePoint communities were bestowed with over 700 commands each.
But all of that has changed changed. Microsoft now has a dedicated SQL PowerShell engineer and the SQL Server Tools team is actively asking for community feedback. They’ve even promised new cmdlets each month! Just check out the exciting things going on with the soon-to-be-released cmdlet, Get-SqlErrorLog.
If you’ve been a fan of PowerShell, I hope the SQL Server team’s recent dedication to PowerShell renews your excitement. If you’re a PowerShell holdout, I understand. I adopted PowerShell for SharePoint long before I did PowerShell for SQL Server. I thought it was slow (have you seen the performance of Start PowerShell in SSMS prior to 2016?!) and hard to learn.
But now I see its power and it will only get more awesome now that PowerShell has a dedicated resource within the SQL Server team.
Thanks for joining me for this month’s T-SQL Tuesday!