 |
|
|
|
Три способа миграции с SPS 2003 на MOSS 2007
Три способа миграции с SPS 2003 на MOSS 2007 Переход к новым версиям продуктов Sharepoint потребует от системного администратора не только времени, но и предварительной теоретической подготовки. Хотя бы потому, что осуществить миграцию можно как минимум тремя способами. В июльском номере вы познакомились с особенностями новой версии портала Microsoft Sharepoint [6]. Если ранее вы активно использовали его предыдущую версию, то обновление портала потребует от вас немало времени и усилий. Миграция с Sharepoint Portal Server 2003 на Microsoft Office Sharepoint Server 2007– задача трудоемкая, особенно если портал подвергался кастомизации и редизайну, в частности:
Если же в SPS 2003 использовались только стандартные средства создания и редактирования страниц с помощью встроенного веб-интерфейса, то вероятность возникновения проблем в ходе перехода на новую версию значительно ниже. Выбор способа миграции Microsoft предлагает три способа миграции на новую версию продукта:
Эти три версии используются как для миграции Sharepoint Portal, так и для перехода с WSS 2.0 на WSS 3.0. Плюсы и минусы использования каждого варианта миграции приведены в таблице. Преимущества и недостатки способов миграции
Миграция in-place рекомендуется в случаях, когда все компоненты Sharepoint установлены на одном сервере и портал не подвергался серьезной кастомизации. Постепенное обновление рекомендуется для фермы серверов в случаях, когда важен минимальный перерыв в работе портала, или в случаях, когда удобнее переносить узлы по очереди (например, миграция отдельных узлов потребует много времени в результате значительной кастомизации). Миграция баз данных особенно удобна, когда нужно не просто перейти на новую версию продукта, но и перенести всю систему на другое аппаратное обеспечение. Впрочем, имеется еще один нюанс выбора способа обновления. В процессе миграции тем или иным способом иногда возникают неизвестные ошибки, не описанные в руководствах. Некоторые возможные проблемы и способы их решения приведены в разделе «Возможные ошибки». В отдельных случаях журналы обновления и сообщения об ошибке не содержат достаточно информации для ее идентификации и исправления. В таких случаях иногда проще попробовать альтернативный способ миграции. Подготовка к миграции Настоятельно рекомендуется сделать полную копию рабочей системы и опробовать миграцию сначала на тестовой копии. Правильный путь – тестовую копию разворачивать на виртуальной машине. Сначала восстановите полную копию рабочего портала SPS 2003, затем сохраните состояние виртуальной машины. Это сэкономит вам время – если один из способов миграции не подойдет и понадобится попробовать другой, вам не нужно будет снова восстанавливать копию SPS 2003, достаточно вернуться к нужному состоянию виртуальной машины. Если вы собираетесь применить способы gradual upgrade или database migration, то сохраните состояние виртуальной машины и сразу же после установки MOSS 2007, также с целью создания точки возврата. Перед началом миграции убедитесь, что у вас установлен Service Pack 2 для SPS 2003. Для обновления также понадобится WSS 3.0 Language Pack для русского языка, который можно скачать на сайте Microsoft: http://www.microsoft.com/downloads/details.aspx?displaylang=ru&FamilyID=36ee1bf0-652c-4e38-b247-f29b3eefa048. Само собой разумеется, перед окончательной миграцией рабочего портала необходимо сделать полную резервную копию:
Перед началом установки новой версии портала необходимо установить .NET Framework 3.0 и в настройках IIS разрешить ASP.NET 2.0 (см. рис. 1).
Рисунок 1. Настройка .NET 2.0 для IIS Первым делом перед началом миграции необходимо запустить утилиту prescan.exe. Ее можно скачать по адресу http://go.microsoft.com/fwlink/?LinkId=92383 или найти по адресу «%PROGRAMFILES%\Common Files\Microsoft Shared\web server extensions\12\BIN», после установки новой версии портала. Для первых двух способов обновления выполнить предварительное сканирование нужно до запуска мастера конфигурации и настройки. Для сканирования всего портала запустите команду: prescan.exe /c preupgradescanconfig.xml /all Для сканирования отдельного узла: prescan.exe /c preupgradescanconfig.xml /v URL Результаты работы утилиты сохраняются в файлах PreupgradeReport_uniqueID_Log.txt и PreupgradeReport_uniqueID_Summary.xml во временной папке пользователя, который запускал сканирование, например, «%SYSTEMDRIVE%:\Documents and Settings\admin\Local Settings\Temp». По файлам нужно запустить поиск по слову «error» и найти сообщения об ошибках. Кроме того, в этих файлах можно найти предупреждения о том, какие узлы и страницы были модифицированы, вследствие чего при их миграции могут возникнуть проблемы, и статистику по их числу. В частности, обратите внимание на записи:
Руководства по миграции портала не содержат описаний всех возможных ошибок и способов их решения. Однако запустить эту утилиту все же необходимо. Во-первых, без запуска этой утилиты процесс миграции просто-напросто не запустится. Во-вторых, если в ходе миграции возникнут проблемы, вы будете знать их возможный источник. Наконец, в-третьих, вы будете иметь под рукой список потенциально проблемных узлов, страниц и веб-частей. Несколько распространенных ошибок, на которые указывает утилита prescan, описаны в разделе «Возможные ошибки». Перед началом миграции необходимо определиться, каким образом поступить с кастомизированными определениями узлов (customized site definitions), если они имеются на портале. Один из вариантов – создать специальные файлы апгрейда определений (uprgade definitions). Подробную информацию о структуре этих файлов можно найти в Office 2007 SDK [3]. Разместить файлы апгрейда определения узлов (upgrade definition files) необходимо до начала миграции в папке «%PROGRAMFILES%/Common Files/Microsoft Shared/Web server extensions/12/CONFIG/UPGRADE». Другие варианты адаптации определений узлов будут рассмотрены дальше (см. раздел «Действия после миграции»). Если выбраны способы gradual upgrade или database migration, проверьте, достаточно ли на сервере баз данных дискового пространства, чтобы поддерживать по две копии содержимого портала. После завершения тестовой миграции просмотрите все узлы или хотя бы наиболее важные. Особое внимание уделите кастомизированным узлам и страницам, а также тем, которые упоминались в отчете программы prescan. Рекомендуется провести тестовую миграцию до конца, включая post-upgrade шаги (см. раздел «Действия после миграции») и довести тестовую систему до полностью рабочего состояния, тщательно записывая все предпринятые действия и сохраняя все необходимые файлы. Во-первых, это значительно сократит процесс перехода основной, рабочей системы. Во-вторых, вы оцените, сколько времени вам понадобится на полное восстановление работоспособности портала. Если это достаточно большое время, возможно, стоит выбрать gradual upgrade, чтобы переводить узлы поочередно, или database migration, чтобы подготовить необходимую среду заранее. Рассмотрим подробнее способы миграции. In-place-миграция Это самый простой и быстрый способ миграции. Запустите программу установки Microsoft Office Sharepoint Server. Выберите способ «Автоматическое обновление» (см. рис. 2).
Рисунок 2. Установка портала с автоматическим обновлением Когда программа установки завершит свою работу, запустится «Мастер настройки продуктов и технологий Microsoft». По запросу мастера или до его запуска установите WSS 3.0 Language Pack для русского языка. В ходе работы мастера введите необходимые параметры: номер порта для узла центрального администрирования и способ аутентификации (этот шаг может быть пропущен при установке на standalone-сервер) (см. рис. 3).
Рисунок 3. Настройка нового портала с помощью мастера После завершения настройки откроется страница с информацией о ходе обновления портала. Остается лишь дождаться его окончания (см. рис. 4).
Рисунок 4. Выполнение автоматического обновления Теперь можно переходить к главной странице центра администрирования со списком первоочередных задач по настройке новой версии портала (см. рис. 5).
Рисунок 5. Центр администрирования после обновления Если миграция проводится для фермы серверов, то необходимо сначала установить новую версию продукта на всех серверах фермы, затем поочередно на каждом сервере запустить «Мастер настройки», начиная с того сервера, где будет располагаться узел центрального администрирования. Gradual-миграция Запустите программу установки Microsoft Office Sharepoint Server. Выберите постепенный способ обновления. Проведите установку и настройку с помощью «Мастера настройки продуктов и технологий Microsoft». По запросу выберите «Создать новую базу данных конфигурации» и укажите необходимые параметры (см. рис. 6).
Рисунок 6. Параметры базы данных конфигурации Далее укажите по запросу номер порта для узла центрального администрирования и способ аутентификации (NTLM или Kerberos). Когда работа мастера завершится и откроется страница центрального администрирования, в списке задач администратора можно найти все необходимые действия для миграции узлов на новую версию со ссылками на русскоязычную справку (см. рис. 7).
Рисунок 7. Задание для администратора по обновлению портала Для начала миграции нужно перейти на вкладку «Операции» центра администрирования и выбрать раздел «Обновление и перенос -> Состояние обновления содержимого узла». Откроется список веб-приложений старой версии портала. Нажмите кнопку «Начать обновление» рядом с желаемым приложением (см. рис. 8).
Рисунок 8. Начать обновление веб-приложения Теперь нужно задать адрес для старой версии веб-приложения и указать параметры для новой версии: пул приложений, способ аутентификации, имена баз данных и сервер индексирования. Некоторое время придется подождать завершения изменений. После этого можно продолжить обновление – перейти к поочередной миграции узлов. Начинать обновление семейства узлов нужно всегда с корневого узла «/» (см. рис. 9, 10).
Рисунок 9. Выбираем узлы для обновления
Рисунок 10. Дожидаемся завершения обновления узлов Помимо веб-интерфейса, узлы можно обновлять с помощью утилиты командной строки stsadm. Утилита находится по адресу: «%PROGRAMFILES%\Common Files\Microsoft Shared\web server extensions\12». Чтобы получить список всех узлов, которые необходимо обновить, выполните команду: stsadm -o enumsites -url http://server_name –redirectedsites Чтобы обновить отдельный узел, нужно выполнить команду: stsadm.exe -o upgrade -sidebyside -url http://server_name/sites/site_name Подробный список параметров утилиты stsadm с описаниями можно найти в 2007 Office Resource Kit [2]. После завершения миграции всех узлов нужно воспользоваться опцией «Завершить обновление» в разделе «Обновление и перенос». Затем Sharepoint Portal 2003 можно удалить. Как показывает опыт, этот способ миграции – самый проблемный. В ходе обновления могут возникать неизвестные ошибки, которые достаточно трудно определить и устранить. Чтобы не тратить на это слишком много времени, если ошибка возникла еще до начала обновления узлов, можно попробовать использовать на уже установленном портале третий вариант миграции – с присоединением баз данных. Database migration Этот способ наиболее трудоемкий, однако при этом обновление портала удобно сочетать с переносом на другой сервер. Сначала необходимо установить с нуля MOSS 2007 либо на новом сервере, либо на том же самом с выбором опции «Не выполнять обновление». Затем необходимо выполнить настройку с помощью мастера, как это описано для постепенного обновления. После завершения работы мастера откроется сайт центрального администрирования. Необходимо создать по веб-приложению и соответствующему семейству узлов для каждого виртуального сервера предыдущей версии портала. Для фермы серверов и веб-приложений необходимо вручную выполнить настройку различных параметров: исходящий почтовый сервер, параметры безопасности, часовой пояс, квоты на размер файлов, управляемые пути и другие параметры [6]. Рекомендуется также подготовить заранее необходимую среду: установить сторонние и собственные веб-части, подобрать подходящую тему, настроить оформление, разработать новые определения узлов и стилевые таблицы. Перед началом миграции на старом портале необходимо сделать базы данных содержимого старого портала доступными только для чтения, чтобы пользователи не смогли внести никаких изменений после начала перехода. Не забудьте выполнить резервное копирование баз данных перед началом миграции. Затем необходимо выполнить присоединение баз данных содержимого с помощью утилиты stsadm. Начинать нужно обязательно с базы данных содержимого, в которой находится главный узел портала. Для присоединения выполните команду: stsadm -o addcontentdb -url <http://newportalname> -databaseserver <dbservername> –databasename <portalname_SITE> -databaseuser <username> -databasepassword <password> Напомню, что по умолчанию в портале создается одна база данных содержимого – «Первые_8_Букв_Названия_Портала1_SITE». Однако личные узлы пользователей (My sites), если они имеются на портале, содержатся в другой базе данных – «Первые_8_Букв_Названия_Портала1_PROF». Для миграции этой базы данных операция «addcontentdb» не используется. Восстановить личные узлы можно при восстановлении общих служб, после присоединения основной базы данных содержимого. Сначала создайте веб-приложение для поставщика общих служб и семейство узлов, где будут располагаться личные узлы, например: stsadm -o createweb -url <mysiteurl> -sitetemplate SPSMSITEHOST -title "Личные узлы" Затем выполните команду: stsadm -o restoressp -title <Restored_SSP> -url <ssp_url> -ssplogin <domain\ssp_login> -mysiteurl <mysiteurl> \ -indexserver <indexservername> -indexlocation <pathtoindex> -keepindex -sspdatabaseserver <dbservername> \ -sspdatabasename <portalname_PROF> -ssppassword <password> По умолчанию индексы (параметр indexlocation) располагаются по адресу: «%PROGRAMFILES%\Microsoft Office Servers\12.0\Data\Office Server\Applications». После этого перезагрузите IIS и проверьте настройки личных сайтов на странице администрирования поставщика общих служб. Обновленные личные узлы будут доступны как по адресу mysiteurl, так и по ссылке «Мой узел» с главной страницы портала. После завершения миграции не забудьте сделать редирект со старого сервера Sharepoint на новый. Сделать это можно средствами самого IIS (см. рис. 11).
Рисунок 11. Настройка перенаправления с помощью IIS Если вы хотите сохранить SPS 2003 для других целей, лучше переместить его на другой порт или другое доменное имя, чтобы по старым, привычным пользователям адресам происходило автоматическое перенаправление на новый портал. «Продвинутый» способ миграции «Продвинутый» способ предполагает использование для миграции промежуточного сервера. Этот вариант актуален для масштабных систем, которые были значительно модифицированы под целевые задачи, и удобен для порталов публикации с редко изменяемым контентом. Также его имеет смысл использовать, если необходимо «перестраховаться»: минимизировать вероятность неполадок и время простоя, исключить ситуацию, когда в результате ошибки в ходе миграции узла не доступна ни старая, ни новая версия этого узла. Последовательность действий при «продвинутом» способе миграции следующая:
Такой вариант позволяет осуществлять полный перевод портала или постепенный перевод семейств узлов на новую версию с гарантированной работоспособностью. При этом старые версии узлов на время адаптации новой версии можно оставить доступными для чтения пользователями. Однако при этом требуются дополнительные аппаратные ресурсы. Промежуточный сервер рекомендуется установить на виртуальной машине. Во-первых, чтобы иметь несколько возможных точек возврата (в виде сохраненных состояний виртуальной машины), во-вторых, чтобы иметь возможность переносить семейства узлов поэтапно. Копирование узла осуществляется с помощью утилиты stsadm. Для SPS 2003 она располагается по адресу «%PROGRAMFILES%\Common Files\Microsoft Shared\web server extensions\60», а для MOSS 2007 – по адресу «%PROGRAMFILES%\Common Files\Microsoft Shared\web server extensions\12». Для копирования семейства узлов необходимо выполнить команду: stsadm.exe –o backup –url http://servername/sitecollectionname -filename SiteCollectionBackup.dat Для восстановления семейства узлов из копии: stsadm.exe –o restore –url http://servername/sitecollectionname -filename SiteCollectionBackup.dat Полное описание опций копирования/восстановления можно найти в 2007 Office Resource Kit [2]. В общем и целом «продвинутый» способ значительно снижает вероятность возникновения критичных ошибок на «боевой» системе, позволяет администратору проявить фантазию и подобрать вариант миграции, наиболее подходящий к конкретной системе. Однако при этом необходимо тщательно следить за адресами узлов и в нужный момент настраивать редирект и/или оповещать пользователей о новом адресе узла. Кроме того, некоторые настройки (развертывание веб-частей, например) выполняются на уровне сервера, а не на уровне узла, и их придется выполнить на двух серверах. Возможные ошибки в ходе миграции Какие ошибки возникают во время миграции, в большей степени зависит от конкретного портала, его настроек и модификаций. Ряд ошибок и способы их устранения описаны в базе знаний Microsoft: http://support.microsoft.com/kb/937291. Здесь я перечислю некоторые достаточно часто возникающие проблемы. При восстановлении SPS 2003 из резервной копии возникает ошибка: «Illegal character path». В названии вашего портала встречаются кавычки, например, Портал ООО «Рога и копыта», или другой специальный символ. Для исправления перейдите к новой (восстановленной) базе содержимого и запустите скрипт (пример для кавычек): begin tran declare @s as nvarchar(4000) SELECT @s=replace (cast(PortalRecoveryBackup as nvarchar(4000)), '"', '') FROM PortalProperties print @s update PortalProperties set PortalRecoveryBackup = @s select PortalRecoveryBackup from PortalProperties -- ок? commit При восстановлении SPS 2003 из резервной копии или попытке миграции баз данных возникает ошибка: «Схема базы данных устарела», или в журнале утилиты prescan указана ошибка: «Exception while looping through virtual servers». Проверьте, установлен ли для SPS 2003 второй сервис-пак и все вышедшие патчи. Миграция прерывается с ошибкой, а в журнале утилиты prescan можно найти ошибки: « The following site has not been scanned…» или «There is no Web named…» или «FAILED to persist field schema of lists in web». Эта ошибка возникает, если в базе данных содержимого имеются «осиротевшие», т.е. оставшиеся без родителей объекты. Например, остался документ из удаленной библиотеки или сайт пользователя, профиль которого был удален. Для исправления ошибки нужно скачать hotfix с сайта Microsoft и выполнить команду: stsadm -o databaserepair -url http://siteurl -databasename databasename -deletecorruption Подробная информация и ссылка на hotfix здесь: http://support.microsoft.com/kb/918744. В процессе миграции возникает ошибка: «Violation of UNIQUE KEY constraint 'AllUserData_Url'. Cannot insert duplicate key in object 'dbo.AllUserData'». Эта ошибка возникает, если на портале есть несколько обсуждений (Discussion boards) с одинаковыми названиями. Для ее исправления необходимо дать каждому обсуждению уникальное имя, например, с помощью Front Page (подробности здесь: http://support.microsoft.com/kb/937290/en-us). Если таких объектов много, можно написать небольшой скрипт. Мастер настройки завершает работу с ошибкой, а в логе содержится ошибка «The pre-upgrade scan tool has not yet been run on this database…». По всей видимости, вы забыли запустить утилиту prescan перед началом работы мастера. Страница администрирования или главный узел портала после миграции не открываются или выдается ошибка «Service unavailable». Чаще всего это связано с неправильной регистрацией ASP .NET 2.0. Чтобы исправить ошибку, нужно заново зарегистрировать .NET 2.0 (выполнить команду «aspnet_regiis -ir» из директории «%windir%\Microsoft.NET\Framework\v2.0.xxxx»), проверить, правильно ли указана версия .NET в настройках сайта IIS «Центр администрирования Sharepoint» (или другого веб-приложения, с которым возникли проблемы), и перезапустить IIS. Также эта проблема возникает, если указан неправильный пул приложения или некорректная учетная запись для его работы. Эти настройки можно проверить и вручную исправить в панели управления IIS. Действия после миграции После завершения процесса миграции чаще всего требуются дополнительные действия, чтобы адаптировать внешний вид новой версии портала, а также полностью восстановить его работоспособность. Перечислю те моменты, на которые нужно обратить особое внимание. Протокол обновления После завершения миграции рекомендуется просмотреть протокол обновления на предмет возможных ошибок. Файл называется Upgrade.log и располагается по адресу «%PROGRAMFILES%\Common Files\Microsoft Shared\web server extensions\12\LOGS». Настраиваем редирект Если использовался способ database migration или «продвинутый» способ миграции, не забудьте настроить перенаправление со старых адресов портала на новые. Доступ администраторов После миграции у администратора может пропасть доступ к некоторым узлам. Дело в том, что по умолчанию в новом портале администратор не имеет доступа ко всему содержимому портала. Его нужно либо вручную назначить администратором каждого семейства узлов, либо воспользоваться политикой для веб-приложения в разделе «Безопасность приложений» вкладки «Приложения» центра администрирования портала и дать права полного доступа для всех узлов приложения (см. рис. 12).
Рисунок 12. Определение прав доступа с помощью политики веб-приложения Веб-части Если у вас есть веб-части собственной разработки, в большинстве случаев их необходимо перекомпилировать под .NET 2.0 и заново развернуть на портале. Если вы использовали веб-части сторонних разработчиков, вероятно, придется запросить версии для нового портала. Прежде чем это делать, ознакомьтесь подробно с новым функционалом Sharepoint 2007, возможно, для решения тех же задач появились встроенные веб-части. Например, для чтения потоков RSS или построения карты сайта теперь нет необходимости устанавливать веб-части сторонних разработчиков, т.к. имеются стандартные. Поиск После миграции скорее всего поиск придется настраивать заново. Настройки поиска находятся на странице администрирования общих служб. Проверьте и при необходимости перенастройте список источников содержимого, список областей поиска и расписания обхода. Профили пользователей Также необходимо заново настроить синхронизацию профилей пользователей с Active Directory. Сделать это в новом портале очень просто и удобно, настройки находятся на странице администрирования поставщика общих служб. Резервное копирование MOSS 2007 не ограничивается тремя базами данных для хранения информации, поэтому не забудьте перенастроить резервное копирование с учетом всех используемых баз. Подробнее об этом рассказано в статье [6]. Внешний вид С внешним видом, если он был сильно изменен по сравнению со стандартным оформлением, придется повозиться. В новом портале другие темы и стилевые таблицы. Некоторые настройки стало делать проще, например, вставлять свой логотип или управлять левой и верхней панелями ссылок. И тем не менее, адаптации внешнего вида придется уделить достаточно времени. Unghosted pages Больше всего проблем после миграции возникает с кастомизированными определениями сайтов и так называемыми «отсоединенными страницами» (unghosted pages). Если страница SPS 2003 хотя бы один раз открывалась в Microsoft Frontpage, даже без сохранения изменений, то она становилась unghosted, т.е. отсоединенной от определения узла. Такие страницы после миграции портала остаются без изменений. Обратного их присоединения автоматически не происходит, а внешний вид остается такой же, как на старом портале. Если вы хотите использовать возможности нового портала на таких страницах или привести их внешний вид в соответствие с основным новым порталом, то можно выполнить «Возврат к определению узла». Для этого нужно открыть узел, перейти к его параметрам и выбрать соответствующий пункт меню в разделе «Внешний вид и функции». Здесь можно «вернуть» как отдельную страницу, так и узел целиком. Это же действие можно выполнить в Sharepoint Designer (см. рис. 13).
Рисунок 13. Возврат к определению узла Однако с этим инструментом нужно быть очень осторожным! Если страница была создана с нуля и в определении узла не может быть найдено подходящее соответствие, такой возврат, как показывает практика, может привести к полной неработоспособности страницы. Поэтому возврат нужно обязательно проверять на тестовой системе. Если вы на 100% уверены, что возврат пройдет нормально, то можно при выполнении миграции с помощью утилиты psconfig указать ключ для автоматического возврата всех страниц к определению узла: psconfig.exe -cmd upgrade -reghostonupgrade Определения узлов Что касается кастомизированных определений узлов, то их, по всей видимости, придется переделывать заново. Если, конечно, вы не использовали файлы обновления определений. Рекомендуемый способ – выполнить возврат к определению узла, а затем внести необходимые изменения в шаблоны страниц (master pages) и раскладки страниц (page layouts). При этом желательно иметь под рукой старую версию узла, чтобы не забыть внести все необходимые детали. Механизм использования master pages появился только в новой версии портала, и вносить изменения в страницы с его помощью значительно удобнее. Можно поступить и по-другому – сначала внести изменения в шаблоны страниц, так, чтобы они соответствовали старому виду узла, затем выполнить возврат к определению. После чего можно встраивать на страницы компоненты нового портала. Веб-сервисы и собственные aspx-страницы В новой версии Sharepoint API также появились изменения. Поэтому веб-сервисы и собственные aspx-страницы, использующие API и объектную модель Sharepoint, необходимо проверить на наличие ошибок. Описание изменений в API можно найти в Sharepoint Server 2007 SDK [3] или по адресу: http://msdn2.microsoft.com/en-us/library/ms581339.aspx. Кроме того, aspx-страницы, работающие в рамках портала, необходимо перекомпилировать под .NET 2.0. Если вы использовали на собственных страницах ссылки на стандартные представления списков или библиотек, проверьте корректность их работы – принципы формирования URL для некоторых из них изменились. Заключение Миграция Sharepoint Portal Server или Windows Sharepoint Services иногда превращается в занимательную головоломку, отнимающую немало сил и времени. Хорошо по крайней мере, что задача эта однократная, хотя отдельные ошибки могут время от времени «всплывать» и после завершения процесса миграции. В основном это некорректное отображение отдельных страниц и веб-частей или же неверные ссылки, поэтому после обновления важно просмотреть все узлы как можно подробнее и попросить пользователей сразу же сообщать обо всех замеченных неисправностях. Однако преимущества новой версии с лихвой окупят страдания администратора. И чем раньше провести обновление – тем лучше, ведь сложность системы и объем содержимого портала растут с каждым днем. Приложение Переход на новую версию и SQL-сервер Как известно, для работы Sharepoint портала необходим Microsoft SQL Server. MOSS 2007 работает как с версией MS SQL Server 2005, так и с предыдущей версией MS SQL Server 2003. Поэтому перед миграцией портала нет необходимости переводить на новую версию SQL Server. Если портал предполагается установить на новом программном обеспечении, удобно совместить миграцию портала и миграцию сервера SQL. Версия 2005 SQL Server позволит использовать дополнительные возможности инструментов Reporting Services при построении бизнес-отчетов. Отличия операций копирования/восстановления и экспорта/импорта Обратите внимание, что выполнять копирование и восстановление можно только для всего семейства узлов! В MOSS 2007 можно выполнять также экспорт/импорт содержимого отдельных узлов с помощью операций export/import утилиты stsadm или средствами Sharepoint Designer. Однако при этом узел, на который выполняется импорт, должен быть уже создан, а узлы, кастомизированные в SPS 2003, могут быть импортированы с ошибками. Возобновление миграции после исправления ошибок Если автоматическое или постепенное обновление завершается с ошибкой, после ее исправления для возобновления миграции можно воспользоваться утилитой psconfig, которая также располагается в папке «%PROGRAMFILES%\Common Files\Microsoft Shared\web server extensions\12». Для возобновления автоматического обновления используется команда: psconfig -cmd upgrade -inplace v2v -wait -force Для постепенного обновления вместо «inplace» необходимо указать «sidebyside». Подробное описание параметров можно получить по команде: «psconfig –help upgrade». Если ошибка возникла на стадии обновления узлов, то достаточно возобновить задание по обновлению в разделе «Обновление и перенос» центра администрирования или запустить обновление узлов заново.
|
Нелли Садретдинова
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
