The request failed with HTTP status 401: Unauthorized

I recently implemented a SharePoint farm with Reporting Services installed on a remote server in SharePoint Integrated mode. After configuring everything and uploading a report a document library, I received the error "The request failed with HTTP status 401: Unauthorized" when I tried to manage the report subscriptions from a client machine. I was able to access all the Report Server functions as long as I was on the server itself, but as soon as I moved to a client machine - no luck.

Research indicated that the proper solution was to enable Kerberos and make sure that the servers and accounts invloved were setup properly for delegation, and that the correct SPN's existed. For a variety of reasons, this was not possible and I needed to find a way to resolve the issue outside of Kerberos.

The work around was to configure the Reporting Services integration in Cemtral Administration to use a Trusted Account rather than Windows authentication. Here's the steps needed to accomplish that:

Open Cntral Administartion and click General Application Settings:

 Next, select Reporting Services Integration:

Next, change the Authentication mode from Windows Authentication to Trusted Account. Enter credentials of an account that is an administrator

User Cannot Approve Task - Access Denied

I created a SharePoint Designer workflow that assigns an approval task to a user when a list item is created. I began receiving reports that users were receiving the task emails from SharePoint, but when they attempted to approve or reject the task they received "Access Denied" .

Further troubleshooting showed that they had access to the task library, and could see the tasks, but they could not open any of their tasks. I broke inheritance and gave the users "Full Control". This did not resolve the issue.

I found mentions on the webthat publishing the workflow files to the local file system resolved this issue. As crazy as it sounds, this resolved my issue. Here are the steps I took:

Open SharePoint Designer and browse to the workflow in question. Right click on the workflow and select "Publish Selected Files"

Select the radio button labeled "Local File System", and browse to any area on your local drive:

If you receive a dialog stating that no website exists and asking if you wish to create it, click yes. Allow the files to be copied to your local drive.

At this point, my users were once again able to approve their assigned tasks.

SharePoint 2010 Alternate Access Mapping

I recently got tripped up while setting up Alternate Access Mappings on a test server I was using for development.

I built a Share Point Foundation farm using the default as the default URL. I needed to mimic a client environment to use "TheHub" as the default URL for demonstration purposes.

I followed the step by step instructions found on TechNet for accomplishing this, (Located Here), but I was still unable to browse my site.

Here are the high level steps for accomplishing this task:

1. The first step is to disable the loop back check on the server. In my case, this was a test server, so I was doing development and browsing the site from the server itself. Until you disable the loopback check, you will not be able to hit the site successfully with the new URL. I used method 2 located here.
2. Next, Open Central Administration /Application Management/Configure Alternate Access Mappings and create a new internal URL as described here.
3. The next step, and the one I neglected, is to open the hosts file located at C:\Windows\System32\drivers\etc and add an entry for 127.0.0.1 and point it to the new URL. You'll need to open Notepad with 'Run As Administrator' permission in order to do this. For more information on editing the host file, check out this article: Creating Entries in the Hosts File.
4. The final step is to go back into Central Administration /Application Management/Configure Alternate Access Mappings  and select "Edit Public URLs" from the menu, and swith the entries so that the new URL is in the default text box and the servername entry is in the intranet text box and click Save.

This will insure that SharePoint uses the new URL as the default URL; otherwise alerts and other emails will go out using the servername instead of the desired URL.

Could Not Find Feature TransMgmtLib

Recently I had to move a client from MOSS 2007 to SharePoint Foundation. There were several problems that I encountered in this process. Microsoft provides few paths for downgrading while moving to a new version.

One the the errors I encountered was "Could Not Find Feature TransMgmtLib" when importing a site. This error occurs when the MOSS site you are moving had features installed that the SharePoint Foundation installtion does not.

I resolved this issue by the following process:


You will need to install the following features in your SharePoint Foundation farm:

1.SlideLib

2.TransMgmtLib

3.RelatedLinksScopeSettingsLink.

4.BaseWeb

5.ReportListTemplate

6.Dataconnectionlibrary

7.BizAppsListTemplates

8.PremiumWeb

By default, SharePoint Foundation does not have the above listed features. You will need to copy them from MOSS to SharePoint Foundation. You will find the above mentioned feature on MOSS server in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES folder.

Copy the feature to the following folder on SharePoint Foundation Server:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES

Once copied, you can install all these feature using the following command.

