Beiträge von misterspeed

Wir hatten uns hier für ein Rechner Erstinstallationsscript wie schon beschrieben wurde mit der automatischen Benutzeranmeldung beholfen. Dies war auch kein Problem, da die automatische Anmeldung nach Erstinstallation des Systems automatisch und restlos wieder entfernt wurde.

Hinweis: Das Passwort wird im Klartext in der Registry gespeichert, daher ist dieses zwingend nach Abschluß wieder zu löschen.

Das ganze kann vollautomatisiert werden sobald du dein Script mit Systemrechten ausführen kannst. Dein Script schreibt dann die nötigen Registryschlüssel für die automatische Anmeldung, startet das System neu und du landest auf dem Desktop des Zielusers wo dann via Autostart die Fortsetzung des Scriptes im Userkontext seine Arbeit verrichtet.

Das wurde allerdings noch zu W7 Zeiten realisiert und ist so unter W10 evtl. nicht mehr möglich.

Bitnugger

Normalerweise wird man nach einer frischen Windows Installation automatisch mit dem Administrator Account angemeldet. Gewisse Installationen und Konfigurationen erfordern bei einer voll automatisierten Installation dann aber früher oder später einen Reboot. Damit das Script auch danach automatisch weiterlaufen kann war es bei uns nötig Anmeldung und Scriptfortsetzung ebenfalls zu automatisieren. Unsignierte Treiber irgendwo aus dem Internet installieren wäre für uns aber keine Option gewesen...

Anstatt den Dialog zu automatisieren könntest du auch einfach vorher mit Autoit Mitteln prüfen ob die Dateien schon existieren, falls ja löschst du sie ebenfalls mit Autoit Mitteln und startest danach erst den Kopiervorgang via Windows Funktion "copyhere". Ein Dialog wird dann nicht mehr erscheinen, wenn du das Problem schon zuvor gelöst hast.

Also mal zur Erklärung:

Wenn du Remotedesktop verwendest wird für die Anmeldesession am Server ein virtuelles Display und eine virtuelle Tastatur erstellt. sobald die Remote Verbindung getrennt wird scheitern alle Autoit Funktionen, die auf diese virtuellen Geräte zugreifen, da sie nur während einer aktiven RDP Session existieren. Es macht schlichtweg keinen Sinn Bildschirm und Tastatur bei einer inaktiven (getrennten) RDP Verbindung zu simulieren, daher wird das von Microsoft auch nicht getan. Beim Minimieren des Fensters passiert ähnliches, die virtuellen Geräte werden abgeschaltet (vergleichbar mit Standby) um unnötige Bandbreite der RDP Verbindung einzusparen, denn dein Client braucht schlichtweg kein Bild und keine Tastatur, wenn du den Client nicht aktiv nutzt, weil minimiert.

Dein Script würde am lokalen Rechner ebenfalls scheitern, wenn du den Rechner sperrst oder auf einen anderen Benutzeraccount wechselt. Dein Account und das Script laufen zwar dann noch im Hintergrund, aber Display und Tastatur sind nicht mehr mit diesem Account, sondern mit dem anderen Account oder dem System Account (Anmeldebildschirm) verbunden.

Wenn dein Script abhängig von der Auflösung ist können Änderungen zur Laufzeit ebenfalls Probleme machen, diese hättest du aber auch lokal am Rechner, wenn du die Bildschirmauflösung einfach änderst solange das Script läuft. Das lässt sich Programmtechnisch aber evtl. fixen indem du in Intervallen (oder besser auf ein Windows Event) die derzeit verwendetet Auflösung prüfst und dein Script dynamisch darauf reagieren lässt. Einfacher ist es aber auf den Vollbildmodus der RDP Verbindung zu verzichten und diese auf eine feste immer gleich bleibende Auflösung einzustellen.

