Monthly Archives: August 2010

HTTPS, Host Headers, Basic Authentication, and SharePoint Search Service (or “Why isn’t my SharePoint search working”)

Setting up SharePoint 2010 Search Service is easy…. if you are running a plain vanilla web application. But, if you are running a more sophisticated setup of SharePoint, you may be in for a rough ride.

In our case, we have a complex setup where we have multiple SharePoint web applications running on a single IIS server, each using HTTPS protocol and host headers.


  • Two SharePoint web applications on a single IIS server using HTTPS.  The HTTPS URL is the only entry point to the web application (I.E. no HTTP or non-SSL support for the applications)
    App1 exists at
    App2 exists at
  • Both web applications need to support search
  • Both web applications are using Basic Authentication to eliminate the need to type the domain name when logging in. (Yes, we can get away with this… we are on an SSL channel after all)
  • Both web applications have a super user read account to support the search service

Easy right?  Nope….

Our First Try
Our first attempt at getting search to work followed these steps:

  1. Installed the search service from the Central Administration web site using the following navigation:
    Application Management –> Manage Service Applications –> New –> Search Service Application
  2. Configured the Search Service Application to taste
  3. Add the application URLs to the default content source Local SharePoint Sites
  4. Set a crawl rule for https://* with support for basic authentication enabled and the search user/password entered.
    NOTE: This is required to allow the search service to logon to the web application.

And then we executed a full crawl….

And we received two errors:

Access denied to sts4s://
Access denied to sts4s://

after some digging around, it appears SharePoint search is accessing the web application through a middle layer (the sts4s part).  As we are using Host Headers and basic authentication, the sts4s protocol appears to be ignored by IIS.

Our Second Try
Out second attempt at getting the search to work revolved around extended the web applications to a host header using integrated authentication.  This extended application would be visible to the internal network only

  1. Extend the web applications to
  2. Remove all of the crawl rules created in our first attempt
  3. Reset the default content sources Local SharePoint Sites to use the myurl.local based addresses

And then we executed a full crawl….

No errors! (There was much rejoicing)

And then we actually searched on a keyword we knew existed.  SharePoint’s search returned nothing.  We were receiving the very frustrating “we did not find any results for …” dialog.  (So much for rejoicing)

Our Third Try
We know the crawl worked as we had thousands of Searchable items listed in the search server.  To make the situation even more confusing, the Recent query rate showed the exact number of test queries we had executed.

After more digging, it appears the myurl.local extended applications need a server name mapping defined.  This allows the search engine to know that the HTTPS link is one and the same as the HTTP link.  Here is what we did

  1. Create new Server Name Mappings for each URL.
    Address for indexing would be http://portal.myurl.local
    Address for display in search results would be


And then we executed a full crawl…

And everything worked!

Android 2.2 (FROYO) and Exchange connectivity issues.

At AIS, many of the development staff have become addicted to the Android based phone and their easy to configure and use MS Exchange active sync integration.  So when Verizon performed an OTA push of 2.2 (FROYO FRG01B) and all upgraded phones suddenly stopped synced with our Exchange server, moribund panic ensued.

The issue had to be fixed…. and fast! (lives were at stake here)

AIS is running

  • Microsoft Exchange 2007 (All patches current)
  • A client access server on the edge network (again, all patches current)
  • SSL certificate from a trusted authority

All in all, a plain vanilla Exchange setup.

Tools of the trade
If you have never used Microsoft’s Exchange Remote Connectivity Tool, you really need to spend some time and check it out!  This tool is a massive timesaver.

The Research
Firing up the Exchange Connectivity test website, we selected and performed the Exchange ActiveSync test.


And what do you know, an error appeared

Accept/Require client certificates were found. Set the IIS configuration to Ignore Client Certificates if you aren’t using this type of authentication.

A quick check of our autodiscover site showed the SSL setting are set to ignore


The Root Cause
After some research into the settings for all of the virtual directories installed as part of MS Exchange, we discovered the virtual directory Microsoft-Server-ActiveSync was set to “Accept”.  It appears Microsoft’s default install of the ActiveSync end point defaults to “Accept”.  With the new FRG01B build, the Android Exchange implementation does not play nicely with Client Certificates.  Nice!

The Fix
Set the Microsoft-Server-ActiveSync virtual directory’s SSL settings to “Ignore” client certificates via the following steps:

  1. Open Internet Information Services (IIS) Manager
  2. Open the website which contains the Microsoft-Server-ActiveSync virtual directory
    This is usually located in the Default Web Site
  3. Click on the Microsoft-Server-ActiveSync virtual directory
  4. In the center action panel, double click on SSL Setting icon
  5. Click the “Ignore” Client Certificates radio button
  6. Restart IIS
  7. Reset your Mail profile on your handset.