none
Перенос больших перенаправляемых папок пользователей на новый файловый сервер RRS feed

  • Вопрос

  • Добрый день, коллеги!

    Есть тривиальная задача - перевезти перемещаемые профили пользователей на новый файловый сервер в том же домене, но - с другим именем.

    На первый взгляд - ничего сложного: указать новый сервер в новой политике, перетащить под эту политику юзеров, и они благополучно переедут сами собой. НО. Всё упирается в то, что у многих пользователей в профилях лежат огромные (до десятков ГБ) объёмы документов. (Да, зачастую это мёртвый груз, но такова специфика и ругаться и уговаривать - СЕЙЧАС бессмысленно). Если перевозить юзеров штатной процедурой, то переезд одного такого "тяжёлого" юзера может занять несколько часов (я, кстати, не понимаю, почему так медленно? - сеть между серверами 10Gb, и обычное копирование того же объёма занимает считанные минуты... А вот переезд юзера с 3ГБ в профиле посредством политики занял около 40 минут), и всё это время у юзера висит надпись "Добро пожаловать" и крутятся часики. Это в рабочее время недопустимо.

    Есть ли идеи, как обмануть систему и "подпихнуть" домену новый сервер, заранее (в офлайне) перенеся на него профили юзеров, чтобы эта процедура стала для них прозрачной и быстрой? 

    Заранее благодарен!


    • Изменено ekotik 9 февраля 2016 г. 11:57
    8 февраля 2016 г. 12:19

Ответы

  • Скопируйте содержимое перенаправленных папок с правами доступа.

    Измените путь в GPO и снимите  Вот эту галку.

    Изменится только сам путь без фактического перемещения контента.


    Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку "Предложить как ответ" или "Пометить как ответ".

    http://zalozny.com.ua



    • Изменено Alexander Zalozny 9 февраля 2016 г. 13:37
    • Предложено в качестве ответа Alexander Zalozny 10 февраля 2016 г. 9:06
    • Помечено в качестве ответа ekotik 10 февраля 2016 г. 11:25
    9 февраля 2016 г. 13:35

