Merge pull request #227417 from MicrosoftDocs/main

Publish to Live Wednesday 4AM PST, 02/15

Author: PMEds28

articles/active-directory/develop/scenario-desktop-acquire-token-wam.md

@@ -129,7 +129,7 @@ Applications cannot remove accounts from Windows!
 - Removes app-only (not OS-wide) accounts.
 
 >[!NOTE]
-> Ony users can remove OS accounts, whereas apps themselves cannot. If an OS account is passed into `RemoveAsync`, and then `GetAccounts` is called with `ListWindowsWorkAndSchoolAccounts` enabled, the same OS accounts will still be returned.
+> Only users can remove OS accounts, whereas apps themselves cannot. If an OS account is passed into `RemoveAsync`, and then `GetAccounts` is called with `ListWindowsWorkAndSchoolAccounts` enabled, the same OS accounts will still be returned.
 
 ## Other considerations
 

articles/active-directory/develop/v2-oauth2-client-creds-grant-flow.md

@@ -106,7 +106,7 @@ https://login.microsoftonline.com/common/adminconsent?client_id=6731de76-14a6-49
 | `redirect_uri` |  Required   | The redirect URI where you want the response to be sent for your app to handle. It must exactly match one of the redirect URIs that you registered in the portal, except that it must be URL-encoded, and it can have additional path segments. |
 |    `state`     | Recommended | A value that's included in the request that's also returned in the token response. It can be a string of any content that you want. The state is used to encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on. |
 
-At this point, Azure AD enforces that only a tenant administrator can sign into complete the request. The administrator will be asked to approve all the direct application permissions that you have requested for your app in the app registration portal.
+At this point, Azure AD enforces that only a tenant administrator can sign in to complete the request. The administrator will be asked to approve all the direct application permissions that you have requested for your app in the app registration portal.
 
 ##### Successful response
 

articles/active-directory/hybrid/concept-azure-ad-connect-sync-declarative-provisioning.md

@@ -98,7 +98,7 @@ In the attribute flows there is a setting to determine if multi-valued attribute
 
 ![Screenshot that shows the "Add transformations" section with the "Merge Types" drop-down menu open.](./media/concept-azure-ad-connect-sync-declarative-provisioning/mergetype.png)  
 
-There is also **Merge** and **MergeCaseInsensitive**. These options allow you to merge values from different sources. For example, it can be used to merge the member or proxyAddresses attribute from several different forests. When you use this option, all sync rules in scope for an object must use the same merge type. You cannot define **Update** from one Connector and **Merge** from another. If you try, you receive an error.
+There is also **Merge** and **MergeCaseInsensitive**. These options allow you to merge values from different sources. For example, it can be used to merge the proxyAddresses attribute from several different forests. When you use this option, all sync rules in scope for an object must use the same merge type. You cannot define **Update** from one Connector and **Merge** from another. If you try, you receive an error.
 
 The difference between **Merge** and **MergeCaseInsensitive** is how to process duplicate attribute values. The sync engine makes sure duplicate values are not inserted into the target attribute. With **MergeCaseInsensitive**, duplicate values with only a difference in case are not going to be present. For example, you should not see both "SMTP:bob@contoso.com" and "smtp:bob@contoso.com" in the target attribute. **Merge** is only looking at the exact values and multiple values where there only is a difference in case might be present.
 
@@ -122,14 +122,20 @@ In *Out to AD - User Exchange hybrid* the following flow can be found:
 This expression should be read as: if the user mailbox is located in Azure AD, then flow the attribute from Azure AD to AD. If not, do not flow anything back to Active Directory. In this case, it would keep the existing value in AD.
 
 ### ImportedValue
-The function ImportedValue is different than all other functions since the attribute name must be enclosed in quotes rather than square brackets:  
+
+The function ImportedValue is different than all other functions since the attribute name must be enclosed in quotes rather than square brackets:
+
 `ImportedValue("proxyAddresses")`.
 
