In order to understand this move it is unfortunately necessary to understand a slightly complicated infrastructure and user account change Google put in place by September 5th. You can find the narrative below.
You may want to look at this Google Apps accounts Conflict Diagram we created first. It tries to convey the below information visually.
MIT signed up to take over the previously un-administered Google Apps for MIT domain on on August 22nd.
Google called these un-administered Apps domains "Team Edition." They were automatically set up by Google for EDU domains, and users with email addresses at the corresponding internet domain, in this example mit.edu, could self-register for an account. Google announced in early August they would be deactivating "Team Edition" domains in early September. At the time, the MIT "Team Edition" domain had 3500 self-registered users, a subset of whom were using it actively. MIT also signed a Google Apps for Education agreement with Google in early August.
Given the above confluence of factors, MIT decided to take over administration of the Google Apps domain for MIT on August 22nd to keep it from expiring.
Shortly after signing up for administering the domain we were notified that Google was transitioning all Google Apps user accounts to its new infrastructure. This would potentially give them access to all the same Google services and applications consumers enjoy on their personal Google accounts. This transition was scheduled for September 5th, a date which could not be changed. The transition had been announced well in advance to other Google Apps domains, but because ours was un-administered "Teams Edition" until August 22nd, we did not hear about it until then.
A side-effect of this transition was that after the transition, a Google account user name could exist in only one Google account. If a Google domain user name conflicts with a personal Google user name or login alias, the user would be presented with a warning page the next time they logged into their personal account informing them that this user name was no longer available for personal use. They would have to pick a new one, or give it up as an alias. As far as Google is concerned the domain user name always trumps a personal user name.
This would have been a very poor experience in our case. Many MIT users use their personal Google accounts for MIT business and professional collaborations, as well as personal activities. Most only dabbled in the Google Apps MIT domain.
On Friday, August 31st we discovered that there were quite a large number of conflicting accounts for which this problem would have occurred. We identified 761 user name conflicts, in addition to an unknown, larger number of conflicts with login aliases on personal accounts. Even working with Google enterprise support there was no way to resolve this issue while maintaining the same user names in both places, and it would continue to be problematic going forward, forcing MIT users to choose whether to use the Google Apps for MIT domain and give up the association of their MIT username with their personal Google account, or not use the Apps domain.
We decided to instead rename all accounts in the MIT Google Apps domain to firstname.lastname@example.org. The accounts remain unchanged, except that in order to log into an MIT Google Apps domain account, the user would use username-google instead of just username. This only applies to MIT Google Apps logins. It does not affect users' MIT Kerberos accounts or personal Google accounts.
In the future, users can choose to associate their MIT username with their Google apps account, once they fully understand the implications. Their MIT username would be set up as an alias in the MIT Google Apps domain. Once we deploy Touchstone authentication, users will be able to sign in with their MIT Kerberos username or MIT certificate, and no longer need to remember to use username-google as their MIT Google Apps username.