Synchronizing user photos across Office 365 workloads isn't easy

One of those who read my post titled “Pretty Delve profiles need better synchronization” from last December came back with a question about how to manage user thumbnail photos across Office 365:

“Everything is pretty straightforward in Exchange and we have figured out the process to make sure that appropriate photos are uploaded to Active Directory. The process worked well on-premises and the photos are synchronized with Azure Active Directory now that we run a hybrid environment. Exchange Online users can see the user photos in the GAL but there’s no trace of them in SharePoint Online. Doesn’t the synchronization with Azure Active Directory make the thumbnails available throughout Office 365?”

Although apparently straightforward in nature, this question runs into some issues that persist inside Office 365 five years after its launch.

First, how to get user thumbnails into Active Directory or Azure Active Directory. Users can upload their own photo from a browser using Office 365 Options (or Outlook Web App options if connected to on-premises Exchange). It’s more likely that an administrator will run the Set-UserPhoto cmdlet to upload a JPEG format photo into a user account or that the cmdlet will run as part of an automated feed, perhaps from a HR system. For instance:

Set-UserPhoto "Kim Akers" -PictureData ([System.IO.File]::ReadAllBytes("C:TempKA.jpg"))

When Office 365 was first launched, Exchange Online restricted thumbnails to 10 KB. That limit is still documented in some articles that you read on the Internet and indeed, if you attempt to load a larger file using Set-UserPhoto, bad things will happen and you’ll discover that the cmdlet’s error handling is not great.

Set-UserPhoto barfs on a file larger than 10 KB

In fact, the 10 KB limit is imposed by Azure Active Directory. This is reasonable because Azure Active Directory is a resource shared across multiple workloads. Exchange 2013 changed the rules because it introduced a method to support higher-resolution photos that could be used with Skype for Business, or Lync as it was then.

As explained in this post by MVP Jeff Guillet, from Exchange 2013 on, two versions of the thumbnail are stored. First, a 96 x 96-pixel version is created and stored in the thumbnailPhoto attribute for the user account in Azure Active Directory.  This version respects the limit and will be under 10 KB. Second, a larger and higher-resolution 648 x 648-pixel version is created and stored in the user mailbox.

It’s sometimes inconvenient to have to downsize photo files before uploading them to Exchange Online, but there’s a way to convince it to accept larger files. To do this, you have to connect to Exchange Online PowerShell via the RPS proxy method. Here’s how to set up a session. Note the ?proxyMethod=RPS qualifier to the Connection URI. As you can see, Once the session is established, you can import large photo files with Set-UserPhoto..

$UserCredential = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/?proxyMethod=RPS -Credential $UserCredential -Authentication Basic -AllowRedirection Import-PSSession $Session Set-UserPhoto –Identity TRedmond -PictureData ([System.IO.File]::ReadAllBytes("C:TempLargeTRPhotojpg"))

Set-UserPhoto ingests a large graphic file

An interesting tool written by MVP James Cussen is available to help you prepare suitable photos for uploading into Office 365. The tool is documented in two parts (part 1 and part 2).

All seems clear and we know how to upload user thumbnails in a way that provides pleasing photos of all concerned when working with Exchange Online and Exchange on-premises. From a hybrid perspective, the directory synchronization process will move thumbnail data along with user accounts as long as they are 10 KB or less (a script is available in the Microsoft Script Gallery to check for larger thumbnails). The high-resolution version is transferred along with other mailbox contents when the mailbox is moved from on-premises to the cloud or vice-versa. 

But then the problem of other Office 365 workloads comes into focus. Although Azure Active Directory is the master, each of the different workloads has its own directory and synchronization processes are used to keep the directories updated. SharePoint Online has SPODS, Skype for Business has LYODS, Exchange Online has EXODS, Yammer has its own directory, and so on. Keeping separate workload directories allows applications to maintain properties and objects that are unique to it rather than having to go to Azure Active Directory all the time.

As it happens, building suitable scripts to use the Set-UserPhoto cmdlet is the easiest way to process bulk uploads of user photos and if you’ve gone through the effort of loading user thumbnails into Exchange, it would be nice if the photos were synchronized to the other workloads. Alas, although simple in concept, this proves to be bafflingly difficult in practice. Or at least, it doesn’t work as well as it should do, especially as we’re now almost five years into the Office 365 journey.

Apart from looking at how properties like phone numbers are synchronized across workloads, I really hadn’t paid much attention to user thumbnails. And after reading the very informative note on the topic by ThreeWill, my brain hurts. The note is from April 2014 but not much seems to have changed since then.

In summary, it seems like Exchange Online and Skype for Business cooperate nicely when it comes to updating user thumbnails but SharePoint Online runs by its own rules and strange things have to happen before a thumbnail turns up. The strangest being the need for someone to edit their Delve Profile and do something (even just cancel the profile update) before a photo that was originally loaded through Exchange Online will appear inside SharePoint. I haven’t figured out Yammer yet. Maybe someone knows whether it’s possible to synchronize photos from Azure Active Directory (or Exchange) to Yammer.

There’s got to be a better way. Stuff like this shouldn’t be happening this far along the cloud journey. I know that Microsoft can do better, but it’s likely that this kind of plumbing work is being bypassed by the desire to push out new features to users as quickly as they become minimally viable.

Follow Tony @12Knocksinna