MDM status is displayed as off when it's actually on #17692
Assignees
Labels
bug
Something isn't working as documented
~critical bug
This is a critical bug and may require a patch release.
~csa
Issue was created by or deemed important by the Customer Solutions Architect.
customer-preston
#g-mdm
MDM product group
P1
Prioritize as critical
:release
Ready to write code. Scheduled in a release. See "Making changes" in handbook.
~released bug
This bug was found in a stable release.
Milestone
Comments
pacamaster
added
bug
nonpunctual
changed the title
nonpunctual
added
the
~csa
|
@roperzh @georgekarrv heads up. Thanks! |
nonpunctual
added
#g-mdm
|
Thanks - What we would expect as the end-user of fleet solution is that fleet automatically retry the enrollment whenever it's in "failed" state of "off" state |
|
Also, the issue name is "MDM Enrollment Migration" but it happens enven with device that were never enrolled on any MDM, and for all kind of windows version / os (home, pro, 10, 11..) |
|
Today (D+2) only 19/61 windows hosts are turned on, it's seems the MDM is able to move from
|
|
logs in fleet instance :
|
georgekarrv
added
the
:release
|
Hi, update on our side As stated, we have some Windows MDM device that where properly enrolled with MDM ON, and for un unknown reason they switch to MDM OFF Here are the osquery logs for one of this device |
|
Another one with " |
|
Hi team, just to provide some context - as shared by @valentinpezon-primo above, this problem is not limited to migrations:
And
Just to put some numbers to this:
|
|
@martinpannier I'm sorry you're experiencing this. We are prioritizing and will investigate today. |
|
Appreciate it - thanks @lukeheath and team |
1 task
dantecatalfamo
added a commit
that referenced
this issue
Mar 26, 2024
#17692 Recently there was a change that filtered out hosts in `EnrollmentState` 3. This change may cause some hosts that are in otherwise good health to appear unresponsive to MDM in the management UI. This change will allow hosts with `EnrollmentStatus` 3 show as enrolled. The root cause of some hosts being in state 3 is still not entirely clear, but may have to do with either trying to re-enroll once already enrolled, or windows updates causing some sort of issue with fleet. Despite the "failed" `EnrollmentState` 3, the host will still display that the system is managed by Fleet, and will actively sync.
georgekarrv
pushed a commit
that referenced
this issue
Mar 26, 2024
#17692 Recently there was a change that filtered out hosts in `EnrollmentState` 3. This change may cause some hosts that are in otherwise good health to appear unresponsive to MDM in the management UI. This change will allow hosts with `EnrollmentStatus` 3 show as enrolled. The root cause of some hosts being in state 3 is still not entirely clear, but may have to do with either trying to re-enroll once already enrolled, or windows updates causing some sort of issue with fleet. Despite the "failed" `EnrollmentState` 3, the host will still display that the system is managed by Fleet, and will actively sync.
lukeheath
added
P1
georgekarrv
pushed a commit
that referenced
this issue
Mar 26, 2024
#17692 Recently there was a change that filtered out hosts in `EnrollmentState` 3. This change may cause some hosts that are in otherwise good health to appear unresponsive to MDM in the management UI. This change will allow hosts with `EnrollmentStatus` 3 show as enrolled. The root cause of some hosts being in state 3 is still not entirely clear, but may have to do with either trying to re-enroll once already enrolled, or windows updates causing some sort of issue with fleet. Despite the "failed" `EnrollmentState` 3, the host will still display that the system is managed by Fleet, and will actively sync.
noahtalerman
changed the title
|
In the cloud city, |
|
Hi @georgekarrv @dantecatalfamo , It means now fleet will display them as "Enrolled" even if it's failed ? Are we still able to run mdm commands on them ? Does the custom OS settings (Configuration profile ) are well applied on the host ? |
|
Yes this 'failure' is not necessarily a full failure of mdm capabilities. (We still haven't tracked 100% what causes this) Ultimately this looks like an event status where we do something that causes a failure and this enrollment registry value changes while still maintaining mdm connections and syncs. |
Okay ! Thanks for the udpate |
|
@noahtalerman @georgekarrv I know we discussed adding this in a separate issue but I don't want it to be lost. I think we should consider deleting previous Windows enrollment artifacts from the Registry when a migration to Fleet Windows MDM occurs. This (in my mind) would solve the problem. if there are no artifacts from prior enrollments, there would not be any question about reporting. There probably are edge cases where customers may want to retain previous enrollments on the Host, or, they may want to try enrolling in multiple management systems. If this is a concern we could have a switch in the UI for disabling the capability to "clean up" old Registry artifacts on a new Fleet enrollment. |
|
Absolutely, if you open a FR and we get it prioritized that sounds fine to me. I will say that in this case our reporting was based on the Fleet registry entry and didn't look to be interfering from our initial investigation. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Fleet version:
Reported in Fleet Fleet 4.47.0 Go go1.21.7
osquery 5.11.0
Fleetd 1.22.0
Web browser and operating system:
Current version
💥 Actual behavior
🧑💻 Steps to reproduce
🕯️ More info (optional)
enable-scriptswas part of the tagged clients' enrollment packageEnrollmentStategets set to 4 for "failed" and there does not appear to retry and the endpoint gets stuck in this statePlease see possibly related issue: #17695
The text was updated successfully, but these errors were encountered: