Mobile Device Management (MDM)

Often device corporate owned and paid (Regular employee of SBS or Enterprise)

MDM primarily focuses on managing the entire device. It allows IT administrators to control and secure the entire device, enforcing policies such as device encryption, passcode requirements, and device compliance. In the context of M365 Intune, this means having a comprehensive view and control over the Windows device itself.

Mobile Application Management (MAM)

Often BYOD Bring your own device private

MAM, on the other hand, shifts the focus to managing and securing specific applications and their data rather than the entire device. This is particularly beneficial in BYOD scenarios where maintaining a balance between security and user privacy is crucial.

1. Mobile Device Management (MDM) Often device corporate owned and paid (Regular employee of SBS or Enterprise)

MDM primarily focuses on managing the entire device. It allows IT administrators to control and secure the entire device, enforcing policies such as device encryption, passcode requirements, and device compliance. In the context of M365 Intune, this means having a comprehensive view and control over the Windows device itself.

• Device Control: With MDM, IT administrators have full control over the enrolled devices. They can enforce policies, configure settings, and monitor the device’s health and compliance. This includes setting up device passcodes, encryption, and remote wiping in case a device is lost or compromised.

• Device Inventory: MDM solutions provide detailed information about the device’s hardware and software inventory. This allows IT admins to track device status, update compliance, and ensure devices are up to date with the latest security patches.

• Configuration Management: MDM enables the centralized management of device configurations and settings. IT professionals can define and enforce policies related to Wi-Fi, VPN, email, and more, ensuring consistent and secure device settings.

• App Deployment: MDM can also facilitate app deployment by pushing apps to devices, making it easy to install, update, or remove applications across the organization.

• Security Policies: MDM solutions help enforce security policies such as disabling camera access, restricting app installations, and implementing VPN settings to enhance device security

Pros of MDM:

• Full Device Control: MDM provides end-to-end control over the device, ensuring that all aspects of the device adhere to security policies.
• Comprehensive Security: It enables the enforcement of security measures on the entire device, reducing the risk of data breaches.

Cons of MDM:

• Privacy Concerns: Employees may have concerns about privacy since MDM gives administrators access to the entire device, including personal data.
• Potential User Resistance: Users might be hesitant to enrol their personal devices in MDM due to the level of control exerted by IT.

2. Mobile Application Management (MAM) (Often BYOD)

MAM, on the other hand, shifts the focus to managing and securing specific applications and their data rather than the entire device. This is particularly beneficial in BYOD scenarios where maintaining a balance between security and user privacy is crucial.

MAM, on the other hand, focuses on securing and managing only the apps and data on a device, rather than the entire device itself. Key aspects of MAM include:

• App Management: IT administrators can control how apps are used on a device without affecting the device itself. This includes securing corporate apps and data, managing app permissions, and controlling data sharing between apps.

• Data Protection: MAM solutions allow for the separation of corporate and personal data on a device through containerization. This ensures that corporate data is protected and can be remotely wiped or controlled without affecting the user’s personal data.

• App-Level Security: MAM enables app-level security policies, such as requiring a PIN or biometric authentication to access specific apps, which helps protect sensitive corporate information.

• App Deployment: MAM solutions often provide app distribution and management capabilities, allowing IT to deliver, update, and revoke access to specific corporate apps as needed.

In summary, the primary difference between MDM and MAM for IT professionals is that MDM focuses on managing and securing the entire device, while MAM focuses on managing and securing the apps and data on the device. In practice, many organizations use both MDM and MAM in combination to create a comprehensive mobile device management and security strategy that addresses the unique needs of their workforce.

Pros of MAM:

• App-Level Security: MAM allows for granular control over corporate apps, ensuring that only authorized users can access sensitive data within those apps.
• User Privacy: Since MAM doesn’t involve managing the entire device, it tends to be more privacy-friendly and is often preferred by users in BYOD scenarios.

Cons of MAM:

• Limited Device Control: MAM doesn’t have the same level of control over the device as MDM, which could be a limitation in certain security scenarios.
• Complexity: Managing security at the app level can be more complex than managing it at the device level.

dsregcmd /status

Lines Relevant to Manual Join Process:

dsregcmd /status

Lines Relevant to MDM Enrollment:

1. AzureAdJoined:

This line indicates whether the device is Azure AD joined. If it says “YES,” the device has been manually joined to Azure AD.

2. DomainJoined:

This line indicates whether the device is joined to an on-premises Active Directory domain. If it says “YES,” the device is domain-joined.

https://learn.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd

3. DeviceId:

The DeviceID uniquely identifies the device within Azure AD. This can be useful for tracking the device’s Azure AD association.

1. MdmEnrolled:

This line indicates whether the device is enrolled in Mobile Device Management (MDM). If it says “YES,” the device is enrolled in an MDM solution, such as Microsoft Intune.

2. UserEmail:

