diff --git a/memdocs/intune/enrollment/apple-account-driven-user-enrollment.md b/memdocs/intune/enrollment/apple-account-driven-user-enrollment.md index f2255eb309..70b06c97e4 100644 --- a/memdocs/intune/enrollment/apple-account-driven-user-enrollment.md +++ b/memdocs/intune/enrollment/apple-account-driven-user-enrollment.md @@ -51,8 +51,13 @@ Before beginning setup, complete the following tasks: You also need to set up service discovery so that Apple can reach the Intune service and retrieve enrollment information. To complete this prerequisite, set up and publish an HTTP well-known resource file on the same domain that employees sign into. Apple retrieves the file via an HTTP GET request to `“https://contoso.com/.well-known/com.apple.remotemanagement”`, with your organization's domain in place of `contoso.com`. Publish the file on a domain that can handle HTTP GET requests. + +> [!NOTE] +> The well-known resource file must be saved without a file extension, such as .json, to function correctly. + Create the file in JSON format, with the content type set to `application/json`. We provide the following JSON samples that you can copy and paste into your file. Use the one that aligns with your environment. Replace the *YourAADTenantID* variable in the base URL with your organization's Microsoft Entra tenant ID. + Microsoft Intune environments: ```json {"Servers":[{"Version":"mdm-byod", "BaseURL":"https://manage.microsoft.com/EnrollmentServer/PostReportDeviceInfoForUEV2?aadTenantId=YourAADTenantID"}]} @@ -72,7 +77,10 @@ Create the file in JSON format, with the content type set to `application/json`. The rest of the JSON sample is populated with all of the information you need, including: * Version: The server version is `mdm-byod`. -* BaseURL: This URL is the location where the Intune service resides. +* BaseURL: This URL is the location where the Intune service resides. + +> [!TIP] +> For more information about the technical requirements for service discovery, see [Implementing the simple authentication user-enrollment flow](https://developer.apple.com/documentation/devicemanagement/user_enrollment/onboarding_users_with_account_sign-in/implementing_the_simple_authentication_user-enrollment_flow) in the Apple Developer documentation. ## Best practices We recommend extra configurations to help improve the enrollment experience for device users. This section provides more information about each recommendation. diff --git a/memdocs/intune/enrollment/corporate-identifiers-add.md b/memdocs/intune/enrollment/corporate-identifiers-add.md index 83e3a98b57..9050d63eb2 100644 --- a/memdocs/intune/enrollment/corporate-identifiers-add.md +++ b/memdocs/intune/enrollment/corporate-identifiers-add.md @@ -9,11 +9,6 @@ ms.author: lanewsad manager: dougeby ms.date: 08/08/2024 ms.topic: how-to -ms.service: microsoft-intune -ms.subservice: enrollment -ms.localizationpriority: high -ms.assetid: 566ed16d-8030-42ee-bac9-5f8252a83012 - # optional metadata #ROBOTS: @@ -120,7 +115,7 @@ Android serial numbers aren't guaranteed to be unique or present. Check with you ### Add Windows corporate identifiers > [!IMPORTANT] -> Corporate identifiers are supported for devices running Windows 10 KB5039299 (with OS Build 19045.4598) and later. If you're enrolling Windows 10 devices with an earlier build, do not use the corporate identifier feature. +> Windows corporate identifiers only apply at enrollment time. They don't determine ownership type in Intune after enrollment. Corporate identifiers are supported for devices running Windows 10 KB5039299 (with OS Build 19045.4598) and later. If you're enrolling Windows 10 devices with an earlier build, do not use the corporate identifier feature. To add corporate identifiers for corporate devices running Windows 11, list the manufacturer, model, and serial number for each device as shown in the following example. @@ -131,11 +126,14 @@ Lenovo,thinkpad t14,02234567890123 Remove all periods, if applicable, from the serial number before you add it to the file. -After you add Windows corporate identifiers, Intune marks devices that match all three identifiers as corporate-owned, and marks all other enrolling devices in your tenant as personal. This means that anything you exclude from the Windows corporate identifiers is marked personal. To change the ownership type after enrollment, you have to manually adjust it in the admin center. +After you add Windows corporate identifiers, Intune marks devices that match all three identifiers as corporate-owned, and marks all other enrolling devices in your tenant as personal. This means that anything you exclude from the Windows corporate identifiers is marked personal, but only at enrollment time. Existing Windows logic determines the final state in Intune. For more information, see the table in this section. To change the ownership type in Intune, you have to manually adjust it in the admin center. :::image type="content" source="./media/corporate-identifiers-add/device-enrollment-add-identifiers.png" alt-text="Screenshot of selecting and adding corporate identifiers."::: -The following table lists the type of ownership given to devices when they enroll without corporate identifiers and when they enroll with corporate identifiers. +The following table lists the type of ownership given to devices when they enroll without corporate identifiers and when they enroll with corporate identifiers. + +>[!TIP] +> As a reminder, corporate identifiers only change the device state at enrollment time. This means that after the device enrolls, the device state matches what you see in the **Without corporate identifiers** column in the table. |Windows enrollment types | Without corporate identifiers | With corporate identifiers | |---|---|---| @@ -153,7 +151,7 @@ The following table lists the type of ownership given to devices when they enrol | [Enrollment using the Intune Company Portal app](../user-help/enroll-windows-10-device.md) | Personal | Personal, unless defined by corporate identifiers | | Enrollment via a Microsoft 365 app, which occurs when users select the **Allow my organization to manage my device** option during app sign-in | Personal | Personal, unless defined by corporate identifiers | -Windows corporate identifiers can only change ownership type if someone adds them to Microsoft Intune. If you don't have corporate identifiers for Windows in Intune, or if you remove them, devices that are Microsoft Entra domain joined are marked as corporate-owned. This includes devices enrolled via [automatic MDM enrollment](windows-enroll.md#enable-windows-automatic-enrollment) with: +Windows corporate identifiers can only change ownership type if someone adds them to Microsoft Intune. If you don't have corporate identifiers for Windows in Intune, or if you remove them, devices that are Microsoft Entra domain joined are marked as corporate-owned at enrollment time. This includes devices enrolled via [automatic MDM enrollment](windows-enroll.md#enable-windows-automatic-enrollment) with: - [Microsoft Entra join during Windows setup](/azure/active-directory/device-management-azuread-joined-devices-frx). @@ -222,7 +220,7 @@ Follow up on imported devices to ensure that they enroll in Intune. After you ad 1. Select the device identifiers you want to delete, and choose **Delete**. 1. Confirm the deletion. -Deleting a corporate identifier for an enrolled device does not change the device's ownership. +Deleting a corporate identifier for an enrolled device doesn't change the device's ownership. ## Change device ownership @@ -247,6 +245,8 @@ To confirm the reason for an enrollment failure, go to **Devices** > **Enrollmen ## Known issues and limitations +- Windows corporate device identifiers only apply at enrollment time. This means that when a device with corporate identifiers enrolls using the *Add Work Account from Windows Settings* option, it's marked as corporate-owned only at enrollment time. Microsoft Intune treats it as a corporate device for the enrollment restriction evaluation, but then after that the device appears as a personal device in the admin center. See the table under [Add Windows corporate identifiers](#add-windows-corporate-identifiers) to help you determine the ownership type. Look to the **Without corporate identifiers** column to learn which devices remain corporate or personal in your tenant for the long-term. + - Windows corporate device identifiers are only supported for devices running: - Windows 10 version 22H2 (OS build 19045.4598) or later. @@ -261,7 +261,7 @@ To confirm the reason for an enrollment failure, go to **Devices** > **Enrollmen - Windows currently doesn't support device details in CSV files. -- Apple user enrollment with Company Portal and account driven user enrollment corporate identifiers are not currently supported because the MDM does not get access to the device serial number, IMEI, and UDID. +- Apple user enrollment with Company Portal and account driven user enrollment corporate identifiers aren't currently supported because the MDM doesn't get access to the device serial number, IMEI, and UDID. ## Resources diff --git a/memdocs/intune/enrollment/enrollment-restrictions-set.md b/memdocs/intune/enrollment/enrollment-restrictions-set.md index 93079dc5b6..aa12007f24 100644 --- a/memdocs/intune/enrollment/enrollment-restrictions-set.md +++ b/memdocs/intune/enrollment/enrollment-restrictions-set.md @@ -156,7 +156,8 @@ Intune also blocks personal devices using these enrollment methods: * Enrollment restrictions are applied to enrollments that are user-driven. Intune enforces the default policy in enrollment scenarios that aren't user-driven, such as: * Windows Autopilot self-deploying mode and Autopilot for pre-provisioned deployment - * Bulk enrollment via Windows Configuration Designer + * Bulk enrollment via Windows Configuration Designer + * Co-managed enrollments * Userless Apple automated device enrollment (without user-device affinity) * Azure Virtual Desktop * Windows 365 diff --git a/memdocs/intune/enrollment/multi-factor-authentication.md b/memdocs/intune/enrollment/multi-factor-authentication.md index cc9bad1e8f..6668def27e 100644 --- a/memdocs/intune/enrollment/multi-factor-authentication.md +++ b/memdocs/intune/enrollment/multi-factor-authentication.md @@ -8,7 +8,7 @@ keywords: author: Lenewsad ms.author: lanewsad manager: dougeby -ms.date: 01/23/2024 +ms.date: 12/11/2024 ms.topic: how-to ms.service: microsoft-intune ms.subservice: enrollment @@ -34,41 +34,45 @@ ms.collection: *Applies to*: * Android * iOS/iPadOS - * macOS - * Windows 8.1 + * macOS * Windows 10 * Windows 11 -You can use Intune together with Microsoft Entra Conditional Access policies to require multifactor authentication (MFA) during device enrollment. If you require MFA, employees and students wanting to enroll devices must first authenticate with a second device and two forms of credentials. MFA requires them to authenticate using two or more of these verification methods: +You can use Intune together with Microsoft Entra Conditional Access policies to require multifactor authentication (MFA) during device enrollment. If you require MFA, employees and students wanting to enroll devices must first authenticate with a second device and two forms of credentials. MFA requires them to authenticate using two or more of these verification methods: - Something they know, such as a password or PIN. - Something they have that can't be duplicated, such as a trusted device or phone. -- Something they are, such as a fingerprint. +- Something they are, such as a fingerprint. + +If a device isn't compliant, the device user is prompted to make the device compliant before enrolling in Microsoft Intune. ## Prerequisites To implement this policy, you must assign Microsoft Entra ID P1 or later to users. ## Configure Intune to require multifactor authentication at device enrollment -Complete these steps to enable multi-factor authentication during Microsoft Intune enrollment. +Complete these steps to enable multifactor authentication during Microsoft Intune enrollment. > [!IMPORTANT] > Don't configure **Device based access rules** for Microsoft Intune enrollment. 1. Sign in to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Go to **Devices** > **Conditional Access**. This area is the same as the Conditional Access area available in the Microsoft Entra admin center. For more information about the available settings, see [Building a Conditional Access policy](/entra/identity/conditional-access/concept-conditional-access-policies). +1. Go to **Devices**. +1. Expand **Manage devices**, and then select **Conditional access**. This conditional access area is the same as the conditional access area available in the Microsoft Entra admin center. For more information about the available settings, see [Building a Conditional Access policy](/entra/identity/conditional-access/concept-conditional-access-policies). 1. Choose **Create new policy**. 1. Name your policy. 1. Select the **Users** category. 1. Under the **Include** tab, choose **Select users or groups**. 2. Additional options appear. Select **Users and groups**. A list of users and groups opens. - 3. Add the users or groups you're assigning the policy to, and then choose **Select**. + 3. Browse and select the Microsoft Entra users or groups you want to include in the policy. Then choose **Select**. 4. To exclude users or groups from the policy, select the **Exclude** tab and add those users or groups like you did in the previous step. -1. Select the next category, **Target resources**. - 1. Select the **Include** tab. - 2. Choose **Select apps** > **Select**. - 3. Choose **Microsoft Intune Enrollment** > **Select** to add the app. Use the search bar in the app picker to find the app. +1. Select the next category, **Target resources**. In this step, you select the resources that the policy applies to. In this case, we want the policy to apply to events where users or groups try to access the Microsoft Intune Enrollment app. + 1. Under **Select what this policy applies to**, choose **Resources (formerly cloud apps)**. + 2. Select the **Include** tab. + 3. Choose **Select resources**. Additional options appear. + 4. Under **Select**, choose **None**. A list of resources open. + 5. Search for **Microsoft Intune Enrollment**. Then choose **Select** to add the app. For Apple automated device enrollments using Setup Assistant with modern authentication, you have two options to choose from. The following table describes the difference between the *Microsoft Intune* option and *Microsoft Intune Enrollment* option. @@ -80,17 +84,20 @@ Complete these steps to enable multi-factor authentication during Microsoft Intu > [!NOTE] > The Microsoft Intune Enrollment cloud app isn't created automatically for new tenants. To add the app for new tenants, a Microsoft Entra administrator must create a service principal object, with app ID d4ebce55-015a-49b5-a083-c84d1797ae8c, in PowerShell or Microsoft Graph. -1. Select the **Grant** category. - 1. Select **Require multifactor authentication** and **Require device to be marked as compliant**. +1. Select the **Grant** category. In this step, you grant or block access to the Microsoft Intune Enrollment app. + 1. Choose **Grant access**. + 1. Select **Require multifactor authentication**. + 1. Select **Require device to be marked as compliant**. 1. Under **For multiple controls**, select **Require all the selected controls**. 1. Choose **Select**. -1. Select the **Session** category. - 1. Select **Sign-in frequency** and choose **Every time**. +1. Select the **Session** category. In this step, you can make use of session controls to enable limited experiences within the Microsoft Intune Enrollment app. + 1. Select **Sign-in frequency**. Additional options appear. + 1. Choose **Every time**. 1. Choose **Select**. 1. For **Enable policy**, select **On**. 1. Select **Create** to save and create your policy. -After you apply and deploy this policy, users will see a one-time MFA prompt when they enroll their device. +After you apply and deploy this policy, device users enrolling their devices see a one-time MFA prompt. > [!NOTE] > A second device or a Temporary Access Pass is required to complete the MFA challenge for these types of corporate-owned devices: diff --git a/memdocs/intune/fundamentals/filters-performance-recommendations.md b/memdocs/intune/fundamentals/filters-performance-recommendations.md index ac621616ac..85ad174633 100644 --- a/memdocs/intune/fundamentals/filters-performance-recommendations.md +++ b/memdocs/intune/fundamentals/filters-performance-recommendations.md @@ -7,7 +7,7 @@ keywords: author: MandiOhlinger ms.author: mandia manager: dougeby -ms.date: 07/22/2024 +ms.date: 12/11/2024 ms.topic: conceptual ms.service: microsoft-intune ms.subservice: fundamentals @@ -89,6 +89,8 @@ These recommendations focus on improving performance and reducing latency in wor Larger groups take longer to sync membership updates between Microsoft Entra ID and Intune. The **All users** and **All devices** are usually the largest groups you have. If you assign Intune workloads to large Microsoft Entra groups that have many users or devices, then synchronization backlogs can happen in your Intune environment. This backlog impacts policy and app deployments, which take longer to reach managed devices. +The update from Microsoft Entra to Intune typically happens within 5 minutes. It's not instant. This time can affect enrollment assignments. Admins should enroll devices after several minutes, not immediately after adding the enrolling users to a group. + The built-in **All users** and **All devices** groups are Intune-only grouping objects that don't exist in Microsoft Entra ID. There isn't a continuous sync between Microsoft Entra ID and Intune. So, group membership is instant. > [!NOTE] diff --git a/memdocs/intune/protect/microsoft-tunnel-upgrade.md b/memdocs/intune/protect/microsoft-tunnel-upgrade.md index 3dfa61e19f..5a4851493a 100644 --- a/memdocs/intune/protect/microsoft-tunnel-upgrade.md +++ b/memdocs/intune/protect/microsoft-tunnel-upgrade.md @@ -139,6 +139,9 @@ Image hash values: Changes in this release: -Diagnostic tool improvements +-Bug fixes for rootless container mode in mst-cli +-Localization improvements in mstunnel-setup + ### October 2, 2024 @@ -600,4 +603,4 @@ Changes in this release: The initial public preview release of Microsoft Tunnel. -End of archive --> \ No newline at end of file +End of archive --> diff --git a/windows-365/enterprise/move-cloud-pc.md b/windows-365/enterprise/move-cloud-pc.md index 174dcfd334..8e1d1fd1c8 100644 --- a/windows-365/enterprise/move-cloud-pc.md +++ b/windows-365/enterprise/move-cloud-pc.md @@ -7,7 +7,7 @@ keywords: author: ErikjeMS ms.author: erikje manager: dougeby -ms.date: 07/25/2024 +ms.date: 12/06/2024 ms.topic: how-to ms.service: windows-365 ms.subservice: windows-365-enterprise @@ -31,45 +31,47 @@ ms.collection: # Move a Cloud PC -By editing a provisioning policy, you can move existing Cloud PCs from their current region or Azure network connection (ANC) to a new one. +By editing a provisioning policy, you can move some or all existing Cloud PCs in a policy from: -The best time to perform moves is over the weekend to make sure the impact to users is minimized. Cloud PCs are shut down during the move process, so you should notify your users before the move so that they can save their work and sign out. +- One region to another single region. +- One Azure network connection (ANC) to another ANC. +- A Microsoft hosted network to an ANC and vice versa. -New Cloud PCs created by the edited provisioning policy are assigned to the new region or ANC. +## Bulk move all Cloud PCs in a policy -## Move a Cloud PC +[!INCLUDE [Move a Cloud PC first steps](../includes/move-cloud-pc-steps.md)] +6. In the **Apply this configuration to existing Cloud PCs** box, select **Region or Azure network connections for all devices** > **Apply**. -1. Sign in to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices** > **Windows 365** (under **Provisioning**) > **Provisioning policies** > select a policy. -2. Under **General**, select **Edit**. -3. Under **Join type details**, make changes depending on the original type: - - - For **Hybrid Microsoft Entra Join**, change the ANC\*. - - For **Microsoft Entra Join**: +\* The domain defined in the new ANC must match that of the Cloud PCs that you want to move. The domain used in the original ANC must be reachable from the new ANC. - - You can change **Network** type from ANC to Microsoft hosted network, or vice versa. - - If a **Microsoft hosted network** is used, change the **Geography** and/or **Region**. - - If an **Azure network connection** is used, change the ANC\*. +All Cloud PCs provisioned after these changes are created in the new region. -4. Select **Next** > **Update**. -5. When ready to move the existing Cloud PCs, select **Apply region change to existing Cloud PCs**. +## Move a subset of Cloud PCs -\* The domain defined in the new ANC must match that of the Cloud PCs that you want to move. The domain used in the original ANC must be reachable from the new ANC. +[!INCLUDE [Move a Cloud PC first steps](../includes/move-cloud-pc-steps.md)] +6. In the **Apply this configuration to existing Cloud PCs** box, select **Region or Azure network connections for select devices (preview)** > **Apply**. +7. Under **Select devices (preview)**, select the devices that you want to move. You can move up to 100 devices at a time. +8. Choose **Select** > **Continue**. -All Cloud PCs provisioned after these changes are created in the new region. +## Best practices -## Move process +The best time to perform moves is over the weekend to make sure the impact to users is minimized. Cloud PCs are shut down and inaccessible for up to several hours during the move process. You should notify your users before the move so that they can save their work and sign out. + +When moving many devices to a new region, start with a few non-critical Cloud PCs and check for success before moving the critical Cloud PCs. + +You can track the status of moving Cloud PCs with the [Cloud PC actions report](report-cloud-pc-actions.md). + +New Cloud PCs created by the edited provisioning policy are assigned to the new region or ANC. -1. All Cloud PCs in the move are backed up before being moved to the new region. This backup, which can take some time, can begin while the user is signed in and active. -2. After the backup is complete, the Cloud PC is shut down. -3. The Cloud PC is moved. During this time, which can take several hours, the Cloud PC is inaccessible. +## Other move operations - - During the move, you can view the status in the **All Cloud PCs** list. The move is complete when the status indicates **Provisioned**. +Cloud PCs can't be moved from one provisioning policy to another. -4. After the move is complete, users can sign in. +You can't move some Cloud PCs to one region and other Cloud PCs to another region in the same policy edit operation. -If an error occurs, you retry the move. +You can't move Cloud PCs from one virtual network or subnet to another using the edit provisioning policy method. To make VNet/subnet changes, create a new ANC with the updated vNet/subnet and then move the Cloud PCs to the new ANC. ## Next steps -[Manage your Cloud PCs](device-management-overview.md). +[Manage your Cloud PCs](device-management-overview.md). \ No newline at end of file diff --git a/windows-365/enterprise/whats-new.md b/windows-365/enterprise/whats-new.md index 75235e6384..b9df59b678 100644 --- a/windows-365/enterprise/whats-new.md +++ b/windows-365/enterprise/whats-new.md @@ -55,6 +55,16 @@ For more information about public preview items, see [Public preview in Windows ### Windows 365 app --> + +## Week of December 9, 2024 + + +### Device management + +#### Move selected Cloud PCs to a new region + +You can now move selected Cloud PCs to a new region. This is instead of moving all Cloud PCs in a provisioning policy. + ## Week of December 2, 2024 (Service release 2411)