Question

I’m planning the migration of some SQL Server 2008 R2 databases between two servers.

The proposal is to follow Method 3 in this article: http://support.microsoft.com/kb/918992 to transfer logins across after the databases have been migrated.

This mostly looks OK to me but one concern is if any of these logins already exist on the target server. If this is the case would anything additional need to be done and if so what?

[My understanding’s a little hazy here – is it possible that users in the restored database would still be orphaned since the logins they referenced have different SIDs on the new server?]

Answer 1

That script generates login scripts rather than executing the statements directly, so you can review them, and just run the scripts for users that don’t already exist on the target.

The script will generate new SIDs dependant on whether the new login needs a new one – it depends on the type of login.

From MSDN on the subject:

The source of the SID depends on how the login is created. If the
login is created from a Windows user or group, it is given the Windows
SID of the source principal; the Windows SID is unique within the
domain. If the SQL Server login is created from a certificate or
asymmetric key, it is assigned a SID derived from the SHA-1 hash of
the public key. If the login is created as a legacy-style SQL Server
login that requires a password, the server will generate a SID.

I don’t think you need to worry about that unless you’re using the sys.server_principals table for something special.

---

From the comments below, Steve wanted to create the logins by script, and detach and re-attach the databases on the new server. The concern was that these logins would now be orphaned – i.e. attached to a login on the original server with the same name as the one on the new server, but with a different SID.

Yes, this would be a problem. To sort this, you’d need to visit this MSDN article. To summarise:

To detect orphaned users, execute the following Transact-SQL statements:

USE <database_name>;
GO; 
sp_change_users_login @Action='Report';
GO;

The output lists the users and corresponding security identifiers (SID) in the current database that are not linked to any SQL Server login. For more information, see sp_change_users_login (Transact-SQL).

To resolve an orphaned user, use the following procedure:

The following command relinks the server login account specified by with the database user specified.

USE <database_name>;
GO
sp_change_users_login @Action='update_one', @UserNamePattern='<database_user>', 
   @LoginName='<login_name>';
GO

---

As Steve points out, sp_change_users_login is depreciated and the preferred alternative is to use ALTER USER:

ALTER USER <database_user>
WITH LOGIN <login_name>

MSDN link