Некоторые аспекты перехода Sharepoint 2007 на платформу Windows Server 2008 R2

В начале этого года мне довелось производить комплексную операцию по переносу SharePoint 2007 на новый сервер Windows Server 2008 R2 с одновременным обновлением SharePoint из Standalone конфигурации до фермы с разнесением на WFE (Web Front End) сервер и выделенный сервер баз данных Microsoft SQL Server 2008. При этом пришлось наткнуться на определенное количество грабель, информацией о которых и хочется поделиться с общественностью.

Перенос баз данных

Самое первое, что давно пугало и долго не давало заняться этой процедурой, это собственно страх переноса баз данных из конфигурации Standalone. Следует отметить, что изначально, когда в нашей организации только задумались о портальных решениях, под задачи SharePoint был выделен физический сервер с Windows Server 2003, на который был установлен SharePoint Server 2003. Затем, опять же не без проблем, была произведена процедура обновления до Microsoft Office SharePoint 2007. И вот настал черед разрастить ферму SharePoint до конфигурации с выделенным сервером баз данных. Не то чтобы производительность SharePoint была неудовлетворительной, отнюдь, по быстродействию он давал фору многим корпоративным приложениям (примерно 300 пользователей на P4 3ГГц, 4ГБ RAM), однако необходимость централизованного управления базами данных, обновление платформы операционной системы SharePoint и перенос SharePoint в виртуальную среду заставили принять именно такое решение.

