How to import high resolution pictures to SharePoint using other links instead of thumbnailPhoto AD attribute?

The size used for the Active Directory thumbnailPhoto attribute is only 48 pixels by 48 pixels. If you would like to get higher resolution pictures rather than AD thumbnailPhoto attribute that is synced from UPS to SharePoint on-premises, you have the following options.

• Import pictures using SharePoint object model either C# or Powrehsell
• Import pictures from exchange

In this blog, we will explain the details to import high resolution pictures from exchange to SharePoint on-premises since we have pictures already imported in exchange. 

     1.  Establish an OAuth trust and service permissions in Exchange

a.       On the Exchange server, login as Administrator and open the Exchange Management Shell through the start menu

b.       Navigate to the scripts directory "C:\Program Files\Microsoft\Exchange Server\V15\Scripts"

c.       Enter the following command, where the AuthMetadataUrl begins with the hostname of the My Site Host

.\Configure-EnterprisePartnerApplication.ps1 -ApplicationType SharePoint -AuthMetadataUrl https://sp.contoso.com/_layouts/15/metadata/json/1

d.       A successful completion of the command should look like this:
        

2.  Set up the OAuth Trust within SharePoint.

a.       Complete the following steps on the SharePoint server that hosts the My Site web application

b.       Create the new SPTrustedSecurityTokenIssuer

$realm = Get-SPAuthenticationRealm

$nameid = "00000002-0000-0ff1-ce00-000000000000@$realm"

New-SPTrustedSecurityTokenIssuer -Name "Exchange" -MetadataEndPoint "https://exch.contoso.com/autodiscover/metadata/json/1" -RegisteredIssuerName $nameId

3.   Configure the Security Token Service

$sts = Get-SPSecurityTokenServiceConfig

$sts.AllowMetadataOverHttp = $true

$sts.Update()

 Note: If the My Site is not an SSL site, update the above to include the following line before the update:

$sts.AllowOAuthOverHttp = $true

Configure Exchange external URLs

Exchange needs to be configured to communicate using various external URLs. Complete the following steps on the Exchange server

4.     Exchange Web Services (picture retrieval) - Configure the Exchange Web Services (EWS) external URL

a.       Confirm that the External URL is not currently configured

Get-WebServicesVirtualDirectory | fl *url*

b.       Set the External URL to the same value as shown for the Internal URL returned from the previous command

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl "https://exch.contoso.com/EWS/Exchange.asmx"

5.      Exchange Control Panel (picture retrieval) - Configure the Exchange Control Panel (ECP) external URL

a.       Confirm that the External URL is not currently configured

Get-EcpVirtualDirectory | fl *url*

b.       Set the External URL to the same value as shown for the Internal URL returned from the previous command

Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -ExternalUrl "https://exch.contoso.com/ECP/"

6.      Outlook Web Access. Because we changed the ECP external URL, we need to do the same for the OWA External URL

a.       Confirm that the External URL is not currently configured

Get-OwaVirtualDirectory | fl *url*

b.       Set the External URL to the same value as shown for the Internal URL returned from the previous command

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -ExternalUrl "https://exch.contoso.com/owa"

 

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. You might need to run picture split powershell to generate three different size of the pictures used by SharePoint.

When you decide to move this to production,  please be aware of some design issues and limitations I will explain in the future blog.

Why some back comparable 2010 workflows intermittently failed on SharePoint 2013?

After we upgrade SharePoint to 2013, we found some workflows failed intermittently. The failed workflows include not only custom workflows but also out of box approval workflows. After debugging the OoB failed workflows, we identified that most of the failed OoB workflows have due date or duration configured. This is pointing to issue “Bulk workflow task processing” timer job that should be trigger by “SharePoint Foundation Workflow Timer Service”. 

If we looked at the SharePoint workflow architecture, the “SharePoint Foundation Workflow Timer Service” should be the process to trigger the workflows with due date or duration configured. This workflow timer service would need to have all the references like assemblies and workflow definitions in order to process successfully the workflows. In our cases, our previous consultants configured the “SharePoint Foundation Workflow Timer Service” on the application servers NOT the WFEs. We normally do not have solutions and workflows deployed to application servers.

One issue we could explain the Muhimbi workflow failed in production. Muhimbi installation will installed many features in 15 hive, one workflow in web.config, and one workflow dll in GAC as in following three screenshots.

  

 

If “SharePoint Foundation Workflow Timer Service” is running on application servers, the service will not be able to find the workflow definition, related dlls, or other reference. It will fail as other people mentioned for different workflows. We might have similar issues for the following workflows.

• Third party workflows like Muhimbi worklfow
• Custom visual studio workflow activities
• Designer workflows
• OoB workflows with due date or duration

Now the fix to resolve intermittently failed workflow on SharePoint 2013 is to run the “SharePoint Foundation Workflow Timer Service” on all WFEs instead as Microsoft recommended. The “Microsoft SharePoint Foundation Workflow Timer Service” should run on the server with “Microsoft SharePoint Foundation Web Application” service running. This server is WFE server. Of cause, you could run the “Microsoft SharePoint Foundation Workflow Timer Service” on different server with the configurations mentioned from Microsoft. We have other SharePoint customers resolve the similar workflow issues by reconfigure the “SharePoint Foundation Workflow Timer Service”to run on WFEs.

In addition, here are some steps your might try to debug the workflow issue.

• Enabled all workflow log level to verbose - Check General, Timer and Workflow Infrastructure under the SharePoint Foundation category and select Verbose in the least critical event to report to trace log.

• Verify workflow service account has the full access to all content databases and config database

•  Restart workflow timer jobs

Workflow	Processes workflow events that are in the scheduled items table, such as delays.	5 minute
Workflow auto cleanup	Deletes tasks and instances in the workflow instance table for workflows that were marked completed more than n days in the past, where n is specified in the workflow association. Crawls through tasks and the workflow instance table.	Daily
Workflow failover	Processes events for workflows that have failed and are marked to be retried.	15 minute
Bulk workflow task processing	Processes bulk workflow task completion.	Daily

• Restart SharePoint timer job

Now you should have much stable workflow process.