Semi-automating profile installation in Big Sur

It’s pretty well known among Mac admins that, starting with Big Sur (macOS 11), Apple has removed the ability for the profiles command to silently install .mobileconfig profiles. Apple wants you to use an MDM to deliver profiles silently… or have users themselves manually install profiles.

If you try to install them silently the old way, you’ll get an error message:

/usr/bin/profiles -IF ~/Desktop/Totally\ Fake\ Wi-Fi\ Profile.mobileconfig
profiles tool no longer supports installs. Use System Preferences Profiles to add configuration profiles.

But you may still have reasons to semi-automate profile installations outside of them being MDM-delivered.

If you double-click the .mobileconfig, all it does is give you this notification, and clicking it doesn’t actually launch up System Preferences:

But if you run a command like this: open /System/Library/PreferencePanes/Profiles.prefPane ~/Desktop/Totally\ Fake\ Wi-Fi\ Profile.mobileconfig, System Preferences will launch up and prompt the user to take action to install the profile:

Once the user does take those actions, the profile will be installed!


Posted

in

by

Comments

6 responses to “Semi-automating profile installation in Big Sur”

  1. Florian Avatar
    Florian

    This seems like a decent workaround but I got one issue. Seems like the „Downloaded“ section can not hold more than one item but I’d like to provide several profiles at once. How could I get around this?

    1. alanysiu Avatar
      alanysiu

      I think if you have multiple profiles you want installed, the best way to deliver them is via user-approved MDM. But you may be able to use some kind of “wait” loop that waits until the first profile is installed before prompting for the next one to be.

  2. Larry Staley Avatar
    Larry Staley

    Alan, as always a great workaround

  3. Bert Mahoney Avatar
    Bert Mahoney

    Thanks so much for this! Really appreciate it. Was all over the web looking for a solution to this EXACT issue and this worked. Cheers!

  4. sebus Avatar
    sebus

    zsh: permission denied: /System/Library/PreferencePanes/Profiles.prefPane

  5. GrumpyMacTech9000 Avatar
    GrumpyMacTech9000

    This is a massive pain in the arse, to be blunt. I understand Apple’s perspective on security and how they don’t want the unsuspecting user to have profiles installed surreptitiously but this is a major obstacle for Mac management in corporate and educational environments.

    “Use MDM” say Apple. We do. We use Apple’s MDM.

    And here’s the issue. One day, Profile Manager decides to start behaving unusually for no apparent reason. iPad enrolment via ASM no longer works and errors when the device is pointed at our Profile Manager machine. It worked fine yesterday but not today. We need iPad enrolment to work. We test Mac enrolment and that’s hosed too. Little surprise when I tell you we need that to work too.

    Apple’s official Profile Manager recovery “solution” is Time Machine so I jump through a few hoops and rewind the Mac server a couple of weeks. Following the restoration it’s left overnight. I come into work this fine morning only to be immediately accosted by staff members complaining of no internet access and no Microsoft Office on their MacBooks. Checking on Profile Manager shows a slew of queued tasks all time-stamped with the same date as the Time Machine backup. That’s not what I want to see. Restart the Mac server and suddenly it’s back in the room and happy to communicate again.

    Unfortunately the damage is already done and any M1 Airs present in the building and connected to the network have dumped their MDM-supplied profiles including Wi-Fi payloads, SSL inspection certificate (required for HTTPS access by our web filter) and all pushed applications.

    Marvellous.

    Our older MacBooks on Catalina are a cinch to sort. Plug in Ethernet, fire up ARD, copy the current trust and enrolment profiles to the admin accounts and run the Profiles command to install them silently.

    The M1s are a different prospect as this article points out, but it gets worse. None of our users have Admin accounts, for good reason. They can’t be trusted. They can’t be trusted to read important emails, can’t be trusted to follow and carry out instructions, and certainly can’t be trusted not to install junk like MacKeeper when something doesn’t work as expected.

    This means they can be prompted by sending the “open /System/Library/PreferencePanes/Profiles.prefPane” command via ARD but they can’t do anything without admin credentials, so we have to enrol EVERY SINGLE ONE INDIVIDUALLY, BY HAND.

    Thanks Apple.

    Unfortunately, and surprisingly given how long Apple have been around, they simply don’t understand enterprise and education and fundamentally treat their devices as personal rather than institutional. If Apple actually thought this through then devices enrolled in Business Manager or School Manager should explicitly allow remote administration functionality – such as the Profiles command – that can otherwise be blocked on retail devices not enrolled in Apple’s management programs. By all means, protect the great unwashed from themselves but give us admins a break and don’t make our jobs harder than they already are.

Leave a Reply

Your email address will not be published. Required fields are marked *