I have a TFS 2013 system (with no updates) and am upgrading SharePoint from 2010 to 2013. The new SharePoint farm was up and running OK. It was constructed using  AutoSPInstaller as far as the July 2014 CU and then patched to the Sept 2014 CU and is running on Windows 2012 R2. It is a simple  farm, 2 web nodes and a separate database node, the same layout I used with 2010. I have also tried this with a single web node and there was no difference.

When I install TFS 2013 (without even configuring it) on any node in the farm if stops SharePoint from working correctly. By not working I specifically mean ASMX SharePoint services are broken for example http:://hostname/_vti_bin/Lists.asmx, the rest of SharePoint appears to be OK.

All the ASMX services return this error message...

startIndex cannot be larger than length of string.
 Parameter name: startIndex

I have narrowed down the cause to the install of the aspnetwebpages2.msi that is run by the TFS installer, which causes the problem. Installing that onto SharePoint node on its own causes the damage and uninstalling it does not undo the damage. There is no obvious issues reported during the installation or configuration only by explicitly connecting to an ASMX web service do I see the problem. The lack of functioning web services means TFS can not create new projects and its Team Explorer cannot connect to SharePoint which is how I first spotted the problem.

I rolled everything back as this was in a virtual deployment and was considered a show stopper.

This question was originally asked on the TFS Admin forum and they suggested raising it here.

Hello Mcaljamj,
 
Thank you for your question.

We are currently looking into this issue and will give you an update as soon as possible.
 
Thank you for your understanding and support.

Victoria

Forum Support

Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

Hi,

Thank you for your patience.

If we didn't use TFS 2013 and SharePoint works well, then i recommend that we need to check if we install and config TFS correctly. And check if there is any compatible issue for TFS 2013 and SharePoint 2013.

Best Regards,

Dats Luo

• Proposed as answer by Dats Luo - MSFT Friday, November 28, 2014 9:31 AM

Hi,

I am writing in to see if there is any update about this issue. Thank you for your time.

Best Regards,

Dats Luo

The TFS implementation has been running the 2013 version for over 1 year without issues and after the introduction of SharePoint 2013 again appeared to continue to function correctly with the exception of the piece that interacts via SharePoint web services. i.e. if I didn't have SharePoint in the TFS deployment then I would have no problems.

Also as the aspnetwebpages2.msi seems to be the cause of the break in the SharePoint services I am also not seeing how TFS in the broadest sense is the cause other than its install invoking aspnetwebpages2.msi as a sub-install.

After some time and building servers using 2008, 2012 and 2012R2 to track this down I found that the issue was with the alternate access mapping paths in SharePoint and claims authentication. I stumbled on it by accident when fixing a SharePoint 2010 deployment that had been converted to claims authentication and was experiencing intermittent and seemingly random authentication failures. When I changed (simplified) the AAM paths the problem with 2010 disappeared. That change was applied to the 2013 deployment and this fixed the the broken web service deployment.

• Marked as answer by Victoria XiaMicrosoft contingent staff, Moderator 6 hours 20 minutes ago