MOSS 2007 Crawl

Question

Я пытаюсь заставить сканирование работать на двух отдельных фермах, которые у меня есть, но я не могу заставить его работать ни на одной из них. У них обоих есть два WFE с дополнительным WFE, настроенным как сервер индекса. Есть еще один сервер, выделенный для Query, и два кластерных внутренних сервера SQL 2005 для базы данных. Я безуспешно пробовал по крайней мере 50 различных веб-сайтов, которые я нашел с решениями из поисковой системы. Я настроил (расширил) свое веб-приложение для использования http://servername:12345 в качестве зоны по умолчанию и http://abc.companyname.com в качестве пользовательских зон и зон интрасети. Когда я ввожу каждый из них в источник контента и затем пытаюсь запустить сканирование, я получаю пару ошибок в журнале сканирования:

http://servername:12345 возвращает:
«Не удалось подключиться к серверу. Убедитесь, что сайт доступен.»

http://abc.companyname.com возвращает:
«Удалено собирателем. (Начальный адрес или источник контента, содержащий этот элемент, был удален, и, следовательно, этот элемент был удален.)»

Однако я могу щелкнуть оба URL-адреса, и страница станет доступной.

Есть идеи?

---

Дополнительная информация:

Я вытер чистую доску, так сказать, и запустил другой обход, чтобы получить обновленный образец.

Мои источники контента таковы:

http://servername:33333
http://sharepoint.portal.fake.com
SPS3: // имя_сервера: 33333

Мои текущие ошибки в журнале сканирования:

SPS3: // имя_сервера: 33333
Ошибка в веб-службе PortalCrawl.

http://servername:33333/mysites
Содержимое этого URL-адреса исключается сервером из-за отсутствия индекса.

http://servername:33333/mysites
Просканировано

sts3: // имя_сервера: 33333 / contentdbid = {62a647a ...
Просканировано

sts3: // имя_сервера: 33333
Просканировано

http://servername:33333
Просканировано

http://sharepoint.portal.fake.com
Обходчик не может связаться с сервером. Убедитесь, что сервер доступен и доступ к брандмауэру настроен правильно.

Я дважды проверил наличие опечаток выше и не вижу их, поэтому это должно быть точное отражение.

Answer 1

Следует помнить, что сканирование сайтов SharePoint отличается от сканирования общих файловых ресурсов или сайтов, не относящихся к SharePoint.

Несколько других быстрых указателей:

• протокол sps3: предназначен для сканирования пользовательских профилей для поиска людей. Вы можете игнорировать все, что говорит об этом сканер, пока не будете готовы к профилям пользователей.
• ваша учетная запись для сканирования должна иметь доступ ко всей вашей ферме. Если вы видите ошибки прав доступа, найдите статью базы знаний, в которой рассказывается, как сбросить учетную запись для сканирования (это особая команда stsadm.exe). Если вы пытаетесь сканировать содержимое другой фермы, вам нужно будет что-то еще обработать, чтобы предоставить доступ к своей учетной записи для сканирования. Я думаю, что это ваша самая большая проблема в настоящее время.
• Программа-обходчик (запущенная с сервера индексирования) попытается посетить общедоступный URL-адрес. У меня были проблемы с межсерверной связью раньше; убедитесь, что все три сервера могут пропинговать друг друга, и убедитесь, что сервер индексирования может получить доступ к общедоступному URL (откройте IE на сервере индексирования и проверьте его). Если у вас есть проблемы, пришло время испачкать файл hosts вашего сервера индексирования. В любом случае, это то, что SharePoint делает для вас, так что не расстраивайтесь. Если вы настроили что-то помимо встроенной аутентификации Windows, вам придется усердно работать, чтобы ваш сканер заработал.

Во всяком случае, в ответах было много взад-вперед, поэтому я просто выдвинул кучу предложений, возможно, одно из них уже намечено.

Answer 2

