Lab Workstations - Slow Logins

[hughesma]

The Situation

We have multiple Mac labs on our campus, most running OS X 10.9 with a few running OS X 10.10. Most are either 2012 i5 iMacs and a few are 2014 i5 iMacs. Nearly all are running with 4GB RAM and non SSD hard drives (I believe 5400rpm, possibly some 7200rpm). iMacs are also used in a number of our classrooms as podium machines, logged in by professors and students alike. All machines are protected by DeepFreeze.

The Problem

Log in times for network users are extremely slow. Boot to login screen is about 60 seconds, not terrible considering the age of the machines that we are dealing with. When a Network User logs in (we are using Active Directory but this problem existed in our OpenLDAP era as well), it will take an a minimum of 90 seconds (and often more) until the desktop appears and a user can actually launch programs. (The local Admin account is much quicker of course). It seems as though this problem has gotten worse as we've gone upward in OS (from 10.6 to 10.8, then 10.9 and 10.10). That could all be in the head though.

For a lot of our users and myself, this seems like a long time. I’d like to cut that down if I can. Obviously, with DeepFreeze active, the network users are being recreated each time and there’s not a really good way to get around that. But can that process be sped up?

So what I’m looking for is - how can I speed this up? What should I be looking for to help with that? Logs, applications, voodoo rituals? Are there tips that others can suggest?

I've already gone through the System Log and there's nothing jumping out at me that screams 'problem'. There are no extra startup items - just Sophos Anti-Virus, AirServer (on podium machines), Bradford Campus Manager agent, and Deep Freeze. A total of 7 apps and web links appear on the desktop but otherwise it's clean.

Any help would be much appreciated. Thanks!

The Process

This is the process I use in creating the image for our lab workstations. We use Kace KBOX for our image capture and deployment.

1) Install a clean OS

2) Create a local Admin account

3) Create a Default User account (Standard)

4) Log in with the Default User

5) Install all applications as the Default User

6) Set all System Configuration (power settings, firewall, etc)

7) Launch all applications as the Default User and configure as necessary

8) Bind workstation to Active Directory (note, we previously used OpenLDAP and had same issues)

9) Log in as Admin account

10) Run Disk Utility (Verify/Repair Permissions), DiskWarrior, and make certain all updates are installed.

11) Copy the Default User profile into the Default Template using the following:

sudo -s

rm -rf /Users/DefaultUser/Library/Keychains/*

rm -R /System/Library/User\ Template/English.lproj

mv /Users/DefaultUser /System/Library/User\ Template/English.lproj


12) Install and configure DeepFreeze

13) Freeze workstation

14) Reboot and log in as any user

 

[MacsRgr8]

Hmm.... this won't help you much, but still... problem is that with time local users experience slow-downs of the same type too, so I'm not sure this is a network-user-related issue.

I have seen this time and time again on old(er) and recent Macs whenever a HDD is used.
Problem has gone worse from 10.8 to 10.11

I have tried deleting caches, plists, etc...

 

[sevoneone]

Have you double checked your DNS settings? If you are using AD, your macs should be looking to the AD server for DNS.

 

[DJLC]

Do double check DNS — forward and reverse lookup should both work.

But in general I'm not sure what else can be done. We note the same issues in an Active Directory environment with shiny new MacBook Airs (and slightly less shiny 2012 MacBook Airs) without DeepFreeze. Although we're usually not waiting 90 seconds... probably more like 30-40 seconds.

 

[hughesma]

DNS settings are good. Just confirmed it and everything went through fine. So unfortunately the problem doesn't seem to lie there :-/

 

[danwestbrook]

Out of interest does your domain end with a .local? we have had a similar issues and used a terminal command to lower the login time.

sudo defaults write /System/Library/SystemConfiguration/IPMonitor.bundle/Contents/Info mdns_timeout -int 1
and
sudo /usr/bin/defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int 2

Might be worth trying those commands on one of the Mac's to see if it works, if it errors out, try changing the numbers up by 1 each time untill you get a login time. The higher you set it the longer it will take to login.

 

[hughesma]

Domain does end in .local (at least according to the host name command).

I tried out those commands on a workstation and it sadly did not make any real impact. Which is sad because it sounded like a really good idea.

I'm starting to think the problem is not so much authentication but rather profile creation. Because we use DeepFreeze, every user is created brand new from scratch using the English.lproj template. Meanwhile, the local admin user gets in quick and easy (granted, that's an already existing account but still). Might experiment with that to see if there are any ways to speed that process up.

 

[hughesma]

Progress has been made.

I decided to take a look at the Default Template folder located in /System/Library/User\ Template/English.lproj. Get Info (and Disk Inventory X) showed that directory as being only 23MB in size which is reasonable. That means each user that was logging in (and thus being created) was recreating 23MB of data.

Something kind of bothered me though and upon closer examination, I realized that the permission on User Template directory were set so that my Admin user could not read any of the sub-directories. Once I changed that, the Default Template folder boomed up to 4.3GB. Um ... wow. Not exactly what I was looking for.

I went in and cleared out the contents of the following directories from the Default Template profile:

/Library/Caches
/.Trashes/
/Library/Containers
/Library/Developers

This dropped the Default Template size down to around 97MB (Caches alone was about 3GB). Multiple tests on machines showed this cut the login time down by about 30 seconds or so. Not perfect but getting a heck of a lot closer to acceptable.