Merge pull request #8869 from MicrosoftDocs/main

Auto push to live 2025-05-06 10:02:07

Author: Deland-Han

.github/workflows/manage_stale_branches.yml

@@ -2,6 +2,7 @@ name: Manage stale branches
 
 permissions:
   contents: write
+  pull-requests: read
 
 on:
   workflow_dispatch:
@@ -19,4 +20,4 @@ jobs:
                              ]'
         ReportOnly: false
     secrets:
-        AccessToken: ${{ secrets.GITHUB_TOKEN }}
+        AccessToken: ${{ secrets.GITHUB_TOKEN }}

support/azure/azure-kubernetes/availability-performance/node-not-ready-then-recovers.md

@@ -29,7 +29,7 @@ To resolve this issue, follow these steps:
 1. Run `kubectl describe node <node-name>` to review detail information about the node's status. Look for any error messages or warnings that might indicate the root cause of the issue.
 2. Check the API server availability by running the `kubectl get apiservices` command. Make sure that the readiness probe is correctly configured in the deployment YAML file.
 3. Verify the node's network configuration to make sure that there are no connectivity issues.
-4. Check the node's resource usage, such as CPU, memory, and disk, to identify potential constraints. For more informations see [Monitor your Kubernetes cluster performance with Container insights](/azure/azure-monitor/containers/container-insights-analyze#view-performance-directly-from-a-cluster)
+4. Check the node's resource usage, such as CPU, memory, and disk, to identify potential constraints. For more information, see [Monitor your Kubernetes cluster performance with Container insights](/azure/azure-monitor/containers/container-insights-analyze#view-performance-directly-from-a-cluster).
 
 For further steps, see [Basic troubleshooting of Node Not Ready failures](node-not-ready-basic-troubleshooting.md).
 

support/azure/azure-kubernetes/create-upgrade-delete/aks-memory-saturation-after-upgrade.md

@@ -1,9 +1,9 @@
 ---
 title: Memory saturation occurs after upgrade to Kubernetes 1.25
 description: Resolve pod failures caused by memory saturation and out-of-memory errors after you upgrade an Azure Kubernetes Service (AKS) cluster to Kubernetes 1.25.x.
-ms.date: 06/14/2023
+ms.date: 05/06/2025
 editor: v-jsitser
-ms.reviewer: aritraghosh, cssakscic, v-leedennis
+ms.reviewer: aritraghosh, cssakscic, v-leedennis, momajed
 ms.service: azure-kubernetes-service
 ms.custom: sap:Create, Upgrade, Scale and Delete operations (cluster or nodepool)
 ---
@@ -34,13 +34,49 @@ Performance degradation can occur in apps that run in the following environments
 
 ## Solution
 
