Perché i processi figlio WSH JScript falliscono quando lo script viene avviato da remoto? - Windows, Amazon-Web-Services, Psexec

Su una macchina standard Windows Server 2012 R2 (AWSIstanza EC2) Sto usando PsExec per avviare un processo su un computer remoto simile, fornendo le credenziali dell'utente. Il processo fallisce in vari modi che mi fanno sospettare le autorizzazioni: due comandi AWS CLI falliscono con i codici 255 (ses sendemail) o 2 (s3 cp) ed Excel si rifiuta di salvare un file, lamentandosi che non c'è spazio su disco.

Se accedo alla seconda macchina usando lo stessocredenziali ed eseguire lo stesso file .bat per avviare il processo, tutto viene eseguito come previsto. Il processo è un JScript WSH e viene eseguito in modo invisibile sotto cscript.exe con il suo output reindirizzato a un file.

Ho eseguito un comando SET tramite entrambi i metodi per vedere se gli ambienti erano diversi. C'erano quattro differenze, nessuna delle quali sembra rilevante:

• l'esecuzione locale ha CLIENTNAME = COMPAQ, il telecomando non ha quella variabile
• local ha una variabile SESSIONNAME (dall'esecuzione tramite mstsc), remote no
• TEMP e TMP hanno una sottodirectory 3 aggiuntiva aggiunta in locale ma non in remoto. Entrambe le versioni terminano con directory che vengono visualizzate come di sola lettura in Explorer.
• IL PERCORSO locale include C: USERSnome utente.dnxbin ma remote ha% USERPROFILE% invece di nome utente. In entrambi i casi non esiste tale directory.

Oggi ho provato il monitor di processo (grazie @ GamerJ5per il suggerimento) e salvato tutti gli eventi di Excel da un'esecuzione locale riuscita e un'esecuzione di avvio remoto non riuscita. Filtrare SUCCESS ha comunque lasciato qualche migliaio di risultati in ogni caso, senza alcuna chiara idea di quale dei tanti fallimenti potesse essere importante.

Qualcuno può suggerire quali tipi di richiesta / risultato potrebbero valere la pena di ulteriori indagini o qualsiasi altra cosa che posso esaminare?

risposte:

Nel caso in cui aiuti qualcun altro:si scopre che c'era una falsa pista nella domanda; gli errori dei due comandi AWS erano conseguenze indirette dell'errore di Excel. Questa è stata una conseguenza dell'ignorare il consiglio di Microsoft "Non eseguire Office su un server" (https://support.microsoft.com/en-us/kb/257757), ma una soluzione alternativa che ho trovato in un altro post (Microsoft Excel non può accedere al file "...". Esistono diversi motivi possibili per Windows Server 2008 R2 con Microsoft Office 2010) ha funzionato in questo caso: creare la directory che Excel si aspetta di trovare in WindowsSystem32configsystemprofileDesktop.