My business partners and I are deploying Office 2007 at a few Customer sites now, and we've quickly learned that Outlook 2007 is greatly "enhanced" with the addition of Windows Desktop Search (WDS). Without WDS, the "Find" functionality in Outlook is diminished.
With this in mind, I embarked on installing WDS as part of an Office 2007 deployment. This particular Customer was of the mind that client computers should not be indexing resources on server computers, being that they have an enterprise search product already implemented to do that. I started looking for a way to administer WDS via Group Policy and, specifically, how to disable indexing of resources via UNC or "mapped" "drive".
In version of WDS prior to 3, from what I could tell, there was a registry
setting to disable indexing of any resources accessible via UNC. Further,
from what I can tell by examining the EXEs and DLLs that come with WDS 3.01,
the name of the registry value that controls this behavior,
PreventIndexingNetworkShares, is no longer a string that occurs
in the SearchIndexer.EXE executable. (As an aside, I did find
the string in another file, Deskbar.DLL, but I don't expect
that it would control indexing behavior.)
The Windows Desktop Search Administration Guide
details extracting a group policy template,
DesktopSearch30.ADM, out of the installation package for WDS,
and I saw no specific setting to prevent indexing of all UNC resources. The
next best setting, appeared to be PreventIndexingCertainPaths,
known by the en-us localized string "Prevent Indexing Certain Paths". The
syntax to specify UNC paths is odd to me, being of the form
otfs://{*}/server/share/path. I wondered if I could exclude all
UNC paths by specifying otfs://{*}/*/*, so I tried.
After specifying this setting in a GPO and rebooting my deployment test
machine, I found that I was waiting approximately two (2) minutes at
"Applying settings..." before the boot would proceed. A little searching
turned up a conversation on the MSDN forums
that described the issue I was having. It seemed that the Windows
Search service (SearchIndexer.EXE, running as the
WSearch service) was hanging up the boot process until the
service control manager got tired of waiting on it. Helpfully, an Ari
Polsky from Microsoft indicated that it was a "known issue", and
offered two (2) mutually unacceptable "fixes": (1) To make the
WSearch service dependent on the NLA service
which several users indicated did not help, and (2) mark the
WSearch service for manual startup, which sorta works.
I decided to go the route of the manual service start, and modified my GPO
containing my WDS management policy to include a setting to make the
WSearch service start manually. The next boot went very
quickly, but I discovered upon logon that the service didn't start "as
advertised" by Mr. Polsky's message, and that attempting to start the
service gave me a "The service terminated with service-specific error
2147500053". This, too, was reported in the MSDN forum thread, and several
readers figured out that marking the WSearch service for manual
startup by altering only the Start parameter in the registry,
rather than using the a service policy in a GPO, seemed to alleviate the
service-specific error.
I knew that service policies in GPOs also alter the security descriptor
assigned to the service, so using the sc sdshow command, I
found that the security descriptor for a stock WSearch service
was:
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY) (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA) (A;;CCLCSWLOCRRC;;;AU) (A;;CCLCSWRPWPDTLOCRRC;;;PU)
After modifying the service to start manually, using group policy, but not modifying the security settings, the security descriptor becomes:
D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA) (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY) (A;;CCLCSWLOCRRC;;;IU).
These descriptors are expressed in the Security Descriptor Definition Language, or SDDL. It's painfully difficult to read, but, fortunately, some people at the University of Washington assembled a SDDL syntax guide that can help you decode these nasty strings. One thing that their guide doesn't contain, though, is a description of how the types of "rights" granted by the descriptor, which are phrased in their documentation in the manner of filesystem permissions such as "Create All Child Objects" or "List Contents", are applied to services.
Microsoft wrote a knowledge-base article, KB 914392, which describes the Best practices and guidance for writers of service discretionary access control lists. This article is dense and, unfortunately, uses abbreviations that are somewhat ambiguous to describe the meaning of the "rights" granted. Alun Jones, a Microsoft "Most Valued Professional" for security, wrote a nice article describing how SDDL rights relate to services that is understandable and clear.
So, armed with these articles, I performed an exercise to figure out what
security descriptor was required in order for the WSearch
service to start and run properly. Fortunately, I hit it right off the bat.
The "stock" descriptor names "Built-in Administrators", "SYSTEM",
"Authenticated Users", and "Power Users". The descriptor that is applied by
group policy, by default, names "Built-in Administrators", "SYSTEM", and
"INTERACTIVE". Just for kicks, I added "Authenticated Users" to my service
policy GPO, and granted them "Read" and "Start, stop and pause" permission.
This gave me a resulting security descriptor of:
D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA) (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY) (A;;CCLCSWRPWPDTLOCRRC;;;AU).
That last bit-- the part that ends in ;;AU) now matches the
"stock" descriptor for "Power Users" (the one ending in ;;;PU)
in the first example).
One reboot later (which proceeded at normal speed), and I found that the
WSearch service had started itself after the user logged-on (as
indicated by time-stamps in the System event log), and did not
terminate with any errors. Success! I'm not really concerned that plain ol'
users can stop and start the WSearch service, because it seems
to want to start itself (by way of the WDS user-land UI).
After doing all of this, I finally got a change to see if the
otfs://{*}/*/* setting for the "Prevent Indexing Certain Paths"
policy worked, and I'm happy to report that it does. The users will not be
indexing the server computers via "mapped" "drive" or UNC.
In summary, if you're having trouble with long startup / bootup times on computers running Windows Desktop Search 3.01 with settings being applied via Group Policy, I'd recommend creating a service policy to set the Windows Search service to manual startup, and modifying the security settings in the policy to include "Authenticated Users" with "Read" and "Start, stop and pause" rights.
As an aside to this whole thing, it appears that Microsoft has implemented a
Group Policy Client Extension (GUID {7933F41E-56F8-41d6-A31C-4148A711EE93})
in srchadmin.dll for WDS to process Administrative Template
settings from. Searching Goooogle for keywords like CLASS
MACHINE and CLIENTEXT, I'm not coming up with a lot of
Administrative Template files, other than this one for WDS, that make use of
the client extension capability. I've thought about doing it for some work
that we've done, and after seeing how easy it is to integrate it into an
Administrative Template, perhaps I should think more strongly about it.
