Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into HOBO

Author: MekaylaMoore

.openpublishing.redirection.json

@@ -6958,6 +6958,11 @@
       "source_path": "articles/signups/startup-programs.md",
       "redirect_url": "/azure/signups/overview",
       "redirect_document_id": false
+    },
+    {
+      "source_path": "articles/reliability/migrate-sql-database.md",
+      "redirect_url": "/azure/azure-sql/database/enable-zone-redundancy",
+      "redirect_document_id": false
     }
 
   ]

articles/application-gateway/overview-v2.md

@@ -24,7 +24,7 @@ The v2 SKU includes the following enhancements:
 
 - **TCP/TLS proxy (Preview)**: Azure Application Gateway now also supports Layer 4 (TCP protocol) and TLS (Transport Layer Security) proxying. This feature is currently in public preview. For more information, see [Application Gateway TCP/TLS proxy overview](tcp-tls-proxy-overview.md).
 - **Autoscaling**: Application Gateway or WAF deployments under the autoscaling SKU can scale out or in based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning. This SKU offers true elasticity. In the Standard_v2 and WAF_v2 SKU, Application Gateway can operate both in fixed capacity (autoscaling disabled) and in autoscaling enabled mode. Fixed capacity mode is useful for scenarios with consistent and predictable workloads. Autoscaling mode is beneficial in applications that see variance in application traffic.
-- **Zone redundancy**: An Application Gateway or WAF deployment can span multiple Availability Zones, removing the need to provision separate Application Gateway instances in each zone with a Traffic Manager. You can choose a single zone or multiple zones where Application Gateway instances are deployed, which makes it more resilient to zone failure. The backend pool for applications can be similarly distributed across availability zones.
+- **Zone redundancy**: Application Gateway or WAF deployments span multiple Availability Zones by default, removing the need to provision separate Application Gateway instances in each zone with a Traffic Manager. Application Gateway instances are deployed (by default) in a minimum of two availability zones, which makes it more resilient to zone failure. The backend pool for applications can be similarly distributed across availability zones.
 
   Zone redundancy is available only where Azure availability zones are available. In other regions, all other features are supported. For more information, see [Azure regions with availability zone support](../reliability/availability-zones-region-support.md).
 - **Static VIP**: Application Gateway v2 SKU supports the static VIP type exclusively. Static VIP ensures that the VIP associated with the application gateway doesn't change for the lifecycle of the deployment, even after a restart. You must use the application gateway URL for domain name routing to App Services via the application gateway, as v1 doesn't have a static VIP.

articles/automation/automation-hrw-run-runbooks.md

@@ -3,7 +3,7 @@ title: Run Azure Automation Runbooks on a Hybrid Runbook Worker
 description: This article describes how to run runbooks on machines in your local datacenter or other cloud provider with the Hybrid Runbook Worker.
 services: automation
 ms.subservice: process-automation
-ms.date: 07/22/2025
+ms.date: 07/29/2025
 ms.topic: how-to
 ms.custom: devx-track-azurepowershell, linux-related-content
 ms.service: azure-automation
@@ -14,7 +14,7 @@ author: jasminemehndir
 # Run Automation runbooks on a Hybrid Runbook Worker
 
 
-> [!Important]
+> [!IMPORTANT]
 > - Starting 1st April 2025, all jobs running on agent-based Hybrid Worker will be stopped. 
 > - Azure Automation Agent-based User Hybrid Runbook Worker (Windows and Linux) has retired on **31 August 2024** and is no longer supported. Follow the guidelines on how to [migrate from an existing Agent-based User Hybrid Runbook Workers to Extension-based Hybrid Workers](migrate-existing-agent-based-hybrid-worker-to-extension-based-workers.md).
 
@@ -41,8 +41,9 @@ Azure Automation handles jobs on Hybrid Runbook Workers differently from jobs ru
 Jobs for Hybrid Runbook Workers run under the local **System** account.
 
 > [!NOTE]
->- PowerShell 5.1, PowerShell 7.1(preview), Python 2.7, and Python 3.8 runbooks are supported on both extension-based and agent-based Windows Hybrid Runbook Workers. For agent based workers, ensure the Windows Hybrid worker version is 7.3.12960 or above.
->- PowerShell 7.2 and Python 3.10 (preview) runbooks are supported on extension-based Windows Hybrid Workers only. Ensure the Windows Hybrid worker extension version is 1.1.11 or above.
+>- PowerShell 7.4 and Python 3.10 runbooks are supported on extension-based Windows Hybrid Workers only. Ensure the Windows Hybrid worker extension version is 1.3.63 or above.
+>- PowerShell 5.1, PowerShell 7.1 (preview), Python 2.7, and Python 3.8 runbooks are supported on both extension-based and agent-based Windows Hybrid Runbook Workers. For agent based workers, ensure the Windows Hybrid worker version is 7.3.12960 or above.
+>- PowerShell 7.2 runbook is supported on extension-based Windows Hybrid Workers only. Ensure the Windows Hybrid worker extension version is 1.1.11 or above.
 
 #### Extension-based Hybrid Workers
 
