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

в 6:08, , рубрики: sharepoint, sharepoint 2013, Блог компании EastBanc Technologies, ит-инфраструктура, метки: ,

В этом топике мы делимся нашим реальным опытом в миграции порталов с 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

Давайте посмотрим вкратце на изменения в процессе миграции, а также в требованиях к ферме:

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

  • для веб-сервера фермы 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. Трудности возникли с веб-приложением старого интранет-портала, проверка показала множественные уведомления:

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

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

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

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

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

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

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

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

Автор: eastbanctech

Источник

Поделиться

* - обязательные к заполнению поля