Moving Site Collection to Different Web Application – SharePoint

We created a site collection for saving CRM documents on Intranet web application, we wanted to move that site collection to a new web application to avoid having a single point of failure for the 2 site collections and also allow the CRM administrators to control the maximum attachment size for files stored on SharePoint.

We achieved this by running the below 2 PowerShell cmdlets:

Backup-SPSite -Identity “” -Path “C:\CRMDocumentsSiteCollection.bak”

Restore-SPSite -Identity “” -Path “C:\CRMDocumentsSiteCollection.bak”

The site collection will be created if not already existing, and if we want to override an already existing site collection on the specified URL then we will need to add the -force parameter.

Then we re-configured the documents management settings in CRM to point to the new site collection URL, the good thing about CRM is that it saves the document locations relatively, so such a change in the base URL only requires updating the SharePoint site URL and everything works fine.

Please note that in case you faced a SQL timeout while re-configuring the document management settings in CRM due to having large number of documents then you will need to increase the CRM SQL timeouts on the front end servers.


CAML.NET Intellisense for Visual Studio 2010

Peace be upon you,

The CAML.NET IntelliSense extensions for Visual Studio 2010 is simply a must-have for SharePoint developers. It can help you tame that sometimes finicky, but ever-so-essential CAML language we all know and love.

Really cool visual studio add-on. You can get it from here.

I noticed 2 drawbacks for this tool from the reviews:

• The schema is incomplete and only a subset of what ships with SharePoint as default.

• The uninstallation does not clean up the environment, leaving the schema as default shcema file and not restoring previous state (SharePoint schema). (That’s ok, You will need to manually restore it in case you wanted to uninstall)

But still the tool is having a great potential and will save a lot of development time in my opinion.

Bug When Adding CAS Permissions to WSP Package

Peace be upon you,

When you try to edit the package manifest to add come code access security permissions and then try to deploy you get that error: ‘Property set method not found.’

Here is the resolution for this issue from MS support site:

Also, here is a nice article about how to deploy a Web Part with Code Access Security in Visual Studio 2010 (SP2010):

SharePoint 2010 Claims Authentication

Peace be upon you,

For having understanding of SP 2010 claims authentication, please read the below, it is really clear and summarized:

Following the paradigm shift from SSPs to Service Applications, authentication has been “offloaded” to the “Security Token Service Application.” The “STS” (as it’s known) is one of those service applications that has no configurable properties. (When you select it in Central Admin, the “Properties” and other Ribbon options are disabled.) This is, as far as I’m concerned, both good and bad: good because there’s nothing extra there to break; bad because there’s nowhere to go to fix it when it indeed is broken. Behind these ominous scenes, the STS is just a WCF service, hanging out in “14\WebServices\SecurityToken.” They way this works is that SharePoint routes all authentication through this service. Whenever anyone logs into anything, STS is the mechanism giving users the nod. Now, the web applications are still operating as normal ASP.NET sites; authentication, authorization, forms, etc. (in terms of configuration) don’t change. It’s just that instead of code running the web app to do the work, a service call is made instead. So architecturally, this is really the only big change. In 2007, each web app (Central Admin included) did its own thing for auth. 2010 has now integrated this into its service application layer, with all web apps plug into. However there is one caveat that will lead us into the second part of this post which covers implementation. Even though the STS handles authentication, web apps are still on their own to implement all other user-centric functionality. The best example is the PeoplePicker. Despite the PeoplePicker depending on the very same mechanics as the STS’ authentication and authorization do, it’s not actually doing authentication or authorization; it’s simply querying into these interfaces against our user store (weather it’s AD, SQL, etc.). What does this mean to us? Basically, when implementing custom authentication or authorization, the STS is what needs to be configured to talk to the ASP.NET MembershipProvider. However, any web app that needs to interact with these users, be it searching within a PeoplePicker, adding users to a group, or granting people Site Collection Administrator permissions in Central Admin, needs to be configured to use the authentication provider as well. Just not for authentication. So in SharePoint 2010 Claims-based Authentication, there are now three places you need to go to configure a custom authentication provider (verses just two in 2007): the web application itself (to allow permission and security functionality to work), Central Admin (to implement the provisioning of Site Collection Administrators and other more global user management tasks), and STS (which, again, is doing the actual authentication). Before we move on to the implementation, I want to briefly discuss some semantics. As it stands, offloading authentication across the farm to the STS does not constitute “claims” authentication all the way. In claims (with a lower-case “C”) auth, you provide your credentials to a third party “issuer” who authenticates you and gives you (or your session) a token. It is this token that you give to the actual site or application. So STS is the first “half” of this paradigm. What about the token? That is abstracted to us, and SharePoint wires up its own “claims” provider that does this work for us. We’re using claims auth without having to worry about anything beyond forms auth!

To summarize:

1. Forms authentication is configured for the web app, so it knows to provide a login page to you.

2. The login page passes your credentials to STS.

3. STS uses our custom provider to authenticate you and issues back a token.

4. This token is sent to the web app, which uses the SPClaimsAuthMembershipProvider and SPClaimsAuthRoleProvider to process the token and use it for final authentication and authorization respectively.

5. The web app then uses the custom provider directly to power user-centric functionality, such as the PeoplePicker.


Fixing that Annoying WebPart

Peace be upon you,

The problem is: Sometimes a developer may throw a Web Part that totally brings down a Web Part page. Brings it down to such an extent that the page won’t even run and you can’t even see the “Edit” menu to remove that offending Web Part.

Luckily, in order to fix the Web page, there is a back door to removing such really smelly Web Parts. Simply go to the following URL:


This page will present you with a menu to clean out these Web Parts from both shared and personal views.

I found this a really nice tip as I really suffered from such Web Parts bringing down the whole page.


PDF Icon in SharePoint 2010

Peace be upon you,

Here is a clean way for adding the PDF icon to be recognized by SharePoint document library and also by search results:

The post is also having links to information about how to index the contents of a PDF file with SharePoint search.

Also, you can understand from here how SharePoint is handling the file icons in general:

In case you wanted to get Icon URL for a file, here is comparison between SPUtility.MapToIcon and SPFile.IconUrl:

SharePoint Web Application Browser File Handling

Peace be upon you,

We faced a problem lately in playing swf files under SharePoint 2010 and I thought of sharing its resolution with you.

In Web Application General Settings,  There is a setting called Browser File Handling and by default it is set to strict. This causes additional HTTP headers to be injected which forces the browser to download the file instead of opening it.

Here is a screen shot by fiddler showing the added header which makes the swf file downloaded instead of being player:

By setting this option to permissive the response header added above is removed and the flash player is now played and not downloaded, here is a screen shot:

I think this is an important information as same thing will happen with other file extensions.