@@ -94,8 +95,9 @@ If the *Python* executable file is at the default location *C:\Python27\python.e
 ### Linux Hybrid Worker
 
 > [!NOTE]
->- PowerShell 5.1, PowerShell 7.1(preview), Python 2.7, Python 3.8 runbooks are supported on both extension-based and agent-based Linux Hybrid Runbook Workers. For agent-based workers, ensure the Linux Hybrid Runbook worker version is 1.7.5.0 or above.
->- PowerShell 7.2 and Python 3.10 (preview) runbooks are supported on extension-based Linux Hybrid Workers only. Ensure the Linux Hybrid worker extension version is 1.1.11 or above.
+>- PowerShell 7.4 and Python 3.10 runbooks are supported on extension-based Linux Hybrid Workers only. Ensure the Linux Hybrid worker extension version is 1.1.23 or above.
+>- PowerShell 5.1, PowerShell 7.1 (preview), Python 2.7, Python 3.8 runbooks are supported on both extension-based and agent-based Linux Hybrid Runbook Workers. For agent-based workers, ensure the Linux Hybrid Runbook worker version is 1.7.5.0 or above.
+>- PowerShell 7.2 runbook is supported on extension-based Linux Hybrid Workers only. Ensure the Linux Hybrid worker extension version is 1.1.11 or above.
 
 #### Extension-based Hybrid Workers
 
@@ -286,7 +288,7 @@ By default, the Hybrid jobs run under the context of System account. However, to
 1. Select **Hybrid Worker Groups**, and then select the specific group.
 1. Select **Settings**.
 1. Change the value of **Hybrid Worker credentials** from **Default** to **Custom**.
-1. Select the credential and click **Save**.
+1. Select the credential and select **Save**.
 1. If the following permissions are not assigned for Custom users, jobs might get suspended.
 
   | **Resource type** | **Folder permissions** |

articles/azure-app-configuration/TOC.yml

@@ -200,6 +200,8 @@
       href: howto-feature-filters-javascript.md
     - name: Python
       href: howto-feature-filters-python.md
+    - name: Go Gin
+      href: howto-feature-filters-go.md
   - name: Enable features on a schedule
     items:
     - name: Overview
@@ -208,6 +210,8 @@
       href: howto-timewindow-filter-aspnet-core.md
     - name: JavaScript
       href: howto-timewindow-filter-javascript.md
+    - name: Go Gin
+      href: howto-timewindow-filter-go.md
     - name: Python
       href: howto-time-window-filter-python.md
   - name: Roll out features to targeted audience

articles/azure-app-configuration/concept-feature-management.md

@@ -96,6 +96,12 @@ To start using feature flags with Azure App Configuration, continue to the follo
 > [!div class="nextstepaction"]
 > [JavaScript](./quickstart-feature-flag-javascript.md)
 
+> [!div class="nextstepaction"]
+> [Go](./quickstart-feature-flag-go-console.md)
+
+> [!div class="nextstepaction"]
+> [Go Gin](./quickstart-feature-flag-go-gin.md)
+
 > [!div class="nextstepaction"]
 > [Azure Kubernetes Service](./quickstart-feature-flag-azure-kubernetes-service.md)
 

articles/azure-app-configuration/howto-feature-filters-go.md

