I hear a lot of stories that start off with “We were going to use InfoPath for this project but we couldn’t get it to work so we had to do it all as .aspx forms”. Frankly, if I were not so stubborn I would have the same stories. At first glance InfoPath seems like a great solution, then you start to get under the covers a little bit and it becomes more and more frustrating. You end up having to purchase a code signing certificate, open the form up to Full Trust, write Code Behind, etc… and every time you add something else you have to go through the learning curves of any quirks that might exist.
The latest quirk we ran up against is accessing the getUserProfileByName method of userprofileservice.asmx. Hey, it worked great on our VM! So, we go to deploy our InfoPath form on our Dev Farm and we start getting 5566 errors accessing the web service. We have not a clue why. The log says that our certificate may be invalid (our Dev, QA, and Prod farms use SSL). So, we get our infrastructure guy on the phone and he tells us that the farm cannot access the CRL (Certificate Revocation List) to determine if the certificate is valid or not. He has us open up the server to the internet (Our servers do not have random internet access) and hey! what do you know! Everything works fine and dandy. Yes.. I used the word dandy.
So, we go to deploy our form to our QA farm so users can start testing and what do you know… 5566 errors again. We were expecting it this time though, so we give our servers internet access and… what?? 5566 errors? it still doesn’t work? But it worked before? Frick! After reviewing our logs in the 12 hive we discovered we were now getting a 401 error when accessing the web service. REALLY?? We could browse directly to web service, what’s the deal?
After HOURS of searching online I once again resorted to twitter… are you using it yet? Anyway, fairly quickly I get a response from Keith Dahlby and the man himself Todd Klindt (I know how you girls ooh and ahh over his Netcasts). They both asked me if I tried the “disable loopback check” fix. Huh? what’s that? Glad you asked! Here’s Todd’s blog about it:
Can’t crawl web apps you KNOW you should be able to crawl
After reading Todd’s blog and the KB I was not real excited. This is not really the problem I’m having, but hey, I’ll try anything at this point. SO! I follow the KB instructions, disable the loopback check and guess what happened?
It fixed our problem! Not only did it fix the new 401 error on our QA farm, it also fixed the original 5566 error on our dev box meaning we did not have to punch a hole in our firewall to access the CRL. I was pretty stupefied (not that hard to stupefy me actually). Like I said, this KB did not specifically address our problem, but it ended up fixing it. It makes sense when you dig a little deeper.
So, let’s bring the blog back full circle, my conclusion is this: Don’t give up on InfoPath just because you run into lots of hurdles. Fight through them, learn from them, and take advantage of what InfoPath has to offer. In the long run it will save you a ton of development time and you can eventually push off all the InfoPath work to your junior developers and you can concentrate on what you really hate about SharePoint. :)