Merge pull request #251275 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/active-directory/app-provisioning/inbound-provisioning-api-issues.md

@@ -40,10 +40,13 @@ This document covers commonly encountered errors and issues with inbound provisi
 
 **Probable causes**
 1. Your API-driven provisioning app is paused. 
-1. The provisioning service is yet to update the provisioning logs with the bulk request processing details. 
+1. The provisioning service is yet to update the provisioning logs with the bulk request processing details.
+2. Your On-premises provisioning agent status is inactive (If you are running the [/API-driven inbound user provisioning to on-premises Active Directory](https://go.microsoft.com/fwlink/?linkid=2245182)).
+
 
 **Resolution:**
 1. Verify that your provisioning app is running. If it isn't running, select the menu option **Start provisioning** to process the data.
+2. Turn your On-premises provisioning agent status to active by restarting the On-premise agent.
 1. Expect 5 to 10-minute delay between processing the request and writing to the provisioning logs. If your API client is sending data to the provisioning /bulkUpload API endpoint, then introduce a time delay between the request invocation and provisioning logs query. 
 
 ### Forbidden 403 response code 

articles/azure-monitor/app/opentelemetry-enable.md

@@ -43,7 +43,7 @@ Follow the steps in this section to instrument your application with OpenTelemet
 
 ### [ASP.NET Core](#tab/aspnetcore)
 
-- Application using an officially supported version of [.NET Core](https://dotnet.microsoft.com/download/dotnet) or [.NET Framework](https://dotnet.microsoft.com/download/dotnet-framework) that's at least .NET Framework 4.6.2
+- [ASP.NET Core Application](/aspnet/core/introduction-to-aspnet-core) using an officially supported version of [.NET Core](https://dotnet.microsoft.com/download/dotnet)
 
 ### [.NET](#tab/net)
 

articles/load-balancer/load-balancer-custom-probe-overview.md

@@ -26,7 +26,7 @@ Health probes have the following properties:
 
 | Health Probe property name | Details|
 | --- | --- | 
-| Name | Name of the health probe. This is a naame you get to define for your health probe |
+| Name | Name of the health probe. This is a name you get to define for your health probe |
 | Protocol | Protocol of health probe. This is the protocol type you would like the health probe to leverage. Options are: TCP, HTTP, HTTPS |
 | Port | Port of the health probe. The destination port you would like the health probe to use when it connects to the virtual machine to check it's health |
 | Interval (seconds) | Interval of health probe. The amount of time (in seconds) between different probe two consecutive health check attemps to the virtual machine |
@@ -63,7 +63,7 @@ The protocol used by the health probe can be configured to one of the following
 
 ## Probe interval
 
-The interval value determines how frequently the health probe checks for a response from your backend pool instances. If the health probe fails, your backend pool instances are immediately marked as unhealthy. If the health probe succeeds on the next healthy probe up, Azure Load Balancer marks your backend pool instances as healthy. The health probe attempts to check the configured health probe port every 15 seconds by default but can be explicitly set to another value.
+The interval value determines how frequently the health probe checks for a response from your backend pool instances. If the health probe fails, your backend pool instances are immediately marked as unhealthy. If the health probe succeeds on the next healthy probe up, Azure Load Balancer marks your backend pool instances as healthy. The health probe attempts to check the configured health probe port every 5 seconds by default but can be explicitly set to another value.
 
 It is important to note that probes also have a timeout period. For example, if a health probe interval is set to 15 seconds, the total time it takes for your health probe to reflect your application would be 20 seconds (interval + timeout period). Assume the reaction to a timeout response takes a minimum of 5 seconds and a maximum of 10 seconds to react to the change. This example is provided to illustrate what is taking place. 
 

articles/managed-grafana/how-to-sync-teams-with-aad-groups.md

@@ -12,7 +12,7 @@ ms.date: 9/11/2023
 
 In this guide, you learn how to use Azure Active Directory (Azure AD) groups with [Grafana Team Sync](https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-team-sync/) (Azure AD group sync) to set dashboard permissions in Azure Managed Grafana. Grafana allows you to control access to its resources at multiple levels. In Managed Grafana, you use the built-in Azure RBAC roles for Grafana to define access rights users have. These permissions are applied to all resources in your Grafana workspace by default. You can't, for example, grant someone edit permission to only one particular dashboard with RBAC. If you assign a user to the Grafana Editor role, that user can make changes to any dashboard in your Grafana workspace. Using Grafana's [granular permission model](https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-team-sync/), you can elevate or demote a user's default permission level for specific dashboards (or dashboard folders).
 
-Setting up dashboard permissions for individual users in Managed Grafana is a little tricky. Managed Grafana stores the user assignments for its built-in RBAC roles in Azure AD. For performance reasons, it doesn't automatically synchronizes the user assignments to Grafana workspaces. Users in these roles don't show up in Grafana's  **Configuration** UI until they've signed in once. You can only grant users extra permissions after they appear in the Grafana user list in **Configuration**. Azure AD group sync gets around this issue. With this feature, you create a *Grafana team* in your Grafana workspace linked with an Azure AD group. You then use that team in configuring your dashboard permissions. For example, you can grant a viewer the ability to modify a dashboard or block an editor from being able to make changes. You don't need to manage the team's member list separately since its membership is already defined in the associated Azure AD group.
+Setting up dashboard permissions for individual users in Managed Grafana is a little tricky. Managed Grafana stores the user assignments for its built-in RBAC roles in Azure AD. For performance reasons, it doesn't automatically synchronize the user assignments to Grafana workspaces. Users in these roles don't show up in Grafana's **Configuration** UI until they've signed in once. You can only grant users extra permissions after they appear in the Grafana user list in **Configuration**. Azure AD group sync gets around this issue. With this feature, you create a *Grafana team* in your Grafana workspace linked with an Azure AD group. You then use that team in configuring your dashboard permissions. For example, you can grant a viewer the ability to modify a dashboard or block an editor from being able to make changes. You don't need to manage the team's member list separately since its membership is already defined in the associated Azure AD group.
 
 > [!IMPORTANT]
 > Azure AD group sync is currently in preview. See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

articles/mysql/flexible-server/concepts-maintenance.md

@@ -43,10 +43,35 @@ You can define system-managed schedule or custom schedule for each flexible serv
 * With custom schedule, you can specify your maintenance window for the server by choosing the day of the week and a one-hour time window.
 * With system-managed schedule, the system will pick any one-hour window between 11pm and 7am in your server's region time.
 
-As part of rolling out changes, we apply the updates to the servers configured with system-managed schedule first followed by servers with custom schedule after a minimum gap of 7-days within a given region. If you intend to receive early updates on fleet of development and test environment servers, we recommend you configure system-managed schedule for servers used in development and test environment. This will allow you to receive the latest update first in your Dev/Test environment for testing and evaluation for validation. If you encounter any behavior or breaking changes, you will have time to address them before the same update is rolled out to production servers with custom-managed schedule. The update starts to roll out on custom-schedule flexible servers after 7 days and is applied to your server at the defined maintenance window. At this time, there is no option to defer the update after the notification has been sent. Custom-schedule is recommended for production environments only.
+> [!IMPORTANT]
+> Previously, a 7-day deployment gap between system-managed and custom-managed schedules was maintained. Due to evolving maintenance demands and the introduction of the [maintenance reschedule feature (preview)](#maintenance-reschedule-preview), we can no longer guarantee this 7-day gap.
 
 In rare cases, maintenance event can be canceled by the system or may fail to complete successfully. If the update fails, the update will be reverted, and the previous version of the binaries is restored. In such failed update scenarios, you may still experience restart of the server during the maintenance window. If the update is canceled or failed, the system will create a notification about canceled or failed maintenance event respectively notifying you. The next attempt to perform maintenance will be scheduled as per your current scheduling settings and you will receive notification about it five days in advance.
 
+## Maintenance reschedule (preview)
+
+> [!IMPORTANT]
+> The maintenance reschedule feature is currently in preview. It is subject to limitations and ongoing development. We value your feedback to help enhance this feature. Please note that this feature is not available for servers using the burstable SKU.
+
+The **maintenance reschedule** feature grants you greater control over the timing of maintenance activities on your Azure MySQL - Flexible server. After receiving a maintenance notification, you can reschedule it to a more convenient time, irrespective of whether it was system or custom managed.
+
+### Reschedule parameters and notifications
+
+Rescheduling isn't confined to fixed time slots; it depends on the earliest and latest permissible times in the current maintenance cycle. Upon rescheduling, a notification will be sent out to confirm the changes, following the standard notification policies.
+
+### Considerations and limitations
+
+Be aware of the following when using this feature:
+
+- **Demand Constraints:** Your rescheduled maintenance might be canceled due to a high number of maintenance activities occurring simultaneously in the same region.
+- **Lock-in Period:** Rescheduling is unavailable 15 minutes prior to the initially scheduled maintenance time to maintain the reliability of the service.
+
+> [!NOTE]
+> We recommend monitoring notifications closely during the preview stage to accommodate potential adjustments.
+
+Use this feature to avoid disruptions during critical database operations. We encourage your feedback as we continue to develop this functionality.
+
+
 ## Next steps
 
 * Learn how to [change the maintenance schedule](how-to-maintenance-portal.md)

articles/sap/center-sap-solutions/get-sap-installation-media.md

@@ -186,7 +186,7 @@ Next, download the SAP installation media to the VM using a script.
 
 1. Where `playbook_bom_downloader_yaml_path` is the absolute path to sap-automation/deploy/ansible/playbook_bom_downloader.yaml. e.g. */home/loggedinusername/sap-automation/deploy/ansible/playbook_bom_downloader.yaml*
 
-1. For `<bom_base_name>`, use the SAP Version you want to install i.e. **_S41909SPS03_v0011ms_** or **_S42020SPS03_v0003ms_** or **_S4HANA_2021_ISS_v0001ms_** or **_S42022_SPS00_v0001ms_**
+1. For `<bom_base_name>`, use the SAP Version you want to install i.e. **_S41909SPS03_v0011ms_** or **_S42020SPS03_v0003ms_** or **_S4HANA_2021_ISS_v0001ms_** or **_S42022SPS00_v0001ms_**
 
 1. For `<s_user>`, use your SAP username.
 
@@ -278,7 +278,7 @@ First, set up an Azure Storage account for the SAP components:
 
         1. **HANA_2_00_071_v0001ms**
 
-        1. **S42022_SPS00_v0001ms**
+        1. **S42022SPS00_v0001ms**
 
         1. **SWPM20SP15_latest**
 

articles/service-bus-messaging/service-bus-outages-disasters.md

@@ -30,10 +30,7 @@ When you use availability zones, **both metadata and data (messages)** are repli
 > [!NOTE]
 > The availability zones support for the premium tier is only available in [Azure regions](../availability-zones/az-region.md) where availability zones are present.
 
-You can enable availability zones on new namespaces only, using the Azure portal. Service Bus doesn't support migration of existing namespaces. You can't disable zone redundancy after enabling it on your namespace.
-
-![1][]
-
+When you create a premium tier namespace, the support for availability zones (if available in the selected region) is automatically enabled for the namespace. There's no additional cost for using this feature and you can't disable or enable this feature.
 
 ## Protection against outages and disasters - standard tier
 To achieve resilience against datacenter outages when using the standard messaging pricing tier, Service Bus supports two approaches: **active** and **passive** replication. For each approach, if a given queue or topic must remain accessible in the presence of a datacenter outage, you can create it in both namespaces. Both entities can have the same name. For example, a primary queue can be reached under **contosoPrimary.servicebus.windows.net/myQueue**, while its secondary counterpart can be reached under **contosoSecondary.servicebus.windows.net/myQueue**.

articles/virtual-network/ip-services/remove-public-ip-address-vm.md

@@ -52,7 +52,7 @@ az network nic ip-config update \
  --name ipconfigmyVM \
  --resource-group myResourceGroup \
  --nic-name myVMNic \
- --public-ip-address ''
+ --public-ip-address null
 ```
 
 - If you don't know the name of the network interface attached to your VM, use the [az vm nic list](/cli/azure/vm/nic#az-vm-nic-list) command to view them. For example, the following command lists the names of the network interfaces attached to a VM named *myVM* in a resource group named *myResourceGroup*:

includes/container-registry-scanning-limitation.md

@@ -15,6 +15,6 @@ ms.custom: include file
 > Some functionality may be unavailable or require more configuration in a container registry that restricts access to private endpoints, selected subnets, or IP addresses.
 >
 > * When public network access to a registry is disabled, registry access by certain [trusted services](../articles/container-registry/allow-access-trusted-services.md) including Azure Security Center requires enabling a network setting to bypass the network rules.
-> * Once the public network access is disabled, Instances of certain Azure services including Azure DevOps Services are currently unable to access the container registry. 
+> * Once the public network access is disabled, instances of certain Azure services including Azure DevOps Services are currently unable to access the container registry. 
 > * Private endpoints are not currently supported with Azure DevOps managed agents. You will need to use a self-hosted agent with network line of sight to the private endpoint. 
 > * If the registry has an approved private endpoint and public network access is disabled, repositories and tags can't be listed outside the virtual network using the Azure portal, Azure CLI, or other tools.