-Usually during synchronization an attribute uses the expected value, even if it hasn’t been exported yet or an error was received during export (“top of the tower”). An inbound synchronization assumes that an attribute that hasn’t yet reached a connected directory eventually reaches it. In some cases, it is important to only synchronize a value that has been confirmed by the connected directory (“hologram and delta import tower”).
+Inbound synchronization has a concept of assuming that an attribute that hasn’t yet reached a connected directory will eventually reach it at some point so, normally, synchronization gets an attribute value from the respective connector space, even if it hasn’t been yet exported or an error occurred during export. 
+In some cases, however, it is important to only synchronize a value that has been exported and confirmed during import from the connected directory. This function can be found in multiple “In From AD/AAD” out-of-box transformation rules where the attribute should only be synchronized when it has been confirmed that the value was exported successfully.
+
+An example of this function can be found in the out-of-box Synchronization Rule *In from AD – User Common from Exchange*, for ProxyAddresses attribute flow with Hybrid Exchange. E.g., when a user’s ProxyAddresses is added, the ImportedValue function will only return the new value after it has been confirmed from the following import step:
 
-An example of this function can be found in the out-of-box Synchronization Rule *In from AD – User Common from Exchange*. In Hybrid Exchange, the value added by Exchange online should only be synchronized when it has been confirmed that the value was exported successfully:  
 `proxyAddresses` <- `RemoveDuplicates(Trim(ImportedValue("proxyAddresses")))`
 
+This function is required when the target directory might change or discard an exported attribute value silently, and we want the synchronization to only process confirmed attribute values. 
+
 ## Precedence
 When several sync rules try to contribute the same attribute value to the target, the precedence value is used to determine the winner. The rule with highest precedence, lowest numeric value, is going to contribute the attribute in a conflict.
 
@@ -140,11 +146,9 @@ This ordering can be used to define more precise attribute flows for a small sub
 Precedence can be defined between Connectors. That allows Connectors with better data to contribute values first.
 
 ### Multiple objects from the same connector space
-If you have several objects in the same connector space joined to the same metaverse object, precedence must be adjusted. If several objects are in scope of the same sync rule, then the sync engine is not able to determine precedence. It is ambiguous which source object should contribute the value to the metaverse. This configuration is reported as ambiguous even if the attributes in the source have the same value.  
-![Diagram that shows multiple objects joined to the same mv object with a transparent red X overlay. ](./media/concept-azure-ad-connect-sync-declarative-provisioning/multiple1.png)  
+It is not possible to have several objects in the same connector space joined to the same metaverse object. This configuration is reported as ambiguous even if the attributes in the source have the same value.
 
-For this scenario, you need to change the scope of the sync rules so the source objects have different sync rules in scope. That allows you to define different precedence.  
-![Multiple objects joined to the same mv object](./media/concept-azure-ad-connect-sync-declarative-provisioning/multiple2.png)  
+![Diagram that shows multiple objects joined to the same mv object with a transparent red X overlay. ](./media/concept-azure-ad-connect-sync-declarative-provisioning/multiple1.png) 
 
 ## Next steps
 * Read more about the expression language in [Understanding Declarative Provisioning Expressions](concept-azure-ad-connect-sync-declarative-provisioning-expressions.md).

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

@@ -136,11 +136,6 @@ These limitations and known issues are specific to group writeback:
 - Nested cloud groups that are members of writeback enabled groups must also be enabled for writeback to remain nested in AD. 
 - Group Writeback setting to manage new security group writeback at scale is not yet available. You will need to configure writeback for each group.  
 
-  If you have a nested group like this, you'll see an export error in Azure AD Connect with the message "A universal group cannot have a local group as a member." The resolution is to remove the member with the **Domain local** scope from the Azure AD group, or update the nested group member scope in Active Directory to **Global** or **Universal**. 
-- Group writeback supports writing back groups to only a single organizational unit (OU). After the feature is enabled, you can't change the OU that you selected. A workaround is to disable group writeback entirely in Azure AD Connect and then select a different OU when you re-enable the feature.  
-- Nested cloud groups that are members of writeback-enabled groups must also be enabled for writeback to remain nested in Active Directory. 
-- A group writeback setting to manage new security group writeback at scale is not yet available. You need to configure writeback for each group.   
-
 ## Next steps 
 
 - [Modify Azure AD Connect group writeback default behavior](how-to-connect-modify-group-writeback.md) 

articles/active-directory/hybrid/how-to-connect-sync-configure-filtering.md

@@ -34,7 +34,7 @@ This article covers how to configure the different filtering methods.
 ## Basics and important notes
 In Azure AD Connect sync, you can enable filtering at any time. If you start with a default configuration of directory synchronization and then configure filtering, the objects that are filtered out are no longer synchronized to Azure AD. Because of this change, any objects in Azure AD that were previously synchronized but were then filtered are deleted in Azure AD.
 
