Перенос файлового сервера на другой сервер
служба хранилища Migration Service упрощает перенос хранилища на сервер Windows или в Azure. Он предоставляет графическое средство, которое выполняет инвентаризацию данных на серверах Windows, Linux и NetApp CIFS, а затем передает данные на более новые серверы или в виртуальные машины Azure. служба хранилища Migration Service также предоставляет возможность передачи удостоверения сервера на конечный сервер, чтобы приложения и пользователи могли получать доступ к своим данным без изменения ссылок или путей.
В этом разделе описывается, почему вы хотите использовать служба хранилища Migration Service, как работает процесс миграции, каковы требования к исходным и целевым серверам, а также что нового в служба хранилища Migration Service.
Шаг 1. Создание задания и инвентаризация серверов для определения того, что нужно перенести
На этом шаге вы укажете, какие серверы следует перенести, а затем сканируете их, чтобы получить сведения о своих файлах и конфигурациях.
На странице проверки необходимых компонентов просмотрите необходимые компоненты. Выберите Далее.
Если вы переносите массив NetApp FAS, на странице "Выбор массива NetApp FAS " введите IP-адрес массива NetApp FAS, учетные данные администратора и пароль. Затем нажмите кнопку Далее.
Если вы выполняете миграцию с сервера или кластера Windows, на странице "Ввод учетных данных" введите учетные данные администратора, которые работают на серверах, с которыми требуется выполнить миграцию, и нажмите кнопку "Далее".
При миграции с серверов Linux вместо этого введите учетные данные на страницах учетных данных Samba и учетных данных Linux , включая пароль SSH или закрытый ключ.
Если выполняется миграция из массива NetApp FAS, используйте учетные данные enter и предсканю страницу NetApp NetApp , чтобы ввести учетные данные администратора, которые работают на серверах NetApp CIFS, с которых требуется выполнить миграцию, а затем нажмите кнопку "Начать сканирование ", чтобы получить список всех серверов NetApp CIFS, работающих в массиве NetApp FAS. Вы можете снять флажок на всех серверах CIFS, которые вы не хотите перенести. Затем нажмите кнопку Далее.
На странице "Установка необходимых средств " убедитесь, что необходимые средства установлены без ошибок. Выберите Далее.
Если вы выполняете миграцию с сервера или кластера Windows или из Linux Samba, на странице "Добавление и сканирование устройств" выберите "Добавить устройство", а затем выполните поиск в Active Directory для кластера исходного сервера. Для выполнения частичного поиска с подстановочными знаками можно использовать звездочку. Можно также ввести точное имя исходного сервера или имя кластеризованного файлового сервера. Щелкните ОК.
Повторите эти действия для всех серверов, которые нуждаются в инвентаризации. Если выполняется миграция из массива NetApp FAS, на странице "Выбор и проверка серверов" уже отображается исходный сервер.
Выберите "Проверить " и убедитесь, что проверка проходит для всех серверов.
Ожидается ошибка для привилегий резервного копирования с серверов NetApp CIFS. Эту ошибку можно игнорировать.
Выберите каждый сервер, чтобы проверить общие папки, конфигурацию, сетевые адаптеры и тома, которые были описаны в процессе инвентаризации.
служба хранилища Migration Service не будет передавать файлы или папки, которые мы знаем, могут препятствовать работе Windows, поэтому вы увидите предупреждения о любых общих папках, расположенных в системной папке Windows. Во время перемещения необходимо будет пропустить эти общие папки. Дополнительные сведения см. в разделе "Какие файлы и папки исключены из передачи".
Нажмите Далее, чтобы перейти к передаче данных.
Новые возможности служба хранилища Migration Service
Windows Admin Center версии 1910 добавлена возможность развертывания виртуальных машин Azure. Это интегрирует развертывание виртуальной машины Azure в служба хранилища Migration Service. Дополнительные сведения см. в статье о миграции виртуальных машин Azure.
Следующие функции после RTM доступны при запуске оркестратора сервера миграции служба хранилища на Windows Server 2019 с установленным пакетом KB5001384 или на Windows Server 2022:
Прямая миграция — это этап миграции, который перемещает сетевое удостоверение исходного компьютера на конечный компьютер. После прямой миграции исходный компьютер будет по-прежнему содержать те же файлы, что и раньше, но он не будет доступен пользователям и приложениям.
Шаг 3. Переход на новые серверы
На этапе прямой миграции выполняется перенос IP-адресов и имен компьютеров на целевые серверы. После его завершения приложения и пользователи получают доступ к новым серверам через имена и адреса исходных серверов.
- Если вы отошли от задания миграции, в Windows Admin Center перейдите в раздел диспетчер сервера>служба хранилища Migration Service и выберите задание, которое вы хотите завершить.
- На странице "Вырезать" на новой странице учетных данных serversEnter> нажмите кнопку "Далее", чтобы использовать введенные ранее учетные данные.
- На странице Настройка прямой конфигурации укажите, какой сетевой адаптер на целевом сервере должен принять параметры адаптера исходного сервера. Это перемещает IP-адрес из источника в место назначения в рамках прямой передачи, предоставляя исходному серверу новый DHCP-или статический IP-адрес. У вас есть возможность пропустить все миграции сети или определенные интерфейсы.
- Укажите, какой IP-адрес следует использовать для исходного сервера после того, как прямая миграция передаст его адрес целевому серверу. При переносе Windows сервера или кластера или в Linux Samba можно использовать DHCP или указать новый статический IP-адрес. Если используется статический адрес, новая подсеть должна быть такой же, как и старая, иначе прямая миграция завершится ошибкой. Если вы переносите массив NetApp FAS, используйте подсети NetApp вместо DHCP. Рис. 4. Исходный сервер и способ перемещения конфигурации сети в место назначения
- Укажите новое имя для исходного сервера после того, как прежнее имя будет назначено целевому серверу. Вы можете использовать случайно созданное имя или ввести его самостоятельно. Выберите Далее.
- На странице "Настройка параметров " может потребоваться предоставить новые учетные данные пользователя AD с разрешениями на удаление исходного компьютера или кластеризованного файлового сервера из домена, а затем добавить их обратно с новым именем, если учетные данные миграции источника не имеют этого разрешения.
- Выберите "Проверить" на странице "Проверить исходное и целевое устройство ", а затем нажмите кнопку "Далее".
- Когда вы готовы выполнить прямую миграцию, нажмите Запустить прямую миграцию.
Пользователи и приложения могут прерывать работу при перемещении адреса и имен, а серверы перезапускаются несколько раз, но в противном случае они не будут затронуты миграцией. Продолжительность прямой миграции зависит от того, как быстро перезапускают серверы, а также время репликации Active Directory и DNS.
Операции после миграции
После переноса сервера или кластера оцените среду для возможных операций после миграции:
Если у вас есть файловые сервера SMB, запущенные на Windows Server 2003, вы, наверное, уже в курсе, что расширенная поддержка этой ОС завершится 14 июля 2015 года. Более подробно об этом вы можете прочитать здесь.
Если вы все еще используете Windows Server 2003, вы должны начать планировать переход на новую версию прямо сейчас. Простейшим способом мигрировать старые файловые сервера SMB будет использование виртуальной машины, чтобы заменить вашу старую виртуальную машину и перенести данные на новую. Не смотря на то, что такой переход кажется довольно простым, вы должны быть осторожны, т.к. это перемещение данных и требует, по крайней мере непродолжительного, времени простоя.
Я рад, что вы читаете эту статью, так как это означает, что вы предпринимаете шаги, чтобы уйти с ваших старых серверов прежде, чем их поддержка прекратится.
- Настройка аккаунтов/групп в Active Directory*
- Настройка компьютера с WS2003*
- Подготовка к миграции (копирование исходных данных до окончательной миграции)
- Экспорт информации о сетевых папках
- Добавление изменений после завершения Шага 3*
- Переименование Windows Server 2003
- Окончательный перенос данных
- Создание сетевых папок в пункте назначения
- Переименование WS2012R2
- Проверка изменений
Шаг 1 — Настройка аккаунтов/групп в Active Directory*
Сначала создадим несколько учетных записей пользователей и групп для домена, с которыми мы будем работать в сценарии.
Этот шаг должен быть выполнен из PowerShell (запущенной с правами Администратора) на контроллере домена под управлением Windows Server 2012 R2.
Более ранние версии Windows Server для контроллера домена также подходят, но я не могу ручаться, что приведенные ниже команды PowerShell будут работать на всех старых версиях.
ВАЖНО: Эти команды должны быть использованы только для симуляции тестового окружения. Не запускайте их в вашей производственной среде.
Шаг 2 – Настройте ваш компьютер с WS2003
Теперь создаем несколько локальных и сетевых папок, с различными разрешениями на уровне файловой системы и сети. Это имитирует производственную среду и помогает протестировать, что файлы, локальные и сетевые папки и разрешения были мигрированы должным образом.
Эти команды должны быть запущены из командной строки на тестовом файловом сервере под управлением Windows Server 2003. В скрипте JOSE – это имя домена.
ВАЖНО: Эти команды должны быть использованы только для симуляции тестового окружения. Не запускайте их в вашей производственной среде.
Шаг 3 – Подготовка к миграции
На этом шаге выполняется первоначальное копирование данных с файлового сервера под управлением Windows Server 2003 на машину под управлением Windows Server 2012 R2 до окончательной миграции.
Делая эту первую копию со старого файлового сервера все еще доступной пользователям, вы минимизируете время простоя, необходимое для финальной копии. Если есть проблемы с открытыми файлами или другими ошибками на этом этапе, то ничего страшного – вы получите возможность захватить эти файлы позже.
Вы должны убедиться, что включили все папки, используемые для ваших сетевых файлов. В этом примере, я предполагаю, что соответствующие файлы находятся в папках C:\homefolder и C:\projects.
ВАЖНО: Вы должны использовать те же буквы дисков и те же самые пути на вашем новом сервере под управлением Windows Server 2012 R2. В противном случае, информация о сетевых папках не будет совпадать, и ваша миграция не будет работать.
ВАЖНО: Это процесс миграции работает только в случае, если для ваших разрешений вы используете доменные аккаунты и доменные группы. Если вы используете локальные аккаунты для общего доступа к файлам или назначения разрешений для файловой системы, то разрешения не будут перемещены ROBOCOPY.
- /e – Копировать подкаталоги, включая пустые
- /xj – Исключить точки соединения
- /r:2 – 2 попытки
- /w:5 – 5 секунд ожидания между двумя попытками
- /v – Подробные сведения для пропущенных файлов
- /it – Включить tweaked-файлы (одинаковый размер/метка времени, но разные атрибуты)
- /purge – Удалить в точке назначения файлы/папки, которые больше не существуют в источнике
- /copyall – Скопировать данные, атрибуты, временные метки, списки контроля доступа, информацию о владельце и сведения аудита
Данный шаг необходимо выполнить на сервере под управлением Windows Server 2012 R2 из командной строки, запущенной с правами Администратора.
Шаг 4 — Экспорт информации о сетевых папках
Экспортируем информацию о сетевых папках из реестра Windows Server 2003. В эту информацию входят имена сетевых папок, путь к ним и информация о безопасности сетевых папок (ACL). Более подробно об этой процедуре экспорта вы можете прочитать здесь.
Эта команда должна быть запущена из командной строки на тестовой файловом сервере под управление Windows Server 2003.
ВАЖНО: Это процесс миграции работает только в случае, если для ваших разрешений вы используете доменные аккаунты и доменные группы. Если вы используете локальные аккаунты для общего доступа к файлам или назначения разрешений для файловой системы, то разрешения не будут перемещены с помощью этого экспорта из регистра.
Шаг 5 — Добавление изменений после завершения Шага 3* (имитирует существующую среду и запускается с файлового сервера под управлением WS2003)
Этот шаг имитирует применение изменений к файлам, после того, как было совершено начальное копирование на Шаге 3. Так как прошло некоторое время между шагами 3 и 6, мы ожидаем, что пользователи все еще продолжали вносить изменения в уже существующие файлы и добавляли новые. Этот имитирующий шаг позволяет убедиться, что с помощью команд возможно захватить эти изменения.
Этот шаг должен быть запущен из командной строки на тестовой файловом сервере под управление Windows Server 2003.
ВАЖНО: Эти команды должны быть использованы только для симуляции тестового окружения. Не запускайте их в вашей производственной среде.
Шаг 6 – Переименование Windows Server 2003 (***Здесь начинается время простоя***)
На этом шаге вы должны переименовать ваш компьютер под управление Windows Server 2003 и перезапустить его. Этот шаг будет началом времени простоя для вашего файлового сервера.
Поскольку Windows Server 2003 не поставляется с опцией командной строки, необходимой для выполнения этой операции, используйте графический интерфейс, чтобы вручную переименовать машину из FILES в XFILES. Здесь предполагается, что FILES – это имя существующего файлового сервера (пользователи получают доступ к данным, используя \\FILES\); XFILES – это неиспользуемое в вашей сети имя. На этом этапе, ваш файловый сервер FILES станет недоступным.
Если вы хотите автоматизировать этот шаг, скачайте Support Tools и используйте команду, приведенную ниже, на компьютере под управлением Windows Server 2003.
Шаг 7 – Окончательный перенос данных
На этом этапе копируются изменения, произошедшие с сетевыми ресурсами (изменение существующих файлов или создание новых) после начального копирования. После того, как система была переименована и перезагружена, в ней не должно быть подключенных пользователей, и, следовательно, не должно возникнуть каких-либо проблем с файлами во время копирования.
Мы будем использовать те же параметры, что и раньше, и ROBOCOPY, для того, чтобы скопировать то, что было изменено с первого копирования. Если первоначальное копирование происходило не очень давно, у вас будет всего несколько изменений, и этот шаг не займет много времени.
ВАЖНО: Т.к. это последнее копирование, вы должны просмотреть каждую ошибку и повторять копирование до тех пор, пока не будет выявлено никаких проблем с нужными вам файлами.
Запустите эту команду с компьютера под управлением Windows Server 2012 R2 из командной строки, запущенной с правами Администратора.
Шаг 8 – Создание сетевых папок в пункте назначения
Импортируем настройки сетевых папок из Windows Server 2003, используя файл, созданный на шаге 4.
Запустите эту команду с компьютера под управлением Windows Server 2012 R2 из командной строки, запущенной с правами Администратора.
Шаг 9 – Переименование WS2012R2
Теперь переименуем компьютер под управлением Windows Server 2012 R2 в тоже имя, которое использовалось на нашем старом Windows Server 2003, и на этом миграция завершена.
После того, как система перезапущена, клиенты смогут получить доступ к сетевым папкам в новой системе, и на этом время простоя закончится.
Запустите эту команду с компьютера под управлением Windows Server 2012 R2 из PowerShell, запущенной с правами Администратора.
Шаг 10 – Проверка изменений (***Здесь заканчивается время простоя***)
Миграция завершена, и вы можете использовать эти команды для того, чтобы убедиться, что все сетевые папки перенесены правильно. С помощью этих команд также проверяются разрешения для некоторых сетевых и локальных папок, чтобы убедиться, что и эта часть работает корректно.
Запустите эту команду с компьютера под управлением Windows Server 2012 R2 из PowerShell, запущенной с правами Администратора.
Заключение
Я настоятельно рекомендую вам настроить тестовую среду прежде, чем пытаться сразу применить эти инструкции на используемом в производстве файловом сервере под управлением Windows Server 2003. Ваша тестовая среда должна имитировать производственную настолько точно, насколько это возможно. В этом случае вы можете узнать подробную информацию о процедуре и настроить скрипты в соответствии деталям вашей среды.
Есть сервер MS Windows Server 2003 R2 с 2 ТБ данных, расшаренных через NTFS права пользователям в домене.
Хочу перенести весь сервер (точнее файлы с шарами) на другую машину с Windows Server 2008 R2 не потеряв права доступа пользователей.
Имена некоторых файлов превышают 250 символов. DFS не настроен.
Подскажите что можно с этим сделать?
Была похожая задача. За несколько лет в шарах скопилось МОРЕ мусора. На новом сервере создал новые пустые шары с правами. Через руководство обязал в течение 2 недель переместить (не скопировать, а переместить) на новые шары только нужные файлы. Через 2 недели закрыл старые шары, "остатки" поместил в архив. Объем шар снизился чуть не вдвое - с 2Т до 1,2Т. Про "остатки" раз в 2-3 месяца кто-то вспоминает - достаем ему файл из архива.
Или выйти в ночь - назвать новый сервер как старый, прицепить к нему старый диск, прописать шары. Утром никто разницы не заметит. Права сохранятся.
такой шары не будет , надо будет по новой настраивать , файло с правами доступа то можно скопировать например в тотале , а вот настройка шар надо настраивать
Я бы порекомендовал вместе с переносом файлов уходить от предоставления пользователям доступа к общей папке в виде \\server\share
Шаг 1й : Подключение шары как сетевого диска
Шаг 2й : настройка DFS и, соответственно подключение сетевого диска через DFS шару.
Шаг 3й : репликация DFS на новое место, отключение старого линка.
Если же стоит вопрос о скорейшем переносе то варианта два :
1. Подключить диски к новому серверу, выключив и выведя из AD старый. Создать такие же шары. Рассказать пользователям или в DNS прописать алиас со старого имени на новый.
2. xcopy /?
Дополнительно : можно пойти по пути, который посоветовал Андрей Ермаченок : наведение порядка еще никому не мешало.
Шаг 0. Установка служба хранилища Migration Service и проверка портов брандмауэра
Перед началом работы установите службу миграции хранилища и проверьте, чтобы все необходимые порты брандмауэра были открыты.
Проверьте требования служба хранилища Migration Service и установите последнюю версию Windows Admin Center на компьютере или на сервере управления, если вы еще этого не сделали. Кроме того, требуется последняя версия расширения служба хранилища Migration Service, которая устанавливается автоматически Windows Admin Center если расширения автоматического обновления включены в Параметры>Extensions. При миграции исходных компьютеров, присоединенных к одному домену, требуется установить и запустить службу миграции хранилища на сервере, присоединенном к тому же домену или лесу, что и исходные компьютеры.
В Windows Admin Center подключитесь к серверу оркестратора под управлением Windows Server 2019 или Windows Server 2022.
Это сервер, на который вы устанавливаете служба хранилища Migration Service и используете для управления миграцией. При миграции только одного сервера можно использовать целевой сервер, если он работает под управлением Windows Server 2019 или Windows Server 2022. Мы рекомендуем использовать отдельный сервер оркестрации для миграции нескольких серверов.
Перейдите к диспетчер сервера (в Windows Admin Center) >служба хранилища Migration Service и выберите "Установить", чтобы установить служба хранилища Migration Service и необходимые компоненты (см. рис. 1). Рис. 1. Установка служба хранилища Migration Service
Установите прокси-сервер служба хранилища Migration Service на всех конечных серверах под управлением Windows Server 2019 или Windows Server 2022. Это удвоит скорость передачи данных.
Для этого подключитесь к конечному серверу в Windows Admin Center, а затем перейдите к диспетчер сервера (в Windows Admin Center) >Роли и компоненты, >компоненты, выберите служба хранилища Прокси-сервер службы миграции, а затем выберите пункт Установите.
Если вы планируете выполнить миграцию в отказоустойчивые кластеры или из Windows, установите средства отказоустойчивой кластеризации на сервере оркестратора. Это происходит автоматически в последней версии Windows Admin Center при выборе параметра "Миграция из отказоустойчивых кластеров" в параметре "Задание Параметры инвентаризации".
Чтобы установить вне этапа инвентаризации служба хранилища Migration Service, подключитесь к серверу оркестратора в Windows Admin Center, а затем перейдите к диспетчер сервера (в Windows Admin Center) >роли и компоненты, компоненты, >> Средства удаленного администрирования сервера, >средства администрирования компонентов, выберите "Средства отказоустойчивой кластеризации", а затем выберите "Установить".
На всех исходных серверах и на всех конечных серверах, работающих Windows Server 2016 или Windows Server 2012 R2, в Windows Admin Center подключитесь к каждому серверу, перейдите к диспетчер сервера (в Windows Admin Center) > Правила брандмауэра>и убедитесь, что включены следующие правила:
- Общий доступ к файлам и принтерам (входящий трафик SMB)
- Служба NetLogon (NP-In)
- Инструментарий управления Windows (DCOM-In)
- Инструментарий управления Windows (WMI-In)
Если вы используете сторонние брандмауэры, открытые диапазоны входящих портов — TCP/445 (SMB), TCP/135 (сопоставитель конечных точек RPC/DCOM) и TCP 1025-65535 (временные порты RPC/DCOM). Порты службы миграции хранилища — TCP/28940 (Orchestrator) и TCP/28941 (прокси-сервер).
Если вы используете сервер оркестратора для управления миграцией и хотите скачать события или журнал передаваемых данных, убедитесь, что на этом сервере также включено правило брандмауэра для общего доступа к файлам и принтерам (SMB-In).
Известные проблемы
Убедитесь, что выполнены требования из обзора служба хранилища Migration Service и установлены последние обновления Windows на компьютере, на котором работает служба хранилища Migration Service.
Дополнительные сведения о следующих проблемах см. на странице известных проблем .
В этом разделе описывается перенос сервера Windows, отказоустойчивого кластера Windows, сервера Samba или массива NetApp FAS, включая их файлы и конфигурацию, на другой сервер Windows или отказоустойчивый кластер Windows с помощью служба хранилища Migration Service и Windows Admin Center. Миграция выполняет три шага после установки службы и открытия всех необходимых портов брандмауэра: инвентаризация серверов, передача данных и переход на новые серверы.
Вопросы и ответы
Шаг 2. Передача данных со старых серверов на конечные серверы
На этом шаге вы передаете данные после указания места его передачи на конечных серверах.
На странице учетных данныхtransfer dataEnter> введите учетные данные администратора, которые работают на целевых серверах, на которые требуется перенести, и нажмите кнопку "Далее".
На странице Добавление целевого устройства и сопоставлений отображается первый исходный сервер. Введите имя сервера или кластеризованного файлового сервера, на который требуется перенести, а затем выберите " Сканировать устройство". При миграции с исходного компьютера, присоединенного к домену, целевой сервер должен быть присоединен к тому же домену. Вы также можете нажать кнопку "Создать новую виртуальную машину Azure" , а затем использовать мастер для развертывания нового целевого сервера в Azure. Это автоматически масштабирует виртуальную машину, подготавливает хранилище, форматирует диски, присоединяет домен и добавляет прокси-сервер служба хранилища Migration Service в назначение Windows Server 2019 или Windows Server 2022. Вы можете выбрать один из Windows Server 2022 (рекомендуется), Windows Server 2019, Windows Server 2016 и Windows Server 2012 виртуальных машин R2 любого размера и использования управляемых дисков.
Для создания виртуальной машины Azure требуется следующее:
Ниже приведено видео, в котором показано, как использовать служба хранилища Migration Service для миграции на виртуальные машины Azure.
Сопоставьте исходные тома с целевыми томами, снимите флажок "Включить" для всех общих папок, которые вы не хотите перенести (включая все административные ресурсы, расположенные в системной папке Windows), и убедитесь, что флажок "Синхронизировать Файлы Azure" установлен для всех томов или общих папок, которые находятся на уровне облака с помощью Синхронизация файлов Azure, а затем нажмите кнопку "Далее".
При переносе серверов NetApp CIFS исходные тома не отображают буквы диска. Эти тома можно сопоставить с любыми целевыми томами, и можно сопоставить несколько томов CiFS NetApp с одинаковым целевым томом. Создаются новые пути к корневой папке, чтобы избежать перезаписи или конфликтов папок, а затем создаются общие папки на правильном уровне. В области сведений об общих папках показана структура папок, которую вы хотите создать.
Рис. 3. Исходный сервер и место, куда будет передано его хранилище
Добавьте целевой сервер и сопоставления для дополнительных серверов и затем нажмите Далее.
На странице "Настройка параметров передачи " укажите, следует ли переносить локальных пользователей и группы на исходных серверах, а затем нажмите кнопку "Далее". Это позволит воссоздать локальных пользователей и группы на целевых серверах, чтобы сохранить разрешения для файлов и общих папок, настроенные для них. Ниже приведены варианты миграции локальных пользователей и групп.
- Переименование учетных записей с тем же именем выбрано по умолчанию и переносит всех локальных пользователей и групп на исходном сервере. Если он находит локальных пользователей или группы с одинаковым именем в исходном и целевом расположении, он переименовывает их в назначении, если только они не встроены (например, пользователь "Администратор" и группа "Администраторы"). Не используйте этот параметр, если исходный или конечный сервер является контроллером домена.
- Повторное использование учетных записей с одинаковыми именами сопоставляется с именами пользователей и групп в исходном и целевом расположениях. Не используйте этот параметр, если исходный или конечный сервер является контроллером домена.
- Не передавайте пользователей и группы пропускает миграцию локальных пользователей и групп, что необходимо, если источник или назначение является контроллером домена, или при заполнения данных для репликации DFS (репликация DFS не поддерживает локальные группы и пользователи).
Перенесенные учетные записи пользователей отключены в месте назначения и назначены 127-символьный пароль, который является сложным и случайным, поэтому вам придется включить их и назначить новый пароль после завершения работы с ними. Это гарантирует, что старые учетные записи с забытыми и ненадежными паролями на исходном сервере не будут проблемой безопасности на целевом. Кроме того, вы можете просмотреть решение для паролей локального администратора (LAPS) как способ управления паролями локального администратора.
При переносе серверов NetApp CIFS нельзя перенести локальных пользователей и группы.
После завершения передачи проверьте целевой сервер, чтобы убедиться, что все передано правильно. Выберите журнал ошибок, только если требуется скачать журнал файлов, которые не были переданы.
Если вы хотите сохранить журнал аудита передачи или планируете выполнить несколько операций передачи в задании, нажмите кнопку "Передать журнал" или другие параметры сохранения журнала, чтобы сохранить копию CSV. При каждой последующем переносе сведения базы данных предыдущего запуска перезаписываются. При переносе большого количества файлов может потребоваться изменить время ожидания для сохранения этого CSV-файла. Дополнительные сведения см. в разделе служба хранилища Время ожидания при скачивании CSV-файла ошибки передачи
Здесь возможны три варианта:
- Перейдите к следующему шагу, чтобы конечные серверы приняли удостоверения исходных серверов.
- Рассмотрите возможность завершения миграции без использования удостоверений исходных серверов.
- Снова перенесите, скопировав только те файлы, которые были обновлены с момента последней передачи.
Если ваша цель — синхронизировать файлы с Azure, можно настроить конечные серверы с Синхронизация файлов Azure после передачи файлов или после перехода на конечные серверы (см. раздел "Планирование развертывания Синхронизация файлов Azure").
Поддерживается ли миграция контроллера домена?
Требования к целевым серверам
Целевой сервер должен работать под управлением одной из ниже перечисленных операционных систем:
- Windows Server, Semi-Annual Channel
- Windows Server 2022
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
Конечные серверы могут быть автономными или частью отказоустойчивого кластера Windows. Они не могут запускать Azure Stack HCI или использовать надстройку кластеризации, не относяющуюся к Майкрософт. Хотя служба служба хранилища Migration Service не поддерживает Файлы Azure в качестве назначения, она полностью поддерживает серверы, на которых работает агент Синхронизация файлов Azure с распределением по уровням в облаке.
Конечные серверы под управлением Windows Server 2022 или Windows Server 2019 имеют двойную производительность передачи более ранних версий Windows Server. Это повышение производительности обусловлено включением встроенной службы прокси-службы служба хранилища Migration Service.
Требования к исходным серверам
Исходный сервер должен работать в одной из следующих операционных систем:
- Windows Server, Semi-Annual Channel
- Windows Server 2022
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2
- Windows Server 2008
- Windows Server 2003 R2
- Windows Server 2003
- Windows Small Business Server 2003 R2
- Windows Small Business Server 2008
- Windows Small Business Server 2011
- Windows Server 2012 Essentials
- Windows Server 2012 R2 Essentials
- Windows Server 2016 Essentials
- Windows Server 2019 Essentials
- Windows Storage Server 2008
- Windows Storage Server 2008 R2
- Windows Storage Server 2012
- Windows Storage Server 2012 R2
- Windows Storage Server 2016
Примечание. Windows Small Business Server и Windows Server Essentials являются контроллерами домена. Служба миграции хранилища пока не может выполнять прямую миграцию контроллеров домена, но может проводить их инвентаризацию и переносить с них файлы.
Если оркестратор работает под управлением Windows Server 2019 с установленным пакетом KB5001384 или Windows Server 2022, можно перенести следующие дополнительные типы источников:
- Отказоустойчивые кластеры под управлением Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 или Windows Server 2008 R2 (Windows Server 2008 R2 поддерживает только инвентаризацию и передачу, а не прямую)
- Серверы Linux, использующие Samba. Мы проверили следующее:
- CentOS 7
- Debian GNU/Linux 8
- RedHat Enterprise Linux 7.6
- SUSE Linux Enterprise Server (SLES) 11 SP4
- Ubuntu 16.04 LTS and 12.04.5 LTS
- Samba 4.8, 4.7, 4.3, 4.2, and 3.6
Подробные этапы
Рис. 2. Служба хранилища Migration Service с описанием этапа прямой миграции
Вы можете отслеживать ход выполнения прямой миграции с помощью описаний каждого этапа, как показано на рисунке выше. В следующей таблице показаны все возможные этапы, а также ход выполнения, описание и все уточняющие примечания.
Ход выполнения Описание Примечания 0 % Прямая миграция простаит. 2 % Подключение к исходному компьютеру. Убедитесь, что требования для исходных и конечных компьютеров выполнены. 5 % Подключение к конечному компьютеру. 6 % Настройка разрешений безопасности для объекта компьютера в Active Directory. Реплицирует разрешения безопасности объектов Active Directory исходного компьютера на конечном компьютере. 8 % Убедитесь, что созданная временная учетная запись была успешно удалена на исходном компьютере. Убедитесь, что мы можем создать временную учетную запись с тем же именем. 11% Создание временной локальной учетной записи пользователя на исходном компьютере. Если исходный компьютер присоединен к домену, имя временного пользователя учетной записи — MsftSmsStorMigratSvc. Пароль состоит из 127 случайных символов юникода с буквами, цифрами, символами и изменениями регистра. Если исходный компьютер находится в рабочей группе, мы используем исходные учетные данные источника. 13 % Настройка политики фильтрации маркеров локальной учетной записи на исходном компьютере. Отключает политику, чтобы мы могли подключаться к источнику, если она не присоединена к домену. Дополнительные сведения о политике фильтрации маркеров локальной учетной записи см. здесь. 16 % Подключение к исходному компьютеру с помощью временной учетной записи локального пользователя. 19 % Убедитесь, что созданная временная учетная запись была успешно удалена на конечном компьютере. 22 % Создание временной локальной учетной записи пользователя на конечном компьютере. Если конечный компьютер присоединен к домену, имя временного пользователя учетной записи — MsftSmsStorMigratSvc. Пароль состоит из 127 случайных символов юникода с буквами, цифрами, символами и изменениями регистра. Если конечный компьютер находится в рабочей группе, мы используем исходные учетные данные назначения. 25 % Настройка политики фильтрации маркеров локальной учетной записи на конечном компьютере. Отключает политику, чтобы мы могли подключаться к назначению, если она не присоединена к домену. Дополнительные сведения о политике фильтрации маркеров локальной учетной записи см. здесь. 27 % Подключение к конечному компьютеру с помощью временной учетной записи локального пользователя. 30 % Удаление исходного компьютера из домена. 31% Сбор IP-адресов исходного компьютера. Применяется только к исходным компьютерам Linux. 33 % Перезапуск исходного компьютера. (1-й перезапуск) 36 % Ожидание ответа исходного компьютера после 1-го перезапуска. Скорее всего, он перестанет отвечать, если исходный компьютер не охвачен подсетью DHCP, но вы выбрали DHCP во время настройки сети. 38 % Сопоставление сетевых интерфейсов на исходном компьютере. 41 % Переименование исходного компьютера. 42% Перезапуск исходного компьютера. (1-й перезапуск) Применяется только к исходным компьютерам Linux. 43% Перезапуск исходного компьютера. (2-й перезапуск) Применяется только к присоединенным к домену компьютерам Windows Server 2003. 43% Ожидание ответа исходного компьютера после 1-го перезапуска. 43% Ожидание ответа исходного компьютера после 2-го перезапуска. 44 % Добавление исходного компьютера в домен. 47 % Перезапуск исходного компьютера. (1-й перезапуск) 50 % Перезапуск исходного компьютера. (2-й перезапуск) 51 % Перезапуск исходного компьютера. (3-й перезапуск) Применяется только к исходным компьютерам Windows Server 2003. 52% Ожидание ответа исходного компьютера. 52% Ожидание ответа исходного компьютера после 1-го перезапуска. 55 % Ожидание ответа исходного компьютера после 2-го перезапуска. 56 % Ожидание ответа исходного компьютера после 3-го перезапуска. 57% Удаление альтернативных имен компьютеров в источнике. Гарантирует, что источник недоступен другим пользователям и приложениям. Дополнительные сведения см. в разделе Netdom computername. 58 % Удаление временной локальной учетной записи, созданной на исходном компьютере. 61 % Сброс политики фильтрации маркеров локальной учетной записи на исходном компьютере. Включает политику. 63 % Удаление конечного компьютера из домена. 66 % Перезагрузка конечного компьютера. (1-й перезапуск) 69% Ожидание ответа конечного компьютера после 1-го перезапуска. 72 % Сопоставление сетевых интерфейсов на конечном компьютере. Карты каждый сетевой адаптер и IP-адрес исходного компьютера на конечный компьютер, заменив сведения о сети назначения. 75 % Переименование конечного компьютера. 77 % Добавление конечного компьютера в домен. Конечный компьютер берет на себя старый объект Active Directory исходного компьютера. Это может завершиться ошибкой, если конечный пользователь не является членом администратора домена или не имеет прав администратора на объект Active Directory исходного компьютера. Вы можете указать альтернативные учетные данные назначения на шаге "Ввести учетные данные" перед началом прямой передачи. 80 % Перезагрузка конечного компьютера. (1-й перезапуск) 83 % Перезагрузка конечного компьютера. (2-й перезапуск) 84% Ожидание ответа конечного компьютера. 86% Ожидание ответа конечного компьютера после 1-го перезапуска. 88 % Ожидание ответа конечного компьютера после 2-го перезапуска. 91 % Ожидание ответа конечного компьютера с новым именем. Может занять много времени из-за репликации Active Directory и DNS. 93 % Удаление альтернативных имен компьютеров в месте назначения. Гарантирует, что имя назначения было заменено. 94 % Удаление временной локальной учетной записи, созданной на конечном компьютере. 97% Сброс политики фильтрации маркеров локальной учетной записи на конечном компьютере. Включает политику. (100%) Выполнено Сводка
Рис. 1. Настройка прямой миграции служба хранилища Migration Service
Перед началом прямой миграции необходимо указать сведения о конфигурации сети, необходимые для перехода с исходного компьютера на конечный компьютер. Вы также можете выбрать новое уникальное имя для исходного компьютера или позволить служба хранилища Migration Service создать случайное имя.
Затем служба хранилища Migration Service выполняет следующие действия, чтобы перерезать исходный компьютер на конечный компьютер:
Мы подключаемся к исходным и конечным компьютерам. У них уже должны быть включены следующие правила брандмауэра:
- Общий доступ к файлам и принтерам (SMB-in), TCP-порт 445
- Служба Netlogon (NP-In), TCP-порт 445
- инструментирование управления Windows (DCOM-In), TCP-порт 135
- Windows инструментарий управления (WMI-in), TCP, любой порт
Мы устанавливаем разрешения безопасности на конечном компьютере в доменные службы Active Directory в соответствии с разрешениями исходного компьютера.
Мы создадим временную локальную учетную запись пользователя на исходном компьютере. Если компьютер присоединен к домену, имя пользователя учетной записи — MsftSmsStorMigratSvc. Мы отключаем политику фильтрации маркеров локальной учетной записи на исходном компьютере, чтобы разрешить эту учетную запись, а затем подключитесь к исходному компьютеру. Мы создадим эту временную учетную запись, чтобы после перезагрузки и удаления исходного компьютера из домена мы по-прежнему могли получить доступ к исходному компьютеру.
Мы повторяем предыдущий шаг на конечном компьютере.
Мы удаляем исходный компьютер из домена, чтобы освободить учетную запись Active Directory, которую конечный компьютер позже возьмет на себя.
Мы сопоставляем сетевые интерфейсы на исходном компьютере и переименуем исходный компьютер.
Мы добавим исходный компьютер обратно в домен. Исходный компьютер теперь имеет новое удостоверение и доступен администраторам, но не пользователям и приложениям.
На исходном компьютере мы удаляем все затяжные альтернативные имена компьютеров, удаляем созданную временную локальную учетную запись и повторно включаем политику фильтрации маркеров локальной учетной записи.
Мы удаляем конечный компьютер из домена.
Мы заменим IP-адреса на конечном компьютере ip-адресами, предоставленными источником, а затем переименуем конечный компьютер в исходное имя исходного компьютера.
Мы присоединяем конечный компьютер к домену. При присоединении она использует исходную учетную запись компьютера-источника Active Directory. Это сохраняет членство в группах и списки управления доступом безопасности. Конечный компьютер теперь имеет удостоверение исходного компьютера.
На конечном компьютере мы удаляем все затяжные альтернативные имена компьютеров, удаляем созданную временную локальную учетную запись и повторно включаем политику фильтрации маркеров локальной учетной записи, завершив прямую миграцию.
После завершения прямой миграции конечный компьютер взял на себя удостоверение исходного компьютера, и затем вы можете высвоить исходный компьютер.
Требования
Служба миграции хранилища работает при наличии следующих условий:
- Исходный сервер или отказоустойчивый кластер для переноса файлов и данных из
- Конечный сервер под управлением Windows Server 2019 или Windows Server 2022 (кластеризованный или автономный) для миграции. Windows Server 2016 и Windows Server 2012 R2 работают, но примерно на 50 % медленнее
- Сервер оркестратора под управлением Windows Server 2019 или Windows Server 2022 для управления миграцией
Если выполняется миграция только нескольких серверов, а один из серверов работает под управлением Windows Server 2019 или Windows Server 2022, его можно использовать в качестве оркестратора. Если вы переносите больше серверов, рекомендуется использовать отдельный сервер оркестратора. - Компьютер или сервер, на котором выполняется последняя Windows Admin Center для запуска пользовательского интерфейса служба хранилища Migration Service, а также последнее средство служба хранилища Migration Service (расширение), доступное в веб-канале. Windows Admin Center должна быть не ниже версии 2103.
Настоятельно рекомендуется, чтобы оркестратор и конечные компьютеры имели по крайней мере два ядра или два виртуальных ЦП и не менее 2 ГБ памяти. Чем больше процессоров и памяти, тем быстрее выполняются инвентаризация и перемещение.
Зачем использовать служба хранилища Migration Service
Используйте служба хранилища Migration Service, так как у вас есть сервер (или много серверов), который требуется перенести на более новое оборудование или виртуальные машины. служба хранилища Migration Service предназначена для выполнения следующих действий:
- Инвентаризация нескольких серверов и их данных
- Быстрая передача файлов, общих папок и конфигурации безопасности с исходных серверов
- При необходимости удостоверяйте исходные серверы (также называемые перерезанием), чтобы пользователям и приложениям не нужно ничего изменять для доступа к существующим данным.
- Управление одной или несколькими миграциями из пользовательского интерфейса Windows Admin Center
Рис. 1. Источники и назначения Службы миграции служба хранилища
Требования безопасности, прокси-сервер службы миграции хранилища и порты брандамауэра
Учетная запись миграции, которая является администратором на исходных компьютерах и компьютере оркестратора. Это может быть домен или локальная учетная запись, за исключением случаев, когда компьютер не присоединен к домену, в этом случае он должен быть локальным пользователем.
Учетная запись миграции, которая является администратором на конечных компьютерах и компьютере оркестратора. Это может быть домен или локальная учетная запись, за исключением случаев, когда компьютер не присоединен к домену, в этом случае он должен быть локальным пользователем.
На компьютере оркестратора должен быть включено правило брандмауэра для общего доступа к файлам и принтерам (SMB-In).
На исходных и конечных компьютерах должны быть включены следующие правила брандмауэра (хотя они уже включены):
- Общий доступ к файлам и принтерам (входящий трафик SMB)
- Служба NetLogon (NP-In)
- Инструментарий управления Windows (DCOM-In)
- Инструментарий управления Windows (WMI-In)
Установка прокси-службы служба хранилища Migration Service на компьютере Windows Server 2019 или Windows Server 2022 автоматически открывает необходимые порты брандмауэра на этом компьютере. Для этого подключитесь к конечному серверу в Windows Admin Center, а затем перейдите к диспетчер сервера (в Windows Admin Center) >Ролям и компонентам, выберите служба хранилища Прокси-сервер Службы миграции, а затем нажмите кнопку "Установить".
Если компьютеры принадлежат домену доменные службы Active Directory, они должны принадлежать к одному лесу. Целевой сервер также должен находиться в том же домене, что и исходный, если во время прямой миграции необходимо передать доменное имя исходного объекта целевому. Прямая миграция технически работает в разных доменах, но полное доменное имя назначения будет отличаться от источника.
Миграция виртуальных машин Azure
Windows Admin Center интегрирует развертывание Azure IaaS в служба хранилища Migration Service. Вместо создания новых серверов и виртуальных машин на портале Azure вручную перед развертыванием рабочей нагрузки и, возможно, отсутствующих необходимых действий и конфигурации, Windows Admin Center может развернуть виртуальную машину Azure IaaS, настроить хранилище, присоединить ее к домену, установить роли и настроить распределенную систему.
Ниже приведено видео, в котором показано, как использовать служба хранилища Migration Service для миграции на виртуальные машины Azure.
Если вы хотите поднять и перенести виртуальные машины в Azure без миграции в более позднюю операционную систему, рассмотрите возможность использования службы "Миграция Azure". Дополнительные сведения см. в обзоре службы "Миграция Azure".
Принцип работы процесса миграции
Процесс миграции включает в себя три этапа:
- Серверы инвентаризации для сбора сведений о своих файлах и конфигурации (см. рис. 2).
- Передача (копирование) данных с исходных серверов на целевые серверы.
- Переключите на новые серверы (необязательно).
Целевым серверам назначают идентификаторы исходных серверов, чтобы приложениям и пользователям не нужно было вносить изменения.
Исходные серверы входят в состояние обслуживания, в котором они по-прежнему содержат те же файлы, которые они всегда имеют (мы никогда не удаляем файлы с исходных серверов), но недоступны для пользователей и приложений. Серверы можно вывести из эксплуатации в удобное для вас время.
Рис. 2. Служба хранилища серверы инвентаризации Службы миграции
Ниже приведено видео, в котором показано, как использовать служба хранилища Migration Service для принятия сервера, например сервера Windows Server 2008 R2, который теперь не поддерживается, и переместить хранилище на более новый сервер.
Читайте также: