@Knight, the Casper account 'was' probably an hidden account like it should be. apple.loginwindow.plist stores such settings. By removing this file (or renaming it), it uses the default values and therefore your Casper management account now shows up at login window.
Just my 2 cents.

Just installed Dev Center 10.10.3 on a VM and it reports opendirectoryd is build 382.20.2. Since I saw 382.20.1 mentioned previously, I'm guessing there has been active work on this. Which is a good thing methinks.

This has happen to me many times and booting to safe mode then just rebooting once more normally worked for me although it doesn't alway boot to safe mode on the 1st reboot. It would sometime still boot 50% of the way trying to get to safe mode so sometime I had to reboot twice at max.

It's good to hear 10.10.3 solves this. At the same time we have three machines with this problem and none of the various workarounds, the rc.server hack, the cache purge, the DSBind timeout, etc., none of them work. All we can do is move their data to a new machine to get them going again.

I've been getting around the rc.server fix by logging in with a local account, then unbinding and re-binding to AD with the "Use UNC path from Active Directory to derive network home location" disabled. Works like a charm in our environment.

Except @emilykausalik, you won't have access to your Windows Server network home with your approach - so it's not really a viable fix in every situation!

@alexforsyth right, which is why I said it worked for our environment. :) We don't issue network home drives for users anymore so it's a fix for us. Ideally it wouldn't be an issue in the first place, but at 300+ comments on this thread…

@emilykausalik

To Clarify, are you implying that rebinding to AD is proactively avoiding the Yosemite boot hang issue, or is it resolving the boot hang issue on previously-affected Macs?

I'm asking because all of my Yosemite Macs are bound to AD, but none of them use the "Use UNC path from Active Directory to derive network home location" option.

If you disable the "Use UNC path from Active Directory to derive network home location" setting, you can still have users home shares mounted at login with a LaunchAgent that runs a script to first check for a valid connection to your domain controllers, then queries AD for the user's home share (SMBHome) and uses that to mount their share for them. If the script can't connect to AD it just exits silently. This gets around the issue of hangs at login.

The Apple AD plug-in really should be handling this problem much more gracefully rather than locking up the OS while it struggles to connect to something it can't. But since Apple really can't give two darns about Macs and AD and can't seem to spare a developer to actually make it work right from day 1, we're left with crafting our own workarounds. At least 10.10.3 will finally fix most of these cases. Wish they'd release it already so we can start testing the final version and deploy it.

Also, @BruceLM - Are these affected Macs using FileVault 2 encryption? Are they also using Active Directory accounts to log in?
If so, you may want to take a look at my post here (from further up this thread) to see if you're getting stuck at the invisible dialog, like we were. We were also seeing the rc.server fix address many, but not all cases, until I found the information here on JN about this invisible dialog popping up due to the user's OriginalHomeDirectory key in their AD account.
Removing the OriginalHomeDirectory key from an AD cached local account has helped quiet down the remainder of these cases, along with the rc.server fix, which helps clear stuck boot cache files.

@dstranathan For every machine I've done this on so far, it fixes the issue (meaning, resolves it for pre-existing machines exhibiting this behavior). I've changed the Directory Binding settings in our JSS environment going forward, too, and so far no new users have reported it as a problem.

This is definitely going to vary from environment to environment. YMMV, etc.

When our AD Server went down due to UPS failure, my Mac Pro wouldn't properly shutdown. Unfortunately, I had to power cycle the machine. When rebooting, the Mac got stuck at the infamous 50% point. Numerous attempts booting and frustration later, I fortunately found this post.

I booted with the help of an external Mac OSX bootable SSD with Micromat's Tech Tools 8 onboard. No hardware issues, so I pressed forward with the Finder equivalent of (from above):

rm -rf /Volumes/Macintosh HD/private/var/db/BootCache
rm -rf /Volumes/Macintosh HD/Library/Caches/com.apple

and rebooted... The Mac Pro came right up.

Thanks to those who blazed the trail before me - I only lost a few hours this morning!

@Sierra.Bob you can also boot into Recovery HD and run those commands.

10.10.3: https://support.apple.com/en-us/HT204490

Addresses an issue that could cause Macs bound to an Active Directory server to become unresponsive at startup

HUZZAH! Awaiting the release of the Combo and the Full Install (from App Store).

Halle-freaking-lujah!

I'm also interested in this bit from the enterprise section:

Fixes an issue installing a configuration profile for 802.1x with EAP-TLS

We've had a lot of strange issues with our 802.1x profile not working correctly, or in some cases, not working at all on Yosemite, despite appearing to be set up correctly. It would be great if this update improves the reliability of those profiles.

54 mintues to download. Yikes!

@emilykausalik check your network cables for kinks. OK, maybe I am a bit too giddy about this release.

@mm2270 same here - anything to improve our 802.1x profile with 10.10 would be excellent.

Also noting this part from the Enterprise section which would be great if the update improved this function as well:

Resolves an issue where folders from a DFS share point might "disappear" when viewed from the Finder on some Macs

whoa dang! 54 minutes!? I'm glad our firewall caches these updates! :)

Not surprised on the 54 minutes to download. This has been a hugely anticipated release. Its the first point release for Yosemite that holds the promise of making 10.10 actually work reliably instead of the turd its been so far. My guess is everyone out there that's been waiting for this hit the download button as soon as it popped up :)

Still no combo or updated full install. Hrmmm

Also remember we're fighting all the normal end-users who want to play with the new Photos App. It's just like every other Apple release: their servers just slow to a crawl, no matter if its OS X or iOS.

Just business as usual.

14d131 in da house, yo.

In my initial testing, the 10.10.3 update (the delta update from the Mac App Store), did not pave over the /etc/rc.server configuration.

I haven't tested the stand-alone Combo update yet. But I assume they all behave the same.

if [ -f "/etc/rc.server" ]; then
rm -rf /etc/rc.server
fi

Yeah, nor did the existence of rc.server cause me any issues in upgrading using the Combo. I excluded 10.10.3 from the rc.server deployment policy and made a new one to remove it for 10.10.3 clients only.