Feb 14 2019 02:02 AM
Feb 14 2019 02:02 AM
I managed to set up Intune for my Windows 10 PCs. So basically they get auto enrolled with their work account, the Terms and conditions appears etc, however the MDM and Compliant are None and N/A.
Auto enrolment works fine. When you log onto intune you can see the Azure connected device, however even though the device appears, under the MDM and compliant columns they are listed as None and N/A. I can't even manage the PC..
Can someone shed some light on this as I am completely lost
Feb 14 2019 05:02 AM
Just an update. I managed to enrol my device however I had to install the company portal to enrol my device. I was under the impression that Windows 10 has it imbuilt and you dont need to stay downloading the Company portal?
Feb 14 2019 05:45 AM
This is true, the company portal app is not required for enrollment. Auto-enrollment occurs with the first sign-in after the following 'Enable automatic MDM enrollment using default Azure AD credentials' is applied to a hybrid-joined computer or with AutoPilot when going through the OOBE. I may have changed my Intune column set but I never see anything referring to an "Azure-connected device." Are you looking at the Intune portal (devicemanagement.microsoft.com) or Azure Active Directory?
Also, I don't know how long you have waited, but the Azure AD Device entry takes some time (hours?) to update to show "managed" and "compliant" in my experience.
Feb 14 2019 06:34 AM
Was looking at portal.azure.com
With the company portal app it works.. However without the app all that automatically appears (after adding the work account) is the Azure ad device and nothing appears under All devices
Feb 14 2019 06:37 AM
Is the GPO setup and is the Azure AD device a hybrid-joined device?
Portal.azure.com is very vague, there are specific portals for both Intune and Azure Active Directory within portal.azure.com that can help you troubleshoot enrollment.
Feb 15 2019 12:00 AM
you wrote you managed to enroll the device using Company Portal, then it seems that your Auto Enrollment is not working like it should. You need to configure Auto Enrollment correctly then you don't need the company portal for successful enrollment. Just enable the MDM scope and leave the MAM scope at None otherwise MAM will take precedence.
For official documentation see here:
and here the important advice:
For BYOD devices, the MAM user scope takes precedence if both MAM user scope and MDM user scope (automatic MDM enrollment) are enabled for all users (or the same groups of users). The device will use Windows Information Protection (WIP) Policies (if you configured them) rather than being MDM enrolled.
For corporate devices, the MDM user scope takes precedence if both scopes are enabled. The devices get MDM enrolled.
Feb 15 2019 12:56 AM
Feb 15 2019 02:38 AM
Exactly you need to use Conditional Access for this and "require device to be marked as compliant"
To complete the picture you should have a compliance policy to define what makes a device compliant.
Feb 15 2019 05:34 AM
Thanks guys, I realised that when trying to enrol via autopilot and I am a normal user I don't get enrolled. If I log in with an admin account then I do get enrolled. This doesnt make sense as I am not going to grant all my users admin privileges.
Feb 15 2019 05:41 AM
There is no functionality to block this in regards of admin or normal user. You can restrict enrollment to AAD groups so an implicit restriction only. Please check your auto enrollment settings again (see post above) and verify that your "normal" user has an assigned Intune license.
Feb 15 2019 05:42 AM
This is not the case, even if you are enrolling as standard user in autopilot the device should get enrolled in Azure AD. Check if the user has valid license assigned and also Automatic MDM enrolment is configured all users or group of users.
Feb 15 2019 05:47 AM
With normal user the Device appears in Azure AD devices. With admin account it appears in Azure AD Devices and under All devices where I can then manage the device.
Feb 15 2019 06:00 AM
Can you verify the MDM user scope as mentioned in the following docs:
Feb 15 2019 07:16 AM
The standard user has:
Azure Active Directory Premium P2 & Intune licenses.
So hold on a second. I am logging on with the standard account which is prem AD account. Now my O365 account is a test .onmicrosoft account. There is no link to one another, however when I log on with my admin on prem account the device gets enrolled.
Feb 25 2019 03:53 PM - edited Feb 25 2019 04:40 PM
I have added a work account to multiple Windows 10 v1803 machines running Office 365 Pro Plus, and everything worked. Currently, we require BitLocker encryption and a password for the local account before the device is compliant.
I had my first machine today that would not cooperate. After adding the company portal, it worked. I haven't isolated the exact problem yet, but there were two main differences with the machine:
1. It is running the Office 2016 MSI installation of Pro Plus
2. The user had previously created a PIN for use with fingerprint, and was not requested to create a PIN and change the local account password at the time of adding the work account. I have seen the requirement to set a PIN and change the local account password on all of the other Windows 10 machines where a work account was added and the company portal was not installed.
If I can isolate the culprit, I'll reply back unless someone else responds indicating what may be the cause.
We're a little different from other orgs in that SCCM is still our MDM authority, but removing all of the user policy in SCCM seems to kick the user over to Intune standalone. The user requiring the Windows 10 company portal was already in Intune standalone with a compliant android device. It was kind of strange because the Windows 10 machine requiring the company portal was not appearing in Intune, SCCM, or on the Exchange device list. However, the Windows 10 machine did appear under the user's device list in Azure with no MDM, the way it does when SCCM is managing the device. The Windows 10 device listing in Azure had a compliance status of "N/A", which I haven't seen before.