OK gang –

The SBS team has blogged explaining where our 2436 errors come from on SBS 2008.  The short story is that SBS is thinking it is protecting itself.  Recommended solution is to edit the registry to add the public URL for your companyweb (e.g.  remote.company.com) to the BackConnectionHostNames, allowing that URL to bypass your SBS server’s loopback check.

Google searches will result in a multitude of work-arounds different people have posted, most of them you do not want to implement including:

  1. Disabling the loopback check all together.
  2. Tweaking the Alternate Access Mappings in SharePoint (unless you need to for other legitimate reasons – not the 2436 error)
  3. Changing your companyweb’s security zones in SharePoint (remote.company.com should be the Default zone, with companyweb in the Intranet zone).

If you’re like me and subscribe to the idea of least privilege access, you can still update the SharePoint search configuration as mentioned in my previous post.  Most built-in accounts (e.g. NETWORK SERVICE, LOCAL SYSTEM, etc.) have more permissions than required to perform SharePoint search functions.  Creating standard user accounts to do the SharePoint Search work follows the general best practices of least-privilege access.  While this follows SharePoint best practices in not using built-in accounts for the SharePoint search service or search content access accounts, it is important to note that editing the SharePoint search configuration on your SBS 2008 has not been tested by Microsoft and therefore is not officially supported.  This doesn’t mean it won’t work (my SBS 2008 boxes are running this configuration without issue so far) – it just means that if it doesn’t work, Microsoft isn’t going to support the configuration.  So if you want to keep in the fully supported realm, leave the SharePoint search configuration as-is.