Edit review

Author: v-phoebh

support/sql/database-engine/security/transfer-logins-passwords-between-instances.md

@@ -1,7 +1,7 @@
 ---
 title: Transfer logins and passwords between instances
 description: This article describes how to transfer the logins and the passwords between different instances of SQL Server running on Windows.
-ms.date: 01/15/2025
+ms.date: 01/17/2025
 ms.custom: sap:Security, Encryption, Auditing, Authorization
 ms.reviewer: jopilov
 ms.author: bartd
@@ -17,39 +17,39 @@ _Original KB number:_   918992, 246133
 
 ## Introduction
 
-This article describes how to transfer the logins and passwords between different instances of Microsoft SQL Server. The instances might be on the same server or on different servers, and their versions might differ.
+This article describes how to transfer the logins and passwords between different instances of Microsoft SQL Server. The instances might be on the same server or different servers, and their versions might differ.
 
-## Why transfer logins between SQL Servers?
+## Why transfer logins between SQL Server instances?
 
 In this article, server A and server B are servers.
 
 After you move a database from a SQL Server instance on server A to a SQL Server instance on server B, users might be unable to log in to the database server on server B. Additionally, users might receive the following error message:
 
 > Login failed for user '**MyUser**'. (Microsoft SQL Server, Error: 18456)
 
-This problem occurs because the logins from SQL Server instance on server A don't exist in the SQL Server instance on server B.
+This problem occurs because the logins from the SQL Server instance on server A don't exist in the SQL Server instance on server B.
 
 Keep in mind that error 18456 occurs for many other reasons. For more information on these causes and their resolutions, see [MSSQLSERVER_18456](/sql/relational-databases/errors-events/mssqlserver-18456-database-engine-error).
 
 ## Steps to transfer the logins
 
 To transfer the logins, use one of the following methods, as appropriate for your situation.
 