Stsadm -o installfeature -name  –force

Example:  stsadm -o installfeature -name slidelibrary -force

Splitting Sites Into New Site Collections

Part of the my current migration effort consists of taking our existing 2007 farm and upgrading it to SharePoint 2010. Given that our current SharePoint 2007 farm consists of a single site collection and content database, one of my objectives is to split out some content into it's own site collection and corresponding content database.

Here, at a high level, is how I did that.The process is farily simple and straightforward:

1. Export the selected content to a directory on the local file system using the stsadm -o export command.
2. Rename the existing web that was just exported using stsadm -o renameweb.
1. I renamed mine by appending _OLD" the the web name.
2. This will ease deleting content later.
3. Create a managed path in Central Administration to reflect the desired managed path for the new site collection.
4. Create the new content database in Central Administration.
5. Temporarily set the pre existing content database to "Offline" in Central Administration.
1. This will force the new site you are about to create to be created in the new content database.
6. Create a new top level site at the desired url, using the newly created managed path using stsadm createsite.
1. Since this is the top level site for your new site collection, you'll need to include the -owneremail and -ownerlogin flags in the command.
7. Import the content of the directory on the local filesystem into the newly created web using stsadm -o import.
8. Delete the original web and subwebs using stsadm -o deleteweb.
9. Open Central Administration and set all content databases to 'Ready'.
10. All new subwebs created under the new site collection will be placed in the new content database. Any new subwebs created in the original site collection will be placed in the original content database.

At this point you should be able to navigate to and successfully view the content you have split off into it's own site collection. Another check is to examine the size of the newly created content database in SQL Server. It should now reflect the size of the data that was imported into it.

One final step is to make sure that the "Manage Content and Structure" option is visible under Site Actions on your new top level site . If it is not listed, you'll need select Site Settings at the new top level site and activate the following features:

• Site Collection Features: SharePoint Server Publishing Infrastructure
• Site Features: SharePoint Server Publishing

Once these features are activated, "Manage Site Content and Structure" will now be listed under Site Actions on the top level site of the new site collection.

An unhandled exception occurred in the Silverlight Application

I was getting "An unhandled exception occurred in the Silverlight Application" when I tried to create a new site in my new SharePoint 2010 farm. I was unable to create even the most basic blank site.

Thanks to Simon Carpentier at SharePoint Overflow, I was able to resolve this issue.

To resolve the issue, you need to go to Central Administration/Application management/(Select the web application)/General Settings/Set Web page Security Validation to "On"

$Resources:DataSourceContentTypeName Error

After upgrading my SharePoint 2007 farm to 2010, when attempting to create  new site using a custom site template I received the error: "The content type name '$Resources:DataSourceContentTypeName;' cannot contain: " as shown below.

After many hours spent attempting to decipher log file entries, Googling, and researching, I zeroed in on the fact that I had a Reporting Services content type that seemed to have been corrupted in the upgrade process.

In 2010, the content type displayed as:

In 2007, the content type displayed correctly:

What was happening is that when I attempted to create the new site with the custom template, it was attempting to activate the corrupt content type. The solution to this issue is to simply delete and recreate the corrupt content type; but this is easier said than done.

Here is the process I used to resolve the issue.

Before a Content Type can be deleted, you must first remove it from every place it is being used. I found the easiest way to identify content type usage is to use the excellent tool SharePoint 2010 manager. This is a truly excellent tool. I was able to identify every place the offending content type was used quickly and easily, and remove it.

Once the content type was no longer being used, I was still unable to delete the content type. I would receive an error stating that the content type was "part of a feature" and could not be deleted.

The next step was to uninstall the feature, which I determined to be the "ReportServer" feature. Here's where it gets tricky. You must do things in the correct order to resolve the issue. The steps, and the order to perform them are:

• stsadm.exe -o deactivatefeature 
• stsadm.exe -o uninstallfeature -force 
• stsadm.exe -o execadmsvcjobs 
• stsadm.exe -o installfeature
• stsadm.exe -o activatefeature

This will properly deactivate, uninstall, reinstall and activate the feature. Once this process is complete, your content types should display correctly, and not as $Resources:........

At this point you've cleaned up the corrupt content type. However, you still cannot create a new site with your custom template because the previously created template still references the old corrupt content types. You need to now create a new site template. The new template will be clean, and there will be no trace of the corrupt content types.

You can now create a site with the template.