Hi

FTS will not populate the catalogs. 0 Items

I have a new installation W2003 with SQL2K Sp3

The SQL Server is running with a high security configuration
All the SQL services are running under an account Domain\SQLService which is a plain old user in the domain and on the SQL Server box

The local system account was chosen during installation. I changed to the domain user via the Enterprise Manager after the fact. SQL Server and SQL Agent run fine. BUILTIN\Administrators has been removed

I saw a post that said changing the service account from one account and back to the original should fix the problem. It did not. I see "Login failed for NT AUTHORITY\SYSTEM" in the SQL Error Log when I try to build the catalog. I checked the account that is running MS Search in the Services dialog and it is still Local System. When I changed accounts on SQL Server, I changed it to myself a local admin and then back to the Domain\SQLService account. I tried changing the MS Search account via the Services dialog to Domain\SQLService account and now it will not start. Domain\SQLService has full control on the FTDATA directory. Any other directories or registery keys that perhaps Domain\SQLService needs access to, but is not being set

Thanks

Follow up..

Here are some messages from the event log
12:14:21 PM Search Service 7052 The Search service has loaded project <SQLServer SQL0002000005>.
12:14:19 PM Indexer 7070 The Search service has added project <SQL0002000005>
12:14:19 PM Indexer 7071 The Search service has removed project <SQL0002000005>
12:14:19 PM Indexer 7042 Project <SQLServer SQL0002000005> has been shut down as requested by user
12:14:05 PM Indexer 7045 The catalog was not propagated, because no new files were detected for the project <SQLServer SQL0002000005>.
12:14:05 PM Gatherer 3018 The end of crawl for project <SQLServer SQL0002000005> has been detected. The Gatherer successfully processed 0 documents totaling 0K. It failed to filter 1 documents. 0 URLs could not be reached or were denied access
12:14:05 PM Gatherer 3024 The crawl for project <SQLServer SQL0002000005> could not be started, because no crawl seeds could be accessed. Fix the errors and try the crawl again
12:14:05 PM Gatherer 3036 The crawl seed <MSSQL75://SQLServer/37fa4c37> in project <SQLServer SQL0002000005> cannot be accessed. Error: 800700e9 - No process is on the other end of the pipe.
12:14:04 PM Gatherer 3019 The crawl on project <SQLServer SQL0002000005> has started

Norman,
The MSSearch service requires that either the BUILTIN\Administrators login
be present or that [NT Authority\System] localsystem login have the below
rights and this is why you are seeing ("Login failed for NT
AUTHORITY\SYSTEM" ) after removing the BUILTIN\Administrators login:

exec sp_grantlogin N'NT Authority\System'
exec sp_defaultdb N'NT Authority\System', N'master'
exec sp_defaultlanguage N'NT Authority\System','us_english'
exec sp_addsrvrolemember N'NT Authority\System', sysadmin

See also KB article Q263712 "INF: How To Prevent Windows NT Administrators
From Administering a Clustered SQL Server"
at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q263712 for more
info.

Regards,
John



[quoted text, click to view]
SQL0002000005> has been detected. The Gatherer successfully processed 0
documents totaling 0K. It failed to filter 1 documents. 0 URLs could not be
reached or were denied access.
[quoted text, click to view]
could not be started, because no crawl seeds could be accessed. Fix the
errors and try the crawl again.
[quoted text, click to view]
project <SQLServer SQL0002000005> cannot be accessed. Error: 800700e9 - No
process is on the other end of the pipe. .
[quoted text, click to view]

John

No kudos to Microsoft for the high level security requiements for MS Search and not providing a KB with a work around for highly secure environments

FYI
Even though I found posts that indicate the contrary, the MS Search service remains Local System Account regardless of which account you put in the the SQL Service or SQL Agent at installation or after the fact via the Enterprise Manager. I tried it on several SQL Server installations on W2K and W2003

My compromise solution was to create a domain account specifically for the MS Search service and make it local admin and sa in the SQL Server. This seems to function correctly for all the test I have tried. The SQL Server service is then still locked down as long as there are no holes to exploit via the FTS queries. (I won't hold my breath

Norman,
Unfortunately, I'd have to agree with you. FYI, the "Microsoft Search"
(mssearch.exe) service should ALWAYS be started and running under the
"system" or LocalSystem account as that how it is currently designed in SQL
Server 2000. However, for SQL Server 2005 (Yukon) this has changed and the
new MSSearch service, will be able to run under the same service account as
the MSSQLServer service.

If I was in the SQL MVP program, I'd be glad to volunteer and write such a
KB article, but alas I'm not *yet* in that program...
Regards,
John




[quoted text, click to view]
Search and not providing a KB with a work around for highly secure
environments.
[quoted text, click to view]
service remains Local System Account regardless of which account you put in
the the SQL Service or SQL Agent at installation or after the fact via the
Enterprise Manager. I tried it on several SQL Server installations on W2K
and W2003.
[quoted text, click to view]
MS Search service and make it local admin and sa in the SQL Server. This
seems to function correctly for all the test I have tried. The SQL Server
service is then still locked down as long as there are no holes to exploit
via the FTS queries. (I won't hold my breath)
[quoted text, click to view]