Sunday 21 October 2012

Set Passphrase for SharePoint 2010 Farm

The Passphrase, for your SharePoint farm, is required to add a new server to the farm.

If you have forgotten the passphrase then there is no method to retrieve or recover it but you can change it.

The passphrase resides in the SharePoint Configuration database and below are the steps to set/change it:
  1. Start SharePoint 2010 Management Shell from Start --> All Programs --> Microsoft SharePoint 2010 Products --> SharePoint 2010 Management Shell
  2. Write $passp = ConvertTo-SecureString -asPlainText -Force. This will prompt you for a string, which is going to be set as the new passphrase of your farm. The string is converted to SecureString, which is the expected type of the passphrase
  3. Next write Set-SPPassPhrase -PassPhrase $passp -Confirm. It will ask for a confirmation after which your new passphrase will be set.

Move/Change SharePoint 2010 Database Server

This, according to me, is a very possible and real -world scenario:

Your client (or your organization, for that matter) is planning to upgrade the databases, or the database architecture/topology and have come up with an entire new set of hardware which will host the databases and you are assigned the task of moving only the SharePoint databases to the new server.

Ordinarily, if this were a .NET application you would simply ask your DBA to backup/restore your databases and make changes to your connection strings in the config file and that's the end of that story. (Please note that I do not claim to be a .NET specialist and I apologize for hurting the sentiments of .NET developers if I have over-simplified the complexity of their task)

But, as I have said time and again "things are not that simple in SharePoint World"!

So, here's what Microsoft have to say about the method of achieving the database move from one server to another for SharePoint: SharePoint 2010 - Move all databases

In simple words, you need to apply an SQL alias to all your SharePoint servers in the farm, so that whenever a request for the "OLD" SharePoint Database server is sent from any SharePoint server it is redirected to the "NEW" Database server. Easier said than done!

To quote one of my colleagues - this is a very "weak" solution because -
  1. The reference of the old database server is never removed
  2. All logs and statistics mention  the old database server name.
To a person who has been newly introduced to the SharePoint farm and is debugging certain issue it is very confusing to figure out that the database server mentioned in the log files is just an alias and the actual database server is different. It could mess up his life and could potentially cause serious mental strain!

The other method is to re-create your farm and re-configure all services with the new database. Ofcourse, you would migrate the content of your Web Applications, residing in Content Databases, to the new server through backup/restores. Here is the link that sheds more light on this method. This is a possible solution if you are dealing with a small farm but if you have a multiple server farm with huge amounts of data residing in SharePoint, which has been crawled by the Search Services and User Profiles running into thousands then re-configuring all services might give you a nightmare.

I am going to concentrate on the former approach of applying aliases in this post. The steps to apply the alias and, therefore, effectively replace your database server are:
  1. Restore databases to the new database server
  2. Remove the SharePoint server from your farm
  3. Apply the SQL alias using cliconfg.exe
  4. Reconnect the SharePoint server to the same farm.
Below these steps are explained in detail, but before you do anything else, please make sure you have the passphrase for your SharePoint farm. The passphrase is required to re-connect the servers to the farm and if (like me) you had not initially setup your farm, there is very high possibility that you do NOT have the passphrase. Refer this post to set/change your farm's passphrase

Step 1 - Restore databases to the new database server -
  • Stop all SharePoint related services on all servers (except the database server) in your farm. Also, stop the IIS service on your WFEs. This is to ensure that no changes will be made to the databases while backup is in progress
  • Backup the SharePoint related databases
  • Restore to the new server
  • Start all the services

Step 2 - Remove SharePoint server from the farm -
  • Logon to your server
  • Run the SharePoint 2010 Products Configuration Wizard
  • Disconnect the server from the farm (please know the passphrase before doing this)
  • Let the wizard complete
Step 3 - Apply the SQL alias to your server -
  • Open command prompt and type cliconfg.exe and the return key
  • An SQL Network Utility will appear that will allow you to enter details of your alias
  • Click on the Alias tab and click Add
  • In the Network Libraries select TCP/IP
  • Write the old database server name in Server Alias and new database server name in Server Name text box.
  • Let the Dynamically determine port check box be selected (and select it if it is not already selected)
  • Click OK
  • Then click Apply and OK
Step 4 - Reconnect the SharePoint Server to the same farm -
  • Again start the SharePoint 2010 Products Configuration Wizard
  • Connect the server to an existing farm
  • And in the database server name provide the name of the OLD database server and select the configuration database name from the dropdown.
  • Enter your passphrase and continue through the next steps of your wizard to reconnect the server to the farm
