Merge pull request #224063 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: huypub

articles/active-directory/hybrid/how-to-connect-modify-group-writeback.md

@@ -33,16 +33,38 @@ If the original version of group writeback is already enabled and in use in your
 To configure directory settings to disable automatic writeback of newly created Microsoft 365 groups, use one of these methods:
 
 - Azure portal: Update the `NewUnifiedGroupWritebackDefault` setting to `false`. 
-- PowerShell: Use the [New-AzureADDirectorySetting](../enterprise-users/groups-settings-cmdlets.md) cmdlet. For example:
+- PowerShell: Use the [Microsoft Graph PowerShell SDK](/powershell/microsoftgraph/installation?view=graph-powershell-1.0&preserve-view=true). For example: 
 
   ```PowerShell 
-  $TemplateId = (Get-AzureADDirectorySettingTemplate | where {$_.DisplayName -eq "Group.Unified" }).Id 
-  $Template = Get-AzureADDirectorySettingTemplate | where -Property Id -Value $TemplateId -EQ 
-  $Setting = $Template.CreateDirectorySetting() 
-  $Setting["NewUnifiedGroupWritebackDefault"] = "False" 
-  New-AzureADDirectorySetting -DirectorySetting $Setting 
+    # Import Module
+    Import-Module Microsoft.Graph.Identity.DirectoryManagement
+
+    #Connect to MgGraph with necessary scope and select the Beta API Version
+    Connect-MgGraph -Scopes Directory.ReadWrite.All
+    Select-MgProfile -Name beta
+
+    # Import "Group.Unified" template values to a hashtable
+    $Template = Get-MgDirectorySettingTemplate | Where-Object {$_.DisplayName -eq "Group.Unified"}
+    $TemplateValues = @{}
+    $Template.Values | ForEach-Object {
+        $TemplateValues.Add($_.Name, $_.DefaultValue)
+    }
+
+    # Update the value for new unified group writeback default
+    $TemplateValues["NewUnifiedGroupWritebackDefault"] = "false"
+    # Create a directory setting using the Template values hashtable including the updated value
+    $params = @{}
+    $params.Add("TemplateId", $Template.Id)
+    $params.Add("Values", @())
+    $TemplateValues.Keys | ForEach-Object {
+        $params.Values += @(@{Name = $_; Value = $TemplateValues[$_]})
+    }
+    New-MgDirectorySetting -BodyParameter $params
   ``` 
 
+> [!NOTE]     
+> We recommend using Microsoft Graph PowerShell SDK with [Windows PowerShell 7](/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.3&preserve-view=true).
+
 - Microsoft Graph: Use the [directorySetting](/graph/api/resources/directorysetting?view=graph-rest-beta&preserve-view=true) resource type. 
 
 ### Disable writeback for all existing Microsoft 365 group 
@@ -56,7 +78,7 @@ To disable writeback of all Microsoft 365 groups that were created before these
     #Import-module
     Import-module Microsoft.Graph
 
-    #Connect to MgGraph and select the Beta API Version
+    #Connect to MgGraph with necessary scope and select the Beta API Version
     Connect-MgGraph -Scopes Group.ReadWrite.All
     Select-MgProfile -Name beta
 
@@ -68,8 +90,8 @@ To disable writeback of all Microsoft 365 groups that were created before these
     {
         Update-MgGroup -GroupId $group.id -WritebackConfiguration @{isEnabled=$false}
     }
-> We recomend using Microsoft Graph PowerShell SDK with [Windows PowerShell 7](/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.3&preserve-view=true)
-  
+  ```
+      
 - Microsoft Graph Explorer: Use a [group object](/graph/api/group-update?tabs=http&view=graph-rest-beta&preserve-view=true). 
 
 ## Delete groups when they're disabled for writeback or soft deleted 

articles/aks/azure-disk-volume.md

@@ -130,7 +130,7 @@ following command:
     pvc-azuredisk   Bound    pv-azuredisk   20Gi        RWO                           5s
     ```
 
