Помощь по WMI фильтру
 

Имею доменую структуру, один из организационных подразделений с пользователями содержит несколько GPO, нужно что бы одна из политик применялась только на одном из терминал-серверов. Создал WMI-фильтр для данной политике с следующим содержанием.
Namespace - root\CIMv2
Query - SELECT * FROM Win32_ComputerSystem WHERE Name = 'V-RDS02'
где V-RDS0' имя компьютера.
Но политика продолжает применяться на остальних терминал-серверах.
Подскажите пожалуйста где у меня ошибка?

SELECT * FROM Win32_OperatingSystem WHERE CSName = 'V-RDS02'

Спасибо за ответ но уже заработала с NAME.
Еще один вопрос SELECT * FROM Win32_ComputerSystem WHERE Name LIKE 'V-RDS0%' - будет включать все сервера содержащие в названии сочетание V-RDS0 ?
Заранее благодарен.

Gremuciy, нет: не «содержащие», а «начинающиеся с».

Если я правильно понял, если прикрепить фильтр SELECT * FROM Win32_ComputerSystem WHERE Name LIKE 'V-RDS0%' к групповой политике, то данная политика будет применяться только к компьютерам у которых имя начинаеться с "V-RDS0", а вариант SELECT * FROM Win32_ComputerSystem WHERE Name LIKE '%V-RDS0%' к компьютерам у которых в имени содержиться "V-RDS0"?

Фильтры лучше не использовать.
Лучше назначать политику на группу и совместить ее с GP Loopback в режиме замены, а еще правильнее использовать Group Policy Preference (там можно настроить на кого именно и что хотите применять).

почему?

Они увеличивают время входа в систему, а в случае проблем с WMI можно нарваться на 10-ми минутный таймаут применения политики.

Так что арифметика примерно такова 1 фильтр - 10 минут входа, 2 - 20 и т.д.

Видел я компы которые давились тремя фильтрами и висели пол часа.

Фильтрацию нужно использовать только в случае если недоступны другие методики.

Кстати вот тут есть замечательный абзац

It is recommended that you use WMI filters primarily for exception management. They can be powerful solutions for targeting GPOs to specific users and computers, but because WMI filters are evaluated every time Group Policy is processed, they increase startup and logon time. Also, there is no time-out for WMI filters. Use them only when necessary.

Последнюю фразу я поддерживаю целиком и полностью.

это всё читала и много другого, мне вот интересно другуе - вы сами, лично сталкивались с этими проблемами? или так, слышали звон?
видела я умирающие жёсткие диски, с 0 свободного места на С:, еле работали.
использовать жёсткике диски не надо.
доступно объяснила? =)

на самом деле всё зависит от самого запроса(ов) в фильтре, поэтому споры эти считаю беспредметными и чутка пафосными.
можно легко и не принуждённо нагнуть core i5 и ms office 2010 открывая стомегабайтный экселевский документ, с кучей рассчётов, но это не означает что core i5 плохой процессор, а офис 2010 не инструмент.
всему своё место.

Видел не далее как на последнем своем аудите.

Запросы были из разряда определения языка (1033 или 1049), определение сервер или нет, XP или Windows 7.

Все максимально просто, один запрос...

Результат - проблемные XP-хи валом висят при перезагрузке, как и положено кол-во запросов * 10 минут, там где накладывали фильтр по 2003 или 2008 сервер логин по RDP висел, как и положено 10 минут.

Спорить не буду :) Экспериментируйте.

я не только экспериментирую, я широко использую фильтрацию WMI, в основном, тоже один, максимум 2 запроса.
железо - от celeron northwood до X5690, на каналах от 1мегабита.
не сталкивалась с описаным вами ни разу.
возможно имеет смысл рассмотреть запросы и проанализовать логи применения ГП на предмет выявления узких мест.

Берем запрос
Select * from Win32_OperatingSystem where Caption = " Microsoft Windows XP Professional"
Анализируем...