Note that you will have to repeat steps 2 - 4 for each server in your farm.

Here is what happens next: If there are any configurational issues with any of your SharePoint services which have uptil now been suppressed, they will start surfacing after you have moved the database server. E.g. Search Topology, User Profile Synchronization etc. So, unless you claim to be a perfectionist at maintaining your farm, you will have to do quite alot of cleanup activity after your actual task is over. So, make sure you have taken a sufficient amount of downtime before you start this activity.


Monday 8 October 2012

Convert existing SharePoint Web Application from Classic mode to Claims mode authentication results in all users getting "Access Denied" error or only view rights of the site

Scenario -
I had an existing SharePoint site that I had created with Classic mode authentication (not a good idea!) and due to certain requirements which needed to be implemented in this site I had to convert the site to Claims based authentication. Though I do not "claim" to be an expert in configuring "Claims" authentication I was aware of the simple process of converting Classic mode authentication to Claims mode.

As is true in most cases, I had commitments to meet and converting the site to Claims mode seemed an easy bit and was at the bottom of my priorities. However, after setting up most pieces of my site (which had anonymous access enabled, by the way) when I converted my site to claims mode I was surprised to see that I could no longer access my site with full privileges except with "System Account". Luckily, since I had anonymous access I was able to atleast browse the site with my other admin users and what I saw is that the user names appeared as "i:0#.w|domain\username". With the System Account I checked for the permissions of the site and the permissions were as earlier, nothing had changed. But, still no access.

Solution -
Please take a backup of your web application before running any of these scripts (it is a good idea to take a backup before running any major Powershell script) as it atleast helped me save face.

First of all below is the powershell script to convert classic mode site to claims mode

$webapp = Get-SPWebApplication -Identity "http://serverURL"
$webapp.UseClaimsAuthentication = $true
$webapp.Update()

As mentioned above after running this script access for my users was altered (removed, rather). Here is what you need to do in addition. But make sure you have your backup ready. The script is as follows -

$webapp = Get-SPWebApplication -Identity "http://serverURL"
$webapp.MigrateUsers($true)

Thats it! Seems pretty simple but it took me around 10 hours of searching before I reached this solution (makes me feel pretty dumb if you reached here in 5 minutes).

Caution! Caution! Caution! -
OK! There was a reason I asked you to have a backup before running scripts. This is what happens when you run the above mentioned scripts:

On executing the first script (to enable claims authentication) the SharePoint Content Database is made ready for claims based authentication but the already existing site users, who in my case were windows users, are not "migrated" to be understood by claims authentication. But SharePoint assumes all users to be claim users and renders them so. Therefore, a normal windows user - "Domain\UserName" appears as "i:0#.w|Domain\UserName". Furthermore, it uses the username in this same format to check for its permissions but does not find a matching entry for the user as the database has windows users - "Domain\UserName". So, the site will give you an access denied or, in my case, anonymous access privileges.

Note that the System Account will work since it's "Domain\UserName" is never used and System Account is a keyword used by SharePoint for your application pool identity. Therefore, it remains unaffected.

To overcome this situation we use the second script to "migrate" the users. MigrateUser($true) will convert all user accounts to claims format. After running this script user accounts are converted in the database to claims format, therefore, user names are read correctly by SharePoint, therefore, permissions for users are associated correclty by SharePoint and therefore, the site permissions work correctly.

Something very important to note here is that ideally, MigrateUser($false) should convert the user names back from claims format to the normal format, but it does not do so. This script will throw an exception and no change will be made to the database - so once you are in claim mode you cannot go back. Please refer this post to revert from claim mode to normal mode. Also note that these scripts are running on Web Applications so they will affect all site collections in that web application

Lessons learnt - I feel, that if you are creating a new web application in SharePoint 2010 always use Claims Mode Authentication as it gives you flexibility and you can avoid wasting your time on "migrating" users back and forth. Probably that is the reason why SharePoint 2013 has done away with Classic mode authentication and has only Claims-based Authentication.

Friday 1 June 2012

SharePoint on Android/iOS Tablets

The tablet market is expanding by every passing day and honestly, the experience it has created for users is "Amazing". Tablets are here to stay and we have to adapt to this new device as soon as possible.

Being involved with SharePoint and sharing views of many SharePoint professionals, I think we have to start making SharePoint "Tablet-friendly". You would argue that SharePoint being a server-side technology, hosted on a web server can be browsed using the web browsers available in these tablets.That is very correct, but a SharePoint site browsed through a portable device gives very limited capabilities. Customers expect to leverage SharePoint to fully use the tablet experience. That is what will make them fully enjoy SharePoint's power.

