Have you tried your luck with 10.10.5? The mDNSResponder service was put back in place with this update after having been replaced with the new DiscoveryD service. This seemed to resolve our login delay issues for our AD-bound Macs.

@brandonpeek, that's the direction I was starting to head ... I'll see what we happens.

It made a big difference for us over here. We were seeing Macs take anywhere from a few minutes to never completing the login. We tried a number of things, but in the end it was 10.10.5 and the reinstatement of the mDNSResponder service that did the trick. It even resolved a SQL connectivity issue for a group of folks that were just absolutely convinced that we pushed some change that broke them.

Some nice details on the whole discoveryD debacle here: MacRumors on mDSNResponder and discoveryD

FYI, 10.10.4 introduced the change from discoveryd to mDNSResponder, not 10.10.5, http://www.macrumors.com/2015/06/30/apple-releases-os-x-10-10-4/ so I don't think your issues are related to the OS version specifically if you have been testing on 10.10.4.

@aporlebeke, for clarification, are you saying that first login is the slowest once on each Mac, or did you mean its slow at first login after every reboot? If you meant the former, that can partially be explained by the fact that you're allowing the Apple AD plug-in create the accounts and home directories on first login. A lot goes on at that initial AD login attempt. The Mac first checks to see if a local cached account for the AD user exists on the Mac. Once it sees that isn't there, it needs to get information from AD about the user account. Then it creates the local directory services record (what you see when you run dscl . list /Users for example), then it creates the home directory, by copying contents from /System/Library/User Template/ into place, sets the account as the owner of that home directory, and finally, logs you in. While that should all be happening fairly quickly, my experience has shown due to issues with Apple's AD plug-in, or just issues with AD in general, this process can take a while. But, it should be a little faster after that first login.
Is there any possibility you'd be able to pre-create the user accounts prior to first login with a script that uses the createmobileaccount binary? That's kind of how we have things set up, within a custom application post imaging, so when the user logs in, it doesn't take so long.
If you're saying its always slow even when the account is already cached, then something else is going on.

So, that probably doesn't explain the whole story. I wouldn't be surprised if your Sophos set up is creating some issues here as you mentioned. AV software tends to be set up in a way that it will scan all reads and writes, not just writes. If you think about how much data is being read by the OS during login, its no wonder AV software slows the whole thing down so terribly. Our McAfee software has been known to do the same thing. We went through a hellish process about a year ago of trying to track down why our Macs were literally almost hanging at login, and it boiled down to McAfee scanning being misconfigured, or configured to scan too much. Do you have any exclusions set up for Sophos, or is it just looking at everything going on on the drive?

@mm2270, thanks for all the details on the AD plugin steps.

I've seen other threads refering to the createmobileaccount binary, but don't know much about it or how to go about utilizing it. I'll look into it.

How do you have this configured in your environment with the custom app & how does this shorten the process for when a user logs in for the first time? Does it still apply the local user template for new users?

Hi All,

First time responding on the nation :). I was running into the same issue. But I discovered this thread that helped me out.

https://jamfnation.jamfsoftware.com/discussion.html?id=7799#responseChild41415

Double check that your clients are directly talking to the domain controller rather than the "All Domains" Don't know if this will help, but it so far this has corrected our issue that just started plaguing our macs. In my environment my login times reported were from 30 to 2mins in some cases. After correcting the issue, we have gained back our original login speeds. I hope this helps.

@aporlebeke Total shot in the dark... but read up on the @rtrouton post Bypassing the Mavericks managed preferences login check and deploy this workaround to a test machine for kicks?

On the "Unable to login at this time" issue, I've often had this related to having the SMBHome enabled in the plugin. Specifically these two options:

Mount home as sharepoint    = Enabled
Use Windows UNC path for home  = Enabled

Try switch these off to see if that helps.

If it does, you can get the home mounted with our script here: https://github.com/amsysuk/psu/blob/master/mountHome.sh

and here's a video of my PSU talk on the topic of stabilising AD integration: https://www.youtube.com/watch?v=X8e2gyS8n_Q&index=21&list=PLRUboZUQxbyVydhdMcxGGfEaZc2sFdQk8

Hope this helps.

@davidacland, initially in trying to solve Issue #2, I created an Applescript application to mount the user's network folder thanks to @bentoms so we could disable the mount home as sharepoint setting - https://macmule.com/2011/09/08/how-to-map-drives-printers-based-on-ad-group-membership-on-osx/.