:)

Я не спорю что все оно работает, когда клиенты живые, но при проблемах WMI на стороне клиента мы сразу же наблюдаем косяки типа "чо та дофига висит при входе". Желания копаться с клиентом за которым не усмотрел саппорт и пр у меня нет.

Естественно отсюда вывод - проблема не в фильтрах а в клиентах на которых они применяются.
Поэтому я предпочитаю другие методики, например логон скрипты, GPE и пр.

линкуем политику на всех, а потом парсим скриптом содержимое?
фу как не красиво. на мой взгляд.
GPE - вы, видимо, о таргеттинге говорите.
он, если что, тоже через WMI работает =)
ну именно так я не запрашиваю - беру Version или Product type или SKU, но, как я говорила, проблем не испытываю.
отсюда мне кажется что вамши слова о каких-то глобальных проблемах с WMI связаны либо с вами лично, либо с организациям аудит которых вы проводите =)
а убирание фильтра сразу решает проблему? или отлинковка политики? тогда проблема с WMI не очевидна.

Именно.

cameron, глобальных проблем не испытываю. Просто предпочитаю использовать фильтрацию только в случае крайней необходимости когда нет других методик + помню про background refresh.

К контексте изначальной задачи использование фильтрации является излишком потому что вполне будет достаточно применить политику к конкретному серверу и включить Group Policy Loopback в режиме замены.

если всё так как вы говорите и фильтр именно тот что написан выше, я могу предположить 3 варианта:
- сильно кривая сборка ХР
- шаловливыми ручками оттюнена ХР
- карма

потому что, ещё раз повторюсь, у меня только WMI фильтрация, я даже почти не использую Security Filtering и ни разу не сталкивалась с таким.
изначальная задача - фильтровать несколько серверов, в имени которых есть какой-то там набор символов.
зачем тут loopback я не понимаю.

Отлично. Сколько у вас политик?

Возможно и не нужно, но раз мы говорим про терминальные серверы ее лучше применять. Хотя бы для того что бы за пользователем не тянулось лишнее.

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

Прикалываться изволите ? :)
Раз не сталкивались это не означает что такого не может быть.

пара десятков
ничего лишнего за пользователем не тянется, ибо фильтруется через WMI =)
так WMI как раз это и даёт.
нет, не прикалываюсь ни разу.
просто если за 10 лет использования WMI я не сталкивалась с этой проблемой, я склонна считать что её нет.
либо, всё же, моя карма лучше =)

у меня нет оснований не верить вам, вы явно хороший специалист с большим опытом работы, но данный случай мне интересен с субуго практической точки зрения - а вдруг у меня полезут грабли с WMI и мне придётся вернуться к loopbaсk, который я забыла как страшный сон со времён 2к.

да, кстати, а если разные терминалы, с разными параметрами, для разных пользователей в разных сайтах, то как у нас с loopback? =)

Всем спасибо за ответы, фильтр решил проблему. Серверов больше нескольких десятков. loopback стоит на политике с подразделением, куда включены терминал сервера, просто из-за специфики работы пользователи имеют разные права и видят разное пользовательское окружение (ярлыки, сетевые диски, настройки некоторых программ и т.п.) в зависимости от сервера. Мне казалось что таргетирование с помощью фильтра быстрее. :)

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

Вы lookback с кем то путаете :)
Он призван на службу и его функционал только для того что бы применять только то что требуется (режим замены), но доступно и совмещение, тогда это действительно ужас.

Последний объект где я копался был начинен 240 политиками которые занимались настройкой рабочих мест и ставили софт, конечно после разбирательства с ними их стало меньше и Sysvol стал легче (с 300 метров до 180). На работе в данный момент политик 360 штук.

Это отлично. Вам повезло. Но это не отменяет возможность наличия проблемы.

zero55 я же написал что loopback политика включена на подразделении куда входят терминал сервера. :)