Merge pull request #251178 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/hybrid/connect/how-to-connect-adconnectivitytools.md

@@ -21,7 +21,7 @@ The ADConnectivity tool is a PowerShell module that is used in one of the follow
 - During installation, when a network connectivity problem prevents the successful validation of the Active Directory credentials.
 - Post installation by a user who calls the functions from a PowerShell session.
 
-The tool is located in: **C:\Program Files\Microsoft Azure Active Directory Connect\Tools\ ADConnectivityTool.psm1** 
+The tool is located in: **C:\Program Files\Microsoft Azure Active Directory Connect\Tools\ADConnectivityTool.psm1**.
 
 ## ADConnectivityTool during installation
 

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

@@ -32,50 +32,54 @@ 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:
 
-- PowerShell: Use the [Microsoft Graph PowerShell SDK](/powershell/microsoftgraph/installation?view=graph-powershell-1.0&preserve-view=true). For example: 
+- PowerShell: Use the [Microsoft Graph Beta PowerShell SDK](/powershell/microsoftgraph/installation?view=graph-powershell-1.0&preserve-view=true). For example: 
 
   ```PowerShell 
-  # 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
-
-  # Verify if "Group.Unified" directory settings exist
-  $DirectorySetting = Get-MgDirectorySetting | Where-Object {$_.DisplayName -eq "Group.Unified"}
-
-  # If "Group.Unified" directory settings exist, update the value for new unified group writeback default
-  if ($DirectorySetting) {
-    $DirectorySetting.Values | ForEach-Object {
-        if ($_.Name -eq "NewUnifiedGroupWritebackDefault") {
-            $_.Value = "false"
-        }
-    }
-    Update-MgDirectorySetting -DirectorySettingId $DirectorySetting.Id -BodyParameter $DirectorySetting
-  }
-  else
-  {
-    # In case the directory setting doesn't exist, create a new "Group.Unified" directory setting
-    # 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)
+    # Import Module
+    Import-Module Microsoft.Graph.Beta.Identity.DirectoryManagement
+    
+    #Connect to MgGraph with necessary scope
+    Connect-MgGraph -Scopes Directory.ReadWrite.All
+    
+    
+    # Verify if "Group.Unified" directory settings exist
+    $DirectorySetting = Get-MgBetaDirectorySetting| Where-Object {$_.DisplayName -eq "Group.Unified"}
+    
+    # If "Group.Unified" directory settings exist, update the value for new unified group writeback default
+    if ($DirectorySetting) 
+    {
+      $params = @{
+        Values = @(
+          @{
+            Name = "NewUnifiedGroupWritebackDefault"
+            Value = $false
+          }
+        )
+      }
+      Update-MgBetaDirectorySetting -DirectorySettingId $DirectorySetting.Id -BodyParameter $params
     }
-
-    # Update the value for new unified group writeback default
-    $TemplateValues["NewUnifiedGroupWritebackDefault"] = "false"
+    else
+    {
+      # In case the directory setting doesn't exist, create a new "Group.Unified" directory setting
+      # Import "Group.Unified" template values to a hashtable
+      $Template = Get-MgBetaDirectorySettingTemplate | Where-Object {$_.DisplayName -eq "Group.Unified"}
+      $TemplateValues = @{}
+      $Template.Values | ForEach-Object {
+          $TemplateValues.Add($_.Name, $_.DefaultValue)
+      }
     
-    # 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[$_]})
+      # 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-MgBetaDirectorySetting -BodyParameter $params
     }
-    New-MgDirectorySetting -BodyParameter $params
-  }
   ``` 
 
 > [!NOTE]     
@@ -88,23 +92,22 @@ To configure directory settings to disable automatic writeback of newly created
 To disable writeback of all Microsoft 365 groups that were created before these modifications, use one of the following methods:
 
 - Portal: Use the [Microsoft Entra admin portal](../../enterprise-users/groups-write-back-portal.md).
-- PowerShell: Use the [Microsoft Graph PowerShell SDK](/powershell/microsoftgraph/installation?view=graph-powershell-1.0&preserve-view=true). For example: 
+- PowerShell: Use the [Microsoft Graph Beta PowerShell SDK](/powershell/microsoftgraph/installation?view=graph-powershell-1.0&preserve-view=true). For example: 
 
   ```PowerShell
     #Import-module
-    Import-module Microsoft.Graph
-
-    #Connect to MgGraph with necessary scope and select the Beta API Version
+    Import-Module Microsoft.Graph.Beta
+    
+    #Connect to MgGraph with necessary scope
     Connect-MgGraph -Scopes Group.ReadWrite.All
-    Select-MgProfile -Name beta
-
+    
     #List all Microsoft 365 Groups
-    $Groups = Get-MgGroup -All | Where-Object {$_.GroupTypes -like "*unified*"}
-
+    $Groups = Get-MgBetaGroup -All | Where-Object {$_.GroupTypes -like "*unified*"}
+    
     #Disable Microsoft 365 Groups
     Foreach ($group in $Groups) 
     {
-        Update-MgGroup -GroupId $group.id -WritebackConfiguration @{isEnabled=$false}
+      Update-MgBetaGroup -GroupId $group.id -WritebackConfiguration @{isEnabled=$false}
     }
   ```
       