However, after disabling the Windows UNC path setting when a user logs in it doesn't successfully create a local mobile account for the user. It presents a dialog box that the library needs to be repaired and if you look in the /Users folder, the logged in user doesn't have a folder.

It sounds like @mm2270 may have an application in his/her environment that runs at login that would still allow us to use local mobile accounts for our users so we could disable the UNC path setting.

@mm2270, I see your comments on this thread that there was an issue in 10.10.3 that broke the createmobileaccount binary. Given your suggestion here, can I assume that this now been fixed?

@aporlebeke Hey, sorry for the delay. Yes, 10.10.4 and up fixed the bug introduced in 10.10.3 that broke the createmobileaccount functionality, so there should be no issue using it going forward.

To answer your question from yesterday, our custom application is not something that runs at each login. Its something that was kind of designed to replace the Apple setup assistant process.
Essentially, our Macs are imaged with DeployStudio and sent to customers to set up. Because AD joining and using an AD account are necessary in our environment and I don't foresee it going anywhere soon, a custom process needed to be developed to help with this. Since the Mac could be shipping to someone in a home office far away from a physical wired connection to the office, we needed a way that when a user received the Mac, they could effectively log in with their AD account. But since we don't know users passwords of course, simply pre-creating their account ahead of time is impossible, and they can't log in while off the network unless the account is created with a cached password.
So what happens is, the Mac is set up to auto log in to a temporary account set up during imaging. This account is pretty locked down, so only the custom app launches at login. It checks to see if it can communicate with AD, and if not, prompts the user to either connect to a network, or launch our VPN software and connect that way. It won't continue until it can "see" the network. It then lets them fill in a few details about location and language preference, asks them for the user ID and their password, and verifies these against AD. Once all good, it uses the createmobileaccount binary behind the scenes to pre-create their AD account. Finally, it makes sure the Mac is enrolled in Casper and such, and finally, logs out. The user can now login at the regular OS X login screen to their Mac, even if completely off the network, since their AD account is now a cached mobile account. Finally, it runs a cleanup script that removes the temp account from the machine, enables FileVault for next user (deferred enablement) and initiates a restart so they can turn on FileVault.

Because the app is so custom and because its not something I created, the above is the most I can really talk about it. Its not something I'd be able to give you. Even if I could, its heavily customized for our environment, so its not something you'd be able to just drop into your setup. The app was designed by my colleague and was written in Applesctipt ObjC.

However, after disabling the Windows UNC path setting when a user logs in it doesn't successfully create a local mobile account for the user. It presents a dialog box that the library needs to be repaired and if you look in the /Users folder, the logged in user doesn't have a folder.

@aporlebeke Sounds like there's an item with bad permissions being deployed to the user library, perhaps via FEU or FUT.

Can you verify that?

@bentoms, it's funny because I just tried disabling the Windows UNC path setting and for some reason now each AD account I try logging in with for the first time does not get the "user cannot be logged in at this time" error AND successfully creates and logs into the local mobile account ... This was not happening originally, so I'm not sure what's different.

I'm doing some more testing to confirm.

After additional testing, after only disabling the "Use UNC Path" setting on machines where before attempting to login as a new user produced a "user cannot login at this time error," the user was able to login without producing the error AND successfully created a local mobile account.

I'm really not sure at this point why we were getting weird issues during our testing where disabling the UNC setting somehow prevented a local mobile account from being created when a user logged in for the first time.

Unfortunately, we are still getting painfully slow login times on these machines. Not installing Sophos shaves off 20-30 seconds of login time, but still over a minute.

A a recent thread mentioned getting faster login times for AD users with the "Perform login hook actions in the background" enabled, but we already had it enabled to begin with.

Any other ideas for improving AD user login times? Does anyone have login time / performance issues in their environment on Macs with HDDs?

@aporlebeke maybe the post linked in: this?

@aporlebeke I think the other thread mentioning "perform login hooks in the background" was a specific issue with their setup as they had a few things running (not AD related) at login. Although its usually worth enabling anyway.

Thanks, @davidacland.

@bentoms, I saw that thread but was confused as to what those two settings actually do, especially the bypasslogincheck

@aporlebeke Sorry, I meant: https://macmule.com/2011/03/11/slow-login-for-ad-mobile-accounts-when-off-the-office-lan/