В итоге в операции переноса баз данных не оказалось ничего страшного, нашлись замечательные статьи Microsoft (http://technet.microsoft.com/en-us/library/cc512725(office.12).aspx, http://technet.microsoft.com/en-us/library/cc263037(office.12).aspx), в которых подробно описаны шаги, которые необходимо произвести. После произведения переноса выяснилось, что из всего многообразия баз данных SharePoint в 90% случаев основную ценность представляют лишь только базы данных контента и база данных SSP. Остальные базы данных – это либо индексы, пересоздание которых обычно не составляет проблемы, либо база данных конфигурации фермы, перенос которой не имеет смысла в случае создания новой фермы SharePoint, либо базы данных сервисов типа SSO, которые как раз и применяются в тех самых 10% случаев, что не было применимо в моем случае.

В итоге сценарий переноса вкратце получается такой:

1. Делается резервная копия базы данных контента и базы данных SSP;
2. Базы данных восстанавливается на выделенном SQL сервере;
3. На новом сервере SharePoint настраивается новая ферма SharePoint 2007 (при этом создается новая база данных конфигурации фермы SPConfig)
4. В новую ферму добавляются базы данных контента и база данных SSP;
5. Осуществляется настройка новой фермы в соответствии с настройками, которые были заданы в прежней ферме.

Подробнее все шаги описаны в официальных руководствах, которыми я и руководствовался при проведении всех операций:

http://technet.microsoft.com/en-us/library/cc262325(office.12).aspx

http://technet.microsoft.com/en-us/library/cc512725(office.12).aspx

Таким образом, был осуществлен переход с физического сервера Windows Server 2003 со Standalone конфигурацией SharePoint и Microsoft SQL Server 2005 на виртуальный Hyper-V сервер с Windows Server 2008 R2 и физический сервер баз данных с Microsoft SQL Serve 2008.

Доступ к WebDAV

Первое время после переезда SharePoint’а на виртуальный сервер все шло просто отлично и, как говорится, «в теле такая легкость образовалась», производительность нового тандема просто поражала. Однако радость была не долгой и первое, с чем пришлось столкнуться, это странная неработоспособность представления проводника. Странность её заключалась в том, что на машинах с Windows 7 при выборе представления проводника возникала ошибка, сообщающая о невозможности отображения библиотеки в представлении проводника, в то время как на компьютерах с Windows XP представление проводника нормально работало. Однако ни в том, ни в другом случае невозможно было получить доступ к библиотекам из проводника Windows, набирая SMB-подобный путь типа \\server\library, и в случае с Windows XP представление проводника имело странный вид в стиле Windows 98:

Конечно же, в первую очередь подозрение пало на сервис веб-клиента (WebClient), который, как известно, различен в Windows XP и Windows 7. Однако никакие манипуляции с этим сервисом ни на стороне клиента, ни на стороне сервера, никакие попытки изменить его настройки не повлияли на ситуацию. Единственным положительным моментом манипуляций с веб-клиентом на Windows 7 стало то, что при его отключении, можно наблюдать ту же самую картину, что и на Windows XP.

Следующим объектом исследований стал компонент WebDAV на IIS 7.5. Конечно же, я много раз убедился, в том, что он установлен. Корректно установлен. Ведь именно благодаря ему (как мне казалось) в SharePoint работает WebDAV. Несколько раз пытался переустановить его… Какое же упорство я проявлял, если бы я знал сразу… Но, не будем забегать вперед. Также я пропускал мимо многочисленные посты экспертов в интернете о том, что SharePoint не нуждается в WebDAV’е от IIS поскольку использует собственные библиотеки для обеспечения функциональности WebDAV.

Наконец изыскания опустили меня до уровня сетевого взаимодействия и, взяв в руки WireShark, я принялся анализировать сетевой траффик на предмет отыскания причин возникающей ошибки. Я обнаружил, что при попытке выбора представления проводника, мой браузер подает HTTP запрос PROPFIND и через некоторое время получает ответ типа HTTP/1.1 405 Method Not Allowed, затем Allow: и перечень допустимых методов. Эти строки, конечно же, не натолкнули меня ни на одну мысль о том, почему это может происходить, кроме одной, самой верной – загрузить их в любимый поисковик. И тут я в очередной раз убедился, что главное в поиске, это не сам поиск, главное в поиске – это точно знать, что искать. Пусть до того момента я безрезультатно перерыл пол интернета с запросами типа IIS7.5+SharePoint+WebDAV и пр., но стоило мне ввести в поисковике PROPFIND+WebDAV+SharePoint, как тут же я наткнулся на статью (http://sharepointinterface.com/2009/12/28/sharepoint-webdav-and-a-case-of-the-405-status-codes), содержание которой заставило меня прослезится. В статье был точь в точь описан мой случай, и самое замечательное заключалось в том, что ее автор, Sean McDonough, нашел-таки выход из ситуации, которая меня заставляла уже лезть на стену.

Прочитав статью, я умилился тем, что Шон прошел примерно такой же путь изысканий, однако оказался более успешен. Вывод, который и он и я сделали для себя в финале этой истории был одинаков – не следует устанавливать компоненты Windows Server впрок. Всему виной оказался тот самый компонент IIS 7.5 WebDAV. Именно он, раньше собственного обработчика WebDAV в SharePoint 2007, перехватывал запросы браузера и некорректно обрабатывал метод PROPFIND, сообщая при этом, что метод не поддерживается. Странно, а ведь я точно помню, что на IIS 6 наличие включенного WebDAV никоим образом не нарушало работоспособности SharePoint 2007.

Таким образом, способом решения проблемы с доступом по WebDAV и представлением проводника стало банальное удаление компонента Веб-публикация DAV для роли Windows Server 2008 R2 Веб сервер (IIS). Удивительно, что Microsoft не позаботились о механизмах совместимости для такого сценария развития событий.

После устранения этой проблемы, я прочитал рекомендуемый Шоном вайтпэйпер (http://www.microsoft.com/downloads/details.aspx?FamilyId=C523AC7A-5724-48BE-B973-641E805588F4&displaylang=en), и многое встало на свои места. Выяснилось, что SharePoint 2007 использует два возможных способа отображения представления проводника, это WebDAV и FPRPC (FrontPage Remote Procedure Calls). Стало ясно, что изначальная странность поведения представления проводника объясняется тем, что SharePoint, обнаружив невозможность функционирования через WebDAV, подсовывал для взаимодействия протокол FPRPC, который, естественно, не мог обеспечить функционала работы по SMB-подобным путям.

Many, many thanks to Sean McDonough!

Максимальный допустимый размер файлов для загрузки в библиотеку документов SharePoint

Следующая проблема, появившаяся на горизонте, исходила из участившихся обращений пользователей, которые сообщали о невозможности загрузки некоторых файлов в библиотеки SharePoint. При загрузке файла возникала ошибка “HTTP 404 Документ не найден”.

Связь с предыдущей проблемой была сразу же отвергнута, поскольку ошибка возникала именно при загрузке через действие Отправить библиотеки документов. Было выяснено также, что ошибка возникает при загрузке больших файлов, и, после ряда экспериментов, удалось даже точно вычислить предельный допустимый размер файла, при котором возникает ошибка. Этот размер соответствовал 300000000 байтам.

Официальные статьи Microsoft по устранению подобных проблем:

http://support.microsoft.com/kb/944981

http://support.microsoft.com/kb/925083/ru

http://support.microsoft.com/kb/942074/

к сожалению не дали результата.

Устранить проблему удалось следующим образом:

В Диспетчере служб IIS на WFE-сервере выбрать раздел Фильтрация запросов, вкладка Правила, затем выбрать в панели Действия пункт Изменить параметры… В открывшемся окне задать параметр Максимальная допустимая длина содержимого (байт) равным или большим размера, указанного в качестве параметра Максимальный объем отправляемых данных для веб-приложений в Центре администрирования.

Заключение

Корпорации Microsoft стоило бы внимательнее относится к совместимости выпускаемых продуктов или, на худой конец, выпускать исправляющие обновления, однако, насколько мне известно, эти проблемы по-прежнему существуют и последние наборы обновлений не содержат механизмов их устранения.