MDM users needs to log in?

[alyssafriesen]

I just installed the MDM application on a new machine and enrolled in device management. I can see the device in Systems Manager, but not all of the profile settings are being applied. If see that under "Profiles" there is an error message that says "The MDM user needs to log in to the device for settings to be updated". 

I'm not finding any documentation on this and I'm not sure what it wants. I am logged into the machine and Microsoft reports that the sync is working correctly, but settings like WiFi are not propagating out to the device (which is connected via ethernet at the moment).

[PhilipDAth]

Authentication when enrolling is not a hard requirement, but I find it makes many things work better so I tend to use it.

You can authenticate against Office 365, Google and Active Directory.

https://documentation.meraki.com/SM/Device_Enrollment/SM_Enrollment_Authentication

[TomBenoit]

I am currently managing machines that are not on a domain.  I am getting this error message over time i.e. the profile works for a while and then it will not accept any updates I make to the profile.  The local admin account that setup the managed profile is logged in.  Any ideas?

[thunt]

We are having the exact same issue.  It works initially and then just stops working.

[thunt]

Agent version

Current Version:

3.5.2

[PaulF]

So, windows has two modes (currently) of enrollment. MDM and agent. Because the MDM is tied to a user account on the device, it can't be updated if that user is not logged in, and that's why you are getting this message

If you use the Systems Manage agent on the device, you won't get this error.

I hope that helps

Paul

[thunt]

We do use the Systems Manager agent on the device and we are getting this message.  We enroll the device via Windows profile and then install the agent.

[PaulF]

And if the user who enrolled the device using Windows profile is not logged in, regardless of whether they have the agent or not, you'll get the message.

[jand]

Would be great if this could be fixed.

Currently I use the following procedure for Windows Devices:

- Install Systems Manager Agent

- Give the future user admin rights to enroll the device.

- Ask the user to log in once

- enroll device

- logout the user

- take back admin rights

If the device then changes the user, you can repeat the whole process 😞 

Is that the right way?

[BlakeRichardson]

I am going to be really cheeky here and its just a joke but you could buy a Mac 😜

[MConley]

Yes, it all works just fine for Macs and iPads. Sigh.

[MConley]

We continue to be unable to perform as simple an operation as changing the password on our SSID thanks to our inability to push changes out to Windows devices. I continue to be stunned at Meraki's lack of response to this issue.

[PaulF]

The user who enrolled into MDM with Windows is the only user that will be affected by MDM commands

Therefore, THAT user has to be logged in for changes to Windows MDM profiles to be effective

[MConley]

As noted elsewhere in this thread, that is precisely what Meraki have gotten wrong. There are settings on Windows that are device-specific, not user-specific, and these need to be pushed out regardless of who happens to be logged in at any given moment. Wi-Fi passwords are one such setting; there are numerous others. The Meraki MDM model for pushing profiles to Windows devices is broken; it works correctly for macOS and iOS.

[PaulF]

You're absolutely right: WiFi configs can be applied at the user level or the device level. I'm checking with engineering as to which one we do, and I'm creating a feature request to allows admins to decide which of these it is

HOWEVER: What is immutable is the need for the ENROLLED user to be logged in for changes to be made. That is a restriction of Microsoft, and something we cannot change

[MConley]

The Meraki client service should be running in the background with admin privileges that allow it to make changes even when no user is logged in. Clearly this is possible, as any number of services run when there is no user logged in.

If that's not possible for you to implement, then Meraki MDM is next to useless for Windows devices, and I will recommend to our technology director and administration that we cancel our Meraki contracts as soon as feasible and move to some other MDM.

[PaulF]

as per: https://documentation.meraki.com/SM/Device_Enrollment/Systems_Manager_Agent_and_MDM_Profile_Enrollme...

You'll see that MDM profiles are installed with MDM, not the SM client. We cannot push MDM updates without the enrolled user being logged in. Again, this is a limitation of Microsoft's implementation of MDM

[TomBenoit]

I took the route of packaging updates into executables using NSIS and AutoHotKey for windows devices.  It was a bit of a learning curve to start but once you get over that you have infinite flexibility for changes.  I have an executable that changes wifi passwords if you are interested.  NSIS and Autohotkey are both free to download.      

[MConley]

Well, that's certainly an approach, and I can see how it would work. Rather defeats the purpose of bothering with an MDM, of course.

It's not dissimilar to the way I run our macOS fleet, installing apps via Munki even though they're enrolled in Meraki. That's mainly legacy, because I simply haven't bothered to make all the apps available to the Meraki Systems Manager. However, the salient point is that, if I did, I could push apps out to my Macs from Meraki and it would just work — whereas doing the same for Windows clients is effectively impossible.

(Also unlike the Windows clients, having the Macs enrolled in Meraki even though I use Munki for apps still makes sense, since I can push profiles out and make changes to them even if they're just sitting there at the login screen. We simply assumed this would work for Windows as well, and, clearly, we were wrong.)

But thanks for the suggestion.

[MConley]

I'm also going to note that 'kudos' is singular, not plural, and does not refer to a countable quality; there is no such word as 'kudo'. In exactly the same way that you do not give someone a 'congratulation', you do not give someone a 'kudo'. But, anyway....