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.

MacBook Air keyboard backlight disabled with a “do not enter” sign

Acknowledgements: Hat tip to my colleague Jerold for stumbling upon this fix.

We had a user come in with a MacBook Air whose keyboard backlight wouldn't turn on. If you pressed the F5 or F6 key to turn it up or down, there would be on-screen feedback but instead of a indicator bar showing it going up or down, there would be only a "do not enter" sign appearing.

We tried an SMC reset and an NVRAM reset, to no avail.

Finally, Jerold just thought "Why don't we plug it into an external monitor?" For some reason, that fixed it (even after unplugging it from the external monitor).

So if you run into this issue, that may not be a sure fix, but it's certainly something to try!

macOS client can’t download Apple updates

This is a really odd situation. I have one client machine that cannot download a particular Apple update. This is the error message that comes up:

softwareupdate -d -a
Software Update Tool

Finding available software

Error downloading Security Update 2017-002: The Internet connection appears to be offline.
Done.

Error downloading updates.
Here are two things that make this situation weird:
  1. The machine can contact any random website, including Apple's.
  2. The machine eventually could even download and install the Safari update from the Apple servers.
I haven't found a real solution to this yet, and it affects only one client, but I did find a workaround, which was to just use Reposado with it.

Importing from Microsoft Remote Desktop 8 to Microsoft Remote Desktop 10 in macOS

Microsoft recently released a new version of Microsoft Remote Desktop for macOS, but the settings from the old version don't carry over automatically.

To import the old list of Windows machines to remote into, go to Connections and select Import from Microsoft Remote Desktop 8.

What to do if Safari refuses to launch

So a user came in with Safari not able to launch.

At first I thought perhaps the user account was corrupted, but I logged in as another user, and the issue persisted. Not launching and crashing. Just not launching at all. The dock icon didn't even bounce.

Running

open /Applications/Safari.app
resulted in an error of
LSOpenURLsWithRole() failed with error -10699 for the file /Applications/Safari.app

Because of System Integrity Protection, you can't actually just copy the /Applications/Safari.app from another machine.

But it turns out reinstalling Safari works (the link in there is for El Capitan—I reinstalled it for Sierra).

Using Munki’s force_install_after_date key to force items to install

Keeping machines up to date can be a challenge. Munki tries to make this as seamless as possible, especially if you mark certain items as unattended installs (Munki will try to install those items in the background and not even bother the user).

But some updates require a logout or a reboot, and users generally don't like to log out or reboot often, particularly if they have laptops (as opposed to desktops). So pending updates can sit there for days, weeks, months, even over a year, unless you force the user to install the items.

I wouldn't recommend using the force_install_after_date option very often, but it can be very handy, particularly if there are critical updates that need to get to users.

And even though Munki itself will attempt to notify users of forced updates, you may want to accompany those built-in warnings with warnings of your own (via email, in person, etc.).

At the final countdown, the screenshots below are examples of what your users will see. Every time there's an OK button in the Managed Software Center, your user has the option to close Managed Software Center for a short time, but then MSC will just pop back up again soon. At the very last dialogue, the user will have no choice but to install the pending install item.

Once again, use sparingly, but you may need to use it, so it's good to know roughly what your users will see...

Troubleshooting Munki failing to install Apple updates

Problem

If you see Apple updates (that require a reboot) not installing properly via Munki, it may be because the downloaded update is stale somehow. Not really 100% sure on how this works, since I've seen this fail even on a "stale" update downloaded the same day (not weeks ago).

Symptoms

When you log out to update, you'll see Munki's progress bar over the login screen window, and it will look for a split second as if it's trying to install the pending Apple update but then move on almost immediately to requiring a reboot.

Then, if you check the logs at /Library/Managed Installs/Logs/Install.log, you'll see something like

Apple Software Update install of Security Update 2017-001-10.12.6: FAILED for unknown reason

Workarounds

You could create a script (run from its own Launch Daemon or as part of a Munki run) to clear old updates from the /Library/Updates folder periodically (though, again, I saw this happen even with a recently downloaded update).

