Updating Managed Settings.. window popup on Mavericks @ every login

[bentoms]

Anyone else seeing the same?

Using 8.73 & this is a Mac that has been upgraded.

[bentoms · Accepted solution]

Got a reply from the Bug Report, it's expected behaviour with 10.9+ http://macmule.com/2013/10/30/updating-managed-settings-popup-at-login-window/

[marcusransom]

I'm seeing this too
JSS is 9.2
retina MacBook Pro running 1st GM of Mavericks
Our JSS is not currently externally facing but managed settings popup happens off site
Does not occur when logging in without a network connection but happens if there is an active connection
Often takes over a minute to log in

log files show the following
24/10/2013 6:54:34.531 pm mdmclient[272]: [Agent:144195332] Processing pre-login MDM check for: 144195332
24/10/2013 6:55:04.588 pm mdmclient[272]: [Agent:144195332] MDM connection still active. Continuing to wait. (0->0) Last command: (null) (Completed)
24/10/2013 6:55:34.652 pm mdmclient[272]: [Agent:144195332] MDM connection still active. Continuing to wait. (0->0) Last command: (null) (Completed)
24/10/2013 6:56:04.655 pm mdmclient[272]: ** ERROR ** [Agent:144195332] Pre-login MDM check: Maximum wait time elapsed. Last command: (null) (Completed)

[bentoms]

@marcusransom thanks for confirming.. i'm guessing this is correct then? (except the time).

It's actually handy as helps my desktop background dirty hack trick

[bentoms]

dupe

[bentoms]

@marcusransom do you have MCX settings scoped to your 10.9 clients?

[bentoms]

ah.. from: https://discussions.apple.com/message/23468449#23468449

Figured it out. I had to delete all my profiles on the clients and re-download them again.

The clients i've seen this on had been updated via Self Service, looks like i might need to add a QuickAdd install post 10.9 install.. will test more & report.

[bentoms]

