A follow-up on my JNUC 2018 presentation around VMs for testing, covering some details I didn't have time for. Plus new things!
This post is just a quick follow-up to the panel I co-presented this past JNUC called "Fall, spring, and everything in between." During that talk I very quickly went through the process of using tools like installinstallmacos.py, AutoDMG, and vfuse to build VMs for MDM and DEP testing purposes. Time was limited so I skipped a few details that people had questions about afterwards, so I thought I'd break some of that down below.
Presentation slides
Jamf has yet to post videos or blog posts about this presentation, so feel free to check out this presentation from an Austin Apple Admins meetup in August were I covered pretty much the same content. I'll post a follow up with links to video/related sundry once they are available online.KextPolicy
While discussing the use of AutoDMG in this workflow I mentioned that I grabbed a copy of the KextPolicy file with VMware Tools pre-approved. This is super hacky, does require setting up at least one VM through a manual VMware Tools installation and prompt approval process, and basically fusses with a SIP protected file… so this is really only designed to help make a 0 to 60 VM for testing as smooth as possible with kext approvals already in place. You can see more details on this here.vfuse and VMware Fusion 11
In the template I used during the presentation I specified a path to VMware Fusion 10 to build the VM, rather than using VMware Fusion 11. This is because of a bug in vmware-vdiskmanager which causes a crash when attempting to build a VM using version 11. You can keep a copy of 10 and use that, then open the VM you've built with 11, or use the new --use-qemu argument in vfuse to use qemu-img (either from homebrew or whatever else it may reside on your Mac by specifying a path) to build without relying on a copy of 10. Join us in the #vfuse channel on the Macadmins Slack for more guidance on this.PPPC and vmware-tools-daemon
This is something I didn't mention in the talk and no one asked me about, but felt worth mentioning. Because of the new user privacy controls policy settings super happy fun times of macOS 10.14 the vmware-tools-daemon needs approval in Accessibility to allow drag-and-drop between the guest OS (VM) and host OS (physical device hosting the VM). To avoid approving the PPPC prompts every time I build a VM (particularly for DEP with MDM enrollment being automatic) I have a profile like the one below scoped just to VMs in our Jamf instance.The above is sanitized, so you may need to rebuild one for yourself. I recommend using either the tccprofile.py program (run the script without arguments to get a GUI) or Jamf's PPPC-Utility to build a profile for your environment. A smart group to scope this profile to can look something like this:
I also make sure to exclude "MDM not approved" from the profile (for when the profile decides to be unapproved, such as testing re-enrollment or enrolling via agent rather than profile), and that group looks like this:
As they say, "work smarter not harder."
Necessary disclaimer
I doubt Apple intended for this kind of MDM/DEP testing to be possible. It's a happy hack, and very convenient for doing quick testing and setting yourself up for consistent testing with VMs. This could break at any time, which is why I try to make the process as Apple-approved as I can, always specifying hardware model ID and a valid serial number. Skipping some of the details may still work for folks, but I prefer a steady-state where I know the configuration each time I clone a VM.Neither I nor my employer endorse hacking VMs for Mac testing purposes, I just prefer the time savings and consistency. Your mileage may vary.
I'll do my best to answer questions but ultimately using this kind of workflow effectively is on you. Additional assistance might be better found in the Macadmins Slack team in either #virtualization, #vfuse, or #vmware.
Good luck, have fun.
Write a comment
Post a Comment