-### Method 1: Generate scripts via SSMS on source server and manually reset passwords for SQL Server logins on destination server
+### Method 1: Generate scripts via SSMS on the source server and manually reset passwords for SQL Server logins on the destination server
 
 You can generate login scripts in SQL Server Management Studio (SSMS) by using the [Generate Scripts option for a database](/sql/ssms/tutorials/scripting-ssms#script-a-database-by-using-the-generate-scripts-option). 
 
-To generate scripts via SSMS on source server and manually reset passwords for SQL Server logins on destination server, follow these steps:
+To generate scripts via SSMS on the source server and manually reset passwords for SQL Server logins on the destination server, follow these steps:
 
 1. Connect to server A that's hosting the source SQL Server.
 1. Expand the **Databases** node.
-1. Right-click on any user database and select **Tasks** > **Generate Scripts**.
-1. The **Introduction** page opens. Select **Next** to open the **Chose Objects** page. Select **Script entire database and all database objects**.
+1. Right-click any user database and select **Tasks** > **Generate Scripts**.
+1. The **Introduction** page opens. Select **Next** to open the **Choose Objects** page. Select **Script entire database and all database objects**.
 1. Select **Next** to open the **Set Scripting Options** page. 
 1. Select the **Advanced** button for Script Login options.
 1. In the **Advanced** list, find **Script Logins**, set the option to **True** and select **OK**.
 1. Back to **Set Scripting Options** under **Select how scripts should be saved** and select **Open in new query window**. 
-1. Select **Next** twice, then select **Finish**.
+1. Select **Next** twice, and then select **Finish**.
 1. Find the section in the script that contains logins. Typically, the generated script contains text with the following comment at the beginning of this section:
 
    `/* For security reasons the login is created disabled and with a random password. */`
@@ -60,7 +60,7 @@ To generate scripts via SSMS on source server and manually reset passwords for S
 1. Apply the login script from the larger generated script to the destination SQL Server.
 1. For any SQL Server Authentication logins, reset the password on the destination SQL Server and re-enable those logins.
 
-### Method 2: Transfer logins and passwords to destination server (Server B) using scripts generated on source server (Server A)
+### Method 2: Transfer logins and passwords to the destination server (Server B) using scripts generated on the source server (Server A)
 
 1. Create stored procedures that will help generate necessary scripts to transfer logins and their passwords. To do so, connect to Server A using SQL Server Management Studio (SSMS) or any other client tool and run the following script:
 
@@ -302,25 +302,25 @@ Review the following information before you run the output script on the instanc
 
   - `VERSION_SHA1`: This hash is generated by using the SHA1 algorithm and is used in SQL Server 2000 through SQL Server 2008 R2.
   - `VERSION_SHA2`: This hash is generated by using the SHA2 512 algorithm and is used in SQL Server 2012 and later versions.
-- In the output script, the logins are created by using the encrypted password. This is because of the HASHED argument in the `CREATE LOGIN` statement. This argument specifies that the password that is entered after the PASSWORD argument is already hashed.
+- In the output script, the logins are created by using the encrypted password. This is because of the `HASHED` argument in the `CREATE LOGIN` statement. This argument specifies that the password that is entered after the `PASSWORD` argument is already hashed.
 
-### How to handle change of domains
+### How to handle the change of domains
 
 Are your source and destination servers in different domains? Review the output script carefully. If server A and server B are in different domains, you have to change the output script. Then, you have to replace the original domain name by using the new domain name in the `CREATE LOGIN` statements. The integrated logins that are granted access in the new domain don't have the same SID as the logins in the original domain. Therefore, users are orphaned from these logins. For more information about how to resolve these orphaned users, see [Troubleshoot orphaned users (SQL Server)](/sql/sql-server/failover-clusters/troubleshoot-orphaned-users-sql-server) and [ALTER USER](/sql/t-sql/statements/alter-user-transact-sql).  
 
 If server A and server B are in the same domain, the same SID is used. Therefore, users are unlikely to be orphaned.
 
-### Permissions to view and select all login
+### Permissions to view and select all logins
 
 By default, only a member of the sysadmin fixed server role can run a `SELECT` statement from the `sys.server_principals` view. Unless a member of the sysadmin fixed server role grants the necessary permissions to the users, the users can't create or run the output script.
 
 ### Default database setting isn't scripted and transferred
 
 The steps in this article don't transfer the default database information for a particular login. This is because the default database might not always exist on server B. To define the default database for a login, use the `ALTER LOGIN` statement by passing in the login name and the default database as arguments.
 
-### How to deal with different sort orders between source and destination SQL Server
+### How to deal with different sort orders between the source and destination servers
 
-There could be differences in sort orders between the source and destination servers or they could be the same. Here's how each scenario can be addressed:
+There might differences in sort orders between the source and destination servers, or they might the same. Here's how each scenario can be addressed:
 
 - **Case-insensitive server A and case-sensitive server B**: The sort order of server A might be case-insensitive, and the sort order of server B might be case-sensitive. In this case, users must type the passwords in all uppercase letters after you transfer the logins and the passwords to the instance on server B.
 - **Case-sensitive server A and case-insensitive server B:** The sort order of server A might be case-sensitive, and the sort order of server B might be case-insensitive. In this case, users can't log in by using the logins and the passwords that you transfer to the instance on server B unless one of the following conditions is true:
@@ -332,7 +332,7 @@ There could be differences in sort orders between the source and destination ser
 
 ### How to deal with logins already existing on the destination server
 
-The script is designed to check if the login exists on the destination server. It creates a login only if it doesn't exist on the destination server. However, if you receive the following error message when you run the output script on the instance on server B, you have to manually resolve it by following the steps in this section.
+The script is designed to check if the login exists on the destination server and create a login only if it doesn't. However, if you receive the following error message when you run the output script on the instance on server B, you have to manually resolve it by following the steps in this section.
 
 > Msg 15025, Level 16, State 1, Line 1  
 > The server principal '**MyLogin**' already exists.
@@ -350,7 +350,7 @@ To manually resolve the issue, follow these steps:
 
 Starting in SQL Server 2005, the SID for a login is used to manage database-level access. Occasionally, a login might have different SIDs when mapped to users in different databases. This issue can occur if databases are manually combined from different servers. In such cases, the login can only access the database where the database principal's SID matches the SID in the `sys.server_principals` view. To resolve this issue, manually remove the database user with the mismatched SID using the [DROP USER](/sql/t-sql/statements/drop-user-transact-sql) statement. Then, add the user again with the `CREATE USER` statement and map it to the correct login (server principal).
 
-For more information and to distinguish server from database principals, see [CREATE USER](/sql/t-sql/statements/create-user-transact-sql) and [CREATE LOGIN.](/sql/t-sql/statements/create-login-transact-sql).
+For more information and to distinguish servers from database principals, see [CREATE USER](/sql/t-sql/statements/create-user-transact-sql) and [CREATE LOGIN](/sql/t-sql/statements/create-login-transact-sql).
 
 ## References