来自Paul Robinson的16条建议很值得琢磨琢磨，这是关于在MOSS上配置企业级搜索时候遇到的问题，有几条还真让我恍然大悟。也解决了部分最近在项目中配置搜索功能时碰到的问题，简单的总结下，共勉之！如果有错误,望各位尽快提出,别在折腾我了...
1． 当我们的文档库启用审核功能时，是不能让普通用户查看或者搜索到没有发布和通过审核的文档，可是当我们的爬网账户权限足够大时，比如能够看到草稿状态的文稿，嘿嘿，你的秘密文稿就会被别人看个摘要，也就没有必要启用审核喽。我们因该给一个普通的读者身份给它，只能看到最后一次发布出去的文稿即可；
2． 搜索关键字中好像不支持通配符吧，比如AND,OR等。可是Nigel Bridport指出通过WebService，在高级搜索中配置SQL语句可以达到此效果，有待尝试；
3． 只有完全爬网才能重新对ASPX文件进行索引。所以了，小心了！一旦你从某个文档库或者列表中删除文档时，你会发现它们仍然出现在搜索结果当中，即使你做了一次增量爬网！所以Graham Tyler告诉我们如何堵住它们；
4． 测试结果推荐你在一个场中最多创建4个SSP，撑死20个(=5 farm)？,有待考证；
5． 测试结果推荐在所有的内容源索引中不要超过500000000个文档，也就是说通常建一个SSP对所有内容源爬网时！解决的办法是再建个SSP，负载均衡吧，因为每个SSP只能有一个索引服务器。对了，BDC的结果也计算在内；
6． 每个内容源的起始地址撑死500个，如果你的默认内容源不小心满了，额外的站点将没有他们的注册起始地址，最后你不得不手动的把它们添加到其他的内容源，或者更改下默认的内容源；
7． 留意了，关于索引和搜索数据库的大小信息最近将会在Technet上看到，期待中；
8． 索引服务器对每个WEB前端爬网并且启用的负载均衡时，每个WEB前端都会被命中，你可以指定索引服务器使用单独的WFE来改变这种状态。
9． 查询和索引角色可以跑在同一个服务器上，可是当你增加额外的查询服务器时，索引服务器就必须要单独生活了。举个例子:1Query+1Index = 1Server;2Query+1Index = 2Server;\o/
10． 适当的配置WFE和查询服务器在同一台服务器上可以提高查询性能，特别是在使用WFE自定义安全动作重复使用某一结果时；
11． 不同体系结构的角色可以混合在一起，比如说32bit的WFE和 62bit的索引服务器，但是最好不要在同一个角色中；
12． 索引服务器推荐使用64位的机器，但是很多第三方的IFilter目前并不支持64位的应用，比如Adobe的PDF，Lotus的什么什么等；
13． 对于索引服务器来说，可以下载和解析的最大文件大小默认为16M,当然了你可以去更改它以适应足够大的PPT文档，等等；
14． 允许进行干扰词查询选项默认是关闭的，你可以在核心搜索结果的部件中启用它，可是它会影响MOSS改良的搜索机制；
15． 搜索结果报告仅支持从客户端异步收集数据，也就是当用户使用MOSS的搜索结果页面时！因此，该报告将不能搜集使用API或者WebService查询的结果；
16． 显而易见，支持表单身份验证的外部站点是不支持爬网的；