Merge pull request #245375 from MicrosoftDocs/main

7/18/2023 PM Publish

Author: Taojunshen

.openpublishing.publish.config.json

@@ -1015,7 +1015,13 @@
       "url": "https://github.com/Azure/actions-workflow-samples",
       "branch": "master",
       "branch_mapping": {}
-    }  
+    },
+    {
+      "path_to_root": "azure-proactive-resiliency-library",
+      "url": "https://github.com/Azure/Azure-Proactive-Resiliency-Library",
+      "branch": "main",
+      "branch_mapping": {}
+    }
   ],
   "branch_target_mapping": {
     "live": ["Publish", "PDF"],

.openpublishing.redirection.json

@@ -24032,6 +24032,11 @@
             "source_path_from_root": "/articles/container-registry/github-action-scan.md",
             "redirect_url": "/azure/developer/github/",
             "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/virtual-machines/virtual-machines-reliability.md",
+            "redirect_url": "/azure/virtual-machines/reliability-virtual-machines",
+            "redirect_document_id": true
         }
     ]
 }

CODEOWNERS

@@ -39,7 +39,7 @@ articles/service-health @rboucher
 /articles/synapse-analytics/synapse-link/ @Rodrigossz @SnehaGunda @jovanpop-msft
 
 # Cognitive Services
-/articles/cognitive-services/ @aahill @patrickfarley @nitinme @mrbullwinkle @laujan @eric-urban @jboback
+/articles/ai-services/ @aahill @patrickfarley @nitinme @mrbullwinkle @laujan @eric-urban @jboback
 
 # DevOps
 /articles/ansible/ @TomArcherMsft

articles/active-directory-domain-services/policy-reference.md

@@ -1,7 +1,7 @@
 ---
 title: Built-in policy definitions for Azure Active Directory Domain Services
 description: Lists Azure Policy built-in policy definitions for Azure Active Directory Domain Services. These built-in policy definitions provide common approaches to managing your Azure resources.
-ms.date: 07/06/2023
+ms.date: 07/18/2023
 ms.service: active-directory
 ms.subservice: domain-services
 author: justinha

articles/active-directory/app-provisioning/application-provisioning-config-problem-scim-compatibility.md

@@ -96,40 +96,39 @@ Below are sample requests to help outline what the sync engine currently sends v
 
 **Without feature flag**
   ```json
-{
+  {
     "schemas": [
         "urn:ietf:params:scim:api:messages:2.0:PatchOp"
     ],
     "Operations": [
-    {
+      {
         "op": "Add",
         "path": "nickName",
         "value": "Babs"
-     }
-   ]
-}
-
+      }
+    ]
+  }
   ```
 
 **With feature flag**
   ```json
-{
-  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
-  "Operations": [
-    {
-      "op": "add",
-      "path": "nickName",
-      "value": "Babs"
-    }
-  ]
-}
+  {
+    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
+    "Operations": [
+      {
+        "op": "add",
+        "path": "nickName",
+        "value": "Babs"
+      }
+    ]
+  }
   ```
 
 **Requests to replace multiple attributes:**
 
 **Without feature flag**
   ```json
-{
+  {
     "schemas": [
         "urn:ietf:params:scim:api:messages:2.0:PatchOp"
     ],
@@ -165,12 +164,12 @@ Below are sample requests to help outline what the sync engine currently sends v
             "value": "Eqpj"
         }
     ]
-}
+  }
   ```
 
 **With feature flag**
   ```json
-{
+  {
     "schemas": [
         "urn:ietf:params:scim:api:messages:2.0:PatchOp"
     ],
@@ -190,14 +189,14 @@ Below are sample requests to help outline what the sync engine currently sends v
             }
         }
     ]
-} 
+  }
   ```
 
 **Requests made to remove a group member:**
 
 **Without feature flag**
   ```json
-{
+  {
     "schemas": [
         "urn:ietf:params:scim:api:messages:2.0:PatchOp"
     ],
@@ -212,12 +211,12 @@ Below are sample requests to help outline what the sync engine currently sends v
             ]
         }
     ]
-} 
+  }
   ```
 
 **With feature flag**
   ```json
-{
+  {
     "schemas": [
         "urn:ietf:params:scim:api:messages:2.0:PatchOp"
     ],
@@ -227,10 +226,9 @@ Below are sample requests to help outline what the sync engine currently sends v
             "path": "members[value eq \"7f4bc1a3-285e-48ae-8202-5accb43efb0e\"]"
         }
     ]
-}
+  }
   ```
 
