Я в настоящее время адски провожу время над тем, что кажется, должно быть довольно простым проектом.
В принципе, $employer есть куча удаленных сайтов с древним оборудованием, имитирующим реальные серверы, и они заменяют их настоящими серверами. Или, точнее, они покупают новые серверы и заставляют меня заменять их. Сайты, как правило, небольшие, поэтому ничего сложного - мы просто предоставляем файловый сервер, службы печати и контроллер домена / DHCP-сервер для всех сайтов.
Проблема, конечно же, связана с перенаправлением профиля пользователя. У всех наших пользователей есть свои My Documents каталог, перенаправленный на файловый сервер, например: \\[crappy-old-server]\users\%username%. Поскольку мы пытаемся сделать все правильно, мы настраиваем DFS на новых серверах и меняем его на: \\[not-crappy-DFS-root]\[sitename]\users\%username%.
Эта часть работает очень хорошо, и после миграции файлового сервера с Набор средств миграции файлового сервера Microsoft, мы бегаем csccmd чтобы указать общую папку на клиентских машинах в новое место, измените некоторые вещи в Active Directory и групповой политике (подключенные диски, принтеры и т. д.) и завершите работу.
Проблема, однако, в том, что при перемещении инструмента csccmd некоторые ссылок реестра на старый сервер, реестр клиента по-прежнему содержит плохие ссылки (MRU, путь Bit Bucket Recycler, принтеры, значения по умолчанию для приложений, точки монтирования, папки Shell, Net Cache и т. д.) и, как следствие, пользователи не могут даже открыть меню «Пуск», не получив тайм-аутов сети, потому что некоторые настройки ищут что-то в \\[crappy-old-server]\users\%username% вместо того \\[not-crappy-DFS-root]\[sitename]\users\%username%. Буквально на то, чтобы сделать что угодно, требуется не менее 30 секунд, что недопустимо.
Чтобы решить эту проблему, я вручную на каждой клиентской машине открывал regedit, выполнял поиск по старой строке сервера и при обнаружении либо удалял ключ, либо заменял старое имя сервера новым путем DFS. Это, очевидно, отстой, и я думаю, что просто должен быть лучший способ, потому что мое текущее решение вообще не масштабируется, и при более крупных миграциях пользователей, должно быть, использовался более автоматизированный подход к этой проблеме.
Итак, как лучше это сделать, не выполняя поиск в реестрах клиентов вручную?
Вы можете установить на каждом сайте машину, отвечающую за \\[crappy-old-server]\users как автономный корень DFS с users являясь ссылкой DFS на новый \\[not-crappy-DFS-root]\[sitename]\users папка. Вы можете использовать сервер, который развертываете на каждом сайте, используя OptionalNames, предполагая, что у вас еще нет общего ресурса с именем users.