Résolution des problèmes : Scripts

Utilisez cet article pour vous aider à dépanner les erreurs de script.

• Dépannage d'une erreur de script
• Échec du téléchargement du script à partir du dépôt d'Atera
• Demandes de création de script
• Dépannage d'un script à partir de la bibliothèque partagée
• Session Windows 0

Dépannage d'un script défectueux

Étapes de dépannage en cas d'échec du script général.

1. Vérifiez si le périphérique est réactif. Pour ce faire, ouvrez des modules tels que le Gestionnaire des tâches, le Gestionnaire de services, etc. Si ces modules ne fonctionnent pas, il peut y avoir des problèmes de réseau entre l'agent et nos serveurs. Veuillez lire l'article Dépannage de l'agent Atera (Windows) pour plus de détails sur la façon de résoudre les erreurs de communication.

2. Vérifiez si le script d'Atera utilise le bon type de fichier. Si le script dans Atera utilise le mauvais type de fichier, il échouera, donc recréez le script en utilisant le bon type.

3. Changez la façon dont les droits du script sont envoyés depuis la console Atera - Utilisateur actuel ou Système et exécutez à nouveau le script sur le même appareil.

4. Vérifiez les codes de sortie du script. Voici les codes de sortie les plus courants, que vous rencontrerez lors de l'exécution de scripts batch.

Pour les scripts Powershell, la sortie vous fournira les informations nécessaires concernant le problème. Les codes de sortie les plus courants :

5. Assurez-vous que le script s'exécute bien sur la machine locale. Si cela échoue, le problème vient du script lui-même.

• Si le script nécessite des droits d'administrateur, vous pouvez essayer de l'exécuter dans Atera en utilisant "Système".
  Cependant, le compte système a certaines limitations, voir la section Session 0. Comme solution de rechange, exécutez le script en tant que "Current user", et assurez-vous que l'utilisateur a des droits d'administrateur sur cette machine.
• Si le script fonctionne bien localement, avec ou sans droits d'administrateur, passez à l'étape suivante.

6. Contactez l'équipe d'assistance d'Atera, et fournissez à notre équipe les informations suivantes.

• Fournissez à notre équipe d'assistance une capture d'écran du résultat de l'exécution du script en local, avec ou sans droits d'administrateur.
• Le script que vous essayez d'exécuter, une brève explication de ce qu'il est censé accomplir, ainsi que la sortie d'Atera et de la machine locale du script.

Impossible de télécharger le script du dépôt d'Atera

Afin de corriger cette erreur, veuillez exécuter les commandes ci-dessous sur votre appareil.

reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\ATERA Networks\AlphaAgent" /v AccountId /f
rmdir "C:\Program Files\ATERA Networks\AteraAgent\Packages\AgentPackageSystemTools" /s /q
rmdir "C:\Program Files (x86)\ATERA Networks\AteraAgent\Packages\AgentPackageSystemTools" /s /q

Si le problème persiste, veuillez contacter notre équipe d'assistance.

Demandes de création de script

Pour les tickets où un client demande la création d'un script à l'équipe de support, informez-le que ce n'est pas un service que nous offrons.

Dépannage d'un script provenant d'une bibliothèque partagée

Lorsqu'il s'agit de scripts qui ont été téléchargés à partir de la bibliothèque partagée, nous ne pouvons que suggérer les actions suivantes.

• Vérifiez que le type de fichier est correct.
• Testez le script en tant que système et utilisateur actuel.

Notre équipe d'assistance ne gère pas et ne dépanne pas les scripts de la bibliothèque de scripts partagée, les scripts sont examinés uniquement pour leur malveillance et non pour leur fonctionnalité.

Si vous avez des problèmes avec un script de la bibliothèque partagée de scripts, veuillez contacter le créateur du script pour obtenir de l'aide.

Session Windows 0

Qu'est-ce que la session 0 de Windows et pourquoi est-ce important ?

La session Windows 0 est une session Windows spécialisée dans laquelle tous les aspects du logiciel, y compris les composants interactifs de l'interface graphique (pop-ups, boîtes de dialogue) et bien d'autres aspects, sont initialisés de manière totalement isolée de votre session normale.

Cette séparation est intentionnelle, par conception et imposée par le système d'exploitation. Cette isolation a été lancée avec Windows Vista/Server 2008 afin d'atténuer divers problèmes de sécurité.

Bref historique :

• Windows NT (1993)
  Le concept de sessions de connexion multiples voit le jour. La session 0 est créée au démarrage, et le premier utilisateur à se connecter est placé dans la session 0.
• Windows Vista (2007)
  Pour limiter les exploits, MS interdit aux utilisateurs de se connecter à la session 0. Le "service de détection des services interactifs" est créé pour permettre aux administrateurs d'accéder temporairement à la session 0. Le premier utilisateur qui se connecte prend la session 1.
• Windows 8 & Windows Server 2012
  Le service de détection des services interactifs est désactivé par défaut. Cela empêche quiconque de passer à la session 0 (sauf si une clé de registre est mise à jour).
• Windows 10 & Windows Server 2016
  Les périphériques d'E/S ne fonctionnent plus en session 0. On pensait que ce comportement était un bogue, mais manifestement, il s'agissait d'une action délibérée visant à empêcher toute interaction avec la session 0.
• Windows 10, version 1803 (2018)
  Le service de détection des services interactifs est officiellement supprimé. Le passage à la session 0 est interdit.

Pourquoi est-ce important pour Atera ?

Étant donné que notre agent est un service qui spawn un processus, la plupart de nos processus démarrent sous Session 0, et ne seront donc pas affichés à vos utilisateurs finaux. De plus, AteraAgent est exécuté en tant que compte Windows intégré "NT Authority/System" afin de tirer parti de ses permissions.

Ok - alors, à quoi cela peut-il ressembler dans un scénario réel ? Prenons un exemple courant :
Vous exécutez un script .bat sur la machine de votre utilisateur final à partir d'Atera, il est censé créer une boîte de dialogue dans laquelle l'utilisateur doit cliquer sur "Ok" ou "Annuler". Si le script s'exécute en tant que "Autorité NT/Système", l'application attend maintenant une entrée dans la fenêtre pop-up, mais l'interface utilisateur n'est pas affichée dans la session de l'utilisateur.

Du point de vue de l'utilisateur, l'application semble bloquée, alors qu'elle se comporte parfaitement normalement et qu'elle attend une réponse de l'utilisateur que ce dernier ne peut pas voir.


Comme vous l'avez déjà remarqué, cela pose un problème. Comme solution de rechange, vous pouvez soit exécuter le script en tant que "Current User", soit tirer parti de "Runas".