Moving SharePoint with Reporting Services (SSRS) to a new server

Imagine you want to move your SharePoint installation to a different server (i.e. server with a different name). You can do it simply by installing a new SharePoint on the server and restoring content databases. If you were running SQL Server Reporting Services in SharePoint integrated mode, the reports stored inside SharePoint won't be working anymore. Here is the fix:

1. Stop Reporting Services service on the server hosting the reporting services
2. Update path references in Reporting Services database:

UPDATE [ServerParametersInstance] SET [Path] = REPLACE([Path],'http://old-server','http://new-server')

UPDATE [Schedule] SET [Path] = REPLACE([Path],'http://old-server','http://new-server')

UPDATE [Schedule] SET [Path] = REPLACE([Path],'http://old-server','http://new-server')

UPDATE [Catalog] SET [Path] = REPLACE([Path],'http://old-server','http://new-server')

3. Start Reporting Services service again

Don't forget to replace old-server and new-server tokens with your values.

Back from New Zealand

Just returned from New Zealand. We had a wonderful time in this amazing country of wine, mountains, wild rivers and rain forests... and if you're into rock climbing and bouldering as I'm then Castle Hill is the place you must not miss...

All pictures taken by this amazing photographer

Barcodes generating web handler as SharePoint solution

I'm just working on the project where I need to generate barcodes and display them inside SharePoint. I needed some component which would generate these barcodes and  I wanted it as SharePoint solution (wsp file) which would make the deployment easier and administrator friendly. I decided to develop a web handler (ASXH file), all you need to do is to call the web handler and pass all information (i.e. barcode data)  as URL parameters.

Here is the example of generated barcodes:

Visual Studio 2010 project is available here. You'll need WSPBuilder extension  to create the wsp package and Free 3 of 9 font installed on the server or dev machine.

How to display Exchange calendar (shared resource) in SharePoint 2010

One thing that I really missed in SharePoint 2007 was a deeper integration with MS Exchange, specifically the ability to display shared resources (e.g. conference room, projector etc) as a calender. This is actually a quite common requirement and almost every client running MS Exchange is asking me for this type of integration. So what's new in this area in SharePoint 2010?

SharePoint 2010 comes with a revamped calendar list, you can now add up to 10 other calendars as overlay layer so the result is one calender view displaying data from several calendars:

When adding overlay calendar you can choose from two calendar types: SharePoint and Exchange.

And here is the catch. You can add Exchange calendar... but ONLY ONE... and ONLY YOURS! If you try to add another Exchange shared resources, you'll get either some weird permission errors or the calendar will be empty. Unfortunately this SharePoint feature is poorly documented so I raised Microsoft Support ticket and after more than one month I got my answer from Microsoft Specialist:

Our technicians think the “Calendar overlay” solution was never intended for Exchange resources or multiple user calendars. It was intended only for multiple SharePoint calendars.

So why the hell there is the option to add Exchange calendar?

Anyway if you were trying to integrate SharePoint with Exchange, this is not a way. The only solution would be a custom development. Hope this will save your time.

Domain name, NetBIOS name and SharePoint User Profile Service

One month ago I was installing SharePoint for one of my client. After the installation I went to Central Administration, configured the user profile import from AD and then started a full synchronization job. When the import was completed, I checked which users were imported and found out that login names in imported user profiles where different from login names used by users to log in to SharePoint:

• User login in User Profile service: contoso\user1
• Actual user login used by user1: contoso.com\user1

It's obvious there's something wrong. At this situation SharePoint is not able to match SharePoint user with his/her user profile because the user login is "primary key" used to locate the user profile. It means you can't use My Profile page, you can't use information in the user profile like the manager field and job title in workflows etc. 

So the question is what is the problem? What we can do to prevent this from happening?

The problem lies in NetBIOS name. Usually the domain name looks like contoso.com and NetBIOS is then contoso. In this case both NetBIOS name and fully qualified name were the same: contoso.com. For some unknown reason (bug?) when SharePoint imports users from AD it trims everything after the first dot. I was consulting it with Microsoft support specialist and his advise was... to rename domain and NetBIOS name. Yes, RENAME domain and NetBIOS name. Wow!

