Office 365 Basic fault finding Part Two
Office 365 Basic fault finding Part Two
Summary
Once the whole cloud mentality takes hold on your organisation, the chances are that everything externally accessible will be out there and, accordingly, you will have deployed some form of directory synchronisation – most likely Microsoft’s AD Connect – and some sort of automation to provision and license new users.
So, here is yet more basic guidance on how to track down what has actually gone wrong in your brave new world of cloud servers, directory synchronisation and federated authentication.
Directory synchronisation
It is highly likely that practically all the accounts that your users will use in the Office 365/Azure directory are synchronised from your internal Active Directory so there will be a replication service (currently called AD Connect) running on one or more of your internal servers that creates new users whenever they are added to your AD. Current versions seem to do this every 30 minutes during the day. It can therefore take 30 minutes from an account being created in your AD before it is available for logon using Office 365. Patience is therefore a virtue as any changes made in your internal Active Directory will take at least that amount of time to replicate into the cloud.
Although there is a nice interface to set AD Connect up (for selecting the OUs that will be in the scope of synchronisation, for example), that is about the limit of its capabilities. For diagnostic purposes, you will need the FIM console – the AD Connect synchronisation engine is just a stealth version of FIM – and this is located by default in c:\program files\microsoft azure ad sync\uishell\miisclient.exe on the server that is running AD Connect. Note the fact that only certain OUs need to be replicated to Office 365/Azure. This means that a user object has to be in one of these OUs in order to get a license and thus get a mailbox. Sometimes it is that simple.
Deeper digging will need the FIM console as shown below:
FIM is a complex product and it does not actually advertise its presence as the concepts behind its operation are likely to cause the rapid onset of brain fatigue. From a fault finding perspective though, the FIM console allows use to quickly figure out if something simple is wrong
- Connector Operations A status of success is good, as you might expect, and anything else is probably bad. Usually not terminally bad though, as export errors are commonplace. Don’t worry about them unless they reoccur as most fix themselves on the next synchronisation run. The other common error you will see – usually shown as a fatal error with a variety of numeric code - actually relates to disk space. As the FIM installation is hidden from view you might not noticed that it also uses SQL and allowed enough space on the drive for that. Over time, the drive fills up and causes the SQL service to crash bringing down FIM/AD Connect in the process. Clean out some space – SQL crash dump files tend to be large so they are a good place to start – and you will be back in business.
- Export Errors As previously stated most export errors resolve themselves but there is one that seems to turn up regularly - AttributeValueMustBeUnique - and that indicates duplication of an account or of an account attribute. Note that depending on whether the duplicate is in your AD or in Office 365, the error may also be displayed in the Office 365 Portal. In either case, it will be necessary to track down the duplicate object in either your AD – usually a duplicate email address or display name rather than a duplicate object - or in Office 365 and delete it. If the duplicate is in Office 365 and it shows a status, in the Office 365 Portal, of In Cloud rather than Synced with Active Directory then that Office 365 object can be deleted and things will sort themselves out on the next Export cycle.