When I patched it, my standard practice is to delete the VD's, Delete the folders, delete the services, patch the ASI folder, recreate the two multi-instances (DEV AND PROD). This was done on this site and both sites confirm that the patch level is 3152. It was patched the same day that the patch came out.

I'm not getting a RED error message. I just don't get any results that return...
It is a Windows 2003 server and there aren't any errors within the log that look familiar to a "SEARCH" related issue.

The latest patch version is 3632, not 3152. I believe 3152 still has the bug.

You should also verify that the content folders that contain the content you wish to be searchable have either the default search website set, or have the additional search websites set, in their edit screen; if neither of those is set, the content will not match any searches performed from any websites.

Yeah, I was looking at ASI's site incorrectly. I've got the latest release patch installed - 3632...

The content folder called "Public"
The setting for Default Website (for search) is Public
The setting for Include content in Searches for these additional Websites is checked for "Always display content in default website"

The default website was selected to Public but the second setting wasn't checked, but I selected it and re-published the entire folder and everything below it...

It still doesn't present any search results.
I have already created a new index rather than the default one and modified the web.config file to reference the new index to see if in fact that would help, with no success.

If you hand-created the new index that may very well explain it; we customize the Properties so that we can cache/search on/return some specialized information. If you look at the Properties for the original iMIS catalog that the installer created, it should have several custom Properties set to Primary storage, including ismembersonly, postpublishurl, contentkey, and publicationdate (there may be others; that's not a complete list). If those properties aren't set to be cacheable, the search will not be able to find any content (because the website and security keys won't match any values).

Rather than using the multi-instance tool to re-create, how would I be able to recreate the settings in the current index? I deleted the earlier one?

You can manually set the properties to be cached. The full list (I just checked an existing server) is:

• updatedby VT_LPWSTR,110
• createdby VT_LPWSTR,110
• ownerwebsitekey VT_LPWSTR,36
• postpublishurl VTLPWSTR,500
• ismembersonly VT_LPWSTR,5
• description VT_LPWSTR,50
• contentkey VT_LPWSTR,36
• publicationdate VT_LPWSTR,15

Double-click each of these properties in the list, check Cached, set storage level to Primary, the datatype and size to the values given above, and click OK. You will need to stop and restart the Index Service and tell it to perform a Full Rescan of the directory or directories in the index.

I did everything you indicate above and to no avail... I'm getting no results. UGH...

The other thing that I do see is that the settings for the default installation appear to be what you suggested earlier.
The setting for the default are:
   Default Website is Public (Set correctly without anything from me)
   Include content in Searches for these additional websites (checked and set correctly without anything from me)

Actually, I just looked at the settings to this index and none of the properties that you provided me were set in the default instance. Why would that be?

When I do a search on that default instance website, it returns no results and no errors, just like the multi-instance Production site.

One other comment. When I ran the multi-instance tool on these two (DEV AND PROD), the tool fails in configuration settings because I didn't include the Public view. Could there be other configuration settings that are preventing all the correct setup to the indexing service. I have noticed when using the multi-instance tool without a public view, it ALWAYS throws an error during the configuration. What other configuration files could possibly be preventing this to work.

To re-cap, I've made all the changes you indicated and still don't return any results.

The original 15.1.1 installer had a bug that caused the properties to not show up until you had stopped/restarted the indexing service (or rebooted the server). You may need to stop/restart the index service and initiate a full rescan on that as well; that may cause the properties to appear.

You should also check that the port number specified in <client url="tcp://localhost:15151"> element in SearchRemoting.config matches the port number given in the <channel ref="tcp" port="15151"> element in PublishService.exe.config for each instance of iMIS. They should all be different per-instance (i.e. no two instances should use the same port) as well.

Excuse me for being a little out of my element, but I'm certainly doing a crash course on Search Indexing...

To confirm restarting the Index service, I'm assuming you're indicating the service in the services Administrative Tools. I've re-started that one several times in the past 2 weeks. Just did it again. I also restarted the indexing Service from the MMC.

I'm not sure what you mean by initiating a full rescan on that as well. I went into each index and re-scanned everything. Properties are there, but no values for any properties on either the default (ASI) or the dev (ASI_DEV). They are there in the PROD (ASI_PROD) because I put them there per your instructions.

I did re-check all the port numbers on all 3 instances (ASI, ASI_DEV and ASI_PROD) (15155,15156,15153). I knew this from an SMR with Matthew and confirmed several times and once again... If that wasn't set up correctly, I'd be getting that red error...

Hm, I'm not sure why they aren't on the default instance. You will want to add them, they definitely need to be there.

Have you tried searching while not logged in vs. searching while logged in as MANAGER?

Matthew just commented on the SMR indicating that he thought it may have something to do with the fact that the Indexing Service was not installed initially. I had to install the indexing service when we first started diagnosing this. Could that have something to do with it?

Yes, that would probably prevent the installer from creating the entries correctly.

I added them to the default instance and the search works there. It doesn't work on either multi-instance (DEV or PROD), so i would rule out the fact that indexing service wasn't first installed. But now - WHAT NOW? Where do I go from here? Both DEV and  PROD result in nothing coming back from the search. The DEV site has the original DEV index that was created with the multi-instance tool The PROD site has the new one that I created and I modified the settings in both.

I tried searches with logged out and logged in. Nothing returns a result.

Would it hurt to re-run the multi-instance tool again on a folder?
ALSO, I'd like to copy the Public directory from another install to the correct location prior to running the multi-instance to insure that all the configurations are completed correctly. Your thoughts?

Both of those sound like reasonable things to do.

I successfully re-ran the multi-instance tool and I'm still getting no results on the search in any of my multi-instance sites...
Add to that, all of the settings were set correctly within the index that I created for the Production site.

Could there be any other configuration parameters that we're missing?

I went on another test client site and duplicated what I'm trying to do on this site.

1. Successfully tested search on the default instance (Worked on both sites).
2. Created a multi-instance from the default instance (Did this on both sites. Worked on other test client site but didn't work on this problem site).

Why would the multi-instance site not render search files, but the default instance render the files?
 

Is this just a multi-instance utility issue?  or do you have search problems on a default site (i.e. a site created directly by the installer's setup.exe)?  I get the impression it's sporadic - works on one server, not another - is that right?   Is the OS Windows 2003 Server?  If so, are there different service pack levels between different servers?

Yes, the search works on the default instance on both servers.
The multi-instance site works on one server but not the other.
Both servers are Windows 2003 Standard Edition, SP 2.

Are there any configuration settings in iMIS that would prevent the search from working? We have moved the DEV database into the default instance configuration and the search doesn't work when doing that. Replacing it with the default instance database allows the search to function? I also took the DEV database and put it in a out-of-the-box configuration of wCM and tried the search with the same result - NO results?

Things to double check in the various config files (I know you've done some of these, but for completeness):

• PublishService.exe.config has the correct database name, iMIS catalog name, and ImisWebServerUrl.
• The port number given in PublishService.exe.config agrees with the port number given in SearchRemoting.config.
• The directory in the Index Server catalog points to the same folder as is listed in the "Local Protected Path" value for the publishing server's entry in Content Management > Maintenance > Publishing servers, and the Publish Server Code listed on that same page agrees with the PublishServerCode entry in PublishService.exe.config.

Note that after creating a new instance using the multi-instance utility, you need to regenerate all content to make sure the search metadata gets published to the new catalog (select the root @ folder, click Publish, select Regenerate existing content and make sure Publish children is checked, and hit OK).

I just checked and this last step is not listed in the MI Utility docs; I'll have it added.

Eric,

Thanks for all your help. After re-generating all the content, the site search matches what's in the index itself. Thanks again for your support.

No problem Ed... thanks for helping me clarify so that I can add the needed info to the user docs. :)

Hi all,

Thanks for the information.  I was able to get the search working as well.  One item I'd like to mention is that it looks like the catalog name in web.config and the index name are case sensitive.  When I had the index name as iMIS and the web.config as imis, it didn't work.  When I made the two match it all worked fine.  

One thing that is somewhat upsetting is that the search only seems to return results when I am logged into the site.  The client that requested this feature has two wCM site and both are public sites that really don't need logins for anything.  They would like the search feature to work when not logged in.  Does anyone have any ideas on how to make that work?

thanks,

Chadd Arthur

I believe there was an issue where on Windows 2003, searches by unauthenticated users were parsed as containing only ignored words; if that's the issue you're seeing (the Event Log on the WCM server will have logged those error messages), there is an update available for iMIS 15.1.1 that resolves it. (It's also resolved in 15.1.2.) Applying the most recent iMIS update should fix the problem for you.

If you've already applied it or you're on 15.1.2, let me know and we'll dig a little more.

Eric Means
System Architect, ASI

Thanks Eric.  They are on Windows 2003, but also on the latest 15.1.1 patch.  I'll check the servers event log and see what infor it gives.

Chadd Arthur

OK, make sure you double check that they're on version 3632 while you're there. :) The SMR I mentioned was # 193847, if you want to look it up.

Eric Means
System Architect, ASI

Yep, they are on the latest 15.1.1 version and I don't see any errors in windows.  I submitted an SMR and this is what the tech analyst had to say.

To get search to return results without being logged in you need to manually update the following properties for the iMIS catalog under Manage Computer > Indexing Service > iMIS > Properties
allowedaccess
createdby VT_LPWSTR 110 Primary
updatedby VT_LPWSTR 110 Primary
ismembersonly VT_LPWSTR 110 Primary
ownerwebsitekey VT_LPWSTR 110 Primary
includeinwebsitekeys
postpublishurl VT_LPWSTR 500 Primary
description VT_LPWSTR 50 Primary
contentkey VT_LPWSTR 36 Primary
publicationdate VT_LPWSTR 15 Primary

Once you have updated the above keys you will need to restart the indexing service and then drill down into Manage Computer > Indexing Service > iMIS > Directories, right click and select Rescan(Full). The key is to make sure you restart the indexing service and do a full rescan after updating the properties.

I did this, but it still requires you to be logged in to return any search results.

Chadd Arthur

You're sure you did the Rescan as well? I worked with Matt on resolving this and I know he got it working after creating the properties, restarting the service, and doing a full rescan. Alternately, you can stop the service, delete the "catalog.wci" folder (hidden) located in the index server catalog's configured location, and restart the service.

Eric Means
System Architect, ASI

deleting that folder combined with the changes tech support suggested and a sprinkle of a rescan makes for a yummy search when not logged in.  Thanks,

Chadd Arthur

I got the WCM search working for TPB using these instructions. Thanks for the tips.

One question though:
I can't see the following properties that you mentioned:
ownerwebsitekey VT_LPWSTR,36
description VT_LPWSTR,50

Is there any reason why these 2 properties are missing?

Not that I know of.

Eric Means
System Architect, ASI