SharePoint 2010 Console App returns ErrorWebParts

On a recent upgrade project I needed to update the properties of a Content Query Web Part. Sounds easy enough, just need to whip a quick console app and away we go.

Coding went very quickly, but when I ran the app I couldn't get any Content Query Web Parts, they were all returned as"ErrorWebParts".

I consulted my good friend google and found this blog post [1]. This guy was having the same issue as me and discovered that this web part references a SPContext object, unfortunately from a console app there is no web-context.

After reading this, I modified my code to set the HTTPContext.Current and like magic, I was able to edit the properties of all the CQWP.
[1] http://sharepoint-insight.blogspot.com/2008/10/sharepoint-all-webparts-appear-as.html

SharePoint Content Query Web Part not returning all results

On a recent SharePoint 2010 migration project we noticed that when we created new items (pages in the pages library), the Content Query Web Parts did not immediately display the results.

This seemed very odd at first, as I had never noticed a delay before with these web parts, so my first thought was a migration issue. But why would a migration only cause the web part to work slower.

So with the help of my good friend Google, I was able to find a blog post [1] that offered the following:CQWP ignores the following items:

1. Items are check-out
2. Items are not published and not-approved

But I was hitting publish on the page, so my items would not have fallen into either of these categories...unless it was just a delay in SharePoint marking the item as published.


Following the advice in the same blog post, I wrote a console app that targeted all the CQWP and changed the "UseCache" property to false.


Just like magic the items I created are now showing up immediately in their respective CQWPs.


Keep in mind this may not be the best solution for a site with a high load or CQWPs that are running large queries. You'll need to weigh the benefits of performance against immediate results. In most cases users will understand if there is a small delay as long as they have an understanding of the situation.


[1] http://msmvps.com/blogs/laflour/archive/2008/12/24/why-content-query-web-part-cqwp-doesn-t-return-all-results.aspx

Migrating SharePoint MySites from 2007 to 2010

The MySites, for me anyways, are like the forgotten child of SharePoint. When migrating I put a lot of thought into how to move their existing site collections and solutions. What do they currently have setup in the SSP and how are we going to recreate them in the Service Application architecture of 2010. But I never put a lot of thought into how are we going to move the MySites?

On the surface this doesn't sound like a big deal. MySites are site collections like any other, simply built off a different template. Ideally they are hosted on their own Web Application and have their own separate content database(s); so what's the big deal?

This view isn't that far off, but there are a couple gotcha's that you need to consider before making the move:

1. No Visual Upgrade option for MySites (or at least I couldn't find one). This means you will be forced to the 2010 Master Page.
2. All Profile Properties are stored in the SSP database, not the MySite Database. Any custom properties, or any customized values will not be migrated over with just the MySites Content Database.
3. Audiences are stored in the SSP. Web Parts referencing audiences will be referencing the GUID of the Audience, not the title. This makes it very difficult to just recreate your Audiences on the new environment.

The solution to the last two issues is to migrate over the SSP database as the profile database of the UserProfile Service Application in the SharePoint 2010 environment.

To do this you can use this PowerShell cmdlet to create the new user profile Service:
$ProfileGUID = New-SPProfileServiceApplication –Name [User Profile Name] –ApplicationPool [App Pool Name] –ProfileDBName [SSP Database] [1]

The above command will create a User Profile Service Application and upgrade the SSP Database. You can review the upgrade by looking at the Upgrade Status page. Next you'll need to run this command:
New-SPProfileApplicationProxy –Name [User Profile Proxy] –ServiceApplication $ProfileGUID [2]

Next up, the multi value User Properties do not come through right away. This, again, is due the new Service Application structure. The multi values were stored in the SSP in MOSS, but are now stored in the Managed Metadata Service in SharePoint 2010. Fortunately there is a handy PowerShell cmdlet that help map the Properties to the Managed Metadata Service:
Move-SPProfileManagedMetadataProperty -Identity [Profile Property] -ProfileApplicationProxy [GUID of User Profile Application Proxy] -AvailableForTagging -TermSetName [Term Set Name] [3]
I ran the above command against these properties:
SPS-Interests
SPS-MemeberOf
SPS-PastProjects
SPS-Responsibility
SPS-School
SPS-Skills

Unfortunately, this command no longer works after you install the July CU or later [4]. If possible run this command after SP1, but before the CU.


Finally, I hope, there is the matter of the picture dimensions. In SharePoint 2010 they have changed things and now use three different sized pictures for the different areas of SharePoint. [5] When a user upload a picture SharePoint automatically creates these 3 different sized pictures. But what do we do about the pictures that already exist due to our migration? Once again it's powershell to the rescue. You'll need to run this cmdlet:
Update-SPProfilePhotoStore -MySiteHostLocation [URL to MySite Host] [6]



Now you should be able to open up this newly created User Profile Service Application. You should see that all your audiences, custom user profile properties and all the user profiles are all there.
To finish off this off, you will need to run a couple configuration steps:

1. Start the User Profile Synchronization Service
2. Re-Map any custom user profile properties to their AD property
3. Configure Synchronization Connection and any filters
4. Setup MySites
5. Start Full Profile Synchronization

Now your upgraded MySites should be ready to use.


[1] http://technet.microsoft.com/en-us/library/ff608036.aspx
[2] http://technet.microsoft.com/en-us/library/ff607737.aspx
[3] http://technet.microsoft.com/en-us/library/ff608037.aspx
[4] http://blogs.technet.com/b/rycampbe/archive/2011/11/22/june-2011-cu-move-spprofilemanagedmetadataproperty-bug-and-the-workaround.aspx
[5] http://blogs.msdn.com/b/spsocial/archive/2011/01/07/photo-management-in-sharepoint-2010.aspx
[6] http://technet.microsoft.com/en-us/library/ff607547.aspx