@Bernard.Huang have a look at this it might be what you are looking for.
Thanks for that :)
As per the article, I have already used "sudo jamf mdm -userlevelmdm" command to enable the current user as MDM enabled.
BUT... the Macbook, as a device, has MDM capabilities = Yes, but MDM Capable Users still = <blank>
I am thinking this is the reason why I can't push any user-level profiles.
Hello,
I'm having a similar problem with MDM capable users.
The command 'sudo jamf mdm -userLevelMdm' returns with an error:
Getting management framework from the JSS...
Enabling MDM at the user level...
Error installing the user level mdm profile: profiles install for file:'/Library/Application Support/JAMF/0C4A5D23-C4E5-4F70-9018-B93286DB42FF.mobileconfig' and user:'root' returned 102 (Het nieuwe profiel voldoet niet aan de criteria voor het vervangen van het bestaande profiel.)
Downloading required CA Certificate(s)...
Problem installing MDM profile.
I can't find anything on this error on Jamfnation so far.
The Dutch sentence translates as follows:
The new profile does not comply to the criteria for replacing the existing profile.
After this the problem of not being able to install mac App Store application persists.
Installing home made applications does work for this user so technically she is mdm capable but not for mac app store items...? -.-
@Sirmacalot Were you able to find a resolution for your issue? We're having the same thing.
This actually occurs with all of our DEP systems in that I can't add or change whatever MDM Capable user is there (even if there's none).
Enabling MDM at the user level...
Error installing the user level mdm profile: profiles install for file:'/Library/Application Support/JAMF/{Long String of Numbers}.mobileconfig' and user:'root' returned 102 (New profile does not meet criteria to replace existing profile.)
Downloading required CA Certificate(s)...
Problem installing MDM profile.
Error running script: return code was 4.
Sadly no solution but for us it turned out that is was a temporary malfunction of the Apple App store.
The day after the user was able to download and install apps again from the app store.
@Sirmacalot @kevinwilemon
Try this, i had the exact same issue when trying to enable MDM for a new local account - JAMF support told me to run the following:
sudo rm -rf /var/db/ConfigurationProfiles
sudo jamf mdm -userLevelMdm
@ant89
Thanks for the reply. While that does work in removing all Profiles and adds them again, it does remove the benefits of enrolling through DEP Prestage (namely now configuration profiles can be removed by the user whereas when enrolled through DEP Prestage, MDM profiles are mandatory and we don't allow the ability to remove these profiles).
@ant89
This was just what I was needing. Thanks!
sudo rm -rf /var/db/ConfigurationProfiles
sudo jamf mdm -userLevelMdm
Thank you @ant89 for the tip, I wish this was not necessary to do.
Note that the command rm -rf /var/db/ConfigurationProfiles no longer works on 10.13 (SIP) -- use the profiles command instead.
Saved my hide. I have been "hands on" with devices for 12 hours with all sorts of issues and couldn't get around this one.
Thanks a TON!
@ant89 , you mention needing to use "the profiles command" now that the "rm..." bit doesn't work in 10.13. What is the profiles command?
You all should also be aware of the new note added to the kb for Enabling mdm for local user accounts where it mentions "For computers with macOS 10.13.2 and later, this workflow for enabling MDM for local user accounts will reset any previous User Approved MDM Enrollments. If you use this as a part of existing ongoing workflows, you should evaluate the impact of these changes."
Even though Apple currently states UAKEL (Previously SKEL) wont be enforced till 'Spring 2018' its still good to be aware of all the changes around User Approved MDM Enrollment - https://support.apple.com/en-us/HT208019
@mjurick I use this command
/usr/bin/profiles -R -p 00000000-0000-0000-XXXX-XXXXXXXXXXX (add your MDM profile identifier here)
jamf manage
I notice that it takes a few for the profiles to be added back. Sending a blank push sometimes helps.
@ant89 I was looking the profile command to remove the MDM profile too, but since we make the MDM Profile non-removable i'm getting the following output when trying to remove the profile via a script:
Running script Remove and Remanage Profile 10.13...
Script exit code: 1
Script result: profiles uninstall for identifier:'00000000-0000-0000-A000-4A414D4XXXXXX' and user:'root' returned 101 (Profile is not removable.)
Error running script: return code was 1.
So on 10.13 does the MDM profile in our DEP prestage need to be switched to "removable"? That seems like it would defeat the purpose of DEP enrollment and ensuring our computers stay managed.
Old Topic - but now in big sur this command is gone
So what is the workarround ? - I used this command after DEP enrollment with Jamf connect, but now if the user cannot be mdm capable anymore what to do ? - skip jamf connect ) ?
Hi, are there any new on that with Jamf Connect / Big Sur / MDM Enabled Users?
Also have this issue. Devices are enrolled via DEP. Users log in with JAMF Connect out of the box.
No MDM enabled users, so no IKEv2 profiles (User Level) etc.
Can anyone advise?
We using both Jamf Connect, for first authentication - but then have to do manual account creation to get the account MDM enabled. In Catalina Jamf Connect was enough, but as you write, if using user certs etc it will not work on Big Sur anymore
@KRIECCO What are we supposed to do in these situations then? I have users that we've shipped out computers, unopened, that are shipping with Big Sur and these folks dont seem to be getting MDM profiles installed. There's gotta be a solution for this.
The quickest would be to re-enroll them manually by opening browser and enroll them again
@KREICCO and @oartola
We enroll (DEP / automated enrollment) in the first place without JAMF Connect. We use the normal Apple Workflow with Account Creation by the user itself. In background our PreStage enrollment is of course creating a admin account for us. So the user has noch Admin rights and is MDM enabled. When the user is created and logged in, we take step two (in our case by Self Service) and we install Jamf Connect and do an reboot. Then the user had to login again with Jamf connect and connect to his already created lokal account. That is not a nice workflow for the user, but it was the only way I found to use Jamf Connect and have the User MDM Enabled.
@KREICCO and @oartola
We enroll (DEP / automated enrollment) in the first place without JAMF Connect. We use the normal Apple Workflow with Account Creation by the user itself. In background our PreStage enrollment is of course creating a admin account for us. So the user has noch Admin rights and is MDM enabled. When the user is created and logged in, we take step two (in our case by Self Service) and we install Jamf Connect and do an reboot. Then the user had to login again with Jamf connect and connect to his already created lokal account. That is not a nice workflow for the user, but it was the only way I found to use Jamf Connect and have the User MDM Enabled.
This is the way!
I would add that, you should automate it via DEPNotify and a LaunchDaemon that forces a reboot, and then disables Jamf Connect. We leverage JamfConnect only to sync local account with cloud credentials, and silently enable FileVault. Upon reboot our DEPNotify LaunchDaemon will verify that passwords have been sync and that FileVault is enable and key escrowed.
Is there still no easy way to make the user MDM capable with connect?
Hi @beek I tried to find better solution at the end of last year.
Here is what Jamf said (in November 2022):
The described behaviour (no MDM capable user created if you skip local user creation and use JC for user creation) is expected. Jamf Connect is MDM agnostic and exists outside of the initial SetupAssistant DEP experience. It is creating accounts just-in-time after the MDM process of device enrollment is complete. The account created is a local account (not bound). Thus, per Apple's specifications, it is not a "managed user." Changing a local user’s MDM capability requires the MDM profile to be re-installed or re-enrolled, which can affect User-approved MDM status if attempted programmatically. Re-enrollment may not be possible in future versions of macOS, limiting this further.