Merge branch 'main' into release-migration-reliability

Author: v-alje

articles/application-gateway/migrate-v1-v2.md

@@ -46,6 +46,9 @@ This article primarily helps with the configuration migration. Client traffic mi
 
 [!INCLUDE [updated-for-az](~/reusable-content/ce-skilling/azure/includes/updated-for-az.md)]
 
+> [!NOTE]
+> If NetworkIsolation is enabled on the subscription, all Application Gateway v2 deployments whether public‑only or  private‑only must be deployed in a subnet delegated to Microsoft.Network/applicationGateways.  Use the following [steps to set up subnet delegation](/azure/virtual-network/manage-subnet-delegation?tabs=manage-subnet-delegation-portal).
+
 ## Configuration migration
 The configuration migration focuses on setting up the new V2 gateway with the settings from your existing V1 environment. We provide two Azure PowerShell scripts designed to facilitate the migration of configurations from V1 (Standard or WAF) to V2 (Standard_V2 or WAF_V2) gateways. These scripts help streamline the transition process by automating key deployment and configuration tasks.
 

articles/application-gateway/retirement-faq.md

@@ -21,33 +21,25 @@ New Customers won't be allowed to create V1 from 1 July 2023 onwards. However, a
 
 ### What happens to existing Application Gateway V1 after 28 April 2026?
 
-Once the deadline arrives V1 gateways aren't supported. Any V1 SKU resources that are still active are stopped, and force deleted.
-
-### What is the definition of a new customer on Application Gateway V1 SKU?
-
-Customers who didn't have Application Gateway V1 SKU in their subscriptions as of 4 July 2023 are considered as new customers. These customers aren't able to create new V1 gateways in subscriptions that didn't have an existing V1 gateway as of 4 July 2023.
-
-### What is the definition of an existing customer on Application Gateway V1 SKU?
-
-Customers who had active or stopped but allocated Application Gateway V1 SKU in their subscriptions as of  4 July 2023, are considered existing customers. These customers get until end of August, 2024 to create new V1 application gateways in their existing subscriptions and until April 28,2026 to migrate their V1 gateways to V2.
+After April 28th 2026, V1 SKU will no longer be supported, and no SLA will be provided for customers using this SKU of Application Gateway. Traffic passing through V1 SKUs after retirement can't be guaranteed as our teams begin the process of cleaning up and decommissioning the hardware that supported V1 SKUs of Application Gateway. 
 
 ### Does this migration plan affect any of my existing workloads that run on Application Gateway V1 SKU?
 
-Until April 28, 2026, existing Application Gateway V1 deployments are supported. After April 28, 2026, any V1 SKU resources that are still active are stopped, and force deleted.
+Until April 28, 2026, existing Application Gateway V1 deployments are supported. After April 28, 2026, any V1 SKU resources that are still active will no longer receive  patches, support, or SLA coverage. Workloads running on V1 will face service disruption, as we'll begin blocking the data path and subsequently deleting the resources. 
 
 ### What happens to my V1 application gateways if I don’t plan on migrating soon?
 
-On April 28, 2026, the V1 gateways are fully retired and all active AppGateway V1s are stopped & deleted. To prevent business impact, we highly recommend starting to plan your migration at the earliest and complete it before April 28, 2026.
+On April 28, 2026, the V1 gateways are fully retired and all active AppGateway V1s will no longer receive  patches, support, or SLA coverage and will face service disruptions. To prevent business impact, we highly recommend starting to plan your migration at the earliest and complete it before April 28, 2026.
 
 ### Does the retirement of Basic SKU Public IPs in September 2025 affect my existing V1 Application Gateways?
 
