20221216 bulk formatting fixes for database names

Author: WilliamDAssafMSFT

azure-sql/database/active-geo-replication-overview.md

@@ -167,7 +167,7 @@ To create a geo-secondary in a subscription different from the subscription of t
    alter role db_owner add member geodrsetup;
    ```
 
-7. In the master database on the **secondary** server, create the same login as on the primary server, using the same name, password, and SID. Replace the hexadecimal SID value in the sample command below with the one obtained in Step 4.
+7. In the `master` database on the **secondary** server, create the same login as on the primary server, using the same name, password, and SID. Replace the hexadecimal SID value in the sample command below with the one obtained in Step 4.
 
    ```sql
    create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
@@ -180,7 +180,7 @@ To create a geo-secondary in a subscription different from the subscription of t
    alter role dbmanager add member geodrsetup;
    ```
 
-9. Connect to the master database on the **primary** server using the new `geodrsetup` login, and initiate geo-secondary creation on the secondary server. Adjust database name and secondary server name as needed. Once the command is executed, you can monitor geo-secondary creation by querying the [sys.dm_geo_replication_link_status](/sql/relational-databases/system-dynamic-management-views/sys-dm-geo-replication-link-status-azure-sql-database) view in the **primary** database, and the [sys.dm_operation_status](/sql/relational-databases/system-dynamic-management-views/sys-dm-operation-status-azure-sql-database) view in the master database on the **primary** server. The time needed to create a geo-secondary depends on the primary database size.
+9. Connect to the `master` database on the **primary** server using the new `geodrsetup` login, and initiate geo-secondary creation on the secondary server. Adjust database name and secondary server name as needed. Once the command is executed, you can monitor geo-secondary creation by querying the [sys.dm_geo_replication_link_status](/sql/relational-databases/system-dynamic-management-views/sys-dm-geo-replication-link-status-azure-sql-database) view in the **primary** database, and the [sys.dm_operation_status](/sql/relational-databases/system-dynamic-management-views/sys-dm-operation-status-azure-sql-database) view in the `master` database on the **primary** server. The time needed to create a geo-secondary depends on the primary database size.
 
    ```sql
    alter database [dbrep] add secondary on server [servername];

azure-sql/database/active-geo-replication-security-configure.md

@@ -17,20 +17,20 @@ This article describes the authentication requirements to configure and control
 
 ## Disaster recovery with contained users
 
-Unlike traditional users, which must be mapped to logins in the master database, a contained user is managed completely by the database itself. This has two benefits. In the disaster recovery scenario, the users can continue to connect to the new primary database or the database recovered using geo-restore without any additional configuration, because the database manages the users. There are also potential scalability and performance benefits from this configuration from a login perspective. For more information, see [Contained Database Users - Making Your Database Portable](/sql/relational-databases/security/contained-database-users-making-your-database-portable).
+Unlike traditional users, which must be mapped to logins in the `master` database, a contained user is managed completely by the database itself. This has two benefits. In the disaster recovery scenario, the users can continue to connect to the new primary database or the database recovered using geo-restore without any additional configuration, because the database manages the users. There are also potential scalability and performance benefits from this configuration from a login perspective. For more information, see [Contained Database Users - Making Your Database Portable](/sql/relational-databases/security/contained-database-users-making-your-database-portable).
 
-The main trade-off is that managing the disaster recovery process at scale is more challenging. When you have multiple databases that use the same login, maintaining the credentials using contained users in multiple databases may negate the benefits of contained users. For example, the password rotation policy requires that changes be made consistently in multiple databases rather than changing the password for the login once in the master database. For this reason, if you have multiple databases that use the same user name and password, using contained users is not recommended.
+The main trade-off is that managing the disaster recovery process at scale is more challenging. When you have multiple databases that use the same login, maintaining the credentials using contained users in multiple databases may negate the benefits of contained users. For example, the password rotation policy requires that changes be made consistently in multiple databases rather than changing the password for the login once in the `master` database. For this reason, if you have multiple databases that use the same user name and password, using contained users is not recommended.
 
 ## How to configure logins and users
 