There are various applications already available in the stores of Apple and Android powered tablets that can interact seamlessly with SharePoint and give users a rich experience. I have listed some of them below:

  1. Formotus
  2. SharePlus
  3. Mobile Entree
They offer quite different range of capabilities.

Also, you can create your own custom application using the following platforms:
  1. Phone Gap - It is HTML 5 based and uses HTML, JavaScript for application creation
  2. Mono - Makes the .NET libraries available over multiple platforms.

Monday 21 May 2012

Moving documents from one document library to another maintaining versions - SharePoint 2010


Hear is a simple task - Move documents from one library to another in SharePoint 2010 Document Library. Sounds simple! You can use "send to another location", "explorer view" etc. etc. But let me slightly complicate things here -

Move documents from one library to another in SharePoint 2010 maintaining all versions of the document in the new library.

Now, there is an understood pre-condition associated with this task that both libraries should have versioning enabled to the same level (minor or major).

What I found was that, when we use "send to another location" or any other OOB method to transfer the document from one location to another, versions are not maintained. They are simply forgotten. Reason for this is simple - at the new location, even though versioning is enabled, the transferred (moved) document is the very first version. In simple words, versioning is initiated at the new location only after the document is created there.

But as usual this was something I did not expect, because all my client asked is to move documents from location A to B and I very confidently agreed to do it in a few minutes time. And as a P.S. the client added that documents have versions and versions will be required at the new location. I thought - "That should not be a problem??"

Turned out I was wrong. I panicked and the first thing came to my mind was "custom code" and the pain it would cause to write all those lines, build, debug, test; build, debug, test; build, debug, test... you get the point.

But then, a little bit of researching gave me this quick solution -

All you need to do is open both locations (document libraries) in explorer view and cut and paste the files to the new location. Note that -
  1. Copy and paste will not carry your versions,
  2. Both location should have versioning enabled and
  3. Both libraries should have the same template i.e. document library --> document library or form library --> form libary and so on.
Really neat trick and saved a lot of my time. Huh! Can spend some time playing angry birds now!

Friday 11 May 2012

"I cannot delete this column from my list??" - Well that must be a SharePoint 2010 Peristent column

If  you are viewing this blog post I assume you have not had a very good day at work today! Here's a look at what happened to me -

I recently ran into a problem where one of my users added a site column called "Target Folder" to their SharePoint list and later realized that that column was not required. So the user wanted to delete the "Target Folder" column. That is the most basic SharePoint task that is there to be done and so I wondered that why is this user coming to me for something so trivial.

Alas! Everything in SharePoint is not what it seems. I went to the list settings clicked on the column and I could not find the delete button in fact I could not find any means to edit that column. What happened here? I checked some other columns (Had my farm gone crazy?) No! Every other column in that list (or for that matter in the site) seemed absolutely fine.

After a few hours of digging here and there I turned to Master Google and I was enlightened!

There are a set of site columns which are Persistent site columns and once added to a list these columns cannot be modified or deleted (through the SharePoint UI). Also, if you add these site columns to a custom site content type you will not be able to delete the site content type as well. On attempting to delete the site content type you will get an error stating - "The content type is in use and cannot be deleted" even though you have not used the content type anywhere.

Here is a list of site columns which are persistent:

  1. Active
  2. Aliases
  3. Article Date
  4. Byline
  5. Contact
  6. Contact E-Mail Address
  7. Contact Name
  8. Contact Picture
  9. Custom Router
  10. Image Caption
  11. Page Content
  12. Page Icon
  13. Page Image
  14. Priority
  15. Properties used in Conditions
  16. Property for Automatic Folder Creation
  17. Rollup Image
  18. Route To External Location
  19. Rule Name
  20. Scheduling End Date
  21. Scheduling Start Date
  22. Submission Content Type
  23. Summary Links
  24. Summary Links 2
  25. Target Audiences
  26. Target Folder
  27. Target Library
  28. Target Path
Be very sure before adding these columns to your list or content type.

To delete these site columns from your list you will need to do so by using PowerShell commands as follows:

$web = Get-SPWeb (Your site URL)
$list = $web.Lists[(Your List Name)]
$field = $list.Fields[(Your Column Name)]
$field.AllowDeletion = “true”
$field.Sealed = “false”
$field.Delete()
$list.Update()
$web.Dispose()

And.. I hope the rest of your day (if left) is nice!

There's a BUG! There's a BUG!! There's a BUG in the Discussion Board

