Gunnalag

Hi All,

I hit by a strange WDS application issue recently.

The issue is that WDS doesn't indexes unless workstation is rebooted after WDS installation. Could someone quickly explain the reason and all possible resolutions for this behaviour

I am using WDSv3.01 and am controlling it's settings via Group Policy.

Thanks,

Govardhan




Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Gunnalag

Hi All,

A close obervation of this issue revealed that, it's beacuse that I explictly excluded the local file system indexing using "Prevent Indexing Certain Paths" and thus WDS NOT at all indexing even mail items too though Oultlook isn't excluded/prevented.

The reason I guess is that, since WDS by default indexes "My Documents" which is located on local file system and thus preventing WDS from indexing local file system somehoe caused WDS to NOT at all index any files. But still wondering why WDS is able to index files after machine reboot when I prevent indexing local file system

Please let me know if someone else has any more observations in this regard.

Thanks,

Govardhan






Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Ari Polsky - MSFT

What do you have entered for the excluded paths policy





Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Gunnalag

Hi Ari Polsky,

Below are the values for all the related settings which would affect WDS indexing Outlook items, please let me know if you are looking for any more information.

"Prevent indexing Microsoft Office Outlook" = Disabled

"Prevent indexing uncached Exchange folders" = Disabled since I used Oultook in online mode.

"Prevent Indexing Certain Paths" = file:///C:\*; otfs://{*}\*; outlookexpress://*;

"Default Indexed Paths" = Disabled

"Default Excluded Paths" = Disabled

"Prevent Indexing of Certain File Types" = Disabled

Thanks,

Govardhan






Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Ari Polsky - MSFT

Just to clarify, you're saying that with these group policies set you install WDS 3.01 but it doesn't index anything until after you reboot. And after that it indexes c:\ even though you told it not to via policy, and it does not index outlook email even though it should. Is that accurate What locations on C:\ are getting indexed





Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Gunnalag

> Just to clarify, you're saying that with these group policies set you install

> WDS 3.01 but it doesn't index anything until after you reboot.

Correct.

> And after that it indexes c:\ even though you told it not to via policy,

No, it doesn't index C:\ as expectedly/configured.

> it does not index outlook email even though it should.

Yes, this is my major concern all about.

Thanks,

Govardhan






Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Ari Polsky - MSFT

Did you start outlook (and keep it open) after the WDS installation Outlook email won't be added to the search scope until outlook is launched, and email can't be indexed unless Outlook is open.





Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Gunnalag

Hi Ari Polsky,

Apparently it seems I missed providing you all details and sorry for that. However, my major intention behind starting this thread is to know is there any known possiblity with WDS to exibhit the behavior I reported.

FYI.

> Did you start outlook (and keep it open) after the WDS installation

Yes, I ensured closing the existing Outlook session and opened new Outlook session and left it undisturbed ~2 hours, just to find that WDS not indexed mail items. Even tried logoff and login but in vain. As a lost option tried rebooting workstation and then found WDS indexing mail items.

Hope this explanation provides you a better undertanding of the issue.

> Outlook email won't be added to the search scope until outlook is launched

Am aware of WDS basic behavior. I checked and found that Outlook was listed in WDS search scope on most of the PCs except few random (#15) PCs.

Please feel free to let me know for any more details. And many thanks for checking this issue.

Thanks,

Govardhan






Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Gunnalag

Now I found that WDS doesn't index mail items at all even when I haven't excluded/prevented local file system (C:\) !!!

This WDS inconsistent behaviour driving me to assume that machine reboot is compulsory for WDS application to work properly after installation.

Could someone please let us know how much it's important to reboot workstation after WDS installation

Thanks,

Govardhan






Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Eric Wolz - MSFT

Just to be clear, is no items getting indexed, or file items are getting indexed but not Office Outlook items What version of Outlook are you using Is there any "search" entries in the event log

Outlook indexing scopes are added by Outlook application when their applications starts.






Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Gunnalag

I had worked with M$ support for more than 2 months and got this issue fixed. The fix was to disable the 'Prevent Unwanted IFilters and Protocol Handlers' policy as it was blocking MAPI protocol too when it's enabled. However, M$ support is still working hard (it's now more than 20 days) to just let us know the procedure for enabling this policy without disturbing the WDS indexing Outlook mail items Sad

I do NOT understand why M$ WDS develpoment team has implemented this policy such that it just blocks Outlook too when it's enabled despite that I has set other policies to allow WDS to index Outlook mail items. Due to this issue all our team has lost confidence on WDS functionality and lead us to consider other alternate desktop search tools since WDS basic functionality was broken due to the above policy. And I had to work hard for months to prove that WDS works good. However, really I feel this is a very bad implementation of Group Policies for WDS!!!

Posting the fix here so that if someone stuck up with this issue, can get it fixed easily (without contacting M$ support) and also to help WDS users community.

Thanks,

Govardhan






Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Ari Polsky - MSFT

