Миграция порталов с SharePoint 2010 на SharePoint 2013. Что изменилось и как с этим жить

В этом топике мы делимся нашим реальным опытом в миграции порталов с 2010 на 2013 SharePoint. Вопрос давно решен, нужно мигрировать, и наверняка руководство уже поставило сроки, когда это должно быть сделано. Вот тут наш материал может оказаться полезным для понимания того, с какой стороны к этому делу подойти. Чтобы не делать огромную статью с кучей специфических вставок технической информации мы сосредоточились на главном — на различиях в миграции с 2007 на 2010 с миграцией 2010 на 2013 и на основных этапах.

Если перед вами стоит еще более сложная задача мигрировать 2007 на 2010, а потом на 2013, почитайте наш прошлогодний материал, там мы уже рассказывали про миграцию портала SharePoint 2007 на SharePoint 2010.

Как всегда рассказываем на практике, начнем со стоящей перед нами задачи:

Перед нами внутренний корпоративный портал:

• Intranet — старый информационный портал со специализированным функционалом и дизайном, разработанный компанией Компания 1, в настоящее время используется в работе несколькими подразделениями компании;
• Intraru2 — новый информационный портал со специализированным функционалом и дизайном, разработанный компанией Компания 2. Также в работе портала задействованы модули, разработанные нами для бронирования переговорных комнат. В настоящее время используется большинством подразделений компании;
• Docflow — портал со специализированным функционалом и дизайном, разработанный компанией Компания 3, используется для документооборота юридическим подразделением;
• HelpdeskCo — портал со стандартным функционалом, используется подразделением ИТ;
• KnowledgeBase — портал со стандартным функционалом, используется подразделением ИТ.

Дополняя картину последними штрихами: на ферме SharePoint установлено более 15 различных Solutions, объем баз контента более 50Гб, а в работе порталов используются различные сервис-приложения:

• служба профилей
• служба поиска
• служба приложений WebApp
• служба метаданных.

Всем этим хозяйством пользуются более 2,5 тысяч юзеров.

Нашей задачей была миграция порталов Intranet, HelpdeskCo, KnowledgeBase и наших модулей бронирования переговорок от портала Intraru2 на Sharepoint 2013. Здесь стоит упомянуть два важных момента:

1. Как всегда нужно переключить версии портала так, чтобы почти никто этого не заметил.
2. «Компания 2» мигрировала свою часть разработок сама.
3. «Компания 1» и «Компания 3» уже не ведут поддержку клиента, поэтому их решения висели в воздухе.

Практический совет тем, кто поддерживает и развивает порталы: покупайте сторонние решения только с исходными текстами и ставьте силами своих администраторов — вы будете уверенны, что с вас не попросят дополнительных денег и что у вас стоит именно, то, что вы купили.

Как показывает опыт, при переходе на следующие версии порталов разработчики запрашивают дополнительные деньги, и они не всегда обоснованы.

Что изменилось в подходе к миграции на 2013

Давайте посмотрим вкратце на изменения в процессе миграции, а также в требованиях к ферме:
technet.microsoft.com/en-us/library/ee617150(v=office.15)
technet.microsoft.com/en-us/library/cc262485.aspx
technet.microsoft.com/en-us/library/ff382641.aspx

Аппаратные требования к ферме:

• для веб-сервера фермы 2013 требуется примерно в два раза больше оперативной памяти, чем веб-сервера фермы 2010 (8Гб против 4Гб для разработки и 12Гб против 8Гб для минимального использования);
• веб-сервер фермы 2013 официально поддерживается на Windows 2008R2SP1/2012, но пока не поддерживается на 2012R2.
• не поддерживается миграция сайтов «Fast-Search»: необходимо либо удалить сайты, либо заменить их на «Enterprise Search»;
• не поддерживается миграция сайтов «PowerPoint Broadcast», которые идут в комплекте с «Web App».

Мигрировать можно только некоторые сервис-приложения:

• Business Data Connectivity
• Managed Metadata
• PerformancePoint
• Secure Store
• User Profile
• Search Administration.

Отказ от функции «Visual Upgrade»:

1. Теперь нет функции «visual upgrade», но появилась возможность тестирования и миграции отдельных коллекций сайтов к виду 2013.
2. Теперь есть нативный режим работы 2010 сайтов, и на файловой системе кроме папки 15 есть и папка 14, при этом ссылка «\_layouts\» попадает в каталог «14/layouts», а ссылка «\_layouts\15\» в каталог «15/layouts».



3. Теперь есть возможность устанавливать WSP-решения от 2010 фермы, при этом нужно использовать флаг «-CompatibilityLevel «14,15»» и, как показала практика, большинство решений будут работать.
4. По умолчанию веб-приложения на ферме 2013 создаются и работают в режиме «CLAIM» авторизации, так что при миграции потребуется дополнительно конвертировать веб-приложение и пользователей к режиму «CLAIM».