-Before you start making changes to filtering, make sure that you [disable the scheduled task](#disable-the-scheduled-task) so you don't accidentally export changes that you haven't yet verified to be correct.
+Before you start making changes to filtering, make sure that you [disable the built-in scheduler](#disable-the-synchronization-scheduler) so you don't accidentally export changes that you haven't yet verified to be correct.
 
 Because filtering can remove many objects at the same time, you want to make sure that your new filters are correct before you start exporting any changes to Azure AD. After you've completed the configuration steps, we strongly recommend that you follow the [verification steps](#apply-and-verify-changes) before you export and make changes to Azure AD.
 
@@ -50,23 +50,21 @@ The filtering configuration is retained when you install or upgrade to a newer v
 
 If you have more than one forest, then you must apply the filtering configurations that are described in this topic to every forest (assuming that you want the same configuration for all of them).
 
-### Disable the scheduled task
+### Disable the synchronization scheduler
 To disable the built-in scheduler that triggers a synchronization cycle every 30 minutes, follow these steps:
 
-1. Go to a PowerShell prompt.
-2. Run `Set-ADSyncScheduler -SyncCycleEnabled $False` to disable the scheduler.
-3. Make the changes that are documented in this article.
-4. Run `Set-ADSyncScheduler -SyncCycleEnabled $True` to enable the scheduler again.
+1. Open Windows Powershell, import the ADSync module and disable the scheduler using the follwoing commands
 
-**If you use an Azure AD Connect build before 1.1.105.0**  
-To disable the scheduled task that triggers a synchronization cycle every three hours, follow these steps:
+```Powershell
+import-module ADSync
+Set-ADSyncScheduler -SyncCycleEnabled $False
+```
 
-1. Start **Task Scheduler** from the **Start** menu.
-2. Directly under **Task Scheduler Library**, find the task named **Azure AD Sync Scheduler**, right-click, and select **Disable**.  
-   ![Task Scheduler](./media/how-to-connect-sync-configure-filtering/taskscheduler.png)  
-3. You can now make configuration changes and run the sync engine manually from the **Synchronization Service Manager** console.
+2. Make the changes that are documented in this article. Then re-enable the scheduler again with the following command
 
-After you've completed all your filtering changes, don't forget to come back and **Enable** the task again.
+```Powershell
+Set-ADSyncScheduler -SyncCycleEnabled $True
+```
 
 ## Filtering options
 You can apply the following filtering configuration types to the directory synchronization tool:

articles/aks/managed-aad.md

@@ -221,10 +221,10 @@ Operation failed with status: 'Bad Request'. Details: Getting static credential
 
 ### Disable local accounts on an existing cluster
 
-To disable local accounts on an existing AKS cluster, use the [`az aks update`][az-aks-update] command with the `disable-local-accounts` parameter.
+To disable local accounts on an existing Azure AD integration enabled AKS cluster, use the [`az aks update`][az-aks-update] command with the `disable-local-accounts` parameter.
 
 ```azurecli-interactive
-az aks update -g <resource-group> -n <cluster-name> --enable-aad --aad-admin-group-object-ids <aad-group-id> --disable-local-accounts
+az aks update -g <resource-group> -n <cluster-name> --disable-local-accounts
 ```
 
 In the output, confirm local accounts have been disabled by checking the field `properties.disableLocalAccounts` is set to `true`.
@@ -247,10 +247,10 @@ Operation failed with status: 'Bad Request'. Details: Getting static credential
 
 ### Re-enable local accounts on an existing cluster
 
-AKS supports enabling a disabled local account on an existing cluster with the `enable-local` parameter.
+AKS supports enabling a disabled local account on an existing cluster with the `enable-local-accounts` parameter.
 
 ```azurecli-interactive
-az aks update -g <resource-group> -n <cluster-name> --enable-aad --aad-admin-group-object-ids <aad-group-id> --enable-local
+az aks update -g <resource-group> -n <cluster-name> --enable-local-accounts
 ```
 
 In the output, confirm local accounts have been re-enabled by checking the field `properties.disableLocalAccounts` is set to `false`.

articles/aks/node-upgrade-github-actions.md

@@ -95,7 +95,7 @@ Download and sign in to the Azure CLI.
 
           steps:
             - name: Azure Login
-              uses: Azure/login@v1.1
+              uses: Azure/login@v1.4.3
               with:
                 creds: ${{ secrets.AZURE_CREDENTIALS }}
       ```
@@ -110,11 +110,16 @@ Download and sign in to the Azure CLI.
 
     ```output
     {
-      "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
-      "displayName": "azure-cli-xxxx-xx-xx-xx-xx-xx",
-      "name": "http://azure-cli-xxxx-xx-xx-xx-xx-xx",
-      "password": "xXxXxXxXx",
-      "tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
+      "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
+      "clientSecret": "xXxXxXxXx",
+      "subscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
+      "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"      
+      "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
+      "resourceManagerEndpointUrl": "https://management.azure.com/",
+      "activeDirectoryGraphResourceId": "https://graph.windows.net/",
+      "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
+      "galleryEndpointUrl": "https://gallery.azure.com/",
+      "managementEndpointUrl": "https://management.core.windows.net/"
     }
     ```
 
@@ -149,11 +154,11 @@ To create the steps to execute Azure CLI commands.
 
         steps:
           - name: Azure Login
-            uses: Azure/login@v1.1
+            uses: Azure/login@v1.4.3
             with:
               creds: ${{ secrets.AZURE_CREDENTIALS }}
           - name: Upgrade node images
-            uses: Azure/[email protected].0
+            uses: Azure/[email protected].6
             with:
               inlineScript: az aks upgrade -g {resourceGroupName} -n {aksClusterName} --node-image-only --yes
     ```
@@ -190,7 +195,7 @@ jobs:
 
     steps:
       - name: Azure Login
-        uses: Azure/login@v1.1
+        uses: Azure/login@v1.4.3
         with:
           creds: ${{ secrets.AZURE_CREDENTIALS }}
 

articles/application-gateway/application-gateway-backend-health-troubleshooting.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: greg-lindsay
 ms.service: application-gateway
 ms.topic: troubleshooting
-ms.date: 09/13/2022
+ms.date: 02/14/2023
 ms.author: greglin 
 ms.custom: devx-track-azurepowershell
 ---
@@ -240,8 +240,8 @@ Learn more about [Application Gateway probe matching](./application-gateway-prob
 
 1. Sign in to the machine where your application is hosted.
 2. Select Win+R or right-click the **Start** button, and then select **Run**.
-3. Enter `certmgr.msc` and select Enter. You can also search for Certificate Manager on the **Start** menu.
-4. Locate the certificate, typically in `\Certificates - Current User\\Personal\\Certificates\`, and open it.
+3. Enter `certlm.msc` and select Enter. You can also search for Certificate Manager on the **Start** menu.
+4. Locate the certificate, typically in `Certificates - Local Computer\Personal\Certificates`, and open it.
 5. Select the root certificate and then select **View Certificate**.
 6. In the Certificate properties, select the **Details** tab.
 7. On the **Details** tab, select the **Copy to File** option and save the file in the Base-64 encoded X.509 (.CER) format.
@@ -317,8 +317,8 @@ For Windows:
 
 1. Sign in to the machine where your application is hosted.
 2. Select Win+R or right-click the **Start** button and select **Run**.
-3. Enter **certmgr.msc** and select Enter. You can also search for Certificate Manager on the **Start** menu.
-4. Locate the certificate (typically in `\Certificates - Current User\\Personal\\Certificates`), and open the certificate.
+3. Enter **certlm.msc** and select Enter. You can also search for Certificate Manager on the **Start** menu.
+4. Locate the certificate (typically in `Certificates - Local Computer\Personal\Certificates`), and open the certificate.
 5. On the **Details** tab, check the certificate **Subject**.
 6. Verify the CN of the certificate from the details and enter the same in the host name field of the custom probe or in the HTTP settings (if **Pick hostname from backend HTTP settings** is selected). If that's not the desired host name for your website, you must get a certificate for that domain or enter the correct host name in the custom probe or HTTP setting configuration.
 

articles/applied-ai-services/.openpublishing.redirection.applied-ai-services.json

@@ -155,6 +155,11 @@
             "source_path_from_root": "/articles/applied-ai-services/form-recognizer/quickstarts/try-v3-form-recognizer-studio.md",
             "redirect_url": "/azure/applied-ai-services/form-recognizer/quickstarts/try-form-recognizer-studio",
             "redirect_document_id": true
+          },
+          {
+            "source_path_from_root": "/articles/applied-ai-services/form-recognizer/form-recognizer-studio-overview.md",
+            "redirect_url": "/azure/applied-ai-services/form-recognizer/studio-overview",
+            "redirect_document_id": true
           }
      ]
 }