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

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"

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.