Pretty Delve profiles need better synchronization

Microsoft uses “Delve profiles” within Office 365 as part of its strategy to make information easier to find, which of course is the mission of the Delve application. The theory is that you might not remember the name of an important document shared with you by someone, but you’ll probably remember the person. Therefore, if you navigate to the profile of that person, Delve will be able to reveal the documents that they have shared with you and the mystery is solved. And it does work, as does Delve search in general, which is the easiest way to find something in Office 365.

SharePoint profiles have been around for a while, along with the User Profile service, and serve to describe the characteristics of a user, much like the properties of an Active Directory account describe an account. Indeed, you can synchronize SharePoint profiles with Active Directory to create or update user profiles. Administrators can add custom properties to user profiles to meet business needs but these properties are not synchronized back to Active Directory.

All of this is fine and the mechanism allows SharePoint to maintain its own directory of users that is well matched to the need of the application. But Office 365 presents a different environment to an on-premises SharePoint deployment. Azure Active Directory is the kingpin directory and there are other applications at play too, including Exchange and Microsoft Online Services (licensing and account management). To accommodate the different needs of the various applications, Office 365 allows them to deploy their own directories, so you end up with EXODS for Exchange, SPODS for SharePoint, and so on.

These directories allow the applications to store information that they need to function without clogging up Azure Active Directory. The directories are linked together by synchronization to ensure that core information (like account identifiers and user names) are shared across applications. An MSOL object for each user holds all the relevant information, including the licenses that are assigned to the user.

Delve profiles are more graphically pleasing than SharePoint profiles and rely on a more limited set of properties. As you’d expect, most of the properties are found in other applications (display name, department, work phone, and so on). Some are unique to Sharepoint/Delve, such as an assistant property, birthday, skills, and interests. See this page for more information on how these properties might be used. For instance, the display name stored for a user in their profile is shown in the author information in SharePoint and OneDrive document libraries.

Because Office 365 presents an integrated environment, you’d expect that updates made to Azure Active Directory would be synchronized out across the applications. In fact, this doesn’t happen. As the table below shows, if you update details for a user in Azure Active Directory using the AAD console, only some of the properties are synchronized back to SPODS to appear in the Delve profile. On the other hand, the two properties kept in EXODS are updated.

Note: I am not a professional tester, so please validate these findings in your own tenant. The point is that these results create enough suspicion that synchronization is not as smooth between Office 365 applications as you might imagine.

Users are not allowed to edit many of the properties displayed in their Delve profile, but updates for the ones that they can change (such as a mobile phone number) remain tied to SPODS and are not synchronized with Azure Active Directory. The exception is when a user updates their photo through their Delve profile as this action is performed by calling an Outlook Web App page, which writes the new photo information to EXODS. An update is also made to SPODS to make the new photo available to the Delve profile.

The situation is very different when an administrator updates details for an Exchange Online mailbox using EAC or a user updates their own details through Outlook Web App options. Behind the scenes, information is retrieved from EXODS and Azure Active Directory and then displayed. If changes are made, it might result in two updates – one via the Set-User cmdlet to Azure Active Directory; the second via the Set-Mailbox cmdlet to EXODS. The sample shown below is captured from EAC using command logging, which accounts for why GUIDS are used to identify accounts.

Set-User -Identity 'ee85c074-0b20-4615-af44-be420d900536' -MobilePhone '+353 222223' -Fax '+353 444444' -PostalCode 'D18 A5R2' -StateOrProvince 'Ireland' -City 'Dublin' -StreetAddress '12 Knocksinna Grove -FirstName 'Tony ' -LastName 'Redmond ' -Title 'Chief Executive' -Department 'Group Operations' -Company 'Redmond & Associates' -Manager '58b56edc-72a5-4f23-958d-83c4eb7b8abe' -Phone '+353 222222'Set-Mailbox -Identity 'ee85c074-0b20-4615-af44-be420d900536' -DisplayName 'Tony Redmond' 

The question then arises if Exchange Online can make sure that bidirectional updates flow smoothly between EXODS and Azure Active Directory, why can’t SharePoint Online do the same thing? It seems logical that all of the Office 365 directories would share a holistic unified view of the properties that are available to communicate information about users, which of those properties can be updated by end users, and how updates propagate throughout the service. That simply doesn’t happen today.

Microsoft is expanding the reach of Delve profiles within Office 365. For instance, a pointer to the user’s profile now shows up if you examine their mailbox properties through the People web application. This is all very well on the surface, but some changes are necessary to make synchronization work properly and consistently across Office 365 before Delve profiles function as you’d expect. It would also be nice if the synchronization happened much faster. It seems like I have had to wait for days before some changes are reflected in my Delve profile whereas updates elsewhere happen within minutes.

In the meantime, those who want to ensure that directories are synchronized across Office 365 need to figure out what data is important and how to make sure (possibly with thrird-party software) that the data appears in the right place at the right time all the time.

Follow Tony @12Knocksinna