-If you are using logins and users (rather than contained users), you must take extra steps to ensure that the same logins exist in the master database. The following sections outline the steps involved and additional considerations.
+If you are using logins and users (rather than contained users), you must take extra steps to ensure that the same logins exist in the `master` database. The following sections outline the steps involved and additional considerations.
 
   >[!NOTE]
   > It is also possible to use Azure Active Directory (AAD) logins to manage your databases. For more information, see [Azure SQL logins and users](./logins-create-manage.md).
 
 ### Set up user access to a secondary or recovered database
 
-In order for the secondary database to be usable as a read-only secondary database, and to ensure proper access to the new primary database or the database recovered using geo-restore, the master database of the target server must have the appropriate security configuration in place before the recovery.
+In order for the secondary database to be usable as a read-only secondary database, and to ensure proper access to the new primary database or the database recovered using geo-restore, the `master` database of the target server must have the appropriate security configuration in place before the recovery.
 
 The specific permissions for each step are described later in this topic.
 
@@ -43,7 +43,7 @@ Setting up logins on the target server involves three steps outlined below:
 
 #### 1. Determine logins with access to the primary database
 
-The first step of the process is to determine which logins must be duplicated on the target server. This is accomplished with a pair of SELECT statements, one in the logical master database on the source server and one in the primary database itself.
+The first step of the process is to determine which logins must be duplicated on the target server. This is accomplished with a pair of SELECT statements, one in the logical `master` database on the source server and one in the primary database itself.
 
 Only the server admin or a member of the **LoginManager** server role can determine the logins on the source server with the following SELECT statement.
 

azure-sql/database/always-encrypted-enclaves-getting-started.md

@@ -361,7 +361,7 @@ In this step, you'll encrypt the data stored in the **SSN** and **Salary** colum
 1. Open a new SSMS instance and connect to your database **with** Always Encrypted enabled for the database connection.
     1. Start a new instance of SSMS.
     2. In the **Connect to Server** dialog, specify the fully qualified name of your server (for example, *myserver135.database.windows.net*), and enter the administrator user name and the password you specified when you created the server.
-    3. Select **Options >>** and select the **Connection Properties** tab. Make sure to select the **ContosoHR** database (not the default, master database). 
+    3. Select **Options >>** and select the **Connection Properties** tab. Make sure to select the **ContosoHR** database (not the default, `master` database). 
     4. Select the **Always Encrypted** tab.
     5. Select the **Enable Always Encrypted (column encryption)** checkbox.
     6. Select **Enable secure enclaves**. (This step applies to SSMS 19 or later.)

azure-sql/database/authentication-aad-configure.md

@@ -65,7 +65,7 @@ For more information, see:
 
 ## Azure AD admin with a server in SQL Database
 
-Each [server](logical-servers.md) in Azure (which hosts SQL Database or Azure Synapse) starts with a single server administrator account that is the administrator of the entire server. Create a second administrator account as an Azure AD account. This principal is created as a contained database user in the master database of the server. Administrator accounts are members of the **db_owner** role in every user database, and enter each user database as the **dbo** user. For more information about administrator accounts, see [Managing Databases and Logins](logins-create-manage.md).
+Each [server](logical-servers.md) in Azure (which hosts SQL Database or Azure Synapse) starts with a single server administrator account that is the administrator of the entire server. Create a second administrator account as an Azure AD account. This principal is created as a contained database user in the `master` database of the server. Administrator accounts are members of the **db_owner** role in every user database, and enter each user database as the **dbo** user. For more information about administrator accounts, see [Managing Databases and Logins](logins-create-manage.md).
 
 When using Azure Active Directory with geo-replication, the Azure Active Directory administrator must be configured for both the primary and the secondary servers. If a server does not have an Azure Active Directory administrator, then Azure Active Directory logins and users receive a `Cannot connect` to server error.
 
