Підготовка до оновлення до sharepoint 2010

Ще перед початком планування необхідно ознайомитися з системними вимогами для SharePoint 2010. На відміну від попередніх версій SharePoint 2010 випускається тільки в 64-розрядної версії. Там чином, необхідно встановлювати SharePoint 2010 на 64-рязрядної версії Windows Server 2008 або Windows Server 2008 R2.

SharePoint потрібно база даних SQL Server, але вона не обов`язково повинна перебувати на тому ж сервері, що і SharePoint. SharePoint 2010 і раніше вимагає SQL Server, але корпорація Майкрософт внесла декілька важливих змін. SharePoint 2010 вимагає, щоб бази даних працювала з 64-розрядної версії SQL Server 2005 або 2008. Це справедливо незалежно від того, чи встановлена база даних локально на сервері SharePoint.

Необхідно також задуматися про використаний веб-браузері, хоча це і не технічна вимога. SharePoint2010 створений для того, щоб оптимізувати використання веб-стандартів. Це означає, що користувачі зможуть працювати без перебоїв незалежно від використовуваного браузера: Explorer або Firefox (3.x або більш пізня версія). Єдина тонкість полягає в тому, що SharePoint 2010 забезпечує обмежену підтримку Internet Explorer 6. Користувачі IE6 не повинні відчувати проблем з переглядом вмісту SharePoint, проте для створення вмісту потрібно IE7 або пізніша версія (або Firefox 3.x або більш пізня версія).

Оновлення поверх існуючої системи

Як ви вже, напевно, чули, SharePoint 2010 дозволяє виконувати оновлення поверх існуючої системи Microsoft Office SharePoint Server (MOSS) 2007. Однак, оскільки SharePoint 2010 є 64-розрядної, можна виконати оновлення поверх існуючої системи тільки в тому випадку, якщо MOSS 2007 запущений поверх 64-розрядної версії Windows Server 2008. Якщо ваші сервери SharePoint відповідають необхідним вимогам, можна виконати оновлення поверх існуючої системи на кожному сервері ферми SharePoint.

Незважаючи на те, що SharePoint повністю підтримує ці оновлення, я б рекомендував їх виконувати тільки при наявності простого розгортання SharePoint без будь-яких налаштувань. У більш складних середовищах рекомендується виконувати повні переноси, оскільки це забезпечує більш повний контроль процесу оновлення. Крім того, це рекомендується також для середовищ, в яких були виконані призначені для користувача настройки, щоб випадково їх не замінити.

Перенесення, як правило, має на увазі збірку повністю нової ферми SharePoint, на якій запущений SharePoint 2010. Після цього до нової фермі можна прикріпити існуючі бази даних SharePoint. Можна також скористатися гібридної стратегією перенесення, яка поєднує поновлення поверх існуючої системи і нові сервери SharePoint 2010.

Перевірка перед оновленням

Незалежно від того, що ви виконуєте - оновлення поверх існуючої системи або перенесення, необхідно перед цим все спланувати і підготуватися. Одним з найбільш важливих кроків у підготовці до оновлення до SharePoint 2010 є запуск програми попереднього аналізу. Перед випуском MOSS 2007 корпорація Майкрософт представила службову програму Prescan.exe, яка допоможе перевірити стан розгортання SharePoint перед оновленням до MOSS 2007.

Програма Prescan.exe свого часу була відмінним засобом, однак вона не дуже добре підходить для попереднього аналізу SharePoint 2010. Ось чому корпорація Майкрософт випустила програму попереднього аналізу Pre-Upgrade Checker. Вона набагато досконаліше програми Prescan.exe. Почнемо з того, що програма попереднього аналізу Pre-Upgrade Checker призначена тільки для читання, тому не доведеться хвилюватися про внесення будь-яких змін на сервери SharePoint.

Однак найбільш зручна Pre-Upgrade Checker саме тим, що виконує куди більш ретельну роботу з пошуку проблем, ніж Prescan.exe. Крім того, вона є розширеною. Вона випускається з набором правил, які використовує при аналізі серверів SharePoint. Це правила в форматі XML, отже, можна створювати свої правила, якщо це буде потрібно. Крім того, використання правил на основі XML спрощує роботу корпорації Майкрософт по оновленню програми попереднього аналізу, якщо їх рекомендації коли-небудь зміняться.

Відео: Оновлення до Windows 10. Детальна інструкція

Вважається, що краще в цій програмі - це інформація, яку вона збирає, але це твердження спірне. Незважаючи на те, що корпорація Майкрософт створювала її як засіб для підготовки до оновлення до SharePoint 2010, деякі організації використовують її для інших цілей. Одна компанія використовує її в рамках свого плану по відновленню після збоїв. Програма попереднього аналізу жодним чином не допоможе врятувати сервер SharePoint після збою, однак зібрана нею інформація може виявитися безцінною, якщо вам доведеться повторно збирати розгортання SharePoint (тільки обов`язково запустіть її перед збоєм).

