Merge pull request #36349 from MicrosoftDocs/main

Auto Publish – main to live - 2026-01-21 18:30 UTC

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

azure-sql/database/auditing-overview.md

@@ -77,11 +77,11 @@ 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.
 - **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).
 - To configure an immutable log store for the server or database-level audit events, follow the [instructions provided by Azure Storage](/azure/storage/blobs/immutable-time-based-retention-policy-overview#allow-protected-append-blobs-writes). When configuring immutable blob storage for auditing, ensure that **Allow protected append writes** is set to either **Append blobs** or **Block and append blobs**. The **None** option isn't supported. For time-based retention policies, the storage account's retention interval must be shorter than the SQL Auditing retention setting. Configurations where the storage policy is set, but SQL Auditing retention is `0`, aren't supported.
-
 - You can write audit logs to an Azure Storage account behind a virtual network or firewall.
 - For details about the log format, hierarchy of the storage folder, and naming conventions, see the article, [SQL Database audit log format](audit-log-format.md).
 - Auditing on [Use read-only replicas to offload read-only query workloads](read-scale-out.md) is automatically enabled. For more information about the hierarchy of the storage folders, naming conventions, and log format, see the article, [SQL Database audit log format](audit-log-format.md).

azure-sql/managed-instance/create-template-quickstart.md

@@ -31,6 +31,18 @@ If your environment meets the prerequisites and you're familiar with using ARM t
 
 The template used in this quickstart is from [Azure Quickstart Templates](https://azure.microsoft.com/resources/templates/sqlmi-new-vnet/).
 
+**Key template parameters**
+
+| Parameter name             | Default / Example        | Allowed values / Constraints          | Description                                   |
+|----------------------------|--------------------------|---------------------------------------|-----------------------------------------------|
+| managedInstanceName        | sqlmi                    | 1–63 characters                       | Name of the SQL managed instance         |
+| location                   | resourceGroup().location | Azure regions that support SQL managed instance     | Region for all resources                      |
+| administratorLogin         | sqladmin                 | Cannot be reserved words              | SQL administrator login                      |
+| administratorLoginPassword | —                        | Minimum length and complexity enforced| SQL administrator password                   |
+| vCores                     | 8                        | Valid vCore values per SKU            | Compute size of the instance                  |
+| storageSizeInGB            | 256                      | Min/Max per service tier              | Storage allocated to the instance             |
+| subnetAddressPrefix        | 10.0.0.0/24              | Dedicated, delegated subnet required  | Subnet for the managed instance               |
+
 :::code language="json" source="~/../quickstart-templates/quickstarts/microsoft.sql/sqlmi-new-vnet/azuredeploy.json":::
 
 These resources are defined in the template:
@@ -46,8 +58,19 @@ More template samples can be found in [Azure Quickstart Templates](https://azure
 
 Select **Try it** from the following PowerShell code block to open Azure Cloud Shell.
 
+**Deployment checklist**
+
+1. Verify prerequisites:
+   - Active Azure subscription
+   - Required permissions (SQL Managed Instance Contributor or Microsoft.Sql/managedInstances/write)
+2. Run the deployment command (PowerShell or Azure CLI) using the snippets below.
+3. Verify success:
+   - In the Azure portal, the deployment shows **Succeeded**
+   - The SQL managed instance appears in the target resource group with state **Creating** or **Ready**
+<!-- Added a numbered deployment checklist to clarify prerequisites, execution steps, and success verification. -->
+
 > [!IMPORTANT]
-> Deploying a managed instance is a long-running operation. Deployment of the first instance in the subnet typically takes much longer than deploying into a subnet with existing managed instances. For average provisioning times, see [SQL Managed Instance management operations](management-operations-duration.md).
+> Deploying a SQL managed instance is a long-running operation. Deployment of the first instance in the subnet typically takes much longer than deploying into a subnet with existing managed instances. For average provisioning times, see [SQL Managed Instance management operations](management-operations-duration.md).
 
 # [PowerShell](#tab/azure-powershell)