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

В этом году, согласно федеральному закону Российской Федерации от 21 июля 2014 г. N 248-ФЗ, в закон об истечении времени под номером N 107-ФЗ от 3-го июня 2011 года, были внесены некоторые изменения (о самих изменениях немного ниже), в связи с которыми 26 октября 2014 года осуществляется перевод часов и устанавливаются соответствующие часовые зоны и значения времени.

Следовательно, корпорация Microsoft не заставила себя ждать и 23-го сентября этого года выпустила очередной патч, предназначенный для учета текущих изменений в порядке исчисления времени, благодаря которому в операционные системы Windows будут внесены соответствующие правки. Этот патч (под номером KB2998527) можно проинсталлировать практически на все актуальные операционные системы Windows.

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

Начнем мы с

Буквально на прошлой неделе мне в чате социальной сети Facebook задали вопрос, связанный с автоматизаций некоторых языковых параметров при использовании функциональных возможностей групповой политики. Во время той переписки я сразу ответил, что можно реализовать все поставленные задачи, если воспользоваться возможностями предпочтений групповой политики и изменить конкретные параметры системного реестра. А интересовали человека следующие возможности: изменение метода ввода с установленным по умолчанию английским языком, а также изменение переключения раскладки на привычную для многих комбинацию клавиш Ctrl+Shift. Следовательно, далее в этой статье я расскажу, как можно решить подобную задачу. Вы также узнаете еще о некоторых маленьких хитростях, связанных с языковыми параметрами и групповой политикой.

Сейчас для бОльшей части пользователей уже не является секретом то, что любой компьютер состоит не только из «тиливизера» и «процессора», коим называли системный блок, но в нем укомплектовано приличное количество устройств, о которых для полноценного функционирования просто обязана знать операционная система. Более продвинутые пользователи также знают и о том, что, начиная с 90-х годов минувшего столетия, мир впервые узнал о таком ассоциируемом с Windows-системами понятии, как Plug and Play или, проще говоря, о PnP, что представляет собой технологию, позволяющую операционной системе автоматически выполнять некоторые конфигурационные настройки для подключенных устройств. Ну а для появления дополнительных возможностей и корректной работы подключенных устройств, конечно, следует устанавливать драйверы, разработанные производителями комплектующих. В свою очередь, такие драйверы администраторы могут устанавливать на целевые компьютеры различными методами: могут самостоятельно бегать по компьютерам с компакт- или DVD-дисками и инсталлировать такие драйверы; могут разместить их в общедоступной папке на файловых серверах и инсталлировать их при помощи скриптов; интегрировать драйверы в операционные системы при помощи таких средств, как Windows ADK; устанавливать драйверы при помощи Microsoft System Center Configuration Manager, а также многими другими методами. Но, по большому счету, данная статья не об этом.
Иногда могут возникнуть такие ситуации, когда вам попросту нужно будет отключить на том или ином компьютере определённое устройство или, наоборот, заставить пользователей работать с конкретными девайсами. Чтобы выполнить такие операции вместо пользователя, причем не отключая (или, наоборот, принудительно не включая) навсегда такое устройство, вы можете воспользоваться определенным элементом предпочтения групповой политики, о котором далее в этой статье и пойдет речь.