-While the Basic SKU Public IPs are scheduled for retirement by September 2025, the Basic IP resources linked to Application Gateway V1 deployments will not be impacted until the retirement of V1 Application Gateways. This will be handled by Microsoft and needs no customer intervention.
+While the Basic SKU Public IPs are scheduled for retirement by September 2025, the Basic IP resources linked to Application Gateway V1 deployments wo'nt be impacted until the retirement of V1 Application Gateways. This will be handled by Microsoft and needs no customer intervention.
 
 ### How do I migrate my application gateway V1 to V2 SKU?
 
 If you have an Application Gateway V1, [Migration from v1 to v2](./migrate-v1-v2.md) can be currently done in two stages:
 - Stage 1: Migrate the configuration - Detailed instruction for Migrating the configuration can be found [here](./migrate-v1-v2.md#configuration-migration).
-- Stage 2: Migrate the client traffic -Client traffic migration varies depending on your specific environment. We now have a [powershell script to retain the Public IP from V1 in V2](./migrate-v1-v2.md#public-ip-retention-script).High level guidelines on traffic migration are provided [here](./migrate-v1-v2.md#traffic-migration-recommendations).
+- Stage 2: Migrate the client traffic -Client traffic migration varies depending on your specific environment. We now have a [PowerShell script to retain the Public IP from V1 in V2](./migrate-v1-v2.md#public-ip-retention-script). High level guidelines on traffic migration are provided [here](./migrate-v1-v2.md#traffic-migration-recommendations).
 
 ### Can Microsoft migrate this data for me?
 
@@ -70,9 +62,9 @@ Yes, see [Caveats/Limitations](./migrate-v1-v2.md#caveatslimitations).
 
 ### Does Application Gateway V2 support NTLM or Kerberos authentication?
 
-Yes. Application Gateway v2 now supports proxying requests with NTLM or Kerberos authentication.For more information, see [Dedicated backend connection](configuration-http-settings.md#dedicated-backend-connection).
+Yes. Application Gateway v2 now supports proxying requests with NTLM or Kerberos authentication. For more information, see [Dedicated backend connection](configuration-http-settings.md#dedicated-backend-connection).
 
-### How are backend certificate behaviours different between Application Gateway V1 and V2 SKUs? How should I manage the migration with the differences in behavior of backend certificate validations between V1 and V2 SKUs?
+### How are backend certificate behaviors different between Application Gateway V1 and V2 SKUs? How should I manage the migration with the differences in behavior of backend certificate validations between V1 and V2 SKUs?
 
 Certificate Validation Behavior in Application Gateway
 
@@ -90,19 +82,23 @@ Yes.
 
 ### Does the Azure PowerShell script also switch over the traffic from my v1 gateway to the newly created v2 gateway?
 
-No, the Azure PowerShell script only migrates the configuration. Actual traffic migration is your responsibility and under your control.You can use the [public IP retention script](./migrate-v1-v2.md#public-ip-retention-script) to retain the Public IP from V1 in V2.This operation has a downtime of 1-5 minutes. 
+No, the Azure PowerShell script only migrates the configuration. Actual traffic migration is your responsibility and under your control. You can use the [public IP retention script](./migrate-v1-v2.md#public-ip-retention-script) to retain the Public IP from V1 in V2. This operation has a downtime of 1-5 minutes. 
 
 ### Is the new v2 gateway created by the Azure PowerShell script sized appropriately to handle all of the traffic that is served by my v1 gateway?
 
 The Azure PowerShell script creates a new v2 gateway with an appropriate size to handle the traffic on your existing v1 gateway. Autoscaling is disabled by default, but you can enable autoscaling when you run the script.
 
+### Can I create an Application Gateway V2 in the same subnet as an existing V1 gateway?
+
+No, V1 and V2 gateways can't coexist in the same subnet. Each gateway type requires its own dedicated subnet within the virtual network. If you plan to migrate from V1 to V2, you must create a new subnet for the V2 gateway and ensure sufficient IP address space is allocated.
+
 ### I configured my v1 gateway  to send logs to Azure storage. Does the script replicate this configuration for v2 as well?
 
 No, the script doesn't replicate this configuration for v2. You must add the log configuration separately to the migrated v2 gateway.
 
 ### Does this script support certificate uploaded to Azure Key Vault?
 
-Yes, you can download the certificate from Keyvault and provide it as input to the migration script.The [enchanced cloning script](./migrate-v1-v2.md#1-enhanced-cloning-script) automatically copies all the SSL certs from V1 to the newly created V2.
+Yes, you can download the certificate from Keyvault and provide it as input to the migration script. The [enhanced cloning script](./migrate-v1-v2.md#1-enhanced-cloning-script) automatically copies all the SSL certs from V1 to the newly created V2.
 
 ### I ran into some issues with using this script. How can I get help?
 

articles/application-gateway/v1-retirement.md

@@ -21,7 +21,7 @@ We announced the deprecation of Application Gateway V1 on **April 28 ,2023**. Be
 
 - Deprecation announcement: April 28 ,2023 
 
--	No new subscriptions for V1 deployments: July 1,2023 onwards - Application Gateway V1 is no longer available for deployment on subscriptions without V1 gateways(Refer to [FAQ](./retirement-faq.md#what-is-the-definition-of-a-new-customer-on-application-gateway-v1-sku) for details) from July 1 2023 onwards.
+-	No new subscriptions for V1 deployments: July 1,2023 onwards - Application Gateway V1 is no longer available for deployment on subscriptions without V1 gateways from July 1 2023 onwards.
 
 - No new V1 deployments: Sept 1, 2024 - V1 creation is stopped completely for all customers 1 September 2024 onwards.
 

articles/automation/automation-managing-data.md

@@ -112,7 +112,7 @@ When you delete an Automation account in Azure, all objects in the account are d
 
 ### Runbooks
 
-You can export your runbooks to script files using either the Azure portal or the [Get-AzureAutomationRunbookDefinition](/powershell/module/servicemanagement/azure/get-azureautomationrunbookdefinition) cmdlet in Windows PowerShell. You can import these script files into another Automation account, as discussed in [Manage runbooks in Azure Automation](manage-runbooks.md).
+You can export your runbooks to script files using either the Azure portal or the [Get-AzAutomationRunbookContent](/powershell/module/az.automation/get-azautomationrunbook) cmdlet in Windows PowerShell. You can import these script files into another Automation account, as discussed in [Manage runbooks in Azure Automation](manage-runbooks.md).
 
 ### Integration modules
 

articles/automation/automation-use-azure-ad.md

@@ -57,7 +57,7 @@ You can use the Azure portal to create the credential asset. Do this operation f
 
 ### Create the credential asset with Windows PowerShell
 
-To prepare a new credential asset in Windows PowerShell, your script first creates a `PSCredential` object using the assigned user name and password. The script then uses this object to create the asset through a call to the [New-AzureAutomationCredential](/powershell/module/servicemanagement/azure/new-azureautomationcredential) cmdlet. Alternatively, the script can call the [Get-Credential](/powershell/module/microsoft.powershell.security/get-credential) cmdlet to prompt the user to type in a name and password. See [Credential assets in Azure Automation](shared-resources/credentials.md). 
+To prepare a new credential asset in Windows PowerShell, your script first creates a `PSCredential` object using the assigned user name and password. The script then uses this object to create the asset through a call to the [New-AzAutomationCredential](/powershell/module/az.automation/new-azautomationcredential) cmdlet. Alternatively, the script can call the [Get-Credential](/powershell/module/microsoft.powershell.security/get-credential) cmdlet to prompt the user to type in a name and password. See [Credential assets in Azure Automation](shared-resources/credentials.md). 
 
 
 ## Manage Azure resources from an Azure Automation runbook

articles/automation/runbook-input-parameters.md

@@ -167,7 +167,7 @@ In the label beneath the input box, you can see the properties that have been se
      Start-AzAutomationRunbook -AutomationAccountName "TestAutomation" -Name "Get-AzureVMGraphical" –ResourceGroupName $resourceGroupName -Parameters $params
    ```
 
-* **Azure classic deployment model cmdlets:** You can start an automation runbook that was created in a default resource group by using [Start-AzureAutomationRunbook](/powershell/module/servicemanagement/azure/start-azureautomationrunbook).
+* **Azure classic deployment model cmdlets:** You can start an automation runbook that was created in a default resource group by using `Start-AzureAutomationRunbook`.
 
    ```powershell
      $params = @{"VMName"="WSVMClassic"; "ServiceName"="WSVMClassicSG"}

articles/automation/shared-resources/certificates.md

@@ -29,9 +29,6 @@ The cmdlets in the following table create and manage Automation certificates wit
 |[Remove-AzAutomationCertificate](/powershell/module/Az.Automation/Remove-AzAutomationCertificate)|Removes a certificate from Automation.|
 |[Set-AzAutomationCertificate](/powershell/module/Az.Automation/Set-AzAutomationCertificate)|Sets the properties for an existing certificate, including uploading the certificate file and setting the password for a **.pfx** file.|
 
-The [Add-AzureCertificate](/powershell/module/servicemanagement/azure/add-azureaccount) cmdlet can also be used to upload a service certificate for the specified cloud service.
-
-
 ## Internal cmdlets to access certificates
 
 The internal cmdlet in the following table is used to access certificates in your runbooks. This cmdlet comes with the global module `Orchestrator.AssetManagement.Cmdlets`. For more information, see [Internal cmdlets](modules.md#internal-cmdlets).

articles/automation/shared-resources/credentials.md

@@ -39,7 +39,7 @@ The cmdlets in the following table are used to access credentials in your runboo
 |:--- |:--- |
 | `Get-AutomationPSCredential` |Gets a `PSCredential` object to use in a runbook or DSC configuration. Most often, you should use this [internal cmdlet](modules.md#internal-cmdlets) instead of the `Get-AzAutomationCredential` cmdlet, as the latter only retrieves credential information. This information isn't normally helpful to pass to another cmdlet. |
 | [Get-Credential](/powershell/module/microsoft.powershell.security/get-credential) |Gets a credential with a prompt for user name and password. This cmdlet is part of the default Microsoft.PowerShell.Security module. See [Default modules](modules.md#default-modules).|
-| [New-AzureAutomationCredential](/powershell/module/servicemanagement/azure/new-azureautomationcredential) | Creates a credential asset. This cmdlet is part of the default Azure module. See [Default modules](modules.md#default-modules).|
+| [New-AzAutomationCredential](/powershell/module/az.automation/new-azautomationcredential) | Creates a credential asset. This cmdlet is part of the default Azure module. See [Default modules](modules.md#default-modules).|
 
 To retrieve `PSCredential` objects in your code, you must import the `Orchestrator.AssetManagement.Cmdlets` module. For more information, see [Manage modules in Azure Automation](modules.md).
 
@@ -89,7 +89,7 @@ The following example shows how to create a new Automation credential asset. A `
 $user = "MyDomain\MyUser"
 $pw = ConvertTo-SecureString "PassWord!" -AsPlainText -Force
 $cred = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $user, $pw
-New-AzureAutomationCredential -AutomationAccountName "MyAutomationAccount" -Name "MyCredential" -Value $cred
+New-AzAutomationCredential -ResourceGroupName "MyResourceGroup" -AutomationAccountName "MyAutomationAccount" -Name "MyCredential" -Value $cred
 ```
 
 ## Get a credential asset

articles/azure-functions/flex-consumption-plan.md

@@ -41,6 +41,9 @@ This table helps you directly compare the features of Flex Consumption with the
 
 For a complete comparison of the Flex Consumption plan against the Consumption plan and all other plan and hosting types, see [function scale and hosting options](functions-scale.md).
 
+> [!TIP]
+> If you're migrating from the Linux Consumption plan, see [Migrate Consumption plan apps to the Flex Consumption plan](migration/migrate-plan-consumption-to-flex.md?pivots=platform-linux) for step-by-step migration instructions and important differences between the plans.
+
 ## Virtual network integration
 
 Flex Consumption expands on the traditional benefits of Consumption plan by adding support for [virtual network integration](./functions-networking-options.md#virtual-network-integration). When your apps run in a Flex Consumption plan, they can connect to other Azure services secured inside a virtual network. All while still allowing you to take advantage of serverless billing and scale, together with the scale and throughput benefits of the Flex Consumption plan. For more information, see [Enable virtual network integration](./flex-consumption-how-to.md#enable-virtual-network-integration).
@@ -105,6 +108,9 @@ To learn how to set concurrency limits for HTTP trigger functions, see [Set HTTP
 
 Deployments in the Flex Consumption plan follow a single path, and there's no longer the need for app settings to influence deployment behavior. Your project code is built and zipped into an application package, then deployed to a blob storage container. On startup, your app gets the package and runs your function code from this package. By default, the same storage account used to store internal host metadata (AzureWebJobsStorage) is also used as the deployment container. However, you can use an alternative storage account or choose your preferred authentication method by [configuring your app's deployment settings](flex-consumption-how-to.md#configure-deployment-settings).
 
+> [!TIP]
+> A **Flex Function App deployment details** diagnostic tool is available in the Azure portal. Open your Flex Consumption app, select **Diagnose and solve problems**, and search for `Flex Function App deployment details`. This tool displays detailed information about your deployments, including deployment history, package status, and troubleshooting recommendations.
+
 ### Zero-downtime deployments
 
 > [!NOTE]
@@ -191,6 +197,7 @@ Keep these other considerations in mind when using Flex Consumption plan:
 + **PowerShell Managed dependencies**: Flex Consumption doesn't support [managed dependencies in PowerShell](functions-reference-powershell.md#managed-dependencies-feature). You must instead [upload modules with app content](functions-reference-powershell.md#including-modules-in-app-content).
 + **Certificates**: Loading certificates with the WEBSITE_LOAD_CERTIFICATES app setting, managed certificates, app service certificates, and other platform certificate-based features like endToEndEncryptionEnabled are currently not supported.
 + **Timezones**: `WEBSITE_TIME_ZONE` and `TZ` app settings aren't currently supported when running on Flex Consumption plan.
++ **Azure Functions Runtime Version and Proxies**: Flex Consumption only supports version 4.x and later of the Azure Functions runtime. Azure Functions proxies was a feature of versions 1.x through 3.x of the Azure Functions runtime and is not available in Flex Consumption.
 
 ## Related articles
 

articles/azure-functions/functions-bindings-dapr-input-secret.md

@@ -3,6 +3,9 @@ title: Dapr Secret input binding for Azure Functions
 description: Learn how to access Dapr Secret input binding data during function execution in Azure Functions.
 ms.topic: reference
 ms.date: 05/10/2024
+ms.author: nigreenf
+ms.reviewer: hannahhunter
+ms.subservice: dapr
 ms.devlang: csharp
 # ms.devlang: csharp, java, javascript, powershell, python
 ms.custom: devx-track-csharp, devx-track-python, devx-track-dotnet, devx-track-extended-java, devx-track-js, build-2024