Інша організація використовувала програму попереднього аналізу для перевірки, чи всі сервери SharePoint налаштовані послідовно. Запускаючи цю програму на кожному сервері SharePoint, можна порівняти звіти кожного з них і виконати пошук окремих елементів настройки, які не відповідають корпоративній політиці.

Так де ж можна знайти цю програму? Є ймовірність, що вона у вас вже є. Корпорація Майкрософт включила її в MOSS 2007 за пакетом оновлень 2 (SP2). Але, можливо, всупереч вашим очікуванням, програма попереднього аналізу не є ізольованим засобом. Корпорація Майкрософт вбудувала її в службову програму STSADM.EXE. Так вже вийшло, що після застосування пакета поновлення 2 (SP2) мені довелося перезавантажувати тестовий сервер кілька разів, поки Windows не дозволила мені отримати доступ до нових функцій STSADM.EXE.

З огляду на все вищесказане, я хочу показати, як працює програма попереднього аналізу. Як я вже говорив, вона працює, аналізуючи файл правила на основі XML, а потім використовуючи ці правила як основу для аналізу розгортання SharePoint. Програма поставляється з вбудованим набором правил. Ці правила, засновані на аналізаторі відповідності рекомендаціям, знаходяться в файлі OssPreUpgradeCheck.xml. На нього можна подивитися на рис. 1.

Мал. 1. Програма попереднього аналізу використовує файл правил на основі XML.

При запуску цієї програми не потрібно явно викликати цей файл правил. Програма викликає його за замовчуванням. Можна використовувати свої файли правил. Повний синтаксис програми попереднього аналізу наступний:

STSADM.EXE -O PreUpgradeCheck
[[-RuleFiles ldquo-rdquo-] [-ListRuleFiles]] [-LocalOnly]

Як можна бачити, існують два обов`язкових параметра -O і слова PreUpgradeCheck. Параметр -RuleFiles є необов`язковим і використовується тільки при необхідності вказати файл правил вручну. Також можна використовувати параметр -ListRuleFiles для відображення файлів правил, які доступні. І, нарешті, можна використовувати параметр -LocalOnly для запуску цих правил тільки для місцевого сервера SharePoint.

Погляньте на рис. 2, який допоможе уявити, як працює програма попереднього аналізу. Як видно на малюнку, я починаю з того, що відкриваю вікно командного рядка і переходжу за адресою C: Program Files Common Files Microsoft Shared Web Server Extensions 12 BIN. Звідти я запускаю наступну команду:

STSADMIN.EXE -O PreUpgradeCheck]

Мал. 2. Перевірка програмою попереднього аналізу розгортання SharePoint.

Як можна бачити на рис. 2, програма попереднього аналізу виконує ряд різних тестів в розгортанні SharePoint. Результати кожної перевірки мають свій колір. Червоний вказує на збій, зелений - на те, що сервер пройшов перевірку. Інформаційні пункти позначені жовтим.

Відео: Upgrading SharePoint 2010 to SharePoint 2013

Вивідні дані програми попереднього аналізу, звичайно ж, не є дуже детальними. Знімок екрана на рис. 2 повідомляє тільки про те, чи пройдена проверка- докладних відомостей не виводиться. Проте, якщо поглянути на нижню частину знімка екрана, можна помітити повідомлення, в якому сказано, що можна ознайомитись з результатами в файлі HTML, розташованому за адресою C: Program Files Common Files Microsoft Shared Web Server Extensions 12 Logs .