Как вы знаете, системный реестр, а именно изменение существующих или же добавление новых разделов и параметров, позволяет вам делать с операционными системами Windows многое. Вы можете изменять параметры, доступные в панели управления, кастомизировать дополнительные компоненты системы, настраивать свою панель задач и рабочий стол, а также изменять существующие или же добавлять новые пункты в различные контекстные меню. Выходит, что если знать о том, какой именно параметр системного реестра требуется изменить или добавить, можно не только уникальным образом настроить свою систему, а еще и полностью автоматизировать этот процесс, что безо всякого сомнения очень удобно.
Некоторые изменяемые параметры можно достаточно просто локализовать при помощи того же Process Monitor-а или утилиты RegMon (об этих утилитах я уже успел кое-что рассказать в статье «Примеры мониторинга системного реестра»), а с некоторыми параметрами, в свою очередь, придется немного повозиться, так как их локализация может оказаться намного сложнее, чем это кажется на первый взгляд. Со значениями искомых параметров иногда получается все очень просто (например, если это параметр типа DWORD, вы не столкнетесь с какими-либо сложностями при определении значения), а иногда задача, связанная с генерацией собственных значений, может оказаться весьма сложной (например, это может быть значение параметра, отвечающего за расположение каталога, из которого следует брать картинки для экрана блокировки операционной системы Windows 8.1). Примеров как с самими параметрами, так и с их значениями можно приводить бесконечно много.
Сегодня же, в этой небольшой статье, вы узнаете о некоторых параметрах системного реестра, позволяющих добавлять дополнительную пользовательскую информацию в окно свойств системы. Причем, чтобы было интереснее, параметры будут добавляться централизованно, т.е. с использованием функциональных возможностей предпочтений групповой политики. Полагаю, можно приступать, и начинать мы будем с

Как вы знаете, такие расширения клиентской стороны технологии групповой политики, как элементы предпочтения, по сути, позволяют вам выполнять большинство различных сценариев, которые попросту невозможно реализовать при помощи административных шаблонов или же параметров безопасности. Ввиду того, что весь набор предпочтений групповой политики включает в себя 21 расширение клиентской стороны (включая неработающие элементы предпочтений приложений), можно прийти к выводу, что практически все те операции, которые решались средствами сценариев можно реализовать путем таких расширений CSE.
Одно и таких расширений клиентской стороны позволяет вам управлять учетными записями пользователей и групп, которые можно найти на каждой машине еще при установке самой операционной системы. С такими учетными записями приходится сталкиваться не столь часто, но иногда могут возникнуть ситуации, когда вам придется выполнять некоторые операции по их обслуживанию, и знание того, по какому принципу следует выполнять такое обслуживание, будет как никогда кстати.
Вот как раз на таких учетных записях и сценариях по их обслуживанию мы с вами и остановимся в этой статье. Далее вы узнаете о том, какие бывают локальные учетные записи пользователей, кое-что узнаете об учетных записях групп, а также о том, каким образом можно управлять такими объектами при использовании функциональных возможностей групповой политики и элемента предпочтений «Локальные пользователи и группы». А начинать мы сейчас будем с

Такая технология как динамический контроль доступа рассматривается в моих статьях уже достаточно давно, но, если честно, я еще не добрался даже до половины всех тем, которые мне хотелось бы рассмотреть. Но, тем не менее, эта статья позволит вам значительно лучше освоить данную технологию и узнать об очередном кирпичике, который крепится ко всему фундаменту динамического контроля доступа. Образно говоря, к такому кирпичику динамического контроля доступа можно отнести не что иное, как сам централизованный доступ. Центральный доступ, по своему существу, позволяет вам реализовать централизованный механизм соответствующих политик авторизации, благодаря которым вы сможете автоматизировать в своей компании «умное» распределение прав. Ведь если вы должным образом сгенерируете свои утверждения, распланируете и создадите все заточенные под ваш бизнес объекты свойств ресурсов, настроите требуемые списки свойств ресурсов и реализуете красивую и корректную классификацию, но допустите непреднамеренные банальные ошибки при работе с централизованными правилами или политиками доступа, весь ваш труд может полететь в тартарары.
Именно по этой причине крайне важно уделить должное внимание созданию своих уникальных централизованных правил и политик доступа и потратить на это столько времени, сколько будет необходимо для того, чтобы полностью предвидеть все возможные ситуации, которые могут произойти уже после того, как вы внедрите технологию динамического контроля доступа в свою производственную среду. Здесь очень важно, чтобы вы все тесты изначально провели в лабораторных условиях и, по возможности, с пилотной группой, так как в противном случае исход может быть самым непредсказуемым. В принципе, к планированию динамического контроля доступа мы с вами еще вернемся в одной из последних статей данного цикла, поэтому останавливаться подробнее на данном этапе в рамках этой темы попросту бессмысленно.
Сегодня будут рассмотрены такие моменты, как назначение самих централизованных правил доступа и централизованных политик доступа. Вы узнаете о том, каким образом можно создать, отредактировать и удалить такие правила и политики. Более того, в этой статье вы узнаете о самом распространении и применении централизованных политик доступа. Получается, как и в случае с четвертой статьей данного цикла, материала в этой статье будет достаточно много, по этой причине будем переходить к первому разделу.