I've found that if you run

softwareupdate -d -a
the newly downloaded update will install just fine via Managed Software Center.

This is tricky, because it's not technically a Munki issue (Munki just uses Apple's built-in softwareupdate to install Apple software updates), but clearly there's some flaw in invoking the software update mechanism.

Factory-resetting a disabled iOS device

A user came in with a disabled iPhone (too many password attempts) and couldn't factory reset it. We tried to get it into DFU mode, but we couldn't easily.

Turns out, if you just plug it into a computer that has Apple Configurator 2 installed, you can use Configurator to restore the device (without having to hold any buttons on the device—particularly helpful if some of the buttons are broken/finicky).

askForPassword and askForPasswordDelay in macOS 10.13 (High Sierra)

In macOS 10.12 (Sierra) and earlier, you could go to System Preferences > Security & Privacy > General > Require password ________ after sleep or screen saver begins, and that would populate the askForPassword and askForPasswordDelay keys in ~/Library/Preferences/com.apple.screensaver.plist for the user.

In macOS 10.13 (High Sierra), setting that preference in the GUI will not make it appear in the relevant .plist file. However, setting the preference with

defaults write com.apple.screensaver askForPassword -bool TRUE
defaults write com.apple.screensaver askForPasswordDelay -int somenumber
will make the change reflect in the GUI, and setting a .mobileconfig profile will also override what's set in the GUI.

Oddly enough, Apple's own documentation makes it sound as if those two keys exist only in 10.13 and later:

Deploying Munki with Mosyle MDM

Acknowledgements: This is a slightly modified workflow based on one proposed by Taz on MacAdmins Slack. Thanks, Taz!

You can use Mosyle to install Munki.


Switch to the macOS platform (if you're not already in there).


Then, click on Management.


Scroll down to and then click on Custom Commands.


Click Add new profile.


Name it whatever you want (e.g., Install Munki), and then put in a modified version of this code:

#!/bin/bash

# Name of .pkg
munkitools='munkitools-3.1.0.3430.pkg'

# Desired hash output
desired_hash='MD5 (munkitools-3.1.0.3430.pkg) = 0afbe2fbe7cb81ff531834cba82f3a75'

# Go to the /tmp directory
/usr/bin/cd /tmp

# Download the latest Munki tools .pkg
/usr/bin/curl -L -O https://github.com/munki/munki/releases/download/v3.1.0/"$munkitools"

# Make sure the hosting server hasn't been compromised and/or the download isn't corrupted
md5_test=$(/sbin/md5 $munkitools)

if [[ "$md5_test" == "$desired_hash" ]]; then

# Install the Munki tools .pkg
/usr/sbin/installer -allowUntrusted -pkg /tmp/munkitools-3.1.0.3430.pkg -target /

# Add in basic auth info
/usr/bin/defaults write "$3"/private/var/root/Library/Preferences/ManagedInstalls AdditionalHttpHeaders -array "Authorization: Basic BASICAUTHCODE"

fi

Assign this profile to whatever devices or groups you want, and then click Save.

Any other Munki preferences (e.g., SoftwareRepoURL) you'll want to deploy in a .mobileconfig profile. More details in Importing custom .mobileconfig profiles into Mosyle MDM.

P.S. I haven't done extensive testing on this, but you may be able to deploy Munki as a .pkg and not as a custom command that downloads the .pkg. You'll have to host it somewhere yourself (and Mosyle does not like the redirect URLs, so you'll legit have to host it), but you may want to try Management > Management Profiles > Install App > Add new profile. Then, under Installation source, pick Enterprise app, and then put in the URL of the hosted Munki installer .pkg.

To change the icon, just get a .png of whatever icon you want. Here's an example of how to generate that:

sips -s format png /Applications/Managed\ Software\ Center.app/Contents/Resources/Managed\ Software\ Center.icns --out MSC.png

Only caveat is that that won't work for scripting basic authentication.