In this post I described how Lync 2013 Preview can use high-resolution photos available in Exchange 2013 Preview mailboxes. SharePoint Server 2013 is also able to use the same high-resolution photos. The SharePoint-Exchange photo sync feature implements this.
SharePoint Server 2013 maintains a library of User Photos, just like in SharePoint Server 2010. When SharePoint-Exchange photo sync is enabled, SharePoint's local photo store becomes a cache, and SharePoint Server 2013 treats Exchange 2013 as the master photo store. SharePoint-Exchange photo sync is not a regular sync job that runs on a recurring cycle. Instead, SharePoint Server 2013 requests photos from Exchange 2013 automatically when a user performs an operation that causes a request for their own photo (for example, browsing to their own user profile page). That means that the user needs to have requested his/her own photo, before other users will be able to see it.
When a user with a valid Exchange 2013 mailbox attempts to change their profile photo, SharePoint Server 2013 will launch the Outlook 2013 Web App photo upload dialog.
Two variables (which can be set per web-application) help govern the syncing behavior:
SharePoint Server 2013 is using the Exchange Web Services Managed API V2.0 and Server to Server authentication (S2SOAuth) to be able to read data from Exchange 2013.
Let me show how to configure the integration. I will use the following sample environment to illustrate the configuration:
In the sample environment the programs have been installed on the C: drive.
Configure the Exchange 2013 Autodiscover service to be available on the FQDN autodiscover.contoso.com. Use the following Exchange Management Shell command on e15fe.contoso.com.
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml
SharePoint Server 2013 use the external Url variants for EWS and ECP when accessing the photos on Exchange 2013. In the sample environment I'll use the internal FQDN's also for external use. Use the following Exchange Management Shell command on e15fe.contoso.com.
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –InternalUrl https://e15fe.contoso.com/ews/exchange.asmx –ExternalUrl https://e15fe.contoso.com/ews/exchange.asmx
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory –InternalUrl https://e15fe.contoso.com/ecp –ExternalUrl https://e15fe.contoso.com/ecp
Install the EWS Managed API from the link above on sps15.contoso.com. Make sure that the Microsoft.Exchange.WebServices.dll is loaded into the GAC by using GacUtil. Make sure to use the .NET 4 version of GacUtil (C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools after you have installed .NET 4.0 SDK)
GacUtil /i C:\Program Files\Microsoft\Exchange\Web Services\2.0\Microsoft.Exchange.WebServices.dll
Now it is time to configure SharePoint to do S2SOAuth with Exchange. Use the following SharePoint 2013 Management Shell commands:
We now need to configure the Exchange 2013 side of things. Use the following Exchange Management Shell commands:
Make sure to restart IIS on both front-end and back-end by issuing the following commands in a command window:
Use the following SharePoint 2013 Management Shell commands:
Sign in to Windows as test1 and use IE to access his My site at http://sps15/my. You should now see the high-resolution photo being shown as the profile photo.
If some reason, the photo is not showing you might be able to diagnose the issue by examining the ULS logs available at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS.
Thanks to Ryan, Nathaniel and Sesha for their input to this post.
Trying to do the same thing with S2S OAuth to get Site/Team Mailboxes going in my SP2013 farm using Ex15...
I can't seem to get past the first step in the PS Cmdlet on the SP2013 side:
New-SPTrustedSecurityTokenIssuer : The remote server returned an error: (500) Internal Server Error.
At line:1 char:1
+ New-SPTrustedSecurityTokenIssuer -name "Exchange" -MetadataEndPoint
I haven't been able to uncover anything on this. My Exchange admins also can't seem to figure out how to "enable" (?) the JSON URL/URI for autodiscover (we have https://ExServer/autodiscover/autodiscover.xml up and running, but don't think this is the same
Anywhere you can point me would be greatly appreciated!!!
Jens>Hi Kevin, the Url to use in that step should be to the autodiscover service. If you have it available at
https://exserver/... then it's that Url to use. You don't have to do anything on Exchange side to enable the url. You could look in your IIS logs on the Exchange server to see if the requests get to it. You should also double
check that you have installed the EWS managed API and it's available in the GAC.
You get lost away while you are reading technet. But your blog brings all things together at one place and a person does not need extra effort.
Jens, I too am struggling with this issue.
First of all, thanks for the post! Im just having problem when the users change their photo from Exchange it won't change on Sharepoint Automatically. Do you have an idea how to fix it?
Jens>Thanks! The photo on SharePoint should change within the time you have configured for the expiry. If it doesn't my recommendation is to take a look in the ULS log to see if you can find an error.
Hi Jens - Thanks for the article it worked well for me. Do you know of a way to trigger SharePoint to request the Exchange photo without requiring a user side browser load of their profile? I can't rely on the users to do this for me!
Jens>Thanks! No, I don't believe there is any other way to trigger it.
Hi Jens, I've gone through this procedure with On-Premise SharePoint 2013 and On-Premise Exchange 2013. From Exchange, get-partnerapplication looks like it is successfully partnered with SharePoint; however, the pictures don't synchronize between Exchange and SharePoint when a user profile page is loaded from the WebApplication. In the SharePoint ULS logs, I see this message when I access my user profile page: PhotosUrl or EcpPhotoUrl is null (from AutoDiscover) for Url ProcessPictureRequest: AutoDiscoverPhotoUrls returned the following: ExternalPhotosUrl = , ExternalEcpPhotoUrl = Does this mean that SharePoint can't find the autodiscover URL or is autodiscover not returning values for those URLs? Any help is greatly appreciated.
Jens>Yes, the problem is that SharePoint can't get the values in the Autodiscover response it needs to get to the photos. You can use a tool like EWSEditor to look at the Autodiscover response coming back.
As a workaround I have applied a client-side powershell load of the SharePoint thumbnail image. This triggers the sync just like loading in a browser does. I run it hidden on the user PC. I run it once a day for a while as for some reason a load of the profile
does not always trigger the sync and if it does not subsequent immediate sync's don't help - presumably due to the UserPhotoExpiration or UserPhotoErrorExpiration settings.
Here's the code - enjoy....
# script to trigger Sharepoint to download the high res photo from Exchange
# sadly this must be done client side.
# have PC management software copy the files to the local PC then run......
# powershell.exe -ExecutionPolicy Unrestricted -noninteractive -File "%temp%\PhotoSync.ps1" >>"PhotoSync.log" 2>&1
# All output will end up in the log file
# the following syntax triggers the download (just find yours from your Sharepoint User profile photos)
$username = [Environment]::UserName
$userphoto = "https://people.myco.com/User%20Photos/Profile%20Pictures/" + $username + "_LThumb.jpg"
write-host "$username : $userphoto"
$web = New-Object system.Net.WebClient
$result = $web.Downloadstring($userphoto)
Raul, make sure you are only using the FQDN of the exchange server, do not prepend with https:// or http://.
Just FYI: MSDN says that UserPhotoErrorExpiration property counts in HOURS while UserPhotoExpiration property counts in DAYS. http://msdn.microsoft.com/EN-US/library/microsoft.sharepoint.administration.spwebapplication.userphotoerrorexpiration(v=office.15).aspx http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.userphotoexpiration(v=office.15).aspx
Jens>Thanks for feedback. The MSDN page is wrong. The parameter is in hours. I've asked the page to be corrected.
Hi Jens, Can you confirm that the solution above is still working with the latest versions of Exchange and SharePoint 2013? We tried it but did not succeed and we opened case about it by Microsoft. They say that the procedure above does not work (anymore). We also get the same response as Raul (PhotosUrl or EcpPhotoUrl is null (from AutoDiscover) for Url) but EWSEditor response is ok. Any help is greatly appreciated.
Jens>I have not heard anything to indicate that this should not work any more. You need to make sure you have set the ExternalUrl on EcpVirtualDirectory and WebServicesVirtualDirectory.
Thanks Jens for your reply. The ExternalUrl is set. Your Microsoft co-worker, Goncalo Martins, e-mailed me this: So, after some test that my SEE colleague did, he got the same issue as you, but through other repro-steps. We then setup a complete new lab, where we ran the exact same steps as you did, from the blog, but this doesn’t work. So, it seems that the blog you have used, does not contain all the necessary information to retrieve the HighRes pictures. Maybe you can assist them in the Microsoft case, REG:115010612230464, we have. Thanks, Jeroen
Jens>Hi Jeroen, please continue to work the case via Microsoft Support. If the ExternalUrl's are set the place to look is the OAuth configuration. If the two sides doesn't trust each other it won't work. The ULS log on the SharePoint side has debug information and you can also trace OAuth on the Exchange side.
Any answer from Mircosoft on this issue? I have the same problems you discribed. Already triple checked all the urls from step 1 & 2...
Followed this article to a T. My staff search is now broken and no photos appear. Just to top it off, the server now spikes at 100%, something to do with the Timer Service. Correlation ID: b4d8199d-6bb9-c0ea-00ee-dd41e4d359d4.
Pretty gutted, was hoping for high-res photos, now I got an unusable SharePoint server, ahhhh!!!!!!!!
Is there a way to reverse this? We tried it and it doesn't suit our needs and would like to revert these changes.
Jens>Setting $wa.UserPhotoImportEnabled = $false should disable it