Search Configuration Part 3: Registration
I am the Ektron Search Configuration utility. In part 2, I took a short trip to visit my cousin, the Ektron Windows Service. There, I picked up information about any CMS sites he had previously discovered. My user interfaced with me and selected the site he wanted to register. After verifying the connection string, setting crawl filters, and entering the search account's credentials, we are ready for Part 3: Registration.
When my user clicked the Register Site button, I started a long, complex chain of events that culminates in the site being registered, the CMS database search tables being updated, and, if all goes well, the readiness to start a full crawl of the CMS database.
As my registration journey starts, I grab the name of the search server, resolve it to an IP then head out over the network to the search server where I located the Ektron Search Server Service on port 8732. Once we've exchanged pleasantries, I ask him to get me a list of content sources and configured sites (He knows how to cajole this information out of SharePoint). I do this in case the site my user selected is already registered; in that case I need to ensure that some clean-up is done before requesting a new crawl. After that task is out of the way, I ask the search server to validate the credentials that my user entered. If they are valid on the search server, the Ektron Search Server Service, the epitome of brevity, returns the word true. The next step is a big one - the testing of the CMS database. For my part, I send the search server the connection string and the search credentials. If the test passes, I get the word true again but if there is a failure, I display the bad news:
This error is not unusual for new configurations. It can occur because the search server cannot resolve the SQL Server name, or maybe security is blocking access. To resolve the error in the past, my user has added the SQL Server name and IP to the hosts file on the search server and changed the connection string from Integrated Security true to false and added SQL accounts in the CMS site web.config. Another thing he encountered once was that the SQL instance (when other than default) was not named in the connection string. The site worked okay but search server needs the instance to be specified, for example, server = name\instance instead of just server=name.
Once the database test returns true, I ask the search server to create a Content Source. The content source name is a concatenation of the following:
<site IIS ID number><CMS server name><database name>
I also send the search server lots of additional information about the site including: the Base Directory, Connection String, Private and Public Assets Paths, Uploaded Files and Images Paths, URL, crawl filters, Temp Directory (for example, c:\EktronSearchData), and the Trace Level. Of course, unless there is a problem creating the content source, the search server returns just one word: Success. I next ask the search server to get me the content source based on the CMS database server and name. The returned data includes: the ContentSourceName, crawl information, current and pending actions, the QueryService, Statistics, and Suggestions service URLs, and the three starting addresses; one each for content, users, and usergroups (they each start at 0). That should be enough to kick off a crawl. This is always a suspenseful moment akin to asking will a watched pot boil? We will see next time in part 4: The Crawl.
comments powered by