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

bentoms
Release Candidate Programs Tester

Anyone else seeing the same?

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

2 ACCEPTED SOLUTIONS

bentoms
Release Candidate Programs Tester

eleven
New Contributor III

Hello Everyone,

This has now been removed from the Casper Suite 9.3 release notes as a Known Issue.

We found that the 'Updating managed settings...' message that had been present when logging into an MDM Managed machine when the MDM server is unreachable is no longer present as of the release of 10.9.2.

We filed a RADAR with Apple based on this behavior present in 10.9 and 10.9.1 and did receive confirmation that the behavior has been addressed with the release of 10.9.2.

If you find differently please contact your Account Manager, though we have confirmed Apple’s change as of 10.9.2 as well.

Thanks!

Eric

View solution in original post

68 REPLIES 68

marcusransom
New Contributor

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
Release Candidate Programs Tester

@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
Release Candidate Programs Tester

dupe

bentoms
Release Candidate Programs Tester

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

bentoms
Release Candidate Programs Tester

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
Release Candidate Programs Tester

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

RaulSantos
Contributor

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

bentoms
Release Candidate Programs Tester

@RaulSantos do you use MCX on 10.9 too?

marcusransom
New Contributor

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
Release Candidate Programs Tester

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?

jwojda
Valued Contributor II

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
Release Candidate Programs Tester

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

Are you not seeing it currently then?

jwojda
Valued Contributor II

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
Release Candidate Programs Tester

Logged on bug reporter: 15319906

bentoms
Release Candidate Programs Tester

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
Release Candidate Programs Tester

@marcusransom AD bound clients logging in offsite?

marcusransom
New Contributor

@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
Release Candidate Programs Tester

@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
Release Candidate Programs Tester

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
Release Candidate Programs Tester

@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
Valued Contributor II

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

bentoms
Release Candidate Programs Tester

@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
New Contributor III

@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
New Contributor III

@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
Release Candidate Programs Tester

@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
Release Candidate Programs Tester

@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
New Contributor III

@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
Contributor

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
Release Candidate Programs Tester

Thankyou @RaulSantos.

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

He's Drew Duggan. @drew.duggan

bentoms
Release Candidate Programs Tester

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
New Contributor III

@bentoms Good to know & thanks for the update!

bentoms
Release Candidate Programs Tester

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
Contributor

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

haircut
Contributor

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
New Contributor

@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
Release Candidate Programs Tester

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

haircut
Contributor

@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
Release Candidate Programs Tester

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
Contributor

@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.