Skip to content

May 25, 2010

IndyTechFest and Professional SharePoint Development

This last Saturday I had the pleasure of spending some time with about 40 folks to talk about Professional SharePoint Development at IndyTechFest. It was a sort of ad-hoc presentation because I forgot to update the title when I updated the abstract. As a result some folks were wanting to see SharePoint Site Lifecycle and others were wanting Professional SharePoint Development.

The Professional SharePoint Development part of the talk was focused around my work on the 10232A course for Microsoft Learning. The course it titled “Designing Applications for Microsoft SharePoint Server 2010”. I had recently delivered a train-the-trainer session for MCTs and used that deck as an outline for our conversation. It was a lot of fun talking about the decisions that professional developers need to be aware of. A lot of what we talked about can be found in our work in progress for the Microsoft Patterns and Practices SharePoint Guidance Version 3 (You can find our previous guidance on the Microsoft web site at

I also got to cover some of the SharePoint Site LifeCycle – Creating and Archiving Sites deck that I’ve used at a few conferences. It’s a lot of fun to deliver that deck as well because we get to talk about how workflows can be used to make light work of the challenges of both provisioning and archiving sites. Along the way, I address the need for a replacement site directory since in SharePoint 2010 the site directory has been depreciated.

Overall the event was great with several hundred people and flying boomerangs … If you’re local to Indy you’ll want to make sure that you come next year. It was a great time.


Bad SSL Certificates and Browser Woes

I was troubleshooting some relatively minor SSL changes that had reportedly worked before but no longer worked. After switching back to old certificates and it still didn’t work I was mystified. It looked like it was working. I could telnet to the port so I knew that HTTP.SYS/IIS was answering. However, the browser refused to return anything on HTTPS.

I ended up breaking out Network Monitor 3.3 and getting a capture. What I saw in the packet capture was odd…

  1. ARP for the target address. (Good we’re starting from scratch)
  2. TCP connection negotiated (Good, we have a channel.)
  3. SSL Negotation and Key Exchange – with a TCP FIN flag set. The FIN flag is “I’m done let’s close this channel.” (This isn’t good. We shouldn’t negotiate and then turn around and close the channel.)
  4. Steps 1-3 repeated except instead of a FIN flag I see a TCP RST flag. That’s a “I’m not talking to you any more – go away” In other words, the connection is terminated abruptly. (This is really bad. This is the point at which the client knows there’s something horribly wrong.)

After some work we realized that the SSL certificates were self-signed and there was something wrong. We moved to a certificate from a CA and the servers started accepting connections on SSL without any more issues. I’m not clear exactly what the heck the problem was with the certificates, but replacing them definitely resolved the issue.

HTTP 400, Kerberos, Bad Request, MaxTokenSize, TokenSz

We turned on Kerberos for a client this past weekend and one of the gifts that we got was that some of the users couldn’t log into the portal. Other users weren’t able to post a form to the server. They would get a HTTP 400 Bad Request.

Initially it was thought that the Kerberos ticket might be getting larger than the MaxTokenSize (See KB327825). After I chatted with my friend Laura Hunter I was pointed to the TokenSz utility. It will show you the token size of the current user. With this information I found that for the most part the users had token sizes of ~3K. One user had a token size of 8194 bytes. So knowing that the token sizes were much smaller than the 12K limit that MaxTokenSize defaults to I had to do some more digging.

Ultimately, I found that HTTP.SYS has a smallish default buffer size for incoming requests and large Kerberos tickets can actually exceed the available size for this buffer. Luckily KB2020943 shows you the registry settings you can change to increase the buffer size of HTTP.SYS. There’s a reboot required after the change but after that the users were able to login. For our environment we felt like a MaxFieldLength of 25K was plenty of headroom for our needs.

Recent Posts

Public Speaking