Wednesday, January 11, 2012

401 SharePoint Designer Connectivity Issues

How Many Times Must I Log In!?

SharePoint Designer 2010 is definitely a huge improvement over 2007. It’s free and has a ton of enhancements to make customizing a SharePoint install easier than ever.
It IS however, just as difficult to troubleshoot as the previous version when things go wrong. This is mainly because almost everything SharePoint Designer 2010 does happens over a web service. This means that a lot of the errors that you tend to get back (if you get any at all) are cryptic, and troubleshoots can be prolonged.
The other day one of our developers was trying to do some edits to a local SharePoint 2010 dev farm via SharePoint Designer 2010 and was having some issues logging in.
The user was a site collection administrator and every time they entered a correct credential, they were prompted to enter it in again (and again).
In addition when running Fiddler to inspect the login traffic, the log was full of authentication attempts to the login service (/_vti_bin/shtml.dll/_vti_rpc) but all returned 401 http status codes (unauthorized). There were no relevant events in the Event Log or in the SharePoint logs (14 hive\Logs directory).
Normally (if accessing it via a host header), we’d assume this has to do with IIS loopback checks, but this wasn’t the case. After a lengthily troubleshoot we found out that the behavior actually had to do with a change we’d made to the web.config.
As it turns out, when you enable ASP.NET tracing, you’ll no longer be able to login via SPD. We had the following line in our web.config.
    <trace enabled="true" requestLimit="40" localOnly="false" />
After we removed this line, we were able to login. We’re still digging around trying to discern how the two are related, but in the interim I’m hoping this saves someone out there some time.
HTH Someone,


Andrew Tappert said...

Ugh, nice find

e signatures said...

Wonderful informations here ! Did you search for and discover these on your personal or is there a supply link I can go to verify out other people.

Unknown said...

I have encountered a similar issue only in my case it was Riverbed Appinternal agent causing the culprit seeing a double hop in the IIS log. Also previous issues with the SCOM APM agent that broke sharepoint.
Basically anything that does packet inspection can cause issues with webservices giving 401 errors also removing the agent solved unable to publish infopath forms as it makes use of the same webservices and extensions.

Melissa Falbo said...

Hi there! Nice stuff, do keep me posted when you post again something like this!Click here

Mehak Shaikh said...