Sorry for the delay in responding. We have seen a lot of confusion around this policy, as the documentation in the admin guide is not quite clear on its effects or proper use.

The purpose of this policy is to limit the set of search plugins that a user can load (note that it doesn't prevent them from installing anything, just loading them). When this policy is enabled, only the protocol handlers and ifilters that you specify can be loaded by the search indexer. The target scenario for this policy is when you want to make sure that a user won't install a rogue protocol handler or IFilter that could cause indexer instability, hog machine resources, or hog network resources. It's not really suited to the scenario where you just want to limit the locations they will be allowed to index. The "Prevent indexing certain paths" policy is much better suited to that situation.

The difficulty in using this policy lies in the fact that the list of plugins you specify is an allow list - you have to enumerate every protocol handler and IFIlter you want to allow, and no others will be loaded. So if you were trying to use this policy to limit indexing to email only, the protocol handler you'd specify would be MAPI (Search.Mapi2Handler.1). The difficulty lies in specifying IFilters. Since any type of document can come as an email attachment (and presumably you'd want those to be indexed as well), you would have to add *every* IFilter on your system to the allowed addins list. Otherwise search would be unable to load the proper IFilter if that type of document came as an attachment. Note that the body of emails is always indexed using the Plain Text, RTF, or HTML IFilters, depending on the format of the message, so if you didn't want to allow attachment indexing these would be the only ones you'd put in the allow list.

The way you need to specify a protocol handler or IFilter is by supplying its ProgID or GUID. The ProgIDs of all installed protocol handlers can be found under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search\ProtocolHandlers. For example, the protocol handler that handles local files is Search.FileHandler.1, which is the value you'd have to add to this policy if you wanted to allow local file indexing.

Finding the correct values for IFilters is a little trickier, since there's no central place in the registry where you can find GUIDs for all installed IFilters (The ones that come with WDS 3.01 don't have ProgIDs defined). This should have been put in the admin guide, but here it is (at least for those IFIlters that come with the product):

Microsoft Office: {f07f3920-7b8c-11cf-9be8-00aa004b9986}

Plain Text: {c1243ca0-bf96-11cd-b579-08002b30bfeb}

RTF: {e2403e98-663b-4df6-b234-687789db8560}

HTML: {e0ca5340-4534-11cf-b952-00aa0051fe20}

XML: {41B9BE05-B3AF-460C-BF0B-2CDD44A093B1}

MIME: {5645C8C2-E277-11CF-8FDA-00AA00A14F93}

The MS Office one above only handles pre-Office 2007 office file formats. For the new formats there is a set of new IFilters that comes with Office 2007:

DOCX: {D3B41FA1-01E3-49AF-AA25-1D0D824275AE}

PPTX: {4F46F75F-199F-4C63-8B7D-86D48FE7970C}

XLSX: {4887767F-7ADC-4983-B576-88FB643D6F79}

I hope I was able to clear up some of the confusion around using this policy properly. Let me know if you have further questions.





Re: Windows Desktop Search Development WDS doesn't start indexing after installation without reboot.

Gunnalag

Hello Ari Polsky,

Thank you for neatly putting across the details.

> It's not really suited to the scenario where you just want to limit the locations they will be allowed to index.

An important clarification: Am NOT at all using this policy to limit what locations will WDS index, also am aware that "Prevent indexing certains paths" better serves limiting what locations WDS index and we have it all set correctly. And also I clearly understand that these two policies are different, are targeted for different purposes & one can't substitute the other, am I right So I request you not to combine/relate/compare these two policies.

My basic intention behind getting the 'Prevent unwanted Ifilter and Protocols' policy enabled is to achieve the target what it is developed for. (by target I meant the same what you explained, you want to make sure that a user won't install a rogue protocol handler or IFilter that could cause indexer instability, hog machine resources, or hog network resources).

> The difficulty in using this policy lies in the fact that the list of plugins you specify is an allow list

I don't see any point in creation of this policy if WDS admin's are expected to gather ProgID/GUID's of all the Ifilters & protocol handlers and put up them in this policy. Hasn't WDS developement team considered overhead with this policy

I strongly request WDS developement team to change the behavior of this policy to specify a deny list instead of allow list. Such that all the ifilters and protocols would be allowed by default and WDS admin's can add any protocol or ifilter to the deny list. Since it's easy to work and get the ProID or GUID of a few ifilters and protocols handlers rather than keeping track of whole bunch of ProID or GUID of all the existing/new ifilters & protocols handlers.

> We have seen a lot of confusion around this policy, as the documentation

> in the admin guide is not quite clear on its effects or proper use.

Is this an acceptable responsibility from a great software developer gaint like M$ Due to this we had to spend much **TIME** & money on chasing the issue and unfortunately the support (in my case) too wasn't skillful either resulting suspending our WDS implementation plans on whole.

Thanks,

Govardhan