Utilizza questo articolo per aiutarti a risolvere gli errori di script.

Risoluzione dei problemi di errore di script

Passaggi per la risoluzione dei problemi generali di script che non funzionano.

1. Verifica se il dispositivo è reattivo. Questo può essere fatto aprendo moduli come Task Manager, Service manager, ecc. Se questi non funzionano, potrebbero esserci problemi di rete tra l'agente e i nostri server. Si prega di leggere l'articolo Troubleshoot the Atera Agent (Windows) per ulteriori dettagli su come risolvere gli errori di comunicazione.

2. Verifica se lo script in Atera utilizza il corretto Tipo di File. Se lo script in Atera utilizza il tipo di file sbagliato, fallirà, quindi ricrea lo script utilizzando il tipo corretto.

3. Se lo script include file di installazione *.exe o *.msi, verifica che siano stati aggiunti i parametri corretti per l'installazione silenziosa. Gli script eseguiti tramite Atera vengono eseguiti in modalità silenziosa sui dispositivi Windows, quindi quando si includono file di installazione, potrebbe essere necessario aggiungere parametri allo script per specificare l'installazione silenziosa del programma. Se lo script non è configurato per includere l'argomento necessario per un'installazione silenziosa, verrà eseguito senza un'interfaccia grafica, impedendo all'utente finale di interagire con la procedura guidata di installazione e causando infine il fallimento dello script. 

4. Modifica il modo in cui i diritti dello script vengono inviati dalla console Atera – Utente corrente o Sistema e riesegui lo script sullo stesso dispositivo.

5. Controlla i codici di uscita dello script. Questi sono i codici di uscita più comuni che incontrerai quando esegui script batch.

Per gli script Powershell, l'output ti fornirà le informazioni necessarie riguardo al problema. I codici di uscita più comuni:

6. Assicurati che lo script funzioni bene sulla macchina locale. Se questo fallisce, il problema è lo script stesso.

• Nel caso in cui lo script richieda diritti di amministratore, puoi provare a eseguire lo script in Atera utilizzando "Sistema".
  Tuttavia, l'account di sistema ha alcune limitazioni, vedi la sezione Sessione 0. Come soluzione alternativa, esegui lo script come "Utente corrente" e assicurati che l'utente abbia diritti di amministratore su quella macchina.
• Se lo script funziona bene localmente, con o senza diritti di amministratore, passa al passaggio successivo.

7. Contatta il team di supporto di Atera e fornisci al nostro team le seguenti informazioni.

• Fornisci al nostro team di supporto uno screenshot dell'output quando esegui lo script localmente, sia con diritti di amministratore che senza.
• Lo script che stai cercando di eseguire, una breve spiegazione di cosa dovrebbe ottenere, insieme all'output da Atera e dalla macchina locale dello script.

Impossibile scaricare lo script dal repository di Atera

Per risolvere questo errore, esegui i comandi seguenti sul tuo 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

Nel caso in cui il problema persista, contatta il nostro team di supporto.

Risoluzione dei problemi dello script dalla Libreria Condivisa

Quando si tratta di script scaricati dalla libreria condivisa, possiamo solo suggerire le seguenti azioni.

• Verifica se il tipo di file è corretto.
• Testa lo script sia come Sistema che come Utente corrente.

Il nostro team di supporto non gestisce/risolve problemi degli script dalla Libreria di Script Condivisi, gli script sono controllati solo per maliciousness e non per funzionalità.

Nel caso in cui tu abbia problemi con uno script dalla Libreria di Script Condivisi, contatta il creatore dello script per assistenza.

Sessione 0 di Windows

Cos'è la Sessione 0 di Windows e perché è importante?

La Sessione 0 di Windows è una sessione specializzata di Windows in cui tutti gli aspetti del software, inclusi i componenti GUI interattivi (pop-up, finestre di dialogo) e molti altri aspetti, vengono inizializzati in completa isolamento dalla tua sessione normale di accesso.

Questa separazione è intenzionale, progettata e applicata dal sistema operativo. Questo isolamento è stato avviato con Windows Vista/Server 2008 per mitigare varie preoccupazioni di sicurezza.

Breve storia:

• Windows NT (1993)
  Nasce il concetto di sessioni di login multiple. La Sessione 0 viene creata all'avvio e il primo utente che effettua il login viene posizionato nella Sessione 0.
• Windows Vista (2007)
  Per mitigare vari exploit, MS proibisce agli utenti di effettuare il login nella Sessione 0. Viene creato il "Servizio di rilevamento dei servizi interattivi" che consente agli amministratori di accedere temporaneamente alla Sessione 0. Il primo utente che effettua il login prenderà la Sessione 1.
• Windows 8 & Windows Server 2012
  Il Servizio di rilevamento interattivo è disabilitato per impostazione predefinita. Questo impedisce a chiunque di passare alla Sessione 0 (a meno che non venga aggiornato un valore del registro).
• Windows 10 & Windows Server 2016
  I dispositivi I/O non funzionano più nella Sessione 0. Questo comportamento era considerato un bug, ma chiaramente era un'azione deliberata intesa a prevenire l'interazione con la Sessione 0.
• Windows 10, versione 1803 (2018)
  Il servizio di rilevamento dei servizi interattivi è ufficialmente rimosso. Il passaggio alla Sessione 0 è vietato.

Perché è importante per Atera?

Poiché il nostro agente è un servizio che genera un processo, la maggior parte dei nostri processi inizia sotto la Sessione 0, quindi non verranno visualizzati ai tuoi utenti finali. Inoltre, AteraAgent viene eseguito come l'account di Windows integrato "NT Authority/System" per sfruttare i suoi permessi.

Ok - quindi come potrebbe apparire questo in uno scenario reale? Prendiamo un esempio comune:
Esegui uno script .bat sulla macchina del tuo utente finale da Atera, dovrebbe creare una finestra di dialogo in attesa che l'utente clicchi su "Ok" o "Annulla". Se lo script viene eseguito come "NT Authority/System", l'applicazione ora attende un input nel pop-up, ma l'interfaccia utente non viene visualizzata nella sessione utente.

Dal punto di vista dell'utente, l'applicazione sembra bloccata/congelata, mentre si comporta perfettamente normalmente e attende una risposta dell'utente che l'utente non può vedere.

Come avrai già notato, questo presenta un problema. Come soluzione alternativa, puoi eseguire lo script come "Utente corrente", oppure puoi sfruttare "Runas"