В последнее время мне пришлось работать над несколькими проектами, целью которых было усовершенствование управления данными и настройками пользователей. Неэффективное или неправильное управление данными и настройками может плохо отразиться на качестве услуг, предоставляемых ИТ-подразделением. Но благодаря удачной организации можно сократить затраты, повысить безопасность, обеспечить мобильность, увеличить производительность и добиться непрерывности деятельности компании.
В Windows есть почти все необходимые для успеха компоненты: перенаправляемые папки, перемещаемые профили, квоты, фильтры файлов, пространства имен DFS, шифрование и автономные файлы. Их нужно дополнить лишь правильно подобранными специалистами, процессами и вспомогательными сценариями. Удачно соединяя все эти элементы, можно создать структуру для эффективного управления данными и настройками. Но сделать это непросто — слишком много переменных. Обширная документация о профилях и перенаправленных папках содержит очень мало сведений о взаимозависимостях между этими технологиями и различными типами данных, которыми приходится управлять на предприятии.
В этой статье, состоящей из двух частей, даны некоторые рекомендации, которые помогут сформировать инфраструктуру для управления данными и настройками. Кроме того, я покажу, как объединить управление данными и настройками для пользователей Windows Vista и Windows XP. Прежде чем приступить к чтению статьи, полезно познакомиться с базовыми сведениями, приведенными в главе 3 документации набора административных ресурсов Windows. В набор ресурсов входят также превосходные инструменты и сценарии, которые могут пригодиться при проектировании инфраструктуры управления данными и настройками. Книга входит в набор ресурсов Windows Server 2008, но ее материал применим и к Windows Server 2003, и к клиентам Vista и XP.
В первой статье речь пойдет о серверах. В частности, я расскажу о физическом пространстве имен (то есть папках и разрешениях), пространстве имен SMB (общих ресурсах) и пространстве имен DFS, самом эффективном серверном компоненте для управления данными и настройками. Во второй статье будут рассмотрены клиентские компоненты.
Уточняем требования предприятия
Для начала проясним некоторые определения. Термин «данные пользователя» относятся к файлам, созданным и необходимым для отдельного пользователя. Это объекты в папке Documents пользователя (My Documents в XP) или на рабочем столе. Термин «настройки» относится ко всему, от пользовательской конфигурации Microsoft Outlook, специального словаря, ярлыков для быстрого запуска программ, шаблонов и обоев рабочего стола до списка «Избранное» браузера Microsoft Internet Explorer (IE). Windows располагает несколькими хранилищами для данных и настроек, в том числе My Documents, Desktop, Favorites, AppData и файл реестра ntuser.dat. Эти хранилища данных могут физически находиться на локальном компьютере, сетевом сервере или и там и там. Данные пользователей ноутбуков хранятся как в сети, так и локально, а для синхронизации двух наборов данных используются такие технологии, как автономные файлы и перемещаемые профили.
Прежде чем приступить к проектированию инфраструктуры управления данными и настройками, следует определить бизнес-требования, которые составляют основание для такого проекта. Их можно разделить на следующие категории:
-
безопасность — необходимо обеспечить защиту данных, созданных пользователем;
-
мобильность — пользователи должны иметь доступ к своим данным и настройкам не только с настольного компьютера или персонального ноутбука, но и из зала для конференций, и с других компьютеров;
-
готовность — когда пользователь получает новый или резервный компьютер, его данные и настройки должны быть доступны при первом включении компьютера;
-
устойчивость к отказам — деловые данные не должны быть потеряны в случае отказа или кражи жесткого диска.
Обзор рекомендаций по проектированию инфраструктуры
Определив стратегические требования, можно приступить к проектированию инфраструктуры для данных и настроек. Ниже дан краткий обзор компонентов, составляющих инфраструктуру.
Перенаправление папок. Перенаправление папок гарантирует, что важнейшие хранилища данных пользователя находятся на серверах файлов. Пользователи на клиентах Windows по-прежнему обращаются к данным в папке Documents, на рабочем столе, в папке Favorites и в мультимедиа-папках, таких как Music, Pictures и Videos. Благодаря функциональности перенаправленных папок пользователи не замечают, что физические хранилища данных для этих папок размещены в сети.
Автономные файлы. С помощью автономных файлов пользователи ноутбуков смогут обращаться к данным, когда связь с сетью отсутствует. Кэш автономных файлов будет зашифрован, чтобы сократить риск утечки данных в случае потери или кражи ноутбука.
Перемещаемые профили. Перемещаемые профили обеспечивают выполнение требований к мобильности, готовности и устойчивости к отказам для пользовательских разделов реестра — файла ntuser.dat в корне профиля. В перемещаемый профиль также входит папка AppData. Как подробно объясняется во второй части статьи, существует техническая возможность перенаправления AppData, но в большинстве случаев перенаправление будет наиболее перспективным решением, а до тех пор AppData управляется как часть перемещаемого профиля. Вероятно, файл реестра и папка AppData будут единственными элементами, для управления которыми используются перемещаемые профили.
Пространства имен DFS. Благодаря пространствам имен DFS работа не будет зависеть от физического местонахождения пользовательских хранилищ данных, что позволит управлять данными с минимальными затратами.
Неуправляемые данные. Классы данных, которые не следует хранить на сетевых серверах (например, музыкальные коллекции пользователей), будут исключены как из перенаправленных папок, так и из перемещаемых профилей. Они остаются на локальном жестком диске пользователя.
Квоты и фильтры файлов. При желании можно применить квоты и фильтры файлов для хранилищ данных для управления качеством и типами сохраненных данных.
Создание физического пространства имен папок для хранилищ данных и настроек
Чтобы выполнить требования безопасности, мобильности, готовности и устойчивости к отказам, перенаправленные папки и перемещаемые профили должны быть куда-то направлены. В конечном итоге данные оказываются на сетевом сервере. Структура папок этого сервера должна обеспечивать управляемость данных и настроек. Для каждого пользователя на сервере рекомендуется структура папок, показанная на экране 1. Некоторые особенности структуры могут показаться неожиданными.
Обратите внимание, что пространство имен в структуре — не плоское. Все типовые хранилища данных пользователя (в том числе рабочий стол и папка Documents) содержатся в родительской папке с именем Data. Папка Data используется, когда для хранилища данных пользователя вводятся квоты. Квота пользователя должна быть универсальной: она должна применяться к данным, хранящимся в папке Documents, на рабочем столе и в мультимедиа-папках. Чтобы эффективно применять квоты к хранилищам пользовательских данных, хранилища должны располагаться под одной родительской папкой. Однако нельзя налагать квоты на папку верхнего уровня пользователя (например, jfine), так как существуют другие хранилища — папки Backups и Profiles, на которые не должна распространяться квота.
Папка Data обеспечивает область управления — контейнер, который представляет все хранилища пользовательских данных. С помощью этой папки можно применить квоту для пользовательских данных, а можно задать область действия фильтров файлов, которые запрещают запись в сетевые хранилища данных определенных типов. Концепция квот и фильтров файлов знакома; их легко реализовать и управлять ими в Windows Server 2008 и Windows Server 2003 R2. Подробности приведены в справочной документации по диспетчеру ресурсов сервера файлов (FSRM).
На экране 1 также показаны две папки профилей: Profile и Profile.V2. В Vista расширение .V2 автоматически добавляется к папке, в которой находится перемещаемый профиль пользователя. Поэтому, если путь профиля пользователя имеет вид amespace\%username%profile, то перемещаемый профиль для пользователя находится в папке Profile, если пользователь регистрируется в системе XP, и в папке Profile.V2, если он регистрируется в компьютере Vista. Из-за существенных различий в реестре и структуре AppData два хранилища настроек для пользователей Vista и XP невозможно объединить. Это еще одно основание для того, чтобы перемещаемые профили управляли только двумя этими хранилищами.
Папки профиля представляют собой папки первого уровня, не подлежащие квоте, примененной к папке Data. Профили не подлежат квотированию, потому что, если система сталкивается с квотой в ходе синхронизации, профиль может быть испорчен. Во второй части статьи будет показано, что в инфраструктуре данных и настроек профили будут содержать только AppData и файл реестра ntuser.dat. Это позволяет не допустить разрастания профиля и улучшить синхронизацию. Профили попросту не будут вырастать до слишком больших размеров, поэтому предпочтительно иметь профили без квот.
Папка Backups служит для устранения проблем управления бизнес-данными, не решаемых с помощью перенаправленных папок и перемещаемых профилей Windows. Кроме того, в папке можно архивировать данные для определенного пользователя (например, старые файлы .pst), которые не требуются в повседневной работе, и потому необязательно обеспечивать автономный доступ к ним для владельцев ноутбуков. Для отбора и записи данных в папку Backups используются иные механизмы, нежели перенаправленные папки и перемещаемые профили. Backups — не вложенная папка папки Data, поэтому ей можно назначить квоту отдельно от квоты, применяемой к обычным повседневно используемым хранилищам.
Над этими папками расположена единая родительская папка пользователя, а над папками пользователей — единый родитель для всех пользователей на сервере. На экране 1 имя папки верхнего уровня — Users. Конечно, все эти папки необходимо защитить в соответствии с принятой в компании политикой информационной безопасности. Папке Users назначается разрешение System::Allow::Full Control, наряду с разрешениями, обеспечивающими административный и вспомогательный доступ к хранилищам пользовательских данных. Например, группе аудита безопасности можно назначить разрешение чтения в хранилищах данных пользователей, а разрешение справочной службы можно дать только для папок пользователей верхнего уровня, но не вложенных папок. В комплекте ресурсов приведены более подробные сведения, наряду с инструментами, которые помогут защитить структуры папок данных пользователя на сервере.
Дополнительный эффект правильной организации — отсутствие необходимости предоставлять любые разрешения обычным пользователям в корневой папке Users. Если каждый пользователь имеет разрешение Full Control в индивидуальной папке \%username%, то необязательно иметь разрешения на уровне папки Users. Предоставляемое пользователю по умолчанию право переходить между папками позволит пользователям «перепрыгивать» (без доступа) через папку Users прямо к собственной папке. Поэтому пользователи не могут просматривать содержимое и даже видеть папки других пользователей. Это метод защиты с минимальными правами.
Одна особенность: каждому пользователю необходимо сопоставить дерево папок перед применением перенаправленных папок и перемещаемых профилей. То есть требуется заранее подготовить структуру папок, показанную на экране 1. И вновь автоматизировать подготовку хранилищ данных пользователей поможет набор ресурсов; в нем есть даже несколько примеров сценариев подготовки папок. Сценарии также можно получить по адресу www.intelliem.com/resourcekit .
Создание пространства имен SMB общих папок для хранилищ данных и настроек
Пространство имен SMB — термин для обозначения стандартных путей Universal Naming Convention (UNC) на основе сервера к хранилищам данных и настроек. Всем наверняка знакомы такие пути, как servernameusers$\%username%. Подобные пути UNC указывают папку через пространство имен SMB.
В правильно организованном пространстве имен SMB для инфраструктуры данных и настроек необходимо дважды сделать общей папку верхнего уровня, Users. В первую очередь, она будет использоваться в путях к хранилищам данных пользователей. В большинстве организаций папке верхнего уровня назначается скрытое общее имя, такое как Users$. Например, SMB-пути к папкам документов пользователей имеют вид serverusers$\%username%datadocuments.
В общем ресурсе Users$ необходимо назначить разрешение полного доступа группе пользователей, которые имеют хранилища данных на сервере. Фактический доступ определяют разрешения NTFS в корневой папке Users и корневой папке каждого пользователя. Помните, что у пользователей нет разрешений NTFS в папке Users, поэтому разрешение Everyone::Allow::Full Control подходит для общего ресурса Users$.
Вторично папка Users должна быть сделана общей для путей, указывающих перемещаемый профиль пользователя. Я рекомендую такое имя, как Profiles$. И вновь необходимо назначить разрешение Full Control группе пользователей на сервере или группе Everyone. Папку Users нужно сделать общей вторично, потому что требуется отключить кэширование SMB-путей для профилей пользователей. Причина связана с потенциальным конфликтом между автономными файлами Windows и перемещаемыми профилями. Кэширование включено по умолчанию и должно быть оставлено включенным для общего ресурса Users$, чтобы обеспечить работу пользователей ноутбуков в структуре данных и настроек. Но требуется отключить кэширование в общем ресурсе Profiles$ (экран 2). Пользователи, в том числе владельцы ноутбуков, по-прежнему будут получать синхронизированную копию своих профилей с помощью процедуры синхронизации профилей (этот механизм отделен от автономных файлов Windows).
Использование пространства имен DFS для абстрагирования и представления хранилищ данных каждого пользователя
Последний и чрезвычайно важный компонент инфраструктуры — пространство имен DFS. Каждый, кому приходилось перемещать пользовательские данные из одного сервера на другой, знает, что при этом приходится вносить много изменений. Требуется изменить путь перемещаемого профиля пользователя и объект GPO, а также настройки перенаправления папки реестра. Это достаточно просто, но вспомним о ссылках внутри и между документами, например в рабочих листах Microsoft Excel со связанными формулами, указывающими на server01users$dholmeDocuments Financeexcelfile.xls, которые необходимо изменить на server02users$dholmeDocuments Financeexcelfile.xls. Такая «миграция пути» требует много работы, и большинству организаций трудно выполнить полную миграцию путей пользователей данных, особенно для ссылок между документами. Поэтому они не занимаются миграцией и теряют в производительности.
Пространство имен DFS, как и другие компоненты, рассмотренные в данной статье, требуют продуманного подхода, но предпочтительная структура показана на экране 3. Здесь представлено пространство имен DFS, которое можно назвать полностью перечислимым. В нем показано каждое хранилище данных и настроек. Пользователю назначается папка первого уровня внутри пространства имен DFS домена (например, contoso.comUsers). Ниже этой папки находится единственный уровень вложенных папок — по одному для каждого хранилища данных и настроек. Поэтому пути для перемещаемых профилей и перенаправляемых папок просты:
amespace usersusernamefoldername (например, contoso.comusersdholmedesktop и contoso.comusersdholmeprofile). Пространство имен скрывает то обстоятельство, что несколько хранилищ данных, в сущности, являются вложенными папками родительской папки Data на сервере. Поэтому папка Data на сервере может управляться квотами на физическое пространство на сервере, не увеличивая сложность пространства имен, используемого для администрирования данных и настроек.
Каждая папка в пространстве имен DFS пользователя указывает на соответствующую папку на сервере. Папки данных используют в качестве целевого путь servernameUsers$ usernameDatafoldername, через общий ресурс Users$, который допускает кэширование. В папках профиля используются целевые пути servernameProfiles$ usernameProfile и Profile.V2, через общий ресурс Profiles$, который отключает автономные файлы, так как в перемещаемых профилях существует отдельный механизм синхронизации.
Полностью перечисляемое пространство имен DFS — оптимальный вариант
На первый взгляд применение отдельных папок пространства имен DFS для каждого хранилища данных пользователя явно избыточно. Многие организации располагают более простым пространством имен DFS, таким как показано на экране 4. Такое пространство имен DFS может быть подходящим решением для небольшой компании. Пути к хранилищам данных пользователей имеют вид domainusers data\%username%datafoldername (например, contoso.comusersdatajfine datadocuments). Двойное присутствие data — не опечатка. Первая папка data находится в пространстве имен DFS, которое указывает на общий ресурс Users$ в пространстве имен SMB сервера. Папка %username% и вторая папка data находятся в физическом пространстве имен сервера, внутри общего ресурса Users$.
Даже в небольшой организации возникает крупная проблема: это пространство имен лишено гибкости. Пространство имен DFS (например, contoso.comusersdata) указывает на фиксированное пространство имен SMB (например, server01 users$). Если хранилища данных некоторых пользователей перемещены в другое пространство имен SMB (например, server02 users$), то потребителю придется перестраивать пространство имен DFS. К сожалению, придется выполнить трудоемкую «миграцию путей» перемещаемых профилей, перенаправляемых папок и всех ссылок между документами. Кроме того, любым пользователям ноутбуков придется манипулировать кэшем автономных файлов, чтобы избежать полной ресинхронизации.
Можно рассмотреть возможность использования пространства имен, показанного на экране 3, до уровня пользователя и избежать вложенных папок для отдельных хранилищ данных. Временно можно обойтись данной конфигурацией, но при этом закладывается жесткая зависимость от физического пространства имен — Desktop, Documents и мультимедиа-файлы находятся в папке Data. Если в будущем потребуется изменить структуру на сервере, то возникнут затруднения. Надеюсь, когда-нибудь появится возможность перенаправлять хранилище Documents в My Site на SharePoint. В настоящее время это «журавль в небе», но благодаря абстрагированию местонахождения Documents в будущем миграция отдельных хранилищ данных на другие серверы и даже другие технологии станет более удобной. С помощью упомянутых выше сценариев достаточно просто обеспечить пространство имен DFS для пользователя, так почему не построить наиболее гибкое и ориентированное на будущее пространство имен для управления?
В силу этих факторов, наряду с проблемами взаимодействия с другими компонентами инфраструктуры данных и настроек, полностью перечисляемое пространство имен DFS будет оптимальным вариантом. В данной статье недостаточно места, чтобы рассмотреть подробности, поэтому обращайтесь к набору ресурсов, в котором рассмотрены достоинства и недостатки других структур пространства имен DFS.
Дэн Холм (danh@intelliem.com ) — директор консалтинговой службы Intelliem, которая организовывает консультации для предприятий, внедряющих SharePoint, Office, Windows и Active Directory