Уже на протяжении трех статей этого цикла мы с вами обсуждаем интересную и относительно новую технологию, которая называется «Динамический контроль доступа» или же, как это звучит в оригинале, «Dynamic Access Control», DAC. Другими словами, если вспомнить о том, что же именно вы могли узнать ранее, то в самой первой статье речь шла о самом назначении этой технологии, а также о ее преимуществах по отношению к методам управления разрешениями для данных в предыдущих операционных системах от корпорации Microsoft. Вторая статья этого цикла посвящалась такой неотъемлемой части данной технологии, как утверждения, типы утверждений, а также условные выражения. Третья часть была сравнительно небольшой, и из нее вы могли узнать о таком понятии, как свойства ресурсов. Сегодня мы с вами будем продолжать совмещать теорию с практическими примерами и, прежде всего, как понятно из заголовка данной статьи, продолжим тему свойств ресурсов, и я буквально в двух словах вам расскажу о таком понятии, как списки свойств ресурсов.
Более того, очень много внимания в данной, четвертой, статье этого интересного цикла будет отведено такой теме, как классификация файлов, причем, для реализации которой вы узнаете о таком средстве, как «Диспетчер ресурсов файлового сервера» или, проще говоря, FSRM. Следовательно, вы узнаете о самом назначении этого средства, о некоторых общих принципах работы с FSRM, а также о том, что собой представляет ручная классификация и правила классификации. То есть, как видите, материала в этой статье будет много, и, как я надеюсь, вы узнаете много новой и интересной информации. В таком случае, приступим.

Ты должен увидеть это сам. Не поздно отказаться. Потом пути назад не будет.
Примешь синюю таблетку — и сказке конец.
Ты проснешься в своей постели и поверишь, что это был сон.
Примешь красную таблетку — войдешь в страну чудес.
Я покажу тебе, насколько глубока кроличья нора.
К/ф. «Матрица»
В двух предыдущих статьях настоящего цикла мы с вами начали разбирать богатейшие функциональные возможности технологии динамического контроля доступа, позволяющие перевести на существенно новый уровень всю вашу модель управления ресурсами, расположенными непосредственно на файловых серверах. По большому счету, за две статьи рассмотреть мы с вами успели довольно-таки немного, а именно: я привел базовые сценарии использования этой технологии, а также вы узнали о том, что собой представляют утверждения и как можно управлять уникальными типами утверждений. Но ведь очевидно, что полученных из этих статей знаний недостаточно для того, чтобы иметь четкое представление о данной технологии и начать у себя в организациях разрабатывать свои уникальные сценарии.
В этой статье мы с вами копнем еще глубже и посмотрим на то, что же собой в концепции DAC-а представляют собой ресурсы и списки свойств ресурсов, что также является неотъемлемой частью технологии динамического контроля доступа. То есть, вероятнее всего, это статья будет предпоследней перед тем как мы начнем создавать централизованные политики доступа и переходить к сценариям, о которых я так много говорил в первой статье этого цикла. Ну что же, далее я предлагаю нам проверить, «насколько глубока эта кроличья нора»…

