wsus_logo

Миграция сервера WSUS с Windows Server 2012 R2 на Windows Server 2016 с помощью Windows Server Migration Tools

Рассмотрим процесс обновления (миграции) Windows Server Update Services (WSUS) сервера с Windows Server 2012R2 (WS2012R2) на Windows Server 2016 (WS2016). WS2016 поддерживает обновления in-place, но, как и ранее, такой сценарий не рекомендуется. В данной статье я рассмотрю процесс миграции на новый сервер с помощью Windows Server Migration Tools.

На момент написания статьи официальная документация по миграции ролей находится в стадии разработки, но в большинстве случаев, руководство по миграции на Windows Server 2012R2 могут быть применены к миграции на Windows Server 2016, о чём официальная документация нам и говорит: https://docs.microsoft.com/ru-ru/windows-server/get-started/migrate-roles-and-features

Попробуем применить старые руководства для перехода на новый сервер.

https://technet.microsoft.com/en-us/library/hh852352(v=ws.11).aspx

На портале docs.microsoft.com есть интересная статья по миграции базы данных WSUS с Windows Internal Database на SQL:
https://docs.microsoft.com/en-us/windows-server/administration/windows-server-update-services/manage/wid-to-sql-migration

1. Текущая конфигурация и поддерживаемые сценарии миграции

Я буду рассматривать пример миграции одного единственного сервера WSUS WS2012R2 с Windows Internal Database на новый сервер Windows Server 2016 c базой данных на отдельном SQL сервере SQL Server 2014. Для Windows Server 2012 документация предусматривала переход с сервера-источника (source server), использующего Windows Internal Database на сервер назначения (destination server), использующий SQL Server 2008 SP1 в качестве сервера баз данных. Обратный сценарий не поддерживался.

2. Подготовка к миграции WSUS

2.1. Подготовка нового сервера, на который будет произведена миграция

Первым делом установим все последние обновления, затем установим роль WSUS. В моём случае база данных будет располагаться на отдельном сервере SQL:

Далее указываем где хранить обновления, локально или на серверах Microsoft Update.

Согласно документации, миграция с сервера, который хранит обновления локально на сервер, который хранит обновления на серверах Microsoft и наоборот невозможна. Поэтому выбираем вариант хранения, который используется на исходном сервере.

Указываем сервер баз данных:

Далее без изменений оставляем предложенные компоненты IIS, завершаем установку и запускаем post-installation tasks:

После завершения Post-Deployment конфигурации проверяем создалась ли база данных SUSDB на сервере SQL:

Если запустится мастер конфигурации (WSUS Configuration Wizard), его необходимо закрыть!
Открываем порты TCP 7000, 7001, 7002 на сервере назначения (WS2016) для передачи данных в процессе миграции. В качестве remoteip указываем ip адрес исходного сервера WS2012R2:

netsh advfirewall firewall add rule name="SmigServerData" dir=in action=allow protocol=TCP localport=7000 remoteip=172.27.208.250
netsh advfirewall firewall add rule name="SmigServerData" dir=in action=allow protocol=TCP localport=7001 remoteip=172.27.208.250
netsh advfirewall firewall add rule name="SmigServerData" dir=in action=allow protocol=TCP localport=7002 remoteip=172.27.208.250

Устанавливаем Windows Server Migration Tools:

Install-WindowsFeature Migration -ComputerName wsus

Установка Windows Server Migration Tools

Важно! Версии Windows Server Migration Tools должны быть одинаковыми на исходном и целевом серверах. Для этого необходимо импортировать пакет Migration Tools с целевого сервера WS2016, чтобы запустить его на исходном сервере WS2012R2.

Открываем command prompt от имени администратора и переходим в каталог

cd %Windir%\System32\ServerMigrationTools\

Запускаем экспорт

SmigDeploy.exe /package /architecture amd64 /os WS12R2 /path <deployment folder path>

deployment folder path — путь экспорта

Копируем папку SMT_ws12R2_amd64 из папки экспорта на наш исходный сервер WS2012R2.
Официальная документация по работе с Migration Tools здесь https://technet.microsoft.com/library/jj134202

2.2. Подготовка исходного сервера WS2012R2

Устанавливаем последние доступные обновления.