Displays the email address of the user associated with the device. This is relevant as the user’s enrollment status in MDM is tied to the device.

3. ManagementServerAddress:

This line provides information about the MDM server’s address. In an Intune-managed environment, this should point to Intune’s service endpoint.

4. EnrollmentServerAddress:

Similar to ManagementServerAddress, this line indicates the server address used for enrollment. In an Intune scenario, this would be relevant to the Intune enrollment service.

5. UserToken:

This token represents the user’s identity in the MDM system. If the device is MDM enrolled, this token would be associated with the user’s MDM profile.

Here you see a HYBRID Joined device and THEN MDM Enrolled > you can change the PRIMARY user in Intunes.

Owenership shows “Corporate”. Devices where ADS (On Premisis Joined) and then via Hybrid Azure synced. After that AUTO Enrolled in MDM via GPO Settings.

TEST #1 to show what happens if users which does enrollment is not allowded to Enroll into MDM.

CLIENT: SEA-WS1

DOMAIN ADS on-premises: NO

IS workgroup: YES

Azure Security Group “Intunes_USERS” member: NO

MDM User scope: > SOME > Azure Security Group “Intunes_USERS”

The user initiating the joining process is not a member of the ‘Intunes_USERS’ security group, which is specified in the Microsoft Intune MDM scope (with only one group selected). As a result, the user lacks the necessary rights to enroll a device into Intune MDM management.

Because the user which joined the DEVICE to AZURE was NOT listed in the Security Group which we have limited on INTUNES MDM / MAM

enrollment the client only appears UNDER Entra/Azure. You will not see it under INTUNES Devices. Because the user did NOT have the right to ENROLL the device for INTUNE MDM.

You will not see it under INTUNES Devices. Because the user did NOT have the right to ENROLL the device for INTUNE MDM.

https://learn.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd

AzureAdJoined: Set the state to YES if the device is joined to Microsoft Entra ID. Otherwise, set the state to NO.

EnterpriseJoined: Set the state to YES if the device is joined to an on-premises data replication service (DRS). A device can’t be both EnterpriseJoined and AzureAdJoined.

DomainJoined: Set the state to YES if the device is joined to a domain (Active Directory).

DomainName: Set the state to the name of the domain if the device is joined to a domain.

Test #2 aims to demonstrate the outcome when users allowed to enroll in MDM are given the opportunity to do so. Let’s repeat the same test with the user included in the Azure Security group INTUNE_USERS.

CLIENT: SEA-WS1

DOMAIN ADS on-premises: NO

IS workgroup: YES

Azure Security Group “Intunes_USERS” member: YES

MDM User scope: > SOME > Azure Security Group “Intunes_USERS”

User which joins is MEMBER of the Security Group “Intunes_USERS” which is listed on the MICROOSFT Intune MDM SCOPE (1 Group selected)

As the user joining the workgroup (BYOD) device to Azure is also a member of the Azure Security Group INTUNES_USERS, and this group is listed under Microsoft Intune Autojoin, the user has the capability to: a) Join the device to Azure and b) Simultaneously enroll the device into MDM/Intune.

Above: MDM

Below: Azure JOINED

In Entra/Azure you see the device like this now:

In Intunes/MDM you see the device like this:

< You can’t change the PRIMARY user in Intunes/M365 Portal

Ownership shows as ‘Personal,’ even if the device was joined to on-premises Active Directory (ADS) and then enrolled exclusively to MDM, without Hybrid Azure existing.

Is this scenario you are NOT able to change the PRIMARY USER in Intunes. The buttons are greyed out.

1. Lack of Hybrid Azure AD Join:
   Without a hybrid Azure AD join setup, the synchronization of user attributes, including the primary user, between on-premises AD and Azure AD may be limited. Azure AD might not have the necessary information to manage primary user assignments.
   

1. Syncing Limitations:
   The synchronization process might not be capturing or updating the primary user attribute in Azure AD. This could be due to configuration limitations or constraints in the sync process.

1. Azure AD as the Source of Authority:
   In scenarios where Azure AD is not the source of authority for user attributes, changes made in Azure AD might not be allowed, especially when it comes to certain attributes like primary user.

Possible Steps to Address:

1. Hybrid Azure AD Join:
   Consider implementing a hybrid Azure AD join if it’s feasible for your organization. This allows for more seamless synchronization of user attributes between on-premises AD and Azure AD.

1. Check Azure AD Connect Configuration:
   Review the configuration of Azure AD Connect to ensure that it is set up to synchronize the necessary user attributes, including primary user information.

1. Evaluate Azure AD Join:
   In some scenarios, if business requirements allow, you might consider transitioning to Azure AD join instead of on-premises AD join. This simplifies the user/device management model and can lead to more straightforward management in Intune.

Keep in mind that the ability to change the primary user might be influenced by various factors specific to your organization’s setup and configurations, and the guidance provided might need to be adapted based on the details of your environment.