Q:

User naming convention

Looking at doing an integration and discussing the sAMAccountName attribute that is being populated in AD with usernames. 
Currently the system is using first initial and last name if a duplicate account is detected with that username it adds a letter for example Robert McKay would be: rmckay. The first account created would work fine however if there is a second account it would be romckay and continue down a strange path of additional letters and numbers forcing uniqueness for the users. The client is wanting to move to a completely numeric username. Instead of rmckay it would now be 0000001 (for logins to everything that is AD connected or pulling from AD). 
Also there are systems that derive their account login and generation from the sAMAccountName - so even though in the case of emails and systems where AD login has been setup the down stream systems that rely on the sAMAccountName  will still required a login of: Employee ID + password vs friendly username + password.
Additionally there has been common consensus among the staff about user friendliness drop – however the one major concern was the issues that could arise for emails, however that will be addressed through the use of aliases. Anyone aware of anywhere that successfully was able to implement an Employee ID as sAMAccountName and found that the net result was positive (give the reduction in user friendliness?) Or can point to best practices that can be reviewed to share?

A:

In our environment, we have 10 domains that were created separately back in the day, then brought together eventually under one forest. One one of the domains, they did something like that. The sAMAccountName was two consistent letters (always the same) followed by a 4-digit number unique to each user.
From what I was told, that requirement originally came from some mainframe application that used that username system. I don't know the details.
In recent years, though, we've been moving those away from it. It's pointless.
If you do have to do it, remember the userPrincipalName attribute, which can also be used for logging in. So even if the sAMAccountName is something awful, you can still make the userPrincipalName equal to their email address and users can then use that userPrincipalName to login. They won't even need to know what their sAMAccountName is.

