Миграция рабочих мест с Windows на Linux: что проверить, кроме установки ОС

Переустановить операционную систему и вернуть сотруднику работоспособное рабочее место — две разные задачи. При переходе с Windows на Linux меняются приложения, способы настройки и пользовательское окружение.

Что вопрос многих касается на практике, видно по поиску. Столько показов в месяц Яндекс Директ прогнозирует по таким запросам (прогноз на ноябрь 2026 года):

ввод astra linux в домен 287

миграция на linux 185

перейти на linux с windows 89

установка astra linux по сети 67

ввод ред ос в домен 60

миграция с windows на linux 59

Главная прикладная сложность такого перехода — замена Microsoft Office и сохранение полноценной работы с корпоративными документами. Открытие файла ещё не подтверждает совместимость: проблемы возникают с макросами, надстройками, сложными расчётными моделями и шаблонами. Отдельного решения требует САПР и другое специализированное ПО. UEM автоматизирует подготовку компьютера, но совместимость приложений и документов нужно решать отдельно.

Для части офисных задач можно использовать веб-приложения Microsoft 365, если это допускают требования организации. Однако браузерные версии не обеспечивают полную совместимость с настольным Office во всех сценариях. Для зависимых от него процессов может потребоваться сохранение Windows-среды с удалённым доступом. Конкретный вариант нужно проверить на реальных документах.

Мы, команда RuDesktop, разберём эти задачи на примере RuDesktop 3.1: продукт помогает автоматизировать перенос рабочих файлов, развёртывание ОС, установку ПО и ввод устройств в домен. Сосредоточимся на том, как перенести данные и подготовить устройства к работе в корпоративной инфраструктуре. Поведение продукта описываем по документации, ссылки на разделы стоят в тексте; замеров со своего стенда в статье нет.

«Российский Linux» нужно превратить в точную конфигурацию

Для воспроизводимого развёртывания недостаточно выбрать название дистрибутива. Необходимо зафиксировать выпуск ОС, архитектуру, состав репозиториев, графическую среду, набор приложений и настройки безопасности.

В документации RuDesktop среди типов образов указаны Astra Linux, ALT Linux и РЕД ОС. Конкретный выпуск и аппаратную конфигурацию следует проверять на пилоте.

Паспорт целевой конфигурации должен позволять ответить на вопрос: «Какое именно окружение мы проверили и можем повторно развернуть?»

В него стоит включить:

• источник и контрольную сумму ISO;

• выпуск ОС и используемые репозитории;

• версии критичных приложений;

• параметры подключения к инфраструктуре;

• сценарии установки и настройки ПО;

• результаты проверки оборудования.

Особенно полезно тестировать полный цикл: установка, настройка, обновление и повторная проверка рабочих операций. Конфигурация, которая работает сразу после развёртывания, должна оставаться обслуживаемой.

Для пилота следует брать устройства с разными сетевыми адаптерами, видеоподсистемами, накопителями и периферией. Одна виртуальная машина не воспроизводит аппаратные особенности всего парка.

Перенос файлов не равен переносу окружения

В сценарии RuDesktop можно выбрать рабочие папки пользователей — «Документы», «Загрузки», «Рабочий стол» и другие каталоги. Данные также могут находиться на дополнительном диске или в каталоге приложения: такие пути нужно включить в перенос отдельно.

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

В RuDesktop сценарий миграции определяет целевой образ, состав пользователей и данных, а также задачи после восстановления. На этапе сбора формируются TAR-архивы и manifest.json; архивы сохраняются в SMB-каталог сервера и проверяются по размеру и SHA-256. Далее следуют переключение в PXE, установка Linux и восстановление. Этот механизм доступен в локальном сервере UEM. Документация: миграции.

Здесь нужно различать две проверки.

Проверка целостности подтверждает соответствие архива ожидаемому содержимому на уровне контрольной суммы. Проверка полноты отвечает на другой вопрос: попали ли в сбор все необходимые данные. Корректный архив может не содержать важную папку, если её не включили в сценарий.

Есть и третий уровень — пригодность данных к работе. В документации прямо указано, что программы и реестр Windows не переносятся. Данные браузеров сохраняются как файлы, при этом работоспособность восстановленного профиля не гарантируется и зависит от совместимости форматов и версий. Документация: действия после миграции.

