Skip to main content
Solved

El Capitan - Slow login

  • November 20, 2015
  • 16 replies
  • 56 views
S
Forum|alt.badge.img+3

We're seeing a behavior with upgrades and new installs, where login of Network users is taking 6 minutes to complete to Desktop. I've tried stripping out all our Login Window settings, disabling all our management and configuration profiles, and nothing seems to speed it up.

The common item in the console for each machine is a ~6 minutes gap between trying to start the SetupAssistantSpringBoard, and that same item failing with error code 171. I can grab a console dump in a little bit, I need access to one of the machines.

Hoping this is something super obvious that I'm missing, as I haven't seen it anywhere else. We are running a Windows domain, and it doesn't matter if the account was logged in prior to upgrade, or on a fresh install, so I know it must be something we're applying in our environment. We've also tried it with/without Sophos SafeGuard and SEP, trying to rule out our managed software.

Best answer by ooshnoo

I just had this issue as well the past few days and solved it an hour ago by enabling the "Local-only users may log in" setting in our Config profile under Login Window -> Access

We didn't have this problem with Yosemite or Mavericks.

    16 replies

    O
    Forum|alt.badge.img+14
    • ooshnoo
    • Honored Contributor
    • Answer
    • November 20, 2015

    I just had this issue as well the past few days and solved it an hour ago by enabling the "Local-only users may log in" setting in our Config profile under Login Window -> Access

    We didn't have this problem with Yosemite or Mavericks.

    S
    Forum|alt.badge.img+3
    • stevecurl
    • Author
    • New Contributor
    • November 20, 2015

    I'll give it a shot, this is frustrating for sure.

    N
    Forum|alt.badge.img+6
    • navek
    • Contributor
    • November 20, 2015

    So I have been struggling with this for the past week as well. The problem I see is that the iCloud login window will not load for all users accounts on the machine. I have tried removing the .Applesetupdone file to reset the setup assistant but that just created a machine that would not boot at all. I have tried a number of ways around this as well and the only way I could get around it right now is to wait the 6 mins. Once it is at desktop we are running the standalone 10.11.1 upgrade software. On the next login the iCloud window show up and we skip or fill it in and the next logins are back to original boot time. The machine appears to be fine after. Other users accounts on the machine get the iCloud window on their first logins.

    I can reproduce this problem on multiple machines that we image with Yosemite and then do the Apple Upgrade or the upgrade file created with Casper Admin and run from self service.

    Good Luck. I hope that someone smarter then me can come up with a better fix then mine so far.

    The local only fix will not work for us in our AD enterprise setup.

    S
    Forum|alt.badge.img+3
    • stevecurl
    • Author
    • New Contributor
    • November 20, 2015

    @navek Sounds like you and I have tried the same things, though I didn't think to try running the installer again after the upgrade. That's the exact behavior I'm seeing, I'll give it a shot.

    O
    Forum|alt.badge.img+14
    • ooshnoo
    • Honored Contributor
    • November 20, 2015

    @navek

    Enabling the Local Only "fix" will not prevent AD users from logging in.

    S
    Forum|alt.badge.img+3
    • stevecurl
    • Author
    • New Contributor
    • November 20, 2015

    @ooshnoo OMG, you are my hero. This doesn't appear to have any impact on our machines, except that my login time is down to normal.

    @navek We are also AD enterprise setup, this doesn't appear to have any impact on our ability to login with new AD accounts.

    N
    Forum|alt.badge.img+6
    • navek
    • Contributor
    • November 20, 2015

    @ooshnoo Cool! I will check it out thank you.

    jhbush
    Forum|alt.badge.img+27
    • jhbush
    • Esteemed Contributor
    • November 21, 2015

    I have this issue as well. I dumped my login window profile and all was well. It's amazing how much this impacts. It broke our Cisco VPN, WiFi, and of course the slow login. It also seems to be a per user issue in regards to the iCloud window. Thanks for the tip on "Enabling the Local Only."

    davidacland
    Forum|alt.badge.img+18
    • davidacland
    • Valued Contributor
    • November 21, 2015

    I'm not sure without testing, but does enabling local only accounts mean new AD users wouldn't be able to login? If you're using cached accounts that might be why its still working.

    In case it helps, we have a config profile that will supress the iCloud setup window for all users here: https://github.com/amsysuk/public_config_profiles/blob/master/First_Boot_Profiles/SupressiCloud.mobileconfig

    A
    Forum|alt.badge.img+14
    • Aziz
    • Contributor
    • November 21, 2015

    @davidacland We have it enabled and AD users are still able to login.

    N
    Forum|alt.badge.img+1
    • nhammer1
    • New Contributor
    • November 23, 2015

    We have noticed slow login issues since the upgrade. We believe it may be cause by a login window profile. Specifically it seems to be blocking the iCloud login window. I have noticed if you exclude the login window answer the iCloud login questions it speeds of the login for that user.

    S
    Forum|alt.badge.img+3
    • stevecurl
    • Author
    • New Contributor
    • November 23, 2015

    The change to _mbsetupuser is the cause for this slowdown during upgrades or first runs without Local-Only users enabled. They changed the way the Setup Assistant launches in El Capitan, replacing Root, with this new _mbsetupuser account.

    https://discussions.apple.com/thread/7297299?start=0&tstart=0

    A
    Forum|alt.badge.img+18
    • andyinindy
    • Valued Contributor
    • November 23, 2015

    We were also impacted by this issue. Our fix was to manually add the _mbsetupuser to the loginwindow ACL. We restrict logins to assigned owner and certain LDAP groups, so this caused extreme delays as the setup assistant tried to use _mbsetupuser to display it's useless nonsense.

    Here is the code we used:

    dseditgroup -o edit -n . -a "_mbsetupuser" -t user -n . com.apple.access_loginwindow &> /dev/null
    N
    Forum|alt.badge.img+6
    • navek
    • Contributor
    • November 23, 2015

    So the configure profile has helped speed up the boot time. I now get the iCloud login window for all the accounts on first boot up quickly and then skipped or filled in the boot up proceeds as it should after.

    Has anyone else found that they have a new folder in the Users folder for the _mbsetupuser after the upgrade to El Capitan on a machine with File Vault2 active before the upgrade? I also have the "Perform authenticated restart on computers with FileVault 2 enabled" option in the upgrade self service job.

    N
    Forum|alt.badge.img+5
    • nicklaird
    • New Contributor
    • March 7, 2016

    Does anyone know if JAMF will be making any changes in response to Apple using this _mbsetupuser account instead of root? It seems like using the local-only login fix should not be a permanent thing we have to do in our environments to make sure el Cap machines don't turn into useless bricks with extremely slow login time and an inability to connect to WPA2 Enterprise networks (that's what we saw happen here - open networks were fine but our secure network was un-joinable. Apple looked into it and could not figure out what was causing that, so thank you all for this thread).

    C
    Forum|alt.badge.img+19
    • charles_hitch
    • Contributor
    • October 19, 2016

    For us this was solved by updating McAfee. With El Cap we had been using McAfee Endpoint Protection for Mac (aka EPM) which does not support El Capitan. Our solution was to upgrade to McAfee Endpoint Security (aka ENS, but don't ask me where they got the N from). It took two days to figure this out with Apple on-site. EPM had seemingly been working fine on El Capitan. This upgrade also required an upgrade to ePO (aka the agent). Once we removed EPM, uninstalled the older ePO agent, installed agent 5.0.2, and ENS 10.1.0 our login times for El Capitan systems went from 3-5 minutes down to 30 seconds (and yes FileVault is enabled). We also adjusted the login window directory services timeout, but didn't find that significantly impacted login times.

    I'll also state that for Sierra compatibility you have to be running ePO 5.0.4 and ENS 10.2.1.

    Lastly I'll give everyone a heads up that there is a bug in the preinstall script of ENS which can get in an endless loop during upgrades of ENS. The preinstall script uses launchctl to quit that some of the ENS processes. However sometimes all the processes don't actually quit. Once that launchctl command is run there is a while loop with no counter that checks to see if the process is still running. If it is, the preinstall script sleeps for 5 seconds. This can of course lead to that package install never finishing. If you are using Casper to deploy that update, the jamf binary just waits for that package to finish, which it never does, and you as the administrator never know if the system just hasn't received the patch yet or if its in this endless loop. We have an open case with McAfee about this and they state it will be fixed in the next major release of ENS, but no timeframe has been provided.

    @donmontalvo this is what we were chatting about last night.

    Terms & ConditionsCookie settingsAccessibility statement