Задача: сохранить рабочие сценарии
В моей практике была миграция более 700 пользователей и рабочих станций между доменами Active Directory. Важно было сохранить возможность работать: вход в систему, привычный профиль, доступ к ресурсам и приложениям. В этом кейсе перенос прошёл без остановки работы бизнеса. Это результат конкретного проекта, а не обещание для любой инфраструктуры.
Здесь не публикую названия доменов, структуру прав и рабочие скрипты. Для другого заказчика эти детали всё равно потребуют отдельного обследования. Полезнее объяснить, какие вопросы нужно закрыть до начала переноса.
Что проверить до миграции
- Какие пользователи, компьютеры и группы входят в область работ.
- Какие приложения и сетевые ресурсы зависят от старого домена.
- Где находятся пользовательские данные и как проверяется резервная копия.
- Как выглядит успешный вход и что делать, если он не проходит.
- Кто согласует окно работ и принимает результат.
Без такой карты можно перенести учётную запись и обнаружить, что человек потерял доступ к своей основной программе. Поэтому техническое завершение операции и готовность рабочего места — разные проверки.
Зачем нужна автоматизация
Повторяемые действия в этом проекте я автоматизировал средствами PowerShell и C#. Автоматизация уменьшает ручной ввод и помогает выполнять одинаковые проверки. Она не отменяет пилот на ограниченной группе, резервное копирование и возможность вернуться к исходному состоянию.
Сначала имеет смысл проверить несколько типовых рабочих мест: обычного сотрудника, пользователя специализированного приложения и человека с нестандартными правами. Разные сценарии выявляют разные зависимости.
Как принимать результат
Проверка должна включать реальный вход пользователя, доступ к данным и выполнение основных рабочих действий. Нужен также список исключений: что перенесено, что требует отдельного решения и кто за него отвечает.
Главный вывод моего кейса: сначала описываем зависимые процессы и критерии приёмки, потом выбираем инструменты. Этот принцип работает и в автоматизации бизнес-процессов, и при изменении обычного внутреннего сервиса.