-5. Create a *azure-disk-pod.yaml* file to reference your *PersistentVolumeClaim*. For example:
+5. Create an *azure-disk-pod.yaml* file to reference your *PersistentVolumeClaim*. For example:
 
     ```yaml
     apiVersion: v1

articles/aks/cluster-container-registry-integration.md

@@ -17,9 +17,6 @@ You can set up the AKS to ACR integration using the Azure CLI or Azure PowerShel
 > [!IMPORTANT]
 > There is a latency issue with Azure Active Directory groups when attaching ACR. If the AcrPull role is granted to an Azure AD group and the kubelet identity is added to the group to complete the RBAC configuration, there might be up to a one-hour delay before the RBAC group takes effect. We recommended you to use the [Bring your own kubelet identity][byo-kubelet-identity] as a workaround. You can pre-create a user-assigned identity, add it to the Azure AD group, then use the identity as the kubelet identity to create an AKS cluster. This ensures the identity is added to the Azure AD group before a token is generated by kubelet, which avoids the latency issue.
 
-> [!IMPORTANT]
-> There is a latency issue with Azure Active Directory groups when attaching ACR. If the AcrPull role is granted to an Azure AD group and the kubelet identity is added to the group to complete the RBAC configuration, there might be up to a one-hour delay before the RBAC group update takes effect. We recommended you use the [Bring your own kubelet identity][byo-kubelet-identity] in the meantime. You can pre-create a user-assigned identity, add it to the Azure AD group, and then use the identity as the kubelet identity to create an AKS cluster. This ensures the identity is first added to the Azure AD group and then a token is generated by kubelet, which works around the latency issue.
-
 > [!NOTE]
 > This article covers automatic authentication between AKS and ACR. If you need to pull an image from a private external registry, use an [image pull secret][image-pull-secret].
 

articles/aks/workload-identity-overview.md

@@ -8,7 +8,7 @@ author: mgoedtel
 
 ---
 
-# Use an Azure AD workload identity (preview) on Azure Kubernetes Service (AKS)
+# Use Azure AD workload identity (preview) with Azure Kubernetes Service (AKS)
 
 Today with Azure Kubernetes Service (AKS), you can assign [managed identities at the pod-level][use-azure-ad-pod-identity], which has been a preview feature. This pod-managed identity allows the hosted workload or application access to resources through Azure Active Directory (Azure AD). For example, a workload stores files in Azure Storage, and when it needs to access those files, the pod authenticates itself against the resource as an Azure managed identity. This authentication method has been replaced with [Azure Active Directory (Azure AD) workload identities][azure-ad-workload-identity] (preview), which integrate with the Kubernetes native capabilities to federate with any external identity providers. This approach is simpler to use and deploy, and overcomes several limitations in Azure AD pod-managed identity:
 

articles/app-service/app-service-plan-manage.md

@@ -42,7 +42,7 @@ You can create an empty App Service plan, or you can create a plan as part of ap
 You can move an app to another App Service plan, as long as the source plan and the target plan are in the _same resource group and geographical region_.
 
 > [!NOTE]
-> Azure deploys each new App Service plan into a deployment unit, internally called a webspace. Each region can have many webspaces, but your app can only move between plans that are created in the same webspace. An App Service Environment is an isolated webspace, so apps can be moved between plans in the same App Service Environment, but not between plans in different App Service Environments.
+> Azure deploys each new App Service plan into a deployment unit, internally called a webspace. Each region can have many webspaces, but your app can only move between plans that are created in the same webspace. An App Service Environment can have multiple webspaces, but your app can only move between plans that are created in the same webspace.
 >
 > You can’t specify the webspace you want when creating a plan, but it’s possible to ensure that a plan is created in the same webspace as an existing plan. In brief, all plans created with the same resource group, region combination and operating system are deployed into the same webspace. For example, if you created a plan in resource group A and region B, then any plan you subsequently create in resource group A and region B is deployed into the same webspace. Note that plans can’t move webspaces after they’re created, so you can’t move a plan into “the same webspace” as another plan by moving it to another resource group.
 >