-
   * **Downgrade URL:** Once the new SCIM compliant behavior becomes the default on the non-gallery application, you can use the following URL to roll back to the old, non SCIM compliant behavior: AzureAdScimPatch2017
 
 

articles/active-directory/authentication/concept-authentication-phone-options.md

@@ -19,9 +19,9 @@ ms.collection: M365-identity-device-management
 
 # Authentication methods in Azure Active Directory - phone options
 
-For direct authentication using text message, you can [Configure and enable users for SMS-based authentication](howto-authentication-sms-signin.md). SMS-based sign-in is great for Frontline workers. With SMS-based sign-in, users don't need to know a username and password to access applications and services. The user instead enters their registered mobile phone number, receives a text message with a verification code, and enters that in the sign-in interface.
+Microsoft recommends users move away from using SMS or voice calls for multifactor authentication (MFA). Modern authentication methods like [Microsoft Authenticator](concept-authentication-authenticator-app.md) are a recommended alternative. For more information, see [It's Time to Hang Up on Phone Transports for Authentication](https://aka.ms/hangup). Users can still verify themselves using a mobile phone or office phone as secondary form of authentication used for multifactor authentication (MFA) or self-service password reset (SSPR).
 
-Users can also verify themselves using a mobile phone or office phone as secondary form of authentication used during Azure AD Multi-Factor Authentication or self-service password reset (SSPR). Azure AD Multi-Factor Authentication and SSPR support phone extensions only for office phones.
+You can [configure and enable users for SMS-based authentication](howto-authentication-sms-signin.md) for direct authentication using text message. SMS-based sign-in is convenient for Frontline workers. With SMS-based sign-in, users don't need to know a username and password to access applications and services. The user instead enters their registered mobile phone number, receives a text message with a verification code, and enters that in the sign-in interface.
 
 >[!NOTE]
 >Phone call verification isn't available for Azure AD tenants with trial subscriptions. For example, if you sign up for a trial license Microsoft Enterprise Mobility and Security (EMS), phone call verification isn't available. Phone numbers must be provided in the format *+CountryCode PhoneNumber*, for example, *+1 4251234567*. There must be a space between the country/region code and the phone number.
@@ -30,10 +30,13 @@ Users can also verify themselves using a mobile phone or office phone as seconda
 
 For Azure AD Multi-Factor Authentication or SSPR, users can choose to receive an SMS message with a verification code to enter in the sign-in interface, or receive a phone call.
 
-If users don't want their mobile phone number to be visible in the directory but want to use it for password reset, administrators shouldn't populate the phone number in the directory. Instead, users should populate their **Authentication Phone** attribute via the combined security info registration at [https://aka.ms/setupsecurityinfo](https://aka.ms/setupsecurityinfo). Administrators can see this information in the user's profile, but it's not published elsewhere.
+If users don't want their mobile phone number to be visible in the directory but want to use it for password reset, administrators shouldn't populate the phone number in the directory. Instead, users should populate their **Authentication Phone** at [My Sign-Ins](https://aka.ms/setupsecurityinfo). Administrators can see this information in the user's profile, but it's not published elsewhere.
 
 :::image type="content" source="media/concept-authentication-methods/user-authentication-methods.png" alt-text="Screenshot of the Azure portal that shows authentication methods with a phone number populated":::
 
+> [!NOTE]
+> Phone extensions are supported only for office phones.
+
 Microsoft doesn't guarantee consistent SMS or voice-based Azure AD Multi-Factor Authentication prompt delivery by the same number. In the interest of our users, we may add or remove short codes at any time as we make route adjustments to improve SMS deliverability. Microsoft doesn't support short codes for countries/regions besides the United States and Canada.
 
 > [!NOTE]

articles/active-directory/authentication/concept-registration-mfa-sspr-combined.md

@@ -171,6 +171,13 @@ Or, you can specify a tenant by URL to access security information.
 
 `https://mysignins.microsoft.com/security-info/?tenantId=<Tenant ID>`
 
+> [!NOTE]
+> Customers attempting to register or manage security info through combined registration or the My Sign-ins page should use a modern browser such as Microsoft Edge. 
+> 
+> IE11 is not officially supported for creating a webview or browser in applications as it will not work as expected in all scenarios.
+> 
+> Applications that have not been updated and are still using Azure AD Authentication Library (ADAL) that rely on legacy webviews can fallback to older versions of IE. In these scenarios, users will experience a blank page when directed to the My Sign-ins page. To resolve this issue, switch to a modern browser.
+
 ## Next steps
 
 To get started, see the tutorials to [enable self-service password reset](tutorial-enable-sspr.md) and [enable Azure AD Multi-Factor Authentication](tutorial-enable-azure-mfa.md).

articles/active-directory/conditional-access/TOC.yml

@@ -88,6 +88,8 @@
       href: howto-policy-unknown-unsupported-device.md
     - name: Require approved app or app protection policy
       href: howto-policy-approved-app-or-app-protection.md
+    - name: Require app protection policy for Windows
+      href: how-to-app-protection-policy-windows.md
     - name: No persistent browser session
       href: howto-policy-persistent-browser-session.md
     - name: Require compliant device, hybrid joined, or MFA for users

articles/active-directory/conditional-access/concept-conditional-access-grant.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 02/16/2023
+ms.date: 06/26/2023
 ms.author: joflore
 author: MicrosoftGuyJFlo
 manager: amycolannino
@@ -59,16 +59,17 @@ Administrators can choose to require [specific authentication strengths](../auth
 
 Organizations that have deployed Intune can use the information returned from their devices to identify devices that meet specific policy compliance requirements. Intune sends compliance information to Azure AD so Conditional Access can decide to grant or block access to resources. For more information about compliance policies, see [Set rules on devices to allow access to resources in your organization by using Intune](/intune/protect/device-compliance-get-started).
 
-A device can be marked as compliant by Intune for any device operating system or by a third-party mobile device management system for Windows 10 devices. You can find a list of supported third-party mobile device management systems in [Support third-party device compliance partners in Intune](/mem/intune/protect/device-compliance-partners).
+A device can be marked as compliant by Intune for any device operating system or by a third-party mobile device management system for Windows devices. You can find a list of supported third-party mobile device management systems in [Support third-party device compliance partners in Intune](/mem/intune/protect/device-compliance-partners).
 
 Devices must be registered in Azure AD before they can be marked as compliant. You can find more information about device registration in [What is a device identity?](../devices/overview.md).
 
 The **Require device to be marked as compliant** control:
+
    - Only supports Windows 10+, iOS, Android, and macOS devices registered with Azure AD and enrolled with Intune.
-   - Considers Microsoft Edge in InPrivate mode a non-compliant device.
+   - Microsoft Edge in InPrivate mode is considered a non-compliant device.
 
 > [!NOTE]
-> On Windows 7, iOS, Android, macOS, and some third-party web browsers, Azure AD identifies the device by using a client certificate that is provisioned when the device is registered with Azure AD. When a user first signs in through the browser, the user is prompted to select the certificate. The user must select this certificate before they can continue to use the browser.
+> On Windows, iOS, Android, macOS, and some third-party web browsers, Azure AD identifies the device by using a client certificate that is provisioned when the device is registered with Azure AD. When a user first signs in through the browser, the user is prompted to select the certificate. The user must select this certificate before they can continue to use the browser.
 
 You can use the Microsoft Defender for Endpoint app with the approved client app policy in Intune to set the device compliance policy to Conditional Access policies. There's no exclusion required for the Microsoft Defender for Endpoint app while you're setting up Conditional Access. Although Microsoft Defender for Endpoint on Android and iOS (app ID dd47d17a-3194-4d86-bfd5-c6ae6f5651e3) isn't an approved app, it has permission to report device security posture. This permission enables the flow of compliance information to Conditional Access.
 
@@ -88,7 +89,7 @@ Organizations can require that an approved client app is used  to access selecte
 
 To apply this grant control, the device must be registered in Azure AD, which requires using a broker app. The broker app can be Microsoft Authenticator for iOS, or either Microsoft Authenticator or Microsoft Company Portal for Android devices. If a broker app isn't installed on the device when the user attempts to authenticate, the user is redirected to the appropriate app store to install the required broker app.
 
-The following client apps support this setting, this list isn't exhaustive and is subject to change::
+The following client apps support this setting. This list isn't exhaustive and is subject to change:
 
 - Microsoft Azure Information Protection
 - Microsoft Cortana
@@ -131,13 +132,13 @@ See [Require approved client apps for cloud app access with Conditional Access](
 
 ### Require app protection policy
 
-In your Conditional Access policy, you can require that an [Intune app protection policy](/intune/app-protection-policy) is present on the client app before access is available to the selected cloud apps.
+In Conditional Access policy, you can require that an [Intune app protection policy](/intune/app-protection-policy) is present on the client app before access is available to the selected applications. These mobile application management (MAM) app protection policies allow you to manage and protect your organization's data within specific applications.
 
-To apply this grant control, Conditional Access requires that the device is registered in Azure AD, which requires using a broker app. The broker app can be either Microsoft Authenticator for iOS or Microsoft Company Portal for Android devices. If a broker app isn't installed on the device when the user attempts to authenticate, the user is redirected to the app store to install the broker app.
+To apply this grant control, Conditional Access requires that the device is registered in Azure AD, which requires using a broker app. The broker app can be either Microsoft Authenticator for iOS or Microsoft Company Portal for Android devices. If a broker app isn't installed on the device when the user attempts to authenticate, the user is redirected to the app store to install the broker app. App protection policies are generally available for iOS and Android, and in public preview for Microsoft Edge on Windows. [Windows devices support no more than 3 Azure AD user accounts in the same session](../devices/faq.yml#i-can-t-add-more-than-3-azure-ad-user-accounts-under-the-same-user-session-on-a-windows-10-11-device--why). For more information about how to apply policy to Windows devices, see the article [Require an app protection policy on Windows devices (preview)](how-to-app-protection-policy-windows.md).
 
-Applications must have the Intune SDK with policy assurance implemented and must meet certain other requirements to support this setting. Developers who are implementing applications with the Intune SDK can find more information on these requirements in the [SDK documentation](/mem/intune/developer/app-sdk-get-started).
+Applications must meet certain requirements to support app protection policies. Developers can find more information about these requirements in the section [Apps you can manage with app protection policies](/mem/intune/apps/app-protection-policy#apps-you-can-manage-with-app-protection-policies). 
 
-The following client apps are confirmed to support this setting, this list isn't exhaustive and is subject to change:
+The following client apps support this setting. This list isn't exhaustive and is subject to change. If your app isn't in the list please check with the application vendor to confirm support:
 
 - Adobe Acrobat Reader mobile app
 - iAnnotate for Office 365
@@ -168,23 +169,14 @@ The following client apps are confirmed to support this setting, this list isn't
 - Provectus - Secure Contacts
 - Yammer (Android, iOS, and iPadOS)
 
-This list isn't all encompassing, if your app isn't in this list please check with the application vendor to confirm support.
-
 > [!NOTE]
 > Kaizala, Skype for Business, and Visio don't support the **Require app protection policy** grant. If you require these apps to work, use the **Require approved apps** grant exclusively. Using the "or" clause between the two grants will not work for these three applications.
 
-Apps for the app protection policy support the Intune mobile application management feature with policy protection.
-
-The **Require app protection policy** control:
-
-- Only supports iOS and Android for device platform condition.
-- Requires a broker app to register the device. On iOS, the broker app is Microsoft Authenticator. On Android, the broker app is Intune Company Portal.
-
 See [Require app protection policy and an approved client app for cloud app access with Conditional Access](app-protection-based-conditional-access.md) for configuration examples.
 
 ### Require password change
 
-When user risk is detected, administrators can employ the user risk policy conditions to have the user securely change a password by using Azure AD self-service password reset. Users can perform a self-service password reset to self-remediate. This process will close the user risk event to prevent unnecessary alerts for administrators.
+When user risk is detected, administrators can employ the user risk policy conditions to have the user securely change a password by using Azure AD self-service password reset. Users can perform a self-service password reset to self-remediate. This process closes the user risk event to prevent unnecessary alerts for administrators.
 
 When a user is prompted to change a password, they'll first be required to complete multifactor authentication. Make sure all users have registered for multifactor authentication, so they're prepared in case risk is detected for their account.