cross sub

Author: MashaMSFT

articles/sql-database/sql-database-active-geo-replication.md

@@ -119,6 +119,78 @@ If you decide to create the secondary with lower compute size, the log IO percen
 
 For more information on the SQL Database compute sizes, see [What are SQL Database Service Tiers](sql-database-purchase-models.md).
 
+## Cross-subscription geo-replication
+
+To setup active geo-replication between two databases belonging to different subscriptions (whether under the same tenant or not), you must follow the special procedure described in this section.  The procedure is based on SQL commands and requires: 
+
+- Creating a privileged login on both servers
+- Whitelisting the IP address of the client performing the change on both servers (such as the IP address of the host running SQL Server Management Studio). 
+
+The client performing the changes needs network access to the primary server. Although the same IP address of the client must be whitelisted on the secondary server, network connectivity to the secondary server is not strictly required. 
+
+### On the master of the primary server
+
+1. Whitelist the IP address of the client performing the changes (for more information see, [Configure firewall](sql-database-firewall-configure.md)). 
+1. Create a login dedicated to setup active geo-replication (and adjust the credentials as needed):
+
+   ```sql
+   create login geodrsetup with password = 'ComplexPassword01'
+   ```
+
+1. Create a corresponding user and assign it to the dbmanager role: 
+
+   ```sql
+   create user geodrsetup for login gedrsetup
+   alter role geodrsetup dbmanager add member geodrsetup
+   ```
+1. Take note of the SID of the new login using this query: 
+
+   ```sql
+   select sid from sys.sql_logins where name = 'geodrsetup'
+   ```
+
+### On the source database on the primary server
+
+1. Create a user for the same login:
+
+   ```sql
+   create user geodrsetup for login geodrsetup
+   ```
+
+1. Add the user to the db_owner role:
+
+   ```sql
+   alter role db_owner add member geodrsetup
+   ```
+
+### On the master of the secondary server 
+
+1. Whitelist the IP address of the client performing the changes. It must the same exact IP address of the primary server. 
+1. Create the same login as on the primary server, using the same username password, and SID: 
+
+   ```sql
+   create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E
+   ```
+
+1. Create a corresponding user and assign it to the dbmanager role:
+
+   ```sql
+   create user geodrsetup for login geodrsetup;
+   alter role dbmanager add member geodrsetup
+   ```
+
+### On the master of the primary server
+
+1. Login to the master of the primary server using  the new login. 
+1. Create a secondary replica of the source database on the secondary server (adjust database name and servername as needed):
+
+   ```sql
+   alter database dbrep add secondary on server <servername>
+   ```
+
+After the initial setup, the users, logins, and firewall rules created can be removed. 
+
+
 ## Keeping credentials and firewall rules in sync
 
 We recommend using [database-level IP firewall rules](sql-database-firewall-configure.md) for geo-replicated databases so these rules can be replicated with the database to ensure all secondary databases have the same IP firewall rules as the primary. This approach eliminates the need for customers to manually configure and maintain firewall rules on servers hosting both the primary and secondary databases. Similarly, using [contained database users](sql-database-manage-logins.md) for data access ensures both primary and secondary databases always have the same user credentials so during a failover, there is no disruptions due to mismatches with logins and passwords. With the addition of [Azure Active Directory](../active-directory/fundamentals/active-directory-whatis.md), customers can manage user access to both primary and secondary databases and eliminating the need for managing credentials in databases altogether.