Обновление WSS 3.0 -> Sharepoint 2010 Foundation, или верный путь к Disaster Recovery

в 8:42, , рубрики: sharepoint, sharepoint 2010, windows, системное администрирование, метки: , ,

Недавно мне пришлось обновлять WSS 3.0 на Sharepoint Foundation 2010. Хочу поделится опытом, а также рассказать о проблемах, которые Microsoft «прячет» от нас.
Предисловие:
Windows Sharepoint Services был установлен как Stand-alone сервер, использует Windows Internal Database Engine. Хочу обновить ферму до Sharepoint 2010 Foundation. Остальное — под катом. Кому интересна финальная рабочая процедура – в нижнюю часть статьи.

Microsoft приводит полное (как сперва кажется) руководство к данной процедуре тут.

Вкратце, Microsoft предлагает следующую процедуру:
1) С диска/дистрибутива Sharepoint 2010 Foundation устанавливаем все необходимое ПО (prerequisites)
2) Устанавливаем Sharepoint 2010 Foundation
3) После установки выбираем обновление существующей фермы WSS 3.0
4) Готово.
Жаль, но все оказывается не так просто.

В описании поддерживаемых/неподдерживаемых путей обновления сказано, что Sharepoint 2010 Foundation НЕ поддерживает Windows Internal Database Engine. Тогда первое, что приходит мне в голову: установить на сервер SQL Server Express 2008 и при обновлении указать его.
ВНИМАНИЕ! SQL-сервер должен быть обязательно x64 архитектуры, на x32 инсталлятор Foundation базы разворачивать отказывается.

Собственно я так и поступаю, но, оказывается, при обновлении НЕВОЗМОЖНО изменить SQL-сервер. В окне обновления Sharepoint 2010 выбран сервер Windows Internal Database, инсталлятор успешно начинает обновление и выпадает в ошибку о том, что ему не хватает прав на SQL-сервере. Что ж, странно…

При этом инсталлятор «убивает» ферму WSS 3.0. Дальнейшие действия, как с помощью портала администрирования, так и с помощью утилиты stsadm, абсолютно невоможны.

Как восстановить работоспособность WSS 3.0? Я решил восстановить WSS 3.0 сразу на SQL-сервер, чтобы попробовать In-Place Upgrade еще раз:
1) С помощью оснастки SQL Server Management Studio подключаемся к Windows Internal Database и делаем бекап баз SharePoint_Config и SharePoint_AdminContent_xxxx-xxxx-xxxx-xxxx-xxxxxxxxx (именно эти 2 базы WSS использует для хранения настроек). Базу данных с содержимым (название WSS_Content по-умолчанию) я просто отсоединяю (detach).
2) Далее я переустанавливаю WSS (удаляю, ставлю заново, ставлю все Service Pack). В процессе установки указываю инстанс SQL-сервера (в расширенном режиме), а не Windows Internal Database.
3) После завершения установки и обновления я останавливаю службы WSS 3.0, подключаюсь SSMS к SQL-инстансу и наблюдаю там 2 базы: новую SharePoint_Config и SharePoint_AdminContent… Они мне не нужны, поэтому смело их удаляю и разворачиваю бекапы этих баз на SQL-инстанс (в моем случае SQL Server Express 2008 R2).
4) Стартую службы WSS. При этом WSS отлично работает, как раньше.

Кажется вот оно – можно обновляться, теперь проблем не будет, все же ведь на SQL-сервере. Я еще раз запускаю Мастер обновления WSS -> Sharepoint 2010. И, о чудо, теперь в окне визарда указан SQL-инстанс. Нажимаю «Next» и… опять ругается на недостаток прав на инстансе Windows Internal Database. «Как?!» — думаю я. Значит, помимо всего, WSS хранит имя сервера/инстанс где-то в базе.

Через несколько запросов я нашел таблицу и строки, где это хранится: база SharePoint_Config, таблица dbo.Objects.
Следующим запросом мы можем изменить эти данные:
USE [SharePoint_Config]
ALTER TABLE dbo.Objects
SET Name=’NEW INSTANCE NAME’
WHERE Name=’OLD INSTANCE NAME’
SET Name=’NEW SERVER NAME’
WHERE Name = ‘OLD SERVER NAME’

Повторно запускаю визард обновления. И, ура, первый шаг успешно проходит без ошибок, связанных с базой. Но, к сожалению, на втором этапе я получаю ошибку ERR Exception: System.ArgumentException: Error during encryption or decryption.
Решения, приведенные в этом KB от Microsoft не помогают. Варианты, которые я нашел в Интернете (удалить Administration Portal узел в IIS, удалить App Pool в IIS) не помогают.
Я принимаю решение развернуть все заново, методом детача баз, а не In-Place Upgrade.

Для этого я снова восстанавливаю WSS-сервер по описанной выше процедуре и:
1) Сохраняю все настройки сайтов Sharepoint (в моем случае это 1 сайт site).
2) Теперь я удаляю WSS и ставлю «чистый» его вариант (только шаги 1 и 2 вышеописанной процедуры).
3) Удаляю SharePoint 2010 Foundation
4) Делаю ребут
5) Заново устанавливаю SharePoint 2010 Foundation в Stand-alone режиме. Инсталлятор после завершения установки предлагает мне обновить существующую («чистую») ферму WSS – соглашаюсь. На этот раз обновление происходит без проблем.
6) В центре администрирования SharePoint 2010 Foundation создаю сайт с настройками, которые я записал в п.1. Прошу визард использовать существующий IIS-узел Site (который был создан в WSS). В качестве БД содержимого указываю новую БД на SQL-инстансе (WSS_Content_Temp), которую я потом удалю.
7) Присоединяю (attach) базу WSS_Content к SQL-серверу.
8) По данному мануалу обновляю и присоединяю базу с содержимым к SharePoint 2010 Foundation командой:
cd “C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14Bin”
stsadm –o addcontentdb –url site –databasename WSS_Content –databaseserver NEWSERVERNEWINSTANCE
9) Проходит процесс обновления. После него удаляю базу WSS_Content_Temp из узла в центре администрирования SharePoint.
10) Вуа-ля.

В общем и целом мне неясно 2 вещи: почему инсталлятор не проверяет необходимые требования и выдает абсолютно не соответствующие действительности ошибки? Но это скорей риторический вопрос…

Автор: pportnoy

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js