Uruchom program przy uruchamianiu komputera, gdy nikt nie jest zalogowany, i wyświetl okno, gdy ktoś się zaloguje (system operacyjny: Windows)

Mam program uruchamiany podczas uruchamiania systemu za pomocą Harmonogramu zadań w systemie Windows Server 2012. Program musi zostać uruchomiony, nawet jeśli komputer uruchomi się ponownie automatycznie.

Administrator jest kontem używanym do uruchamiania programu, dla zadania zaznaczona jest opcja „Uruchom niezależnie od tego, czy użytkownik jest zalogowany”.

Problem polega na tym, że gdy ktoś w końcu zaloguje się jako Administrator za pomocą Podłączania pulpitu zdalnego, interfejs (okno programu) jest ukryty.

Jak rozumiem, nie ma sposobu, aby rozwiązać ten problem za pomocą Harmonogramu zadań.

Jak mogę to rozwiązać?

Powinien to być dość powszechny problem, ale nie mogę nic znaleźć, przeszukując sieć. Jestem dość zaskoczony, że Microsoft zezwala na takie ograniczenie w swoim harmonogramie. Czy mogę stworzyć VBScript lub coś, co działa podczas uruchamiania i uruchamia program, który będzie widoczny po zalogowaniu się użytkownika?

Inne pomysły?

(Nie chcę tworzyć osobnego programu opartego tylko na interfejsie GUI, który nawiasem mówiąc, łączy się z oryginalnym programem. Wolałbym również, jeśli nie muszę kończyć już działającego programu po zalogowaniu użytkownika, a następnie uruchomić to znowu.)

Zrozumiałem, jak to zrobić sam. Jest to trochę obejście, ale tego się spodziewałem.

• Dobra, pierwszym krokiem jest pobranie programu o nazwie AutoLogon.exe z Microsoft:
  http://technet.microsoft.com/sv-se/sysinternals/bb963905.aspx

Zatrzymać! Nie maruduj jeszcze. Czytaj...

• Uruchom go, ustaw tak, aby Administrator automatycznie się logował.

• Utwórz zadanie w Harmonogramie zadań. Ustaw, aby działał tylko wtedy, gdy użytkownik (Administrator) jest zalogowany. Trigger jest „przy logowaniu” i określa, że ​​dzieje się tak tylko wtedy, gdy administrator się loguje.

• Utwórz drugie zadanie. Uruchom tylko wtedy, gdy użytkownik jest zalogowany, uruchom przy logowaniu administratora. Akcją powinno być „uruchomienie programu”, a programem jest „C: \ Windows \ System32 \ rundll32.exe” z polem argumentów ustawionym na „user32.dll, LockWorkStation”.

Co się stanie teraz, jeśli ponownie uruchomisz komputer, administrator automatycznie się zaloguje, program, który chcesz uruchomić, zostanie uruchomiony, a stacja robocza zostanie zablokowana. Jeśli zaloguję się za pomocą Podłączania pulpitu zdalnego, zobaczę okno programu i korzystam z GUI. Mogę bez problemu blokować / odblokowywać komputer i dowolnie rozłączać / podłączać ponownie. Nie ma problemu, jeśli pójdę na serwer i zaloguję się na rzeczywistej stacji roboczej. Ponieważ Administrator jest już zalogowany, zadanie nie uruchomi się ponownie (nie tworzy nieskończonej pętli logowania i blokady, z której nie można się wydostać).

Proste. To prawda, że ​​przed automatycznym zalogowaniem komputer ma blokadę na sekundę i wydaje mi się, że pro haker z fizycznym dostępem do komputera może zrobić coś podstępnego w tym oknie czasowym, ale w moim przypadku mogę przeoczyć to ryzyko bezpieczeństwa. Dopóki nie wpuszczę żadnych profesjonalnych hakerów do mojego domu i nie pokażę im komputera, system powinien być względnie bezpieczny. Przede wszystkim nie ma tak dużej wartości na komputerze, który wymaga ochrony super-repozytorium, więc jestem całkiem zadowolony z tego rozwiązania.

Mam program uruchamiany podczas uruchamiania systemu za pomocą Harmonogramu zadań w systemie Windows Server 2012. Program musi zostać uruchomiony, nawet jeśli komputer uruchomi się ponownie automatycznie.

Dlaczego więc nie uczynić go usługą systemową, jak definiują specyfikacje systemu Windows?

Jak mogę to rozwiązać?

Nie możesz. Programy działające w tle nie powinny wchodzić w interakcje z interfejsem użytkownika. Lub: interfejs użytkownika powinien uruchomić własny program, który następnie łączy się z usługą. Interfejs użytkownika działający w przestrzeni użytkownika zalogowanego użytkownika wykonuje prezentację, usługa Windows wykonuje przetwarzanie. W ten sposób model jest zaprojektowany na około 15 lat.

Jestem dość zaskoczony, że Microsoft zezwala na takie ograniczenie w swoim harmonogramie.

Jestem bardziej zaskoczony, że nigdy nie pytałeś dlaczego.

Istnieje wiele problemów:

• Kto jest zalogowany, gdy zalogowanych jest wiele osób?
• Kiedy użytkownik się wylogowuje, zabijasz program? AUĆ.
• Bezpieczeństwo. Program działający w tle może działać z ograniczonymi prawami - ujawnienie interfejsu użytkownika użytkownikowi oznacza, że ​​użytkownik może tam wykonać kod. Model przesyłania wiadomości w systemie Windows jest - ah - pełen problemów.

Nie chcę tworzyć osobnego programu zawierającego tylko GUI, który nawiasem mówiąc, łączy się z oryginalnym programem.

Ani ja, ani Microsoft nie dba w tym momencie o to, co lubisz robić. Istnieje ustalony i obsługiwany model umożliwiający powiązanie przetwarzania w tle z zalogowanym interfejsem użytkownika - użyj go lub nie. Ale kiedy nie, nie narzekaj na zgłaszane problemy bezpieczeństwa.

Chodzi o to Session, w którym program się uruchamia. Jeśli nikt nie jest zalogowany, nie ma interaktywnej sesji do wyświetlenia, myślę, że działa pod Session 0, który ma dziwny interfejs użytkownika, który nie wyświetla się tak jak inne.

Teraz, jeśli Twój program wykryje explorer.exeuruchomienie (lub inny sposób wykrycia loginu użytkownika) i magicznie zmieni się na nowo lub stworzy proces potomny na tym nowym sessionid, każdy, kto się zaloguje, z przyjemnością zobaczy, co robisz.