High Resolution User Photo Synchronization to Office 365

There are some known limitation and inconsistency with user photos synchronization from Active Directory (using the thumbnailPhoto attribute) to Azure AD and Office 365 apps: Exchange, SharePoint and Skype for Business (aka Lync), specifically if you want to upload high resolution photos of your users that will span across all of Office 365 services.

After spending some research time around this issue, here are my findings:

So to summarize at this point, we want to import high resolution photos to our users. If we rely on the thumbnailPhoto attribute value from Active Directory, we will end up with low resolution images (needs more JPEG effect) or inconsistent results if we look on the SharePoint case.

To upload high resolution photos to Office 365, you should use Set-UserPhoto. This approach works great for Exchange Online, Skype for Business and Azure AD. Although promising, my testing (and others..) showed that if your users’ photos were previously synced to SharePoint Online – they will not necessarily be updated using this method.

Here is my take on solving this, in a somewhat chronological order:

  1. If you need your on-premises thumbnailPhoto attribute populated, keep your current practice of maintaining them.
    1. To avoid future inconsistencies – use Azure AD app and attribute filtering to filter out thumbnailPhoto using AAD Connect – Custom installation of Azure AD Connect
  2. Utilize the Set-UserPhoto cmdlet in Exchange Online PowerShell to upload your users high resolutions (648×648 px) photos
    1. Note Uploading High Resolution Photos using PowerShell for Office 365 to workaround – “The remote server returned an error: (413) Request Entity Too Large” error if you get this.
  3. To upload your users high resolution photos to SharePoint online use the Core.ProfilePictureUploader sample app from the OfficeDev PnP GitHub repo.
    1. To make this easier to non coders :) I’ve complied the code sample for your usage – http://ilantz.com/files/Core.ProfilePictureUploader.zip
      1. Get the source code here and also make sure to read the FAQhttps://github.com/OfficeDev/PnP/tree/master/Samples/Core.ProfilePictureUploader
      2. Follow the explanations in the GitHub page link above around how to run the utility (configuration.xml , the CSV input file and the command syntax).
      3. Make sure your pictures are JPEG files…
    2. This sample app is also documented here, with some additional explanations – Upload user profile pictures sample app for SharePoint

That’s it !

Hope this helps anyone, please comment if it did.


Posted in Azure AD, Office 365 | 1 Comment

Intune On-Premises Exchange Connector Log

Just a quick note for everyone missing the log files location of Microsoft Intune On-Premises Exchange Connector, seems like there is no documentation on where those files exists. and they are very useful for debugging this component.

This info came from a support case I’ve had with the on-premises connector :)


  • Log files are here – C:\ProgramData\Microsoft\Windows Intune Exchange Connector\
  • If you wish to enable verbose tracing for more advanced debugging do the following:
  1. Open the Exchange Connector tracing configuration file. The file is located at: %ProgramData%\Microsoft\Windows Intune Exchange Connector\TracingConfiguration.xml
  2. Locate the TraceSourceLine with the following key: OnPremisesExchangeConnectorService
  3. Change the SourceLevel node value from Warning ActivityTracing (the default) to Verbose ActivityTracing.
      <Key xsi:type="xsd:string">OnPremisesExchangeConnectorService</Key>
      <Value xsi:type="TraceSource">
            <SourceLevel>Verbose ActivityTracing</SourceLevel>
            <FileName>Microsoft\Windows Intune Exchange Connector\Logs\Connector.svclog</FileName>

It is important to note that the ActivityTracing setting should remain or be included with ANY value that is set for the setting.


Posted in Uncategorized | 2 Comments

Lesson learned on PowerShell Modules

Quick note, make sure you do not forget to modify your PSModulePath system variable when installing a new PowerShell module…

Quoting from Installing Modules:

Effect of Incorrect Installation

If the module is not well-formed and its location is not included in the value of the PSModulePath environment variable, basic discovery features of Windows PowerShell, such as the following, do not work.

  • The Module Auto-Loading feature cannot import the module automatically.
  • The ListAvailable parameter of the Get-Module cmdlet cannot find the module.
  • The Import-Module cmdlet cannot find the module. To import the module, you must provide the full path to the root module file or module manifest file.

In my case, I’ve noticed that because I did not modified the PSModulePath system variable, a schedule task of the PowerShell script using that module failed to import the module…. the fun part was that running it in Interactive Mode (while being logged in to the server) actually worked…