@@ -274,7 +274,7 @@ The following two procedures show you how to provision an Azure Active Directory
 The process of changing the administrator may take several minutes. Then the new administrator appears in the **Active Directory admin** box.
 
    > [!NOTE]
-   > When setting up the Azure AD admin, the new admin name (user or group) cannot already be present in the virtual master database as a server authentication user. If present, the Azure AD admin setup will fail; rolling back its creation and indicating that such an admin (name) already exists. Since such a server authentication user is not part of the Azure AD, any effort to connect to the server using Azure AD authentication fails.
+   > When setting up the Azure AD admin, the new admin name (user or group) cannot already be present in the virtual `master` database as a server authentication user. If present, the Azure AD admin setup will fail; rolling back its creation and indicating that such an admin (name) already exists. Since such a server authentication user is not part of the Azure AD, any effort to connect to the server using Azure AD authentication fails.
 
 To later remove an Admin, at the top of the **Active Directory admin** page, select **Remove admin**, and then select **Save**.
 
@@ -374,7 +374,7 @@ You can meet these requirements by:
 
 Because SQL Managed Instance supports Azure AD server principals (logins), using contained database users is not required. Azure AD server principals (logins) enable you to create logins from Azure AD users, groups, or applications. This means that you can authenticate with your SQL Managed Instance by using the Azure AD server login rather than a contained database user. For more information, see [SQL Managed Instance overview](../managed-instance/sql-managed-instance-paas-overview.md#azure-active-directory-integration). For syntax on creating Azure AD server principals (logins), see [CREATE LOGIN](/sql/t-sql/statements/create-login-transact-sql?view=azuresqldb-mi-current&preserve-view=true).
 
-However, using Azure Active Directory authentication with SQL Database and Azure Synapse requires using contained database users based on an Azure AD identity. A contained database user does not have a login in the master database, and maps to an identity in Azure AD that is associated with the database. The Azure AD identity can be either an individual user account or a group. For more information about contained database users, see [Contained Database Users- Making Your Database Portable](/sql/relational-databases/security/contained-database-users-making-your-database-portable).
+However, using Azure Active Directory authentication with SQL Database and Azure Synapse requires using contained database users based on an Azure AD identity. A contained database user does not have a login in the `master` database, and maps to an identity in Azure AD that is associated with the database. The Azure AD identity can be either an individual user account or a group. For more information about contained database users, see [Contained Database Users- Making Your Database Portable](/sql/relational-databases/security/contained-database-users-making-your-database-portable).
 
 > [!NOTE]
 > Database users (with the exception of administrators) cannot be created using the Azure portal. Azure roles are not propagated to the database in SQL Database, the SQL Managed Instance, or Azure Synapse. Azure roles are used for managing Azure Resources, and do not apply to database permissions. For example, the **SQL Server Contributor** role does not grant access to connect to the database in SQL Database, the SQL Managed Instance, or Azure Synapse. The access permission must be granted directly in the database using Transact-SQL statements.

azure-sql/database/authentication-azure-ad-logins-tutorial.md

@@ -18,21 +18,21 @@ monikerRange: "= azuresql || = azuresql-db || = azuresql-mi"
 > [!NOTE]
 > Azure Active Directory (Azure AD) server principals (logins) are currently in public preview for Azure SQL Database. Azure SQL Managed Instance can already utilize Azure AD logins.
 
-This article guides you through creating and utilizing [Azure Active Directory (Azure AD) principals (logins)](authentication-azure-ad-logins.md) in the virtual master database of Azure SQL.
+This article guides you through creating and utilizing [Azure Active Directory (Azure AD) principals (logins)](authentication-azure-ad-logins.md) in the virtual `master` database of Azure SQL.
 
 In this tutorial, you learn how to:
 
 > [!div class="checklist"]
-> - Create an Azure AD login in the virtual master database with the new syntax extension for Azure SQL Database
-> - Create a user mapped to an Azure AD login in the virtual master database
+> - Create an Azure AD login in the virtual `master` database with the new syntax extension for Azure SQL Database
+> - Create a user mapped to an Azure AD login in the virtual `master` database
 > - Grant server roles to an Azure AD user
 > - Disable an Azure AD login
 
 ## Prerequisites
 
 - A SQL Database or SQL Managed Instance with a database. See [Quickstart: Create an Azure SQL Database single database](single-database-create-quickstart.md) if you haven't already created an Azure SQL Database, or [Quickstart: Create an Azure SQL Managed Instance](../managed-instance/instance-create-quickstart.md).
 - Azure AD authentication set up for SQL Database or Managed Instance. For more information, see [Configure and manage Azure AD authentication with Azure SQL](authentication-aad-configure.md).
-- This article instructs you on creating an Azure AD login and user within the virtual master database. Only an Azure AD admin can create a user within the virtual master database, so we recommend you use the Azure AD admin account when going through this tutorial. An Azure AD principal with the `loginmanager` role can create a login, but not a user within the virtual master database.
+- This article instructs you on creating an Azure AD login and user within the virtual `master` database. Only an Azure AD admin can create a user within the virtual `master` database, so we recommend you use the Azure AD admin account when going through this tutorial. An Azure AD principal with the `loginmanager` role can create a login, but not a user within the virtual `master` database.
 
 ## Create Azure AD login
 
@@ -65,13 +65,13 @@ In this tutorial, you learn how to:
    bob@contoso.com                 EXTERNAL_LOGIN  E      0 
    ```
 
-1. The login `bob@contoso.com` has been created in the virtual master database.
+1. The login `bob@contoso.com` has been created in the virtual `master` database.
 
 ## Create user from an Azure AD login
 
-1. Now that we've created an Azure AD login, we can create a database-level Azure AD user that is mapped to the Azure AD login in the virtual master database. We'll continue to use our example, `bob@contoso.com` to create a user in the virtual master database, as we want to demonstrate adding the user to special roles. Only an Azure AD admin or SQL server admin can create users in the virtual master database.
+1. Now that we've created an Azure AD login, we can create a database-level Azure AD user that is mapped to the Azure AD login in the virtual `master` database. We'll continue to use our example, `bob@contoso.com` to create a user in the virtual `master` database, as we want to demonstrate adding the user to special roles. Only an Azure AD admin or SQL server admin can create users in the virtual `master` database.
 
-1. We're using the virtual master database, but you can switch to a database of your choice if you want to create users in other databases. Run the following query.
+1. We're using the virtual `master` database, but you can switch to a database of your choice if you want to create users in other databases. Run the following query.
 
    ```sql
    Use master
@@ -141,9 +141,9 @@ SELECT roles.principal_id AS RolePID,roles.name AS RolePName,
 
 ## Grant special roles for Azure AD users
 
-[Special roles for SQL Database](/sql/relational-databases/security/authentication-access/database-level-roles#special-roles-for--and-azure-synapse) can be assigned to users in the virtual master database.
+[Special roles for SQL Database](/sql/relational-databases/security/authentication-access/database-level-roles#special-roles-for--and-azure-synapse) can be assigned to users in the virtual `master` database.
 
-In order to grant one of the special database roles to a user, the user must exist in the virtual master database. 
+In order to grant one of the special database roles to a user, the user must exist in the virtual `master` database. 
 
 To add a user to a role, you can run the following query:
 
@@ -184,9 +184,9 @@ In our example, we created the user `bob@contoso.com`. Let's give the user the *
    You would see a similar output to the following:
 
    ```output
-   DatabaseRoleName	   DatabaseUserName 
+   DatabaseRoleName       DatabaseUserName 
    dbmanager              bob@contoso.com
-   loginmanager	       bob@contoso.com
+   loginmanager           bob@contoso.com
    ```
 
 ## Optional - Disable a login