@@ -0,0 +1,124 @@
+---
+title: Enable conditional features with a custom filter in a Go Gin web application
+titleSuffix: Azure App Configuration
+description: Learn how to implement a custom feature filter to enable conditional feature flags for your Go Gin web application.
+ms.service: azure-app-configuration
+ms.devlang: golang
+author: linglingye
+ms.author: linglingye
+ms.topic: how-to
+ms.custom: devx-track-go, mode-other
+ms.date: 07/25/2025
+---
+
+# Enable conditional features with a custom filter in a Go Gin web application
+
+Feature flags can use feature filters to enable features conditionally. To learn more about feature filters, see [Enable conditional features with feature filters](./howto-feature-filters.md).
+
+The example used in this guide is based on the Go Gin web application introduced in the feature management [quickstart](./quickstart-feature-flag-go-gin.md). Before proceeding further, complete the quickstart to create a Go Gin web application with a *Beta* feature flag. Once completed, you must [add a custom feature filter](./howto-feature-filters.md) to the *Beta* feature flag in your App Configuration store. 
+
+In this guide, you learn how to implement a custom feature filter and use the feature filter to enable features conditionally.
+
+## Prerequisites
+
+- Create a [Go Gin web application with a feature flag](./quickstart-feature-flag-go-gin.md).
+- [Add a custom feature filter to the feature flag](./howto-feature-filters.md)
+
+## Implement a custom feature filter
+
+You added a custom feature filter named **Random** with a **Percentage** parameter for your *Beta* feature flag in the prerequisites. Next, you'll implement the feature filter to enable the *Beta* feature flag based on the chance defined by the **Percentage** parameter.
+
+1. Create a `random_filter.go` file with the following code:
+
+    ```golang
+    package main
+
+    import (
+        "fmt"
+        "math/rand"
+        "time"
+
+        "github.com/microsoft/Featuremanagement-Go/featuremanagement"
+    )
+
+    type RandomFilter struct{}
+
+    func (f *RandomFilter) Name() string {
+        return "Random"
+    }
+
+    func (f *RandomFilter) Evaluate(evalCtx featuremanagement.FeatureFilterEvaluationContext, appCtx any) (bool, error) {
+        percentage, ok := evalCtx.Parameters["Percentage"].(float64)
+        if !ok {
+            return false, fmt.Errorf("invalid parameter type for Percentage: expected float64, got %T", evalCtx.Parameters["Percentage"])
+        }
+
+        rand.Seed(time.Now().UnixNano())
+        randomValue := rand.Intn(100)
+        return randomValue <= int(percentage), nil
+    }
+    ```
+
+    You added a `RandomFilter` struct that implements the `FeatureFilter` interface from the `featuremanagement` library. The `FeatureFilter` interface has two methods:
+    - `Name()` returns the filter name **Random**, which matches the filter name you set in the *Beta* feature flag in Azure App Configuration.
+    - `Evaluate()` is called whenever a feature flag is evaluated. A feature filter enables a feature flag by returning `true`.
+
+2. Update your `main.go` file to register the `RandomFilter` when creating the feature manager:
+
+    ```golang
+    // ...existing code...
+
+    func main() {
+        ctx := context.Background()
+
+        // Load Azure App Configuration
+        appConfig, err := loadAzureAppConfiguration(ctx)
+        if err != nil {
+            log.Fatalf("Error loading Azure App Configuration: %v", err)
+        }
+
+        // Create feature flag provider
+        featureFlagProvider, err := azappconfig.NewFeatureFlagProvider(appConfig)
+        if err != nil {
+            log.Fatalf("Error creating feature flag provider: %v", err)
+        }
+
+        // Register custom filters
+        options := &featuremanagement.Options{
+            Filters: []featuremanagement.FeatureFilter{
+                &RandomFilter{},
+            },
+        }
+
+        // Create feature manager with custom filters
+        featureManager, err := featuremanagement.NewFeatureManager(featureFlagProvider, options)
+        if err != nil {
+            log.Fatalf("Error creating feature manager: %v", err)
+        }
+
+        // ...existing code...
+    }
+    ```
+
+## Feature filter in action
+
+Relaunch the application and refresh the browser a few times. Without manually toggling the feature flag, the **Beta** menu appears randomly based on the percentage you set.
+
+:::image type="content" source="./media/quickstarts/gin-app-feature-flag-before.png" alt-text="Screenshot of Gin web app with Beta menu hidden.":::
+
+:::image type="content" source="./media/quickstarts/gin-app-feature-flag-after.png" alt-text="Screenshot of Gin web app with Beta menu.":::
+
+## Next steps
+
+To learn more about the built-in feature filters, continue to the following documents.
+
+> [!div class="nextstepaction"]
+> [Enable features on a schedule](./howto-timewindow-filter.md)
+
+> [!div class="nextstepaction"]
+> [Roll out features to targeted audience](./howto-targetingfilter.md)
+
+For the full feature rundown of the Go feature management library, continue to the following document.
+
+> [!div class="nextstepaction"]
+> [Go Feature Management reference](https://pkg.go.dev/github.com/microsoft/Featuremanagement-Go/featuremanagement)

articles/azure-app-configuration/howto-feature-filters.md

@@ -62,6 +62,7 @@ You can create custom feature filters that enable features based on your specifi
     - [ASP.NET Core](./howto-feature-filters-aspnet-core.md)
     - [Node.js](./howto-feature-filters-javascript.md)
     - [Python](./howto-feature-filters-python.md)
+    - [Go Gin](./howto-feature-filters-go.md)
 
 ## Next steps
 

articles/azure-app-configuration/howto-timewindow-filter-go.md

@@ -0,0 +1,88 @@
+---
+title: Enable features on a schedule in a Go Gin web application
+titleSuffix: Azure App Configuration
+description: Learn how to enable feature flags on a schedule in a Go Gin web application by using time window filters.
+ms.service: azure-app-configuration
+ms.devlang: golang
+author: linglingye
+ms.author: linglingye
+ms.topic: how-to
+ms.custom: devx-track-go, mode-other
+ms.date: 07/25/2025
+---
+
+# Enable features on a schedule in a Go Gin web application
+
+In this guide, you use the time window filter to enable a feature on a schedule for a Go Gin web application. 
+
+The example used in this article is based on the Go Gin web application introduced in the feature management [quickstart](./quickstart-feature-flag-go-gin.md). Before proceeding further, complete the quickstart to create a Go Gin web application with a *Beta* feature flag. Once completed, you must [add a time window filter](./howto-timewindow-filter.md) to the *Beta* feature flag in your App Configuration store.
+
+## Prerequisites
+
+- Create a [Go Gin web application with a feature flag](./quickstart-feature-flag-go-gin.md).
+- [Add a time window filter to the feature flag](./howto-timewindow-filter.md)
+
+## Use the time window filter
+
+You added a time window filter for your *Beta* feature flag in the prerequisites. Next, you'll use the feature flag with the time window filter in your Go Gin web application.
+
+When you create a feature manager, the built-in feature filters are automatically added to its feature filter collection
+
+The existing code from the quickstart already handles time window filters through the feature manager:
+
+```golang
+// Create feature flag provider
+featureFlagProvider, err := azappconfig.NewFeatureFlagProvider(appConfig)
+if err != nil {
+    log.Fatalf("Error creating feature flag provider: %v", err)
+}
+
+// Create feature manager (supports built-in filters including TimeWindowFilter)
+featureManager, err := featuremanagement.NewFeatureManager(featureFlagProvider, nil)
+if err != nil {
+    log.Fatalf("Error creating feature manager: %v", err)
+}
+```
+
+The feature evaluation in your middleware will now respect the time window filter:
+
+```golang
+func (app *WebApp) featureMiddleware() gin.HandlerFunc {
+    return func(c *gin.Context) {
+        // Check if Beta feature is enabled (TimeWindowFilter is automatically evaluated)
+        betaEnabled, err := app.featureManager.IsEnabled("Beta")
+        if err != nil {
+            log.Printf("Error checking Beta feature: %v", err)
+        }
+
+        // Store feature flag status for use in templates
+        c.Set("betaEnabled", betaEnabled)
+        c.Next()
+    }
+}
+```
+
+## Time window filter in action
+
+Relaunch the application. If your current time is earlier than the start time set for the time window filter, the **Beta** menu item won't appear on the toolbar. This is because the *Beta* feature flag is disabled by the time window filter.
+
+:::image type="content" source="./media/quickstarts/gin-app-feature-flag-before.png" alt-text="Screenshot of Gin web app with Beta menu hidden.":::
+
+Once the start time has passed, refresh your browser a few times. You'll notice that the **Beta** menu item now appears. This is because the *Beta* feature flag is now enabled by the time window filter.
+
+:::image type="content" source="./media/quickstarts/gin-app-feature-flag-after.png" alt-text="Screenshot of Gin web app with Beta menu.":::
+
+## Next steps
+
+To learn more about the feature filters, continue to the following documents.
+
+> [!div class="nextstepaction"]
+> [Enable conditional features with feature filters](./howto-feature-filters.md)
+
+> [!div class="nextstepaction"]
+> [Roll out features to targeted audience](./howto-targetingfilter.md)
+
+For the full feature rundown of the Go feature management library, continue to the following document.
+
+> [!div class="nextstepaction"]
+> [Go Feature Management reference](https://pkg.go.dev/github.com/microsoft/Featuremanagement-Go/featuremanagement)

articles/azure-app-configuration/howto-timewindow-filter.md

@@ -58,6 +58,7 @@ In this article, you learn how to add and configure a time window filter for you
 
     - [ASP.NET Core](./howto-timewindow-filter-aspnet-core.md)
     - [JavaScript](./howto-timewindow-filter-javascript.md)
+    - [Go Gin](./howto-timewindow-filter-go.md)
     - [Python](./howto-time-window-filter-python.md)
 
 ## Next steps

articles/azure-functions/functions-bindings-mcp-trigger.md

@@ -421,6 +421,8 @@ In both cases, you must include a call to `builder.EnableMcpToolMetadata()` in y
 ```csharp
 var builder = FunctionsApplication.CreateBuilder(args);
 
+builder.ConfigureFunctionsWebApplication();
+
 builder.EnableMcpToolMetadata();
 
 // other configuration
@@ -449,6 +451,8 @@ You can define one or more tool properties in your entry point (`Program.cs`) fi
 ```csharp
 var builder = FunctionsApplication.CreateBuilder(args);
 
+builder.ConfigureFunctionsWebApplication();
+
 builder.EnableMcpToolMetadata();
 
 builder