Nvm the above, this seems in relation to the MCX refresh @ login.. removing the refresh did it but obviously broke MCX :(

[RaulSantos]

I notice this issue too when i took my laptop off site any way around this?

[bentoms]

@RaulSantos do you use MCX on 10.9 too?

[marcusransom]

A bit more investigation - I have tried a fresh enrolI which hasn't made any difference. It happens on a Mobile AD account but not on a local account. In our case it could be related to the MCX that the AD plugin includes when we bind machines? The MCX put there by other system preferences (com.apple.SubmitDiagInfo.plist, com.apple.systempolicy.control.plist and com.apple.systempolicy.managed.plist) don't seem to trigger the popup window. As far as I know, we aren't using MCX to manage any other preferences (at least not intentionally)

The only difference in the local and AD account is the inclusion of the loginwindow.plist from what I can see - our particular config only includes the following

<?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>AutoLaunchedApplicationDictionary-managed</key> <array> <dict> <key>Path</key> <string>/System/Library/CoreServices/ManagedClient.app/Contents/Resources/MCXMenuExtraTool.app</string> </dict> </array>
</dict>
</plist>

[bentoms]

Thanks @marcusransom.

The loginwindow plist is where I've been looking too.

How is that entry added into the plist in your example above? Is it MCX or a custom profile? Script?

[ImAMacGuy]

I had a bug report with Apple in the early 10.9 betas. Then I reimaged when the next beta came out and it went away and I hadn't seen it till just last night it happened. But I've been using 13a603 since they released it to devs a week or so ago.

I think it's when the machine can't reach the JSS, but i'm just guessing.

[bentoms]

@jwojda that's the same build number as the public release & the same I'm testing.

Are you not seeing it currently then?

[ImAMacGuy]

I didn't see it in the last 4 or 5 beta's and then with GM 13a598. but as of yesterday night on 13a603 (public release and final GM) it's back.

[bentoms]

Logged on bug reporter: 15319906

[bentoms]

Ok.. well maybe not MCX... :(

With NO MCX, NO login scripts & just the MDM Enrollment profile installed i am seeing this with ONLY AD accounts.

Below are excerpts when logging in with an AD account:

25/10/2013 18:18:08.974 mdmclient[4437]: [Agent:735480991] Processing server request: ProfileList  for: <User: 735480991>
25/10/2013 18:23:24.565 mdmclient[1020]: [Agent:735480991] Processing server request: CertificateList  for: <User: 735480991>

Here is what happens when logging in with the local account:

5/10/2013 18:38:07.608 mdmclient[6721]: [Agent:501] Current user is not bound by the MDM configuration: '<Payload: MDM Enrollment (00000000-0000-0000-A000-4A414D460004) from profile: MDM Enrollment (00000000-0000-0000-A000-4A414D460003)>' because it was installed by a different user on the system.

[bentoms]

@marcusransom AD bound clients logging in offsite?

[marcusransom]

@bentoms it seems to only be AD bound users for me. Binding to AD puts some MCX in for these users - did you remove this and it still happens?

[bentoms]

@marcusransom Our MCX are being scoped via OS, I removed the 10.9 group so no MCX are being published.

Can you test with no config profiles on the mac? (Seeing as they leverage MCX it should be no surprise they're linked).

[rtrouton]

I just saw the window flash by briefly when I logged into a Mavericks VM with an AD user. I did not see it when I logged in with a local user.

My Casper doesn't use a loginhook (our Kace KBox's agent is occupying the loginhook slot with its script) so I am not doing any user-level MCX or profiles with Casper.

My JSS is running 8.71. If all goes well, I'll be upgrading to 8.73 next week.

[bentoms]

@rtrouton thanks!

Is the VM enrolled into Casper?

I'm guessing with your KACE logo hook policies are not being checked @ login & neither is the JSS MCX being refreshed.

[tkimpton]

Sigh...don't you just love testing for Apple for free!

[bentoms]

@tkimpton not sure that it's an Apple or Casper thing atm... Reached out to the MacEnterprise list to see if this issue affects those running profile manager or another management solution.

[lionelgruenberg]

@bentoms @tkimpton @marcusransom
I'm seeing this on my machine. AD mobile accounts/10.9 installed from the app store/JSS is running 8.73 and client binary is up to date.
Haven’t seen the pop up at login since I manually removed the jamf framework (sudo jamf removeFramework) and reinstalled profiles.

[lionelgruenberg]

@bentoms @tkimpton @marcusransom
I'm seeing this on my machine. AD mobile accounts/10.9 installed from the app store/JSS is running 8.73 and client binary is up to date.
Haven’t seen the pop up at login since I manually removed the jamf framework (sudo jamf removeFramework) and reinstalled profiles.

[rtrouton]

@bentoms,

My VM is enrolled with Casper. To verify that this was tied to Casper, I set up a VM running 10.9 and didn't include installing the Casper agent. On the machine without the Casper agent, no pop-up window was observed.

[bentoms]

@rtrouton & @lionelgruenberg thanks for confirming. So looks like this maybe an issue limited to Casper.

Which is why no-one else has said they've seen it when using other tools.

Lionel, once you've removed the framework. Which method did you use to reinstall?

[lionelgruenberg]

@bentoms
I used Recon to re-enroll my machine in the JSS. The pop up came back after re-enrolling.

@rtrouton @bentoms
Not sure if this is significant or not...

Logged in on my machine with an AD mobile account with no existing home folder, username testlabs. I see the Managed settings pop up and as you would expect the System created a brand new clean home folder in the Users folder.
Logged out of testlabs account and into the root account.
Changed permissions on Library directory in testlabs home folder:

chmod -R 600 /Users/testlabs/Library

Also changed ownership for Library directory:

chown -R root:wheel /Users/testlabs/Library

Logged out and back in as testlabs. No Managed settings pop up. Once logged in the System did prompt me for admin creds to repair permissions on testlabs Library. Repaired permissions, logged out and back in using testlabs account. The Managed settings pop up is back!

[RaulSantos]

My account manager was able to replicate exactly what we are seeing here. He has filed the defect internally. It is currently filed so the development team here will be taking a closer look to see what might be causing this.

[bentoms]

Thankyou @RaulSantos.

Can you ask your account manager to ping a not to to mine?

He's Drew Duggan. @drew.duggan

[bentoms]

I've had responses from people on the MacEnterprise list, & it appears to be an issue with enrolled Macs + AD user accounts.

Bug report filed: 15339910

[lionelgruenberg]

@bentoms Good to know & thanks for the update!

[bentoms · Accepted solution]

Got a reply from the Bug Report, it's expected behaviour with 10.9+ http://macmule.com/2013/10/30/updating-managed-settings-popup-at-login-window/

[corbinmharris]

We use Centrify for AD/mobile accounts and we're seeing this with Mavericks at login.

[haircut]

Has anyone discovered a way to disable this behavior? I understand what it's doing, but I'm not using an MCX on the Finder so I don't want it slowing down logins. If the user does not have network connectivity at the login window, I've seen it take up to 40 minutes to "update."

[ELW]

@bmwarren I'd like to disable this as well. In my testing, it takes about 1 minute 30 seconds when not connected to the network. It's no 40 minutes, but it's still annoying.

[bentoms]

It's a feature of Mavericks & not a bug... You'll need to holla & Apple to get it changed.

[haircut]

@bentoms - right, I know everything is functioning as designed. I'm just curious if there's a preference I can set to disable the behavior.

In my testing I've seen the excessively long login occur only with mobile accounts (via AD) and only when there is no network connectivity at the login window (no saved wifi networks or Ethernet). I've tried settings the following preference:

com.apple.loginwindow.plist - MCXLaunchAfterUserLogin - false

That doesn't seem to affect anything. Nothing in com.apple.MCX.plist seems to control the behavior. I've even deleted all plists for all users out of /Library/Managed Preferences/ and the window still comes up.

My big concern is user confusion over the message, and the potential extremely long login. Our Windows team just dealt with a corrupted file sever where all Windows user home directories lived, leading to 40-120 minute logins. Having just come out of that problem, now isn't the best time to have a "similar" login time problem on Mac OS X.

[rtrouton]

There is a way to disable this behavior. I've got a post on it here:

http://derflounder.wordpress.com/2013/11/13/bypassing-the-mavericks-managed-preferences-login-check/

If you want to test in your own shop, run the following command with root privileges:

defaults write /Library/Preferences/com.apple.mdmclient BypassPreLoginCheck -bool YES

The command above will disable the managed preferences check that is causing both the login delay and the Updating Managed Settings message to appear.

[haircut]

@rtrouton - amazing! Thanks so much, Rich! I'm not using any managed preferences in my shop that would be affected, so this is a perfect fix.