+> [!NOTE]  
+> If you only experience increased memory usage and no other symptoms that are mentioned in the [Symptoms](#symptoms) section, no action is needed.
+
 Beginning in the release of Kubernetes 1.25, the [cgroup version 2 API](https://kubernetes.io/blog/2022/08/31/cgroupv2-ga-1-25/) has reached general availability (GA). AKS now uses Ubuntu Linux version 22.04. By default, version 22.04 uses cgroup version 2 API. To make sure the cgroup version 2 API is available for use in other environments to prevent the memory saturation issue, follow this guidance:
 
 - If you run Java applications, [upgrade to a Java version that supports cgroup version 2](https://kubernetes.io/blog/2022/08/31/cgroupv2-ga-1-25/#migrate-to-cgroup-v2) and follow the guidance in [Containerize your Java applications](/azure/developer/java/containers/overview). You might be able to update the base image in certain versions in which the fix has been backported. Use a version or framework that natively supports cgroup version 2. For Azure customers, Microsoft officially supports [Eclipse Temurin](https://adoptium.net/) binaries (Java 8) and [Microsoft Build of OpenJDK](https://www.microsoft.com/openjdk) binaries (Java 11+).
 
 - Similarly, if you're using .NET, upgrade to [.NET version 5.0](https://devblogs.microsoft.com/dotnet/announcing-net-5-0/#containers) or a later version.
 
-In addition, to enable pods to use more resources, increase their memory requests and limits.
+- If you see a higher eviction rate on the pods, [use higher limits and requests for the pods](/azure/aks/developer-best-practices-resource-management#define-pod-resource-requests-and-limits).
+
+- `cgroup` v2 uses a different API than `cgroup` v1. If there are any applications that directly access the `cgroup` file system, update them to later versions that support `cgroup` v2. For example:
+
+  - **Third-party monitoring and security agents**:
+
+     Some monitoring and security agents depend on the `cgroup` file system. Update these agents to versions that support `cgroup` v2.
+
+  - **Java applications**:
+
+     Use versions that fully support `cgroup` v2:
+    - OpenJDK/HotSpot: `jdk8u372`, `11.0.16`, `15`, and later versions.
+    - IBM Semeru Runtimes: `8.0.382.0`, `11.0.20.0`, `17.0.8.0`, and later versions.
+    - IBM Java: `8.0.8.6` and later versions.
+
+  - **uber-go/automaxprocs**:  
+    If you're using the `uber-go/automaxprocs` package, ensure the version is `v1.5.1` or later.
+
+- An alternative temporary solution is to revert the `cgroup` version on your nodes by using the DaemonSet. For more information, see [Revert to cgroup v1 DaemonSet](https://github.com/Azure/AKS/blob/master/examples/cgroups/revert-cgroup-v1.yaml).
+
+  > [!IMPORTANT]
+  > - Use the DaemonSet cautiously. Test it in a lower environment before applying to production to ensure compatibility and avoid disruptions.
+  > - By default, the DaemonSet applies to all nodes in the cluster and reboots them to implement the `cgroup` change.  
+  > - To control how the DaemonSet is applied, configure a `nodeSelector` to target specific nodes.
+
+## Status
+
+Microsoft is working with the Kubernetes community to resolve the issue. Track progress at [Azure/AKS Issue #3443](https://github.com/kubernetes/kubernetes/issues/118916).
+
+As part of the resolution, the plan is to adjust the eviction thresholds or update [resource reservations](/azure/aks/concepts-clusters-workloads#resource-reservations), depending on the outcome of the fix.
+
+## Reference
+
+- [Node memory usage on cgroupv2 reported higher than cgroupv1](https://github.com/kubernetes/kubernetes/issues/118916) (GitHub issue)
 
 [!INCLUDE [Third-party disclaimer](../../../includes/third-party-disclaimer.md)]
 

support/azure/virtual-machines/windows/serial-console-overview.md

@@ -20,7 +20,7 @@ ms.custom: sap:VM Admin - Windows (Guest OS)
 
 [!INCLUDE [Feedback](../../../includes/feedback.md)]
 
-Serial Console in the Azure portal provides access to a text-based console for virtual machines (VMs) and virtual machine scale set instances running either Linux or Windows. Serial Console connects to the ttyS0 or COM1 serial port of the VM or virtual machine scale set instance, providing access independent of the network or operating system state. The serial console can be accessed by using the Azure portal or [Azure CLI](/cli/azure/serial-console) and is allowed only for those users who have an access role of Contributor or higher to the VM or virtual machine scale set.
+Serial Console in the Azure portal provides access to a text-based console for virtual machines (VMs) and virtual machine scale set instances running either Linux or Windows. Serial Console connects to the ttyS0 or COM1 serial port of the VM or virtual machine scale set instance, providing access independent of the network state. The serial console can be accessed by using the Azure portal or [Azure CLI](/cli/azure/serial-console) and is allowed only for those users who have an access role of Contributor or higher to the VM or virtual machine scale set.
 
 Serial Console works in the same manner for VMs and virtual machine scale set instances. In this doc, all mentions to VMs will implicitly include virtual machine scale set instances unless otherwise stated.
 

support/entra/entra-id/toc.yml

@@ -293,6 +293,8 @@
      href: users-groups-entra-apis/memberof-api-returns-null-properties.md
    - name: Getting access denied errors (Authorization)
      items:
+      - name: Add an owner to an application
+        href: users-groups-entra-apis/add-owner-for-application-microsoft-graph.md
       - name: Can't modify user mail or phone number attributes
         href: users-groups-entra-apis/cannot-modify-user-mail-phone-attributes.md
       - name: Error "The identity of the calling application could not be established"
@@ -303,6 +305,8 @@
         href: users-groups-entra-apis/add-owner-for-application-microsoft-graph.md
       - name: NoPermissionsInAccessToken when calling me endpoint
         href: users-groups-entra-apis/error-call-me-endpoint-microsoft-graph.md
+      - name: Tenant doesn't have premium license error when query sign-in activities
+        href: users-groups-entra-apis/b2c-or-tenant-premium-license-sign-in-activities.md
    - name: Problem with using the Graph SDK - libraries
      items:
       - name: Python scripts making requests are detected as web crawlers

support/entra/entra-id/users-groups-entra-apis/b2c-or-tenant-premium-license-sign-in-activities.md

@@ -0,0 +1,60 @@
+---
+title: Tenant doesn't have premium license When You Query User Sign-in Activities By Using Microsoft Graph
+description: Provides solutions to the "either tenant is B2C or tenant doesn't have premium license" error when you query user sign-in activities by using Microsoft Graph
+ms.date: 04/25/2025
+ms.service: entra-id
+ms.author: bachoang
+ms.custom: sap:Getting access denied errors (Authorization)
+---
+
+# "Neither tenant is B2C or tenant doesn't have premium license" error when you query sign-in activities
+
+This article discusses the error that occurs when you make Microsoft Graph API calls that are related to user sign-in activities or user registration details.
+
+## Symptoms
+
+You run one of the following Microsoft Graph API calls:
+
+```http
+GET https://graph.microsoft.com/v1.0/auditLogs/signIns
+
+GET https://graph.microsoft.com/v1.0/users?$select=displayName,userPrincipalName,signInActivity
+
+GET https://graph.microsoft.com/v1.0/reports/UserRegistrationDetails
+```
+
+After you run the call, your receive an error response that resembles the following text:
+
+```output
+'error': {
+    'code': 'Authentication\_RequestFromNonPremiumTenantOrB2CTenant',
+    'message': 'Neither tenant is B2C or tenant doesn't have premium license',
+    'innerError': {
+        'date': '2021-03-04T07:53:51',
+        'request-id': 'a0a074e6-xxx-c511669fa420',
+        'client-request-id': 'a0a074e6-xxx-c511669fa420'
+    }
+}
+```
+
+## Solution
+
+### Scenario 1: Query user sign-in activities
+
+1. Make sure that the target tenant has an Entra ID Premium P1 or P2 license. In the Azure portal, go to **Microsoft Entra ID**, select **Overview**, and then check the **License** value.  For more information, see [Sign up for Microsoft Entra ID P1 or P2 editions](/entra/fundamentals/get-started-premium).
+1. Verify that the Microsoft Graph Access Token was granted the `AuditLog.Read.All` and `Directory.Read.All` permissions.
+
+### Scenario 2: Query credential user registration details
+
+1. Make sure that the target tenant has an Entra ID Premium P1 or P2 license.
+1. Verify that the Microsoft Graph Access Token was granted the `Reports.Read.All` permission.
+1. Verify that the authenticating user or the service principle of the application is in one of the following required administrative roles:
+    - Reports Reader
+    - Security Reader
+    - Security Administrator
+    - Global Reader
+    - Global Administrator
+
+## More information
+
+If an application is configured by using only the **AuditLog.Read.All** permission, this error might occur intermittently. This is expected behavior because the **Directory.Read.All** permission is required to retrieve tenant licensing information if it isn't already cached. To avoid this error, make sure that both permissions are included.

support/sql/database-engine/availability-groups/listener-connection-times-out.md

@@ -1,7 +1,7 @@
 ---
 title: Listener connection times out
 description: This article provides resolutions for the timeout error that occurs when you connect to a SQL Server Always On availability group listener in a multi-subnet environment.
-ms.date: 08/04/2020
+ms.date: 05/06/2025
 ms.custom: sap:Always On Availability Groups (AG)
 ms.reviewer: ramakoni
 ---
@@ -10,19 +10,19 @@ ms.reviewer: ramakoni
 
 This article helps you resolve the problem that occurs when you connect to a SQL Server Always On availability group listener in a multi-subnet environment.
 
-_Original product version:_   SQL Server 2012 Developer, SQL Server 2012 Enterprise, SQL Server 2012 Express, SQL Server 2012 Standard, SQL Server 2012 Web, SQL Server 2012 Enterprise Core  
+_Original product version:_   SQL Server 2012 and later versions  
 _Original KB number:_   2792139
 
 ## Symptoms
 
-After you configure the availability group listener for an Always On Availability Group in Microsoft SQL Server 2012, you may be unable to ping the listener or connect to it from an application.
+After you configure the availability group listener for an Always On Availability Group in Microsoft SQL Server, you might be unable to ping the listener or connect to it from an application.
 
-For example, when you try to connect to a listener of SQL Server by using `SQLCMD`, the connection times out. Additionally, you receive an error message that resembles the following:
+For example, when you try to connect to a listener of SQL Server by using `SQLCMD`, the connection times out. Additionally, you receive an error message that resembles the following one:
 
 > Sqlcmd: Error: Microsoft SQL Native Client: Login timeout expired.
 
 > [!NOTE]
-> These symptoms are usually intermittent, or related to failover of the availability group resource.
+> These symptoms are intermittent, or related to failover of the availability group resource.
 
 The following screenshot shows an example of what occurs when you try to ping the listener for the availability of `aglisten`. The screenshot also shows a successful connection to SQL Server by using the `SQLCMD` command when you include the multi-subnet failover parameter `-M`.
 
@@ -33,20 +33,20 @@ The following screenshot shows an example of what occurs when you try to ping th
 
 ## Cause
 
-This issue occurs because your application either uses a legacy data provider that does not support the new `MultiSubnetFailover` parameter, or isn't configured to use this parameter.
+This issue occurs because your application either uses a legacy data provider that doesn't support the new `MultiSubnetFailover` parameter, or isn't configured to use this parameter.
 
-This parameter is supported in newer versions of the SQLClient driver that is included with the .NET Framework 4 and with later versions of the .NET Framework, and is back ported to the .NET Framework 3.5.
+This parameter is supported in newer versions of the SQLClient driver that is included with the .NET Framework 4 and later versions of the .NET Framework, and is back ported to the .NET Framework 3.5.
 
 > [!NOTE]
-> The `PING` command is a simple connectivity testing tool that does not support the new parameter.
+> The `PING` command is a simple connectivity testing tool that doesn't support the new parameter.
 
 ## Resolution
 
 You can use one of the following resolutions as applicable to your case:
 
 - To resolve this situation when the data providers support the `MultiSubNetFailover` parameter, add the `MultiSubNetFailover` parameter to your connection string, and set it to **true**.
 
-- To resolve this situation when your legacy clients cannot use the `MultiSubnetFailover` property, you can change the listener's `RegisterAllProvidersIP` value to **0**. To do this, run the following command from the Windows PowerShell command-line interface:
+- To resolve this situation when your legacy clients can't use the `MultiSubnetFailover` property, you can change the listener's `RegisterAllProvidersIP` value to **0** by running the following command from the Windows PowerShell command-line interface:
 
     ```powershell
     Import-Module FailoverClusters
@@ -56,22 +56,22 @@ You can use one of the following resolutions as applicable to your case:
     :::image type="content" source="media/listener-connection-times-out/change-listener-registeraiiprovidersip.png" alt-text="Screenshot shows the output of an example of the command in Windows PowerShell.":::
 
 > [!NOTE]
-> After you set the `RegisterAllProvidersIP` value to **0**, the current online IP address must be un-registered from the DNS server and the offline IP address must be registered to the DNS server when a failover occurs. This may cause a connection delay for the next failover.
+> After you set the `RegisterAllProvidersIP` value to **0**, the current online IP address must be unregistered from the DNS server and the offline IP address must be registered to the DNS server when a failover occurs. This might cause a connection delay for the next failover.
 
 ## More information
 
-When you try to connect to a listener that is defined on more than one subnet, the operation may fail if the client driver tries to connect by using one of the listener's offline IP addresses.
+When you try to connect to a listener that is defined on more than one subnet, the operation might fail if the client driver tries to connect by using one of the listener's offline IP addresses.
 
 When a listener is created, an IP address is designated for each unique subnet that an availability group replica is hosted in. For example, if a listener is created for an availability group that has replicas that exist in two subnets, two IP addresses are defined in the listener. One address is used by an application that can connect to an instance of SQL Server in subnet 1, and the other address is used when an application connects to an instance of SQL Server in subnet 2.
 
-Behind the scenes, the listener creates a Windows cluster Client Access Point resource. One of its properties is `RegisterAllProvidersIP`. When a listener is created, this is set to **1**, and all the listener's IP addresses are registered in DNS server. This configuration provides reduced reconnection time for clients.
+Behind the scenes, the listener creates a Windows cluster Client Access Point resource. One of its properties is `RegisterAllProvidersIP`. When a listener is created, this property is set to **1**, and all the listener's IP addresses are registered in DNS server. This configuration provides reduced reconnection time for clients.
 
-Because the DNS record contains all the IP addresses, a client that tries to connect to the listener must know how to handle this situation. The `MultiSubnetFailover` parameter enables the client driver to try connections in parallel to all the listener's IP addresses. Without the `MultiSubnetFailover` parameter, the client driver will try to connect sequentially to all IP addresses for the listener. Sequential connections may cause a long logon time or logon time-outs.
+Because the DNS record contains all the IP addresses, a client that tries to connect to the listener must know how to handle this situation. The `MultiSubnetFailover` parameter enables the client driver to try connections in parallel to all the listener's IP addresses. Without the `MultiSubnetFailover` parameter, the client driver will try to connect sequentially to all IP addresses for the listener. Sequential connections might cause a long logon time or logon time-outs.
 
 > [!NOTE]
 > The problem that is mentioned in this article also affects SharePoint environments that are configured to use an Always On Availability Group's secondary read-only replica. To resolve this issue, perform whichever of the following actions applies to your version of SharePoint:
 
-- For SharePoint 2007: This is classified as a legacy application. Therefore, SharePoint 2007 cannot be configured to use the `MultiSubnetFailover` parameter. Instead, you have to use the Windows PowerShell command that is described in the [Resolution](#resolution) section.
+- For SharePoint 2007: This is classified as a legacy application. Therefore, SharePoint 2007 can't be configured to use the `MultiSubnetFailover` parameter. Instead, you have to use the Windows PowerShell command that is described in the [Resolution](#resolution) section.
 
 - For SharePoint 2010: Cumulative update packages are now available that add support for the `MultiSubnetFailover` parameter. For more information about the update packages, see the following article: