Avviare il programma all'avvio del computer quando nessuno è connesso e mostrare la window quando qualcuno accede (OS: Windows)

Ho un programma che viene lanciato all'avvio del sistema utilizzando Task Scheduler su Windows Server 2012. Il programma deve iniziare anche se il computer si riavvia automaticamente.

L'amministratore è l'account utilizzato per avviare il programma, l'opzione "Esegue se l'utente è connesso o no" è selezionato per l'attività.

  • Perché lo schermo di accesso RDS varia in base all'utente e al PC?
  • Se eseguire il backup di un host HyperV, dovrei eseguire il backup degli ospiti?
  • Blocco dell'account dopo un singolo errore di authentication
  • Alternative a Splunk?
  • Come faccio a fare un servizio dipendente da un altro in Windows 7?
  • Configurare SCCM in modo che i file con un simbolo più (+) nel nome file possano essere scaricati dal punto di distribuzione
  • Il problema con questo è che quando qualcuno finalmente accede come amministratore utilizzando Remote Desktop Connection l'interface (window del programma) è nascosta.

    Come ho capito, non è ansible risolvere questo problema utilizzando Task Scheduler.

    Come posso risolvere questo?

    Dovrebbe essere un problema abbastanza comune ma non riesco a trovare qualcosa cercando la networking. Sono abbastanza sorpreso che Microsoft permetta una tale limitazione nel loro scheduler. Posso fare un VBScript o qualcosa che viene eseguito all'avvio e lancio il programma che sarà visibile quando l'utente effettua l'accesso?

    Altre idee?

    (Non voglio fare un programma separato GUI che si connette al programma originale, preferisco anche se non dovrei terminare il programma già in esecuzione dopo l'accesso agli utenti e quindi lanciare nuovamente.)

    3 Solutions collect form web for “Avviare il programma all'avvio del computer quando nessuno è connesso e mostrare la window quando qualcuno accede (OS: Windows)”

    Figura come farlo io stesso. È un po 'di una soluzione, ma è quello che mi aspettavo di get.

    Stop! Non cringe ancora. Continuare a leggere…

    • Eseguirlo, impostarlo in modo che l'amministratore dovrebbe accedere automaticamente.

    • Creare un'attività in Task Scheduler. Impostarlo per eseguire solo quando l'utente (amministratore) è connesso. Trigger è "al momento del login" e specifica che è solo quando l'amministratore accede.

    • Crea una seconda attività. Esegui solo quando l'utente è connesso, innescare il log di amministratore. L'azione dovrebbe essere "avviare un programma" e il programma è "C: \ Windows \ System32 \ rundll32.exe" con il field di argomento impostato su "user32.dll, LockWorkStation".

    Quello che succede ora se riavvii il computer è che l'amministratore si accede automaticamente, il programma che si desidera avviare viene avviato e la postazione di lavoro viene bloccata. Se accedo tramite Connessione Desktop remoto, posso vedere la window del programma e utilizzare la GUI. Posso bloccare / sbloccare il computer senza alcun problema e scolbind / ricolbind come mi piace. Non esiste alcun problema se vado al server e accedi alla workstation effettiva. Poiché l'amministratore è già stato firmato, l'attività non verrà eseguita nuovamente (non crea un ciclo di accesso log-in-lock infinito che non è ansible eliminare).

    Semplice come quella. Dato che c'è un secondo periodo di tempo prima che il computer si blocca dopo l'accesso automatico e suppongo che un pro hacker con accesso fisico al computer potrebbe fare qualcosa di sneaky durante questa window temporale ma nel mio caso posso trascurare quel rischio di sicurezza. Finché non lascio che pro hacker pro nella mia casa e mostrare loro il computer il sistema dovrebbe essere relativamente sicuro. Soprattutto non c'è molto di valore sul computer che ha bisogno di protezione super-cassa, quindi sono abbastanza soddisfatto di questa soluzione.

    Ho un programma che viene lanciato all'avvio del sistema utilizzando Task Scheduler su Windows Server 2012. Il programma deve iniziare anche se il computer si riavvia automaticamente.

    Allora perché non lo fai un servizio di sistema, come definisce le windows?

    Come posso risolvere questo?

    Non puoi. I programmi di background non dovrebbero interagire con l'interface utente. Oppure: l'UI dovrebbe eseguire il proprio programma che si connette al servizio. L'interface utente che esegue lo spazio utente dell'utente registrato fa la presentazione, il servizio Windows esegue l'elaborazione. Questo è il modo in cui il model è stato progettato per forse 15 anni o giù di lì.

    Sono abbastanza sorpreso che Microsoft permetta una tale limitazione nel loro scheduler.

    Sono più sorpreso che non ti abbia mai domandato perché.

    Esistono più problemi:

    • Quando si registrano più persone, chi ottiene l'interface utente?
    • Quando l'utente si disconnette, uccidi il programma? AHIA.
    • Sicurezza. Il programma di background può essere eseguito con diritti limitati: esponendo l'interface utente all'utente significa che l'utente può eseguire codice. Il model di messaggistica di Windows è – ah – pieno di problemi.

    Non voglio fare un programma separato GUI che si connette al programma originale dal modo giusto.

    Né io né Microsoft si preoccupa a questo punto che cosa ti piace fare. C'è un model consolidato e supportto per bind l'elaborazione di background in un utente registrato UI – utilizzarlo o no. Ma quando no, non complilare i problemi di sicurezza che hai posto.

    Tutto è della Session cui il programma viene eseguito. Se nessuno è connesso, non esiste una session intertriggers da visualizzare, credo che funziona sotto Session 0 , che ha un UI strano che non si presenta come gli altri.

    Ora, se il tuo programma rileva quando explorer.exe lancia (o un altro modo per rilevare l'accesso utente) e magicamente si è rimbosso o ha generato qualche process figlio in quella nuova sessionid, chiunque che accede vedrà felicemente cosa stai facendo.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.