One of the cool things about working at NewsGator is that the software we write is insanely popular—a LOT of people use it. (Our customers are mainly Fortune 500 companies, but we have a lot of little customers too.) Since our software gets deployed to so many varied environments, we see a lot of different server configurations, and have learned to make no assumptions about SharePoint configuration. We’ve also seen a lot of things that can go wring with deployments. Even though I’m not in our support organization, we’re all involved in support when we’re deploying at major customers and things go south. So from experience, here are a few things that can go wrong with server farms, and how they can be resolved. Just about all of these configuration errors can drastically effect the deployment of custom solutions on the platform. (Are you hiring a SharePoint administrator? Throw your farm into one of these mis-configurations and see if the interviewee can identify it!)
Common SharePoint Configuration Errors
1. IIS mis-match. A web application was manually deleted from IIS but is still referenced in the SharePoint configuration (database). This is relatively easy to fix if you can identify the orphaned web applications. You’ll see failed deployment jobs when this happens.
2. A server on the farm is not available—it’s either missing or unresponsive. The symptom of this will be that a solution will remain in the “deploying” state. We’ve even seen customers “unplug” and repurpose a server from the farm without cleanly removing it! There seems to also be a bug where you can remove a server from the farm, but SharePoint still thinks it’s in the farm, and still deploys the WSP to that box in globally deployed WSPs. This is actually the most common worst-case scenario we’ve seen. It seems that large SharePoint environments are much more dynamic that you’d think these “controlled environments” would be! The fix is simple, but time consuming. Audit the Servers in Farm page in Central Admin and validate each server is up and validate the solution deployment on each server.
3. Clashes of the AJAX runtime by third party components. This can be common if you’re using controls from vendors that were written back in the MS AJAX 1.0 days, and you haven’t moved to the 3.5 SP1 AJAX bits. Luckily, a but of binding redirection in web.config will do the trick.
4. Unpatched environments. This isn’t too common, but we’ve seen a lot of deployment errors across farms that were fixed in the Feb (2009) WSS Update. We now require the WSS February Update or later, although I fully recommend SP 2 for both MOSS and WSS.
The moral of the story: as you grow your SharePoint farm, each server you add does add management liability. Make sure you’re up to the administrative cost before adding servers, and don’t add servers to the farm if you don’t plan on keeping them there.
While these seem simple enough, these configuration errors can stop deployments dead in their tracks. They can also be difficult to identify, so consider this your cheat-sheet!
