My account manager recommended running "sudo jamf manage" but I've had better luck with "sudo jamf mdm"

Reading stuff like this makes me dread even more migrating from MCX to config profiles.

Yep it is scary but this is the route Apple is going. Better to get stuck in and work with the community to make it better. Apple won't listen to us but they will listen to JAMF if they file something.

@bajones Thanks. I tried sudo jamf manage and sudo jamf recon. I'll add the mdm option to my troubleshooting belt :)

I ended up first adjusting the scope to no one. Then tomorrow I'm going to push out a new config profile. Anyone know how often the machines should be checking for a new config profile? Every15?

Best

I'm with CasperSally. We've been avoiding Config Profiles so far, because, quite frankly everything I've read about them makes them sound more flaky than an overbaked baklava!

Damn you Apple on deprecating MCX. It worked just fine, and it seems they are moving to something that is not only not as flexible (at first) but more unreliable to boot. Wonderful! :(

@rcurran I'm pretty sure profiles get pushed almost instantly since it uses Apple's push notification frameworks. I could be wrong on this however.

Yep, commands go through APNS.

For me, commands are quicker AM UK then PM.

Servers seem busier in the PM when the US wakes.

Same for iOS & OSX

All good suggestions. If worse comes to worse, we can always push out config profiles via a DMG and use the built in "profiles" command to install it similar to the following:

profiles -I -F /path/to/file.configprofile

Toss a 'man profiles' in Terminal to get some more options. If things get worse, please feel free to reach out to your account manager and we can get this worked out.

Thanks a lot,

Jason Lieble
Support Specialist
JAMF Software

Hey guys,

I know that post is a really old one but hopefully one of you will respond.

Like Jason mentioned, I pushed my profile (user level, not computer level) to my clients computer and tried to install it by using a script running profiles -I -F /path/to/file.configprofile. But it could not be installed! I think it's because, if your read 'man profiles' option -U, sais: you can only install profiles for the current user, this is only useful for validation.

That means, I cannot install a user level profile with a script, because the script runs as the local admin on the clients computer. Does that make sense? Any suggestions on that?

Thanks in advance.

Cheers,
Fabian

I suppose you could install a user level profile using 'su' in your script and cycle through the list of users that you want to target.

That's what I tried by using su -l, but I had the same effect and also I was prompted to enter the users password.

you can send a Blank Push.... that usually get things going

I have better questions.

How do I use the API to determine which profiles I should have installed - can't.
How do I pull in profiles when I don't have what I should have - can't.

3 years later and were still dealing.

If you look at the profile in System Preferences, does the profile have the new settings listed and it just isn't taking effect, or is the profile still the old one, or is the profile still the old one?

1. A blank pus something works.
2. The sudo jamf mdm command to start. Second, you can download the profile manually from the JSS and install it. See if it works that way. If it doesn't, there may be something wrong with the profile itself and it will need to be re-created.
3. If it downloads and installs normally and works, and the sudo jamf mdm command doesn't pull down the new profile, delete that profile manually and try to get it again.
4. You can also try un-enrolling the device and re-enrolling it to get the profiles back down.

You can also use the sudo profile -P to get a list of identifiers for the profiles you have installed. Then, take this script below and repeat the first line for all of the profiles you have.

#!/bin/sh

#Repeat this line for each profile indentifier you have
/usr/bin/profiles -R -p *<INSERT PROFILE IDENTIFIER HERE>*

sleep 3

# Jamf MDM remove
/usr/local/jamf/bin/jamf removeMdmProfile

sleep 5

# Jamf MDM Add
/usr/local/jamf/bin/jamf mdm


exit 0

So far as i'm able to determine, there's still no way to trigger a 'blank push' progmatically, but that's what works most of the time. I've tried pulling the mdmprofile, which pulls all profiles. Then I follow up with a jamf mdm, or jamf manage which enforces about %70 of the time. When stuck pending the profiles can just sit there for days.

Unfortunately, this is a proxy configuration and needs to be in place within seconds. The scope is limited by network segment, which can be fun trying to update while the proxy is enforced and your off-net.

I'm starting to really hate profiles. They are not reliable in the slightest.

@NightFlight – I've had pending profiles stuck in place for months. It's really annoying since I'm trying to push out a new config profile for wifi since my company is moving to new offices with new SSID information, and nearly 60% of my managed macs aren't pulling the profile. It's been pending for 24 hours now on all those machines, but I see some of those machines have profile pushes going back to January and December. :-(

@michael-brodt – Thank you for that little script. I tested it and one of my machines that was still waiting on profiles now finally has those config profiles installed.

Just chiming in on the continued frustration saga with Profiles.
I literally moved off an APNs pushed profile for a cert Configuration Profile due to the massive unreliability of getting it deployed. Config Profiles are still very good for deploying certificates, but using Apple's push process proved far too frustrating. On top of that, we had weird cases of the profile vanishing from Macs, which was fun considering it was an intermediate SSL decryption cert, so clients it vanished on suddenly could not hit any secure sites from inside the network. Ugh!

I just moved it over to installing the profile via script with the profiles command, In fact, I came up with a way of deploying Config Profiles direct from my JSS without needing to even package them up. My script can pull down the profile using the API and install it. No packages needed.

I fully understand that profiles deployed this way are tougher to update later, and can't be replaced with a pushed profile, but it's worth it to me in this case at least, since I needed a way to ensure that it a) got deployed when I said so, and b) STAYED on the Mac after it was deployed. Apple's push process was not really giving me either requirement in a way I felt satisfied with.

