Utilisez cet article pour vous aider à résoudre les erreurs de script.

Résoudre les échecs de script

Étapes de dépannage pour un échec général de script.

1. Vérifiez si l'appareil est réactif. Cela peut être fait en ouvrant des modules comme le Gestionnaire des tâches, le Gestionnaire de services, etc. Si ceux-ci ne fonctionnent pas, il pourrait y avoir des problèmes de réseau entre l'agent et nos serveurs. Veuillez lire l'article Dépanner 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 dans Atera utilise le bon Type de fichier. Si le script dans Atera utilise le mauvais type de fichier, il échouera, alors recréez le script en utilisant le bon type.

3. Si le script inclut des fichiers d'installation *.exe ou *.msi, vérifiez que les arguments appropriés ont été ajoutés pour une installation silencieuse. Les scripts exécutés via Atera sont exécutés silencieusement sur les appareils Windows, donc lors de l'inclusion de fichiers d'installation, vous devrez peut-être ajouter des paramètres au script pour spécifier l'installation silencieuse du programme. Si le script n'est pas configuré pour inclure le(s) argument(s) nécessaire(s) pour une installation silencieuse, il s'exécutera sans interface graphique, empêchant l'utilisateur final d'interagir avec l'assistant d'installation et provoquant finalement l'échec du script. 

4. Modifiez 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.

5. 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 :

6. Assurez-vous que le script fonctionne 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 contournement, exécutez le script en tant qu'"Utilisateur actuel", et assurez-vous que l'utilisateur dispose des droits d'administrateur sur cette machine.
• Si le script fonctionne bien localement, avec ou sans droits d'administrateur, passez à l'étape suivante.

7. Contactez l'équipe de support Atera et fournissez à notre équipe les informations suivantes.

• Fournissez à notre équipe de support une capture d'écran du résultat lors de l'exécution du script localement, à la fois avec et 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 le résultat d'Atera et de la machine locale du script.

Échec du téléchargement du script depuis le dépôt d'Atera

Pour 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 de support.

Dépannage du script depuis la bibliothèque partagée

En ce qui concerne les scripts téléchargés depuis la bibliothèque partagée, nous ne pouvons que suggérer les actions suivantes.

• Vérifiez si le type de fichier est correct.
• Testez le script soit en tant que Système, soit en tant qu'Utilisateur actuel.

Notre équipe de support ne gère pas/ne dépanne pas les scripts de la bibliothèque de scripts partagés, les scripts sont uniquement vérifiés pour leur malveillance et non pour leur fonctionnalité.

En cas de problème avec un script de la bibliothèque de scripts partagés, veuillez contacter le créateur du script pour obtenir de l'aide.

Session Windows 0

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

La Session Windows 0 est une session Windows spécialisée où tous les aspects du logiciel, y compris les composants GUI interactifs (pop-ups, boîtes de dialogue) et de nombreux autres aspects, sont initialisés en complète isolation de votre session normale connectée.

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

Brève histoire :

• 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 atténuer diverses exploitations, MS interdit aux utilisateurs de se connecter à la session 0. Le "service de détection des services interactifs" est créé, permettant aux administrateurs d'accéder temporairement à la session 0. Le premier utilisateur à se connecter prendra la session 1.
• Windows 8 & Windows Server 2012
  Le service de détection interactive 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 dans la session 0. Ce comportement était considéré comme un bug, mais il s'agissait clairement d'une action délibérée visant à empêcher l'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 génère un processus, la plupart de nos processus démarrent sous la session 0, de sorte qu'ils ne seront pas affichés à vos utilisateurs finaux. De plus, AteraAgent fonctionne sous le compte Windows intégré "NT Authority/System" afin de tirer parti de ses autorisations.

D'accord - à quoi cela pourrait-il réellement ressembler dans un scénario réel ? Prenons un exemple courant :
Vous exécutez un script .bat sur la machine de votre utilisateur final depuis Atera, il est censé créer une boîte de dialogue attendant que l'utilisateur clique sur "Ok" ou "Annuler". Si le script s'exécute en tant que "NT Authority/System", l'application attend maintenant une entrée sur le pop-up, mais l'interface utilisateur n'est pas affichée dans la session utilisateur.

Du point de vue de l'utilisateur, l'application semble être bloquée/gelée, alors qu'elle se comporte parfaitement normalement et attend une réponse de l'utilisateur que celui-ci ne peut pas voir.

Comme vous l'avez déjà remarqué, cela pose un problème. Comme solution de contournement, vous pouvez soit exécuter le script en tant que "Utilisateur actuel", soit profiter de "Runas"