Большинство ваших проблем связано с Kerberos, похоже. Если у вас не применено обновление инфраструктуры, то Sharepoint не сможет использовать аутентификацию kerberos для веб-сайтов без портов по умолчанию (80/443). Вот почему (я бы поспорил), что вы не можете получить доступ к CA с сервера 5, когда он находится на сервере 4. Если у вас нет правильно настроенных SPN, CA будет доступен только с машины, на которой он установлен. Если вы установили Sharepoint, используя порт 80 в качестве URL по умолчанию, вы сможете выполнять локальный обход по sharepoint без каких-либо проблем. Но по замыслу обход локальных сайтов sharepoint использует URL-адрес по умолчанию для доступа к сайтам sharepoint. Ознакомьтесь с http://codefrob.spaces.live.com/blog/cns!7C69E7B2271B08F6!363.entry, чтобы узнать, как заставить Kerberos & Sharepoint работать вместе.

Answer 3

Можете ли вы создать источник контента для http://www.cnn.com и начать полное сканирование? Вы получаете ту же ошибку (ы)?

Кроме того, мы можем отключить эту функцию, дайте мне знать, если вы хотите это сделать.

Я не уверен, есть ли способ отправки личных сообщений через stackoverflow.

Answer 4

Я немного запутался в топологии вашей фермы. Машина, установленная как просто WFE, не может быть индексатором. Машина, установленная как «полная», может быть индексатором, запросом и / или wfe ...

Кроме того, вместо изменения учетной записи для доступа к контенту по умолчанию вы можете вместо этого добавить правило обхода (после того, как все будет готово)

Можете ли вы посмотреть, есть ли что-нибудь полезное в журналах% commonprogramfiles% / microsoft shared / extensions веб-сервера / 12 / на вашем индексаторе?

Файл журнала может быть немного многословным, вы можете выполнить поиск «запущен» или «полный», и это, как правило, приведет вас к строке в журнале, где началось сканирование.

Кроме того, на вашем компьютере sql вы можете получить больше информации из таблицы MSScrawlurlhistory.

Answer 5

Спасибо за новый вклад!

Итак, я вернулся с выходных и хотел просмотреть ваши указатели и попробовать все, а затем сообщить о том, как они не работали, а затем опубликовать результаты, которые я получил. Однако случилось нечто забавное.

Я зашел в свой индексатор (servername5) и попытался подключиться к Central Admin и главному порталу из Internet Explorer. Ни один не работал. Поэтому я вошел в IIS на Индексаторе, чтобы попытаться перейти к основному порталу из IIS. Это тоже не сработало, и я получил сообщение о том, что этот порт использует что-то другое. Поэтому я увидел свой старый веб-сайт из предыдущей сборки и удалил его из IIS вместе с соответствующим пулом приложений. Затем я запустил пул приложений для веб-сайта из новой сборки и зашел на сайт. Успех. Затем я зашел на сайт из браузера на моем собственном ПК. Удачи снова. Затем я запустил сканирование по полному URL, а не по имени сервера, например:

http://sharepoint.portal.fake.com

Успех снова. Он просканировал весь портал, включая дочерние сайты, как я и хотел. «Предметы в индексе» заполнились быстро, и я мог сказать, что катился.

Я по-прежнему не могу получить доступ к сайту центрального администратора, размещенному на servername4, из servername5. Я не уверен, почему нет, но я не знаю, насколько это важно в данный момент.

Где это меня оставляет? Что это было за исправление?

Я все еще не уверен. Может быть, это была перестройка. Возможно, как только я перестроил ферму серверов, у меня было все, что нужно, чтобы она заработала, но она просто не сработала из-за предыдущего веб-сайта, все еще работающего в IIS. (Забавно, насколько небрежной может быть деинсталляция SharePoint. Ручное удаление баз данных контента, веб-сайтов и пулов приложений кажется необходимым, и, вероятно, этого не должно быть.)

В любом случае, теперь он работает на моей "тестовой" ферме, поэтому ключ заключается в том, чтобы заставить ее работать на рабочей ферме. Я надеюсь, что после этого опыта это будет не так сложно.

Спасибо за помощь от всех!

Answer 6

В разделе «Службы на сервере» проверьте свойства учетной записи обхода при поиске, чтобы убедиться, что она настроена и имеет разрешения на доступ к этим сайтам.