Utilice este artículo para ayudarle a solucionar errores de script.

Solucionar fallos de script

Pasos para solucionar fallos generales de script.

1. Verifique si el dispositivo es receptivo. Esto se puede hacer abriendo módulos como el Administrador de tareas, el Administrador de servicios, etc. Si estos no funcionan, podría haber problemas de red entre el agente y nuestros servidores. Por favor, lea el artículo Solucionar problemas del agente de Atera (Windows) para obtener más detalles sobre cómo resolver errores de comunicación.

2. Verifique si el script en Atera utiliza el Tipo de archivo correcto. Si el script en Atera utiliza el tipo de archivo incorrecto, fallará, por lo que debe recrear el script utilizando el tipo correcto.

3. Si el script incluye archivos de instalación *.exe o *.msi, verifique que se hayan agregado los argumentos adecuados para la instalación silenciosa. Los scripts ejecutados a través de Atera se ejecutan de manera silenciosa en dispositivos Windows, por lo que al incluir archivos de instalación, es posible que deba agregar parámetros al script para especificar la instalación silenciosa del programa. Si el script no está configurado para incluir el(los) argumento(s) necesario(s) para una instalación silenciosa, se ejecutará sin una interfaz gráfica, impidiendo que el usuario final pueda interactuar con el asistente de instalación y, en última instancia, causando que el script falle. 

4. Cambie cómo se envían los derechos del script desde la consola de Atera: Usuario actual o Sistema y ejecute el script nuevamente en el mismo dispositivo.

5. Verifique los códigos de salida del script. Estos son los códigos de salida más comunes que encontrará al ejecutar scripts por lotes.

Para scripts de Powershell, la salida le proporcionará la información necesaria sobre el problema. Los códigos de salida más comunes:

6. Asegúrese de que el script se ejecute bien en la máquina local. Si esto falla, el problema es el propio script.

• En caso de que el script requiera derechos de administrador, puede intentar ejecutar el script en Atera usando "Sistema".
  Sin embargo, la cuenta del sistema tiene ciertas limitaciones, consulte la sección Sesión 0. Como solución alternativa, ejecute el script como "Usuario actual" y asegúrese de que el usuario tenga derechos de administrador en esa máquina.
• Si el script se ejecuta bien localmente, con o sin derechos de administrador, pase al siguiente paso.

7. Contacte al equipo de soporte de Atera y proporcione a nuestro equipo la siguiente información.

• Proporcione a nuestro equipo de soporte una captura de pantalla del resultado al ejecutar el script localmente, tanto con derechos de administrador como sin ellos.
• El script que intenta ejecutar, una breve explicación de lo que se supone que debe lograr, junto con el resultado de Atera y de la máquina local del script.

Error al descargar el script del repositorio de Atera

Para solucionar este error, ejecute los siguientes comandos en su dispositivo.

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

En caso de que el problema persista, comuníquese con nuestro equipo de soporte.

Solucionar problemas del script de la Biblioteca Compartida

Cuando se trata de scripts que se descargaron de la biblioteca compartida, solo podemos sugerir las siguientes acciones.

• Verifique si el tipo de archivo es correcto.
• Pruebe el script tanto como Sistema como Usuario actual.

Nuestro equipo de soporte no gestiona/soluciona problemas de scripts de la Biblioteca de Scripts Compartidos, los scripts solo se revisan por malicia y no por funcionalidad.

En caso de que tenga problemas con un script de la Biblioteca de Scripts Compartidos, comuníquese con el creador del script para obtener asistencia.

Sesión 0 de Windows

¿Qué es la Sesión 0 de Windows y por qué es importante?

La Sesión 0 de Windows es una sesión especializada de Windows donde todos los aspectos del software, incluidos los componentes GUI interactivos (ventanas emergentes, cuadros de diálogo) y muchos otros aspectos, se inicializan en completo aislamiento de su sesión normal iniciada.

Esta separación es intencional, por diseño, y es impuesta por el sistema operativo. Este aislamiento comenzó con Windows Vista/Server 2008 para mitigar diversas preocupaciones de seguridad.

Breve historia:

• Windows NT (1993)
  Nace el concepto de múltiples sesiones de inicio de sesión. La Sesión 0 se crea al arrancar, y el primer usuario que inicia sesión se coloca en la Sesión 0.
• Windows Vista (2007)
  Para mitigar varios exploits, MS prohíbe a los usuarios iniciar sesión en la Sesión 0. Se crea el "Servicio de Detección de Servicios Interactivos" que permite a los administradores acceder temporalmente a la Sesión 0. El primer usuario que inicie sesión tomará la Sesión 1.
• Windows 8 & Windows Server 2012
  El Servicio de Detección Interactiva está deshabilitado por defecto. Esto impide que cualquiera cambie a la Sesión 0 (a menos que se actualice una clave de registro).
• Windows 10 & Windows Server 2016
  Los dispositivos de E/S ya no funcionan en la Sesión 0. Este comportamiento se pensó que era un error, pero claramente fue una acción deliberada destinada a prevenir la interacción con la Sesión 0.
• Windows 10, versión 1803 (2018)
  El servicio de Detección de Servicios Interactivos se elimina oficialmente. Cambiar a la Sesión 0 está prohibido.

¿Por qué es esto importante para Atera?

Dado que nuestro agente es un servicio que genera un proceso, la mayoría de nuestros procesos comienzan bajo la Sesión 0, por lo que no se mostrarán a sus usuarios finales. Además, AteraAgent se ejecuta como la cuenta integrada de Windows "NT Authority/System" para aprovechar sus permisos.

Bien, entonces, ¿cómo podría ser esto en un escenario del mundo real? Tomemos un ejemplo común:
Ejecutas un script .bat en la máquina de tu usuario final desde Atera, se supone que debe crear un cuadro de diálogo esperando que el usuario haga clic en "Aceptar" o "Cancelar". Si el script se ejecuta como "NT Authority/System", la aplicación ahora está esperando una entrada en el pop-up, pero la interfaz de usuario no se muestra en la sesión del usuario.

Desde la perspectiva del usuario, la aplicación parece estar colgada/congelada, mientras que se está comportando perfectamente normal, y está esperando una respuesta del usuario que el usuario no puede ver.

Como ya has notado, esto presenta un problema. Como solución, puedes ejecutar el script como "Usuario Actual", o puedes aprovechar "Runas"