So I was trying to get the user’s profile pictures to show up on their user profiles in SharePoint 2010. It worked great until I got to the part of running Update-SPProfilePhotoStore.

Update-SPProfilePhotoStore : Error processing the photo URL User Photos/Profile

Pictures/0c37852b-34d0-418e-91c6-2ac25af4be5b_10.jpg for user i:05.t adfs20ser
ver michael.tupker@company.com: System.UriFormatException: Invalid URI: A Do

s path must be rooted, for example, ‘c:\’.

Um, why is it telling me that a Dos path must be rooted? I’m working with a URL here! I after much fighting and swearing at the User Profile Service and it’s apparently broken powershell command. I decided to write my own version of Update-SPProfilePhotoStore. I don’t think it’s as robust as the one that is supposed to work, but at least now all the employees have pictures on their profiles. I still don’t know why the built in cmdlet doesn’t work. We are have up to the august 2011 CU installed. We had not tried running the Update-SPProfilePhotoStore cmdlet before this.

There are a few things that you will need to set.

$mySiteUrl
$upAttribute
$newpictureURL
$picturePath

As well as the searchbase on the get-aduser cmdlet.

#########Begin script
Import-Module ActiveDirectory -ErrorAction SilentlyContinue
Add-PsSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
Start-SPAssignment -Global
#creates connection to UPS
$mySiteUrl = "https://mysite.corp.net"
$upAttribute = "PictureURL"
$site = Get-SPSite $mySiteUrl
$context = Get-SPServiceContext $site
$profileManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($context)
$profiles = $profileManager.GetEnumerator()
$newpictureURL = "https://mysite.corp.net/ADPictures/"
$picturePath = "E:\Scripts\SyncPics\ProfilePictures"
#gets all pictures from AD and save them locally
$users = Get-ADUser -Filter * -SearchBase "OU=Accounts,DC=company,DC=net" -Properties mail,thumbnailphoto
$users | foreach-object {$username = $_.mail; $_.thumbnailphoto | Set-Content $picturePath\$username.jpg -Encoding byte}
$spWeb = Get-SPWeb -Identity $mySiteUrl
$spFolder = $spWeb.GetFolder("ADPictures")
$spFileCollection = $spFolder.Files
#loops through all profiles, uploads the picture to the library and sets the profile picture
Foreach ($profile in $profiles) {
    $email = $profile["workemail"].value
    Write-Host $email
    $file = Get-ChildItem $picturePath -filter "$email.jpg"
    #check if file exists. if true upload pic to library and set picture URL
    If ({Test-Path $picturePath\$email.jpg} -and $file.length -gt 1) {
        $filename = $file.name
        $spFileCollection.Add("ADPictures/$($filename)",$file.OpenRead(),$true)
        $profile[$upAttribute].Value = $newpictureURL + $filename
        $profile.Commit()
    }
    else {
        $profile[$upAttribute].Value = $Null
        $profile.Commit()
    }
}
Stop-SPAssignment -Global

Update 2012-07-16: So I finally got my logon and resource domain connections setup and working last week (see this blog post). Today I tried the Update-SPProfilePhotoStore cmdlet again now that we are off of ADFS and and using good old windows auth, guess what it worked.

Update-SPProfilePhotoStore -MySiteHostLocation https://devserver.domain.local/my -CreateThumbnailsForImportedPhotos $true

I ran the above command as it appears to be actually creating pictures in the User Photos picture library in the my site host.

I’m still not sure why the cmdlet fails when sharepoint is using an external identity provider like ADFS, (I’ve also seen reports that this happens with FBA claims as well). It may still be a product of the CU we are on (aug 2011) and may be fixed in a later CU. I will probably never end up finding out for sure. 🙁

Just an FYI, if you have a large user base expect this to create a LOT of pictures. I believe it creates 3 different pictures sizes for each user. It shouldn’t be a problem because of sharepoint 2010’s list and library limits (unless you have over 10 million employees). 🙂