Vous vous intéressez aux filtres WMI pour les GPO ? Ils sont vraiment pratiques pour cibler des machines spécifiques en fonction de leur système d’exploitation, de leur matériel ou même de leur sous-réseau. Mais attention, il est facile de se tromper dans la requête WMI ou de se retrouver bloqué sans savoir si le filtre fonctionne. Ce n’est pas toujours évident au premier abord, surtout si vous débutez avec WMI et la syntaxe WQL. En résumé : les filtres WMI utilisent le langage de requête WMI (WQL) – un peu comme SQL, mais pour les informations de gestion Windows – pour définir les conditions d’application des stratégies. L’avantage principal ? Ils permettent de cibler précisément vos stratégies sans avoir à jongler avec les groupes de sécurité ni à créer d’exclusions manuelles. Attention : sur une configuration, cela a fonctionné du premier coup, sur une autre, il a fallu quelques ajustements. Car, comme toujours, Windows a la fâcheuse habitude de compliquer les choses.
Comment créer et tester des filtres WMI pour les GPO
Configurer le filtre WMI dans la console de gestion des stratégies de groupe
- Ouvrez gpmc.msc (la console de gestion des stratégies de groupe).Si elle n’est pas déjà ouverte, appuyez sur la touche Windows + R Win + R, saisissez gpmc.msc et appuyez sur Entrée.
- Dans le volet de gauche, accédez à la section Filtres WMI. Créez un nouveau filtre : cliquez avec le bouton droit et sélectionnez Nouveau.
- Donnez-lui un nom descriptif, comme « Windows 10 et 11 uniquement » ou « Machines virtuelles uniquement ».Facultatif : ajoutez une description pour vous rappeler à quoi sert ce filtre.
- Cliquez sur Ajouter pour créer votre requête. Vous aurez besoin de l’espace de noms WMI (généralement root\CIMv2 ).Ensuite, saisissez votre requête WMI dans la zone prévue à cet effet. Par exemple, pour cibler Windows 10 et 11, utilisez :
Select * from Win32_OperatingSystem where Version like "10.%" or Version like "11.%". C’est un peu surprenant, mais c’est cette syntaxe qui détermine le filtre. - Une fois terminé, enregistrez-le. Vous pouvez maintenant lier ce filtre à n’importe quel objet de stratégie de groupe (GPO) : sélectionnez le GPO, accédez à Étendue et ajoutez votre filtre WMI sous Filtrage WMI.
Pourquoi cela est utile
Cette méthode garantit que vos stratégies ne s’appliquent pas à un système d’exploitation ou un matériel incompatible. Par exemple, si certains paramètres sont spécifiques à Windows 10/11, il est inutile de les appliquer à Windows Server. Correctement configurée, la stratégie n’est appliquée qu’aux machines répondant à ces critères ; fini les configurations fastidieuses avec les groupes de sécurité.
Quand l’utiliser
Généralement, cela se produit lorsque votre GPO ne s’applique pas correctement ou que vous souhaitez effectuer des déploiements ciblés (par exemple, déployer une mise à jour du firmware uniquement sur les ordinateurs portables dotés de 16 Go de RAM ou appliquer un paramètre uniquement aux postes de travail virtualisés dans VMware).Si la commande `gpresult /r` affiche le statut « Filtrage : Refusé (Filtre WMI) » et que cela est dû à votre filtre, vous avez la solution.
Tester la requête WMI avant de l’appliquer
C’est quasiment indispensable. Avant de faire le lien et de croiser les doigts, vérifiez que votre requête correspond bien à votre machine. Ouvrez PowerShell et exécutez :
Get-WmiObject -Namespace root\CIMv2 -Query "YOUR QUERY HERE".
OU mieux encore (puisque Get-WmiObject est quelque peu obsolète dans les versions récentes de PowerShell) :
Get-CimInstance -Namespace root\CIMv2 -Query "YOUR QUERY HERE".
Par exemple, si vous souhaitez vérifier si Office 16 est installé sur votre ordinateur, essayez :
Get-WmiObject -Query 'Select * from Win32_Product where Name like "%Office 16%"'.
Si vous obtenez une liste de produits, votre requête est correcte. Si aucun résultat n’est renvoyé, vous savez que le filtre ne s’applique pas. Ainsi, vous évitez les suppositions : les tests permettent de déceler les erreurs silencieuses et inattendues.
Exemples de requêtes WMI dont vous pourriez avoir besoin
Vous souhaitez cibler par version de système d’exploitation ? En voici une pratique :
select * from Win32_OperatingSystem WHERE Version LIKE "10.%" OR Version LIKE "11.%".
Pour les contrôleurs de domaine ou le matériel spécifique comme les machines virtuelles VMware :
SELECT Model FROM Win32_ComputerSystem WHERE Model LIKE "%VMware%"
Ou ciblez les machines dotées de plus de 4 Go de RAM :
select * from Win32_ComputerSystem where TotalPhysicalMemory >= 4200000000
Et si vous souhaitez approfondir le sujet, l’ outil WMI Code Creator v1.0 est très pratique pour parcourir les classes et les attributs. C’est un excellent moyen de vérifier la syntaxe avant de l’utiliser dans vos filtres.
Testez votre filtre WMI à l’aide de PowerShell
N’appliquez jamais un filtre WMI sans réfléchir, car il arrive qu’il ne corresponde pas à ce que vous imaginez. Pour vérifier, exécutez la requête depuis PowerShell et comparez les informations de votre machine. Par exemple, pour vérifier si vous utilisez Windows 10, saisissez :
Get-CimInstance -Namespace root\CIMv2 -Query "select * from Win32_OperatingSystem where Version like '10.%'".
Si la requête renvoie des informations, c’est bon. Si elle ne renvoie rien, vous savez qu’il faut la modifier.
Astuce : pour vérifier les applications installées ou d’autres éléments, modifiez simplement la classe et filtrez en conséquence. Notez que dans les versions récentes de PowerShell, `is` Get-WmiObjectest progressivement remplacé par `is` Get-CimInstance. Adaptez donc votre configuration en conséquence.
En résumé, les filtres WMI sont puissants, mais leur configuration peut s’avérer complexe. Tester chaque requête sur une machine simplifie grandement les choses : fini les erreurs silencieuses et les approximations. L’essentiel est de bien comprendre vos données, puis de les traduire en une requête WMI que vous pouvez tester et optimiser.
Conclure
J’espère que cela permettra de clarifier certains points concernant les filtres WMI. Ils constituent un excellent moyen de configurer très précisément les stratégies de groupe, notamment lorsque les groupes de sécurité seraient excessifs ou impraticables. N’oubliez pas de tester vos requêtes sur des machines physiques au préalable : il serait inutile d’appliquer des stratégies qui échouent à cause d’une faute de frappe ou d’une erreur de logique. Ce n’est pas une solution infaillible, mais c’est assurément un bon moyen de rendre votre configuration de stratégie de groupe plus intelligente et plus ciblée.
Résumé
- Utilisez gpmc.msc pour créer des filtres WMI et les lier à des GPO.
- Rédigez vos requêtes WMI au format suivant :
Select * from Class where condition - Effectuez des requêtes de test à l’aide de PowerShell pour vous assurer qu’elles correspondent aux machines attendues.
- Appliquez des filtres pour définir précisément la portée de votre GPO : système d’exploitation, matériel, réseau ou logiciel.
J’espère que cela permettra à certains d’éviter de perdre des heures à tâtonner. Les filtres WMI sont un peu capricieux au début, mais une fois qu’on les maîtrise, ils sont très performants. Bonne chance et bon courage pour la configuration de vos GPO !