Tag: dep

Getting up and running with InstallApplications

Erik Gomez did a presentation in 2017 on his InstallApplications project:
Macbrained SF Pinterest April 2017

Now that Apple's deprecating monolithic imaging, a lot of workflows have gone to DEP=>MDM=>something else (like Munki).

After doing some testing with InstallApplications, I think we're probably going to stick with our custom script workflow, but I didn't want our tinkering with it to be in vain, so hopefully some of these notes should help another school, org, or company that wants to get its feet wet with InstallApplications and may actually find it better suited for their situation than for ours.

This isn't a comprehensive guide on how to set up InstallApplications—just some implementation notes that may help people on a few of the things we got hung up on when trying it. For more comprehensive details on InstallApplications, check out the README for it and also this blog post: CUSTOM DEP - PART 9: A PRACTICAL EXAMPLE OF INSTALLAPPLICATIONS, CRYPT, DEPNOTIFY AND MUNKI.

You will need a signing certificate for InstallApplications.

The kind you want, though, can't be obtained by an admin. It has to be created by the Team Agent.

When you add a certificate, make sure you select macOS from the drop-down menu, and then select Developer ID.

Then select Developer ID Installer

Once you go through the steps of setting up the certificate, you should have a certificate on your Mac to import into your Keychain. Import it into your login (not system) keychain.

Then, make a note of this part: Developer ID Installer: YOURDEVELOPERDESCRIPTION (AWHOLEBUNCHOFSTUFF). You'll use that later in the build-info.json file.

When you download the project from GitHub (or git clone it), you'll see a bunch of files and folders.

For the simplest set up, the only things you'll modify are build-info.json and com.erikng.installapplications.plist.

The generatejson.py file you'll use to generate a .json to put on a server somewhere (or build into your package).

When you run munkipkg on the InstallApplications project folder, you'll get a .pkg in the build folder, which you can upload to your MDM.

Special note to other Mosyle users out there—don't be silly like me and forget to check the checkbox after you upload your InstallApplications .pkg file.

Hat tip to jacobfgrant on the Mac Admins Slack for telling me the minimal files to modify.

When DEP nag won’t work but Setup Assistant will to enroll in your MDM

Explanation
Symptoms
Workaround
Automating
Other Considerations

Explanation

The two-days-later update: after doing troubleshooting with our MDM, asking around to other Mac admins, Google searching, and creating an enterprise case with Apple, I finally got back a definitive answer from Apple, which is that this functionality is essentially broken in Sierra (10.12.6). They're saying it should be fixed in High Sierra beta (10.13.4 right now). It makes a lot of sense. Almost all of our fleet is 10.12.6 (as of this writing, anyway), and the few computers that did work were on 10.13.2 or 10.13.3 (so not beta but still working).

So there you go. Either use the workaround below or upgrade to 10.13 if you're having this issue.

Symptoms

We have a bunch of computers that refuse to get a DEP (Device Enrollment Program) nag, even though they get the DEP prompt using Setup Assistant.

I tried blowing out a bunch of files and folders by following the Reset an enrollment section of How to troubleshoot your DEP/MDM Enrollments (on the MicroMDM blog but with generic instructions that can work for any MDM). That worked, but it requires you to go through the Setup Assistant.

I tried creating two fresh (never booted) AutoDMG-created images—one that skips the Setup Assistant and one that doesn't. If I don't skip the Setup Assistant, it obviously works. Here's the weird thing, though: if I do skip the Setup Assistant, then running

sudo profiles -N
doesn't work (skips to the next line in the terminal) and
sudo /usr/libexec/mdmclient dep nag
either gives me this error:
[ERROR] Unable to get activation record: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.ManagedClient.cloudconfigurationd" UserInfo={NSDebugDescription=connection to service named com.apple.ManagedClient.cloudconfigurationd}
or spits back the activation record dictionary (but with no actual nag appearing):
Activation record: {
AllowPairing = 0;
AwaitDeviceConfigured = 0;
ConfigurationURL = "https://mymdmsenrollmentsurl.com/withabunchofotherstuffattheend";
IsMDMUnremovable = 1;
IsMandatory = 1;
IsSupervised = 1;
OrganizationAddress = "Our Address";
OrganizationEmail = "Our email";
OrganizationMagic = someidentifier;
OrganizationName = "Our organization name";
OrganizationPhone = Our organization phone;
SkipSetup = (
Passcode,
Registration,
Location,
Restore,
AppleID,
TOS,
Biometric,
Payment,
Zoom,
Siri,
Diagnostics,
FileVault,
iCloudDiagnostics
);
}
Now, if I actually just delete the /var/db/.AppleSetupDone file at this point and then go through the Setup Assistant, the Mac will DEP-enroll into the MDM.

So there is no network issue here (I've also tested there being no network issue on these devices by temporarily tethering them to my phone to go outside of our school's firewall—same issue).

So I really have no idea what's going on here. My MDM has all of the log information and all of my tests and insists it's not a problem on their end, but it's not the network, and it's not the image (again, a freshly created never-booted image).

Workaround

So, as yet, I don't have a solution for this. Maybe I'm the only one experiencing this. I've asked around on the Mac Admins Slack, contacted my MDM directly, contacted our Apple rep directly, done a ton of Google searches. Seems a bit weird that it's just us with a never-booted image having issues on and off network.

There is good news, though. I don't have to do Setup Assistant for every single computer or do (much worse) a factory reset on each machine to DEP-enroll it (and, yes, we have a whole deployed fleet already that needs to be DEP-enrolled).

I found that if I take the ConfigurationURL from the activation record dictionary and just put that in Safari, it will download and try to install the MDM profile in a DEP way (not just in a non-DEP way).

So the only real missing piece is the actual notification that pops up. Notifications aren't blocked (again, on a never-booted AutoDMG-created image, why would they without some custom script explicitly doing so).

Update (18/02/08): At least one other person, using another MDM, has not found this to work. Safari just loads a blank page and doesn't download and install the enrollment profile. I'm using Mosyle, and this works for Mosyle at least, as of this writing.

Automating

If that works for you (putting the ConfigurationURL in Safari and installing the profile via System Preferences), you can try also automating the workaround by having the .mobileconfig delivered as a payload to /tmp and then running a script like this as a postinstall script:

#!/bin/bash

# Install profile
/usr/bin/profiles -I -F "$3"/tmp/NAMEOFDEPPROFILE.mobileconfig
Had to run the separate profiles command because Munki will not support managing enrollment profiles.

Other Considerations

You don't have to use Safari to go to the ConfigurationURL, but it's handy to do so, because Safari, after downloading the enrollment profile, will just launch up System Preferences and try to install the profile. If you use another browser (e.g., Chrome), it will just download the profile, and you'll have to open it to get it to launch System Preferences to prompt for an install.

Yes, you can also just enroll in the MDM without using DEP, but Apple—with High Sierra's APFS default and the iMac Pro's secure boot—is moving more toward making macOS like iOS, so it's possible that DEP-enrolled devices may be treated differently or have different functionality from non-DEP-enrolled (but still MDM'ed) devices. Probably safest to do a DEP-enroll into the MDM.