Установка роли WSUS на Windows Server 2012 R2 / 2016
Еще в Windows Server 2008 сервис WSUS был выделен в отдельную роль, которую можно было установить через консоль управления сервером. В Windows Server 2012 / R2 этот момент не поменялся. Откройте консоль Server Manager и отметьте роль Windows Server Update Services (система автоматически выберет и предложит установить необходимые компоненты веб сервера IIS).
Отметьте опцию WSUS Services, далее необходимо выбрать тип базы данных, которую будет использовать WSUS.
В Windows Server 2012 R2 поддерживаются следующие типы SQL баз данных для WSUS сервера:
- Windows Internal Database (WID);
- Microsoft SQL Server 2008 R2 SP1, 2012, 2014, 2016 в редакциях Enterprise / Standard / Express Edition;
- Microsoft SQL Server 2012 Enterprise / Standard / Express Edition.
Соответственно вы можете использовать встроенную базу данных Windows WID (Windows Internal database), которая является бесплатной и не требует дополнительного лицензирования. Либо вы можете использовать выделенную локальная или удаленную (на другом сервере) базу данных на SQL Server для хранения данных WSUS.
База WID по умолчанию называется SUSDB.mdf и хранится в каталоге windir%\wid\data\. Эта база поддерживает только Windows аутентификацию (но не SQL). Инстанс внутренней (WID) базы данных для WSUS называется server_name\Microsoft##WID. В базе данных WSUS хранятся настройки сервера обновлений, метаданные обновлений и сведения о клиентах сервера WSUS.
Внутреннюю базу Windows (Windows Internal Database) рекомендуется использовать, если:
- Организация не имеет и не планирует покупать лицензии на SQL Server;
- Не планируется использовать балансировку нагрузки на WSUS (NLB WSUS);
- Если планируется развернуть дочерний сервер WSUS (например, в филиалах). В этом случае на вторичных серверах рекомендуется использовать встроенную базу WSUS.
Базу WID можно администрировать через SQL Server Management Studio (SSMS), если указать в строке подключения \\.\pipe\MICROSOFT##WID\tsql\query.
Отметим, что в бесплатных редакциях SQL Server 2008/2012 Express имеет ограничение на максимальный размер БД – 10 Гб. Скорее всего это ограничение достигнуто не будет (например, размер базы WSUS на 2500 клиентов – около 3 Гб). Ограничение Windows Internal Database – 524 Гб.
В случае, установки роли WSUS и сервера БД на разных серверах, существует ряд ограничений:
- SQL сервер с БД WSUS не может быть контроллером домена;
- Сервер WSUS не может быть одновременно сервером терминалов с ролью Remote Desktop Services;
Если вы планируете использовать встроенную базу данных (это вполне рекомендуемый и работоспособный вариант даже для больших инфраструктур), отметьте опцию WID Database.
Затем нужно указать каталог, в котором будут храниться файлы обновлений (рекомендуется, чтобы на выбранном диске было как минимум 10 Гб свободного места).
Размер базы данных WSUS сильно зависит от количества продуктов и ОС Windows, которое вы планируете обновлять. В большой организации размер файлов обновлений на WSUS сервере может достигать сотни Гб. Например, у меня каталог с обновлениями WSUS занимает около 400 Гб (хранятся обновления для Windows 7, 8.1, 10, Windows Server 2008 R2, 2012 / R2/ 2016, Exchange 2013, Office 2010 и 2016, SQL Server 2008/2012/2016). Имейте это в виду, планируя место для размещения файлов WSUS.
В том случае, если ранее было выбрано использование отдельной выделенной БД SQL, необходимо указать имя сервера СУБД, инстанса БД и проверить подключение.
Далее запустится установка роли WSUS и всех необходимых компонентов, после окончания которых запустите консоль управления WSUS в консоли Server Manager.
Вы также можете установить сервер WSUS со внутренней базой данных с помощью следующей команды PowerShell:
Алгоритм устранения проблем с GPO
Предположим, что у меня есть групповая политика, которая применяется на организационное подразделение «Client Computers». Политика называется «Управление UIPI». По какой-то причине пользователь жалуется, что она у него не применилась.
Из информации, об области действия групповой политики, первое на что нужно обратить свое внимание, это находится ли объект пользователя или компьютера по нужному пути. Сделать, это просто в оснастке «Управление групповой политикой» найдите вашу политику и посмотрите к каким OU она применяется, это видно на вкладке «Область (Scope)», ее еще называют областью действия политики
В моем случае, это путь root.pyatilistnik.org/Client Computers.
Так как Active Directory, это иерархическая структура, то одна OU можете быть часть дерева из других и сама включать в себя большое количество организационных подразделений. Поэтому если у вас есть вложенность, то просто зайдя в нужную OU вы можете сразу не найти нужный объект. В таком случае воспользуйтесь поиском по Active Directory. Например у меня есть рабочая станция с которой идут жалобы на применение объекта GPO. В поиске выбираем в поле «Найти» компьютеры и в имени указываем w10-cl01, после чего нажимаем «Найти». В результатах поиска вы получите выдачу. Щелкаем по нужному объекту и переходим в нем на вкладку «Объект», где смотрим «Каноническое имя объекта», по сути это его путь расположения в Active Directory. Сравниваем его с тем, что получили из области применения групповой политики и делаем вывод, попадает объект под действие или нет.
Далее убедитесь, что у вас элементарно включена связь объекта групповой политики с нужным организационным подразделением. Для этого в оснастке управления GPO, щелкните правым кликом по нужной политике и в контекстном меню проверьте, что установлена галка «Связь включена», ее так же можно проверить на вкладке «Область» в столбце «Связь задействована», должно стоять значение «да».
Следующим моментом необходимо проверить, что политика не отключена на определенный объект. Для этого перейдите на вкладку «Сведения» на нужной GPO. Нас интересует строка «Состояние GPO». По умолчанию там стоит значение «Включено», означающее, что политика будет пытаться примениться заданные в ней настройки к обоим типам объектов (Пользователю и компьютеру). Но может быть выставлено значение:
- Параметры конфигурации компьютера отключены (Computer configuration settings disabled)
- Параметры конфигурации пользователя отключены (User configuration settings disabled)
- Все параметры отключены (All setting disabled) — запретит применение политики для любого объекта
Сделано, это для ускорения применения политики к объекты. Согласитесь, что если у вас в GPO настроены изменения только для пользователя, то нет смысла проверять политику для компьютера. Поэтому системные администраторы могут отключать это, но могут и ошибиться, выключив не тот объект
Выше я вам писал, что структура OU иерархическая, а это означает, что политика прилинкованная с вышестоящего организационного подразделения применяется на нижестоящее. Но вот если у нижестоящей OU отключено наследование сверху, то он не сможет применить данную политику. Проверяется очень просто, найдите нужную вам OU, щелкните по ней правым кликом и удостоверьтесь, что не стоит пункт «Блокировать наследование».
Он кстати будет иметь характерный значок с восклицательным знаком. Данный механизм создан специально, чтобы изолировать данную OU от ненужных политик GPO.
Для чего нужен механизм фильтрации GPO
Какую бы вы сложную иерархию Active Directory не создавали у вас рано или поздно появится ситуация, что вам нужно для двух и более объектов находящихся в одном OU иметь разные настройки, а для кого-то вообще запретить применение определенной групповой политики, но перемещать объект нельзя, так как в текущей иерархии он получает все настройки по корпоративному стандарту, и усложнять структуру не представляется возможным.
Лично я стараюсь не создавать лишних организационных подразделений, так как, чем проще система, тем проще ею управлять. У вас может быть вообще одна OU и все навалено в ней, но это вам не мешает грамотно применять политики к конкретным объектам, благодаря фильтрации на разных этапах GPO.
Управление областью действия GPO
Если параметр политики не применяется к клиенту, проверьте область действия GPO. Если вы настраиваете параметр в разделе Computer Configuration («Конфигурация компьютера»), ваша групповая политика должна быть сопряжена с организационным подразделением (OU) объектов компьютеров. То же самое верно, если вы установите свои параметры в разделе User configuration («Конфигурации пользователя»).
Также убедитесь, что объект, к которому вы пытаетесь применить свой GPO, находится в правильном контейнере AD (OU) компьютеров или пользователей. Если у вас много объектов и вы не можете вспомнить, в каком организационном подразделении находится нужный вам пользователь или компьютер, то вы можете выполнить поиск по объектам в своём домене. После выполнения поиска, чтобы узнать, в какое организационное подразделение (OU) помещён найденный объект, дважды кликните на него, перейдите на вкладку Object («Объект»), где в поле «Каноническое имя объекта» вы увидите полный путь, включающий имя организационного подразделения.
Связанная статья: Поиск по Active Director групп и пользователей с использованием подстановочных знаков
Это означает, что целевой объект должен находиться в подразделении, с которым связана политика (или во вложенном контейнере AD).
Как включить GPO Loopback Processing Mode (режим обработки замыкания GPO)
Если вы включили Loopback Processing mode («Режим обработки замыкания»), вы можете применить настройки из раздела «Конфигурация пользователя» к объекту компьютера. Вы можете включить режим кольцевой обработки в следующем разделе редактора GPO: Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy Loopback Processing mode (в русифицированной версии Конфигурация компьютера → Политики → Административные шаблоны → Система → Групповая политика → Настройка режима обработки замыкания пользовательской групповой политики). Например, если вы включите обработку обратной связи политики, зададите некоторые параметры в разделе «Конфигурация пользователя» и свяжете политику с подразделением с объектами компьютеров, эти параметры политики будут применены к выполнившим вход пользователям.
Этот режим обработки замыкания политики имеет два возможных значения:
Merge («Слияние») – сначала к пользователю применяется объект групповой политики на основе местоположения пользователя, а затем применяется объект групповой политики, связанный с компьютером
В случае конфликта политик OU пользователя и компьютера, политика компьютера будет иметь более высокий приоритет.
В этом режиме политика запускается дважды, обратите внимание на это при использовании сценариев входа в систему.
Replace («Замена») – к пользователю будут применяться только политики, назначенные подразделению, содержащему компьютер, на котором пользователь вошёл в систему.
Фильтрация GPO WMI
В объекте групповой политики можно использовать специальные фильтры WMI. Таким образом, вы можете применить политику к своим компьютерам на основе некоторого запроса WMI. Например, вы можете создать фильтр WMI GPO для применения политики только к компьютерам с определённой версией Windows, к компьютерам в определённой IP-подсети, только к ноутбукам и так далее.
При использовании фильтрации WMI групповой политики убедитесь, что ваш запрос WMI верен. Он должен выбирать только те системы, которые вам нужны, и ни один целевой компьютер не исключается. Вы можете протестировать свой WMI-фильтр на компьютерах с помощью PowerShell:
gwmi -Query 'select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"'
Если запрос возвращает какие-либо данные, то к этому компьютеру будет применён фильтр WMI.
Анализ событий групповой политики в системных журналах Windows
В журнале приложения идентификатор события 6006 из Winlogon со следующим сообщением может свидетельствовать о медленном применении политики:
The winlogon notification subscriber <GPClient> took 3104 seconds to handle the notification event (CreateSession).
Перевод: Подписчику уведомления winlogon <GPClient> потребовалось 3104 секунды для обработки события уведомления (CreateSession).
Согласно этому событию, пользователю приходилось ждать применения групповых политик при загрузке почти час…
В Windows 7 / Windows 2008 R2 или выше все события, связанные с обработкой групповой политики на клиенте, доступны в Event Viewer («Просмотр событий»), его можно открыть в командной строке:
eventvwr.msc
В окне Event Viewer («Просмотр событий») перейдите по пути Applications and Services Logs → Microsoft → Windows → Applications and Services Logs → Group Policy → Operational (в русскоязычной версии это Журналы приложений и служб → Microsoft → Windows → Group Policy → Operational).
В Event Viewer («Просмотр событий») вы также можете фильтровать события по источнику для этого нажмите «Создать настраиваемое представление» и в качестве источника выберите GroupPolicy (Microsoft-Windows-GroupPolicy).
Вы увидите журнал событий, связанных с применением групповых политик:
Примечание. В системном журнале остаются только события, связанные с работой самого Клиента групповой политики (gpsvc).
Для анализа времени применения политики будут полезны следующие EventID (Коды событий):
События с идентификаторами 4016 и 5016 показывают время начала и окончания обработки расширений приложения GPO. Последний также указывает общее время обработки расширения. Например, на скриншоте ниже была включена фильтрация Group Policy → Operational по EventID 4016 и 5016. В сообщении EventID 5016 вы можете увидеть время обработки этого компонента GPO.
Завершена обработка расширения Security за 266 мс.
- EventID 5312 содержит список применённых политик, а EventID 5317 показывает список отфильтрованных GPO.
- EventID 8000 и 8001 содержат время обработки политик компьютера и пользователя во время загрузки соответственно. А в EventID 8006 и 8007 есть данные о времени применения политики при регулярных обновлениях.
Завершена обработка политики загрузки компьютера для DS\HACKWARE-WIN$ за 28 с. Завершена обработка политики входа пользователя для DS\Administrator за 5 с.
Анализируя журнал, обратите внимание на время между двумя соседними событиями. Это может помочь найти проблемный компонент.
Другие связанные параметры групповой политики
Существуют другие параметры политики Windows Hello для бизнеса, которые можно настроить для управления вашим развертыванием Windows Hello для бизнеса. Эти параметры политики представляют собой параметры политики для компьютеров, т. е. они применяются к любому пользователю, выполняющему вход с компьютера с этими параметрами политики.
Использование устройства аппаратной защиты
По умолчанию Windows Hello для бизнеса отдает предпочтение аппаратно защищенным учетным данным, однако не все компьютеры способны создавать аппаратно защищенные учетные данные. Когда при регистрации в Windows Hello для бизнеса обнаруживается компьютер, который не способен создавать аппаратно защищенные учетные данные, создаются программные учетные данные.
Можно настроить и развернуть параметр групповой политики Использование устройства аппаратной защиты, чтобы принудить Windows Hello для бизнеса создавать только аппаратно защищенные учетные данные. Пользователи, которые выполняют вход с компьютера, неспособного создавать аппаратно защищенные учетные данные, не регистрируются в Windows Hello для бизнеса.
При включении параметра групповой политики Использование устройства аппаратной защиты становится доступен еще один параметр политики, который позволяет запретить использовать для регистрации в Windows Hello для бизнеса доверенные платформенные модули (TPM) версии 1.2. TTP-машины версии 1.2 обычно выполняют криптографические операции медленнее, чем TPM версии 2.0, и более неумолимы во время действий защиты от блокировки ПИН-кода. Некоторым организациям может не потребоваться низкая производительность входа и затраты на управление, связанные с TTP версии 1.2. Чтобы запретить Windows Hello для бизнеса использовать TPM версии 1.2, установите флажок TPM 1.2 после включения объекта Использовать аппаратное устройство безопасности групповая политика.
Использование биометрии
В сочетании с биометрическими данными Windows Hello для бизнеса обеспечивает пользователям максимальный комфорт. Вместо предоставления для входа в систему PIN-кода пользователь может использовать для входа в Windows отпечатки пальцев или распознавание лиц, не жертвуя при этом безопасностью.
По умолчанию Windows Hello для бизнеса позволяет пользователям регистрироваться и использовать биометрические данные. Некоторые организации, однако, пока не готовы переходить на биометрию, и хотели бы пока отключить ее использование. Чтобы запретить пользователям использовать биометрические данные, отключите параметр групповой политики Использование биометрии и примените его к своим компьютерам. Параметр политики отключает все биометрические данные. В настоящее время Windows не предоставляет возможность задавать детализированные политики, которые позволяют отключить определенные методы биометрии, например разрешить распознавание лиц, но запретить распознавание отпечатков пальцев.
Сложность PIN-кода
Сложность PIN-кода относится не только к Windows Hello для бизнеса. Windows позволяет пользователям использовать ПИН-коды за пределами Windows Hello для бизнеса. Параметры групповой политики «Сложность PIN-кода» применяются ко всем ситуациям использования PIN-кодов, даже когда Windows Hello для бизнеса не развернута.
Windows предоставляет восемь параметров сложности ПИН-кода групповая политика, которые предоставляют детальный контроль над созданием ПИН-кода и управлением ими. Эти параметры политики можно развертывать для компьютеров, т. е. они будут влиять на всех пользователей, создающих PIN-коды на данном компьютере; или же их можно развертывать для пользователей, т. е. они будут влиять на создание PIN-кодов данными пользователями вне зависимости от используемого ими компьютера. При развертывании параметров групповой политики сложности PIN-кода и для компьютеров, и для пользователей, параметры политики для пользователей имеют приоритет над параметрами политики для компьютеров. Кроме того, разрешение таких конфликтов зависит от того, какая политика была применена последней. Windows не объединяет параметры политики автоматически. Предусмотрены следующие параметры политики:
- Требовать использование цифр
- Требовать использование строчных букв
- Максимальная длина PIN-кода
- Минимальная длина PIN-кода
- Срок действия
- Журнал
- Требовать использование специальных символов
- Требовать использование прописных букв
Параметры можно найти в разделе Административные шаблоны\Система\Сложность ПИН-кода в узлах Конфигурация компьютера и пользователя редактора групповая политика.
Фильтрация безопасности в GPO
Проверьте настройки Security Filtering («фильтрации безопасности») в своей политике. По умолчанию для всех новых объектов GPO в домене включены разрешения для группы Authenticated Users («Прошедшие проверку»). В эту группу входят все пользователи и компьютеры в домене. Это означает, что политика будет применяться ко всем пользователям и компьютерам в пределах её области действия.
Если вы хотите изменить фильтрацию безопасности, чтобы применить политику только к членам определённой группы безопасности (или определенным пользователям/компьютерам), удалите «Authenticated Users» из списка фильтрации безопасности и убедитесь, что целевой объект (пользователь или компьютер) добавлен в нужную вам группу AD. Также убедитесь, что группа, которую вы добавили в фильтр безопасности, имеет разрешения Read и Apply group policy с установленным флажком Allow («Разрешить») в GPO → Delegation → кнопка Advanced (GPO → Делегирование → кнопка «Дополнительно»).
Если вы используете нестандартные фильтры безопасности GPO, убедитесь, что нет явного запрета на использование GPO для целевых групп (Deny).
