[SP ALL] Opening a web service is returning a 401.1 "Access Denied" error

[ISSUE]
Yesterday I was asked to assist in troubleshooting an issue with a SharePoint web service. The SharePoint indexing process failed to work properly for just one web application. Some investigation revealed that the indexer was unable to open the sitedata.asmx web service. When trying to open the same web service via IE, I was prompted for credentials however whatever credentials were entered, after three attempts an "Access Denied" page (401.1 error) was shown.

[SOLUTION]
Unfortunately Process Monitor didn't reveal anything and I noticed that the sitedata web service wasn't the only web service that failed. After some troubleshooting I found out that the cause was in the web config:

The "remove verb *.asmx" line was placed after the "add verb *.asmx" line in the httphandler setting, essentially removing the configuration after adding it. For example:

<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
....
<remove verb="*" path="*.asmx" />

After correcting this by placing the remove line in front of the add line, all web services started working just fine!

<remove verb="*" path="*.asmx" />
....
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

[EXPLANATION]
Why is this happening? By first placing the remove line, you make sure any declarations that are done in other (global) configuration files are made void. That way you know for sure that no conflicts will occur between two configurations. However after removing the asmx httphandler, you have to declare it again, else SharePoint (or better yet IIS) does not know how to handle the asmx file. The confusing part for this issue is that it will display an authentication prompt to the user, without it actually being an authentication issue.

[SP2010] Issue migrate Classic to Claims authentication

[SITUATION]
Currently I am working at a customer where we have to migrate SharePoint 2007 data to a new SharePoint 2010 environment. Security ACLs on the SharePoint 2007 data are registered in the old SharePoint 2007 way (called Classic in SharePoint 2010). In order to use claims these ACLs need to be converted into Claims ACLs.

[ISSUE]
On the TechNet site I discovered this article. Unfortunately when performing these steps (running a PowerShell script), it did not work. As with many issues, SharePoint doesn't give any clue what might be wrong :-(

[SOLUTION]
After some troubleshooting I remembered an issue I had back in MOSS2007. There I tried to perform an activity on a site collection, which did not work. It turned out that I did not have permissions on the site collection. To solve that, I granted myself "Full Control" permissions via the "Policy for Web Applications" page, after which the activity worked fine.

To test this theory, I tried the following steps:

1. Create a new web application
2. Create a new site collection
3. Add some data and set unique permissions
4. Grant my admin account Full Control permissions for the web application
5. Run the PowerShell script to migrate the web application to Claims

and see here, the script now runs just fine and migrates all Classic ACLs to Claims ACLs!!

[NOTE]
Microsoft has confirmed that there are some issues with the Classic to Claims migration. According to them, Service Pack 1 will include a tool which should be able to successfully migrate Classic to Claims. So either test your migration thoroughly or wait for SP1 (expected end Q2/beginning Q3)!!