Tag Archive

Using the distribution-style flag in munkipkg for PreStage Enrollment in Jamf

Posted on February 1, 2023 by alanysiu

Even though Jamf has its own package creation tool (Jamf Composer), there are lots of great reasons to use munkipkg instead for creating custom packages, as Elliot Jordan outlines in You might like MunkiPkg.

One of the keys munkipkg has is the distribution-style key (more details in the munkipkg README), which is usually fine to leave as false.

But if you’re using a package for PreStage Enrollment, it has to be both a code-signed package and a distribution-style package (read more in Jamf Pro Documentation).

So all you have to do (apart from code-signing), is change the build-info.plist file from having


to having


Then rebuild your package and upload it to Jamf Pro.


Ensure your VMware Fusion Macs enroll in Jamf as Computers, not Devices

Posted on February 24, 2022 by alanysiu

It used to be that you could create a VMware Fusion virtual machine Mac, enroll it in Jamf (either by spoofing the serial number for Automated Device Enrollment or just using an auto-generated VM serial for manual enrollment).

Recently (not sure when, exactly), you may have noticed if you try to enroll a VMware Fusion Mac in Jamf, it will install the MDM profile… and that’s it. No jamf binary. No /var/log/jamf.log file. Your VM did enroll, but it enrolled to Devices, not to Computers.

To get it to enroll as a Computer in Jamf, you’ll need to remove the existing enrollment profile, shut down fully (not suspend/sleep) your VM, edit the VM’s .vmx file (right-click the VM and select Show Package contents to find the .vmx file) with a text editor, and set the following:

SMBIOS.use12CharSerialNumber = "TRUE"
serialNumber = "SERIAL"
hw.model = "MODEL"
serialNumber.reflectHost = "FALSE"
hw.model.reflectHost = "FALSE"
smbios.reflectHost = "FALSE"

where SERIAL is a fake serial number of your choice, and MODEL is the model you want to spoof (e.g., MacBookPro15,2).

Then, restart your VM, and try to enroll in Jamf again. If your spoofed serial is a real serial that’s in Apple Business Manager or Apple School Manager and assigned to your Jamf MDM, you can use sudo profiles renew -type enrollment to try to use Automated Device Enrollment, or you can go to your Jamf manual enrollment URL, authenticate, and manually enroll in Jamf.

If all goes well, your VM Mac should now be recognized as a Computer (Mac) and not a Device (iPhone/iPad).

Special shoutout to kevin.v on the MacAdmins Slack for the tip.


Signs you may have conflicting MDM profiles in macOS

Posted on November 8, 2021 by alanysiu

Jamf doesn’t currently let you easily separate out individual parts of a profile, so if you deploy a Restrictions profile, you have to enforce all the parts of the Restrictions profile. Sure, you can download the profile, un-sign it, modify it, re-sign it, and then re-upload it, but that’s not very easy to then modify going forward, and the re-signed profile won’t show you what’s actually being enforced.

You can—if you know what keys to use for what domains—create an “upload” profile with XML. You can also use a .json schema that creates the XML for you.

Just be careful not to mix and match a full templated profile from Jamf with a potentially conflicting XML “upload” profile.

One sign you may have conflicting profiles is if you notice the profile setting you want enforced is enforced… and then isn’t… and then is… and then isn’t. If you have conflicted enforced settings, macOS doesn’t know what profile to pay attention to, so it will use one or the other seemingly randomly.


“Invalid Message – The message could not be parsed.” with Jamf Cloud

Posted on May 5, 2021 by alanysiu

Invalid Message - The message could not be parsed. is an odd error message for a jamf recon when you’re using Jamf Cloud, because if you Google that error message, there are only two results:

The first is for on-premise Jamf and involves fixing a distribution point setting. The second tries to get some diagnostic data but then doesn’t actually give a solution.

But what if you get that message, and you’re using Jamf Cloud, not on-premise Jamf?

Well, I’ll tell you now what won’t fix it: unenrolling, deleting the device from Jamf, and re-enrolling; checking the distribution point in Jamf Cloud; using a mobile hotspot to bypass router issues.

What may fix it? Creating a brand new account and copying over only files and not settings.

There’s obviously some kind of corrupted Jamf-related files that don’t get fixed by running jamf recon again, because it’s definitely not network-related. Could possibly be something in ~/Library/Caches/ or somewhere else? Didn’t really have the luxury of trying to dig around and delete one thing at a time to figure out where the actual corruption happened. Maybe there’s something in the home directory Jamf has trouble collecting information about?

