Introduction
Vous pouvez déployer l'agent Level sur des appareils Windows joints à un domaine à l'aide de la stratégie de groupe. Deux approches sont possibles : importer une automatisation prédéfinie de Level qui gère la création de l'objet de stratégie de groupe (GPO) automatiquement, ou configurer le GPO manuellement.
Quelle méthode utiliser ?
Méthode | Ce qu'elle nécessite | Ce que vous obtenez |
Configuration automatisée (Méthode 1) | Un compte Active Directory pouvant créer des GPO, et — sur un domaine avec plusieurs contrôleurs de domaine — l'exécuter sur l'émulateur PDC. | Level crée et lie le GPO pour vous. Le programme d'installation qu'il génère consigne également l'activité d'installation dans le journal des événements Windows sur chaque client, ce qui facilite la résolution des problèmes en cas d'échec d'installation. |
Configuration manuelle (Méthode 2) | Un administrateur de domaine pour créer le GPO manuellement dans la gestion des stratégies de groupe. | Contrôle total sur l'unité d'organisation (UO) ciblée, sans rien à créer ni à relire dans Active Directory. C'est l'option la plus fiable sur les domaines comptant plusieurs contrôleurs de domaine, mais elle n'ajoute pas de journalisation des événements côté client. |
⚙️ PRÉREQUIS
Domaine Active Directory avec la gestion des stratégies de groupe
Un contrôleur de domaine accessible depuis Level
Un compte Level avec l'autorisation d'ajouter des appareils
Pour la configuration automatisée : un compte Active Directory pouvant créer des GPO (voir Avant d'exécuter l'automatisation ci-dessous)
ℹ️ REMARQUE : Cette méthode de déploiement est fournie à titre de commodité. Le comportement des GPO varie selon les environnements Active Directory — effectuez des tests avant de déployer en production.
Installer via la stratégie de groupe
Méthode 1 : Configuration automatisée
Level fournit une automatisation prédéfinie qui crée et lie le GPO pour vous. Elle s'exécute sur un seul contrôleur de domaine et propage l'installation de l'agent sur tous les clients via une tâche planifiée.
Avant d'exécuter l'automatisation
⚠️ AVERTISSEMENT : Deux conditions d'environnement déterminent si cette automatisation réussit : le compte sous lequel elle s'exécute doit pouvoir créer des GPO, et sur un domaine avec plusieurs contrôleurs de domaine, elle doit s'exécuter sur l'émulateur PDC. Vérifiez les deux avant de la lancer.
Exécuter sous un compte pouvant créer des GPO
Par défaut, l'étape de script de l'automatisation s'exécute en tant que Système local, qui est le compte SYSTEM propre au contrôleur de domaine. Dans la plupart des environnements Active Directory, SYSTEM n'est pas membre de Propriétaires du groupe de stratégies, de sorte qu'Active Directory refuse de créer le GPO et que l'exécution s'arrête avec New-GPO : Access is denied.
Pour l'exécuter sous un compte disposant des droits nécessaires :
Ouvrez l'automatisation importée et sélectionnez l'étape de script.
Définissez Exécuter en tant que en Utilisateur actuel.
Connectez-vous à la console du contrôleur de domaine que vous avez désigné, en utilisant un compte Administrateur de domaine ou membre des Propriétaires du groupe de stratégies.
Exécutez l'automatisation pendant que ce compte est connecté.
ℹ️ REMARQUE : La modification de Exécuter en tant que n'affecte que ce script de configuration unique sur le contrôleur de domaine. Le GPO qu'il crée installe toujours l'agent sur les appareils clients en tant que SYSTEM, et cela ne change pas.
Sur un domaine multi-DC, exécuter sur l'émulateur PDC
Le script de configuration crée le GPO sur le contrôleur de domaine détenant le rôle d'émulateur PDC, puis le relit depuis le contrôleur de domaine sur lequel il s'exécute. Lorsque ces deux contrôleurs sont différents, le GPO tout juste créé peut ne pas avoir encore été répliqué et l'exécution s'arrête avec Get-ADObject : Directory object not found. L'exécution de l'automatisation sur l'émulateur PDC maintient les deux étapes sur le même contrôleur.
Pour déterminer quel contrôleur détient le rôle, exécutez netdom query fsmo depuis une invite élevée sur n'importe quel contrôleur de domaine, ou ouvrez Utilisateurs et ordinateurs Active Directory, faites un clic droit sur le domaine, choisissez Maîtres d'opérations et consultez l'onglet PDC onglet. Si votre domaine ne dispose que d'un seul contrôleur de domaine, cela ne vous concerne pas.
Étape 1 : Importer l'automatisation GPO
Importez l'automatisation dans votre compte Level : Importer l'automatisation GPO Level
Cliquez sur Importer l'automatisation pour l'ajouter à votre compte.
Étape 2 : Obtenir votre clé d'installation
Dans Level, ouvrez Liste des appareils et cliquez sur Ajouter un nouvel appareil.
Sélectionnez Windows depuis le sélecteur de système d'exploitation.
Sélectionnez éventuellement un groupe d'appareils — la clé d'installation inclura l'identifiant du groupe si un groupe est sélectionné.
Copiez la clé d'installation depuis la fenêtre modale.
Étape 3 : Configurer les variables de l'automatisation
Ouvrez l'automatisation importée et sélectionnez l'onglet Variables onglet.
Collez votre clé d'installation dans la variable
LEVEL_API_KEYvariable.Si vous avez sélectionné un groupe, collez l'identifiant du groupe dans la variable d'identifiant de groupe.
Étape 4 : Affecter à un contrôleur de domaine
Ajoutez un seul contrôleur de domaine comme appareil cible pour cette automatisation. Sur un domaine avec plusieurs contrôleurs de domaine, choisissez celui qui détient le rôle d'émulateur PDC (netdom query fsmo).
⚠️ AVERTISSEMENT : N'affectez cette automatisation qu'à un seul contrôleur de domaine. L'automatisation crée un GPO à la racine du domaine — l'exécuter sur plusieurs contrôleurs entraînera des conflits.
Étape 5 : Approuver et exécuter
La première étape de l'automatisation est une validation par un administrateur. Vérifiez et cliquez sur Approuver pour continuer.
La deuxième étape exécute un script qui crée un nouveau GPO appelé «Install Level Agent» et le lie à la racine du domaine. Le GPO crée une tâche planifiée sur tous les clients Active Directory qui exécute immédiatement le script d'installation de Level.
ℹ️ REMARQUE : La configuration automatisée écrit des messages dans le journal des événements Windows sur les machines clientes lors de l'exécution du script d'installation. Ils sont enregistrés dans le journal Application journal sous la source Level, avec les identifiants d'événements 100 à 104 couvrant les résultats suivants : installé, déjà installé, échec possible de l'installation, et résultats du démarrage du service. Ces informations sont utiles pour résoudre les problèmes d'installation échouée.
⚠️ AVERTISSEMENT : Le journal d'exécution affiche la clé d'installation transmise au programme d'installation. Traitez ce journal comme sensible — si vous le partagez, supprimez d'abord la clé, et si une clé a été exposée, générez-en une nouvelle et mettez à jour la variable LEVEL_API_KEY variable.
Résolution des problèmes de la configuration automatisée
Erreur dans la sortie d'exécution | Ce que cela signifie | Que faire |
| Le compte sous lequel le script s'est exécuté ne peut pas créer de GPO. C'est normal lorsque l'étape s'exécute en tant que Système local, car SYSTEM n'est généralement pas membre des Propriétaires du groupe de stratégies. | Définissez le paramètre Exécuter en tant que en Utilisateur actuel et exécutez l'automatisation pendant qu'un Administrateur de domaine est connecté à la console du contrôleur de domaine. Voir Avant d'exécuter l'automatisation. |
| Le GPO a été créé, mais le script l'a relu depuis un contrôleur de domaine qui ne l'avait pas encore reçu. L'identifiant d'objet dans l'erreur est le GPO qui vient d'être créé, donc rien n'est mal configuré — les deux contrôleurs sont momentanément désynchronisés. | Exécutez l'automatisation sur le contrôleur de domaine détenant le rôle d'émulateur PDC, ou attendez la réplication et relancez. Utilisez la configuration manuelle si vous préférez ne pas dépendre du timing de réplication. |
L'exécution s'est terminée, mais aucun appareil n'apparaît dans Level | Le GPO est en place, mais l'installation ne s'est pas effectuée sur les clients. | Consultez le journal Application journal des événements sur un client pour les messages provenant de la source Level, puis consultez la FAQ ci-dessous. |
Vous n'avez pas besoin de supprimer le GPO avant de réessayer. Si un GPO Install Level Agent GPO existe déjà, le script le réutilise, supprime la tâche planifiée qu'il avait précédemment enregistrée, et continue. Une exécution interrompue prématurément laisse un GPO qui ne fait rien sur les clients, car le script n'avait pas encore enregistré la tâche planifiée dans la stratégie de groupe.
Méthode 2 : Configuration manuelle
Si vous préférez configurer le GPO vous-même, utilisez une tâche planifiée immédiate. Rien ici ne dépend de la réplication Active Directory ni des droits de création de GPO du compte au-delà de ce qu'un administrateur de domaine possède déjà, ce qui en fait l'option la plus fiable sur les domaines comptant plusieurs contrôleurs de domaine.
Étape 1 : Créer et lier le GPO
Ouvrez Gestion des stratégies de groupe.
Créez un nouveau GPO et liez-le à l'unité d'organisation appropriée dans Active Directory.
Étape 2 : Configurer la tâche planifiée
Modifiez le GPO et accédez à Configuration ordinateur → Préférences → Paramètres du panneau de configuration → Tâches planifiées.
Faites un clic droit et sélectionnez Nouvelle → Tâche immédiate (Au moins Windows 7).
Onglet Général :
Paramètre | Valeur |
Nom | Install Level Agent |
Utilisateur | SYSTEM |
Exécuter même si l'utilisateur n'est pas connecté | Activé |
Exécuter avec les privilèges les plus élevés | Activé |
Configurer pour | Windows 7, Windows Server 2008 R2 |
Onglet Actions :
Cliquez sur Nouveau et configurez l'action :
Champ | Valeur |
Programme/script |
|
Ajouter des arguments | Voir ci-dessous |
Dans le champ Ajouter des arguments champ, collez ce qui suit. Remplacez PUT_YOUR_LEVEL_KEY_HERE avec votre clé d'installation :
-ExecutionPolicy Bypass; $env:LEVEL_API_KEY = 'PUT_YOUR_LEVEL_KEY_HERE'; Set-ExecutionPolicy RemoteSigned -Scope Process -Force; [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; iwr -useb https://downloads.level.io/install_windows.ps1 | iex
Cliquez sur OK pour fermer l'action, puis OK à nouveau pour fermer les propriétés de la tâche.
Étape 3 : Attendre l'actualisation de la stratégie
Lors de la prochaine actualisation de la stratégie de groupe, la tâche planifiée s'exécute et l'agent Level est installé sur les appareils joints au domaine dans l'unité d'organisation liée. Les appareils apparaissent dans Level quelques secondes après la fin de l'installation.
ℹ️ REMARQUE : La configuration manuelle du GPO ne génère pas de messages dans le journal des événements Windows sur les machines clientes. Utilisez la méthode automatisée si vous avez besoin de journaliser l'activité d'installation à des fins de dépannage.
FAQ
Le GPO s'est exécuté mais les appareils n'apparaissent pas dans Level — que s'est-il passé ? Commencez par consulter le journal des événements Windows sur les clients concernés pour les messages du script d'installation de Level (méthode automatisée uniquement — ils apparaissent dans le journal Application journal sous la source Level). Causes fréquentes : le script PowerShell a été bloqué par une stratégie d'exécution, un outil AV/EDR a mis en quarantaine le téléchargement, ou l'appareil n'a pas pu atteindre
downloads.level.io. Voir Faux positifs AV/EDR et Dépannage hors ligne.Puis-je cibler une unité d'organisation spécifique plutôt que l'ensemble du domaine ? Pour la méthode automatisée, le script lie le GPO à la racine du domaine. Si vous avez besoin d'un ciblage au niveau de l'unité d'organisation, utilisez la méthode manuelle et liez le GPO à l'unité d'organisation spécifique.
Dois-je mettre à jour le GPO si ma clé d'installation change ? Oui. Mettez à jour la valeur
LEVEL_API_KEYdans les variables de l'automatisation (méthode automatisée) ou dans les arguments de la tâche planifiée (méthode manuelle).Qui peut exécuter la configuration GPO automatisée ? Deux autorisations distinctes sont impliquées. Dans Level, tout technicien ayant la permission d'exécuter des automatisations sur le contrôleur de domaine peut la lancer, et l'étape de validation par un administrateur vous offre un point de contrôle avant l'exécution du script. Dans Active Directory, le compte sous lequel s'exécute le script doit pouvoir créer des GPO — un Administrateur de domaine ou un membre des Propriétaires du groupe de stratégies. La valeur par défaut de l'étape de script Système local ne le peut généralement pas, ce qui explique pourquoi la configuration peut échouer avec
New-GPO : Access is deniedmême si l'automatisation elle-même s'est bien exécutée. Voir Avant d'exécuter l'automatisation.La configuration automatisée a échoué en cours d'exécution. Dois-je supprimer le GPO avant de réessayer ? Non. Si un GPO Install Level Agent GPO existe déjà, le script le réutilise et supprime la tâche planifiée qu'il avait précédemment enregistrée. Tant qu'une exécution n'est pas terminée, le GPO n'installe rien sur les clients, donc une exécution partielle est sans conséquence. Si l'échec était
Get-ADObject : Directory object not found, exécutez l'automatisation depuis l'émulateur PDC afin que la création et la relecture s'effectuent sur le même contrôleur de domaine.L'automatisation modifie-t-elle la façon dont l'agent s'installe sur les appareils clients ? Non. Le GPO qu'il crée exécute toujours l'installation en tant que SYSTEM avec les privilèges les plus élevés. Le paramètre Exécuter en tant que ne contrôle que le compte utilisé pour la configuration GPO unique sur le contrôleur de domaine.