Следовательно, для браузеров, почтовых клиентов и специализированных приложений нужно заранее проверить поддерживаемый способ переноса. Наличие каталога профиля ещё не подтверждает, что приложение сможет использовать его в новой ОС.

Сотрудник будет искать файлы там, где привык, поэтому место восстановления стоит знать заранее и включить в инструкцию:

Учётные записи переносятся по-разному. Локальные пароли Windows не сохраняются: сотрудник входит с временным паролем из сценария и обязан сменить его при первом входе. На ALT Linux и РЕД ОС кириллические имена локальных пользователей транслитерируются: Иванов становится ivanov. Доменные пользователи сохраняют имя и входят со своим паролем. Выбранные браузеры перед сбором закрываются принудительно, поэтому сотрудников предупреждают заранее. Документация: подготовка к миграции.

PXE меняет требования к организации работ

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

В инструкции RuDesktop предусмотрено включение Network Stack и IPv4 PXE Support, а также отключение Fast Boot. Ставить PXE первым вариантом загрузки не требуется: на UEFI сервер задаёт одноразовую загрузку через bcdedit, на BIOS/Legacy при неудаче ломает загрузку с диска, чтобы устройство ушло на следующий вариант. Поэтому запись PXE должна быть зарегистрирована в прошивке заранее. Встроенный PXE-сервер описан как работающий в одной локальной сети с устройством. Для удалённых сетей документация предусматривает отдельный экземпляр сервера или внешние средства. Документация: подготовка к миграции.

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

Отдельная точка контроля — выбор накопителя. Документация предупреждает, что установка Linux стирает выбранный установщиком диск, а при нескольких физических дисках может быть выбран любой подходящий. Документация: этапы миграции.

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

Ввод устройства в домен после установки Linux

После установки Linux устройство нужно ввести в корпоративный домен. В сценарии миграции это происходит на этапе восстановления, если на устройстве есть доменные пользователи. В сценарии нужно заполнить логин и пароль учётной записи с правом ввода устройств в домен: без них этап завершится ошибкой. Вне сценария миграции для этого предусмотрена политика «Ввод устройства в домен». Администратор задаёт необходимые параметры и учётные данные, а затем проверяет применение политики на целевой конфигурации. Управление пользователями, правами доступа и политиками безопасности остаётся задачей службы каталогов.

Если ввод не проходит, в документации политики названы такие причины и особенности Linux:

• адрес контроллера домена на Linux обязателен;

• некорректный DNS — одна из самых частых причин ошибок;

• заметное расхождение времени с контроллером домена мешает работе Kerberos;

• при некорректном hostname политика завершится ошибкой до попытки ввода, как и при конфликте с существующей учётной записью компьютера;

• realm list на некоторых системах не показывает подключение даже при успешном вводе, поэтому результат подтверждается через adcli testjoin и наличие файлов конфигурации;

• политика меняет /etc/krb5.conf, /etc/sssd/sssd.conf, /etc/nsswitch.conf и настройки PAM, а после успешного ввода перезагружает устройство.

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

Рекомендуем проверять такую операцию на пилоте с реальными ограничениями доступа. Учётная запись, под которой всё работает в лаборатории, может иметь существенно больше прав, чем разрешено в рабочей инфраструктуре.

Подготовку приложений нужно включить в сценарий

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

В RuDesktop для этого предусмотрено поле «Задачи после миграции». Оно отличается от поля «Задачи после установки» в образе ОС: при миграции используются именно задачи сценария миграции. Выбранные задачи выполняются однократно после восстановления; их обычное расписание игнорируется. Документация: задачи после миграции.

Эту разницу важно проверить на стенде. Образ, который корректно подготавливает компьютер при чистой установке, может потребовать отдельной настройки сценария переноса.

Для собственных скриптов рекомендуем придерживаться трёх правил:

1. Проверять исходное состояние перед изменением.

2. Завершаться с понятным результатом и диагностикой.

3. Корректно обрабатывать повторный запуск.

