我试图在我拥有的两个单独的农场上工作以进行爬网，但不能在任何一个上工作。它们都有两个WFE，另外一个WFE被配置为索引服务器。还有一个专用于Query的服务器和两个用于数据库的群集SQL 2005后端服务器。我尝试使用搜索引擎的解决方案找到的至少50个不同的网站均未成功。我已配置(扩展)我的Web应用程序以使用http：//服务器名：12345作为默认区域，并使用http://abc.companyname.com作为自定义和Intranet区域。当我将每一个输入到内容源中，然后尝试运行爬网时，在爬网日志中会遇到一些错误：

http：// servername：12345返回：
"无法连接到服务器。请确保该站点可访问。"

http://abc.companyname.com返回：
"被收集者删除。(包含此项目的起始地址或者内容源被删除，因此该项目也被删除。)"

但是，我可以同时单击两个URL，并且可以访问该页面。

有任何想法吗？

更多信息：

可以这么说，我将板岩擦干净了，然后又进行了一次爬网以提供更新的样本。

我的内容来源如下：

http：//服务器名称：33333
http://sharepoint.portal.fake.com
sps3：//服务器名称：33333

我当前的抓取日志错误是：

sps3：//服务器名称：33333
PortalCrawl Web服务中的错误。

http：//服务器名称：33333 / mysites
服务器不包含此URL的内容，因为它没有索引属性。

http：//服务器名称：33333 / mysites
爬行

sts3：//服务器名称：33333 / contentdbid = {62a647a ...
爬行

sts3：//服务器名称：33333
爬行

http：//服务器名称：33333
爬行

http://sharepoint.portal.fake.com
搜寻器无法与服务器通信。检查服务器是否可用以及防火墙访问是否已正确配置。

我仔细检查了上面的错别字，但没有看到任何错别字，所以这应该是准确的反映。

解决方案

在"服务器上的服务"部分中，检查搜索爬网帐户的属性以确保已设置该帐户，并且该帐户具有访问这些网站的权限。

我对服务器场拓扑结构有些困惑。仅作为WFE安装的计算机不能是索引器。安装为"完整"的计算机可以是索引器，查询和/或者功能。

另外，我们可能希望添加一个爬网规则(一旦一切正常并运行)，而不是更改默认的内容访问帐户。

我们是否可以看到索引器上的％commonprogramfiles％/ microsoft shared / Web服务器扩展/ 12 /日志中是否有帮助？

日志文件可能有点冗长，我们可以搜索" started"或者" full"，这通常会使我们进入爬网开始的日志行。

另外，在sql机器上，我们也许可以从MSScrawlurlhistory表中获取更多信息。

我们可以为http://www.cnn.com创建内容源并开始完全爬网吗？我们是否得到相同的错误？

另外，我们可能希望将此功能脱机，如果我们要这样做，请告诉我。

我不确定是否可以通过stackoverflow发送私人消息。

要记住的一件事是，对SharePoint网站进行爬网与对文件共享或者非SharePoint网站进行爬网不同。

其他一些快速提示：

• sps3：协议用于对用户搜索的用户配置文件进行爬网。在准备好用户配置文件之前，我们可以无视爬虫所说的任何内容。
• 抓取帐户应该可以访问整个服务器场。如果看到权限错误，请找到有关如何重置爬网帐户的知识库文章(这是一个特定的stsadm.exe命令)。如果我们尝试爬网另一个服务器场的内容，则必须进行其他工作才能授予爬网帐户访问权限。我认为这是我们目前最大的问题。
• 搜寻器(从索引服务器运行)将尝试访问公共URL。我以前遇到过服务器间的通讯问题；确保所有三个服务器都能ping通，并确保索引服务器可以访问公共URL(在索引服务器上打开IE并将其检出)。如果遇到问题，是时候清理索引服务器的hosts文件了。无论如何，这是SharePoint可以为我们完成的工作，因此，不要为此感到难过。如果我们除了设置了集成Windows身份验证之外还进行了其他设置，则必须更加努力地使搜寻器正常工作。

无论如何，答复中有很多来回的回响，所以我只是提出了一些建议，也许其中一个是针对性的。

感谢新输入！

因此，我从周末回来，我想遍历指针，尝试每一个指针，然后报告它们如何不起作用，然后发布我得到的结果。有趣的事情发生了。

我去了Indexer(servername5)，然后尝试从Internet Explorer连接到Central Admin和主门户。两者都不起作用。因此，我进入了Indexer上的IIS，尝试从IIS中浏览到主门户。那也不起作用，我收到一个错误消息，告诉我其他东西正在使用该端口。因此，我看到了以前版本中的旧网站，并将其连同相应的应用程序池从IIS中删除了。然后，我从新版本启动了网站的应用程序池，并浏览到该网站。成功。然后，我从自己的PC上的浏览器浏览到该网站。再次成功。然后，我按完整的URL(而不是服务器名)进行爬网，如下所示：

http://sharepoint.portal.fake.com

再次成功。就像我想要的那样，它爬行了包括子站点在内的整个门户。 "索引中的项目"快速填充，我可以确定自己正在滚动。

我仍然无法从servername5访问servername4上托管的管理中心站点。我不确定为什么不这样做，但是我不知道这点有多重要。

这在哪里离开我？解决的方法是什么？

我还不确定。也许是重建。也许当我重建服务器场后，我便拥有了使其正常工作所需的一切，但由于先前的网站仍在IIS中，因此它无法正常工作。 (有趣的是，SharePoint的卸载有多么草率。似乎有必要手动删除内容数据库，网站和应用程序池，而事实并非如此。)

无论如何，它现在都可以在我的"测试"服务器场上工作，所以关键是要使其在生产服务器场上工作。我希望经过这段经历不会有那么困难。

感谢大家的帮助！

听起来，大多数问题都与Kerberos有关。如果我们没有应用基础结构更新，则Sharepoint将无法对非默认(80/443)端口的网站使用kerberos auth。这就是为什么(我敢打赌)当服务器5在服务器4上时，我们无法从服务器5访问CA。如果没有正确设置SPN，则只能从安装CA的计算机上访问CA。如果我们使用端口80作为默认URL安装了Sharepoint，则可以进行本地Sharepoint爬网而不会遇到任何麻烦。但是通过设计，本地共享点网站爬网使用默认的URL来访问共享点网站。请访问http://codefrob.spaces.live.com/blog/cns!7C69E7B2271B08F6!363.entry，以获取有关如何使Kerberos和Sharepoint协同工作的更多详细信息。