Недавно мне пришлось обновить WSS 3.0 на Sharepoint Foundation 2010. Я хотел бы поделиться своим опытом, а также рассказать о проблемах, которые Microsoft «скрывает» от нас.
Предисловие: Службы Windows Sharepoint были установлены как автономный сервер с использованием внутреннего ядра СУБД Windows. Я хочу обновить свою ферму до Sharepoint 2010 Foundation. Остальное под катом.
Для тех, кому интересен окончательный порядок работы, смотрите внизу статьи.
Microsoft предоставляет полное (как кажется на первый взгляд) руководство по этой процедуре.
здесь .
Короче говоря, Microsoft предлагает следующую процедуру: 1) Установите все необходимое программное обеспечение (предварительные условия) с диска/дистрибутива Sharepoint 2010 Foundation. 2) Установите Sharepoint 2010 Foundation. 3) После установки выберите обновление существующей фермы WSS 3.0. 4) Готово.
Жаль, но все оказывается не так просто.
В описание поддерживаемых/неподдерживаемых В путях обновления указано, что Sharepoint 2010 Foundation НЕ поддерживает ядро внутренней базы данных Windows. Тогда первое, что мне приходит в голову — установить на сервер SQL Server Express 2008 и указать его при обновлении.
ВНИМАНИЕ! SQL-сервер должен иметь архитектуру x64; установщик Foundation отказывается развертывать базу данных на x32. Собственно, я так и делаю, но оказывается, что изменить SQL-сервер при обновлении НЕВОЗМОЖНО.
В окне обновления Sharepoint 2010 выбран сервер внутренней базы данных Windows, установщик успешно запускает обновление и получает ошибку о том, что у него недостаточно прав на SQL-сервере.
Ну, это странно.
В этом случае установщик «убивает» ферму WSS 3.0. Дальнейшие действия, как с помощью портала администрирования, так и с помощью утилиты сцадм , абсолютно невозможны.
Как восстановить функциональность WSS 3.0? Я решил восстановить WSS 3.0 непосредственно на SQL-сервере, чтобы еще раз попробовать обновление на месте: 1) Используя оснастку SQL Server Management Studio, подключитесь к внутренней базе данных Windows и сделайте резервную копию баз данных.
SharePoint_Config И SharePoint_AdminContent_xxxx-xxxx-xxxx-xxxx-xxxxxxxxx (WSS использует эти две базы данных для хранения настроек).
База данных с содержимым (имя WSS_Content по умолчанию) я просто отсоединяюсь (отсоединяюсь).
2) Далее переустанавливаю WSS (удаляю, переустанавливаю, устанавливаю все Service Pack).
В процессе установки я указываю экземпляр SQL-сервера (в расширенном режиме), а не внутреннюю базу данных Windows. 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. Нажимаю «Далее» и.
опять он ругается на отсутствие прав на экземпляре внутренней базы данных Windows. "Как?!" - Я думаю.
Это означает, что помимо всего прочего 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: Ошибка во время шифрования или дешифрования.
Решения приведены в эта КБ Майкрософт не помогает. Варианты, которые я нашел в Интернете (удалить узел «Портал администрирования» в IIS, удалить «Пул приложений» в IIS) не помогают. Я решаю развернуть всё заново, методом отсоединения базы данных, а не In-Place Upgrade. Для этого я заново восстанавливаю WSS-сервер по описанной выше процедуре и: 1) Сохраняю все настройки для сайтов Sharepoint (в моем случае это 1 сайт сайт ).
2) Теперь я удаляю WSS и устанавливаю его «чистую» версию (только шаги 1 и 2 вышеописанной процедуры).
3) Удалите SharePoint 2010 Foundation. 4) Делаю перезагрузку 5) Я переустанавливаю SharePoint 2010 Foundation в автономном режиме.
После завершения установки установщик предлагает мне обновить существующую («чистую») WSS-ферму — я соглашаюсь.
На этот раз обновление происходит без проблем.
6) В центре администрирования SharePoint 2010 Foundation я создаю сайт с настройками, записанными на шаге 1. Прошу мастера использовать существующий сайт IIS (который был создан в WSS).
В качестве базы данных контента я указываю новую базу данных на экземпляре SQL (WSS_Content_Temp), которую затем удалю.
7) Прикрепляю (подключаю) базу данных WSS_Content к SQL-серверу.
8) По это руководство Я обновляю и присоединяю базу данных с содержимым к SharePoint 2010 Foundation с помощью команды: cd «C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Bin» stsadm –o addcontentdb –url сайт –имя базы данных WSS_Content –сервер базы данных NEWSERVER\NEWINSTANCE 9) Идет процесс обновления.
После этого я удаляю базу данных WSS_Content_Temp из узла в центре администрирования SharePoint. 10) Вуаля.
Вообще мне непонятны две вещи: почему установщик не проверяет необходимые требования и выдаёт ошибки, которые совершенно не соответствуют действительности? Но это скорее риторический вопрос.
Теги: #sharepoint #sharepoint 2010 Foundation #SharePoint 2010 #Системное администрирование #windows SharePoint Services #обновление WSS #sharepoint
-
Нуристанские Языки
19 Oct, 24 -
Лингвистическая Просодия
19 Oct, 24 -
Gps-Сервисы Для Животных: С Нами И С Ними
19 Oct, 24 -
«Концепции» В C++
19 Oct, 24 -
Третий Google — Как Пятый Битлз
19 Oct, 24
