Beiträge von misterspeed

    Naja da dort Linux läuft und das "terminal" vermutlich nix anderes ist als eine webbasierte SSH Verbindung würde ich die Webautomatisierung komplett weglassen und direkt per SSH zugreifen. Putty sollte entsprechend automatisierbar sein um sowohl login, als auch reboot zu bewerkstelligen, ganz ohne fehleranfällige Tastatur Emulation oder Webseitenautomatisierung.


    EDIT:

    Plink aus dem Putty Paket sollte das können was du brauchst

    https://www.thegeekstuff.com/2017/05/putty-plink-examples/ (siehe Punkt 3)

    https://the.earth.li/~sgtatham….60/htmldoc/Chapter7.html (siehe Parameter zur PW Übergabe)

    Edit: Ach du scheiße - was hab ich denn hier für ne Threadleiche ausgegraben? - der Thread ist ja zwei Jahre alt - wie kam der denn auf meine Startseite?

    Vielleicht kam die Sortierfunktion des Forums mit dem Threaddatum durcheinander *hust*

    Oder du lebst einfach in der Vergangenheit und hattest im Moment des Antwortens eine "Schalt-mich-in-die-Gegenwart" Sekunde.

    Ich schlage vor wir suchen die Antwort in 400 Jahren und lassen den Thread bis dahin in der Vergangenheit.

    "psexec" mag normalerweise vielleicht möglich sein, wenn sich Quell und Ziel PC im selben Netzwerk befinden und andere Vorraussetzungen (Gruppenrichtlinien, Firewall, Virenschutz) dafür erfüllt sind. Hier ist das aufgrund von Home Office und mangelnder VPN Verbindung aber nicht gegeben.

    Da wir auch schon ein ähnliches Problem hatten und dem Benutzer das lokale Administrator Passwort nicht einfach so mitteilen konnten:


    Du könntest per Teamviewer im Usercontext zugreifen.


    Danach lädst du ein kleines Autoitscript hoch, welches hardcodierte Daten des lokalen Administrators enthält und via runas dort einen temporären Adminuser anlegt, dessen Daten du dann bedenkenlos dem User mitteilen kannst. Dein Script löscht sich nach getaner Arbeit am besten selbst, so dass keine Spuren davon auf dem Rechner zurückbleiben.


    Den temporären Adminuser kannst du nach der VPN Installation über selbige Methode auch wieder löschen.


    Es ist unwahrscheinlich, dass der User unter deiner Beaufsichtigung Unsinn mit dem temporären Adminaccount anstellt.


    Alternativ kannst du natürlich auch versuchen die komplette Installation via runas Aufruf zu automatisieren. Aufwand ist aber deulich höher als einem User ein temporäres Admin Passwort mitzuteilen und ihn durch die Installation zu leiten.


    Weitere Alternative... statt mit einem temporären Admin Account zu arbeiten kannst du auch den Benutzeraccount temporär zu den Administratoren hinzufügen.


    Und zu guter letzt... wir nutzen Teamviewer zwar eher selten, aber ich erinner mich daran schonmal die Windowsanmeldemaske in einer Teamviewersitzung gesehen zu haben. Theoretisch sollte es dir so auch möglich sein dich mit deinem lokalen Administrator anzumelden und die Installation darüber durchzuführen. Zumindestens bei uns erscheint auf dem Superadministrator Account keine UAC Abfrage.

    Dein Ziel ist es jederzeit das zur Uhrzeit passenden Desktophintergrundbild zu setzen. Dich stört, dass es bei der Nutzeranmeldung zu lange dauert bis das Script startet.


    Daher würde ich das Script bzw. eine modifizierte Instanz davon bereits vor Windowsameldung als System ausführen. So ist gewährleistet, dass bei allen (bekannten / von dir gewählten) Usern schon vor der Anmeldung das passende Hintergrundbild gesetzt wird.


    Das sollte grundsätzlich möglich sein, da der Wert dafür scheinbar nur in den Registryzweig des "current users" geschrieben werden muss. Der DLL Call deines Scriptes ist vermutlich nur zur Aktualisierung des gerade angezeigten Desktops notwendig, was bei Useranmeldung dann ohnehin erfolgt.


    Für das Systemscript muss denke ich auch der Registrywert "Wallpaper" im Zweig "HKEY_USERS\S-1-5-21-xxxxxxx-xxxxxxx-xxxx\Control Panel\Desktop" geändert werden. Welche ID dein(e) User haben musst du vorher ermitteln.

    Den Start des Systemscripts machst du über die Windows Aufgabenplanung mit der Option "unabhängig von der Benutzeranmeldung" ausführen, falls nötig mit dem User "SYSTEM" und "höchsten Privilegien".


    So sollte bei Anmeldung bereits das korrekte Bild gesetzt sein und du kannst alle weiteren Änderungen dann über das Script des Nutzers machen, oder aber du lässt das Systemscript die eigentliche Arbeit weiterhin machen und führst im Userkontext nur periodisch den DLL Call aus, damit das Bild gemäß des aktuellen Registrywerts regelmäßig aktualisiert wird.

    Zwar sicher nicht die professionellste Art zwischen Prozessen zu kommunizieren, aber wie alpines vorgschlagen hat lassen sich auch beliebige (unsichtare) GUI controls zur Kommunikation missbrauchen. Habe ich selbst mal in einem Script mit mehreren ausgelagerten Prozessen verwendet. Vorteil war, dass es beachtliche Performance Vorteile brachte und man keine künstlichen Pausen einbauen musste um den beteiligten Prozessen genug Zeit zu geben die Datei fertig zu beschreiben. Das Abfragen der GUI verursacht auch keine vergleichbare Systemlast wie es Dateizugriffe in schneller Folge tun.

    Vermutlich schreiben und lesen deine Scripte unverhältnismässig oft. Poste am besten dein Script, damit man dir den Fehler bzw. elegantere Lösungen zeigen kann. Es ist auch nicht unbedingt notwendig ständig die Dateien neu zu erzeugen bzw. zu löschen. Wenn man schon auf diese eher unperformante Art Daten austauscht kann man das auch anderst lösen.


    Die explorer.exe läuft vermutlich Amok, weil die Dateien viel zu schnell verschwinden und neu erstellt werden. der Explorer analysiert Dateien im Verzeichnis um z.B. das korrekte Verknüpfungsicon oder die integrierte Vorschau anzuzeigen, je nach Dateiformat und installierter Software. Auch für die Windows Suche müssen die Dateien indiziert werden.

    Somit müssen zum einen der Temporäre Pfad und der Zielpfad aus dem Echtzeitschutz und dem Ransomware- Schutz genommen werden, um brauchbare Resultate zu erzielen.

    Den Tempordner als Ausnahme zu definieren halte ich für eine sehr gefährliche Lösung, denn gerade dort werden oftmals Schadprogramme automatisch entpacket, ausgeführt und versteckt.


    Ich würde dir stattdessen empfehlen andere Compiler Settings zu testen. Als ich zuletzt Probleme mit Avira und Autoit hatte war das Problem z.B. nur bei 64bit Compilaten vorhanden. Außerdem verursacht der Laufzeitpacker UPX oft Fehlalarme und sollte daher besser nicht genutzt werden.


    Ebenfalls testen könntest du den Wechsel auf eine neuere oder ggf. auch ältere Autoit Version. Evtl. mag Avira nur die Signaturen einer bestimmten Autoit Version nicht.


    Was die "wiederhergestellte" und "nicht löschbare" Datei anbelangt:

    - Wie sind die Dateisystemrechte denn nun gesetzt? Fehlen deinem Benutzeraccount evtl. nur die Besitzrechte?

    Besitz von Dateien übernehmen

    - Bedenke bitte auch, dass der Explorer normalerweise als Benutzer und nicht als Administrator ausgeführt wird, selbst wenn dein Benutzer in der Administratorgruppe ist. Evtl reicht schon ein CMD Shell als Administrator um die Datei zu löschen.

    CMD als Administrator User starten

    - Prinzipiell kannst du auch eine CMD Shell mit SYSTEM Rechten öffnen. Darüber kann die Datei dann vermutlich auch gelöscht oder die Berechtigungen korrigiert werden.

    CMD als SYSTEM User starten

    - Ein sauberer vollständiger Windows Neustart löst auch so manches Problem, W10 nutz normalerweise nur einen Standby Fast Boot, was zu diversen Problemen führen kann

    W10 Fast Boot vs. Full Reboot

    Je nach Fall kann man es sich auch sparen mehrere verschiedene aber sehr gleichartige Fenster zu erstellen.


    Hab dein Script zwar nur überflogen, aber mein Eindruck war, dass deine Optionen Fenster sich kaum unterscheiden. Da wäre es auch eine möglichkeit nur mit unterschiedlichen Control-Gruppen zu arbeiten, welche je nach gewünschter "Otionsseite" ein- oder ausgebelendet werden.

    Einfach keine Adminrechte für Programmteile anfordern, die ganz sicher keine benötigen. Deine GUI kann getrost auch mit Userrechten laufen.


    Als Administrator zu arbeiten ist ein Privileg und sollte seit Einführung der Benutzerkontensteuerung kein Standard mehr in Programmen sein.


    Die Trennung von GUI und Arbeitsprozessen hat in der Regel auch Performance Vorteile, da du von Multitprocessing profitierst und heutige CPU's auf Paralellisierung ausgelegt sind.


    Würde dir also eher einen Programmaufbau mit multiplen Prozessen nahelegen:


    Code
    GUI -> Prozessmanager/Kommunikation -> Arbeitsprozesse ohne Admin Privilegien
    -> Adminrechte Anforderer -> Arbeitsprozesse mit Admin Privilegien

    Naja wie schon gesagt wurde ist W10 "sicherer" und lässt nicht mehr zu, dass bestimmte WindowMessages (hier Drag&Drop) von nieder Privilegierten Benutzerkontexten an höher Privilegierten gesendet werden.


    Das konnte man nämlich ausnutzen um ohne Adminrechte Code im Administratorkontext auszuführen, sofern ein entsprechendes Fenster existent war.


    Dein Desktop und Explorer Fenster läuft normalerweise im Kontext deines Benutzeraccount mit normalen Privilegien, daher funktioniert Drag&Drop auch nicht mit GUI's im Adminkontext.


    Anstatt das Verhalten zu umgehen oder gar eine Explorer Instanz mit erhöhten Privilegien zu starten sollte man eher modular und sorgsam mit hohen Privilegien umgehen. Erreichen kann man das z.B. durch Trennung der Prozesse für GUI und "Worker". In der Regel benötigt nämlich nur der Worker höhere Privilegien.


    Durch getrennte Prozesse von GUI und dem eigentlichen Code kann man übrigens auch andere Probleme wie eine nicht mehr reagierende Oberfläche vermeiden.

    Ja also bei der Beschreibung ist definitiv die Windows Aufgabenplanung die erste Wahl. Als Trigger kann dort auch die Benutzeranmeldung gewählt werden, dann wird dein Script wie gewünscht ausgeführt und du benötigst nicht mal Einträge im Autostart des Users.


    Davon mal abgesehen... ich kenne deine Backuplösung nicht, aber alle Backuplösungen die ich so kenne arbeiten ihre angelegten Backupjobs voll automatisch nach definiertem Zeitplan ab. Die Backup Software installiert dafür einen Dienst der immer aktiv ist und ausreichend Rechte besitzt. Kann mir kaum vorstellen, dass das bei deiner Software nicht der Fall ist.

    Ahja eine Lösung wäre auch noch die Nutzung von runas und die Angabe eines Benutzeraccounts mit deaktivierten UAC Prompts (kann man per Registry oder Gruppenrichtlinie deaktivieren).


    Der Superadministrator Account "Administrator", welcher standardmässig deaktiviert ist hat diese UAC Einstellung normalerweise.


    Die Angabe von solchen Zugangsdaten in deinem Script ist aber nicht wirklich "sicher" und nicht zu empfehlen.

    Vielleicht nochmal genauer beschreiben was du erreichen willst bzw. wie dein Wunschablauf ist.


    Grundsätzlich hilft dir runas denke ich soweiso nicht, denn mit runas wird lediglich der Benutzer definiert unter dessen Account das Script ausgeführt wird, das hat erstmal nichts mit erhöhten (Admin-)Rechten zu tun.


    Standardmässig arbeite seit Windows Vista nämlich jeder Benutzeraccount mit normalen Benutzer Privilegien. Werden Adminprivilegien benötigt erscheint der UAC Dialog, welcher dir erlaubt mit erhöhten Rechten weiterzuarbeiten.


    Ob der UAC Dialog eine Angabe von Username und Passwort, einfach nur einen Klick auf JA erfordert oder garnicht erscheint hängt von mehreren Gegebenheiten bzw. den Einstellungen von UAC ab.


    Also kurz nochmal:

    Selbst wenn du bei runas Administratordaten angibst startet der Prozess nur im Benutzermodus, siehe auch deine Beobachtungen.


    ---------


    Das ganze funktioniert über die Windowsaufgabenplannung, wenn dort der Haken "Mit höchsten Privilegien ausführen" gesetzt wird und sich der dort hinterlegte Account in der Administratorgruppe befindet. In diesem Fall wird UAC tatsächlich automatisiert.


    Um Aufgaben in der Aufgabenplannung anzulegen werden allerdings ebenfalls Administratorprivilegien benötigt. Du müsstest also zumindestens für die Installation deiner "Hintertür" einmalig diese Privilegien durch Benutzerinteraktion mit UAC erhalten.


    --------


    Sofern es für dich kein Problem ist bei jedem Script Start einmalig UAC zu bestätigen kannst du dir auch die Vererbung der Berechtigungen zu Nutze machen.


    Jeder Prozess, der mit erhöhten Privilegien arbeitet gibt diese auch an Prozesse weiter, welche er aufruft. Du kannst also dein Script nutzen um die Berechtigungen anzufordern und danach über das Script z.B. 10 andere Programm mit erhöhten Privilegien starten ohne weitere Angabe von Benutzerdaten oder Bestätigung von UAC Dialogen.


    Diese Lösung erfordert zwar Benutzerinteraktion, dafür werden aber keine Zugangsdaten irgendwo gespeichert.

    Grundsätzlich würde ich auch eher die Backupdateien prüfen. Das sollte dein Script aber ohnehin tun, denn wenn eine Backupdatei warum auch immer nicht erstellt werden kann solltest du davon zeitnah Kenntnis erhalten, damit das Problem behoben werden kann und nicht monatelang unentdeckt bleibt. Eine Warn-/Fehlermeldung sollte den Anwender hier informieren.


    Aber natürlich hast du recht, dass die mehrmalige Scriptausführung im Fehlerfall dann evtl. nicht mehr sauber unterbunden wird. Daher ist eine zusätzliche Logdatei sinnvoll. Hier würde ich dann nicht nur die Ausführung ansich protokollieren, sondern auch den Erfolg/Misserfolg, rein informativ die Dauer und alle "gewollten" Abbrüche der Ausführung. Ob Abbruch oder nicht kannst du einfach durch das Änderungsdatum der Logdatei entscheiden.


    Rechtetechnisch solltest du beim Schreiben von (Log-)Dateien vielleicht noch beachten, dass Windows Standardverzeichnisse in der Regel von der Benutzerkontensteuerung und evtl. Antivirensoftware geschützt werden. Deine Log Datei sollte also nicht unbedingt unter "C:\programme\.." liegen. Ich empfehle die Logdatei im Zielverzeichnis der Backups abzulegen, da du hier ohnehin Schreibrechte sicherstellen musst.


    Du solltest die Rückgabewerte der Log Schreibfunktion prüfen und so schon vor Beginn des Backups bei Schreibproblemen der Logdatei eine Warnung und einen Programmabbruch auslösen.

    Alternativ kann man den Speicherpfad auch einfach direkt in den CMD Befehl packen.


    Code
    $cmd = @ComSpec & ' /c ' & 'ipconfig /all > "' & @WorkingDir & '\data\ipconfig.txt"'
    consolewrite($cmd & @crlf)
    RunWait($cmd, @WorkingDir, "", @SW_HIDE)

    Nachtrag: Ich habe es jetzt "temporär" via Windows Aufgabenplanung gelöst, d.h. sobald ich mich anmelde, wird die 1. EXE gestartet. Dienst wäre etwas schicker.

    Nein wäre es nicht. Da der Dienst vermutlich in einem anderen Benutzerkontext laufen würde (local system?) kann dein Script sehr wahrscheinlich auch keine Fenster auf dem Desktop eines anderen angemeldeten Benutzers finden. Das Script im Kontext des entsprechenden Users auszuführen ist also in diesem Fall die beste / einzigste Lösung. Deine Konstruktion mit zwei Scripten ist eigentlich dann auch überflüssig, anstatt ein weiteres Script aufzurufen könnte dein Script die Fenster auch selbst verschieben und dann auch problemlos in Intervallen die Position prüfen bzw. wiederherstellen falls nötig.

    Bildanalyse mag ja vielleicht eine Möglichkeit sein um das Problem zu lösen, aber ist das wirklich die beste und einzigste Möglichkeit? Woher stammen die Bilder? Vermutlich von einer Webseite. Es sollte also grundsätzlich die Möglichkeit geben den Sitzplatzstatus direkt live abzufragen. Jenachdem ob du dort beschäftigt bist oder quasi extern auf die Daten zugreifst hast du vielleicht sogar die Möglichkeit direkt oder indirekt via API auf die zugrundeliegende DB zuzugreifen.