Warum passiert das nun nicht auch wenn du über KVM Lösungen des Serveranbieters auf den Server zugreifst? Hierbei verwendest du eine sogenannte Konsolensitzung, d.h. die Anmeldesession ist nicht rein virtuell, sondern identisch mit einer Anmeldung direkt am Server per angeschlossener Tastatur und Maus. Windows geht in solch einem Fall davon aus, dass Monitor und Tastatur nur dann nicht gebraucht werden, wenn der Server in den Standby wechselt, was bei Server Betriebssystemen in der Regel deaktiviert ist. Die Bildschirmauflösung der virtuellen Verbindung ändert sich hier in der Regel auch nicht, da KVM oder VNC Clients maximal einen Softwarezoom anbieten, die eigentliche Auflösung des Displays aber nicht anfassen (sieht man daran, dass bei Größenänderungen das Bild unscharf wirkt). Die Regeln für den Sperrbildschirm oder Benutzerwechsel gelten aber auch hier... Display und Tastatur ändert den Fokus auf einen anderen Account und dein Script scheitert.

Mögliche Lösungen für dich:

1. Verzichte auf jegliche Art von simulierten Tastatureingaben und Bildschirmabhängigen Funktionen. In deinem Script Ausschnitt sind das alle "send" Befehle... ersetze diese durch Alternativen der Excel UDF und dein Problem ist gelöst

2. Teste wie oben beschrieben ob eine RDP Verbindung mit dem Paramater "console" zum selben Ergebnis führt wie bei einer KVM Sitzung:
"mstsc -v:MACHINE_NAME /F -console"

3. Verwende Alternativen zu Microsoft RDP für den Serverzugriff. Das Stichwort ist VNC. Auch hier hast du in der Regel eine Konsolensitzung wie bei der KVM Lösung des Serveranbieters, bist aber nicht auf einen Webbasierten Client hierfür angewiesen.

Hier mehr Informationen zum Microsoft Bug und dem aktuellen Fix Status:

Error in Access when opening a database on a network file share

Das Problem wurde je nach Office Version bislang nur teilweise behoben. Problematisch sind nachwievor DB Zugriffe, die über gemappte Laufwerke erfolgen. Direkter lokaler Zugriff oder über UNC Pfade sollte mittlerweile wieder funktionieren, sofern die dort genannten Patches installiert wurden.

Wir haben seit Dezember das selbe Problem mit unserer Personalwirtschaft.

Virenscanner? Evtl. auch einfach nur ein Caching Phänomen deiner CPU oder Betriebssystem, evtl. wird deine CPU auch erst nach einer gewissen Zeit unter hoher Last höher getaktet? Autoit nutz außerdem nur einen Kern, es wäre also denkbar, dass manchmal der "bessere" weniger belastete Kern genutzt wird und manchmal ein eher ausgelasteter oder noch schlimmer, dass der Task zur Laufzeit auf einen anderen Kern verschoben wird.

Hatte selbst schon beobachtet, dass bei mehrmaliger Ausführung eines Scriptes in kurzen Abständen die Laufzeit besser wurde.

Die Schwierigkeit ist eher den Standardbrowser (in dem Fall deine eigene Autoit.exe) für alle Benutzer des Systems als Standard zu setzen. Dazu gab es vor einigen Monaten hier mal einen Thread.

Wenn dir das zuverlässig gelingt ist der Rest keine besondere Herausforderung. Der Link wird immer als Parameter an den definierten Standardbrowser übergeben und ab da kannst du dann tun was immer du möchtest. Eine weitere Schwierigkeit wäre evtl. noch den gewünschten "normalen" Browser des Users zu erkennen und dann entsprechend den Aufruf dorthin umzuleiten wenn der Link deinen Kriterien entspricht. Das machst du am besten bevor du den Standardbrowser auf deine Autoit.exe umstellst und speicherst die "original" Einstellung des Users in einer ini Datei.

EDIT:

Hier das Thema bzgl. Standard App Festlegung unter W10 -> RE: Dateitypen für eigenes Programm registrieren

Zitat von Bitnugger

So auch mit alle anderen (ausführbaren) Erweiterungen, die in PATHEXT enthalten sind.

