Создание рабочей среды - для пользователей служб удаленных рабочих столов
терминальный доступ
Станислав Шпак, Thursday 30 August 2012 - 00:00:00

[newpage= Типы профилей]

Создание рабочей среды - для пользователей служб удаленных рабочих столов

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

Иногда для обеспечении отказоустойчивой работы служб удаленного рабочего стола (Remote Desktop Services, RDS) желательно объединить нескольких серверов в ферму (кластер).
Если не предпринимать никаких дополнительных мер, то пользователь, осуществляя вход в систему, будет иметь на каждом члене фермы свой уникальный локальный профиль. Под термином «профиль» подразумевается набор настроек ОС и созданных пользователем файлов, которые располагаются в его личном хранилище.
Настройки обычно хранятся в реестре в ветке HKEY_CURRENT_USER (HCU), а файлы - в подпап-ках, расположенных по пути, на который указывает системная переменная %USERPROFILE% (по умолчанию для Windows Vista/7/2008 это %SYSTEMDRIVE%\USERS\ %USERNAME%.%USERDOMAIN%).

Собственно говоря, настройки реестра также представляют собой файл NTUSER.DAT, который хранится в вышеназванной папке и подгружается в реестр при его входе в систему, причем каждый пользователь имеет свой собственный раздел HCU.
В статье используются терминология и названия политик, принятые в Windows Server 2008 R2. Большинство из них существуют и в Windows Server 2008, но немного с другими названиями по причине того, что службы терминалов (Terminal Services) были переименованы в Windows Server 2008 R2 в службы удаленных рабочих столов. В случае исключений будет сделана отдельная оговорка.

Типы профилей

Профили пользователя бывают трех видов:




Настройка перемещаемого профиля групповой политикой

Локальные профили

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

Перемещаемые профили
Хранятся обычно в общей сетевой папке и копируются на нужный сервер при входе пользователя в систему, как бы «следуя» за ним. По завершении сеанса работы изменения копируются обратно в сетевое расположение.
Существует два варианта включения перемещаемого профиля: один служит только для входа через RDS, второй -для любого входа в систему.
Настраиваются они либо через групповую политику (приоритетнее), либо в свойствах учетной записи пользователя. Нас сейчас интересует использование перемещаемого профиля для входа через службы RDS.
Соответствующая настройка групповой политики (см. рис.) называется Set path for Remote Desktop Services Roaming User Profile (Задать путь для перемещаемого профиля пользователя служб удаленных рабочих столов) и находится в разделе Computer Configuration (Конфигурация компьютера) -> Policies (Политики) -> Administrative Templates (Административные шаблоны) -> Windows Components (Компоненты Windows) -> Remote Desktop Services (Службы удаленных рабочих столов) -> Remote Desktop Session Host (Узел сеансов удаленных рабочих столов) -> Profiles (Профили).Аналогичная настройка в свойствах объекта «пользователь» находится во вкладке Remote Desktop Services Profile (Профиль служб удаленных рабочих столов). Для включения перемещаемых профилей нужно указать сетевую папку, которая будет использоваться в качестве «корневой» для всех пользователей.
Будьте внимательны: в данном случае не нужно указывать переменную %USERNAME% (тогда как это рекомендуется при включении перемещаемых профилей на уровне всего сервера) - система сама создаст папку с именем %USERNAME%.%USERDOMAIN%.V2.
Обратите внимание на «V2» в конце пути. Оно создается автоматически системами Windows Server 2008 и выше, так как профили пользователя начиная с Windows Vista несовместимы с более ранними версиями. При использовании одной и той же папки в качестве хранилища профилей для Windows Server 2003 и 2008 суффикс «V2» позволит их не смешивать. Если при создании перемещаемого профиля сетевое расположение недоступно, система выдаст ошибку и создаст локальный (при первом входе пользователя на сервер) либо будет использовать котированный профиль (если таковой имеется).
Использование перемещаемых профилей решает проблему синхронизации пользовательского окружения на разных серверах. Их удобно использовать в унифицированных средах, когда все рабочие станции или серверы настроены одинаковым образом. Именно потому это решения редко встречается на локальных компьютерах пользователей, но рекомендуется на серверах RDS. Недостатком является то, что при увеличении объема данных замедляются вход пользователя в систему и загрузка сетевого интерфейса сервера. Кроме того, если не удалять котированные профили, то есть риск столкнуться с исчерпанием свободного места на диске.

