If you just want the answer, scroll down for the TLDR. Otherwise read on for a giggle at how a missing character caused so much grief.

We recently had to onboard several hundred new staff in a short period due to an acquisition. Job number one, create their user accounts. Simple…

The server team came to the rescue with an old script they had kicking around. It simply reads a CSV with some key data (the usual stuff, first and last name, job title, etc) and then creates the AD accounts according to some logic, along with the home folders and permissions. Sounds like a win!

The problem came that the users were logging in on their first day but they had no home drive. Cue the troubleshooting process. Folder permissions, check. AD attributes, check. What was going on? Someone tried manually mapping the drive for a user and it worked perfectly. So why wasn’t it mapping automatically when the user logged in?

For clarity, users home drives are configured on their AD account, with the home folder attribute set to the appropriate UNC path and the home drive attribute set to the drive letter all of our users have for their personal drive. The drive isn’t mapped with Group Policy Preferences, just the native AD functionality.

Then the weirdness kicked into overdrive. A problematic user was copied in AD for testing and everything worked perfectly first go. Even weirder, accounts that we’d been investigating suddenly started working but no one had changed anything. Why had some accounts starting working? Why did a clone of a problematic account work? Why were most still broken?

It was then that something off was spotted. If a broken user account was checked using Active Directory User and Computers, everything looked fine. However, if the same account was checked using Active Directory Administrative Center then the home drive attribute was empty but the path was populated. Time to break out PowerShell.

Using PowerShell to compare the attributes of a broken account and working clone, it soon became clear there was something wrong with the home drive attribute. There was a colon missing. It was a simple as that. PowerShell commands to set the attribute to include the colon after the drive letter were fired off, AD Admin Center opening and would you believe it, the home drive attribute was showing correctly. The user logged in and as if by magic, the home drive mapped. All of that because of a missing colon.

When the original script that created the user was checked, the home drive attribute was set without the colon. This has been fixed and tested and users work correctly.

As for the broken users, a quick PowerShell commands to search for users with the broken home drive attribute and a follow up to fix and hey presto, everyone is working again.

So why did some users mysteriously start working? Remember when I said that ADUC was showing the home drive correct? If you click OK to close the user properties dialog, it was fixing the missing colon. If you click Cancel then the quirk remains. It’s as simple as that. ADUC is also sensible enough to spot the mistake when you copy a user and fix it for you. A warning of a the problem with the original user would’ve been nice but that would take the fun out of troubleshooting!

I’m sharing this here as we wasted too much time trying to figure this out so I hope it helps someone else.

TLDR; If your AD users home drive isn’t mapping, check the home drive attribute and make sure it isn’t missing a colon after the letter.