articles/aks/intro-kubernetes.md

@@ -53,7 +53,7 @@ To secure your AKS clusters, see [Integrate Azure AD with AKS][aks-aad].
 
 Container Insights has native integration with AKS, like collecting critical metrics and logs, alerting on identified issues, and providing visualization with workbooks or integration with Grafana. It can also collect Prometheus metrics and send them to [Azure Monitor managed service for Prometheus][azure-monitor-managed-prometheus], and all together deliver end-to-end observability.
 
-Logs from the AKS control plane components are collected separately in Azure as resource logs and sent to different locations, such as [Azure Monitor Logs][azure-monitor-logs]. For more information, see [Collect control plane logs][monitor-aks.md#collect-control-plane-logs].
+Logs from the AKS control plane components are collected separately in Azure as resource logs and sent to different locations, such as [Azure Monitor Logs][azure-monitor-logs]. For more information, see [Resource logs](monitor-aks-reference.md#resource-logs).
 
 ## Clusters and nodes
 

articles/automation/whats-new.md

@@ -123,13 +123,13 @@ Users can now restore an Automation account deleted within 30 days. Read [here](
 
 **Type:** New feature
 
-New scripts are added to the Azure Automation [GitHub repository](https://github.com/azureautomation) to address one of Azure Automation's key scenarios of VM management based on Azure Monitor alert. For more information, see [Trigger runbook from Azure alert](./automation-create-alert-triggered-runbook.md#common-azure-vm-management-operations).
+New scripts are added to the Azure Automation [GitHub organisation](https://github.com/azureautomation) to address one of Azure Automation's key scenarios of VM management based on Azure Monitor alert. For more information, see [Trigger runbook from Azure alert](./automation-create-alert-triggered-runbook.md#common-azure-vm-management-operations).
 
-- Stop-Azure-VM-On-Alert
-- Restart-Azure-VM-On-Alert
-- Delete-Azure-VM-On-Alert
-- ScaleDown-Azure-VM-On-Alert
-- ScaleUp-Azure-VM-On-Alert
+- [Stop-Azure-VM-On-Alert](https://github.com/azureautomation/Stop-Azure-VM-On-Alert)
+- [Restart-Azure-VM-On-Alert](https://github.com/azureautomation/Restart-Azure-VM-On-Alert)
+- [Delete-Azure-VM-On-Alert](https://github.com/azureautomation/Delete-Azure-VM-On-Alert)
+- [ScaleDown-Azure-VM-On-Alert](https://github.com/azureautomation/ScaleDown-Azure-VM-On-Alert)
+- [ScaleUp-Azure-VM-On-Alert](https://github.com/azureautomation/ScaleUp-Azure-VM-On-Alert)
 
 ## November 2021
 
@@ -241,4 +241,4 @@ Azure Automation now supports [system-assigned managed identities](./automation-
 
 ## Next steps
 
-If you'd like to contribute to Azure Automation documentation, see our [contributor guide](/contribute/).
+If you'd like to contribute to Azure Automation documentation, see our [contributor guide](/contribute/).

articles/communication-services/concepts/call-automation/call-automation.md

@@ -111,6 +111,11 @@ Whether your application has answered a one-to-one or group call, or placed an o
 **Cancel media operations** 
 Based on business logic your application may need to cancel ongoing and queued media operations. Depending on the media operation canceled and the ones in queue, you'll receive a webhook event indicating that the action has been canceled. 
 
+### Query scenarios
+
+**List participants**
+Returns a list of all the participants in a call. Recording and transcription bots are omitted from this list.
+
 ## Events
 
 The following table outlines the current events emitted by Azure Communication Services. The following two tables describe the events emitted by Event Grid and from the Call Automation as webhook events.

articles/service-fabric/service-fabric-work-with-reliable-collections.md

@@ -213,10 +213,53 @@ Internally, Reliable Collections serialize your objects using .NET's DataContrac
 Furthermore, service code is upgraded one upgrade domain at a time. So, during an upgrade, you have two different versions of your service code running simultaneously. You must avoid having the new version of your service code use the new schema as old versions of your service code might not be able to handle the new schema. When possible, you should design each version of your service to be forward compatible by one version. Specifically, this means that V1 of your service code should be able to ignore any schema elements it does not explicitly handle. However, it must be able to save any data it doesn't explicitly know about and write it back out when updating a dictionary key or value.
 
 > [!WARNING]
-> While you can modify the schema of a key, you must ensure that your key's hash code and equals algorithms are stable. If you change how either of these algorithms operate, you will not be able to look up the key within the reliable dictionary ever again.
+> While you can modify the schema of a key, you must ensure that your key's equality and comparison algorithms are stable.
+> Behavior of reliable collections after a change in either of these algorithms is undefined and may lead to data corruption, loss and
+> service crashes.
 > .NET Strings can be used as a key but use the string itself as the key--do not use the result of String.GetHashCode as the key.
 
-Alternatively, you can perform what is typically referred to as a two upgrade. With a two-phase upgrade, you upgrade your service from V1 to V2: V2 contains the code that knows how to deal with the new schema change but this code doesn't execute. When the V2 code reads V1 data, it operates on it and writes V1 data. Then, after the upgrade is complete across all upgrade domains, you can somehow signal to the running V2 instances that the upgrade is complete. (One way to signal this is to roll out a configuration upgrade; this is what makes this a two-phase upgrade.) Now, the V2 instances can read V1 data, convert it to V2 data, operate on it, and write it out as V2 data. When other instances read V2 data, they do not need to convert it, they just operate on it, and write out V2 data.
+Alternatively, you can perform a multi-phase upgrade. 
+1. Upgrade service to a new version that
+    - has both the original V1, and the new V2 version of the data contracts included in the service code package;
+    - registers custom V2 [state serializers](/azure/service-fabric/service-fabric-reliable-services-reliable-collections-serialization#custom-serialization), if needed;
+    - performs all operations on the original, V1 collection using the V1 data contracts.
+2. Upgrade service to a new version that
+    - [creates a new, V2 collection](/dotnet/api/microsoft.servicefabric.data.ireliablestatemanager.getoraddasync);
+    - performs each add, update and delete operation on first V1 and then V2 collections in a single transaction;
+    - performs read operations on the V1 collection only.
+3. Copy all data from the V1 collection to the V2 collection.
+    - This can be done in a background process by the service version deployed in step 2.
+    - [Retreieve all keys](/dotnet/api/microsoft.servicefabric.data.collections.ireliabledictionary2-2.createkeyenumerableasync)
+      from the V1 collection. Enumeration is performed with the
+      [IsolationLevel.Snapshot](/dotnet/api/microsoft.servicefabric.data.beta.isolationlevel)
+      by default to avoid locking the collection for the duration of the operation.
+    - For each key, use a separate transaction to
+        - [TryGetValueAsync](/dotnet/api/microsoft.servicefabric.data.collections.ireliabledictionary-2.trygetvalueasync)
+          from the V1 collection.
+        - If the value has already been removed from the V1 collection since the copy process started,
+          the key should be skipped and not resurected in the V2 collection.
+        - [TryAddAsync](/dotnet/api/microsoft.servicefabric.data.collections.ireliabledictionary.tryaddasync)
+          the value to the V2 collection.
+        - If the value has already been added to the V2 collection since the copy process started,
+          the key should be skipped.
+        - The transaction should be committed only if the `TryAddAsync` returns `true`.
+        - Value access APIs use the [IsolationLevel.ReadRepeatable](/dotnet/api/microsoft.servicefabric.data.beta.isolationlevel)
+          by default and rely on locking to guarantee that the values aren't modified by another caller until the transaction is committed or aborted.
+4. Upgrade service to a new version that
+    - performs read operations on the V2 collection only;
+    - still performs each add, update and delete operation on first V1 and then V2 collections to maintain the option of rolling back to V1.
+5. Comprehensively test the service and confirm it is working as expected.
+    - If you missed any value access operation that wasn't updated to work on both V1 and V2 collection, you may notice missing data.
+    - If any data is missing roll back to Step 1, remove the V2 collection and repeat the process.
+6. Upgrade service to a new version that
+    - performs all operations on the V2 collection only;
+    - going back to V1 is no longer possible with a service rollback and would require rolling forward with reversed steps 2-4.
+7. Upgrade service a new version that
+    - [removes the V1 collection](/dotnet/api/microsoft.servicefabric.data.ireliablestatemanager.removeasync).
+8. Wait for log truncation.
+    - By default, this happens every 50MB of writes (adds, updates, and removes) to reliable collections.
+9. Upgrade service to a new version that
+    - no longer has the V1 data contracts included in the service code package.
 
 ## Next steps
 To learn about creating forward compatible data contracts, see [Forward-Compatible Data Contracts](/dotnet/framework/wcf/feature-details/forward-compatible-data-contracts)
@@ -226,3 +269,5 @@ To learn best practices on versioning data contracts, see [Data Contract Version
 To learn how to implement version tolerant data contracts, see [Version-Tolerant Serialization Callbacks](/dotnet/framework/wcf/feature-details/version-tolerant-serialization-callbacks)
 
 To learn how to provide a data structure that can interoperate across multiple versions, see [IExtensibleDataObject](/dotnet/api/system.runtime.serialization.iextensibledataobject)
+
+To learn how to configure reliable collections, see [Replicator Configuration](/azure/service-fabric/service-fabric-reliable-services-configuration#replicator-configuration)

includes/app-provisioning-sql.md

@@ -373,7 +373,7 @@ If you are connecting to a new database or one that is empty and has no users, t
 
     |Property|Value|
     |-----|-----|
-    |Tenant URL| `https://localhost:8585/ecma2host_SQL/scim`|
+    |Tenant URL| `https://localhost:8585/ecma2host_{connectorName}/scim`|
 
  5. Enter the **Secret Token** value that you defined when you created the connector.
      >[!NOTE]