Learn from the mistakes of others…


Posted in PowerShell | Leave a comment

Exchange upgrade fails due to missing language files

Just to help anyone out there that might be facing this issue. I’ve helped troubleshoot an Exchange 2010 RTM upgrade to Exchange 2010 SP3 which kept failing due to missing language files…

Event ID 1603 was also thrown as per to the KB 2784788 – “1635” or “1603” error code when you install update rollups or service packs for Exchange Server 2007 or Exchange Server 2010

The MSILOG indeed showed that the setup was looking for the RTM language files in the original location where the setup files were, but they are long gone… with the RTM DVD no where to be-found (RTM trial files + the oldest Language Pack bundle are in a non compatible version) this situation was doomed to failure.

So, I’ve turned to manually remove any references to the Client / Server language packs on the server, this included removing a whole bunch of registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\Language Packs\ <-- the whole KEY
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\  <-- Whatever "Microsoft Exchange ** Language Pack" I found
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\  <-- Whatever "Microsoft Exchange ** Language Pack" I found
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products  <-- Whatever "Microsoft Exchange ** Language Pack" I found

Following this brutal way, I’ve stumbled upon a way to Applying Small Updates by Reinstalling the Product this actually achieves what the installer wants:

msiexec /i Server<or>ClientLanguagePack.msi REINSTALLMODE=vomus

And it works ! Now, I guess that with a script this would have been much quicker then the registry method, but at least now I’m (and you are) aware of this workaround , and here’s the script for your usage:

** edit the $setuplocation variable for your directory of the servicepack.

$setupLocation = "c:\sp3"
$allDirs = dir $setupLocation -Directory
foreach ($dir in $allDirs)
if (Test-Path ($dir.FullName + "\clientlanguagepack.msi")) {Write-Host "Installing" $dir.name ; Start-Process -FilePath msiexec -ArgumentList /i, ($dir.FullName + "\clientlanguagepack.msi"), "REINSTALLMODE=vomus" -Wait }
if (Test-Path ($dir.FullName + "\serverlanguagepack.msi")) {Write-Host "Installing" $dir.name ; Start-Process -FilePath msiexec -ArgumentList /i, ($dir.FullName + "\serverlanguagepack.msi"), "REINSTALLMODE=vomus" -Wait }


Additional references:

Upgrading Service pack – keep asking for language pack

http://stackoverflow.com/a/7916340 – credit for the REINSTALLMODE=vomus trick

How to restore the missing Windows Installer cache files and resolve problems that occur during a SQL Server update – kb 969052

Posted in Exchange 2007, Exchange 2010, Exchange 2013, PowerShell, Server 2008 / R2, Server 2012 | Leave a comment

Don’t forget to modify your Windows Server Power Options

Following a troubleshooting session I’ve had lately, I wanted to share with you an important recommended settings that most folks (myself included) often overlook.

With more and more virtual servers and less and less physical servers being deployed, capabilities like SpeedStep of a CPU were forgotten. Take for example the following “modest” specifications of Intel Xeon E5-2690 v2, with 10 cores @ 3.0 GHz this is a “fare” spec for a high load / CPU intensive profile server.

BUT ! if you forget to select the “High Performance” power option in Windows Server for example, you could end up with:

e5-2690v2 at half speed

Notice that the speed of the CPU is less the half the speed it can run at. now to make things better, just make sure to select the “preferred” settings for your busy server:

e5-2690v2 at full speed

Just a heads up for all you folks out there, the default “Balanced” option caused a performance issue with an Exchange 2013 server that was running on this physical hardware and once the option was changed – all was back to normal :)


Posted in Exchange 2013, Misc, Server 2008 / R2, Server 2012 | 4 Comments

The Exchange toolkit

I’ve just bumped into Chad Solarz’s “The Exchange toolkit” blog entry. it’s quite dated… but nonetheless has great links and a great “one stop shop” here.

For your usage..


Posted in Exchange 2003, Exchange 2007, Exchange 2010, Exchange 2013, Office 365, Outlook / MAPI, PowerShell | 2 Comments

Quest (Dell) ActiveRoles Management Shell for Active Directory

Looking to download QAD / Quest AD cmdlets / Quest ActiveRoles Management Shell for Active Directory ?

Took me a while to locate it now once Quest was integrated into the Dell Software website… so here’s your quick way to download :


It was just hiding in the Trial downloads section – http://software.dell.com/trials/