Создание единого обязательного профиля




Рисунок 2. Управление профилями сервера


Обязательные профили
Это преднастроенное пользовательское окружение, которое может быть изменено в процессе работы, но эти изменения не будут сохранены.
Такой профиль удобно размещать в сетевом хранилище (индивидуальный для каждого сотрудника или один для всех), он станет копироваться при входе пользователя на сервер, но любые изменения будут потеряны при выходе из системы.
Создать его проще всего из уже имеющегося локального или перемещаемого профиля. Для отого нужно переименовать файл NTUSER.DAT в NTUSER.MAN, после чего существующий профиль станет обязательным.
Обратите внимание, что в случае перемещаемого профиля котированный локальный профиль будет не обязательным, а обычным, но реплицироваться в сетевое хранилище не будет.
Однако, если речь идет о сотнях пользователей, подобный метод не очень эффективен. Использование обязательного профиля обеспечивает его минимальный и постоянный размер, отсутствие необходимости в синхронизации, но это не всегда удобно по ряду причин.
Первая из них, как ни странно, в том, что он неизменяемый. Кроме того, существуют программы, которые требуют хранения и изменения пользовательских настроек.
Плюс еще есть возможность сохранять файлы локально (в «Мои документы» или на «Рабочий стол»), которые будут потеряны при выходе.
Как видите, несмотря на существование различных типов профиля, ни один из них не является подходящим для использования вместе с кластером серверов RDS.

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

[newpage= Управление профилями]

Управление профилями
Одна из основных проблем - увеличение объема пользовательских данных в профиле, заполнение ими локального диска и, как следствие, невозможность дальнейшей полноценной работы.
Самое простое и неэффективное, что можно сделать, -это удалить их вручную. Но не надо забывать, что начиная с Windows Vista удалять пользовательские профили через проводник (или файловый менеджер) нельзя, так как впоследствии такой пользователь не сможет корректно войти в систему.
Для ручного удаления нужно вызвать из Панели управления апплет System, нажать Advanced system settings и далее кнопку Settings в разделе User Profiles. Прежде чем появится
список существующих профилей, придется подождать некоторое время - в зависимости от их количества и объема (см. рис. 2). Остается выбрать нужный (а точнее, ненужный) и нажать кнопку Delete (Удалить).
При необходимости проводить удаление через скрипт можно воспользоваться утилитой Delprof.exe . Если же папка с профилем удалена через проводник, то в вышеупомянутом списке он уже не появится. Чтобы в этом случае обеспечить возможность корректного входа в систему, откройте редактор реестра, перейдите в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\ProfileList. Здесь представлены своими SID все пользователи, имеющие профиль на данном сервере. Найдите SID нужного пользователя (через поиск или просматривая каждый раздел) и удалите его полностью.
Конечно же, лучше не допускать ситуации, когда диск заполнится пользовательскими данными и придется удалять их вручную. Для этого существует несколько настроек, доступных через групповые политики.
Во-первых, можно установить квоту на размер профиля. Соответствующая политика настраивается в разделе User Configuration (Конфигурация пользователя) -> Policies (Политики) ->• Administrative Templates (Административные шаблоны) -> System (Система) -> User Profiles (Профили пользователей) и называется Limit Profile Size (Ограничить размер профиля).
Здесь задаются пороговое значение (в Windows 2003 максимально допустимое значение для размера профиля в этой политике равнялось 30 000 байт, в Windows 2008 это ограничение было снято), сообщение для пользователя и частота его появления (см. рис. За).
При этом в системной области панели задач появляется значок, который информирует пользователя о доступном ему свободном месте (см. рис. Зb).
В версиях Windows ниже Vista пользователю не разрешалось выходить из системы, пока объем данных не станет ниже установленного уровня. Теперь же это допустимо, однако в случае перемещаемого профиля изменения не будут скопированы в сетевое хранилище и потеряются при выходе.
Во-вторых, можно удалять кэшированные локальные профили. Соответствующие две политики находятся в разделе Computer Configuration (Конфигурация компьютера) -> Policies (Политики) -> Administrative Templates (Административные шаблоны) ->» System (Система) -> User Profiles (Профили пользователей).
Первая называется Delete Cached Copies Of Roaming Profiles (Удалять кэшированные копии перемещаемых профилей) и используется для удаления кэшированного перемещаемого профиля при выходе пользователя из системы. Однако это не всегда полезно, так как он обеспечивает работу пользователя в случае проблем с загрузкой перемещаемого профиля.
Поотому можно воспользоваться менее агрессивной политикой Delete User Profiles Older Than A Specified Number Of Days On System Restart (Удалять при перезагрузке системы профили пользователей по истечении указанного числа дней). Благодаря ей профили пользователей, которые старше указанного времени, будут удалены, но только при перезагрузке системы.