Danke, wusste ich in der Tat nicht. Sicherer ist es jedenfalls grundsätzlich vollständige Pfadangaben für Dateien jeder Art zu verwenden und ggf. auch vorab auf deren Existenz und bei Bedarf via Hash auf Authentizität zu prüfen.

Und könnte es auch vorkommen, dass mehr als die 4 Dateien über die Projektnummer gefunden werden? Z.B. bei korregierten Exports aus dem ERP oder ähnlichem?

Sind dir die Dateinamen vollständig bekannt, sobald du die Projektnummer hast oder gibt es je nach Projekt weitere Variable Teile des Namens? Im ersteren fall könntest du auf eine Suche im Dateisystem komplett verzichten und müsstest lediglich auf die Existenz der 4 Dateien prüfen.

Mal von den vielen angebrachten Tipps abgesehen hat scheinbar noch niemand den echten Fehler entdeckt:

            ;PCO-View
            Run("X:\bin\.pcoview")
            WinWaitActive("PCO View Login")
            send($user)
            send("{TAB}")
            Send($pwd)
            Sleep(1000)
            Send("{ENTER}")
            Sleep(1500)
            WinWaitActive("bwms-app")

Dein run(...) Aufruf von PCO-View ist schlichtweg falsch (Dateiendung fehlt). Daher wird das Programm nicht gestartet und dein Script bleibt sehr wahrscheinlich beim darauffolgenden WinWaitActive(..) hängen.

Angenommen es würde funktionieren wie du es willst... ist Adlibregister dann überhaupt eine sinnvolle Wahl? Die in Adlibregister registrierte Funktion zur Verarbeitung könnte deine Funktion zum neu Befüllen deines Arrays unterbrechen. Angenommen das passiert bei 50% des Füllvorgangs, dann verarbeitest du zur Hälfte "alte" Daten und zur Hälfte "neue" Daten. Wenn das ein Problem wäre kommt das so ohnehin nicht in Frage.

Zitat von Tweaky

Kann sein, dass ich mich auch täusche und es noch nie funktioniert hat. Früher hatte ich sehr selten #RequireAdmin benötigt.

Meine auch, dass das früher kein Problem war, selbst unter W10. Microsoft hat die betreffenden Sicherheitslücken aber irgendwann gefixt, was dann zu weiteren Einschränkungen zwischen User und Admin Prozessen führte.

Und wenn du Scite ebenfalls mit Adminrechten startest?

Vermutlich ein Rechteproblem, bei dem weniger priviligierte Prozesse (scite) nicht mit Prozessen höherer Berechtigung Kommunizieren können. Aus diesem Grund funktioniert z.B. auch kein Drag and Drop von "normalen Benutzer Fenstern" in "Admin Fenster".

Nunja, sofern Oscar recht hat und das Event immer genau zweimal triggert kannst du dir auch einfach mit einer Zählervariable behelfen.

global $checkme = 0

;...
            Select
                Case $iCode = $LVN_ITEMCHANGED
                    if $checkme = 1 then
                        _check()
                    else 
                        $checkme += 1
                    endif
            EndSelect

;...

Func _check()
    Local $iListView_markiert2
    $checkme = 0
;...
EndFunc   ;==>_check

Ohne das Programm zu kennen oder mir das angeschaut zu haben... hast du mal geprüft ob die Software einen Windows Dienst eingerichtet hat? Die Tatsache, dass unsauberes Beenden erkannt wird deutet jedenfalls darauf hin, dass es nebend er GUI bzw. Trayicon noch einen überwachenden Hauptprozess gibt. Falls es sich dabei um einen Windows Dienst handelt genügt es evtl diesen zu beenden.

Via DOS Befehl ginge das z.B. so:

net stop servicename

Entweder per run(...) ausführen oder ggf. eine passende Funktion der Win API direkt via Autoit nutzen.

Benötigt die Software evtl. Adminrechte?

#RequireAdmin

Mal versucht beim Run Aufruf das "Workingdir" festzulegen?

