Sorry it took a couple of days, but here is the solution and some of the trouble shooting steps we took to solve the search results error I blogged about in Part 1.
First, some of things we tried. Our very first step was to reset the crawl log, once the crawl log was reset, we checked the content sources and scheduling to point all the URLs that were being crawled to the domain names we wanted to return, just to make sure this wasn’t the problem. We also added the URLs into their respective places in Server Name Mappings” under the search settings in Central Administration, hoping this would replace the bad section of the URL. Unfortunately, none of these steps worked. We next created a search center with custom scopes. We set the rules on these scopes to include only content with the correct URL. Items were listed as being in the scopes and, upon searching using our custom scopes, the correct results were being returned. So, why does the custom scope work but not the This Site: and This List: search? Honestly, I’m still not sure.
I’m not really sure what made us try this, but the next step was to switch the URL in the AAM…instead of the port number being default and the correct URL being intranet. We swapped them so we now the correct URL as being default and the port number being intranet…still no luck. The last thing we tried was to start the IIS sites using the various port numbers, low and behold, search started working…great, we figure out the problem…both IIS sites need to be running even though we are only going to ever use one of them as the port numbered sites were just for migration purposes.
So, we found the problem but were still stuck as we didn’t want all the extra IIS sites running. So, this fix we discovered that actually worked. We went into Central Administration, delete SharePoint from IIS, and deleted the intranet zone site. Next we went into the content databases to make sure we had the correct name of the content database and the name of the SQL server it is on, if you have more then when. Finally we went back to Application Management and clicked on Delete Web Application. Next, MAKE SURE YOU UNCHECK DELETE CONTENT DATABSE. Go ahead and delete your web application. Your web application is complete gone, however the content database is still on your SQL Server.
Click to create a new web application, when we created our new web application, we entered the production URL we wanted (rather than the alternate port number URL), and entered the name of our already existing databases. We then filled in the rest of the information as usual and click Create. Once the web application was successfully created, we navigated to the site, everything was there and we could still access it all as normal, and most importantly every aspect of search still worked!! So, that is how we fixed our problem.
As I dig more into this issue into my free time to see what is really going on, I’ll hopefully have some future posts about what the problem actually is. If anyone knows or has any additional insight into the problem or any other questions about it feel free to leave a comment.
