Merge branch 'MicrosoftDocs:main' into main

Author: abhimantiwari

azure-sql/database/connectivity-architecture.md

@@ -13,7 +13,7 @@ ms.topic: conceptual
 author: rohitnayakmsft
 ms.author: rohitna
 ms.reviewer: wiassaf, mathoma, vanto
-ms.date: 03/18/2022
+ms.date: 07/13/2022
 ---
 # Azure SQL Database and Azure Synapse Analytics connectivity architecture
 [!INCLUDE[appliesto-sqldb-asa](../includes/appliesto-sqldb-asa.md)]
@@ -41,9 +41,9 @@ Servers in SQL Database and Azure Synapse support the following three options fo
 - **Redirect (recommended):** Clients establish connections directly to the node hosting the database, leading to reduced latency and improved throughput. For connections to use this mode, clients need to:
   - Allow outbound communication from the client to all Azure SQL IP addresses in the region on ports in the range of 11000 to 11999. Use the Service Tags for SQL to make this easier to manage.  
   - Allow outbound communication from the client to Azure SQL Database gateway IP addresses on port 1433.
-
+  - When using the Redirect connection policy, refer to the [Azure IP Ranges and Service Tags – Public Cloud](https://www.microsoft.com/download/details.aspx?id=56519) for a list of your region's IP addresses to allow.
 - **Proxy:** In this mode, all connections are proxied via the Azure SQL Database gateways, leading to increased latency and reduced throughput. For connections to use this mode, clients need to allow outbound communication from the client to Azure SQL Database gateway IP addresses on port 1433.
-
+  - When using the Proxy connection policy, refer to the [Gateway IP addresses](#gateway-ip-addresses) list later in this article for your region's IP addresses to allow.
 - **Default:** This is the connection policy in effect on all servers after creation unless you explicitly alter the connection policy to either `Proxy` or `Redirect`. The default policy is`Redirect` for all client connections originating inside of Azure (for example, from an Azure Virtual Machine) and `Proxy`for all client connections originating outside (for example, connections from your local workstation).
 
 We highly recommend the `Redirect` connection policy over the `Proxy` connection policy for the lowest latency and highest throughput. However, you will need to meet the additional requirements for allowing network traffic as outlined above. If the client is an Azure Virtual Machine, you can accomplish this using Network Security Groups (NSG) with [service tags](/azure/virtual-network/network-security-groups-overview#service-tags). If the client is connecting from a workstation on-premises then you may need to work with your network admin to allow network traffic through your corporate firewall.

azure-sql/database/connectivity-settings.md

@@ -10,7 +10,7 @@ ms.topic: how-to
 author: rohitnayakmsft
 ms.author: rohitna
 ms.reviewer: wiassaf, mathoma, vanto
-ms.date: 08/03/2021
+ms.date: 07/14/2022
 ms.custom:
   - "devx-track-azurepowershell"
   - "devx-track-azurecli"
@@ -23,21 +23,20 @@ ms.devlang:
 
 This article introduces settings that control connectivity to the server for Azure SQL Database and [dedicated SQL pool (formerly SQL DW)](/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-overview-what-is) in Azure Synapse Analytics. These settings apply to all SQL Database and dedicated SQL pool (formerly SQL DW) databases associated with the server.
 
-> [!IMPORTANT]
-> This article doesn't apply to Azure SQL Managed Instance. This article also does not apply to dedicated SQL pools in Azure Synapse Analytics workspaces. See [Azure Synapse Analytics IP firewall rules](/azure/synapse-analytics/security/synapse-workspace-ip-firewall) for guidance on how to configure IP firewall rules for Azure Synapse Analytics with workspaces.
 
-The connectivity settings are accessible from the **Firewalls and virtual networks** screen as shown in the following screenshot:
+You can change these settings from the networking tab of your [logical server](logical-servers.md): 
 
-:::image type="content" source="media/single-database-create-quickstart/manage-connectivity-settings.png" alt-text="Screenshot of the Firewalls and virtual networks settings in Azure portal for SQL server":::
+:::image type="content" source="media/connectivity-settings/manage-connectivity-settings.png" alt-text="Screenshot of the Firewalls and virtual networks settings in Azure portal for SQL server.":::
+
+> [!IMPORTANT]
+> This article doesn't apply to Azure SQL Managed Instance. This article also does not apply to dedicated SQL pools in Azure Synapse Analytics workspaces. See [Azure Synapse Analytics IP firewall rules](/azure/synapse-analytics/security/synapse-workspace-ip-firewall) for guidance on how to configure IP firewall rules for Azure Synapse Analytics with workspaces.
 
-> [!NOTE]
-> These settings take effect immediately after they're applied. Your customers might experience connection loss if they don't meet the requirements for each setting.
 
 ## Deny public network access
 
-The default for this setting is **No** so that customers can connect by using either public endpoints (with IP-based server- level firewall rules or with virtual-network firewall rules) or private endpoints (by using Azure Private Link), as outlined in the [network access overview](network-access-controls-overview.md).
+The default for the **Connectivity method** setting is **No access** so that customers can connect by using either public endpoints (with IP-based server- level firewall rules or with virtual-network firewall rules) or private endpoints (by using Azure Private Link), as outlined in the [network access overview](network-access-controls-overview.md).
 
-When **Deny public network access** is set to **Yes**, only connections via private endpoints are allowed. All connections via public endpoints will be denied with an error message similar to:  
+When **Connectivity method** is set to **No access**, only connections via private endpoints are allowed. All connections via public endpoints will be denied with an error message similar to:  
 
 ```output
 Error 47073
@@ -46,16 +45,37 @@ The public network interface on this server is not accessible.
 To connect to this server, use the Private Endpoint from inside your virtual network.
 ```
 
-When **Deny public network access** is set to **Yes**, any attempts to add, remove or edit any firewall rules will be denied with an error message similar to:
+When **Connectivity method** is set to **No access**, any attempts to add, remove or edit any firewall rules will be denied with an error message similar to:
 
 ```output
 Error 42101
 Unable to create or modify firewall rules when public network interface for the server is disabled. 
 To manage server or database level firewall rules, please enable the public network interface.
 ```
-Ensure that **Deny public network access** is set to **No** to be able to add, remove or edit any firewall rules for Azure Sql
 
-## Change public network access via PowerShell
+Ensure that **Connectivity method** is set to **Public endpoint** or **Private endpoint** to be able to add, remove or edit any firewall rules for Azure SQL Database and Azure Synapse Analytics. 
+
+## Change public network access 
+
+It's possible to change the public network access via the Azure portal, Azure PowerShell, and the Azure CLI. 
+
+### [Portal](#tab/azure-portal)
+
+To enable public network access for the logical server hosting your databases, go to the **Networking page** in the [Azure portal](https://portal.azure.com), choose the **Public access** tab, and then set the **Public network access** to **Select networks**. 
+
+
+From this page, you can add a virtual network rule, as well as configure firewall rules for your public endpoint. 
+
+Choose the **Private access** tab to configure a [private endpoint](private-endpoint-overview.md). 
+
+
+> [!NOTE]
+> These settings take effect immediately after they're applied. Your customers might experience connection loss if they don't meet the requirements for each setting.
+
+### [PowerShell](#tab/azure-powershell)
+
+It's possible to change public network access by using Azure PowerShell. 
+
 
 > [!IMPORTANT]
 > Azure SQL Database still supports the PowerShell Azure Resource Manager module, but all future development is for the Az.Sql module. For these cmdlets, see [AzureRM.Sql](/powershell/module/AzureRM.Sql/). The arguments for the commands in the Az module and in the AzureRm modules are substantially identical. The following script requires the [Azure PowerShell module](/powershell/azure/install-az-ps).
@@ -72,13 +92,13 @@ $SecureString = ConvertTo-SecureString "password" -AsPlainText -Force
 Set-AzSqlServer -ServerName sql-server-name -ResourceGroupName sql-server-group -SqlAdministratorPassword $SecureString -PublicNetworkAccess "Disabled"
 ```
 
-## Change public network access via CLI
+### [Azure CLI](#tab/azure-cli)
+
+It's possible to change the public network settings by using the Azure CLI. 
 
 > [!IMPORTANT]
 > All scripts in this section require the [Azure CLI](/cli/azure/install-azure-cli).
 
-### Azure CLI in a Bash shell
-
 The following CLI script shows how to change the **Public Network Access** setting in a Bash shell:
 
 ```azurecli-interactive
@@ -90,9 +110,11 @@ az sql server show -n sql-server-name -g sql-server-group --query "publicNetwork
 az sql server update -n sql-server-name -g sql-server-group --set publicNetworkAccess="Disabled"
 ```
 
+---
+
 ## Minimal TLS version 
 
-The minimal [Transport Layer Security (TLS)](https://support.microsoft.com/help/3135244/tls-1-2-support-for-microsoft-sql-server) version setting allows customers to choose which version of TLS their SQL database uses.
+The minimal [Transport Layer Security (TLS)](https://support.microsoft.com/help/3135244/tls-1-2-support-for-microsoft-sql-server) version setting allows customers to choose which version of TLS their SQL database uses. It's possible to change the minimum TLS version by using the Azure portal, Azure PowerShell, and the Azure CLI. 
 
 Currently, we support TLS 1.0, 1.1, and 1.2. Setting a minimal TLS version ensures that newer TLS versions are supported. For example, choosing a TLS version 1.1 means only connections with TLS 1.1 and 1.2 are accepted, and connections with TLS 1.0 are rejected. After you test to confirm that your applications support it, we recommend setting the minimal TLS version to 1.2. This version includes fixes for vulnerabilities in previous versions and is the highest version of TLS that's supported in Azure SQL Database.
 
@@ -110,11 +132,15 @@ Error 47072
 Login failed with invalid TLS version
 ```
 
-## Set the minimal TLS version in Azure portal
+### [Portal](#tab/azure-portal)
 
-In the [Azure portal](https://portal.azure.com), go to your **SQL server** resource. Under the **Security** settings, select **Firewalls and virtual networks**. Select the **Minimum TLS Version** desired for all SQL Databases associated with the server, and select **Save**.
+In the [Azure portal](https://portal.azure.com), go to your **SQL server** resource. Under the **Security** settings, select **Networking** and then choose the **Connectivity** tab. Select the **Minimum TLS Version** desired for all databases associated with the server, and select **Save**.
 
-## Set the minimal TLS version via PowerShell
+:::image type="content" source="media/connectivity-settings/minimal-tls-version.png" alt-text="Screenshot of the Connectivity tab of the Networking settings for your logical server, minimal TLS version drop-down selected." lightbox="media/connectivity-settings/minimal-tls-version.png":::
+
+### [PowerShell](#tab/azure-powershell)
+
+It's possible to change the minimum TLS version by using Azure PowerShell. 
 
 > [!IMPORTANT]
 > Azure SQL Database still supports the PowerShell Azure Resource Manager module, but all future development is for the Az.Sql module. For these cmdlets, see [AzureRM.Sql](/powershell/module/AzureRM.Sql/). The arguments for the commands in the Az module and in the AzureRm modules are substantially identical. The following script requires the [Azure PowerShell module](/powershell/azure/install-az-ps).
@@ -131,12 +157,13 @@ $SecureString = ConvertTo-SecureString "password" -AsPlainText -Force
 Set-AzSqlServer -ServerName sql-server-name -ResourceGroupName sql-server-group -SqlAdministratorPassword $SecureString  -MinimalTlsVersion "1.2"
 ```
 
-## Set the minimal TLS version via the Azure CLI
+### [Azure CLI](#tab/azure-cli)
+
+It's possible to change the minimum TLS settings by using the Azure CLI. 
 
 > [!IMPORTANT]
 > All scripts in this section require the [Azure CLI](/cli/azure/install-azure-cli).
 
-### Azure CLI in a Bash shell
 
 The following CLI script shows how to change the **Minimal TLS Version** setting in a Bash shell:
 
@@ -148,11 +175,25 @@ az sql server show -n sql-server-name -g sql-server-group --query "minimalTlsVer
 az sql server update -n sql-server-name -g sql-server-group --set minimalTlsVersion="1.2"
 ```
 
+---
+
 ## Change the connection policy
 
 [Connection policy](connectivity-architecture.md#connection-policy) determines how customers connect to Azure SQL Database.
 
-## Change the connection policy via PowerShell
+It's possible to change the connection policy by using the Azure portal, Azure PowerShell, and the Azure CLI. 
+
+### [Portal](#tab/azure-portal)
+
+It's possible to change your connection policy for your logical server by using the Azure portal. 
+
+In the [Azure portal](https://portal.azure.com), go to your **SQL server** resource. Under the **Security** settings, select **Networking** and then choose the **Connectivity** tab. Choose the desired connection policy, and select **Save**.
+
+:::image type="content" source="media/connectivity-settings/change-connection-policy.png" alt-text="Screenshot of the Connectivity tab of the Networking page, Connection policy selected.":::
+
+### [PowerShell](#tab/azure-powershell)
+
+It's possible to change the connection policy for your logical server by using Azure PowerShell. 
 
 > [!IMPORTANT]
 > Azure SQL Database still supports the PowerShell Azure Resource Manager module, but all future development is for the Az.Sql module. For these cmdlets, see [AzureRM.Sql](/powershell/module/AzureRM.Sql/). The arguments for the commands in the Az module and in the AzureRm modules are substantially identical. The following script requires the [Azure PowerShell module](/powershell/azure/install-az-ps).
@@ -173,7 +214,9 @@ $id="$sqlserverid/connectionPolicies/Default"
 Set-AzResource -ResourceId $id -Properties @{"connectionType" = "Proxy"} -f
 ```
 
-## Change the connection policy via the Azure CLI
+### [Azure CLI](#tab/azure-cli)
+
+It's possible to change the connection policy for your logical server by using the Azure CLI. 
 
 > [!IMPORTANT]
 > All scripts in this section require the [Azure CLI](/cli/azure/install-azure-cli).
@@ -211,6 +254,8 @@ az resource show --ids %sqlserverid%
 az resource update --ids %sqlserverid% --set properties.connectionType=Proxy
 ```
 
+---
+
 ## Next steps
 
 - For an overview of how connectivity works in Azure SQL Database, refer to [Connectivity architecture](connectivity-architecture.md).

azure-sql/database/disaster-recovery-guidance.md

@@ -108,10 +108,10 @@ For more information about database alert rules, see [Receive Alert Notification
 
 ### Enable auditing
 
-If auditing is required to access your database, you need to enable Auditing after the database recovery. For more information, see [Database auditing](/azure/azure-sql/database/auditing-overview).
+If auditing is required to access your database, you need to enable Auditing after the database recovery. For more information, see [Database auditing](./auditing-overview.md).
 
 ## Next steps
 
 - To learn about Azure SQL Database automated backups, see [SQL Database automated backups](automated-backups-overview.md)
 - To learn about business continuity design and recovery scenarios, see [Continuity scenarios](business-continuity-high-availability-disaster-recover-hadr-overview.md)
-- To learn about using automated backups for recovery, see [restore a database from the service-initiated backups](recovery-using-backups.md)
+- To learn about using automated backups for recovery, see [restore a database from the service-initiated backups](recovery-using-backups.md)

azure-sql/database/dns-alias-overview.md

@@ -106,7 +106,7 @@ Presently, a DNS alias has the following limitations:
 - _Table auditing is not supported:_ You cannot use a DNS alias on a server that has *table auditing* enabled on a database.
   - Table auditing is deprecated.
   - We recommend that you move to [Blob Auditing](auditing-overview.md).
-  - We recommend that you move to [Blob Auditing](/azure/azure-sql/database/auditing-overview).
+  - We recommend that you move to [Blob Auditing](./auditing-overview.md).
 - DNS alias is subject to [naming restrictions](/azure/azure-resource-manager/management/resource-name-rules).
 
 ## Related resources
@@ -117,4 +117,4 @@ Presently, a DNS alias has the following limitations:
 
 ## Next steps
 
-- [PowerShell for DNS Alias to Azure SQL Database](dns-alias-powershell-create.md)
+- [PowerShell for DNS Alias to Azure SQL Database](dns-alias-powershell-create.md)

azure-sql/database/doc-changes-updates-release-notes-whats-new.md

@@ -123,10 +123,10 @@ Learn about significant changes to the Azure SQL Database documentation.
 | **Azure AD-only authentication** | It's now possible to restrict authentication to your Azure SQL Database to Azure Active Directory users only. This feature is currently in preview. To learn more, see [Azure AD-only authentication](authentication-azure-ad-only-authentication.md). | 
 | **Query store hints** | It's now possible to use query hints to optimize your query execution via the OPTION clause. This feature is currently in preview. To learn more, see [Query store hints](/sql/relational-databases/performance/query-store-hints?view=azuresqldb-current&preserve-view=true). | 
 | **Change data capture** | Using change data capture (CDC) with Azure SQL Database is now in preview. To learn more, see [Change data capture](/sql/relational-databases/track-changes/about-change-data-capture-sql-server). | 
-| **SQL Database ledger** | SQL Database ledger is in preview, and introduces the ability to cryptographically attest to other parties, such as auditors or other business parties, that your data hasn't been tampered with. To learn more, see [Ledger](ledger-overview.md). | 
+| **SQL Database ledger** | SQL Database ledger is in preview, and introduces the ability to cryptographically attest to other parties, such as auditors or other business parties, that your data hasn't been tampered with. To learn more, see [Ledger](/sql/relational-databases/security/ledger/ledger-overview). | 
 | **Maintenance window** | The maintenance window feature allows you to configure a maintenance schedule for your Azure SQL Database, currently in preview. To learn more, see [maintenance window](maintenance-window.md).|
 | **SQL insights** | SQL insights is a comprehensive solution for monitoring any product in the Azure SQL family. SQL insights uses dynamic management views to expose the data you need to monitor health, diagnose problems, and tune performance. To learn more, see [SQL insights](/azure/azure-monitor/insights/sql-insights-overview). | 
 
 ## Contribute to content
 
-To contribute to the Azure SQL documentation, see the [Docs contributor guide](/contribute/).
+To contribute to the Azure SQL documentation, see the [Docs contributor guide](/contribute/).