Блог Ильи Бойко

22-го мая партнерам стал доступен релиз SharePoint 2010 и других офисных продуктов нового покаления. Всвязи с этим у многих компаний встал вопрос о миграции уже развернутых и используемых ферм построенных на SharePoint 2010 RC. В этой статье я отражаю свой опыт и свой путь миграции.

Важно: До того как я начну рассказывать о сути решения, хочется отметить то что корпорация Microsoft официально не поддерживает апгрейдс RC версии на RTM. Описанные мною методологии могут содержать принципиальные ошибки и не точности, так как они основаны на предположениях.

Как мигрировать?!

Конкретные сценарии миграции всегда будут зовисеть от конфигурации вашей фермы, в своём опыте по миграции я исходил из одного важного предположения “В RC версию, новый функционал не добавляется, а соответственно публичные интерфейсы, структуры данных и конфигурации не должны измениться по сравению с RTM”. Исходя из такогопредположения – миграция данных стандартными средствами резервного копирования – должна быть достаточно безопасно.

В исходных данных были:

• Служба метаданных
• Служба профилей
• Веб-части
• Публичный брендированный сайт с настроенными процессами документооборота (Workflows, Visio Services, InfoPath Services)
• Веб-приложения Access Services

Для начала делаем полную резервную копию фермы на SharePoint 2010 RC:

Add-PSSnapin Microsoft.SharePoint.PowerShell
Backup-SPFarm -Directory \\myserver\SPBackup -BackupMethod Full

Миграция сервисов

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

Служба метаданных

Миграция этого сервиса была признана наиболее приоритетной задачей, т.к. данные из справоячников в решении на RC использовались повсеместно. Отказ от миграции, или потеря GUID’ов автматически привело бы к переработке всех процессов и всего контента сайтов и профилей.

Миграция службы была проведена стандартными средствами восстановления из резервной копии, через веб-интерфейс:

1. Служба метаданных была восстановлена из полной резерной копии фермы.
2. Прокси-служба метаданных, так же была восстановлена из полной резервной копии.
3. Служба была связана с центром администрирования и другими приложениями, и указанна в конфигурации “По умолчанию”.

На этом миграция службы завершилась, в дальнейшей работе проблем обнаружено не было.

Служба профилей пользователей

Изначально эта служба была мигрированная также как и предыдущая – резевным копированием и восстановлением. Однако, когда появилось необходимость настроить сенхронизацию учетных записей с внешними источниками данных, оказалось что в службе сохранились старые конфигурации синхронизации, которые мешали произвести нужные настройки в новой ферме. В итоге было принято решение развернуть новую службу профилей и скопировать внеё учётные записи с помощью скрипта PowerShell.

Полную версию скрипта, копирующего профили вы можете найти по ссылке:

http://bkilya.ru/files/MigrateProfiles.ps1.zip

Значимую часть приведу здесь:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.UserProfiles")

$site =  New-Object Microsoft.SharePoint.SPSite(http://oldsite/);
$newsite =  New-Object Microsoft.SharePoint.SPSite("http://newsite/");

$currentContext = [Microsoft.SharePoint.SPServiceContext]::GetContext($site);
$currentContextForNew = [Microsoft.SharePoint.SPServiceContext]::GetContext($newsite);
$profileManager = 

 New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($currentContext);
$profileManagerForNew = 

 New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($currentContextForNew);

foreach ($fromUserProfile in $profileManager.GetEnumerator())
{
    $toUser = 

    $fromUserProfile[[Microsoft.Office.Server.UserProfiles.PropertyConstants]::AccountName].Value

    if($profileManagerForNew.UserExists($toUser) -ne $true) 
    {
       $profileManagerForNew.CreateUserProfile($toUser);
    }

    $toUserProfile = $profileManagerForNew.GetUserProfile($toUser);

    $toUserProfile[[Microsoft.Office.Server.UserProfiles.PropertyConstants]::PreferredName].Value = 

       $fromUserProfile[[Microsoft.Office.Server.UserProfiles.PropertyConstants]::PreferredName].Value;

    $toUserProfile.Commit();
}

$newsite.Close(); $site.Close();

Перед запуском скрипта убедитесь что все копируемые поля присутствуют в новой служюе профилей. Если во время копирования будет возникать ошибка о недоступности того или иного свойства, но приэтом вы уверены в его наличии, то  проблема может быть в производительности сервера, попробуйте замедлить скрипт вставками команды “sleep –s 5”.

После завершения миграции, внесите службу в группу настроек “По умолчанию” для всех веб-приложений.

Далее натройте необходимые правила синхронизации и удалите старую службу.

Веб-части

Можно мигрировать из бекапа, можно переустановить:

PS C:\> Add-SPSolution -LiteralPath C:\MySolutions.wsp
PS C:\> Install-SPSolution -Identity MySolutions.wsp –GACDeployment 

        -WebApplication http://mysharepoint

Миграция семейств сайтов

Как правило это наиболее объемная часть и поэтому эти данные важно перенести автоматизированно.

Для миграции коллекций сайтов есть два варианта:

1. Резервное копирование и восстановление уровня фермы
2. Фрагментарное резервное копирование и восстановление

Второй вариант по моему мнению является наиболее удобным и универсальным, т.к. в первом случае вы получаете развернутую из резервной копии БД, которая может оказаться в мелочах не совместима с версией RTM.

Для выполнения миграции выполните следующие шаги:

1. Сделайте резервную копию семейства сайтов с исходной фермы:
2. Создайте новое семейство сайтов, без шаблона в новой ферме
3. Восстановите резервную копию поверх созданного семейства сайтов

Если восстановление происходит в новом домене, важно не забыть через центр администрирования изменить администратора коллекции сайтов. Иначе вы не сможете зайти на восстановленный сайт.

В качестве заключения