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

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

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.

Thankyou @RaulSantos.

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

He's Drew Duggan. @drew.duggan

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

@bentoms Good to know & thanks for the update!

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/

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

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

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

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

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

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.

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

So here's a question, and perhaps I'm not seeing this right, but another article mentioned that this preference simply delays the Prelogcheck to next boot (when presumably it gets booted again, etc).

How does this affect user level config profiles? Does this mean that the profiles will not be applied correctly, or will this preference simply affect the login time?

I've asked JAMF this question, and was referred to Apple, but before jumping through the hoops I thought I'd check if someone here knows definitively, or has already asked Apple the question.

In preliminary testing I was able to get the user level settings working with the defaults script by doing the following:

- Run the defaults script using $ defaults write /Library/Preferences/com.apple.mdmclient BypassPreLoginCheck -bool YES
- Run the same script choosing " -bool NO" instead.

This populates the plist and seems to allow for the user level config profiles to populate, while still taking care of the endless login lag. Tested with OS 10.9.2 and JSS 9.24 with AD Binding.

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

Hi Eric,

FWIW I was still seeing the issue with 9.22 & 10.9.2+. But since moving to 9.3, we're not seeing the issue.

BUT, we also had a issue with our sites internet connection.. so that may have caused the issue.

@eleven, I am seeing this issue present on 10.9.2 images and using JSS 9.3. I sent an e-mail in to my account manager. My thread that was recently opened is at: https://jamfnation.jamfsoftware.com/discussion.html?id=10282

@cstout, I replied in that thread. See my response that is marked as the answer & my linked blog post.

Is some situations, it's Apples new desired behaviour. Also see @rtrouton's method to bypass the prompt linked in this thread.

@bentoms, thank you for that response. It's at least good to know that it is "desired behavior." At this point I suppose I'm going to have to use the logging method you outline to find out why I only see it intermittently. My accounts are logging in internally, hardwired to our LAN, and there are no outstanding issues with our JSS.

Just about to do a deployment of 10.9.2 MacBook Pro's. Started seeing this issue today when testing a final build. Didn't really come up until we were testing it with a server based or Mobile account. (OD - OS X Server). We are still running Casper 9.25. I was originally holding of on 9.3 as there seemed to be a few issues out there. Then with 9.31 I was thinking of waiting till after this deployment. But maybe I'm going to 9.31 sooner than I thought. Is 9.3.x working ok for most of you ?

I went throughout his with Apple.... In our case the issue was because the MDM security cert was not properly pushed to the clients. The login process was looking to run profiles and the cert didn't exist properly, therefore the timeout and the window....

9.3 fixes the issue. We have successfully pulled in 0ver 200 clients with 9.3 and the improved cert mechanism.

Thanks for the reply @Stockton Maybe I am going to 9.31.

Posted 4/29/14 at 5:06 PM by Stockton

I went throughout his with Apple.... In our case the issue was because the MDM security cert was not properly pushed to the clients. The login process was looking to run profiles and the cert didn't exist properly, therefore the timeout and the window....

9.3 fixes the issue. We have successfully pulled in 0ver 200 clients with 9.3 and the improved cert mechanism.

@eleven][/url
@amanda.wulff][/url

We have seen the same issue on Casper 8.73 and 10.9.2 clients.
Is there any update coming to fix this on Casper v8 as it seems to be fixed in Casper 9.3?