Как обычно тренируемся (тестовая миграция)

Итак, как обычно мы проанализировали портал, сделали тестовую ферму, на которой и отработали первые ошибки. 90% решений WSP установилось без проблем, другие требовали исправлений, основные ошибки, с которыми столкнулись, это:

• неправильные пути к файлам;
• несовместимость решений с Framework 4.5.

При проверке базы в основном были ошибки «остатки от удаленных решений»:

• некорректные веб-части на страницах;
• некорректные «Feature»;
• некорректные решения WSP.

Далее, удостоверившись, что данные веб-части, фичи и решения не используются в работе, мы провели чистку базы, попутно удалили неиспользуемые коллекции сайтов, версии документов и данные корзин.

В результате получилась чистая от ошибок база контента, которую и подключили к тестовой ферме.

В процессе тестовой миграции также произвели миграцию сервис-приложений, которая никаких трудностей не вызвала:

• служба профилей;
• служба метаданных.

После подключения баз и конвертирования веб-приложения на режим авторизации «CLAIM» получили проблему с функционалом нашего решения для бронирования переговорных комнат, так что потребовалось его исправлять для работы с «CLAIMS».

В качестве примера миграции custom-разработки приводим решение по бронированию переговорных комнат, правильная архитектура позволила сделать правки минимальными, а именно изменить в web.config конфигурацию для wcf-сервиса.

Например, добавление useRequestHeadersForMetadataAddress атрибута в секцию behavior:

<serviceBehaviors>
  <behavior name="RoowRequestBehavior">
    <serviceMetadata httpGetEnabled="true" />
    <serviceDebug includeExceptionDetailInFaults="false" />
  </behavior>
</serviceBehaviors>

Помимо изменений в web.config исправления коснулись способа взаимодействия с SharePoint Search Services. Если в SharePoint 2010 взаимодействие происходило через FullTextSqlQuery и напоминало обычный SQL-запрос:

const string querySchema = "SELECT {0},{1} FROM Scope() WHERE (\"scope\"='people') AND (\"{2}\"='{3}'";
ResultTableCollection rtc = null;
var ftsq = new FullTextSqlQuery(ServerContext.Current)
{
  QueryText = String.Format(querySchema, employeeIdField, nameField, departmentField, department),
  ResultTypes = ResultType.RelevantResults
};
rtc = ftsq.Execute();

То теперь необходимо использовать KeywordQuery и такой же запрос будет выглядеть так:

const string querySchema = "{0}:{1}";

ResultTableCollection rtc = null;

var kwq = new KeywordQuery(site)
{
  QueryText = String.Format(querySchema, departmentField, department),
  ResultTypes = ResultType.RelevantResults,
  KeywordInclusion = KeywordInclusion.AllKeywords,
  HiddenConstraints = "scope:" + "\"People\""        
};
kwq.SelectProperties.Add(employeeIdField);
kwq.SelectProperties.Add(nameField);
SearchExecutor se = new SearchExecutor();
rtc = se.ExecuteQuery(kwq);

Наш совет: перед миграцией, если есть custom-компоненты, посмотрите на изменения в API, обычно дело заканчивается незначительными изменениями в коде.

Далее нам предстояло обновление сайтов к виду 2013. Со стандартными веб-приложениями проблем не возникло, и коллекции сайтов корректно обновились до вида 2013. Трудности возникли с веб-приложением старого интранет-портала, проверка показала множественные уведомления:



Соответственно следующими шагом была планомерная работа по корректировке внешнего вида портала. Замечу, что не весь дизайн удалось корректно перенести на 2013 и остались незначительные недочеты, которые никак не влияли на функционал портала и по согласованию с заказчиком их не стали дальше исправлять.

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

Боевая миграция

Как всегда после тестовой миграции мы еще раз сделали тренировочный прогон на чистой инфраструктуре и записали по шагам, что и как нужно делать. Боевую миграцию проводили в выходной день, чтобы не мешать ежедневной работе пользователей портала. Никаких новых ошибок в ходе боевой миграции не возникло, времени ушло около 6 часов.

В итоге хочется сказать, что процесс миграции стал немного проще, но нужно помнить простые вещи:

1. Не захламляйте свой портал ненужными решениями.
2. Храните исходные тексты, настройки, все версии того, что устанавливаете на портал. Потом подчас невозможно разобраться, откуда это взялось и что будет, если не мигрировать.
3. Описывайте (документируйте) конфигурацию сервисов — служба поиска, профилей, отчетов и т.д. — время проходит все забывается. Как правило, каждая настройка важна для работоспособности портала.
4. Старайтесь не изобретать велосипед и максимально правильно использовать функциональность портала.
5. Собрались мигрировать — не пожалейте времени на тренировку.

Будем рады, если наш опыт вам пригодится. Пишите вопросы, если знаем ответ, то обязательно проконсультируем и поможем!