I'd like to point out that we got help from the JAMF support team to figure out what turned out to be our issue with profile delivery. We had a routing issue on our end and once we fixed that we've had nothing but success with profile delivery in a nearly instantaneous fashion.

They really went to bat on conference with us for a couple hours to help US with with what turned out to be OUR issue.

I should now proceed to eat my hat.

@NightFlight Does that mean you'll be changing your avatar to a half eaten hat? :)

Anyway, good to hear that Jamf helped you get it working reliably. I suppose there could be a routing issue on our end as well causing problems, though I'm not sure how to explain the cases of Profiles that were deployed that somehow got removed later, in our case. That doesn't sound like a routing issue to me.

@mm2270, would you be willing to share your script? I have a use case where the profile I am trying to deploy will often fail for various reasons (typically off-network related) and once a profile fails, there doesn't seem to be an easy way to re-push it.

Thanks,
Jim

@jstasik Sure, you can find my script located here.
Feel free to comment or create an issue on the github repo if you run into any problems with it. Be sure to carefully read the notes in the script as well as the description in the main github section on how it works and how to use it.

The script needs to be run as root and, as designed, must run from the jamf binary, i.e. from a policy, or via sudo jamf runScript -script <script_name> -path <path_to_script> -p1 <apiusername> -p2 <apipassword>, etc.

I had a client that would not pick up it's MDM Profile after a re-image. I deleted the Client in JSS and ran the JAMF Client, set it to be in scope for the policy and it picked it up. I guess this would work for the OP but it's a bit heavy handed if it's more than a handful of clients.

@Initialised Sounds like you ran into the same problem I did with not being able to run a QuickAdd on machine after a re-image. After some back and forth with Jamf tech support I ended up modifying my QuickAdd package to add a preinstall script that deletes the machine from my JSS.

Another trick I came across today that fixed an issue we had with a user who couldn't pull a Profile from Self Service (it would just hang forever)...noticed that the user wasn't listed in "MDM Capable Users" in General inventory; running sudo jamf mdm didn't do it, then had him try sudo jamf mdm -userLevelMdm and that worked and MDM-enabled the user. He was immediately able to pull profiles from SS and a few that were assigned previously.

I had a system yesterday that was to receive a new configuration profile but came up with failed. The system was in a smart group so I configured the system as an exclusion and then took it back out of the exclusion and all was well. It's times like this that I miss Group Policy from my Windows admin days.