Bypassing the Mavericks managed preferences login check
With the release of 10.9, a number of Mac admins began seeing an Updating Managed Settings message appear at the login window.
When contacted, Apple said that this was new behavior and it was added for the following reasons:
Starting with 10.9, MCX will attempt to contact an AD/OD/MDM server during login, before the Finder is launched to ensure that all managed settings are applied before any user session applications run.
The dialog you are seeing comes up if this process takes more than a couple seconds.
The dialog does not add any time to the login process.
It’s just telling you why the login is taking extra time.
If your AD/OD/MDM server is responding slowly, then this is “normal” as the client just has to wait for the operations to complete.
In my own shop, this was going to be an issue. Our Casper server does not communicate with its clients over the Internet, so my users would see this message whenever they logged in while off of the office network. After working with Apple support, I now have a solution that works while a better one is hopefully being developed. See below the jump for the details.
It is possible to disable the MDM check that is causing both the login delay and the Updating Managed Settings message to appear. You can disable the check by running the following command with root privileges:
defaults write /Library/Preferences/com.apple.mdmclient BypassPreLoginCheck -bool YES
Here’s what /Library/Preferences/com.apple.mdmclient.plist looked like on my Mac once the command had been run:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>BypassPreLoginCheck</key> <true/> </dict> </plist>
Effects of disabling the login check
Disabling the login check causes any pending profiles that contain user-level managed preferences not to be applied until the following login. The point of the delay was to make sure that the MDM server had a chance to apply settings; bypassing the login check-in will affect that.
For my own shop, the solution above is an acceptable trade-off but different shops have different needs. Evaluate your own needs carefully.
Update – 11-13-2013: I’ve now built a script and payload-free package to disable the login check. Both are available here on my GitHub repo:
Leave a comment
Recent Comments
 | Ben LeRoy on Losing a giant |
 | Peter-Erik on Downloading installer packages… |
 | nathanhaggard on Losing a giant |
 | andras0602 on Disabling login window clock d… |
 | Jeff on Losing a giant |
Der Flounder 
Did they give you any hints as to how to get rid of the dialog, but still enforce the prelogincheck?
As always, I see a new issue, and it is already documented on derflounder.
Thanks Rich,
Adam
Thank you for this Rich. Unfortunately, that file doesn’t exist on any the machines in my shop. Not sure why.
Same issue here Rich. Perhaps leveraging as a loginhook and some if/then logic before the defaults command to check for known networks that we know our MDM server to be in would allow a more dynamic on/off activation of the function? This assumes this script would trigger prior to the MDM check happening.
/Library/Preferences/com.apple.mdmclient.plist does not exist before running the defaults command. Running the defaults command will create it.
the terminal command needs to end with “yes” not “Y”. It gives an error with “Y”
Nevermind, I see I hadn’t scrolled. The “ES” was cut off of “YES”
You can also accomplish this via a profile.
Custom settings in Profile Manager
Domain: com.apple.mdmclient
Key: BypassPreLoginCheck boolean (checked)
Worked in my testings! Thanks Rich
Awesome, thanks for posting this. One question, will user level managed preferences and configuration profiles apply when the machine logs in the next time on the office network?
Do you ever see this affecting logouts? Im seeing an applying managed preferences message on logout and its taking about 10min to log out.
The “Defaults write” command does not seem to have the same effect in Yosemite. Back to the Configuration Profile Tool nags.