Merge pull request #290315 from dominicbetts/release-aio-ga-fix-conflict

Dirty PR - AIO [GA]: Release-aio-ga-fix-merge-conflict

Author: rmca14

articles/azure-cache-for-redis/cache-azure-active-directory-for-authentication.md

@@ -147,6 +147,7 @@ The following table includes links to code samples. They demonstrate how to conn
 | Client library  | Language   | Link to sample code|
 |----|----|----|
 | StackExchange.Redis | .NET           | [StackExchange.Redis code sample](https://github.com/Azure/Microsoft.Azure.StackExchangeRedis)   |
+| go-redis            | Go             | [go-redis code sample](https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/azidentity#example-package-Redis) |
 | redis-py            | Python         | [redis-py code sample](https://aka.ms/redis/aad/sample-code/python)        |
 | Jedis               | Java           | [Jedis code sample](https://aka.ms/redis/aad/sample-code/java-jedis)    |
 | Lettuce             | Java           | [Lettuce code sample](https://aka.ms/redis/aad/sample-code/java-lettuce)  |

articles/azure-government/documentation-government-overview-wwps.md

@@ -80,7 +80,7 @@ Your data in an Azure Storage account is [always replicated](../storage/common/s
 
 Data in an Azure Storage account is always replicated three times in the primary region. Azure Storage provides LRS and ZRS redundancy options for replicating data in the primary region. For applications requiring high availability, you can choose geo-replication to a secondary region that is hundreds of kilometers away from the primary region. Azure Storage offers GRS and GZRS options for copying data to a secondary region. More options are available to you for configuring read access (RA) to the secondary region (RA-GRS and RA-GZRS), as explained in [Read access to data in the secondary region](../storage/common/storage-redundancy.md#read-access-to-data-in-the-secondary-region).
 
-Azure Storage redundancy options can have implications on data residency as Azure relies on [paired regions](../availability-zones/cross-region-replication-azure.md) to deliver [geo-redundant storage](../storage/common/storage-redundancy.md#geo-redundant-storage) (GRS). For example, if you're concerned about geo-replication across regions that span country boundaries, you may want to choose LRS or ZRS to keep Azure Storage data at rest within the geographic boundaries of the country in which the primary region is located. Similarly, [geo replication for Azure SQL Database](/azure/azure-sql/database/active-geo-replication-overview) can be obtained by configuring asynchronous replication of transactions to any region in the world, although it's recommended that paired regions be used for this purpose as well. If you need to keep relational data inside the geographic boundaries of your country/region, you shouldn't configure Azure SQL Database asynchronous replication to a region outside that country/region.
+Azure Storage redundancy options can have implications on data residency as Azure relies on [paired regions](../availability-zones/cross-region-replication-azure.md) to deliver [geo-redundant storage](../storage/common/storage-redundancy.md#geo-redundant-storage) (GRS). For example, if you're concerned about geo-replication across regions that span country/region boundaries, you may want to choose LRS or ZRS to keep Azure Storage data at rest within the geographic boundaries of the country/region in which the primary region is located. Similarly, [geo replication for Azure SQL Database](/azure/azure-sql/database/active-geo-replication-overview) can be obtained by configuring asynchronous replication of transactions to any region in the world, although it's recommended that paired regions be used for this purpose as well. If you need to keep relational data inside the geographic boundaries of your country/region, you shouldn't configure Azure SQL Database asynchronous replication to a region outside that country/region.
 
 As described on the [data location page](https://azure.microsoft.com/global-infrastructure/data-residency/), most Azure **regional** services honor the data at rest commitment to ensure that your data remains within the geographic boundary where the corresponding service is deployed. A handful of exceptions to this rule are noted on the data location page. You should review these exceptions to determine if the type of data stored outside your chosen deployment Geography meets your needs.
 

articles/azure-resource-manager/bicep/bicep-cli.md

@@ -3,7 +3,7 @@ title: Bicep CLI commands and overview
 description: Describes the commands that you can use in the Bicep CLI. These commands include building Azure Resource Manager templates from Bicep.
 ms.topic: reference
 ms.custom: devx-track-azurecli, devx-track-bicep, devx-track-arm-template
-ms.date: 10/23/2024
+ms.date: 10/30/2024
 ---
 
 # Bicep CLI commands
@@ -140,6 +140,99 @@ To install a specific version:
 az bicep install --version v0.3.255
 ```
 
+## jsonrpc
+
+The `jsonrpc` command enables running the Bicep CLI with a JSON-RPC interface, allowing for programmatic interaction with structured output and avoiding cold-start delays when compiling multiple files. This setup also supports building libraries to interact with Bicep files programmatically in non-.NET languages.
+
+The wire format for sending and receiving input/output is header-delimited, using the following structure, where `\r` and `\n` represent carriage return and line feed characters:
+
+```
+Content-Length: <length>\r\n\r\n<message>\r\n\r\n
+```
+
+* `<length>` is the length of the `<message>` string, including the trailing `\r\n\r\n`.
+* `<message>` is the raw JSON message.
+
+For example:
+
+```
+Content-Length: 72\r\n\r\n{"jsonrpc": "2.0", "id": 0, "method": "bicep/version", "params": {}}\r\n\r\n
+```
+
+The following message shows an example for Bicep version.
+
+* The input:
+
+  ```json
+  {
+    "jsonrpc": "2.0",
+    "id": 0,
+    "method": "bicep/version",
+    "params": {}
+  }
+  ```
+  
+* The output:
+
+  ```json
+  {
+    "jsonrpc": "2.0",
+    "id": 0,
+    "result": {
+      "version": "0.24.211"
+    }
+  }
+  ```
+
+For the available methods & request/response bodies, see [`ICliJsonRpcProtocol.cs`](https://github.com/Azure/bicep/blob/main/src/Bicep.Cli/Rpc/ICliJsonRpcProtocol.cs).
+For an example establishing a JSONRPC connection and interacting with Bicep files programmatically using Node, see [`jsonrpc.test.ts`](https://github.com/Azure/bicep/blob/main/src/Bicep.Cli.E2eTests/src/jsonrpc.test.ts).
+
+### Usage for named pipe
+
+Use the following syntax to connect to an existing named pipe as a JSONRPC client.
+
+```bicep cli
+bicep jsonrpc --pipe <named_pipe>`
+```
+
+`<named_pipe>` is an existing named pipe to connect the JSONRPC client to.
+
+To connect to a named pipe on OSX/Linux :
+
+```bicep cli
+bicep jsonrpc --pipe /tmp/bicep-81375a8084b474fa2eaedda1702a7aa40e2eaa24b3.sock
+```
+
+To connect to a named pipe on Windows :
+
+```bicep cli
+bicep jsonrpc --pipe \\.\pipe\\bicep-81375a8084b474fa2eaedda1702a7aa40e2eaa24b3.sock`
+```
+
+For more examples, see [C#](https://github.com/Azure/bicep/blob/096c32f9d5c42bfb85dff550f72f3fe16f8142c7/src/Bicep.Cli.IntegrationTests/JsonRpcCommandTests.cs#L24-L50) and [node.js](https://github.com/anthony-c-martin/bicep-node/blob/4769e402f2d2c1da8d27df86cb3d62677e7a7456/src/utils/jsonrpc.ts#L117-L151).
+
+### Usage for TCP socket
+
+Use the following syntax to connect to an existing TCP socket as a JSONRPC client.
+
+```bicep cli
+bicep jsonrpc --socket <tcp_socket>
+```
+
+`<tcp_socket>` is a socket number to connect the JSONRPC client to.
+
+To connect to a TCP socket
+
+`bicep jsonrpc --socket 12345`
+
+### Usage for stdin and stdout
+
+Use the following syntax to run the JSONRPC interface using stdin & stdout for messages.
+
+```bicep cli
+bicep jsonrpc --stdio
+```
+
 ## lint
 
 The `lint` command returns the errors and the [linter rule](./linter.md) violations of a Bicep file.
@@ -264,19 +357,19 @@ module stgModule 'br:exampleregistry.azurecr.io/bicep/modules/storage:v1' = {
 
 The local cache is found in:
 
-- On Windows
+* On Windows
 
     ```path
     %USERPROFILE%\.bicep\br\<registry-name>.azurecr.io\<module-path\<tag>
     ```
 
-- On Linux
+* On Linux
 
     ```path
     /home/<username>/.bicep
     ```
 
-- On Mac
+* On Mac
 
     ```path
     ~/.bicep
@@ -318,6 +411,6 @@ If the Bicep CLI hasn't been installed, you'll encounter an error message statin
 
 To learn about deploying a Bicep file, see:
 
-- [Azure CLI](deploy-cli.md)
-- [Cloud Shell](deploy-cloud-shell.md)
-- [PowerShell](deploy-powershell.md)
+* [Azure CLI](deploy-cli.md)
+* [Cloud Shell](deploy-cloud-shell.md)
+* [PowerShell](deploy-powershell.md)

articles/cost-management-billing/costs/export-cost-data-storage-account-sas-key.md

@@ -18,8 +18,10 @@ Often, partners don't have their own Azure subscriptions in the tenant associate
 
 ## Requirements
 
+- **Availability:** This feature is available only in the public cloud. 
+
 - You must be a partner with a Microsoft Partner Agreement. Your customers on the Azure plan must have a signed Microsoft Customer Agreement.
-    - SAS key-based export isn't supported for indirect enterprise agreements.
+- SAS key-based export isn't supported for indirect enterprise agreements.
 - SAS key-based export is available for partners that sign in to the Azure portal from a partner tenant. However, the SAS key option isn't supported if you're using Azure Lighthouse for customer management.
 - You must be global admin for your partner organization's billing account.
 - You must have access to configure a storage account that's in a different tenant of your partner organization. You're responsible for maintaining permissions and data access when your export data to your storage account.

articles/cost-management-billing/manage/mca-setup-account.md

@@ -142,6 +142,9 @@ Your new billing account simplifies billing for your organization and provides e
 3. You use an invoice section to organize your costs based on your needs, similar to departments in your Enterprise Agreement enrollment. Department becomes invoice sections and department administrators become owners of the respective invoice sections. To learn more about invoice sections, see [understand invoice sections](../understand/mca-overview.md#invoice-sections).
 4. The accounts that were created in your Enterprise Agreement aren't supported in the new billing account. The account's subscriptions belong to the respective invoice section for their department. Account owners can create and manage subscriptions for their invoice sections.
 
+> [!NOTE]
+> When you have SQL Server licenses applied with centrally managed SQL Azure Hybrid Benefit in your Enterprise Agreement and then transfer the agreement to a Microsoft Customer Agreement (enterprise), the licenses don’t automatically transfer. After your new agreement migration completes, you must manually assign licenses with centrally managed SQL Hybrid Benefit. For more information about planning and getting started, see [Transition to centrally managed Azure Hybrid Benefit](../scope-level/transition-existing.md). For more information about centrally managed Azure Hybrid Benefit, see [What is centrally managed Azure Hybrid Benefit for SQL Server](../scope-level/overview-azure-hybrid-benefit-scope.md).
+
 ## Changes to billing administrator access
 
 Depending on their access, billing administrators on your Enterprise Agreement enrollment get access to the billing scopes on the new account. The following lists explain the changes to access that result from setup:

articles/cost-management-billing/scope-level/overview-azure-hybrid-benefit-scope.md

@@ -3,7 +3,7 @@ title: What is centrally managed Azure Hybrid Benefit for SQL Server?
 description: Azure Hybrid Benefit is a licensing benefit that lets you bring your on-premises core-based Windows Server and SQL Server licenses with active Software Assurance (or subscription) to Azure.
 author: bandersmsft
 ms.author: banders
-ms.date: 03/21/2024
+ms.date: 11/11/2024
 ms.topic: overview
 ms.service: cost-management-billing
 ms.subservice: ahb
@@ -33,6 +33,9 @@ To use centrally managed licenses, you must have a specific role assigned to you
     - Billing profile contributor  
         If you don't have one of the roles, your organization must assign one to you. For more information about how to become a member of the roles, see [Manage billing roles](../manage/understand-mca-roles.md#manage-billing-roles-in-the-azure-portal).
 
+> [!NOTE]
+> When you have SQL Server licenses applied with centrally managed SQL Azure Hybrid Benefit in your Enterprise Agreement and then transfer the agreement to a Microsoft Customer Agreement (enterprise), the licenses don’t automatically transfer. After your new agreement migration completes, you must manually assign licenses with centrally managed SQL Hybrid Benefit. For more information about migrating from an Enterprise Agreement to a Microsoft Customer Agreement (enterprise), see [Set up your billing account for a Microsoft Customer Agreement](../manage/mca-setup-account.md).
+
 At a high level, here's how centrally managed Azure Hybrid Benefit works:
 
 1. First, confirm that all your SQL Server VMs are visible to you and Azure by enabling automatic registration of the self-installed SQL server images with the IaaS extension. For more information, see [Register multiple SQL VMs in Azure with the SQL IaaS Agent extension](/azure/azure-sql/virtual-machines/windows/sql-agent-extension-manually-register-vms-bulk).

articles/cost-management-billing/scope-level/transition-existing.md

@@ -3,7 +3,7 @@ title: Transition to centrally managed Azure Hybrid Benefit
 description: This article describes the changes and several transition scenarios to illustrate transitioning to centrally managed Azure Hybrid Benefit.
 author: bandersmsft
 ms.author: banders
-ms.date: 03/21/2024
+ms.date: 11/11/2024
 ms.topic: conceptual
 ms.service: cost-management-billing
 ms.subservice: ahb
@@ -13,6 +13,9 @@ ms.subservice: ahb
 
 When you transition to centrally managed Azure Hybrid Benefit, it removes the need to configure the benefit at the resource level. This article describes the changes and several transition scenarios to illustrate the result. For a better understanding about how the new scope-level license management experience applies licenses and discounts to your resources, see [What is centrally managed Azure Hybrid Benefit?](overview-azure-hybrid-benefit-scope.md)
 
+> [!NOTE]
+> When you have SQL Server licenses applied with centrally managed SQL Azure Hybrid Benefit in your Enterprise Agreement and then transfer the agreement to a Microsoft Customer Agreement (enterprise), the licenses don’t automatically transfer. After your new agreement migration completes, you must manually assign licenses with centrally managed SQL Hybrid Benefit. For more information about migrating from an Enterprise Agreement to a Microsoft Customer Agreement (enterprise), see [Set up your billing account for a Microsoft Customer Agreement](../manage/mca-setup-account.md).
+
 ## Changes to individual resource configuration
 
 When you assign licenses to a subscription using the new experience, changes are shown in the Azure portal. Afterward, you can't manage the benefit at the resource level. Any changes that you make at a scope level override settings at the individual resource level.

articles/firewall/protect-azure-kubernetes-service.md

@@ -146,6 +146,11 @@ When the previous command has succeeded, save the firewall frontend IP address f
 
 FWPUBLIC_IP=$(az network public-ip show -g $RG -n $FWPUBLICIP_NAME --query "ipAddress" -o tsv)
 FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIPAddress" -o tsv)
+
+
+# set fw as vnet dns server so dns queries are visible in fw logs
+
+az network vnet update -g $RG --name $VNET_NAME --dns-servers $FWPRIVATE_IP
 ```
 
 > [!NOTE]
@@ -191,6 +196,11 @@ az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aks
 
 ```azurecli
 az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow --priority 100
+
+# set fw application rule to allow kubernettes to reach storage and image resources
+
+az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwarweb' -n 'storage' --source-addresses '10.42.1.0/24' --protocols 'https=443' --target-fqdns '*.blob.storage.azure.net' '*.blob.core.windows.net' --action allow --priority 101
+az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwarweb' -n 'website' --source-addresses '10.42.1.0/24' --protocols 'https=443' --target-fqdns 'ghcr.io' '*.docker.io' '*.docker.com' '*.githubusercontent.com' 
 ```
 
 See [Azure Firewall documentation](overview.md) to learn more about the Azure Firewall service.

articles/frontdoor/TOC.yml

@@ -154,6 +154,8 @@
           href: front-door-url-rewrite.md?pivots=front-door-standard-premium
         - name: URL redirect
           href: front-door-url-redirect.md?pivots=front-door-standard-premium
+      - name: WebSocket
+        href: standard-premium/websocket.md
       - name: Sensitive data protection
         href: standard-premium/sensitive-data-protection.md
       - name: Understand billing