Run ( "program" [, "workingdir" [, show_flag[, opt_flag ]]] )

Ahja und Falls es eine 32bit Anwendung ist sollte dein Autoitscript ebenfalls 32bit sein bzw. 64bit bei einer 64bit Anwendung um Probleme mit Windows FS Redirection zu vermeiden.

#AutoIt3Wrapper_usex64=Y
; oder
#AutoIt3Wrapper_usex64=N

Wozu umständlich, wenn es auch einfach und direkt geht?

https://www.autoitscript.com/autoit3/docs/l…rentProcess.htm

Damit bekommst du die PID des Parent Prozesses eines beliebigen Unterprozesses. Der Parentprozess muss nicht zwangsläufig ein Fenster und erst recht keinen Fenstertitel haben. Mag vielleicht bei Chrome und FF derzeit zutreffen, aber dass das prinzipiell so wäre und auch so bleibt würde ich mal lieber nicht annehmen.

32vroni

Laufen die "chrome.exe" Prozesse alle im gleichen Benutzerkontext, oder handelt es sich evtl. um Prozesse eines anderen Benutzers / Dienstes? Ist letzteres der Fall fehlen deinem Autoit Prozess die Berechtigungen um die Prozesse zu beenden. Hier helfen in der Regel Adminrechte für das Script. In sehr seltenen Fällen sind sogar Systemrechte notwendig (z.B. möglich wenn es sich um Unterprozesse eines Updatedienstes handelt).

Mögliche Ursachen:

- Windows FS Redirection: Dein Autoitscript ist 32bit und dadurch werden die Windows System Pfade auf die jeweiligen 32bit Pfade umgelenkt. In deinem Fall dann vermutlich "C:\Windows\SysWOW64" statt "C:\Windows\System32". Dort gibt es dann auch tatsächlich keine "wuauclt.exe"

- Arbeitsverzeichnis falsch: Beim Run Aufruf kannst du explizit ein Arbeitsverzeichnis mitgeben. Sofern dein Script nicht auf C:\ ausgeführt wird kann auch das gelegentlich dazu führen, dass Standard Windows Befehle nicht richtig umgesetzt werden.

Ich tippe auf Variante 1. Die einfachste Lösung wäre dein Script als 64bit Script zu kompilieren. Gibt dafür aber auch andere Lösungen, die die Windows FS Redirection temporär für dein Script abschalten oder du verwendest den "sysnative" Pfad.

Details siehe hier:

Vorhandene! bcdedit.exe kann NiCHT vom Script ausgeführt werden weil es diese exe nicht findet

http://www.samlogic.net/articles/sysna…bit-windows.htm

https://www.autoitscript.com/autoit3/docs/l…Redirection.htm

Vielleicht solltest du die Randbedingungen, den IST-Zustand und SOLL-Zustand doch mal genauer erklären. Ich bin mir ziemlich sicher, dass es auch möglich ist vor Nutzung von Teamviewer sämtliche gespeicherten Daten zu löschen und dir somit deinen Idealzustand herzustellen, bei dem du selbst deine Daten via Autoit eintragen kannst (das funktioniert ja anscheinend).

Zu den grundlegenden Infos die man benötigt um dir zu helfen gehört z.B.:

- Teamviewer Version

- Teamviewer Lizenzierung (Free oder Abo?)

- Wer nutzt dein Script bzw. den Rechner auf dem das Script ausgeführt wird

- Bist du Alleinnutzer oder hast du eingeschränkte Möglichkeiten den Rechner zu verwalten?

- Auf welches System oder auf welche Systeme wird zugegriffen?

- Sind dir die Zugangsdaten (ID und PW) immer für alle Systeme bekannt?

- usw.

Warum kompliziert wenn es evtl. auch viel einfacher geht?

https://community.teamviewer.com/German/kb/arti…zeilenparameter

Demnach ist eine GUI Automatisierung völlig unnötig und man kann alle benötigten Verbindungsdaten per cmdline Aufruf an die teamviewer.exe übergeben.