Например, установка сертификата должна проверять его наличие, а изменение конфигурации — учитывать уже внесённые параметры. Это упрощает восстановление после частичного выполнения и уменьшает объём ручной диагностики.

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

Продолжение после ошибки и возврат на Windows — разные процедуры

Миграцию нужно планировать с учётом частичного успеха: данные собраны, ОС установлена, но восстановление не завершилось.

В RuDesktop задача хранит состояние каждого устройства и журнал выполнения. После устранения причины ошибки действие «Запустить/продолжить миграцию» повторяет неуспешный этап; успешно завершённые этапы повторно не запускаются. Действие «Сбросить миграцию» имеет другую семантику и возвращает обработку к началу. Документация: задачи миграции.

Разница существенна: после сброса повторный сбор удаляет ранее собранные TAR-архивы и манифест устройства. Если на устройстве уже стёрта Windows, эти архивы могут оказаться единственной копией данных, поэтому их сохраняют отдельно до сброса.

Типовые причины ошибок, которые называет документация:

• не заполнены учётные данные администратора домена, а на устройстве есть доменные пользователи;

• устройство недоступно при сборе данных: запуск повторяется до 10 раз с интервалом 30 секунд;

• не настроены PXE или DHCP, и устройство не получило загрузочный образ.

Это механизм продолжения процесса. Возврат к исходной ОС нужно проектировать отдельно: документация раздела установки ОС ограничивает миграцию направлением Windows → Linux и не предусматривает обратный сценарий. Документация: установка ОС.

План возврата должен определять, чем восстанавливаются Windows, приложения и данные, кто принимает решение и сколько времени отведено на восстановление. Для критичных ролей имеет смысл подготовить подменное рабочее место.

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

Масштабировать стоит по результатам приёмки

Предлагаем начинать с технического стенда, затем переходить к пилотной группе сотрудников и только после этого — к последовательным волнам.

Пилот должен представлять будущий парк: разные роли, периферию, способы аутентификации и объёмы данных. Если в него входят только сотрудники ИТ, значительная часть прикладных проблем останется незамеченной.

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

Размер волны стоит выбирать по объёму переноса и возможностям инфраструктуры. Пятьдесят компьютеров с небольшими профилями и столько же устройств с локальными архивами — разная нагрузка на сеть и хранилище.

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

Техническое завершение миграции и готовность сотрудника к работе следует проверять отдельно.

В RuDesktop ориентиром завершения процесса служит состояние устройства «Готово». До него на компьютере могут продолжаться восстановление и задачи UEM. Документация: контроль состояния устройств.

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

Сотруднику также понадобится короткая инструкция: как войти, где находятся перенесённые файлы, какие приложения использовать и куда обращаться за помощью. Её стоит готовить по результатам пилота, когда уже известны реальные вопросы пользователей.

Документация RuDesktop

• Установка ОС

• Сценарии миграции

• Задачи миграции

• Кейс «Миграция Windows → Linux»

• После миграции

• Ввод устройства в домен

Вместо вывода — кратко о сказанном выше

• Успешная установка Linux не подтверждает, что сотрудник может работать: совместимость документов и профильного ПО проверяется отдельно.

• Архив проверяют трижды: на целостность, на полноту и на пригодность данных к работе.

• Загрузку по PXE проверяют в каждом сетевом сегменте, а состав дисков — до переустановки.

• «Продолжить» и «Сбросить» — разные действия, и ни одно из них не возвращает Windows.

• Волны растут только после приёмки, а условия остановки определяют заранее.

В процессе миграции RuDesktop связывает перенос пользовательских данных, установку Linux, подготовку приложений и ввод устройств в домен. Это сокращает объём повторяющихся действий администратора. Готовность корпоративных документов и специализированного ПО остаётся отдельной частью проекта: её нельзя подтвердить успешной переустановкой ОС. Миграция доступна в локальном сервере RuDesktop UEM.

Если вы переводили рабочие места с Windows на Linux, расскажите в комментариях: какой дистрибутив выбрали, сколько устройств было в первой волне и что сломалось первым — макросы, домен, загрузка по PXE или что-то ещё. По поисковым запросам мы видим, что чаще всего спрашивают про ввод в домен. Возможно, у вас главной проблемой оказалось другое.