Мы запускаем среду ActiveDirectory с Windows 2008 как DC и Samba 3.3 как файловый сервер, используя перемещаемые профили. Некоторые из наших офисов подключены к HQ по медленным каналам (1/2 Мбит). Естественно, это не очень быстро, но этого следовало ожидать.
Я не понимаю, что если пользователь выйдет из системы (для синхронизации потребуется много времени, как и ожидалось), а затем снова войдет в систему на следующий день, также потребуется много времени для входа в систему. И вот чего я не понимаю. Разве синхронизация не должна распознавать, что ничего не изменилось довольно быстро? Также: есть ли достойный документ о том, как реализована синхронизация?
РЕДАКТИРОВАТЬ: Спасибо за помощь. В конце концов, это оказался Sophos Antivirus, сканирующий удаленные профили. Позже был установлен флажок «Отключить сканирование удаленных общих ресурсов при доступе», все происходит быстро. (Так быстро, как 1mbit. Так что для регистрации потребуется всего 5 минут ...)
Насколько я помню, начиная с Windows 2000 клиент перемещаемого профиля сравнивал даты / время файлов в серверной копии профиля с локальной копией, и, если локальная копия была актуальной, он не копировал сервер -сторонний файл обратно клиенту. Найти документацию Microsoft об этом поведении оказалось невозможным. (Опять же, у нас есть одна из тех ситуаций, когда доступ к исходному коду Windows решит эту проблему, но вместо этого мы вынуждены тыкать в нее палками и камнями, как пещерные люди ...)
Мои воспоминания были основаны на истории, которая подтолкнула меня к постоянному использованию перенаправления папок в папке «Рабочий стол». На сайте заказчика пользователь сохранял несколько многогигабайтных чертежей САПР на своем «рабочем столе», а не в соответствующих папках на сервере. Жесткий диск в их ПК отказал, и мой тогдашний работодатель направил техника для замены жесткого диска и повторного образа ПК. Мне позвонили, потому что заменяющее изображение "зависало" в диалоговом окне "Загрузка личных настроек ...". Я заметил, используя «Сетевой монитор» на сервере, что файлы копируются с сервера на клиент. Еще немного обнюхивая, и мы обнаружили более 20 ГБ файлов в папке «Рабочий стол» серверного профиля пользователя, которые копировались клиенту. Техник был нетерпелив и продолжал перезагружать компьютер, в результате чего процесс начинался заново с файлом, который был частично скопирован при предыдущей попытке. Как только мы позволим всему копировать, пользователь сможет входить и выходить из системы без проблем и задержек.
Итак, имея в виду эту историю, я только что сделал небольшой макет виртуальной машины, используя Windows Server 2003 R2 в качестве файлового сервера и Windows XP Professional SP3 в качестве клиента.
Я вошел в виртуальную машину с учетной записью пользователя, у которой уже был перемещаемый профиль пользователя, чтобы профиль мог быть кэширован клиентом, затем я вышел из системы. Это привело к кэшированию перемещаемого профиля пользователя размером 12 МБ для клиента.
Я снова вошел в систему, на этот раз перехватив трафик между клиентом и сервером с помощью Wireshark (работающего на сервере). Я видел около 2500 кадров Ethernet, прошедших во время входа в систему. Менее 1,5 МБ трафика перемещается между клиентом и сервером во время этого входа в систему, хотя, как вы помните, каталог профиля занимает более 12 МБ. Это довольно хороший признак того, что полная копия не выполняется при каждом входе в систему (но мне нужны дополнительные доказательства, как вы увидите).
Поведение, которое я наблюдал при захвате, было рекурсивным обходом папок в профиле, начиная с корневого каталога, с использованием API «Firstfirst». После того, как этот обход был завершен, клиент выполнил пошаговое руководство по профилю, выполняя «открытие», а затем «запрос информации о файле» для каждой папки.
Нигде во время этого входа в систему я не видел, чтобы содержимое файлов в профиле действительно проходило по сети (и, как я уже сказал, весь диалог был менее 1,5 МБ, тогда как данные, составляющие профиль, составляют 12 МБ).
Я закинул в профиль 56-мегабайтный файл и вышел из системы. Я проверил, что файл появился в серверной копии профиля после завершения выхода из системы на клиенте, затем удалил файл из кэшированной копии на жестком диске клиентского компьютера (через общий ресурс "C $").
Я снова вошел в систему на клиенте во время просмотра с помощью Wireshark и заметил передачу 60 МБ между клиентом и сервером во время входа в систему. Я ясно видел на снимке, где клиент запрашивал у сервера содержимое файла размером 56 МБ.
Я вышел из системы и снова вошел в систему, на этот раз оставив локально кэшированный файл размером 56 МБ только на клиенте. При этом входе в систему общий объем передачи между клиентом и сервером снова был чуть меньше 1,5 МБ.
Кажется, это подтверждает мои воспоминания о поведении, по крайней мере, в Windows XP Professional SP3.
Итак, почему вы наблюдаете длительные задержки входа в систему? Помимо того, что они «медленные» (я бы сказал, что они просто «медленные»), ваши каналы WAN, вероятно, довольно скрыты (по сравнению с локальным Ethernet). Рекурсивный обход каталога, который я наблюдал при входе в систему выше, занял около 3 секунд в локальной сети. Это было бы во много раз больше, чем в WAN, даже несмотря на то, что на самом деле очень мало данных передавалось по сети. SMB засасывает скрытые ссылки, как пылесос.
Я подозреваю, что если вы «очистили» профиль пользователя от посторонних файлов в папке «Application Data», «Cookies» и т. Д., Вы увидите уменьшение времени входа в систему и выхода из нее. К сожалению, там часто скапливается мусор, и его трудно контролировать.
Некоторые идеи:
Профили Immidio Flex создает ZIP-файл, содержащий все данные профиля пользователя, и загружает его на серверный компьютер. Он будет работать лучше со скрытыми ссылками, чем встроенный механизм репликации профилей. Раньше этот набор инструментов был бесплатным, но теперь я считаю, что это платный продукт.
Если пользователи не часто перемещаются между офисами за пределами площадки, вы можете разместить «сервер» в каждом удаленном месте, который будет «сервером перемещаемых профилей» для тех пользователей, которые работают в этом офисе, и выполнять резервное копирование удаленно. В этой роли вы можете использовать клиентский компьютер Windows, если более 10 пользователей не пытаются подключиться к нему одновременно (и он не выключается). В качестве альтернативы, поскольку вы уже знакомы с Samba, вы можете поставить низкоуровневую машину Linux с перемещаемыми профилями в каждом офисе и использовать что-то вроде rsync для копирования файлов обратно в расположение концентратора для резервного копирования.
Если вы хотите «утолить» решение, вы можете установить машину Windows Server в каждый офис, реплицировать общий ресурс перемещаемых профилей с помощью DFS-R, и пользователи смогут свободно перемещаться между всеми офисами.
Чтобы получить максимальную отдачу от перемещаемых профилей пользователей, важно прочитать всю документацию и тщательно спланировать внедрение. В этом разделе представлены передовые методы использования перемещаемых профилей пользователей.
Отключите функцию быстрого входа в систему
Благодаря усовершенствованию быстрого входа в систему в Windows XP, когда пользователи переходят с локального профиля на перемещаемый, для регистрации изменений профиля потребуется два входа в систему на каждом компьютере. Это связано с тем, что пользователь всегда входит в систему с кэшированными учетными данными; поэтому требуется один вход в сеть, чтобы заметить, что пользователь перешел в роуминг, и второй вход в систему, чтобы применить эти настройки.
Для обеспечения наилучшего взаимодействия включите параметр «Всегда ждать сети при запуске компьютера и входе в систему», расположенный в разделе «Конфигурация компьютера \ Административные шаблоны \ Система \ Логон».
Перенаправить расположение папки «Мои документы» за пределы перемещаемого профиля пользователя.
Чтобы уменьшить время первоначального входа в систему на новый компьютер, рекомендуется перенаправить расположение папки «Мои документы» за пределы перемещаемого профиля пользователя. Лучший способ сделать это - перенаправление папок. Если у вас не включена Active Directory, вы можете сделать это с помощью сценария входа в систему или попросить пользователя сделать это вручную.
Позвольте системе создать папки профиля для каждого пользователя.
Чтобы обеспечить оптимальную работу перемещаемых профилей пользователей, создайте на сервере только общий ресурс корневого профиля и позвольте системе создавать папки для каждого пользователя. Если вы должны создать папки для пользователей, убедитесь, что у вас установлены правильные разрешения. Подробные сведения о необходимых разрешениях см. В разделе «Вопросы безопасности при настройке перемещаемых профилей пользователей».
Не используйте автономные папки в перемещаемых общих ресурсах профиля.
Убедитесь, что вы отключили автономные папки для общих ресурсов, в которых хранятся перемещаемые профили пользователей. Если вы не отключите автономные папки для профиля пользователя, могут возникнуть проблемы с синхронизацией, поскольку и автономные папки, и перемещаемые профили будут пытаться синхронизировать файлы в профиле пользователя.
Сегодня все могло быть по-другому, но еще в 2001 году я получил очень конкретный совет от парня, страдающего рассеянным склерозом. НЕ использовать перемещаемые профили, основная причина - производительность файловой системы (особенно много небольших файлов). Перенаправление папок, развертывание приложений, блокировка рабочего стола и сохранение остальной части профиля были предпочтительнее.
Я также думаю, что даже кешированная копия должна быть проверена на соответствие мастеру, и это всегда приведет к дополнительной задержке.
Windows XP кэширует профили. При входе в систему Windows XP проверит время последней записи ntuser.dat, если локальная кэшированная копия новее, чем версия в перемещаемом профиле на сервере, она просто запустится с локальной кэшированной копии.
Вот технот в теме. Возможно, вы захотите проверить файл ntuser.dat в каталоге пользователей от одного дня до следующего, чтобы узнать, изменились ли дата / время в файле.