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.

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.

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.

Spain - First Consecutive Euro Champs

Spain have done it again!

Just a couple of days back Spain created football history by becoming the first team ever to successfully defend their Euro title; and they defended it by the best ever win margin in a Euro final - a 4-0 thrashing of Italy. And the second team to win three major titles in a row - Euro 2008, World Cup 2010, Euro 2012 - after Argentina.

If you go 4 years (and a few months) back Spain had never won the World Cup and had won Euro just once that too way back in 1964. Going by titles this is the best ever Spanish team and possibly the best team of all times.

Though it was an expected result I was hoping for a little more enthusiasm from Italy. Italy's superstar, after the semi-final with Germany - Mario Balotelli, hardly posed a threat to the Spanish defense and the usually awesome Gianluigi Buffon was clueless. In the semi-final against Germany the ball seemed to have a magnetic attraction with Buffon; it hardly missed him to reach the nets, but the final seemed to be the "polar" opposite.

Though, I don't mean to take anything away from the Spanish attack. It looked like the attack of the World Champions that they are but I feel Buffon is an exceptionally talented goal keeper.

But the bottom line is Spain are Euro Champs once again and serious contenders for the World title in 2014.

Well done Spain!

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.

Miracle of Syedna Mohammed Burhanuddin (TUS) - 2 - Personal Experience

My experiences might not apear like miracles, but the way these events have occured in my life they are certainly miracles for me. This is what happened:

My family and I had come to know that my wife was pregnant; as with any parent there was a great deal of excitement, tension and preparation going on...

But sadly, our happiness was short lived. We had gone to the doctor for a check up and we came to know that the baby had moved down and was close to being aborted. My wife was advised to be admitted to hospital and we had the following options:
 1. My wife had to undergo an operation to prevent the child from moving further down, or
 2. Abort the child.

The doctor had said that even after the operation my wife would have to be on complete bed rest until the delivery. And all this also did not guarantee that the child will be born safe and chances of abortion were still very high. The greatest risk was that the child might have to be aborted during the operation if something should go wrong.

We did araz of the same in Huzurala (TUS), Moula bestowed benediction and gave raza to undergo operation and not abort the child.

The operation was performed the next day. It went on for around 45 minutes (which appeared to be longer than forever). I was outside the operation theatre for some time but later went for ziyarat of Syedna Taher Saifuddin. No sooner had I stepped out of the roza complex that I got a call from my father-in-law that the operation was successful. I was happy but this was just the first step.

It is difficult for a person to take complete bed rest even when they are suffering from some physical disability, imagine a bed rest for 7 months by choice!

But, it was surely the dua mubarak of Aqa Moula (TUS) that my wife was positive and patient throughout her bed rest. She could only get up from bed when she had to go to the doctor for her check-up.

The doctor had called us 5 weeks after the operation for the first check-up. As scheduled we took an appointment and met with our doctor after 5 weeks. She examined my wife and said that "It is truly a miracle that your baby has survived. I did not expect this. I thought that you will come after 2-3 weeks to abort the baby as there were very minimal chances of survival."

After hearing this we, as well as the doctor, expected that the baby might be born a little premature in the 7th month. We repeatedly did araz in Huzurala (TUS). It was only due to the dua of Aqa Moula (TUS)  that I was gifted with a son. He was born in the 9th month, though he was underweight at birth, but healthy.

I along with my family araz sajadat of shukr in the hazrat of Aqa Moula Mohammed Burhanuddin (TUS) for this very dearest of blessings. And guess what my son's name is - Burhanuddin!

And finally, I thank my wife for having the patience and courage to go through those tough times. She just gave a demonstration of how strong women can be!

Also, I would like to thank Shaikh Shabbir Najmi for doing all our araz.

May Allah ta'ala  grant a long, healthy and prosperous life to Syedna Mohammed Burhanuddin till the end of time. Ameen!

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

Here 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!