Happy QAD’ing :)

Posted in PowerShell | 3 Comments

How to reset OneDrive for Business when it’s crashing constantly

Recently I’ve messed with my Windows 8.1 profile account, and shortly after my OneDrive for business client started crashing in a loop… it just went crazy, filling my notification area with icons failing to stop. I had no way to reach any menu or remove the folders I’m syncing.

I’ve tried the easy (lazy) way of repairing / uninstalling / removing Office 365 ProPlus (in my case) which turned out useless.. did some manual clean up of registry entries, removed caching files and obviously looked-up forum threads and KB’s which also turned out as you’ve guessed it – useless…

Almost desperate, I’ve turned to the all mighty Process Monitor and started debugging the errors.

Thru closely examining the endless output of entries, I’ve spotted an undocumented registry entry that was being checked by the Groove.exe (which is your OneDrive sync process) upon start-up.

So there I was, crossing fingers,  editing the registry hoping… and BINGO! I have performed a reset to the OneDrive for Business client, and it behaved like the first time I’ve opened it up.

Here it is, Add/Modify these two DWORD values:



Hope this post will help more good folks out there.


Posted in Office 365 | 3 Comments

Exchange 2013 CU5 upgrade fails with error – The object already exists

Just ran into this one,

An existing Exchange 2013 CU2 installation was requested to be updated to CU5, nothing special there…

Once trying to run the CU5 setup.exe /PrepareAD , the setup failed with an error:
[02/07/2014 11:57:49.0192] [1] [ERROR] Active Directory operation failed on dc.domain.com. The object 'CN=Default,CN=OWA Mailbox Policies,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com' already exists.
[02/07/2014 11:57:49.0192] [1] [ERROR] The object exists.

Digging in the ExchangeSetup.log file, I’ve tried to identify the cause.

[02/07/2014 11:57:49.0192] [1] [ERROR] The following error was generated when "$error.Clear();
$policyDefault = Get-OwaMailboxPolicy -DomainController $RoleDomainController | where {$_.Identity -eq "Default"};

if($policyDefault -eq $null)
New-OwaMailboxPolicy -Name "Default" -DomainController $RoleDomainController
" was run:
Active Directory operation failed on dc.domain.com. The object 'CN=Default,CN=OWA Mailbox Policies,CN=Exchange,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=domain,DC=com' already exists. ---> System.DirectoryServices.Protocols.DirectoryOperationException:
The object exists.

So I’ve tried to reproduce the test manually using the same command in the setup:
Get-OwaMailboxPolicy -DomainController $RoleDomainController | where {$_.Identity -eq "Default"}
And the result was indeed $null .. which made no sense here… because it does exists, as the error states – the object ‘CN=Default,CN=OWA Mailbox Policies,CN=Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com’ already exists.

Then I’ve noticed that the CN was “default” with lower “d” … although the Where-Object and -eq should be case insensitive, the check failed…

get-owamailboxpolicy before the change - default

So, I’ve modified the value to be “Default” with capital “D”:

Set-OwaMailboxPolicy -Identity default -Name Default

get-owamailboxpolicy after the change

that did the trick :) and the setup.exe /PrepareAD was successful.


Posted in Exchange 2013 | 3 Comments

The Windows PowerShell snap-in Coexistence-Configuration is not installed on this machine

Update – July 7th 2015 – For those who have installed the latest AADSync – Azure Active Directory Sync or AD Connect – Azure Active Directory Connect

There has been another change to the module name, it is now ADSync. and the great news is that forcing replication will no longer be a PowerShell cmdlet.

To initiate a synchronization locally or remotely (if enabled) , you could run the following command for example:

Invoke-Command -ComputerName DirSync-Server.domain.com -ScriptBlock {& "C:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCmd.exe"}

If you’re looking also to force a full password sync to Azure AD , visit this page – How to Use PowerShell to Trigger a Full Password Sync in Azure AD Sync

Just noticed now that the new build of Windows Azure Directory Synchronization Tool, is missing the DirSyncConfigShell.psc1 file.
Moreover, the Coexistence-Configuration PSSnapin is also gone. Trying to add the pssnapin would generate the error – The Windows PowerShell snap-in Coexistence-Configuration is not installed on this machine.

So if you’ve trying to use the known way to force a synchronization with DirSync, use these PowerShell commands to achieve what you were used to.

Import-Module DirSync


enjoy !

Posted in Office 365 | 9 Comments