Рисунок 3.а. Включение ограничения размера профиля через групповую политику




Рисунок 3.b. Уведомление для пользователя


Обеспечивать необходимую частоту перезагрузки сервера RDS придется системному администратору. Казалось бы, почему бы серверу самостоятельно не проверять наличие устаревших профилей и не удалять их без перезагрузки?
Похоже, в Microsoft тоже об этом подумали, и в Windows Server 2008 R2 появилась новая политика Limit the size of the entire roaming user profile cache (Ограничить размер кэша всех перемещаемых профилей пользователей). Она расположена в разделе Computer Configuration (Конфигурация компьютера) ->Policies (Политики) -> Administrative Templates (Административные шаблоны) -> Windows Components (Компоненты Windows) -> Remote Desktop Services (Службы удаленных рабочих столов) -> Remote Desktop Session Host (Узел сеансов удаленных рабочих столов) -> Profiles (Профили) и позволяет задать общее ограничение объема всех пользовательских профилей, а также интервал проверки. Система будет самостоятельно проверять с указанным интервалом, сколько места ими занято, и в случае превышения установленного критического уровня удалять наиболее старые.
Когда используется перемещаемый профиль, рекомендую включить политику Add the Administrators security group to roaming user profile (Добавляет группу безопасности Администраторы к перемещаемым профилям пользователя), которая находится в разделе User Profiles.
По умолчанию при создании перемещаемого профиля на него автоматически устанавливаются настройки безопасности таким образом, что только владелец может иметь к нему доступ.
Данная политика позволяет добавить группу Администраторы к списку контроля доступа, что может быть полезно для целей администрирования.

[newpage= Перенаправление папок (Folder Redirection)]

Перенаправление папок (Folder Redirection)
Это очень хороший способ уменьшить размер профиля и обеспечить возможность пользователю сохранять файлы в привычных для него местах, даже при использовании обязательных профилей.
Включив эту опцию, вы обеспечиваете прозрачный для пользователя перенос их в сетевое расположение, внешнее по отношению к профилю. Пользователь видит перед собой рабочий стол с ярлыками и файлами, которые на самом деле расположены на файловом сервере, сравнению с предыдущими версиями Windows Server 2008 может обеспечивать перенаправление большего числа папок профиля, чем раньше.
На рис. 4 открыт раздел групповой политики, в котором видно, какие папки доступны для этого. Для активирования этой возможности нужно нажать правой кнопкой мыши по соответствующему названию и выбрать Properties (Свойства). При этом предлагаются следующие варианты: No configured, Basic и Advanced (см. рис. 4). Первая отключает перенаправление этой папки, вторая позволяет перенаправлять папку в одно и то же расположение для всех пользователей, а третья - управлять перенаправлением на уровне членства в группах.
Данная тема сама по себе достойна отдельной статьи, поэтому, если не доводилось сталкиваться с этим ранее, советую обратиться к встроенной справочной системе Windows.
Тут же скажу немного лишь о вкладке Settings (Параметры) в окне свойств на рис. 4. По умолчанию здесь включена опция Grant the user exclusive rights to... (Предоставить права монопольного доступа к...) и выключена Also apply redirection policy to Windows 2000/XP/2003 operating systems (Применить политику перенаправления также к операционным системам Windows 2000/ХР/2003). Последний вариант заблокирован для папок, не существующих в версиях до Windows Vista.
Отключение первой опции позволит системе не проверять владельца папки, что, с одной стороны, ослабляет безопасность, а с другой, позволяет настроить доступ для администраторов.
Включение второй обязательно, если планируется распространять политику на серверы и компьютеры ранних версий Windows.
Также на этой вкладке настраивается поведение при отмене политики: должны ли перемещенные данные остаться на старом месте или быть перенесены обратно в исходное положение.
Иногда эта настройка не срабатывает и данные не «возвращаются». В этом случае может помочь опция Redirect to the local user profile location (Перенаправлять в расположение, определяемое локальным профилем), доступная в варианте Basic на вкладке Target (Конечная папка).
Включение перенаправления папок позволяет не только уменьшить размер перемещаемого профиля на серверах RDS. Если ату же политику применить и к рабочим станциям пользователей, то можно обеспечить им доступ к своим файлам в привычном расположении независимо от того, работает ли человек удаленно или локально.
Однако, хотя большинство программ успешно справляются с такими папками, с некоторыми могут возникнуть сложности, особенно при обращении к ним из скриптов.
Например, можно адресоваться к рабочему столу пользователя с помощью пути %USERPROFILE%\Desktop. Но, если перенаправление папки рабочего стола включено, его там уже не окажется.
Кроме того, перенос части профиля в сетевое расположение предъявляет повышенные требования к стабильности сети и хранилища.

