mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 13:27:23 +00:00
MDM Freshness
This commit is contained in:
Vinay Pamnani (from Dev Box)
parent
12c776784b
commit
6b576d9549
@ -5,18 +5,18 @@ ms.topic: conceptual
|
||||
ms.collection:
|
||||
- highpri
|
||||
- tier2
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Microsoft Entra integration with MDM
|
||||
|
||||
Microsoft Entra ID is the world's largest enterprise cloud identity management service. It's used by organizations to access Microsoft 365 and business applications from Microsoft and third-party software as a service (SaaS) vendors. Many of the rich Windows experiences for organizational users (such as store access or OS state roaming) use Microsoft Entra ID as the underlying identity infrastructure. Windows integrates with Microsoft Entra ID, allowing devices to be registered in Microsoft Entra ID and enrolled into MDM in an integrated flow.
|
||||
Microsoft Entra ID is the world's largest enterprise cloud identity management service. It's used by organizations to access Microsoft 365 and business applications from Microsoft and third-party software as a service (SaaS) vendors. Many of the rich Windows experiences for organizational users (such as store access or OS state roaming) use Microsoft Entra ID as the underlying identity infrastructure. Windows integrates with Microsoft Entra ID, allowing devices to be registered in Microsoft Entra ID and enrolled into Mobile Device Management (MDM) in an integrated flow.
|
||||
|
||||
Once a device is enrolled in MDM, the MDM:
|
||||
|
||||
- Can enforce compliance with organization policies, add or remove apps, and more.
|
||||
- Can report a device's compliance in Microsoft Entra ID.
|
||||
- Microsoft Entra ID can allow access to organization resources or applications secured by Microsoft Entra ID to devices that comply with policies.
|
||||
- Can allow access to organization resources or applications secured by Microsoft Entra ID to devices that comply with policies.
|
||||
|
||||
To support these rich experiences with their MDM product, MDM vendors can integrate with Microsoft Entra ID.
|
||||
|
||||
@ -24,23 +24,21 @@ To support these rich experiences with their MDM product, MDM vendors can integr
|
||||
|
||||
There are several ways to connect your devices to Microsoft Entra ID:
|
||||
|
||||
- [Join device to Microsoft Entra ID](/azure/active-directory/devices/concept-azure-ad-join)
|
||||
- [Join device to on-premises AD and Microsoft Entra ID](/azure/active-directory/devices/concept-azure-ad-join-hybrid)
|
||||
- [Add a Microsoft work account to Windows](/azure/active-directory/devices/concept-azure-ad-register)
|
||||
- [Join device to Microsoft Entra ID](/entra/identity/devices/concept-directory-join)
|
||||
- [Join device to on-premises AD and Microsoft Entra ID](/entra/identity/devices/concept-hybrid-join)
|
||||
- [Add a Microsoft work account to Windows](/entra/identity/devices/concept-device-registration)
|
||||
|
||||
In each scenario, Microsoft Entra authenticates the user and the device. It provides a verified unique device identifier that can be used for MDM enrollment. The enrollment flow provides an opportunity for the MDM service to render its own UI, using a web view. MDM vendors should use the UI to render the Terms of Use (TOU), which can be different for company-owned and bring-your-own-device (BYOD) devices. MDM vendors can also use the web view to render more UI elements, such as asking for a one-time PIN.
|
||||
|
||||
In Windows 10, the web view during the out-of-the-box scenario is displayed as full-screen by default, providing MDM vendors with the capability to create a seamless edge-to-edge user experience. However, in Windows 11 the web view is rendered within an iframe. It's important that MDM vendors who integrate with Microsoft Entra ID respect the Windows design guidelines. This step includes using a responsive web design and respecting the Windows accessibility guidelines. For example, include the forward and back buttons that are properly wired to the navigation logic. More details are provided later in this article.
|
||||
|
||||
For Microsoft Entra enrollment to work for an Active Directory Federated Services (AD FS) backed Microsoft Entra account, you must enable password authentication for the intranet on the ADFS service. For more information, see [Configure Azure MFA as authentication provider with AD FS](/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa).
|
||||
For Microsoft Entra enrollment to work for an Active Directory Federated Services (AD FS) backed Microsoft Entra account, you must enable password authentication for the intranet on the ADFS service. For more information, see [Configure Microsoft Entra multifactor authentication as authentication provider with AD FS](/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa).
|
||||
|
||||
Once a user has a Microsoft Entra account added to Windows and enrolled in MDM, the enrollment can be managed through **Settings** > **Accounts** > **Access work or school**. Device management of either Microsoft Entra join for organization scenarios or BYOD scenarios is similar.
|
||||
|
||||
> [!NOTE]
|
||||
> Users can't remove the device enrollment through the **Access work or school** user interface because management is tied to the Microsoft Entra ID or work account.
|
||||
|
||||
<a name='mdm-endpoints-involved-in-azure-ad-integrated-enrollment'></a>
|
||||
|
||||
### MDM endpoints involved in Microsoft Entra integrated enrollment
|
||||
|
||||
Microsoft Entra MDM enrollment is a two-step process:
|
||||
@ -64,17 +62,15 @@ To support Microsoft Entra enrollment, MDM vendors must host and expose a **Term
|
||||
|
||||
The MDM is expected to use this information about the device (Device ID) when reporting device compliance back to Microsoft Entra ID using the [Microsoft Graph API](/azure/active-directory/develop/active-directory-graph-api). A sample for reporting device compliance is provided later in this article.
|
||||
|
||||
<a name='make-mdm-a-reliable-party-of-azure-ad'></a>
|
||||
|
||||
## Make MDM a reliable party of Microsoft Entra ID
|
||||
|
||||
To participate in the integrated enrollment flow outlined in the previous section, the MDM must consume access tokens issued by Microsoft Entra ID. To report compliance with Microsoft Entra ID, the MDM must authenticate itself to Microsoft Entra ID and obtain authorization in the form of an access token that allows it to invoke the [Microsoft Graph API](/azure/active-directory/develop/active-directory-graph-api).
|
||||
|
||||
### Cloud-based MDM
|
||||
|
||||
A cloud-based MDM is a SaaS application that provides device management capabilities in the cloud. It's a multi-tenant application. This application is registered with Microsoft Entra ID in the home tenant of the MDM vendor. When an IT admin decides to use this MDM solution, an instance of this application is made visible in the tenant of the customer.
|
||||
A cloud-based MDM is a SaaS application that provides device management capabilities in the cloud. It's a multitenant application. This application is registered with Microsoft Entra ID in the home tenant of the MDM vendor. When an IT admin decides to use this MDM solution, an instance of this application is made visible in the tenant of the customer.
|
||||
|
||||
The MDM vendor must first register the application in their home tenant and mark it as a multi-tenant application. For more information about how to add multi-tenant applications to Microsoft Entra ID, see the [Integrate an app that authenticates users and calls Microsoft Graph using the multi-tenant integration pattern (SaaS)](https://go.microsoft.com/fwlink/p/?LinkId=613661) code sample on GitHub.
|
||||
The MDM vendor must first register the application in their home tenant and mark it as a multitenant application. For more information about how to add multitenant applications to Microsoft Entra ID, see the [Integrate an app that authenticates users and calls Microsoft Graph using the multitenant integration pattern (SaaS)](https://go.microsoft.com/fwlink/p/?LinkId=613661) code sample on GitHub.
|
||||
|
||||
> [!NOTE]
|
||||
> For the MDM provider, if you don't have an existing Microsoft Entra tenant with a Microsoft Entra subscription that you manage, follow these step-by-step guides:
|
||||
@ -82,7 +78,7 @@ The MDM vendor must first register the application in their home tenant and mark
|
||||
> - [Quickstart: Create a new tenant in Microsoft Entra ID](/azure/active-directory/fundamentals/active-directory-access-create-new-tenant) to set up a tenant.
|
||||
> - [Associate or add an Azure subscription to your Microsoft Entra tenant](/azure/active-directory/fundamentals/active-directory-how-subscriptions-associated-directory) to add a subscription, and manage it via the Azure Portal.
|
||||
|
||||
The MDM application uses keys to request access tokens from Microsoft Entra ID. These keys are managed within the tenant of the MDM provider and not visible to individual customers. The same key is used by the multi-tenant MDM application to authenticate itself with Microsoft Entra ID, in the customer tenant where the managed device belongs.
|
||||
The MDM application uses keys to request access tokens from Microsoft Entra ID. These keys are managed within the tenant of the MDM provider and not visible to individual customers. The same key is used by the multitenant MDM application to authenticate itself with Microsoft Entra ID, in the customer tenant where the managed device belongs.
|
||||
|
||||
> [!NOTE]
|
||||
> All MDM apps must implement Microsoft Entra v2 tokens before we certify that integration works. Due to changes in the Microsoft Entra app platform, using Microsoft Entra v2 tokens is a hard requirement. For more information, see [Microsoft identity platform access tokens](/azure/active-directory/develop/access-tokens#token-formats).
|
||||
@ -107,8 +103,6 @@ For cloud-based MDM, you can roll over the application keys without requiring a
|
||||
|
||||
For the on-premises MDM, the Microsoft Entra authentication keys are within the customer tenant and the customer's administrator must roll over the keys. To improve security, provide guidance to customers about rolling over and protecting the keys.
|
||||
|
||||
<a name='publish-your-mdm-app-to-azure-ad-app-gallery'></a>
|
||||
|
||||
## Publish your MDM app to Microsoft Entra app gallery
|
||||
|
||||
IT administrators use the Microsoft Entra app gallery to add an MDM for their organization to use. The app gallery is a rich store with over 2400 SaaS applications that are integrated with Microsoft Entra ID.
|
||||
@ -124,7 +118,7 @@ The following table shows the required information to create an entry in the Mic
|
||||
|
||||
| Item | Description |
|
||||
|---------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **Application ID** | The client ID of your MDM app that is configured within your tenant. This ID is the unique identifier for your multi-tenant app. |
|
||||
| **Application ID** | The client ID of your MDM app that is configured within your tenant. This ID is the unique identifier for your multitenant app. |
|
||||
| **Publisher** | A string that identifies the publisher of the app. |
|
||||
| **Application URL** | A URL to the landing page of your app where your administrators can get more information about the MDM app and contains a link to the landing page of your app. This URL isn't used for the actual enrollment. |
|
||||
| **Description** | A brief description of your MDM app, which must be under 255 characters. |
|
||||
@ -191,7 +185,7 @@ The following claims are expected in the access token passed by Windows to the T
|
||||
|-----------|----------------------------------------------------------------------------------------------|
|
||||
| Object ID | Identifier of the user object corresponding to the authenticated user. |
|
||||
| UPN | A claim containing the user principal name (UPN) of the authenticated user. |
|
||||
| TID | A claim representing the tenant ID of the tenant. In the example above, it's Fabrikam. |
|
||||
| TID | A claim representing the tenant ID of the tenant. In the previous example, it's Fabrikam. |
|
||||
| Resource | A sanitized URL representing the MDM application. Example: `https://fabrikam.contosomdm.com` |
|
||||
|
||||
> [!NOTE]
|
||||
@ -206,7 +200,7 @@ https://fabrikam.contosomdm.com/TermsOfUse?redirect_uri=ms-appx-web://ContosoMdm
|
||||
Authorization: Bearer eyJ0eXAiOi
|
||||
```
|
||||
|
||||
The MDM is expected to validate the signature of the access token to ensure it is issued by Microsoft Entra ID and that the recipient is appropriate.
|
||||
The MDM is expected to validate the signature of the access token to ensure it's issued by Microsoft Entra ID and that the recipient is appropriate.
|
||||
|
||||
### Terms of Use content
|
||||
|
||||
@ -260,8 +254,6 @@ The following table shows the error codes.
|
||||
| Microsoft Entra token validation failed | 302 | unauthorized_client | unauthorized_client |
|
||||
| internal service error | 302 | server_error | internal service error |
|
||||
|
||||
<a name='enrollment-protocol-with-azure-ad'></a>
|
||||
|
||||
## Enrollment protocol with Microsoft Entra ID
|
||||
|
||||
With Azure integrated MDM enrollment, there's no discovery phase and the discovery URL is directly passed down to the system from Azure. The following table shows the comparison between the traditional and Azure enrollments.
|
||||
@ -284,8 +276,6 @@ With Azure integrated MDM enrollment, there's no discovery phase and the discove
|
||||
|EnrollmentData Terms of Use binary blob as AdditionalContext for EnrollmentServiceURL|Not supported|Supported|Supported|
|
||||
|CSPs accessible during enrollment|Windows 10 support: <br/>- DMClient <br/>- CertificateStore <br/>- RootCATrustedCertificates <br/> - ClientCertificateInstall <br/>- EnterpriseModernAppManagement <br/> - PassportForWork <br/> - Policy <br/> - w7 APPLICATION|||
|
||||
|
||||
<a name='management-protocol-with-azure-ad'></a>
|
||||
|
||||
## Management protocol with Microsoft Entra ID
|
||||
|
||||
There are two different MDM enrollment types that integrate with Microsoft Entra ID, and use Microsoft Entra user and device identities. Depending on the enrollment type, the MDM service may need to manage a single user or multiple users.
|
||||
@ -318,8 +308,6 @@ There are two different MDM enrollment types that integrate with Microsoft Entra
|
||||
- Use the JWT Token Handler extension for WIF to validate the contents of the access token and extract claims required for use. For more information, see [JwtSecurityTokenHandler Class](/dotnet/api/system.identitymodel.tokens.jwt.jwtsecuritytokenhandler).
|
||||
- Refer to the Microsoft Entra authentication code samples to get a sample for working with access tokens. For an example, see [NativeClient-DotNet](https://go.microsoft.com/fwlink/p/?LinkId=613667).
|
||||
|
||||
<a name='device-alert-1224-for-azure-ad-user-token'></a>
|
||||
|
||||
## Device Alert 1224 for Microsoft Entra user token
|
||||
|
||||
An alert is sent when the DM session starts and there's a Microsoft Entra user logged in. The alert is sent in OMA DM package #1. Here's an example:
|
||||
@ -372,15 +360,13 @@ Here's an example.
|
||||
</SyncBody>
|
||||
```
|
||||
|
||||
<a name='report-device-compliance-to-azure-ad'></a>
|
||||
|
||||
## Report device compliance to Microsoft Entra ID
|
||||
|
||||
Once a device is enrolled with the MDM for management, organization policies configured by the IT administrator are enforced on the device. MDM evaluates the device compliance with configured policies and then reports it to Microsoft Entra ID. This section covers the Graph API call you can use to report a device compliance status to Microsoft Entra ID.
|
||||
|
||||
For a sample that illustrates how an MDM can obtain an access token using OAuth 2.0 client\_credentials grant type, see [Daemon\_CertificateCredential-DotNet](https://go.microsoft.com/fwlink/p/?LinkId=613822).
|
||||
|
||||
- **Cloud-based MDM** - If your product is a cloud-based multi-tenant MDM service, you have a single key configured for your service within your tenant. To obtain authorization, use this key to authenticate the MDM service with Microsoft Entra ID.
|
||||
- **Cloud-based MDM** - If your product is a cloud-based multitenant MDM service, you have a single key configured for your service within your tenant. To obtain authorization, use this key to authenticate the MDM service with Microsoft Entra ID.
|
||||
- **On-premises MDM** - If your product is an on-premises MDM, customers must configure your product with the key used to authenticate with Microsoft Entra ID. This key configuration is because each on-premises instance of your MDM product has a different tenant-specific key. So, you may need to expose a configuration experience in your MDM product that enables administrators to specify the key to be used to authenticate with Microsoft Entra ID.
|
||||
|
||||
### Use Microsoft Graph API
|
||||
@ -415,8 +401,6 @@ Response:
|
||||
- Success - HTTP 204 with No Content.
|
||||
- Failure/Error - HTTP 404 Not Found. This error may be returned if the specified device or tenant can't be found.
|
||||
|
||||
<a name='data-loss-during-unenrollment-from-azure-active-directory-join'></a>
|
||||
|
||||
## Data loss during unenrollment from Microsoft Entra join
|
||||
|
||||
When a user is enrolled into MDM through Microsoft Entra join and then disconnects the enrollment, there's no warning that the user will lose Windows Information Protection (WIP) data. The disconnection message doesn't indicate the loss of WIP data.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Automatic MDM enrollment in the Intune admin center
|
||||
description: Automatic MDM enrollment in the Intune admin center
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Automatic MDM enrollment in the Intune admin center
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
---
|
||||
title: Bulk enrollment
|
||||
description: Bulk enrollment is an efficient way to set up a large number of devices to be managed by an MDM server without the need to reimage the devices.
|
||||
description: Bulk enrollment is an efficient way to set up a large number of devices to manage by an MDM server without the need to reimage the devices.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Bulk enrollment using Windows Configuration Designer
|
||||
|
||||
Bulk enrollment is an efficient way to set up a large number of devices to be managed by an MDM server without the need to reimage the devices. You can use the [Provisioning CSP](mdm/provisioning-csp.md) for bulk enrollment, except for the Microsoft Entra join enrollment scenario.
|
||||
Bulk enrollment is an efficient way to set up a large number of devices to manage by an MDM server without the need to reimage the devices. You can use the [Provisioning CSP](mdm/provisioning-csp.md) for bulk enrollment, except for the Microsoft Entra join enrollment scenario.
|
||||
|
||||
## Typical use cases
|
||||
|
||||
@ -68,7 +68,7 @@ Using the WCD, create a provisioning package using the enrollment information re
|
||||
|
||||
|
||||
1. Configure the other settings, such as the Wi-Fi connections so that the device can join a network before joining MDM (for example, **Runtime settings** > **ConnectivityProfiles** > **WLANSetting**).
|
||||
1. When you're done adding all the settings, on the **File** menu, select **Save**.
|
||||
1. After adding all the settings, select **Save** on the **File** menu.
|
||||
1. On the main menu, select **Export** > **Provisioning package**.
|
||||
|
||||
|
||||
@ -120,7 +120,7 @@ Using the WCD, create a provisioning package using the enrollment information re
|
||||
For detailed descriptions of these settings, see [Provisioning CSP](mdm/provisioning-csp.md).
|
||||
|
||||
1. Configure the other settings, such as the Wi-Fi connection so that the device can join a network before joining MDM (for example, **Runtime settings** > **ConnectivityProfiles** > **WLANSetting**).
|
||||
1. When you're done adding all the settings, on the **File** menu, select **Save**.
|
||||
1. After adding all the settings, select **Save** on the **File** menu.
|
||||
1. Export and build the package (steps 10-13 in previous section).
|
||||
1. Apply the package to some test devices and verify that they work. For more information, see [Apply a provisioning package](#apply-a-provisioning-package).
|
||||
1. Apply the package to your devices.
|
||||
@ -142,7 +142,7 @@ Using the WCD, create a provisioning package using the enrollment information re
|
||||
- If the provisioning engine receives a failure from a CSP, it retries provisioning three times in a row.
|
||||
- If all immediate attempts fail, a delayed task is launched to try provisioning again later. It will retry four times at a decaying rate of 15 minutes -> 1 hr -> 4 hr -> "Next System Start". These attempts are run from the SYSTEM context.
|
||||
- It also retries the provisioning each time it's launched, if started from somewhere else as well.
|
||||
- In addition, provisioning will be restarted in the SYSTEM context after a sign in and the [system has been idle](/windows/win32/taskschd/task-idle-conditions).
|
||||
- In addition, provisioning will be restarted in the SYSTEM context after a sign in and the [system is idle](/windows/win32/taskschd/task-idle-conditions).
|
||||
|
||||
## Related articles
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Certificate authentication device enrollment
|
||||
description: This section provides an example of the mobile device enrollment protocol using certificate authentication policy.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Certificate authentication device enrollment
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Certificate Renewal
|
||||
description: Learn how to find all the resources that you need to provide continuous access to client certificates.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Certificate Renewal
|
||||
@ -19,7 +19,7 @@ Windows supports automatic certificate renewal, also known as Renew On Behalf Of
|
||||
> [!NOTE]
|
||||
> Certificate renewal of the enrollment certificate through ROBO is only supported with Microsoft PKI.
|
||||
|
||||
Auto certificate renewal is the only supported MDM client certificate renewal method for the device that's enrolled using WAB authentication. Meaning, the AuthPolicy is set to Federated. It also means if the server supports WAB authentication, then the MDM certificate enrollment server MUST also support client TLS to renew the MDM client certificate.
|
||||
Auto certificate renewal is the only supported MDM client certificate renewal method for a device enrolled using WAB authentication. Meaning, the AuthPolicy is set to Federated. It also means if the server supports WAB authentication, then the MDM certificate enrollment server MUST also support client TLS to renew the MDM client certificate.
|
||||
|
||||
For Windows devices, during the MDM client certificate enrollment phase or during MDM management section, the enrollment server or MDM server could configure the device to support automatic MDM client certificate renewal using [CertificateStore CSP's](mdm/certificatestore-csp.md) ROBOSupport node under `CertificateStore/My/WSTEP/Renew` URL.
|
||||
|
||||
@ -89,7 +89,7 @@ In Windows, the renewal period can only be set during the MDM enrollment phase.
|
||||
|
||||
For more information about the parameters, see the [CertificateStore configuration service provider](mdm/certificatestore-csp.md).
|
||||
|
||||
Unlike manual certificate renewal, the device doesn't perform an automatic MDM client certificate renewal if the certificate is already expired. To make sure the device has enough time to automatically renew, we recommend you set a renewal period a couple months (40-60 days) before the certificate expires. And, set the renewal retry interval to every few days, like every 4-5 days instead of every seven days (weekly). This change increases the chance that the device will try to connect at different days of the week.
|
||||
Unlike manual certificate renewal, the device doesn't perform an automatic MDM client certificate renewal if the certificate is already expired. To make sure the device has enough time to automatically renew, we recommend you set a renewal period a couple months (40-60 days) before the certificate expires. And, set the renewal retry interval to every few days, like every 4-5 days instead of every seven days (weekly). This change increases the chance that the device tries to connect at different days of the week.
|
||||
|
||||
## Certificate renewal response
|
||||
|
||||
@ -99,7 +99,7 @@ When RequestType is set to Renew, the web service verifies the following (in add
|
||||
- The client's certificate is in the renewal period
|
||||
- The certificate is issued by the enrollment service
|
||||
- The requester is the same as the requester for initial enrollment
|
||||
- For standard client's request, the client hasn't been blocked
|
||||
- For standard client's request, the client isn't blocked
|
||||
|
||||
After validation is completed, the web service retrieves the PKCS#10 content from the PKCS#7 BinarySecurityToken. The rest is the same as initial enrollment, except that the Provisioning XML only needs to have the new certificate issued by the CA.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Secured-core configuration lock
|
||||
description: A secured-core PC (SCPC) feature that prevents configuration drift from secured-core PC features caused by unintentional misconfiguration.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
appliesto:
|
||||
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
|
||||
---
|
||||
@ -63,7 +63,7 @@ The steps to turn on config lock using Microsoft Intune are as follows:
|
||||
|
||||
Config lock is designed to ensure that a secured-core PC isn't unintentionally misconfigured. You keep the ability to enable or disable SCPC features, for example, firmware protection. You can make these changes with group policies or MDM services like Microsoft Intune.
|
||||
|
||||
:::image type="content" source="images/configlock-mem-firmwareprotect.png" alt-text="The Defender Firmware protection setting, with a description of Windows Defender System Guard protects your device from compromised firmware. The setting is set to Off.":::
|
||||
:::image type="content" source="images/configlock-mem-firmwareprotect.png" alt-text="The Defender Firmware protection setting, with a description of System Guard protects your device from compromised firmware. The setting is set to Off.":::
|
||||
|
||||
## FAQ
|
||||
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
---
|
||||
title: Declared configuration extensibility
|
||||
description: Learn more about declared configuration extensibility through native WMI providers.
|
||||
ms.date: 09/26/2023
|
||||
ms.date: 07/08/2024
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
# Declared configuration extensibility providers
|
||||
|
||||
The declared configuration enrollment, which supports the declared configuration client stack, offers extensibility through native WMI providers. This feature instantiates and interfaces with a Windows Management Instrumentation (WMI) provider that has implemented a management infrastructure (MI) interface. The interface must implement GetTargetResource, TestTargetResource, and SetTargetResource methods, and may implement any number of string properties.
|
||||
The declared configuration enrollment, which supports the declared configuration client stack, offers extensibility through native WMI providers. This feature instantiates and interfaces with a Windows Management Instrumentation (WMI) provider that implements a management infrastructure (MI) interface. The interface must implement GetTargetResource, TestTargetResource, and SetTargetResource methods, and can implement any number of string properties.
|
||||
|
||||
> [!NOTE]
|
||||
> Only string properties are currently supported by extensibility providers.
|
||||
@ -51,7 +51,7 @@ uint32 SetTargetResource(
|
||||
|
||||
To create a native WMI provider, follow the steps outlined in [How to implement an MI provider](/previous-versions/windows/desktop/wmi_v2/how-to-implement-an-mi-provider). These steps include how to generate the source code for an MI interface using the `Convert-MofToProvider.exe` tool to generate the DLL and prepare it for placement.
|
||||
|
||||
1. Create a MOF file that defines the schema for the desired state configuration resource including parameters and methods. This file includes the required parameters for the resource.
|
||||
1. Create a Managed Object Format (MOF) file that defines the schema for the desired state configuration resource including parameters and methods. This file includes the required parameters for the resource.
|
||||
2. Copy the schema MOF file along with any required files into the provider tools directory, for example: ProviderGenerationTool.
|
||||
3. Edit the required files and include the correct file names and class names.
|
||||
4. Invoke the provider generator tool to generate the provider's project files.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Declared configuration protocol
|
||||
description: Learn more about using declared configuration protocol for desired state management of Windows devices.
|
||||
ms.date: 09/26/2023
|
||||
ms.date: 07/08/2024
|
||||
ms.topic: overview
|
||||
---
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Mobile device management MDM for device updates
|
||||
description: Windows provides several APIs to help mobile device management (MDM) solutions manage updates. Learn how to use these APIs to implement update management.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
ms.collection:
|
||||
- highpri
|
||||
- tier2
|
||||
@ -25,7 +25,7 @@ In particular, Windows provides APIs to enable MDMs to:
|
||||
- Enter a per-device update approval list. The list makes sure devices only install updates that are approved and tested.
|
||||
- Approve end-user license agreements (EULAs) for the end user so update deployment can be automated even for updates with EULAs.
|
||||
|
||||
This article provides independent software vendors (ISV) with the information they need to implement update management in Windows. For more information, see [Policy CSP - Update](mdm/policy-csp-update.md).
|
||||
This article provides independent software publishers (ISV) with the information they need to implement update management in Windows. For more information, see [Policy CSP - Update](mdm/policy-csp-update.md).
|
||||
|
||||
> [!NOTE]
|
||||
> The OMA DM APIs for specifying update approvals and getting compliance status refer to updates by using an Update ID. The Update ID is a GUID that identifies a particular update. The MDM will want to show IT-friendly information about the update, instead of a raw GUID, including the update's title, description, KB, update type, like a security update or service pack. For more information, see [[MS-WSUSSS]: Windows Update Services: Server-Server Protocol](/openspecs/windows_protocols/ms-wsusss/f49f0c3e-a426-4b4b-b401-9aeb2892815c).
|
||||
@ -88,7 +88,7 @@ This section describes a possible algorithm for using the server-server sync pro
|
||||
|
||||
First some background:
|
||||
|
||||
- If you have a multi-tenant MDM, the update metadata can be kept in a shared partition, since it's common to all tenants.
|
||||
- If you have a multitenant MDM, the update metadata can be kept in a shared partition, since it's common to all tenants.
|
||||
- A metadata sync service can then be implemented. The service periodically calls server-server sync to pull in metadata for the updates IT cares about.
|
||||
- The MDM component that uses OMA DM to control devices (described in the next section) should send the metadata sync service the list of needed updates it gets from each client, if those updates aren't already known to the device.
|
||||
|
||||
@ -130,7 +130,7 @@ The following screenshots of the administrator console show the list of update t
|
||||
|
||||
### SyncML example
|
||||
|
||||
Set auto update to notify and defer.
|
||||
Set Microsoft AutoUpdate to notify and defer.
|
||||
|
||||
```xml
|
||||
<SyncML xmlns="SYNCML:SYNCML1.1">
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Disconnecting from the management infrastructure (unenrollment)
|
||||
description: Disconnecting is initiated either locally by the user using a phone or remotely by the IT admin using management server.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Disconnecting from the management infrastructure (unenrollment)
|
||||
@ -22,14 +22,14 @@ During disconnection, the client executes the following tasks:
|
||||
|
||||
In Windows, after the user confirms the account deletion command and before the account is deleted, the MDM client will notify to the MDM server that the account will be removed. This notification is a best-effort action as no retry is built in to ensure the notification is successfully sent to the device.
|
||||
|
||||
This action utilizes the OMA DM generic alert 1226 function to send a user an MDM unenrollment user alert to the MDM server after the device accepts the user unenrollment request, but before it deletes any enterprise data. The server should set the expectation that unenrollment may succeed or fail, and the server can check whether the device is unenrolled by either checking whether the device calls back at scheduled time or by sending a push notification to the device to see whether it responds back. If the server plans to send a push notification, it should allow for some delay to give the device the time to complete the unenrollment work.
|
||||
This action utilizes the OMA DM generic alert 1226 function to send a user an MDM unenrollment user alert to the MDM server after the device accepts the user unenrollment request, but before it deletes any enterprise data. The server should set the expectation that unenrollment can succeed or fail, and the server can check whether the device is unenrolled by either checking whether the device calls back at scheduled time or by sending a push notification to the device to see whether it responds back. If the server plans to send a push notification, it should allow for some delay to give the device the time to complete the unenrollment work.
|
||||
|
||||
> [!NOTE]
|
||||
> The user unenrollment is an OMA DM standard. For more information about the 1226 generic alert, see the OMA Device Management Protocol specification (OMA-TS-DM\_Protocol-V1\_2\_1-20080617-A), available from the [OMA website](https://www.openmobilealliance.org/release/DM/V1_1_2-20031209-A/).
|
||||
|
||||
The vendor uses the Type attribute to specify what type of generic alert it is. For device initiated MDM unenrollment, the alert type is **com.microsoft:mdm.unenrollment.userrequest**.
|
||||
|
||||
After the user elects to unenroll, any active MDM OMA DM sessions are terminated. After that, the DM client starts a DM session, including a user unenroll generic alert in the first package that it sends to the server.
|
||||
After the user elects to unenroll, any active MDM OMA DM sessions are terminated. After that, the DMClient starts a DM session, including a user unenroll generic alert in the first package that it sends to the server.
|
||||
|
||||
The following sample shows an OMA DM first package that contains a generic alert message. For more information on WP OMA DM support, see the [OMA DM protocol support](oma-dm-protocol-support.md) article.
|
||||
|
||||
@ -107,15 +107,13 @@ You can only use the Work Access page to unenroll under the following conditions
|
||||
- Enrollment was done using bulk enrollment.
|
||||
- Enrollment was created using the Work Access page.
|
||||
|
||||
<a name='unenrollment-from-azure-active-directory-join'></a>
|
||||
|
||||
## Unenrollment from Microsoft Entra join
|
||||
|
||||
When a user is enrolled into MDM through Microsoft Entra join and later, the enrollment disconnects, there's no warning that the user will lose Windows Information Protection (WIP) data. The disconnection message doesn't indicate the loss of WIP data.
|
||||
|
||||
|
||||
|
||||
During the process in which a device is enrolled into MDM through Microsoft Entra join and then remotely unenrolled, the device may get into a state where it must be reimaged. When devices are remotely unenrolled from MDM, the Microsoft Entra association is also removed. This safeguard is in place to avoid leaving the corporate devices in unmanaged state.
|
||||
During the process in which a device is enrolled into MDM through Microsoft Entra join and then remotely unenrolled, the device can get into a state where it must be reimaged. When devices are remotely unenrolled from MDM, the Microsoft Entra association is also removed. This safeguard is in place to avoid leaving the corporate devices in unmanaged state.
|
||||
|
||||
Before remotely unenrolling corporate devices, you must ensure that there is at least one admin user on the device that isn't part of Microsoft Entra ID, otherwise the device won't have any admin user after the operation.
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ title: Enable ADMX policies in MDM
|
||||
description: Use this step-by-step guide to configure a selected set of Group Policy administrative templates (ADMX policies) in Mobile Device Management (MDM).
|
||||
ms.topic: conceptual
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Enable ADMX policies in MDM
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Enroll a Windows device automatically using Group Policy
|
||||
description: Learn how to use a Group Policy to trigger autoenrollment to MDM for Active Directory (AD) domain-joined devices.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
ms.collection:
|
||||
- highpri
|
||||
- tier2
|
||||
@ -12,7 +12,7 @@ ms.collection:
|
||||
|
||||
You can use a Group Policy to trigger autoenrollment to Mobile Device Management (MDM) for Active Directory (AD) domain-joined devices.
|
||||
|
||||
The enrollment into Intune is triggered by a group policy created on your local AD and happens without any user interaction. This cause-and-effect mechanism means you can automatically mass-enroll a large number of domain-joined corporate devices into Microsoft Intune. The enrollment process starts in the background once you sign in to the device with your Microsoft Entra account.
|
||||
The group policy created on your local AD triggers enrollment into Intune without any user interaction. This cause-and-effect mechanism means you can automatically mass-enroll a large number of domain-joined corporate devices into Microsoft Intune. The enrollment process starts in the background once you sign in to the device with your Microsoft Entra account.
|
||||
|
||||
**Requirements**:
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Enterprise app management
|
||||
description: This article covers one of the key mobile device management (MDM) features for managing the lifecycle of apps across Windows devices.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Enterprise app management
|
||||
@ -116,7 +116,7 @@ There are two basic types of apps you can deploy:
|
||||
- Store apps.
|
||||
- Enterprise signed apps.
|
||||
|
||||
To deploy enterprise signed apps, you must enable a setting on the device to allow trusted apps. The apps can be signed by a Microsoft approved root (such as Symantec), an enterprise deployed root, or apps that are self-signed. This section covers the steps to configure the device for non-store app deployment.
|
||||
To deploy enterprise signed apps, you must enable a setting on the device to allow trusted apps. The apps can be signed by a Microsoft approved root (such as Symantec), an enterprise deployed root, or apps that are self-signed. This section covers the steps to configure the device for nonstore app deployment.
|
||||
|
||||
### Unlock the device for non-Store apps
|
||||
|
||||
@ -154,7 +154,7 @@ Here's an example:
|
||||
|
||||
### Unlock the device for developer mode
|
||||
|
||||
Development of apps on Windows devices no longer requires a special license. You can enable debugging and deployment of non-packaged apps using [ApplicationManagement/AllowDeveloperUnlock](mdm/policy-csp-applicationmanagement.md) policy in Policy CSP.
|
||||
Development of apps on Windows devices no longer requires a special license. You can enable debugging and deployment of nonpackaged apps using [ApplicationManagement/AllowDeveloperUnlock](mdm/policy-csp-applicationmanagement.md) policy in Policy CSP.
|
||||
|
||||
AllowDeveloperUnlock policy enables the development mode on the device. The AllowDeveloperUnlock isn't configured by default, which means only Microsoft Store apps can be installed. If the management server explicitly sets the value to off, the setting is disabled in the settings panel on the device.
|
||||
|
||||
@ -238,8 +238,8 @@ If you purchased an app from the Store for Business, the app license must be dep
|
||||
|
||||
In the SyncML, you need to specify the following information in the `Exec` command:
|
||||
|
||||
- License ID - This ID is specified in the LocURI. The License ID for the offline license is referred to as the "Content ID" in the license file. You can retrieve this information from the Base64 encoded license download from the Store for Business.
|
||||
- License Content - This content is specified in the data section. The License Content is the Base64 encoded blob of the license.
|
||||
- License ID - This ID is specified in the LocURI. The License ID for the offline license is referred to as the "Content ID" in the license file. You can retrieve this information from the Base 64 encoded license download from the Store for Business.
|
||||
- License Content - This content is specified in the data section. The License Content is the Base 64 encoded blob of the license.
|
||||
|
||||
Here's an example of an offline license installation.
|
||||
|
||||
@ -469,7 +469,7 @@ When an app installation is completed, a Windows notification is sent. You can a
|
||||
- NOT\_INSTALLED (0) - The node was added, but the execution wasn't completed.
|
||||
- INSTALLING (1) - Execution has started, but the deployment hasn't completed. If the deployment completes regardless of success, then this value is updated.
|
||||
- FAILED (2) - Installation failed. The details of the error can be found under LastError and LastErrorDescription.
|
||||
- INSTALLED (3) - Once an install is successful this node is cleaned up. If the clean up action hasn't completed, then this state may briefly appear.
|
||||
- INSTALLED (3) - Once an install is successful this node is cleaned up. If the clean-up action hasn't completed, then this state may briefly appear.
|
||||
- LastError - The last error reported by the app deployment server.
|
||||
- LastErrorDescription - Describes the last error reported by the app deployment server.
|
||||
- Status - An integer that indicates the progress of the app installation. In cases of an HTTPS location, this status shows the estimated download progress. Status isn't available for provisioning and only used for user-based installations. For provisioning, the value is always 0.
|
||||
|
||||
@ -3,7 +3,7 @@ title: eSIM Enterprise Management
|
||||
description: Learn how Mobile Device Management (MDM) Providers support the eSIM Profile Management Solution on Windows.
|
||||
ms.localizationpriority: medium
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# How Mobile Device Management Providers support eSIM Management on Windows
|
||||
@ -28,7 +28,7 @@ If you're a Mobile Device Management (MDM) Provider and want to support eSIM Man
|
||||
- Assess solution type that you would like to provide your customers
|
||||
- Batch/offline solution
|
||||
- IT Admin can manually import a flat file containing list of eSIM activation codes, and provision eSIM on LTE enabled devices.
|
||||
- Operator doesn't have visibility over status of the eSIM profiles and device eSIM has been downloaded and installed to
|
||||
- Operator doesn't have visibility over status of the eSIM profiles
|
||||
- Real-time solution
|
||||
- MDM automatically syncs with the Operator backend system for subscription pool and eSIM management, via SIM vendor solution component. IT Admin can view subscription pool and provision eSIM in real time.
|
||||
- Operator is notified of the status of each eSIM profile and has visibility on which devices are being used
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Federated authentication device enrollment
|
||||
description: This section provides an example of the mobile device enrollment protocol using federated authentication policy.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Federated authentication device enrollment
|
||||
@ -122,7 +122,7 @@ The discovery response is in the XML format and includes the following fields:
|
||||
> [!NOTE]
|
||||
> The HTTP server response must not set Transfer-Encoding to Chunked; it must be sent as one message.
|
||||
|
||||
When authentication policy is set to be Federated, Web Authentication Broker (WAB) is used by the enrollment client to get a security token. The WAB start page URL is provided by the discovery service in the response message. The enrollment client calls the WAB API within the response message to start the WAB process. WAB pages are server hosted web pages. The server should build those pages to fit the device screen nicely and be as consistent as possible to other builds in the MDM enrollment UI. The opaque security token that is returned from WAB as an endpage is used by the enrollment client as the device security secret during the client certificate enrollment request call.
|
||||
When authentication policy is set to be Federated, Web Authentication Broker (WAB) is used by the enrollment client to get a security token. The WAB start page URL is provided by the discovery service in the response message. The enrollment client calls the WAB API within the response message to start the WAB process. WAB pages are server hosted web pages. The server should build those pages to fit the device screen nicely and be as consistent as possible to other builds in the MDM enrollment UI. The opaque security token that is returned from WAB as an end page is used by the enrollment client as the device security secret during the client certificate enrollment request call.
|
||||
|
||||
> [!NOTE]
|
||||
> Instead of relying on the user agent string that is passed during authentication to get information, such as the OS version, use the following guidance:
|
||||
@ -183,7 +183,7 @@ Content-Length: 556
|
||||
</html>
|
||||
```
|
||||
|
||||
The server has to send a POST to a redirect URL of the form `ms-app://string` (the URL scheme is ms-app) as indicated in the POST method action. The security token value is the base64-encoded string `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary` contained in the `<wsse:BinarySecurityToken>` EncodingType attribute. Windows does the binary encode when it sends it back to enrollment server, in the form its just HTML encoded. This string is opaque to the enrollment client; the client doesn't interpret the string.
|
||||
The server has to send a POST to a redirect URL of the form `ms-app://string` (the URL scheme is ms-app) as indicated in the POST method action. The security token value is the base64-encoded string `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary` contained in the `<wsse:BinarySecurityToken>` EncodingType attribute. Windows does the binary encode when it sends it back to enrollment server, in the form it's just HTML encoded. This string is opaque to the enrollment client; the client doesn't interpret the string.
|
||||
|
||||
The following example shows a response received from the discovery web service that requires authentication via WAB.
|
||||
|
||||
@ -367,7 +367,7 @@ The following snippet shows the policy web service response.
|
||||
|
||||
## Enrollment web service
|
||||
|
||||
This web service implements the MS-WSTEP protocol. It processes the RequestSecurityToken (RST) message from the client, authenticates the client, requests the certificate from the CA, and returns it in the RequestSecurityTokenResponse (RSTR) to the client. Besides the issued certificate, the response also contains configurations needed to provision the DM client.
|
||||
This web service implements the MS-WSTEP protocol. It processes the RequestSecurityToken (RST) message from the client, authenticates the client, requests the certificate from the CA, and returns it in the RequestSecurityTokenResponse (RSTR) to the client. Besides the issued certificate, the response also contains configurations needed to provision the DMClient.
|
||||
|
||||
The RequestSecurityToken (RST) must have the user credential and a certificate request. The user credential in an RST SOAP envelope is the same as in GetPolicies, and can vary depending on whether the authentication policy is OnPremise or Federated. The BinarySecurityToken in an RST SOAP body contains a Base64-encoded PKCS\#10 certificate request, which is generated by the client based on the enrollment policy. The client could have requested an enrollment policy by using MS-XCEP before requesting a certificate using MS-WSTEP. If the PKCS\#10 certificate request is accepted by the certification authority (CA) (the key length, hashing algorithm, and so on, match the certificate template), the client can enroll successfully.
|
||||
|
||||
@ -471,15 +471,15 @@ Similar to the TokenType in the RST, the RSTR uses a custom ValueType in the Bin
|
||||
The provisioning XML contains:
|
||||
|
||||
- The requested certificates (required)
|
||||
- The DM client configuration (required)
|
||||
- The DMClient configuration (required)
|
||||
|
||||
The client installs the client certificate, the enterprise root certificate, and intermediate CA certificate if there's one. The DM configuration includes the name and address of the DM server, which client certificate to use, and schedules when the DM client calls back to the server.
|
||||
The client installs the client certificate, the enterprise root certificate, and intermediate CA certificate if there's one. The DM configuration includes the name and address of the DM server, which client certificate to use, and schedules when the DMClient calls back to the server.
|
||||
|
||||
Enrollment provisioning XML should contain a maximum of one root certificate and one intermediate CA certificate that is needed to chain up the MDM client certificate. More root and intermediate CA certificates could be provisioned during an OMA DM session.
|
||||
|
||||
When root and intermediate CA certificates are being provisioned, the supported CSP node path is: CertificateStore/Root/System for root certificate provisioning, CertificateStore/My/User for intermediate CA certificate provisioning.
|
||||
|
||||
Here's a sample RSTR message and a sample of OMA client provisioning XML within RSTR. For more information about the configuration service providers (CSPs) used in provisioning XML, see the Enterprise settings, policies and app management section.
|
||||
Here's a sample RSTR message and a sample of OMA client provisioning XML within RSTR. For more information about the configuration service providers (CSPs) used in provisioning XML, see the Enterprise settings, policies, and app management section.
|
||||
|
||||
The following example shows the enrollment web service response.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Support for Windows Information Protection (WIP) on Windows
|
||||
description: Learn about implementing the Windows version of Windows Information Protection (WIP), which is a lightweight solution for managing company data access and security on personal devices.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Support for Windows Information Protection (WIP) on Windows
|
||||
@ -11,8 +11,6 @@ Windows Information Protection (WIP) is a lightweight solution for managing comp
|
||||
|
||||
[!INCLUDE [Deprecate Windows Information Protection](../security/information-protection/windows-information-protection/includes/wip-deprecation.md)]
|
||||
|
||||
<a name='integration-with-azure-ad'></a>
|
||||
|
||||
## Integration with Microsoft Entra ID
|
||||
|
||||
WIP is integrated with Microsoft Entra identity service. The WIP service supports Microsoft Entra integrated authentication for the user and the device during enrollment and the downloading of WIP policies. WIP integration with Microsoft Entra ID is similar to mobile device management (MDM) integration. See [Microsoft Entra integration with MDM](azure-active-directory-integration-with-mdm.md).
|
||||
@ -78,7 +76,7 @@ Since the [Poll](mdm/dmclient-csp.md#deviceproviderprovideridpoll) node isn't pr
|
||||
|
||||
## Supported CSPs
|
||||
|
||||
WIP supports the following configuration service providers (CSPs). All other CSPs are blocked. Note the list may change later based on customer feedback:
|
||||
WIP supports the following configuration service providers (CSPs). All other CSPs are blocked. Note the list can change later based on customer feedback:
|
||||
|
||||
- [AppLocker CSP](mdm/applocker-csp.md) for configuration of Windows Information Protection enterprise allowed apps.
|
||||
- [ClientCertificateInstall CSP](mdm/clientcertificateinstall-csp.md) for installing VPN and Wi-Fi certs.
|
||||
|
||||
@ -13,7 +13,7 @@ metadata:
|
||||
author: vinaypamnani-msft
|
||||
ms.author: vinpa
|
||||
manager: aaroncz
|
||||
ms.date: 01/18/2024
|
||||
ms.date: 07/08/2024
|
||||
localization_priority: medium
|
||||
|
||||
# linkListType: architecture | concept | deploy | download | get-started | how-to-guide | learn | overview | quickstart | reference | tutorial | video | whats-new
|
||||
|
||||
@ -2,13 +2,13 @@
|
||||
title: Manage Windows devices in your organization - transitioning to modern management
|
||||
description: This article offers strategies for deploying and managing Windows devices, including deploying Windows in a mixed environment.
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
ms.topic: conceptual
|
||||
---
|
||||
|
||||
# Manage Windows devices in your organization - transitioning to modern management
|
||||
|
||||
Use of personal devices for work, and employees working outside the office, may be changing how your organization manages devices. Certain parts of your organization might require deep, granular control over devices, while other parts might seek lighter, scenario-based management that empowers the modern workforce. Windows offers the flexibility to respond to these changing requirements, and can easily be deployed in a mixed environment. You can shift the percentage of Windows devices gradually, following the normal upgrade schedules used in your organization.
|
||||
Use of personal devices for work, and users working outside the office, may be changing how your organization manages devices. Certain parts of your organization might require deep, granular control over devices, while other parts might seek lighter, scenario-based management that empowers the modern workforce. Windows offers the flexibility to respond to these changing requirements, and can easily be deployed in a mixed environment. You can shift the percentage of Windows devices gradually, following the normal upgrade schedules used in your organization.
|
||||
|
||||
Your organization can support various operating systems across a wide range of device types, and manage them through a common set of tools such as Microsoft Configuration Manager, Microsoft Intune, or other third-party products. This "managed diversity" enables you to empower your users to benefit from the productivity enhancements available on their new Windows devices (including rich touch and ink support), while still maintaining your standards for security and manageability. It can help you and your organization benefit from Windows faster.
|
||||
|
||||
@ -45,13 +45,13 @@ You can use Windows and services like [Microsoft Entra ID](/azure/active-directo
|
||||
|
||||
You can envision user and device management as falling into these two categories:
|
||||
|
||||
- **Corporate (CYOD) or personal (BYOD) devices used by mobile users for SaaS apps such as Office 365.** With Windows, your employees can self-provision their devices:
|
||||
- **Corporate (CYOD) or personal (BYOD) devices used by mobile users for SaaS apps such as Office 365.** With Windows, your users can self-provision their devices:
|
||||
|
||||
- For corporate devices, they can set up corporate access with [Microsoft Entra join](/azure/active-directory/devices/overview). When you offer them Microsoft Entra join with automatic Intune MDM enrollment, they can bring devices into a corporate-managed state in [*one step*](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/windows-10-azure-ad-and-microsoft-intune-automatic-mdm/ba-p/244067), all from the cloud.
|
||||
|
||||
Microsoft Entra join is also a great solution for temporary staff, partners, or other part-time employees. These accounts can be kept separate from the on-premises AD domain but still access needed corporate resources.
|
||||
Microsoft Entra join is also a great solution for temporary staff, partners, or other part-time users. These accounts can be kept separate from the on-premises AD domain but still access needed corporate resources.
|
||||
|
||||
- Likewise, for personal devices, employees can use a new, simplified [BYOD experience](/azure/active-directory/devices/overview) to add their work account to Windows, then access work resources on the device.
|
||||
- Likewise, for personal devices, users can use a new, simplified [BYOD experience](/azure/active-directory/devices/overview) to add their work account to Windows, then access work resources on the device.
|
||||
|
||||
- **Domain joined PCs and tablets used for traditional applications and access to important resources.** These applications and resources may be traditional ones that require authentication or accessing highly sensitive or classified resources on-premises.
|
||||
|
||||
@ -71,7 +71,7 @@ As you review the roles in your organization, you can use the following generali
|
||||
|
||||
## Settings and configuration
|
||||
|
||||
Your configuration requirements are defined by multiple factors, including the level of management needed, the devices and data managed, and your industry requirements. Meanwhile, employees are frequently concerned about IT applying strict policies to their personal devices, but they still want access to corporate email and documents. You can create a consistent set of configurations across PCs, tablets, and phones through the common MDM layer.
|
||||
Your configuration requirements are defined by multiple factors, including the level of management needed, the devices and data managed, and your industry requirements. Meanwhile, users are frequently concerned about IT applying strict policies to their personal devices, but they still want access to corporate email and documents. You can create a consistent set of configurations across PCs, tablets, and phones through the common MDM layer.
|
||||
|
||||
- **MDM**: MDM gives you a way to configure settings that achieve your administrative intent without exposing every possible setting. (In contrast, group policy exposes fine-grained settings that you control individually.) One benefit of MDM is that it enables you to apply broader privacy, security, and application management settings through lighter and more efficient tools. MDM also allows you to target Internet-connected devices to manage policies without using group policy that requires on-premises domain-joined devices. This provision makes MDM the best choice for devices that are constantly on the go.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Collect MDM logs
|
||||
description: Learn how to collect MDM logs. Examining these logs can help diagnose enrollment or device management issues in Windows devices managed by an MDM server.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
ms.collection:
|
||||
- highpri
|
||||
- tier2
|
||||
@ -40,7 +40,7 @@ mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zi
|
||||
|
||||
### Understanding zip structure
|
||||
|
||||
The zip file has logs according to the areas that were used in the command. This explanation is based on DeviceEnrollment, DeviceProvisioning and Autopilot areas. It applies to the zip files collected via command line or Feedback Hub
|
||||
The zip file has logs according to the areas that were used in the command. This explanation is based on DeviceEnrollment, DeviceProvisioning, and Autopilot areas. It applies to the zip files collected via command line or Feedback Hub
|
||||
|
||||
- DiagnosticLogCSP_Collector_Autopilot_*: Autopilot etls
|
||||
- DiagnosticLogCSP_Collector_DeviceProvisioning_*: Provisioning etls (Microsoft-Windows-Provisioning-Diagnostics-Provider)
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Diagnose MDM enrollment failures
|
||||
description: Learn how to diagnose enrollment failures for Windows devices
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Diagnose MDM enrollment
|
||||
|
||||
@ -5,12 +5,12 @@ ms.topic: conceptual
|
||||
ms.collection:
|
||||
- highpri
|
||||
- tier2
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# MDM enrollment of Windows devices
|
||||
|
||||
In today's cloud-first world, enterprise IT departments increasingly want to let employees use their own devices, or even choose and purchase corporate-owned devices. Connecting your devices to work makes it easy for you to access your organization's resources, such as apps, the corporate network, and email.
|
||||
In today's cloud-first world, enterprise IT departments increasingly want to let users use their own devices, or even choose and purchase corporate-owned devices. Connecting your devices to work makes it easy for you to access your organization's resources, such as apps, the corporate network, and email.
|
||||
|
||||
> [!NOTE]
|
||||
> When you connect your device using mobile device management (MDM) enrollment, your organization may enforce certain policies on your device.
|
||||
@ -24,8 +24,6 @@ You can connect corporate-owned devices to work by either joining the device to
|
||||
> [!NOTE]
|
||||
> For devices joined to on-premises Active Directory, see [Group policy enrollment](enroll-a-windows-10-device-automatically-using-group-policy.md).
|
||||
|
||||
<a name='connect-your-device-to-an-azure-ad-domain-join-azure-ad'></a>
|
||||
|
||||
### Connect your device to a Microsoft Entra domain (join Microsoft Entra ID)
|
||||
|
||||
All Windows devices can be connected to a Microsoft Entra domain. These devices can be connected during OOBE. Additionally, desktop devices can be connected to a Microsoft Entra domain using the Settings app.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Known issues in MDM
|
||||
description: Learn about known issues for Windows devices in MDM
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Known issues
|
||||
@ -11,11 +11,11 @@ ms.date: 08/10/2023
|
||||
|
||||
A Get command inside an atomic command isn't supported.
|
||||
|
||||
## Apps installed using WMI classes are not removed
|
||||
## Apps installed using WMI classes aren't removed
|
||||
|
||||
Applications installed using WMI classes aren't removed when the MDM account is removed from device.
|
||||
|
||||
## Passing CDATA in SyncML does not work
|
||||
## Passing CDATA in SyncML doesn't work
|
||||
|
||||
Passing CDATA in data in SyncML to ConfigManager and CSPs doesn't work.
|
||||
|
||||
@ -222,8 +222,6 @@ Alternatively you can use the following procedure to create an EAP Configuration
|
||||
|
||||
After the MDM client automatically renews the WNS channel URI, the MDM client will immediately check in with the MDM server. Henceforth, for every MDM client check-in, the MDM server should send a GET request for "ProviderID/Push/ChannelURI" to retrieve the latest channel URI and compare it with the existing channel URI; then update the channel URI if necessary.
|
||||
|
||||
<a name='user-provisioning-failure-in-azure-active-directory-joined-devices'></a>
|
||||
|
||||
## User provisioning failure in Microsoft Entra joined devices
|
||||
|
||||
For Microsoft Entra joined devices, provisioning `.\User` resources fails when the user isn't logged in as a Microsoft Entra user. If you attempt to join Microsoft Entra ID from **Settings** > **System** > **About** user interface, ensure to sign out and sign in with Microsoft Entra credentials to get your organizational configuration from your MDM server. This behavior is by design.
|
||||
@ -232,6 +230,6 @@ For Microsoft Entra joined devices, provisioning `.\User` resources fails when t
|
||||
|
||||
If you want to use the certificate used for VPN authentication also for Kerberos authentication (required if you need access to on-premises resources using NTLM or Kerberos), the user's certificate must meet the requirements for smart card certificate, the Subject field should contain the DNS domain name in the DN or the SAN should contain a fully qualified UPN so that the DC can be located from the DNS registrations. If certificates that don't meet these requirements are used for VPN, users may fail to access resources that require Kerberos authentication.
|
||||
|
||||
## Device management agent for the push-button reset is not working
|
||||
## Device management agent for the push-button reset isn't working
|
||||
|
||||
The DM agent for [push-button reset](/windows-hardware/manufacture/desktop/push-button-reset-overview) keeps the registry settings for OMA DM sessions, but deletes the task schedules. The client enrollment is retained, but it never syncs with the MDM service.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Mobile Device Management overview
|
||||
description: Windows provides an enterprise-level solution to mobile management, to help IT pros comply with security policies while avoiding compromise of user's privacy.
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
ms.topic: conceptual
|
||||
ms.localizationpriority: medium
|
||||
ms.collection:
|
||||
@ -56,8 +56,6 @@ For information about the MDM policies defined in the Intune security baseline,
|
||||
|
||||
No. Only one MDM is allowed.
|
||||
|
||||
<a name='how-do-i-set-the-maximum-number-of-azure-active-directory-joined-devices-per-user'></a>
|
||||
|
||||
### How do I set the maximum number of Microsoft Entra joined devices per user?
|
||||
|
||||
1. Sign in to the portal as tenant admin: <https://portal.azure.com>.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Mobile device enrollment
|
||||
description: Learn how mobile device enrollment verifies that only authenticated and authorized devices are managed by the enterprise.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
ms.collection:
|
||||
- highpri
|
||||
- tier2
|
||||
@ -43,13 +43,13 @@ The certificate enrollment is an implementation of the MS-WSTEP protocol.
|
||||
|
||||
### Management configuration
|
||||
|
||||
The server sends provisioning XML that contains a server certificate (for TLS/SSL server authentication), a client certificate issued by enterprise CA, DM client bootstrap information (for the client to communicate with the management server), an enterprise application token (for the user to install enterprise applications), and the link to download the Company Hub application.
|
||||
The server sends provisioning XML that contains a server certificate (for TLS/SSL server authentication), a client certificate issued by enterprise CA, DMClient bootstrap information (for the client to communicate with the management server), an enterprise application token (for the user to install enterprise applications), and the link to download the Company Hub application.
|
||||
|
||||
The following articles describe the end-to-end enrollment process using various authentication methods:
|
||||
|
||||
- [Federated authentication device enrollment](federated-authentication-device-enrollment.md)
|
||||
- [Certificate authentication device enrollment](certificate-authentication-device-enrollment.md)
|
||||
- [On-premise authentication device enrollment](on-premise-authentication-device-enrollment.md)
|
||||
- [On-premises authentication device enrollment](on-premise-authentication-device-enrollment.md)
|
||||
|
||||
> [!NOTE]
|
||||
> As a best practice, don't use hardcoded server-side checks on values such as:
|
||||
@ -168,4 +168,4 @@ TraceID is a freeform text node that is logged. It should identify the server si
|
||||
- [MDM enrollment of Windows-based devices](mdm-enrollment-of-windows-devices.md)
|
||||
- [Federated authentication device enrollment](federated-authentication-device-enrollment.md)
|
||||
- [Certificate authentication device enrollment](certificate-authentication-device-enrollment.md)
|
||||
- [On-premise authentication device enrollment](on-premise-authentication-device-enrollment.md)
|
||||
- [On-premises authentication device enrollment](on-premise-authentication-device-enrollment.md)
|
||||
|
||||
@ -3,7 +3,7 @@ title: What's new in MDM enrollment and management
|
||||
description: Discover what's new and breaking changes in mobile device management (MDM) enrollment and management experience across all Windows devices.
|
||||
ms.topic: conceptual
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# What's new in mobile device enrollment and management
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: OMA DM protocol support
|
||||
description: See how the OMA DM client communicates with the server over HTTPS and uses DM Sync (OMA DM v1.2) as the message payload.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# OMA DM protocol support
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: On-premises authentication device enrollment
|
||||
description: This section provides an example of the mobile device enrollment protocol using on-premises authentication policy.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# On-premises authentication device enrollment
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Push notification support for device management
|
||||
description: The DMClient CSP supports the ability to configure push-initiated device management sessions.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Push notification support for device management
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Server requirements for using OMA DM to manage Windows devices
|
||||
description: Learn about the general server requirements for using OMA DM to manage Windows devices, including the supported versions of OMA DM.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Server requirements for using OMA DM to manage Windows devices
|
||||
@ -11,11 +11,11 @@ The following list shows the general server requirements for using OMA DM to man
|
||||
|
||||
- The OMA DM server must support the OMA DM v1.1.2 or later protocol.
|
||||
|
||||
- Secure Sockets Layer (TLS/SSL) must be on the OMA DM server, and it must provide server certificate-based authentication, data integrity check, and data encryption. If the certificate isn't issued by a commercial Certification Authority whose root certificate is preinstalled in the device, you must provision the enterprise root certificate in the device's Root store.
|
||||
- Secure Sockets Layer (TLS/SSL) must be on the OMA DM server, and it must provide server certificate-based authentication, data integrity check, and data encryption. If the certificate isn't issued by a public Certification Authority whose root certificate is preinstalled in the device, you must provision the enterprise root certificate in the device's Root store.
|
||||
|
||||
- To authenticate the client at the application level, you must use either Basic or MD5 client authentication.
|
||||
|
||||
- The server MD5 nonce must be renewed in each DM session. The DM client sends the new server nonce for the next session to the server over the Status element in every DM session.
|
||||
- The server MD5 nonce must be renewed in each DM session. The DMClient sends the new server nonce for the next session to the server over the Status element in every DM session.
|
||||
|
||||
- The MD5 binary nonce is sent over XML B64 encoded format, but the octal form of the binary data should be used when the service calculates the hash.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Structure of OMA DM provisioning files
|
||||
description: Learn about the structure of OMA DM provisioning files, for example how each message is composed of a header, specified by the SyncHdr element, and a message body.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Structure of OMA DM provisioning files
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Understanding ADMX policies
|
||||
description: You can use ADMX policies for Windows mobile device management (MDM) across Windows devices.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Understanding ADMX policies
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Using PowerShell scripting with the WMI Bridge Provider
|
||||
description: This article covers using PowerShell Cmdlet scripts to configure per-user and per-device policy settings, and how to invoke methods through the WMI Bridge Provider.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Using PowerShell scripting with the WMI Bridge Provider
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Win32 and Desktop Bridge app ADMX policy Ingestion
|
||||
description: Ingest ADMX files and set ADMX policies for Win32 and Desktop Bridge apps.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Win32 and Desktop Bridge app ADMX policy Ingestion
|
||||
|
||||
@ -1,17 +1,17 @@
|
||||
---
|
||||
title: Enterprise settings and policy management
|
||||
description: The DM client manages the interaction between a device and a server. Learn more about the client-server management workflow.
|
||||
description: The DMClient manages the interaction between a device and a server. Learn more about the client-server management workflow.
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# Enterprise settings and policy management
|
||||
|
||||
The actual management interaction between the device and server is done via the DM client. The DM client communicates with the enterprise management server via DM v1.2 SyncML syntax. The full description of the OMA DM protocol v1.2 can be found at the [OMA website](https://technical.openmobilealliance.org/).
|
||||
The actual management interaction between the device and server is done via the DMClient. The DMClient communicates with the enterprise management server via DM v1.2 SyncML syntax. The full description of the OMA DM protocol v1.2 can be found at the [OMA website](https://technical.openmobilealliance.org/).
|
||||
|
||||
Enterprise MDM settings are exposed via various configuration service providers to the DM client. For the list of available configuration service providers, see [Configuration service provider reference](mdm/index.yml).
|
||||
Enterprise MDM settings are exposed via various configuration service providers to the DMClient. For the list of available configuration service providers, see [Configuration service provider reference](mdm/index.yml).
|
||||
|
||||
Windows currently supports one MDM server. The DM client that is configured via the enrollment process is granted access to enterprise related settings. During the enrollment process, the task scheduler is configured to invoke the DM client to periodically poll the MDM server.
|
||||
Windows currently supports one MDM server. The DMClient that is configured via the enrollment process is granted access to enterprise related settings. During the enrollment process, the task scheduler is configured to invoke the DMClient to periodically poll the MDM server.
|
||||
|
||||
The following diagram shows the work flow between server and client.
|
||||
|
||||
@ -21,9 +21,9 @@ The following diagram shows the work flow between server and client.
|
||||
|
||||
This protocol defines an HTTPS-based client/server communication with DM SyncML XML as the package payload that carries management requests and execution results. The configuration request is addressed via a managed object (MO). The settings supported by the managed object are represented in a conceptual tree structure. This logical view of configurable device settings simplifies the way the server addresses the device settings by isolating the implementation details from the conceptual tree structure.
|
||||
|
||||
To facilitate security-enhanced communication with the remote server for enterprise management, Windows supports certificate-based mutual authentication over an encrypted TLS/SSL HTTP channel between the DM client and management service. The server and client certificates are provisioned during the enrollment process.
|
||||
To facilitate security-enhanced communication with the remote server for enterprise management, Windows supports certificate-based mutual authentication over an encrypted TLS/SSL HTTP channel between the DMClient and management service. The server and client certificates are provisioned during the enrollment process.
|
||||
|
||||
The DM client configuration, company policy enforcement, business application management, and device inventory are all exposed or expressed via configuration service providers (CSPs). CSPs are the Windows term for managed objects. The DM client communicates with the server and sends configuration request to CSPs. The server only needs to know the logical local URIs defined by those CSP nodes in order to use the DM protocol XML to manage the device.
|
||||
The DMClient configuration, company policy enforcement, business application management, and device inventory are all exposed or expressed via configuration service providers (CSPs). CSPs are the Windows term for managed objects. The DMClient communicates with the server and sends configuration request to CSPs. The server only needs to know the logical local URIs defined by those CSP nodes in order to use the DM protocol XML to manage the device.
|
||||
|
||||
Here's a summary of the DM tasks supported for enterprise management:
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: WMI providers supported in Windows
|
||||
description: Manage settings and applications on devices that subscribe to the Mobile Device Management (MDM) service with Windows Management Infrastructure (WMI).
|
||||
ms.topic: conceptual
|
||||
ms.date: 08/10/2023
|
||||
ms.date: 07/08/2024
|
||||
---
|
||||
|
||||
# WMI providers supported in Windows
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user