В этом топике мы делимся нашим реальным опытом в миграции порталов с 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. Здесь стоит упомянуть два важных момента:
- Как всегда нужно переключить версии портала так, чтобы почти никто этого не заметил.
- «Компания 2» мигрировала свою часть разработок сама.
- «Компания 1» и «Компания 3» уже не ведут поддержку клиента, поэтому их решения висели в воздухе.
Практический совет тем, кто поддерживает и развивает порталы: покупайте сторонние решения только с исходными текстами и ставьте силами своих администраторов — вы будете уверенны, что с вас не попросят дополнительных денег и что у вас стоит именно, то, что вы купили.
Как показывает опыт, при переходе на следующие версии порталов разработчики запрашивают дополнительные деньги, и они не всегда обоснованы.
Что изменилось в подходе к миграции на 2013
Давайте посмотрим вкратце на изменения в процессе миграции, а также в требованиях к ферме:
Аппаратные требования к ферме:
- для веб-сервера фермы 2013 требуется примерно в два раза больше оперативной памяти, чем веб-сервера фермы 2010 (8Гб против 4Гб для разработки и 12Гб против 8Гб для минимального использования);
- веб-сервер фермы 2013 официально поддерживается на Windows 2008R2SP1/2012, но пока не поддерживается на 2012R2.
Способ миграции только один: мигрировать на 2013 теперь можно только методом «Database-attach upgrade» либо сторонними средствами, метод «In-place upgrade» больше не поддерживается (да и не очень-то надо).
Не все службы портала можно мигрировать:
- не поддерживается миграция сайтов «Fast-Search»: необходимо либо удалить сайты, либо заменить их на «Enterprise Search»;
- не поддерживается миграция сайтов «PowerPoint Broadcast», которые идут в комплекте с «Web App».
Мигрировать можно только некоторые сервис-приложения:
- Business Data Connectivity
- Managed Metadata
- PerformancePoint
- Secure Store
- User Profile
- Search Administration.
Отказ от функции «Visual Upgrade»:
- теперь нет функции «visual upgrade», но появилась возможность тестирования и миграции отдельных коллекций сайтов к виду 2013;
- теперь есть нативный режим работы 2010 сайтов, и на файловой системе кроме папки 15 есть и папка 14, при этом ссылка «_layouts» попадает в каталог «14/layouts», а ссылка «_layouts/15» в каталог «15/layouts».
- теперь есть возможность устанавливать WSP-решения от 2010 фермы, при этом нужно использовать флаг «-CompatibilityLevel «14,15»» и, как показала практика, большинство решений будут работать;
- по умолчанию веб-приложения на ферме 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" />
<useRequestHeadersForMetadataAddress />
<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 часов.
В итоге хочется сказать, что процесс миграции стал немного проще, но нужно помнить простые вещи:
- Не захламляйте свой портал ненужными решениями.
- Храните исходные тексты, настройки, все версии того, что устанавливаете на портал. Потом подчас невозможно разобраться, откуда это взялось и что будет, если не мигрировать.
- Описывайте (документируйте) конфигурацию сервисов — служба поиска, профилей, отчетов и т.д. — время проходит все забывается. Как правило, каждая настройка важна для работоспособности портала.
- Старайтесь не изобретать велосипед и максимально правильно использовать функциональность портала.
- Собрались мигрировать — не пожалейте времени на тренировку.
Будем рады, если наш опыт вам пригодится. Пишите вопросы, если знаем ответ, то обязательно проконсультируем и поможем!
Автор: eastbanctech