Програма попереднього аналізу створює три окремих файлу журналу при кожному запуску. Один з них - це файл HTML, адреса якого вказана в кінці перевірки, два інших - це файли LOG і XML. Можна використовувати будь-який з них, але файл HTML зручніше читати.

Як вже було сказано, програма попереднього аналізу збирає безліч інформації. Отже, немає нічого дивного в тому, що остаточні файли журналу занадто довге для того, щоб приводити їх повністю. Можна, однак, отримає загальне уявлення про те, як виглядають файли журналу в форматі HTML, глянувши на рис. 3.

Мал. 3. Результати роботи програми попереднього аналізу можна переглянути за допомогою веб-браузера.

Визначення налаштувань

Ще один важливий крок у плануванні оновлення - визначити для користувача настройки серверів SharePoint. Неважливо, що ви виконуєте, - оновлення поверх існуючої системи або перенесення, - можна ненавмисно переписати призначені для користувача настройки. Отже, слід їх задокументувати і зробити резервну копію тільки цих файлів, щоб їх можна було без проблем використовувати після поновлення, якщо буде потрібно.

Сподіваюся, ви ретельно задокументували всі налаштування в міру розширення середовища SharePoint. Насправді відстежувати всі зміни може бути важко. Отже, приділіть час перегляду журналу налаштувань, навіть якщо вважаєте, що всі вони були задокументовані. На жаль, SharePoint не містить будь-яких вбудованих засобів для визначення налаштувань. Але це все одно не означає, що вам потрібно вручну переглядати кожен файл на серверах SharePoint.

Є спосіб визначити настройки - методика під назвою пошук відмінностей. Ідея укладає в тому, що можна встановити резервний сервер MOSS 2007 (переконайтеся в тому, що на ньому запущені ті ж виправлення, що і на робочих серверах) і скористатися програмою для пошуку відмінностей, щоб побачити, які файли на робочих серверах відрізняються від файлів на незміненому сервері SharePoint.

Корпорація Майкрософт рекомендує використовувати, однак існують і інші програми, багато хто з них мають більш великі функції, ніж WinDiff.

Перевірка процесу оновлення

При підготовці до переходу на SharePoint 2010 неминуче настане момент, коли ви разработаете план виконання оновлення. Припустимо, що ви вирішили всі проблеми, знайдені програмою попереднього аналізу. Значить, процес оновлення повинен проходити відносно гладко. Проте, його потрібно ретельно контролювати.

Розгорніть MOSS 2007 в ізольованій лабораторному середовищі і спробуйте реалізувати план оновлення в ній, перш ніж виконувати оновлення на робочих серверах. Лабораторне середовище допоможе ознайомитися з процесом оновлення, а також визначити проблеми, які можуть виникнути в ході справжнього оновлення.

Кращий підхід для підприємств малого та середнього бізнесу - встановити кілька віртуальних серверів, а потім відновити резервні копії робочих серверів на серверах лабораторної середовища. Це дозволить вам перевірити план оновлення в середовищі, яка практично ідентична виробничої.

У більших організаціях створювати точну копію виробничого розгортання SharePoint, можливо, буде непрактично. У подібних ситуаціях можна встановити невелику середу, налаштовану так само, як і виробниче середовище. Можна також спробувати відновити в лабораторному середовищі резервні копії - але не всі - серверів SharePoint. У той час як цей підхід може здаватися дуже перспективним, не забувайте про те, що ви, швидше за все, не будете переносити всі розгортання в SharePoint 2010 за раз-вам буде потрібно сконцентрувати розгортання поступово.

Перевірка резервних копій

Останній крок перед початком оновлення до SharePoint 2010 - перевірка, чи правильно працюють резервні копії. Якраз на цьому тижні мені довелося допомагати одній людині, який вважав, що старанно виконує резервне копіювання серверів, але виявив, що ці резервні копії нікуди не годилися. Не допускайте подібних ситуацій. Перевіряйте резервні копії, необхідно переконатися в тому, що їх можна відновити.