Многие, если не сказать – большинство из вас уже, как я уверен, успели установить и оценить новые возможности в последней клиентской операционной системе от Microsoft – Windows 8. В принципе, некоторым понравился новый «Metro»-интерфейс, а кто-то сразу кинулся искать возможности вернуть «на родину» кнопку «Пуск». Кто-то активно использует новые упакованные приложения, а кто-то изменяет значения системного реестра, чтобы сразу отображался рабочий стол вместо начального экрана. Кто-то успел оценить возможности графического пароля, а кому-то не понравились изменения, связанные с ленточным интерфейсом в большинстве стандартных приложений, включая проводник. Иначе говоря, можно либо смириться со всеми новациями, привыкать к новым возможностям и работать, как ни в чем не бывало, либо постоянно видоизменять ту или иную функциональную возможность (насколько это может позволить Microsoft, естественно) исключительно под свои нужды.
Однако, в этой операционной системе есть несколько таких интересных возможностей, которые попросту не изменяют интерфейс и не добавляют/удаляют новые возможности системы, а просто не подлежат кастомизации. Так вот именно о таких возможностях и пойдет далее в текущей статье речь. Другими словами, в этой статье я не буду говорить о групповых политиках, об Active Directory и о Windows Server в частности. Речь пойдет исключительно о кастомизации клиентской операционной системы, причем о кастомизации таких компонентов системы, в которые можно вносить изменения только при использовании сторонних утилит. Ну что же…

Настройка установленных программных продуктов – довольно утомительная процедура. А если учесть то, что в большинстве организаций идентичные настройки должны быть установлены не на одной машине, а по меньшей мере у нескольких сотрудников одного отдела, то если вы настраиваете приложения средствами графического интерфейса, весь этот процесс может затянуться надолго. Учитывая этот момент, можно сразу прийти к такому выводу, что желательно было бы попробовать автоматизировать процесс настройки программ, чтобы можно было централизованно управлять конфигурациями приложений ваших пользователей.
По большому счету, можно выделить несколько методов, позволяющих настраивать программные продукты, не прибегая к использованию пользовательского интерфейса. К таким методам можно отнести формирование сценариев для автоматизации определенных задач средствами какого-то скриптового языка, например Windows PowerShell или AutoIT, и последующее распространение таких сценариев средствами групповой политики. Помимо этого, если программные продукты генерируют определенные параметры в системном реестре операционных систем, вы можете централизованно предопределять такие настройки при помощи соответствующего элемента предпочтения групповой политики. В конце концов, некоторые программы могут для хранения своих настроек использовать конфигурационные файлы, изменяя которые вы можете вносить некоторые изменения в настройке таких продуктов.
Сегодня мы с вами остановимся именно на последнем описанном выше методе. Другими словами, из материала данной статьи вы узнаете о том, что собой представляют INI-файлы, каким образом они могут повлиять на настройку программ, а также, естественно, я расскажу о централизованной настройке INI-файлов. Но обо всем по порядку.

В предыдущей статье данного цикла я немного вас ввел в курс дела и рассказал, что собой представляет динамический контроль доступа, чем он отличается от предоставления доступа на основе списков ACL, о его преимуществах, а также – буквально в двух словах – o наиболее частых сценариях, когда целесообразно применять данную функциональную возможность. Статья была немного громоздкой, наполненной исключительно теоретическим материалом, да и, вообще сложной для восприятия, так как в ней отсутствовали описания каких-либо пошаговых процедур.
Начиная с этой статьи, я постараюсь исправиться и рассказать вам о том, с чего же необходимо начинать знакомство с этой технологией. А начинать, как видно из самого заголовка статьи, следует ни с чего иного, как с утверждений (они же, как я уже писал в предыдущей статье, еще называются заявками, клаймами и прочими словами, которыми можно заменить claim), которые смело можно отнести к одной из основных составляющих динамического контроля доступа. Сейчас же я постараюсь дать как можно меньше теоретического материала и практически сразу перейти к пошаговой процедуре. Итак, что же вы для себя сможете почерпнуть из этой относительно небольшой статьи?

