VPN profile will not import on macOS: read the payload first

When a profile installs cleanly on one Mac and gets refused on another, the network has not been reached yet, so certificates, gateways and passwords deserve no blame. The installer stopped at a payload it would not accept, and it normally records which one. That leaves the profile file and whatever generated it as the only sensible places to work, and it makes wiping settings on the client a way of destroying evidence rather than a repair.

Read the profile instead of resetting the Mac

Export the .mobileconfig and look at what it actually carries before touching the client:

plutil -p profile.mobileconfig | head -60

A VPN profile is really two payloads doing different jobs: com.apple.vpn.managed holds the connection, and com.apple.dnsSettings.managed holds resolver configuration. Installation halts at the first payload the installer rejects, and the rejection lands in the system log with that payload named, so the log is what tells you which section to open. Keep a copy of the last profile that did import, because that file is the baseline your diff gets measured against.

What the generator quietly added

Apple Configurator 2.15 build 7A23 emitted the following block inside its DNS payload:

<key>DNS</key>
<dict>
  <key>SupplementalMatchDomainsNoSearch</key>
  <integer>0</integer>
</dict>

On macOS 12.1, profiles written by that build were rejected at import. A connection made with Configurator 2.11.1 went in without complaint, since that release never wrote the key at all. Remove the whole DNS dictionary or just the offending key, save it again, then retry on the same machine before you change anything else. That single edit is usually the entire repair.

The tool has a trap worth knowing before you trust it. Once the key had been deleted, saving the same connection did not put it back, and it reappeared only when a connection was created from scratch. Treat every freshly generated profile as suspect and inspect it, particularly when a whole batch of connections was made in one sitting.

The MDM path fails somewhere else

A management service pushing the same profile can fail in a different place: the client complains that no VPN service was created at all. The reported instance had a payload configured for certificate authentication that nevertheless demanded a password field; filling it with a placeholder let the profile apply, and nothing ever used that value to authenticate.

If you take that route, store a dummy string and never a live credential, and keep the real secret out of the profile body. A profile carrying a working password becomes a file that has to be protected like a key, which is a considerably larger problem than the failed import you started with. Decide who owns that placeholder before the profile is distributed, so nobody later mistakes it for a value worth rotating. Documenting why it exists takes one line and saves an argument in six months.

Confirm the profile actually landed

Import success is not a working service, so check in this order:

profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20

The first command lists installed payloads; the second says whether a VPN service exists at all. The last one, run after connecting, shows the resolver the system will really use. Read them in that order and stop where the chain breaks, because a missing service makes any resolver question meaningless. A profile can be listed as installed and still own nothing usable, which is exactly the state this sequence is designed to expose.

Should the tunnel come up while a service entry still has no usable name, the display-name field was lost in the export, and the cure is a regenerated profile rather than a rename on the client. If the resolver keeps pointing at the local one, the DNS payload was removed more thoroughly than you intended.

Stage the rollout, one Mac at a time

Install on one managed Mac running the same OS build, then check three things separately: the service appears, the resolver changes, and a single real internal request succeeds. Only after all three should the scope widen.

Those are three different results that fail in three different ways, which is what makes one test machine worth the ten minutes. A profile that imports is not a profile that works, and the stage-one machine catches both kinds of failure before the rest of the fleet sees either.