Открываем порт TCP 7000, 7001, 7002, в качестве remoteip указываем ip адрес целевого сервера WS2016:

netsh advfirewall firewall add rule name="SmigServerData" dir=in action=allow protocol=TCP localport=7000 remoteip=172.27.208.251
netsh advfirewall firewall add rule name="SmigServerData" dir=in action=allow protocol=TCP localport=7001 remoteip=172.27.208.251
netsh advfirewall firewall add rule name="SmigServerData" dir=in action=allow protocol=TCP localport=7002 remoteip=172.27.208.251

Если было изменено поведение брандмауэра по умолчанию на блокировку исходящего трафика, то нужно открыть также исходящий трафик UDP на порт 7000.
Открываем command prompt от имени администратора, переходим в скопированный каталог с Windows Server Migration Tools и запускаем SmigDeploy.exe:

Откроется PowerShell консоль Migration Tools.
На этом подготовительная часть завершена, приступаем к самому процессу миграции.

3. Процесс миграции WSUS

3.1. Перенос файлов обновлений из папки WSUS с исходного сервера на целевой

Если файлы обновлений хранятся на серверах Microsoft Update, то этот шаг можно пропустить.
Перенести содержимое папки контента можно любым способом (Windows Server Migration Tools, Windows Explorer, Xcopy, или Robocopy). Я покажу как перенести контент с помощью Windows Server Migration Tool, заодно мы проверим работу этого инструмента, все ли необходимое для его работы настроено.
• На целевом сервере WS2016 открываем PowerShell консоль инструмента Windows Server Migration Tools от имени администратора: Меню пуск -> Administrative Tools -> папка Windows Server Migration Tools:

• Проверяем достаточно ли свободного места на диске для переноса содержимого на целевой сервер.
• На целевом сервере WS2016 в открытой сессии PowerShell инструмента Windows Server Migration Tools запускаем командлет Receive-SmigServerData

Указываем пароль для шифрования трафика между серверами. Его же нужно будет указать и на исходном сервере. Командлет должен открыть порт и перейти в режим ожидания данных:

По умолчанию командлет будет ожидать 5 минут, затем закроет порт.

• В консоли Migration Tools, которую мы запустили на подготовительном этапе на исходном сервере WS2012R2 запускаем команду:

Send-SmigServerData -ComputerName <DestinationServer> -SourcePath <source_path> -DestinationPath <destination_path> -Include All -Force -Recurse

DestinationServer — имя сервера назначения. Source_path — путь до папки UpdateServicesPackages на исходном сервере — в моём случае это C:\WSUS\UpdateServicesPackages. Destination_path — путь до папки UpdateServicesPackages на целевом сервере. В моём случае это тоже C:\WSUS\UpdateServicesPackages. Папка UpdateServicesPackages может быть пустой на исходном сервере, тогда можно пропустить этот шаг и переносить сразу папку WsusContent. В моём случае эта папка находится в C:\WSUS\WsusContent. Командлет запросит пароль, который мы указали на целевом сервере. В процессе переноса данных в консоли PowerShell отображается ход выполнения
Со стороны исходного сервера:

Со стороны целевого сервера:

Если возникают какие-либо ошибки, то журнал работы Migration Tools для Windows Server 2008 и выше находится здесь: %localappdata%\SvrMig\Log

3.2. Миграция групп безопасности WSUS

Если состав локальных групп WSUS Administrators, WSUS Reporters на исходном сервере WS2012R2 не слишком большой, то можно вручную добавить соответствующие группы или пользователей на целевом сервере. Если вручную это будет сделать трудоёмко, то можно воспользоваться Migration Tools.
Рассмотрим процесс миграции групп с использованием Migration Tools.
На исходном сервере запускаем PowerShell от имени администратора и добавляем оснастку Server Manager Migration Tools:

Add-PSSnapin Microsoft.Windows.ServerManager.Migration

Запускаем экспорт групп. Можно также экспортировать и локальных пользователей, которые были созданы на исходном сервере (актуально для серверов в рабочих группах):

Export-SmigServerSetting -User <Enabled | Disabled | All> -Group -Path <MigrationStorePath> -Verbose