So what is the lesson learned? Never use dots in NetBIOS name... and  always check NetBIOS name before installing SharePoint. You can do it easily with nbtstat -n command.

How to back up SharePoint with Backup-SpFarm PowerShell command

The first you need to know is what components you can back up. You can list all SharePoint components available for the backup in the hierarchical tree format by running the following PowerShell command:

Backup-SPFarm -ShowTree

The result should be something like this:

OK, let's say I want to backup my web application on port 80 which was named SharePoint Intranet - 80 together with all components under this node:

Backup-SPFarm -BackupMethod Full -Item "Farm\Microsoft SharePoint Foundation Web Application\SharePoint Intranet - 80" -Directory "\\MySP2010Server\BackupDirectory"

For full description of all parameters see the Microsoft technet: http://technet.microsoft.com/en-us/library/ff607881.aspx

After backup is completed, go to Directory folder. There should be a new directory with many backup files and one spbackup.log file. If everything went well, the file should contain the following messages at the very end of the file:

[6/04/2011 10:25:12 PM] Finished with 0 warnings.

[6/04/2011 10:25:12 PM] Finished with 0 errors.

[6/04/2011 10:25:12 PM] Backup completed successfully.

[6/04/2011 10:25:13 PM] -------------------------------------------------

Now when we have PowerShell script which is working, next step is to create a scheduled task so you can run a back-up on regular basis. To do this, create a text file with PS1 extension and copy & paste the following line.

Add-PSSnapin Microsoft.SharePoint.PowerShell

The second line should the actual PowerShell back up script, in my case:

Backup-SPFarm -BackupMethod Full -Item "Farm\Microsoft SharePoint Foundation Web Application\SharePoint Intranet - 80" -Directory "\\MySP2010Server\BackupDirectory"

Now you're ready to go to Task Scheduler and create a backup scheduled task using the script file you just created.

The most common issues you're probably going to face are:

• Operating system error code 3 (The system cannot find the path specified)

You'll run into this error if you specify the local path in Directory parameter (e.g. c:\Backup). The reason is that SharePoint delegates the content database backup to SQL Server which is probably located on different server and the back up directory doesn't exist on that server. That's why I use UNC path together with a share folder.

• Operating system error code 5 (Access denied)

Actually this error is related to the previous error and this time the problem is permission related. As I said before a content database backup is delegated to SQL Server and it means that SQL Server (e.i. account running SQL Server service) needs to have the write/modify permission on the folder specified in Directory parameter. So check the folder permission and update it if needed.

• Database permission denied error

The account you're using for the back up has to have backup rights . If it doesn't, the backup will fail. You can use either SharePoint farm account or you can create specific account just for this purpose.

Be careful when installing Office Web Apps

Last week I've been installing Microsoft Office Web Apps for my client. The client is running  rather smaller farm with 1 WFE server and 2 application servers.

After running installation packages on all servers I went to one site and what was my surprise... I got Internal Server Error 500.

In few minutes I found out that installation corrupted ALL web.config files of ALL SharePoint web applications, specifically it duplicated staticContent tag so it looked like this:


    <staticContent>
        <mimeMap fileExtension=".atomsvc" mimeType="application/atomsvc+xml" />
        <remove fileExtension=".svg" />
        <mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
    </staticContent>
    <staticContent />
</system.webServer>

When I removed the duplicated tag, the site started to work again. However I had to update 15 web.config files (5 web apps, 3 SharePoint servers). This could be a serious problem if you are running middle-size or large-size farm with tens of web apps.

This is just another reason why web.config files should be a part of your SharePoint back ups.

How to change Authentication type of the existing SharePoint web app?

When you create a new SharePoint web application in Central Administration you can choose from Classic Mode and Claim Based Authentication. After the application is created there is no way how  to change it in Central Administration. Nevertheless you can still do it in PowerShell:

$app = Get-SPWebApplication [web app url, e.g. http://portal]
$app.UseClaimsAuthentication = "True"
$app.Update()

That's all!