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

Три ожидания с тремя разными владельцами

Именно перемещаемый профиль заставляет параметры пользователя следовать за человеком между участвующими компьютерами, и загрузка происходит в начале сеанса. Ветвь реестра пользователя и папки профиля копируются или объединяются при входе, а затем записываются обратно при выходе. Эта работа синхронна, поэтому медленное плечо до общего ресурса профилей ощущается как медленный рабочий стол, а не как медленное копирование файлов.

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

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

Измерьте, что именно ждет

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

Эти два факта сужают проблему быстрее любого аудита политик, и для их сбора не нужно менять конфигурацию. Запустите их на пострадавшем ноутбуке, а не на сервере, который стоит рядом с публикацией.

Get-CimInstance Win32_UserProfile | Select-Object LocalPath, Loaded, SID
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*' | Select-Object ProfileImagePath
Measure-Command { Get-ChildItem '\\fs01.corp.internal\profiles\a.singh' | Out-Null }

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

Подключение появляется после начала ожидания

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

Исправить это значит сдвинуть подключение раньше, а не настраивать профиль. Туннель компьютера или подключение до входа с проверкой подлинности компьютера устанавливает путь до того, как пользователь войдет, и требует собственного жизненного цикла сертификата и собственных правил брандмауэра. Кэшированные учетные данные — вторая половина замысла, и они работают только для учетных записей, которые входили раньше.

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

Держите документы вне профиля

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

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

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

Проверьте все четыре сценария, прежде чем считать это исправленным

Быстрый вход в офисе доказывает очень мало. Замысел должен выдержать доступ из офиса, работу из дома через туннель, работу без подключения и возвращение в офис, потому что именно в четвертом случае появляются конфликты синхронизации. Измерьте те же четыре на одной контролируемой учетной записи и с настоящими приложениями, и запишите цифры.

Соберите журнал службы профилей и полученный набор политик из пострадавшего сеанса, а не со своей административной рабочей станции.

Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 30
gpresult /r /scope:user
Measure-Command { Get-ChildItem '\\fs01.corp.internal\users\a.singh\Documents' | Out-Null }

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

Похожие статьи