Tip for testing the new Jamf Pro 10.3 enrollment workflow

Make sure your testing VMs are MDM profile ready for Jamf Pro 10.3 testing by building them with AutoDMG and vfuse.



As you've probably seen from the release notes of Jamf Pro 10.3, the enrollment style has changed for Macs on 10.13.0+ to prompt to install profiles rather than install the QuickAdd (which then installed the profile). This way the MDM profile is user-approved, because the user has to accept the installation themselves prior to the rest of the enrollment happening.

This is a Good Thing(tm).

What's worth noting for those of us that test on VMs, however, is that if you just set up a vanilla VM (with VMware Fusion, Parallels, VirtualBox, or your virtual tool of choice, whatever it is) is that a device without a recognized Apple hardware model ID is going to be treated as a generic "Mobile Device" and not be recognized as a Mac. It'll do a big ol' "wft mate" during enrollment and cause some weirdness. And as a result, the profiles won't install correctly.



If you use VMs to test, my recommendation is to use AutoDMG+vfuse to build it. This is comparable to this post by Ross D about testing DEP with VMs. Really the concept is the same. Fortunately if you're just evaluating user-approved MDM enrollment (not specifically DEP enrollment) for this change in Jamf Pro 10.3 the s/n can be random (though can't include special characters!), but a model ID must be defined.

Using vfuse to build the VM will look something like this:
/path/to/vfuse -i /path/to/osx_custom_autodmg.apfs.dmg -o /path/to/save/location/  -s random --hw-model "iMacPro1,1" -n "macOS 10.13.3 mdm tester"

--hw-model can be whatever, as long as it's a real Apple model ID. A list of currently-shipping model IDs can be found here. I would also strongly recommend using vfuse to define a random serial number rather than letting VMware (for this example at least), because vfuse's -s random will make sure special characters are not used. Special characters can wreak havoc on MDM management as well.

TBH it's probably something we should all do anyway, to ensure consistent testing with VMs. Or use an actual physical machine to test. But VMs are faster. ymmv. Good night and good luck.

ETA: for the Parallels crew, check out this post on Jamf Nation.

Write a comment