Merge pull request #230149 from MicrosoftDocs/repo_sync_working_branch

huypub · web-flow · commit 8e8dec749022 · 2023-03-09T14:45:39.000-08:00
Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)
diff --git a/articles/active-directory/conditional-access/concept-condition-filters-for-devices.md b/articles/active-directory/conditional-access/concept-condition-filters-for-devices.md
@@ -119,7 +119,7 @@ The following device attributes can be used with the filter for devices conditio
 | model | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.model -notContains "Surface") |
 | operatingSystem | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | A valid operating system (like Windows, iOS, or Android) | (device.operatingSystem -eq "Windows") |
 | operatingSystemVersion | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | A valid operating system version (like 6.1 for Windows 7, 6.2 for Windows 8, or 10.0 for Windows 10 and Windows 11) | (device.operatingSystemVersion -in ["10.0.18363", "10.0.19041", "10.0.19042", "10.0.22000"]) |
-| physicalIds | Contains, NotContains | As an example all Windows Autopilot devices store ZTDId (a unique value assigned to all imported Windows Autopilot devices) in device physicalIds property. | (device.devicePhysicalIDs -contains "[ZTDId]:value") |
+| physicalIds | Contains, NotContains | As an example all Windows Autopilot devices store ZTDId (a unique value assigned to all imported Windows Autopilot devices) in device physicalIds property. | (device.physicalIds -contains "[ZTDId]:value") |
 | profileType | Equals, NotEquals | A valid profile type set for a device. Supported values are: RegisteredDevice (default), SecureVM (used for Windows VMs in Azure enabled with Azure AD sign in.), Printer (used for printers), Shared (used for shared devices), IoT (used for IoT devices) | (device.profileType -eq "Printer") |
 | systemLabels | Contains, NotContains | List of labels applied to the device by the system. Some of the supported values are: AzureResource (used for Windows VMs in Azure enabled with Azure AD sign in), M365Managed (used for devices managed using Microsoft Managed Desktop), MultiUser (used for shared devices) | (device.systemLabels -contains "M365Managed") |
 | trustType | Equals, NotEquals | A valid registered state for devices. Supported values are: AzureAD (used for Azure AD joined devices), ServerAD (used for Hybrid Azure AD joined devices), Workplace (used for Azure AD registered devices) | (device.trustType -eq "ServerAD") |