This is something fishy!
Recently I was working with discussion boards in MOSS 2007. All seemed well. I had to create a simple discussion board with approval. "No big deal!", "That's non-IT stuff if you use SharePoint!"....... If this is what you feel you are in for a BIG surprise........ (just like I was :-) )
So I went ahead and created a Discussion Board, went into versioning settings, selected "Require Content Approval" and did a few test runs. Everything seemed to be working fine until I tested with different users.
Problem: User X writes a new post. This post goes for approval to User A. Until User A approves the post this post will not be visible to all the users. So the obvious thing to do is for User A to approve which he does but as soon as User A approves the post, User A's name starts appearing everywhere in the post viz-a-viz in the quoted text section, the picture of the person who started the thread. And poor User X who actally started the post is lost.
Reason: Now, when User A approves the post, he/she becomes the user to last update the post i.e. the modified by column of the post is updated to User A. And it so happens that in the flat or threaded view of a discussion the name of the user who last modified the post is displayed. But in our "content approval" case it sends a very wrong message. If you go back to the subject view to see the entire list of threads you see that the User X is still the creator of the post.
Now what: I had posted a question on MSDN forums, this is the link. I was not too satisfied with the answer. It stated to write an event receiver to update the modified by column of the post back to the created by column..

I wish there was a better way.... 

Copying Multiple User Field from one SharePoint List to another


So once again I landed up in trouble because of the Person or Group field (Multiple Selection). Refer earlier post.
Now, this time what I needed to do is I simply needed to copy a Person or Group field with multiple selection enabled to another such column in another list, through an Event Receiver.
You might think - "Why is he writing an event receiver?? Why can't he just use a simple SPD Workflow??"
But as usual.......... there is a catch!!
I have created a SharePoint site with Forms Based Authentication (FBA). My users no longer come from the Active Directory, they come from an SQL Membership API database.
And.... SPD Workflows run under the OWSTIMER.EXE service not the w3wp.exe service.
(For general information the w3wp service is created by the IIS and is used to handle web requests coming to a web server. The OWSTIMER service is created by the Windows SharePoint Timer Service and is used to execute scheduled jobs of SharePoint.)
So, since the SPD Workflows run under a different service, they cannot read the web.config placed under the IIS Service, therefore, they cannot read the Membership API database settings, therefore, SPD Workflows cannot identify FBA users.
So, I write a little bit of code to perform the task at hand i.e. copying multiple users from one column to another (using event receiver).
But again..... things are not as simple as you think. I write this line of code:
oDestinationList["MultiUser"] = oSourceList["MultiUser"];
here
  • DestinationList is Destination List object
  • SourceList is Source List object, and
  • MultiUser is the name of the field
but this simple line of code doesnt work. It states that the source and destination objects are not of the same type and cannot copy code!!!! Why????? I have no clue!
On googling I found a long procedure for copying multiple user fields: Create a SPFieldUserValueCollection object and append user names in this object etc.etc..... thats too much work...
So, on doing a little bit of research I found that there IS a simpler way of achieving this. Here's the code:
oDestinationList["MultiUser"] = Convert.ToString(oSourceList["MultiUser"]);
and it worked!!!! Hurray!!!!
Really SharePoint is funny!! :)

Send E-Mails to SharePoint Multiple User Field SPD Workflow

I faced a recent problem whilst designing declarative workflows in SPD 2007:
It sounds pretty simple - I needed to send mails using the Workflow to users who were stored in a Person or Group field.
You might think - "What's the big deal in that??".... But here's the catch. The Person or Group field I am referring to allowed multiple user selection.
==Bam==
All hell broke loose. How was this possible??? The Person or Group field just doesn't show up in the Workflow lookup! What do I do? Will I need to write an event receiver? Ohh!!! I didn't want to write code here? It seemed so simple. But wait..... lets try to fool SharePoint.
OK so first I do not allow multiple user selection in my Person or Group field. (You might think what about the already existing records? Data loss! Ya I know.... you might have to do this the hard way - Create a template for your list including content, recreate your list using the template you just created and after finishing all the steps mentioned here add all the entries again..... I told you this was the hard way!)
OK continuing with fooling sharepoint...... now, on preventing multiple user entries my Person or Group field starts appearing in the Workflow lookup for sending mails.
I complete my workflow steps, go back to my list and again allow multiple user selection in my Person or Grop field.
Now lets check whether the workflow is giving any errors.....
No......... no errors! Congratulations! SharePoint has been fooled! (Now can re enter your entries as I had mentioned above)
Happy SharePointing! :) 

Blogs about SharePoint

Hi All,

I have created this blog exclusively for recording my experiences with SharePoint.

This is only a subset of my blogs. You can find all blogs at My Blog