Как известно каждому системному администратору Windows, начиная с серверной операционной системы Windows Server 2008, такая важнейшая комплексная роль, позволяющая эффективно управлять идентификацией и доступом в организациях, как доменные службы Active Directory, была разделена на целых пять ролей. Если говорить точнее, то всем понятно, что основной задачей роли «Доменные службы Active Directory» (Active Directory Domain Services) выступает выполнение операций, связанных с идентификацией и доступом. То есть тут вам задачи, связанные с проверкой подлинности и авторизацией, тут же есть возможности создания и управления принципалами безопасности, сайтами, службами, а также доверительными отношениями. К этой же роли смело можно отнести централизованную настройку рабочих мест, реализуемую средствами функциональных возможностей групповой политики, и многое другое. Помимо этого, для того, чтобы воспользоваться всеми богатейшими возможностями служб каталогов, также еще можно работать со прочими серверными ролями.
СПОЙЛЕР: В данной статье подается сугубо теоретический материал, и эта статья не предполагает никаких поэтапных процедур.

Одна из возможностей, которой славится новейшая клиентская операционная система от Microsoft, – это возможность кастомизации фона экрана блокировки компьютера, чего так не хватало в предыдущих операционках, из-за чего пользователям приходилось изобретать различные твики и, в большинстве случаев, использовать сторонние программные продукты, которые, между прочим, могли даже принести вред самому рабочему месту пользователя. Думаю, многие помнят, что если вы не хотите использовать какое-либо стороннее программное обеспечение, то нужно было для решения такой задачи в той же Windows 7 вносить изменения в параметры реестра OEMBackground и UseOEMBackground, создавать картинки с определенными разрешениями экрана и определенными наименованиями и помещать их в папку C:\Windows\System32\oobe\info\backgrounds. Короче говоря, весьма утомительная процедура для какой-то мелочи, без которой, по большому счету, можно было бы и прожить.
Собственно, теперь в Windows 8 можно в разы проще изменять изображения экрана блокировки системы, и это может выполнить, грубо говоря, любой пользователь, включая тех, которые боятся даже подходить к компьютерам. То есть для этого на том же начальном экране нужно перейти по ссылке «Сменить аватар», а затем в группе «Экран блокировки» указывается требуемая картинка. Другими словами, 4 клика, не считая поиска самой картинки. Ну проще некуда. Но, опять же, даже здесь есть одно маленькое ограничение. По дефолту операционная система отображает экран блокировки только лишь 1 минуту, а затем экран гаснет, причем не имеет значения, работаете вы от батареи или от сети. И, к сожалению, по умолчанию просто невозможно найти каких-либо опций, снимающих данное ограничение.
Здесь, естественно, может возникнуть следующий вопрос: «А могу ли я как-то снять такое ограничение и добавить опцию в GUI?». Этим мы в данной статье и займемся. Но чтобы было все интереснее, сделаем все централизовано для каждого пользователя, то есть средствами групповой политики. Ну что же, приступим.

Все мы знаем, что с выходом Windows 8 корпорация Microsoft решила полностью изменить представление пользователей о десктопных приложениях. Упакованные приложения, они же Metro-приложения, отличаются единообразием, обновленным упрощенным внешним видом и новым взаимодействием с пользователем. В этих приложениях минимизированы отвлекающие факторы, удалены практически все графические эффекты, включая Windows Aero, над которыми Microsoft трудилась несколько последних лет, для всех приложений используются единая цветовая гамма, шрифты и прочее. Не будем сейчас останавливаться на том, хорошо ли поступили Microsoft, что решили возвращаться к приложениям в стиле Windows 3.1, однако, с этим придется смириться и предпринимать какие-то действия по обслуживанию таких приложений.
Как известно практически каждому, начиная с таких операционных систем, как Windows 7, специально для выполнения задач, связанных с ограничением доступа пользователей к конкретным файлам или приложениям, в дополнение к политикам SRP Microsoft создали новую технологию, которую они назвали AppLocker. Политика AppLocker представляет собой набор из правил AppLocker, включающих в себя различные настройки, предназначенные для принудительного применения. Как свойственно объектам групповой политики, каждое правило сохраняется в конкретной политике, а сами политики уже распространяются согласно вашей иерархии объектов групповой политики.

