Merge pull request #37011 from MicrosoftDocs/main

Auto Publish – main to live - 2026-04-03 17:30 UTC

Author: learn-build-service-prod[bot]

azure-sql/database/audit-write-storage-account-behind-vnet-firewall.md

@@ -5,7 +5,7 @@ description: Configure auditing to write database events on a storage account be
 author: sravanisaluru
 ms.author: srsaluru
 ms.reviewer: wiassaf, vanto, mathoma
-ms.date: 06/10/2025
+ms.date: 03/30/2026
 ms.service: azure-sql-database
 ms.subservice: security
 ms.topic: how-to
@@ -23,6 +23,9 @@ Auditing for [Azure SQL Database](sql-database-paas-overview.md) and [Azure Syna
 
 This article explains two ways to configure Azure SQL Database and Azure storage account for this option. The first uses the Azure portal, the second uses REST.
 
+> [!IMPORTANT]
+> When a storage account is behind a virtual network or firewall, you must use **managed identity** authentication (Storage Blob Data Contributor role), not storage access keys. The Azure portal configures this automatically when you save your auditing settings. If you configure auditing via REST API or PowerShell, don't specify a `storageAccountAccessKey` — the server's managed identity authenticates to the storage account instead.
+
 ## Background
 
 [Azure Virtual Network (VNet)](/azure/virtual-network/virtual-networks-overview) is the fundamental building block for your private network in Azure. VNet enables many types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other, the internet, and on-premises networks. VNet is similar to a traditional network in your own data center, but brings with it additional benefits of Azure infrastructure such as scale, availability, and isolation.
@@ -53,16 +56,16 @@ Connect to [Azure portal](https://portal.azure.com) with your subscription. Navi
 
 1. Select **Auditing** under the Security heading. Select **On**.
 
-1. Select **Storage**. Select the storage account where logs will be saved. The storage account must comply with the requirements listed in [Prerequisites](#prerequisites).
+1. Select **Storage**. Select the storage account where logs are saved. The storage account must comply with the requirements listed in [Prerequisites](#prerequisites).
 
 1. Open **Storage details**
 
    > [!NOTE]
-   > If the selected Storage account is behind VNet, you will see the following message:
+   > If the selected Storage account is behind VNet, you see the following message:
    >
    >`You have selected a storage account that is behind a firewall or in a virtual network. Using this storage requires to enable 'Allow trusted Microsoft services to access this storage account' on the storage account and creates a server managed identity with 'storage blob data contributor' RBAC.`
    >
-   >If you do not see this message, then storage account is not behind a VNet.
+   >If you don't see this message, then the storage account isn't behind a VNet.
 
 1. Select the number of days for the retention period. Then select **OK**. Logs older than the retention period are deleted.
 
@@ -166,7 +169,7 @@ You can configure auditing to write database events on a storage account behind
 - [Deploy an Azure SQL Server with Auditing enabled to write audit logs to a blob storage](https://azure.microsoft.com/resources/templates/sql-auditing-server-policy-to-blob-storage/)
 
 > [!NOTE]
-> The linked sample is on an external public repository and is provided 'as is', without warranty, and are not supported under any Microsoft support program/service.
+> The linked sample is on an external public repository and is provided 'as is', without warranty, and aren't supported under any Microsoft support program/service.
 
 ## Related content
 

azure-sql/database/auditing-overview.md

@@ -5,7 +5,7 @@ description: SQL Auditing for Azure SQL Database and Azure Synapse Analytics tra
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: srsaluru, vanto, mathoma
-ms.date: 12/19/2025
+ms.date: 03/30/2026
 ms.service: azure-sql-database
 ms.subservice: security
 ms.topic: concept-article
@@ -48,9 +48,9 @@ You can use SQL Database auditing to:
 ### Changes from the re-architecture of server auditing
 
 - Folder structure change for storage account:
-  - One of the primary changes involves a folder structure change for audit logs stored in storage account containers. Previously, server audit logs were written to separate folders; one for each database, with the database name serving as the folder name. With the new update, all server audit logs will be consolidated into a single folder labeled `master`. This behavior is the same as Azure SQL Managed Instance and SQL Server.
+  - One of the primary changes involves a folder structure change for audit logs stored in storage account containers. Previously, server audit logs were written to separate folders; one for each database, with the database name serving as the folder name. With the new update, all server audit logs are consolidated into a single folder labeled `master`. This behavior is the same as Azure SQL Managed Instance and SQL Server.
 - Folder structure change for read-only replicas:
-  - Read-only database replicas previously had their logs stored in a read-only folder. Those logs will now be written into the `master` folder. You can retrieve these logs by filtering on the new column `is_secondary_replica_true`.
+  - Read-only database replicas previously had their logs stored in a read-only folder. Those logs are now written into the `master` folder. You can retrieve these logs by filtering on the new column `is_secondary_replica_true`.
 - Permissions required to view Audit logs:
   - `VIEW DATABASE SECURITY AUDIT` permission in user database
 
@@ -66,6 +66,9 @@ For environments with many databases running heavy OLTP workloads, using server
 - Enabling auditing on a paused **Azure Synapse SQL pool** isn't supported. To enable auditing, resume the **Synapse SQL pool**.
 - Enabling auditing by using User Assigned Managed Identity (UAMI) isn't supported on **Azure Synapse**.
 - Currently, managed identities aren't supported for Azure Synapse, unless the storage account is behind a virtual network or firewall.
+
+> [!NOTE]
+> For Azure Synapse Analytics, auditing to a storage account behind a VNet requires the server's **system-assigned managed identity** with the **Storage Blob Data Contributor** role. User-assigned managed identities (UAMI) aren't supported for Synapse auditing. If you need to audit to a storage account that uses Microsoft Entra-only authentication, configure the system-assigned managed identity on the server and grant it the Storage Blob Data Contributor role on the target storage account. For more information, see [Write audit to a storage account behind VNet and firewall](audit-write-storage-account-behind-vnet-firewall.md).
 - Due to performance constraints, we don't audit the **tempdb** and **temporary tables**. While the batch completed action group captures statements against temporary tables, it might not correctly populate the object names. However, the source table is always audited, ensuring that all inserts from the source table to temporary tables are recorded.
 - Auditing for **Azure Synapse SQL pools** supports default audit action groups **only**.
 - When you configure auditing for a [logical server in Azure](logical-servers.md) or Azure SQL Database with the log destination as a storage account, the authentication mode must match the configuration for that storage account. If using storage access keys as the authentication type, the target storage account must be enabled with access to the storage account keys. If the storage account is configured to only use authentication with Microsoft Entra ID ([formerly Azure Active Directory](/entra/fundamentals/new-name)), auditing can be configured to use managed identities for authentication.
@@ -77,7 +80,7 @@ For environments with many databases running heavy OLTP workloads, using server
 ## Remarks
 
 - **Premium storage** with **BlockBlobStorage** is supported. Standard storage is supported. However, for audit to write to a storage account behind a virtual network or firewall, you must have a **general-purpose v2 storage account**. If you have a general-purpose v1 or Blob Storage account, [upgrade to a general-purpose v2 storage account](/azure/storage/common/storage-account-upgrade). For specific instructions see, [Write audit to a storage account behind VNet and firewall](audit-write-storage-account-behind-vnet-firewall.md). For more information, see [Types of storage accounts](/azure/storage/common/storage-account-overview#types-of-storage-accounts).
-- When customers enable SQL auditing and also configure **outbound networking** restrictions, they must allow list the fully qualified domain names of their auditing storage account to ensure audit events can successfully reach the destination. If the storage endpoint is not allowlisted, audit traffic is blocked, resulting in audit event loss. After adding the required storage account FQDNs to the allow list, customers must **re‑save** their auditing configuration to resume normal audit event flow.
+- When customers enable SQL auditing and also configure **outbound networking** restrictions, they must allow list the fully qualified domain names of their auditing storage account to ensure audit events can successfully reach the destination. If the storage endpoint isn't allowlisted, audit traffic is blocked, resulting in audit event loss. After adding the required storage account FQDNs to the allow list, customers must **re‑save** their auditing configuration to resume normal audit event flow.
 - **Hierarchical namespace** for all types of **standard storage account** and **premium storage account with BlockBlobStorage** is supported.
 - Audit logs are written to **Append Blobs** in an Azure Blob Storage on your Azure subscription
 - Audit logs are in .xel format and can be opened with [SQL Server Management Studio (SSMS)](/ssms/sql-server-management-studio-ssms).

azure-sql/database/private-endpoint-overview.md

@@ -5,7 +5,7 @@ description: Overview of private endpoint feature.
 author: VanMSFT
 ms.author: vanto
 ms.reviewer: wiassaf, vanto, mathoma, randolphwest
-ms.date: 06/24/2025
+ms.date: 03/30/2026
 ms.service: azure-sql-database
 ms.subservice: security
 ms.topic: overview
@@ -27,6 +27,8 @@ ms.custom:
 
 > [!IMPORTANT]  
 > This article applies to both 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. For simplicity, the term 'database' refers to both databases in Azure SQL Database and Azure Synapse Analytics. Likewise, any references to 'server' is referring to the [logical server](logical-servers.md) that hosts Azure SQL Database and dedicated SQL pool (formerly SQL DW) in Azure Synapse Analytics. This article does *not* apply to Azure SQL Managed Instance or dedicated SQL pools in Azure Synapse Analytics workspaces.
+>
+> Always use the fully qualified domain name (FQDN) of the server (`<server>.database.windows.net`) in connection strings for all client drivers and tools. Login attempts made directly to the private IP address or using the private link FQDN (`<server>.privatelink.database.windows.net`) fail. This behavior is by design because the private endpoint routes traffic to the SQL Gateway, which requires the correct FQDN to route logins successfully.
 
 <a id="how-to-set-up-private-link-for-azure-sql-database"></a>
 

azure-sql/database/region-availability.md

@@ -4,7 +4,7 @@ description: Learn about feature availability by region for Azure SQL Database.
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: rsetlem, peskount, rokhot, shrtiwar
-ms.date: 03/13/2026
+ms.date: 04/02/2026
 ms.service: azure-sql-database
 ms.topic: concept-article
 ms.custom:
@@ -99,6 +99,10 @@ Standard-series (Gen5) hardware is available in [all public regions worldwide wh
 
 ---
 
+US Gov Arizona supports **Hyperscale premium-series** up to 80 vCores.
+
+US Gov Texas and US Gov Virginia support **Hyperscale premium-series** up to 128 vCores.
+
 160 vCore and 192 vCore hardware for **Hyperscale premium-series** for single databases and elastic pools are a preview feature in the following regions:
 
 #### [Americas](#tab/americas)

azure-sql/database/transact-sql-tsql-differences-sql-server.md

@@ -4,7 +4,7 @@ description: This article discusses the Transact-SQL (T-SQL) differences between
 author: croblesm
 ms.author: roblescarlos
 ms.reviewer: wiassaf, mathoma, randolphwest
-ms.date: 02/19/2026
+ms.date: 04/02/2026
 ms.service: azure-sql-database
 ms.subservice: migration
 ms.topic: reference
@@ -38,6 +38,7 @@ The core DDL statements are available, but DDL statement extensions related to u
 - The `CREATE TABLE` and `ALTER TABLE` statements have `FILETABLE` and `FILESTREAM` options that can't be used on SQL Database because these features aren't supported.
 - Creating, altering, or dropping user objects such as tables, views, or stored procedures using the corresponding `CREATE`, `ALTER`, and `DROP` statements in the `master` database on a [logical server](logical-servers.md) is not supported.
 - `CREATE LOGIN` and `ALTER LOGIN` statements are supported, but don't offer all options available in SQL Server. To make your database more portable, SQL Database encourages using contained database users instead of logins whenever possible. For more information, see [CREATE LOGIN](/sql/t-sql/statements/create-login-transact-sql?view=azuresqldb-current&preserve-view=true), [ALTER LOGIN](/sql/t-sql/statements/alter-login-transact-sql?view=azuresqldb-current&preserve-view=true), and [Authorize database access to SQL Database, SQL Managed Instance, and Azure Synapse Analytics](logins-create-manage.md).
+- For a given database, the `database_id` column doesn't provide the same value across all system views. For more information, see the [Remarks](/sql/t-sql/functions/db-id-transact-sql#remarks) section for the `DB_ID` built-in function.
 
 ## T-SQL syntax not supported in Azure SQL Database