Is there a terminal command to do this? I made one change to my 10.7 config profile in the JSS and resent it out to all machines but the few I've checked don't have the new preference enabled. I have tried rebooting and logging in/out a few times on the machines in question.
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?
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! :(
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,
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.
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?
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.
@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.
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.
Unfortunately I'm back here because of the User Approved profile kafuffle. 'jamf mdm' works fine for me now, but endpoints are never user approved in time for the Kernel extensions profile. I have a script to user approve an endpoint remotely.... but here I am working late hours, waiting for all the seats to clear so I can issue user approvals.
Anyone figure out how to lock down a system - ie kiosk it down to useless UNTIL they user approve the MDM profile?
@jhle1 - I can't comment due to the super secret nature on some of our lines of business.
@NightFlight I guess you could create a bunch of Software Restriction policies to block all common business apps (Office, Safari, Chrome, etc) and apply them to machines where the MDM profile isn't approved yet, by using a Smart Group, so that once they have approved the MDM profile the SR policies would be removed automatically?
Looks like all our machines that matter are pretty much in DEP. Problem being that DEP enrollment, isn't something you can re-run. That and I believe if you remove the framework for general troubleshooting - you loose your DEP enrollment status.
@KSchroeder - I've been re-thinking this and if I were to implement this sort of restriction without the ability to bake in instructions to approve the machine in order to release functionality - I'd have my head handed to me.
True story...I guess you could put the "how to approve MDM" instructions into the message that pops up when you block the app. It wouldn't have pictures or something like that, but might be enough?
I'm just solving problems, not with solutions that everyone will officially like :)