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

January 6, 2021

Mac admin’ing

alanysiu

Tags:

big sur, macos, profiles

Comments

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

Florian

January 13, 2021

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?

Reply
1. alanysiu
  
  January 15, 2021
  
  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.
  
  Reply
Larry Staley

March 31, 2021

Alan, as always a great workaround

Reply
Bert Mahoney

May 11, 2021

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!

Reply
sebus

October 23, 2021

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

Reply
GrumpyMacTech9000

July 15, 2022

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.

Reply
Kent West

April 30, 2024

It’s two years later, and I’m leaving this comment to say one thing:

GrumpyMacTech9000 is EXACTLY correct!

Reply
Importando perfis de política no macOS – Eduardo Mozart

August 27, 2024

[…] Semi-automating profile installation in Big Sur. Alan Siu’s Blog. […]

Reply
Ber

November 6, 2024

This does not work as of macOS Sonoma. If a .prefPane is embedded in a main Settings menu option (like Profiles is a submenu of Privacy & Security) then you will only open the main Settings menu (Privacy & Security). Tried several ones, all behaved like this.

Reply
1. alanysiu
  
  November 16, 2024
  
  Can you try open x-apple.systempreferences:com.apple.Profiles-Settings.extension? I don’t know if that’ll work to prompt for installation, but it should work to open the correct pref pane.
  
  Reply