Office 365 UPN User Principal Name not updated after first active directory sync

A new user assigned an Office 365 License could not log on to Office 365 Word and Excel etc.
It soon became obvious that that login 'username' was wrong on Office 365. This was the first time I had encountered this problem.

The logon should have been bloggsj@mydomain.com but was showing joeb@mydomain.com in Office 365.

I asked a colleague to check every attribute on AD and there were a couple of attributes that matched the old format so these were 'corrected'. A quick manual sync and ... no change. Then I checked the Active Directory Sync status and that showed no errors or exceptions.

After some research I found that this UPN attribute, a type of primary key for the logon, is set at first sync and not updated subsequently. The only way to change it is with PowerShell. I had reinstalled my laptop from scratch  recently with Windows 8.1 and there was no PowerShell tooling installed. After installing the appropriate PowerShell modules (see below) I changed the username as below.

Set-MsolUserPrincipalName -UserPrincipalName [CurrentUPN] -NewUserPrincipalName [NewUPN]

The user was able to log on immediately and start using Office 365.

This highlighted (at the time of writing) the poor state of tooling for Azure AD, and indeed other PowerShell features.

On installing the PowerShell Azure cmdlets the installer tells you that must first install Sign-in Assistant 7.

This is actually surprisingly tricky to hunt down and eventually takes you you to a web page described as Sign-in Assistant BETA, hardly confidence inspiring, the earlier 'non beta' version was too old.

http://www.microsoft.com/en-us/download/details.aspx?id=39267

Then how do you know the recently installed cmdlets are up to date, what version they are, or will they be kept up to date, are the cmdlets related to other Windows Azure tooling, which also follows the same mess.
The Web Platform Installer shows that the PowerShell Libraries in this area are a hotch potch of rapidly coded and released software without much thought to the future. This is probably how it is at the moment, but someone needs to take a look at the management of this

These cmdlets should be included in the add/remove features of PowerShell and if you tick them then they should load all the prerequisites and automatically update.I would have hoped for this to be the case by now. I had left office 365 for a year to settle down so that these sorts of problems would already have been ironed out. Alternatively they should just install them anyway as part of the main Windows install. They are pretty safe as you need to have credentials to do anything with them.

Active Directory Office 365 sync problems

Setup is Directory Sync to Office 365 hybrid (ie write back some AD attributes from Office 365) with password sync.

On initial sync there were some problems not found with the Office 365 pre-check tool.

A few users had inadequate permissions to write-back AD attributes. This was caused by them not inheriting security in AD. Switching inheritance back on fixed the problem immediately. Why they had been set to not inherit many years ago remains a mystery.

Another user who had moved to a different role just would not sync due to a duplicate attribute. The sync tool 'helpfully' omitted which attribute was in conflict.  The user in question had been copied from the original user and then changed and the original user left in place for business reasons. After some time including checking every (visible?) AD attribute no duplicates could be found. The (very useful) idfix tool did not spot any problems either with this record. Google/Bing for idfix.
I added the person to my Outlook to take a look what they had in their mailbox and 2 copies of the same mailbox appeared - very strange- never seen that before. I then removed the person from my Outlook only for 1 of the mailboxes to remain. It seemed obvious that the record had some major problem.The person in question no longer required the account and it was deleted in AD. 2 syncs later the problem had gone. It would have been useful to know exactly what was failing the unique constraint. I am sure it would be pretty easy for the programmers to report this information in the sync failure email you get sent.

I strongly recommend you pin the sync tool UI to the taskbar / desktop as you might be looking at it more than you had hoped at the start!

You can find it here (could change with future versions):
C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe

When you look at the on screen log of what it does automatically it is easy to run manual syncs by mimicking the steps it takes. There is a PowerShell command start-onlinecoexistencesync but you will be needing the GUI to track down problems. This GUI is actually a poor man's very crude AD auditing tool as you can see how many and the nature of changes to your AD and roughly when they happened but not who did it. It is certainly better than nothing, and is a good spin-off benefit of having installed the software.

It can save time when troubleshooting to change the default sync time from 3 hours to 5 minutes so the sync tool keeps attempting to sync whilst you are troubleshooting without you having to run anything:

To do this change the file:
C:\Program Files\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.Config

temporarily from this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <!--the interval in hours-->
    <!--refer for valid values:http://msdn2.microsoft.com/en-us/library/system.timespan.parse.aspx-->
    <add key="SyncTimeInterval" value="3:0:0" />
  </appSettings>
</configuration>

to this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <!--the interval in hours-->
    <!--refer for valid values:http://msdn2.microsoft.com/en-us/library/system.timespan.parse.aspx-->
    <add key="SyncTimeInterval" value="0:5:0" />
  </appSettings>
</configuration>

Set it back to your selected sync time afterwards - I would not recommend leaving it at 5 mins!

Happy syncing