Ни для кого не является секретом то, что в организациях установка приложений на клиентские компьютеры должна быть (или, если честно, то рекомендуется, чтобы была) автоматизированной. Естественно, комплексные продукты, например, такие как Microsoft System Center Configuration Manager, могут превосходно справляться с такой задачей, однако ведь всегда были, есть и будут организации, которые по той или иной причине не приобрели себе такой продукт. Поэтому приходится устанавливать программные продукты с помощью тех же штатных средств операционных систем Windows, и для выполнения такой задачи предпочтительными становятся функциональные возможности групповой политики.
Также все прекрасно знают и о том, что при помощи расширения клиентской стороны Group Policy Software Installation – GPSI, приложения можно развертывать на клиентские машины двумя методами: либо путем публикации только для пользователей, либо при помощи назначения для пользователей или компьютеров.

Ввиду того, что во время Хабравстречи я рассказывал об 11 различных сценариях, естественно, мне хотелось бы на каждом из этих моментов остановиться подробнее. Другими словами, начиная с этой статьи я рассмотрю большинство моментов, о которых шла речь во время предыдущего доклада. Итак…
Относительно недавно мне в Windows Live Messenger задали несколько вопросов, связанных с делегированием административных полномочий в Active Directory. Однако, прежде чем переходить к самим вопросам по этой теме, я буквально в двух словах расскажу, что же собой представляет делегирование и для чего оно нужно.

Большинство системных администраторов в своей корпоративной среде для обеспечения системы идентификации и доступа своих пользователей к ресурсам предприятия используют доменные службы Active Directory, которые смело можно назвать сердцем всей инфраструктуры предприятия. Как многие из вас знают, структура доменных служб в организациях может включать в себя как один, так и несколько лесов (набор доменов, включающих описание сетевой конфигурации и единственный экземпляр каталога), в зависимости от таких факторов как ограничение области доверительных отношений, полное разделение сетевых данных, получение административной изоляции. В свою очередь, каждый большой лес для упрощения администрирования и репликации данных должен разделяться на домены. В каждом домене для управления доменными службами и выполнения таких задач как проверка подлинности, запуск службы «Центр распределения ключей Kerberos» и управления доступом используются контроллеры домена. А для управления сетевым трафиком между офисами разрабатываются сайты.

Во многих компаниях, для большинства пользователей основным (а иногда и единственным) продуктом, который использует большая часть сотрудников, является тестовый редактор Microsoft Word, входящий как ключевой компонент программного продукта Microsoft Office. В принципе, изначально после установки данный продукт настроен оптимальным образом, и большинство людей использует его, не внося какие-либо изменений в настройки. Если посмотреть на этот программный продукт глубже и хотя бы открыть диалоговое окно «Параметры Word», то можно увидеть, что Microsoft Word включает в себя около двухсот различных настроек, позволяющих подогнать данный продукт непосредственно под свои потребности.
Если перед вами стоит задача, связанная с настройкой некоторых параметров данного продукта для нескольких компьютеров, входящих в домашнее окружение или в рабочую группу, думаю, вас не сильно затруднит, перебрать все настройки и вручную изменить тот или иной параметр. Но если вам нужно поменять определенные настройки для десятка или сотни пользователей, расположенных в нескольких подразделениях на разных этажах, то такое занятие займет у вас продолжительное время, грубо говоря, потраченное зря.
Как многие из вас знают, для централизованного распространения общесистемных настроек и настроек некоторых программных продуктов, целесообразно использовать функционал групповой политики. В этой статье речь пойдет в распространении настроек Microsoft Word 2010 средствами групповой политики, на компьютеры с операционной системой Windows 7, входящие в домен Active Directory, работающим в режиме домена Windows Server 2008 R2 в фиктивной компании Biopharmaceutic.

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

Настройка среды
Поставленную задачу мы будем решать при помощи Microsoft Visual Sutdio 2008. В моем распоряжении в этот самый момент находится редакция Team Edition. Для реализации задуманного потребуется наличие некоторых компонентов от Visual C++. Если вы пишете, например, только на C#, или вы начинающий разработчик, вы могли пропустить установку этих компонентов: