If you don't host your Employee Directory Photos in Active Directory (which I've found to be pretty common), and you're using SharePoint 2010 User Profiles, you've probably done something in Forefront Synchronization Service Manager to import the Photos. Possibly something custom or really cool that I've never even heard of. Regardless of how you get the pictures into SharePoint, you may have a new problem: Picture Sizing Issues.
Here's some simple Powershell to Resize those User Profile Pictures that you can run from the SharePoint 2010 Management Shell.
Update-SPProfilePhotoStore –MySiteHostLocation “http://YourMySiteHost/”
If you want to run it from regular old Powershell it becomes a *massive 2 line script.
Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
Update-SPProfilePhotoStore –MySiteHostLocation “http://YourMySiteHost/”
What's Next?
How do we take advantage of this amazing automation you ask? Well, for simplicity, you could save the regular option or *massive option as a "resizeUPSPhotos.ps1" and run the "resizeUPSPhotos.ps1" in Task Scheduler (or whatever you use as a Job Execution Server).
*Note: Not actually "massive" since it's only 2 lines.
You should take into consideration the Task scheduling so that it executes after the User Profile Syncronization completes. This could vary depending on the size of your organization and time it takes to complete the syncronization. Much like the first Full Syncronization takes to import, the first time your resize the photos, it will also be slow.
A Farm Administrator will be needed to run the job. It's possible that there might be a less permission role that could be used to resize the photos, but I haven't gone that deep into investigating it.
How do I import from another source?
If you're looking to Import Employee Pictures, from a source other than the Active Directory Thumbnail Attribute, here's a great article to do so, by Chaitu Madala - http://www.chaitumadala.com/2010/05/setting-up-pictureurl-user-profile.html
Friday, April 6, 2012
Adding a Content Database to a farm with different patch levels.
Attaching and Upgrading a SharePoint 2010 Content Database
I personaly prefer Powershell for simplicity and how many options we gain by using it. Here's a breakdown of some options for attaching a Content Database, granting access to domain account previously configured as Managed Accounts in your Farm and upgrading the Content Database.
The following below assumes that Content Database has already been attached in SQL by our Database Administrator friends, and now we need to make use of it in SharePoint. *FYI - DBA's do not like spaces in Database Names, so when you create them, don't use names with spaces.*
Add Content DB:
Mount-SPContentDatabase "Content_Database_A" -Database Server "DBServerName"-WebApplication http://webappA
Here's a link for reference - http://technet.microsoft.com/en-us/library/cc825314.aspx
It's hardly a complicated or lengthy script, so you either save it as "AddContentDB.ps1" and run it or just paste it into the SharePoint 2010 Management Shell window.
Attach and Upgrade a Content Database.
New Challenge - Attach a Content Database from a Farm with lower patch level. and then upgrade it once it's attached. To solve this challenge we'll need to upgrade the database after attaching it. Again our friend Mr. PowerShell will be able to help us.
Mount-SPContentDatabase "Content_Database_A" -Database Server "DBServerName"-WebApplication http://webappA
Get-SPContentDatabase | ?{$_.NeedsUpgrade –eq $true} | Upgrade-SPContentDatabase -confirm
This will do 2 things here, with a prompt before starting the 2nd thing.
#1) This will Attach the Content Database
#2) This will look for any content databases that need upgrading and prompt you to upgrade 1 or all of them.
Attach a Content Database, Grant a Domain Account access and Upgrade the Content Database.
Yet another challenge. Attach a Content Database, grant access a Domain Account access (ideally also a ManagedAccount in your Farm) and upgrade the database after it's attached.
Mount-SPContentDatabase "Content_Database_A" -Database Server "DBServerName"-WebApplication http://webappA
$webapp = GetSPWebApplication "http://webappA"
$webapp.GrantAccessToProcessIdentity("Domain\AcountNameA")
Get-SPContentDatabase | ?{$_.NeedsUpgrade –eq $true} | Upgrade-SPContentDatabase -confirm
This probably isn't a very common situation. But if you're running Office Web Apps as a Domain Account, different from your Web Application Account, you'll need to grant the OWA account access to the Content Database. I'm creating a topic for another post, but something to note, the Office Web Apps Cache is part of each Content Database so the account will need access.
Subscribe to:
Posts (Atom)