Все ответы

  • не думаю, что есть такая возможность, и скорее всего Вам придется или договориться с пользователями или ждать
    9 февраля 2016 г. 10:05
  • Может быть, есть мысли, почему "штатный процесс" столь затянут? и копнуть в сторону обеспечения тепличных условий для миграции? Как я говорил в скобках - копирование занимает несколько минут, а перенос с пом. GP - многие часы... Why??
    9 февраля 2016 г. 10:11
  • А вот переезд юзера с 3ГБ в профиле посредством политики занял около 40 минут), и всё это время у юзера висит надпись "Добро пожаловать" и крутятся часики. Это в рабочее время недопустимо.

    т.е. каждое утро, когда пользователи входят в систему, и каждый вечер, когда пользователи выходят из системы - они ожидают по 40 минут?

    но такова специфика и ругаться и уговаривать - СЕЙЧАС бессмысленно

    рекомендация: попробуйте исключить папки с тяжёлыми файлами, с помощью перенаправляемых папок, перенаправив их отдельное сетевое расположение (общую папку). В таком случае, пользователи будут открывать свои документы "по сети".

    ну а по поводу вашей задачи, посмотрите эту тему. Можно попробовать переместить файлы с сервера на сервер и поменять политику с новым именем.



    9 февраля 2016 г. 10:13
    Модератор
  • ненене... Это НЕ AppData, юзер не ждёт пока его профиль перечитается! Иначе я бы с Вами не разговаривал ))) И вообще roaming НЕ используется. Речь идёт о файлах (документах, зачастую - просто архивах за несколько лет - "ооочччень нууужных!!!"), которые лежат в юзерских папках РабСтол и МоиДок-ты, на файловом сервере. В процитированном Вами куске ключевое слово - "ПЕРЕЕЗД". Эти эмпирические данные я получил, когда тестировал переезд "тяжёлых" юзеров на лабе. Создал домен, два файлера, завёл юзера под гп с переносом РабСтола и Док-тов. Накачал его профиль 3-мя гигами, и поменял в ГП имя файловика на другое. Перелогинил юзера, его профиль полился на новый, указанный в ГП файлер. Загрузка сетевушки составила 5-7%, и вот так, неспешно - 40 минут - текло, пока не вытекло всё... А вот прямой move того же профиля между теми же серверами (при загрузке сетевой карты под 80%) всё ушло за пару минут. У меня есть много таких "красивых юзеров" с 50-70 Гигами барахла... :( Это уже даже не 3 гига...  А всего там человек 70, и всё дико занятые. Делать-то чё? :((
    9 февраля 2016 г. 10:47
  • И вообще roaming НЕ используется ....
    Создал домен, два файлера, завёл юзера под гп с переносом РабСтола и Док-тов.

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

    и поменял в ГП имя файловика на другое
    на другой сервер перед сменой ГП, файлы со старого копировали?
    9 февраля 2016 г. 11:00
    Модератор
  • а тупо перетащить дату на новый сервак с теми же путями,  старый отрубить, а в днс запилить алиас старого на новый не судьба?
    9 февраля 2016 г. 11:36
  • Вы правы - поправку с терминологией принимаю. Действительно, речь о перенаправлении папок. Да, копировал. С сохранением всех прав доступа. Это была самая первая мысль. Вот прямо сейчас не могу точно вспомнить, во что я упёрся, но "оно" не прокатило. Не помню из-за того, что после этой первой мысли было много других "извратов"... Пожалуй, надо ещё раз экспериментнуть, освежить голову.
    9 февраля 2016 г. 11:56
  • Нечто похожее опробовал. Собственно, именно для этого лабу и строил. Правда, схема была немного иная - алиас нового сервера я в ДНС дал старому. После этого в ГП поменял имя старого на имя нового, на который скопировал все данные со старого, в надежде потом убрать (переименовать) старый сервер, а вместо алиаса включить сам новый сервер. (Во, вспомнил, во что упёрся!). Затем перелогинил юзера. Никакой ругани в логах, ГП отработала, ни на что не ругаясь (ибо нашла имя файлового сервера, он же - алиас нового)... НО! Путь на старый файловик остался активным, ибо этот путь прописывается в реестр рабочей станции в пользовательский профиль. 

    Ваш вариант (с алиасом старого сервера на новом) имеет все шансы прокатить... хотя, это тоже костыль. Но ведь можно потом по-тихому юзерам и реестр ремоутно подправить, когда они уже де-факто будут на новом месте работать. Надо отрепетировать.

    Спасибо!

    9 февраля 2016 г. 13:17
  • Скопируйте содержимое перенаправленных папок с правами доступа.

    Измените путь в GPO и снимите  Вот эту галку.

    Изменится только сам путь без фактического перемещения контента.


    Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку "Предложить как ответ" или "Пометить как ответ".

    http://zalozny.com.ua



    • Изменено Alexander Zalozny 9 февраля 2016 г. 13:37
    • Предложено в качестве ответа Alexander Zalozny 10 февраля 2016 г. 9:06
    • Помечено в качестве ответа ekotik 10 февраля 2016 г. 11:25
    9 февраля 2016 г. 13:35
  • Серъёзная заявка на победу. Спасибо, коллега! Пошёл проверять в лабу.

    На кнопку "ответ" нажать не забуду!

    9 февраля 2016 г. 13:45
  • DFS имена сделайте на будущее.

    Сазонов Илья

    https://isazonov.wordpress.com/

    10 февраля 2016 г. 8:16
    Модератор
  • Александр, Ваше решение отработало правильно, хотя и с неким "но". Весьма, надо сказать, неприятным... На макете отработал на двух юзерах - с идентичным результатом. Дело в том, переключение под новую политику (с изменёнными путями) происходит только после второго входа пользователя в систему.

    После копирования юзерских данных на новый сервер (рабочая станция в это время выключена) и перевода учётки пользователя под управление новой политики (с редиректом на новый файловик), юзер, включая рабочую станцию, остается ещё под управлением СТАРОЙ политики, и все пути смотрят ещё на старый сервер. В event'ах пишется, что "Применение политики отложено из-за того, что действует оптимизация входа групповой политики". В это время учётка пользователя, видимо, обнаруживает, что она теперь должна подчиняться новой политике, и радостно ждёт, когда ей предоставят такую возможность. Юзер же тем временем ваяет новые данные, не подозревая, что они при следующей перезагрузке останутся на старом сервере..., и, перезагрузившись наутро, (и переключившись уже на новые пути), не обнаруживает результатов вчерашней работы... :(

    Как избежать первой - холостой - загрузки? Иными словами - как при загрузке/логине пользователя сделать принудительную проверку текущей применяемой политики - такой однократный "gpupdate /force /boot"?

    10 февраля 2016 г. 12:03
  • Конечно, можно на рабочий стол перенесённого юзера на "старом" пути в качестве заключительного аккорда положить файлик dummy.dum, а в автозагрузку (в ГП со старыми путями) воткнуть батник с gpupdate /force /boot c проверкой наличия этого самого файлика. Тогда при запуске сессии со старым путём он (батник) отработает и перезапустит юзерскую сессию, которая после рестарта начнёт подчиняться уже новой политике - без этой проверки... Да и на новом пути этого файлика не будет.

    Немного громоздко... Any ideas?

    10 февраля 2016 г. 12:21
  • Как уже рекомендовали выше для таких вещей лучше использовать DFS.

    То есть в качестве пути к перенаправленным папкам использовать DFS путь.

    В текущей ситуации один из вариантов - настроить репликацию DFS между старым и новым расположением.

    Второй вариант - отключить "оптимизацию быстрого входа групповой политики"

    Конфигурация компьютера\Административные шаблоны\Система\Вход в систему\Всегда  ожидать инициализации сети при загрузке и входе в систему

    https://msdn.microsoft.com/ru-ru/library/cc780527%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396


    Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку "Предложить как ответ" или "Пометить как ответ".

    http://zalozny.com.ua

    10 февраля 2016 г. 13:01