But if you’re reading this, using Jamf Cloud, and running into a Mac experiencing this error with jamf recon, definitely consider creating a new local account.


Managing macOS Notification Center settings using a Jamf profile

Posted on January 13, 2021 by alanysiu

There’s a feature request called Add support for new Notification Settings payloads for Catalina, originally created 19 August, 2019 and currently marked as partially implemented in Jamf Pro 10.19.0, the details being Starting in Jamf Pro 10.19.0, admins may automatically whitelist notifications in macOS Catalina for the Jamf Management Framework and Self Service application bundle..

So you can use Jamf to make sure notifications from Jamf appear. But what if you want to manage notifications for something else… like Munki?

In theory, you could use ProfileCreator, but that’s been crashing for me on Big Sur. Maybe that will be fixed in future releases. If that works for you, you can create the signed profile using that, and then just upload it directly to Jamf.

Another thing you can use is Joshua D. Miller’s .json schema.

In Jamf, go to Configuration Profiles > New. Fill in the usual stuff you would in General.

Then, go to Application & Custom Settings, and select External Applications.

Click Add.

Under Source, select Custom Schema.

For Preference Domain, put in com.apple.notificationsettings.

For Custom Schema, paste in Joshua D. Miller’s .json.

Click Save, and then click Edit.

For Notification Settings, select Configured. Then click Add Value.

You can then select various options for your application (Alert Type, Use Badges on App Icon, Enable Notifications, etc.). Select what you want, but also be sure to fill in Application Identifier, which you can find in ~/Library/Preferences/com.apple.ncprefs.plist. For example, for Munki, this would be com.googlecode.munki.ManagedSoftwareCenter.

If you find Jamf documentation to be helpful, you can use Customize the App Using Jamf Pro as a reference, too.


If Jamf recon is launching a du process that causes a CPU spike

Posted on September 16, 2020 by alanysiu

If Jamf inventory (jamf recon) causes an extended CPU spike specifically related to the du command, you can fix that by going, in the Jamf settings, to Computer Management > Computer Management – Management Framework > Inventory Collection, and then uncheck the Include home directory sizes checkbox.

That is a system-wide setting, but especially if most or all of your fleet is one-to-one Macs (not shared Macs), it’s a good idea to do. Your jamf recon inventory runs will still report back free disk space, just not broken down by individual home directories.

Special shoutout to tlark and neilmartin83 on the MacAdmins Slack for giving me more context around this.


Script to make Jamf Self Service policy install a Munki optional install

Posted on June 10, 2020 by alanysiu

There is a huge project called jamJAR that seeks to integrate Munki and Jamf in a seamless way.

I’ve written a script that does something a bit less ambitious, but it may still be helpful to your organization if you are “using” Jamf Self-Service, really want to be using Managed Software Center, and still want to keep Self-Service around (either temporarily or semi-permanently).

Basically install_munki_optional.py is a script that you can include in a Jamf Self-Service policy that will attempt to install a Munki optional install item. Just make the item name (not necessarily the same as the display name, mind you) the Parameter 4 in Parameter Values. Oh, and make sure that item actually is an optional install available in Managed Software Center!

The script will attempt to add that item to the SelfServeManifest. If the item already exists in the SelfServeManifest, the script will launch up Managed Software Center and try to focus on the item to basically say “Hey, remember this is already installed?” If the item doesn’t already exist in the SelfServeManifest, the script will add the item to the SelfServeManifest, launch up Managed Software Center, and attempt a managedsoftwareupdate --auto run.

As it’s written, it’s using Munki’s embedded Python 3, but if you have your own Python 3 you’d rather use, just update the shebang path.


Fixing Jamf device signature error

Posted on March 18, 2020 by alanysiu

Even though this Jamf Nation thread is five years old, as of this writing, it’s still got the solution to the Device Signature Error - A valid device signature is required to perform the action error message.

In my experience, the actual working solution is to run sudo jamf enroll -prompt and then enter credentials when prompted. Repeatedly running sudo jamf recon (even after a reboot) or sudo jamf policy doesn’t fix the issue, nor does verifying that the system clock time is correct.

Now why this comes up in the first place on a freshly factory-reset computer that DEP-enrolled in Jamf—who knows but Jamf?