diff --git a/articles/active-directory/develop/publisher-verification-overview.md b/articles/active-directory/develop/publisher-verification-overview.md
@@ -66,7 +66,7 @@ App developers must meet a few requirements to complete the publisher verificati
 
   - In Partner Center, this user must have one of the following [roles](/partner-center/permissions-overview): MPN Partner Admin, Account Admin, or Global Administrator (a shared role that's mastered in Azure AD).
   
-- The user who initiates verification must sign in by using [multifactor authentication](../authentication/howto-mfa-getstarted.md).
+- The user who initiates verification must sign in by using [Azure AD multifactor authentication](../authentication/howto-mfa-getstarted.md).
 
 - The publisher must consent to the [Microsoft identity platform for developers Terms of Use](/legal/microsoft-identity-platform/terms-of-use).
 
diff --git a/articles/active-directory/identity-protection/howto-identity-protection-simulate-risk.md b/articles/active-directory/identity-protection/howto-identity-protection-simulate-risk.md
@@ -97,7 +97,7 @@ This risk detection indicates that the application's valid credentials have been
    
 5. Get the TenantID and Application(Client)ID in the **Overview** page.
 6. Ensure you disable the application via **Azure Active Directory** > **Enterprise Application** > **Properties** > Set **Enabled for users to sign-in** to **No**.
-7. Create a **public** GitHub Repository, add the following config and commit the change.
+7. Create a **public** GitHub Repository, add the following config and commit the change as a file with the .txt extension.
    ```GitHub file
      "AadClientId": "XXXX-2dd4-4645-98c2-960cf76a4357",
      "AadSecret": "p3n7Q~XXXX",
diff --git a/articles/active-directory/saas-apps/facebook-work-accounts-provisioning-tutorial.md b/articles/active-directory/saas-apps/facebook-work-accounts-provisioning-tutorial.md
@@ -1,6 +1,6 @@
 ---
-title: 'Tutorial: Configure Facebook Work Accounts for automatic user provisioning with Azure Active Directory | Microsoft Docs'
-description: Learn how to automatically provision and de-provision user accounts from Azure AD to Facebook Work Accounts.
+title: 'Tutorial: Configure Meta Work Accounts for automatic user provisioning with Azure Active Directory | Microsoft Docs'
+description: Learn how to automatically provision and de-provision user accounts from Azure AD to Meta Work Accounts.
 services: active-directory
 author: jeevansd
 manager: CelesteDG
@@ -13,17 +13,17 @@ ms.topic: tutorial
 ms.date: 01/06/2023
 ---
 
-# Tutorial: Configure Facebook Work Accounts for automatic user provisioning
+# Tutorial: Configure Meta Work Accounts for automatic user provisioning
 
-This tutorial describes the steps you need to perform in both Facebook Work Accounts and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and de-provisions users and groups to [Facebook Work Accounts](https://work.facebook.com) using the Azure AD Provisioning service. For important details on what this service does, how it works, and frequently asked questions, see [Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory](../app-provisioning/user-provisioning.md).
+This tutorial describes the steps you need to perform in both Meta Work Accounts and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and de-provisions users and groups to [Meta Work Accounts](https://work.meta.com) using the Azure AD Provisioning service. For important details on what this service does, how it works, and frequently asked questions, see [Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory](../app-provisioning/user-provisioning.md).
 
 ## Capabilities supported
 
 > [!div class="checklist"]
-> * Create users in Facebook Work Accounts
-> * Remove users in Facebook Work Accounts when they do not require access anymore
-> * Keep user attributes synchronized between Azure AD and Facebook Work Accounts
-> * Single sign-on to Facebook Work Accounts (recommended)
+> * Create users in Meta Work Accounts
+> * Remove users in Meta Work Accounts when they do not require access anymore
+> * Keep user attributes synchronized between Azure AD and Meta Work Accounts
+> * Single sign-on to Meta Work Accounts (recommended)
 
 ## Prerequisites
 
@@ -37,11 +37,11 @@ The scenario outlined in this tutorial assumes that you already have the followi
 
 1. Learn about [how the provisioning service works](../app-provisioning/user-provisioning.md).
 1. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).
-1. Determine what data to [map between Azure AD and Facebook Work Accounts](../app-provisioning/customize-application-attributes.md).
+1. Determine what data to [map between Azure AD and Meta Work Accounts](../app-provisioning/customize-application-attributes.md).
 
-## Step 2. Add Facebook Work Accounts from the Azure AD application gallery
+## Step 2. Add Meta Work Accounts from the Azure AD application gallery
 
-Add Facebook Work Accounts from the Azure AD application gallery to start managing provisioning to Facebook Work Accounts. If you have previously setup Facebook Work Accounts for SSO, you can use the same application. However it is recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).
+Add Meta Work Accounts from the Azure AD application gallery to start managing provisioning to Meta Work Accounts. If you have previously setup Meta Work Accounts for SSO, you can use the same application. However it is recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).
 
 ## Step 3. Define who will be in scope for provisioning
 
@@ -51,31 +51,31 @@ The Azure AD provisioning service allows you to scope who will be provisioned ba
 
 * If you need additional roles, you can [update the application manifest](../develop/howto-add-app-roles-in-azure-ad-apps.md) to add new roles.
 
-## Step 4. Configure automatic user provisioning to Facebook Work Accounts
+## Step 4. Configure automatic user provisioning to Meta Work Accounts
 
 This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users and/or groups in TestApp based on user and/or group assignments in Azure AD.
 
-### To configure automatic user provisioning for Facebook Work Accounts in Azure AD:
+### To configure automatic user provisioning for Meta Work Accounts in Azure AD:
 
 1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.
 
-1. In the applications list, select **Facebook Work Accounts**.
+1. In the applications list, select **Meta Work Accounts**.
 
 1. Select the **Provisioning** tab.
 
 1. Set the **Provisioning Mode** to **Automatic**.
 
-1. Under the **Admin Credentials** section, click on **Authorize**. You will be redirected to **Facebook Work Accounts**'s authorization page. Input your Facebook Work Accounts username and click on the **Continue** button. Click **Test Connection** to ensure Azure AD can connect to Facebook Work Accounts. If the connection fails, ensure your Facebook Work Accounts account has Admin permissions and try again.
+1. Under the **Admin Credentials** section, click on **Authorize**. You will be redirected to **Meta Work Accounts**'s authorization page. Input your Meta Work Accounts username and click on the **Continue** button. Click **Test Connection** to ensure Azure AD can connect to Meta Work Accounts. If the connection fails, ensure your Meta Work Accounts account has Admin permissions and try again.
 
-    :::image type="content" source="media/facebook-work-accounts-provisioning-tutorial/azure-connect.png" alt-text="Screenshot shows the Facebook Work Accounts authorization page.":::
+    :::image type="content" source="media/facebook-work-accounts-provisioning-tutorial/azure-connect.png" alt-text="Screenshot shows the Meta Work Accounts authorization page.":::
 
 1. In the **Notification Email** field, enter the email address of a person or group who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.
 
 1. Select **Save**.
 
-1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Facebook Work Accounts**.
+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Meta Work Accounts**.
 
-1. Review the user attributes that are synchronized from Azure AD to Facebook Work Accounts in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Facebook Work Accounts for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you will need to ensure that the Facebook Work Accounts API supports filtering users based on that attribute. Select the **Save** button to commit any changes.
+1. Review the user attributes that are synchronized from Azure AD to Meta Work Accounts in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Meta Work Accounts for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you will need to ensure that the Meta Work Accounts API supports filtering users based on that attribute. Select the **Save** button to commit any changes.
 
     |Attribute|Type|Supported for filtering|
     |---|---|---|
@@ -100,9 +100,9 @@ This section guides you through the steps to configure the Azure AD provisioning
 
 1. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).
 
-1. To enable the Azure AD provisioning service for Facebook Work Accounts, change the **Provisioning Status** to **On** in the **Settings** section.
+1. To enable the Azure AD provisioning service for Meta Work Accounts, change the **Provisioning Status** to **On** in the **Settings** section.
 
-1. Define the users and/or groups that you would like to provision to Facebook Work Accounts by choosing the desired values in **Scope** in the **Settings** section.
+1. Define the users and/or groups that you would like to provision to Meta Work Accounts by choosing the desired values in **Scope** in the **Settings** section.
 
    ![Screenshot shows the Scope dropdown in the Settings section.](common/provisioning-scope.png)
 
diff --git a/articles/aks/upgrade-cluster.md b/articles/aks/upgrade-cluster.md
@@ -246,7 +246,7 @@ To confirm that the upgrade was successful, navigate to your AKS cluster in the
 When you upgrade your cluster, the following Kubernetes events may occur on each node:
 
 - Surge – Create surge node.
-- Drain – Pods are being evicted from the node. Each pod has a 30-minute timeout to complete the eviction.
+- Drain – Pods are being evicted from the node. Each pod has a 30-second timeout to complete the eviction.
 - Update – Update of a node has succeeded or failed.
 - Delete – Deleted a surge node.
 
diff --git a/articles/aks/workload-identity-overview.md b/articles/aks/workload-identity-overview.md
@@ -103,7 +103,7 @@ If you've used [Azure AD pod-managed identity][use-azure-ad-pod-identity], think
 |`azure.workload.identity/service-account-token-expiration` |Represents the `expirationSeconds` field for the projected service account token. It's an optional field that you configure to prevent any downtime caused by errors during service account token refresh. Kubernetes service account token expiry isn't correlated with Azure AD tokens. Azure AD tokens expire in 24 hours after they're issued. <sup>1</sup> |3600<br> Supported range is 3600-86400. |
 |`azure.workload.identity/skip-containers` |Represents a semi-colon-separated list of containers to skip adding projected service account token volume. For example `container1;container2`. |By default, the projected service account token volume is added to all containers if the service account is labeled with `azure.workload.identity/use: true`. |
 |`azure.workload.identity/inject-proxy-sidecar` |Injects a proxy init container and proxy sidecar into the pod. The proxy sidecar is used to intercept token requests to IMDS and acquire an Azure AD token on behalf of the user with federated identity credential. |true |
-|`azure.workload.identity/proxy-sidecar-port` |Represents the port of the proxy sidecar. |8080 |
+|`azure.workload.identity/proxy-sidecar-port` |Represents the port of the proxy sidecar. |8000 |
 
  <sup>1</sup> Takes precedence if the service account is also annotated.
 
diff --git a/articles/azure-cache-for-redis/cache-how-to-geo-replication.md b/articles/azure-cache-for-redis/cache-how-to-geo-replication.md
@@ -42,6 +42,7 @@ To configure geo-replication between two caches, the following prerequisites mus
 - Both caches are in the same Azure subscription.
 - The secondary linked cache is either the same cache size or a larger cache size than the primary linked cache. To use geo-failover, both caches must be the same size.
 - Both caches are created and in a running state.
+- Both caches are running the same version of Redis server.
 
 > [!NOTE]
 > Data transfer between Azure regions is charged at standard [bandwidth rates](https://azure.microsoft.com/pricing/details/bandwidth/).
diff --git a/articles/iot-edge/how-to-create-iot-edge-device.md b/articles/iot-edge/how-to-create-iot-edge-device.md
@@ -32,11 +32,6 @@ If you want more information about how to choose the right option for you, conti
 >[!NOTE]
 >The following table reflects the supported scenarios for IoT Edge version 1.4.
 
-|    | Linux containers on Linux hosts |
-|--| ----- |
-| **Manual provisioning (single device)** | [X.509 certificates](how-to-provision-single-device-linux-x509.md)<br><br>[Symmetric keys](how-to-provision-single-device-linux-symmetric.md) |
-| **Autoprovisioning (devices at scale)** | [X.509 certificates](how-to-provision-devices-at-scale-linux-x509.md)<br><br>[TPM](how-to-provision-devices-at-scale-linux-tpm.md)<br><br>[Symmetric keys](how-to-provision-devices-at-scale-linux-symmetric.md) |
-
 |    | Linux containers on Linux hosts | Linux containers on Windows hosts |
 |--| ----- | ---------------- |
 | **Manual provisioning (single device)** | [X.509 certificates](how-to-provision-single-device-linux-x509.md)<br><br>[Symmetric keys](how-to-provision-single-device-linux-symmetric.md) | [X.509 certificates](how-to-provision-single-device-linux-on-windows-x509.md)<br><br>[Symmetric keys](how-to-provision-single-device-linux-on-windows-symmetric.md) |