Рисунок 4. Включение перенаправления папок через гркпповую политику


[newpage= Режим обработки замыкания групповой политики (Loopback Policy Processing)]

Режим обработки замыкания групповой политики (Loopback Policy Processing)
Если управлять пользовательскими профилями через групповые политики, то можно заметить, что некоторые настройки, например, перенаправление папок, располагаются в разделе User configuration (Конфигурация пользователя) политики.
А это значит, что если пользовательская учетная запись находится в организационном подразделении (Organization Unit, OU), на которое распространяется действие такой политики, то применяться эти настройки будут при входе пользователя в систему независимо от того, локальный это компьютер или сервер RDS. Такое поведение может быть нежелательным, вполне разумно иметь одни пользовательские настройки для сервера, другие - для локального компьютера.
Но если поместить политику с настроенными разделами User Configuration в раздел OU с серверами, то она не будет обрабатываться, так как учетные записи пользователей не находятся в этом OU.
Чтобы это произошло, существует специальная политика Loopback Policy Processing (Режим обработки замыкания пользовательской групповой политики), располагающаяся в разделе Computer Configuration (Конфигурация компьютера) -» Policies (Политики) -> Administrative Templates (Административные шаблоны) -> System (Система) -> Group Policy (Групповая политика).
У нее два режима работы - Replace (Замена) и Merge (Слияние). В первом случае происходит замещение пользовательских политик из OU пользователя, во втором - объединение с ними.

Например, на рис. 5 изображен домен с двумя организационными подразделениями - OU1 и OU2.
В первом находятся объекты учетных записей пользователей и их локальные компьютеры, во втором - объекты серверов RDS.
Если пользователь осуществляет вход в систему на локальном компьютере, то он оказывается под действием доменной групповой политики (Default domain policy), затем политики GP1 локального компьютера (которая была применена при его включении) и политики GP2 пользователя (примененной при входе в систему).
Если пользователь осуществляет вход на сервер RDS, то будут действовать доменная политика, политика сервера GP3 и политика пользователя GP2.
Если же включить Loopback Policy Processing, то при входе на сервер RDS будут действовать доменная политика, политика сервера GP3 и политика пользователя GP2+GP4 (в режиме Merge) или только GP4 (в режиме Replace).
При возникновении любых конфликтов настроек между политиками OU пользователя и OU сервера в режиме Merge политика в OU сервера будет иметь более высокий приоритет.


Рисунок 5. Образец структуры OU в домене

***



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

Источник: Системный Администратор 06 / 2012


эта статья с Компьютерные сети и технологии
( http://www.xnets.ru/plugins/content/content.php?content.240 )