MigrationStorePath — путь, куда Migration Tools будет сохранять данные. Можно использовать общую папку, чтобы не копировать файл экспорта вручную. Я открыл общий доступ к папке C:\smig на исходном сервере.
Значения параметра -User:
Enabled — экспорт только включенных учётных записей
Disabled — экспорт только выключенных учётных записей
All — экспорт всех учётных записей и включенных и отключенных
Для рассматриваемого сценария не требуется экспорт локальных пользователей, поэтому я ограничусь только группами. Для выполнения процедуры также указываем пароль для шифрования данных.

Export-SmigServerSetting -Group -Path \\redwsus\smig -Verbose

На сервере назначения WS2016 выполняем команду импорта:

Import-SmigServerSetting -User <Enabled | Disabled | All> -Group -Path <MigrationStorePath> -Verbose
Import-SmigServerSetting -Group -Path \\redwsus\smig -Verbose

3.3. Перенос базы данных WSUS

Перенос базы данных WSUS как между Windows Internal Database вариантом, так и между SQL Server осуществляется методом восстановления резервной копии.
Для создания резервной копии я использовал SQL Server Management Studio Express 2012 https://www.microsoft.com/en-us/download/details.aspx?id=29062 установив её локально на исходный сервер WS2012 с Windows Internal Database (WID). Для подключения к WID необходимо в ServerName указать:
-для WS2012, WS2012R2 \\.\pipe\MICROSOFT##WID\tsql\query
-для WS2008, WS2008R2 \\.\pipe\Microsoft##SSEE\sql\query
Важно! Для подключения к WID консоль SSMS необходимо запустить от имени администратора.

Находим базу данных SUSDB и запускаем резервное копирование:

Восстанавливаем полученную резервную копию на сервере SQL, который держит базу данных нового WSUS сервера WS2016.
Подключаемся с помощью SSMS к серверу баз данных и выполняем запрос на удаление текущей базы SUSDB:

USE master
GO
ALTER DATABASE SUSDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DROP DATABASE SUSDB
GO

Затем правый клик на Databases, выбираем Restore Database:

Указываем путь до файла бэкапа и восстанавливаем базу:

На целевом сервере WS2016 запускаем командную строку от имени администратора и выполняем следующее:
Если миграция произведена на сервер с WID:

"%programfiles%\update services\tools\wsusutil.exe" postinstall CONTENT_DIR=C:\Wsus

Если миграция была произведена на wsus с базой данных на полноценном SQL Server:

"%programfiles%\update services\tools\wsusutil.exe" postinstall CONTENT_DIR=C:\Wsus SQL_INSTANCE_NAME=<database server name>

В параметре CONTENT_DIR указываем путь до контент директории WSUS, в SQL_INSTANCE_NAME указываем имя SQL сервера:

3.4. Смена идентификатора сервера

На сервере назначения WS2016 необходимо сменить GUID сервера на новый. Запускаем PowerShell от имени администратора и выполняем следующие команды:

$updateServer = get-wsusserver
$config = $updateServer.GetConfiguration()
$config.ServerId = [System.Guid]::NewGuid()
$config.Save()

После смены GUID запускаем ещё раз задачу Postinstall в командной строке от имени администратора:

"%ProgramFiles%\Update Services\Tools\wsusutil.exe" postinstall SQL_INSTANCE_NAME=<DatabaseServerName>

На этом фаза миграции сервера WSUS закончена, можно открыть консоль WSUS на новом сервере и убедиться, что сервер «видит» клиентов, их статусы, имеет данные о загруженных обновлениях и т.п.

4. Действия после миграции

Основная задача после успешной миграции — перенацелить клиентов на новый сервер. Для этого в GPO необходимо изменить адреса сервера обновлений и сервера статистики на новый сервер.

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

Также можно удалить созданные в процессе миграции правила брандмауэра, удалить компонент Windows Server Migration Tools.

Если возникают проблемы с частым перезапуском пула WsusPool или его становкой, можно попробовать подобрать значения лимитов для этого пула. Подробнее об этом в статье «WSUS: частая перезагрузка IIS пула ‘WsusPool’ (Pool Recycling), зависания в процессе перезапуска. Event ID 5117, 5138, 5013«

Добавить комментарий