Beiträge von misterspeed

Gibt noch andere mögliche Gründe.

(Anderer) Virenschutz auf dem Server? Virenscanner reagieren in der Regel empfindlicher / gründlicher bei Ausführung von Netzlaufwerken, das selbe gilt für die Windows Benutzerkontensteuerung.

Teste doch mal das Verhalten wenn alle Komponenten und Hilfsprogramme in einem lokalen Ordner des Servers liegen.

Serverbetriebssysteme haben außerdem die "Datenausführungsverhinderung / DEP". Hier hilft evtl. eine Ausnahme für das betreffende Programm.

Aber dein Problem ist ja scheinbar bereits durch eine Alternative gelöst.

Ah hab nochmal kurz geschaut, zumindestens in meiner Version (14.8) bietet die RST Software selbst schon die Möglichkeit Emailbenachrichtigungen zu aktivieren (Voreinstellungen -> Email). Das Ereignislog überwachen ist also garnicht notwendig. Wenn das ganze Teil deiner Software sein soll könntest du einen eigenen simplen TCP/SMTP Server in Autoit schreiben, der die Email des RST Treibers abfängt und auswertet.

Für ältere Treiberversionen gibt es anscheinend ein Command Line Interface, welches genutzt werden könnte um die gewünschten Informationen zu erhalten:

https://communities.intel.com/thread/101156

Scheinbar wird das aber nicht mehr weiterentwickelt und ist inkompatibel mit aktuellen Treiberversionen. Hab jetzt aber auch nicht intensiver gesucht ob es evtl. doch eine aktuelle und kompatible Version gibt.

Webautomatisierung via IE.AU3 scheidet im Falle von Intel onboard Raid aus, da hier kein Webinterface, sondern eine normale Desktopanwendung zum Einsatz kommt.

Falls es dir ausreicht lediglich beim Ausfall des Raids alarmiert zu werden könnte man alternativ evtl. das Windows Ereignislog auswerten. Vermutlich generiert der Raidtreiber hier Warnmeldungen auf die reagiert werden könnte. Das nüsste man aber wohl testen.

Das Tool Crystal Disk Info kann im Übrigen die SMART Werde aller Intel Raid Einzelfestplatten auslesen und ist soweit ich mich erinnere per CMD automatisierbar. Auch das könnte man nutzen um den Zustand der Festplatten regelmäßig zu prüfen.

Zitat von BugFix

Das funktioniert bei mir problemlos.

Ähm ja bei mir mittlerweile auch... hatte irgendwie noch einen unsichtbaren calc.exe Prozess im Hintergrund laufen und beim zweiten gibts dann wohl Komplikationen, bzw. das bereits unsichtbare Fenster wird angesprochen.
Ich nehme die Behauptung also zurück, nachträgliches/zeitversetztes Verstecken funktioniert durchaus.

Ursache könnte sein, dass das Fenster evtl. zu spät erstellt bzw. innerhalb der Software nochmals explizit sichtbar gemacht wird, wenn die Sichtbarkeit nicht gegeben ist. Im Falle von normaler Anwendungssoftware ist es üblicherweise ja auch durchaus gewünscht, dass das Fenster nach Programmstart sowohl sichtbar als auch im Vordergrund ist.

Ähnliche Phänomene hatte ich auch schon mit diversen anderen Programmen, welche bei mir durch ein Autostart Script minimiert starten sollen. Teilweise war hier auch ein nachträgliches prüfen/bearbeiten des Fensterstatus notwendig.

Interessantes Phänomen. Kann anhand deines Scriptes unter Windows 7 bestätigen, dass die calc.exe sichtbar startet. Selbst ein späteres verstecken statt schließen ist scheinbar nicht möglich.
Hab jetzt keine Zeit / Lust damit rumzuspielen, würde mich aber trotzdem interessieren wo genau das Problem liegt.

Wenn es nur um die Sichtbarkeit geht kann man aber alternativ auch runas verwenden und die Software im Kontext eines anderen Benutzers ausführen.

Hab das nur mal schnell überflogen, aber hier einige Anmerkungen und auch ein Verdacht warum dir evtl. die Rechte fehlen die Logdatei zu schreiben:

1. Warum automatisierst du ein sichtbares CMD Fenster mit Tastenbefehlen wie SEND? Führ doch einfach gleich die entsprechenden DOS Commandos via RUN aus.
2. Warum automatisierst du Outlook mit Tastenbefehlen? Alternativ kommt evtl. die outlook UDF in Frage oder aber es gibt andere, bessere und direktere Methoden ein Outlook Profil zu sichern. Tastenbefehle sind absolut unzuverlässig, wenn man schon GUI Automatisierung nutzt sollte man auf controlsend usw. setzen.
3. Bitte mehr Details zum eigentlichen Problem...

- Handelt es sich beim Pfad auf "C:\" um einen Windows Standardordner wie "C:\programme" oder Ähnliches? Wenn ja schützt die Benutzerkontensteuerung oder eine evtl. vorhandene Antivirensoftware evtl. vor Schreibzugriffen.
- Sehe ich das richtig, dass du beim ersten Durchlauf einen lokalen Administrator anlegst, welcher dann beim zweiten Systemstart automatisch angemeldet wird und zur Scriptfortsetzung genutzt wird? Das Schreibproblem tritt nur unter diesem erstellten Administrator auf? Wenn ja arbeitest du sehr wahrscheinlich beim ersten Durchlauf mit dem Superadministrator "Administrator", welcher spezielle Benutzerkontensteuerungs Einstellungen hat (komplett deaktiviert / keine Rückfrage). Der Account verfügt auch ansonsten über mehr Rechte als alle anderen Administratoren.

Lösungen wären die Nutzung des Superadministrators, temporäres Deaktivieren der Benutzerkontensteuerung, die Nutzung eines nicht durch die Benutzerkontensteuerung geschützten Verzeichnisses, z.B. "C:\_install" usw.

Naja schonmal gegoogelt? Eine eigene Umsetzung von SIP erfordert jedenfalls jedemenge Arbeit wie bei den meisten Protokollen.

Zitat von Wikipedia

Das Session Initiation Protocol (SIP) ist ein Netzprotokoll zum Aufbau, zur Steuerung und zum Abbau einer Kommunikationssitzung zwischen zwei und mehr Teilnehmern. Das Protokoll wird u. a. im RFC 3261 spezifiziert. In der IP-Telefonie ist das SIP ein häufig angewandtes Protokoll.
...
https://de.wikipedia.org/wiki/Session_Initiation_Protocol

Der grobe Protokollablauf ist auf Wikipedia zu finden, die genaue Spezifikation des Protokolls findest du wie üblich im zugehörigen RFC Dokument:
https://tools.ietf.org/html/rfc3261

In einem anderen Thread habe ich die systematische Auswertung eines DHCREQUEST Pakets beispielhaft mal teilweise implementiert und beschrieben:
Testcode: Anmeldungen im LAN via UDP Broadcast mitbekommen
Erläuterung: DHCP Client emulieren

Eine vollständige Umsetzung des DHCP Protokolls hätte aber sicher mehrere Monate benötigt.

Zurück zu SIP...

Wenn du nach "sip command line" googlest wirst du ebenfalls sofort fündig:
http://sipcmd.sourceforge.net/

Der Autor ist sogar so nett seinen Quellcode auf Github zu veröffentlichen. Es steht dir also frei dir anzusehen wie er das Protokoll implementiert hat und dieses nach Autoit zu portieren. Ich würde rein gefühlsmässig aber sagen, dass andere Sprachen bzgl. Performance und Multithread Fähigkeit deutlich besser für Echtzeit Anwendungen geeignet sind als Autoit.

Mal vom eigentlichen Problem abgesehen bin ich doch sehr überrascht, dass den anderen Logikfehler noch niemand entdeckt hat...

If StringLen($sPW1) < 4 Then
MsgBox(16, "Fehler", "Ihr Passwort muss mind. 5 Zeichen haben")

Das ist leider falsch. Entweder du änderst die Abfrage zu <=4 oder <5. Alternativ kannst du dich natürlich auch mit einem 4-stelligen Passwort begnügen, dann stimmt aber dein Text nicht.

Zitat von autoiter

EDIT: Was misterspeed sagt, ist übrigens schlagend. Wenn du Angst vor den Nutzern hast, darfst du AutoIt fast nicht verwenden..

Naja wenn mans richtig macht schon. Man kann sowas auch mittels Client / Server Scripten machen. Die richtig kritischen Berechtigungen hat nur der Server Teil, welcher für den Benutzer weder zugreifbar noch manipulierbar ist. Der Client schickt lediglich mittels eigener API, bevorzugt verschlüsselt und authentifiziert die gewünschten Änderungsanfragen an den Server, welcher diese nach Prüfung dann umsetzt. Der Benutzer (Client) kann dann nur im begrenzten Umfang der API bestimmte Änderungen anfragen und hat niemals Zugriff auf fremde Zugangsdaten, welche das Serverscript evtl. für die Umsetzung benötigt.

Zitat von mumpel

(das erreiche ich schon mit dem geheimen Kennwort, das verhindert das Öffnen der Datei mit z.B. Hex-Editoren)

Ja aber wo steht denn dein geheimes Passwort? Vermutlich im Quellcode deines Autoit Scriptes. Also alles andere als geheim und extrem leicht auslesbar.

Zitat von autoiter

Aber ich verstehe es nicht, warum das notwendig sein sollte. Was willst du genau verhindern?

Frag ich mich auch immernoch. Warum soll überhaupt eine geheime, passwortgeschützte Excel Tabelle auf einem "Fremdrechner" automatisiert gelesen/bearbeitet werden? Das ist ansich schon unsicher! Um an die Excel Tabelle zu kommen brauch ich keine weitere Excel Instanz, sondern nur einen Dekompiler und/oder Networksniffer, werlche mir die Zugangsdaten zum Netzlaufwerk / Webspace und zur Excel Datei bermutlich in Sekunden offenbart.

Naja eine extreme Möglichkeit wäre noch die Datei excel.exe oder wie auch immer sie genau heißen mag zu Programmstart umzubenennen und ggf. die Excel UDF so anzupassen, dass deine Excel.exe - Kopie mit anderem Namen gestartet wird. Dadurch sollten alle Dateiverknüpfungen und sonstige Möglichkeiten Excel selbst zu starten solange ins Leere laufen bis du die Datei wieder zurückbenannt hast.

Eine weitere Variante ist es temporör in der Registry einen Dummy "Debugger" für die Excel.exe festzulegen um so weitere Starts zu verhindern. Diese Methode wird hier anhand des nervigen Werbepopups von Avira Antivir demonstriert (in aktuellen Versionen nicht mehr notwendig / möglich)

https://www.youtube.com/watch?v=eMGsw44iY00

Beide Varianten erfordern Admin Rechte und können außerdem ggf. Schutzmechanismen des installierten Virenscanners triggern. Wie oben schon erwähnt sind diese Lösungen ebenfalls problematisch wenn dein Script abstürzt, da deine Änderung dann eben erstmal permanent ist. Allerdings wären diese Varianten sehr einfach rückgängig zu machen.

Naja viel zu aufwendig und riskant. Kannst natürlich in der Registry rumpfuschen und die Dateityp Zuordnung für alle relevanten Formate unbrauchbar machen und die Startmenüeinträge, Desktopverknüpfungen und angepinnte Programmverknüpfungen ebenfalls entfernen. Wäre mir aber viel zu riskant... was passiert wenn dein Script aufgrund schlampiger Programmierung abstürzt und die Änderungen nicht mehr rückgängig machen kann? Danach heißts dann wohl Office Reparatur oder Neuinstallation starten für den Anwender / IT Admin.

Die Frage ist doch viel mehr warum es dich überhaupt juckt wenn der Anwender nebenher eigene Instanzen von Excel startet. Soweit ich mich erinnere nutzt die Excel UDF COM Objekte um mit der gestarteten Excel Instanz zu kommunizieren. Dabei sollte es eigentlich keine Komplikationen mit anderen Instanzen geben.

Selbst wenn... die viel einfachere Lösung für das Problem ist ein aufdringlicher visueller Hinweis an den Benutzer, dass er gefälligst die Finger von manuellen Excelstarts zu lassen hat. Wenn er meint er ist gescheiter ist es sein Problem und er muss dann eben mit den Konsequenzen leben. Alternativ kannst du auch einfach Maus und Tastatur mit blockinput sperren und den Benutzer darauf Hinweisen, dass er sich jetzt mal 2min zurücklehnen darf bis dein Script fertig ist.

Wie dem auch sei und was du auch immer tun wirst... alle notwendigen Informationen bzgl. Registry, Startmenü und anpinnen von Verknüpfungen findest du recht schnell per google. Für pin/unpin gibt es funktionierende Autoit Scripte. Dateiverknüpfungen und die entsprechenden Registryänderungen sind von Microsoft dokumentiert.

Na entweder per Unicast TCP Verbindung an alle bekannten IP's des (Sub-)Netzwerkes oder eben indem du deine Nachricht an die Broadcast IP des (Sub-)Netzwerkes sendest. Was eine Broadcast IP ist und wie du diese für das jeweilige (Sub-)Netzwerk ermittelst googlest du bitte. Broadcasts werden in Firmennetzwerken aber evtl. durch eine Firewall unterbunden, genauso wie Subnetzinterne Kommunikation beschränkt oder ganz gesperrt sein könnte. Details hierzu kannst du bei euerem Netzwerkadministrator in Erfahrung bringen. Ich bezweifle aber mal, dass euer Chef der da evtl. kommt euch die Erlaubnis gibt eigene Client-/Server Software auf eueren Rechnern zu installieren. Es soll auch sowas wie whatsapp und whatsapp Gruppen geben wenn ihr privat kommunizieren wollt...

Zitat von De Rand Ere

... ich kann also einer Variable eine Funktion zuweisen und muß später der Variable nur die (muß)-Parameter übermitteln.DAS kannte ich noch nicht ... danke.

Geht aber nur in aktuelleren Autoit Versionen. Ich persönlich verwende immernoch eine alte Version, weil mir Geschichten wie das da oben nicht wirklich gefallen. Die neueren Versionen erlauben noch ganz andere Spielereien, welche in alten Versionen schlichtweg Syntaxfehler werfen würden. In deinem Fall fatal, weil du dir nicht bewusst warst, dass du die Variable quasi zur "Funktion" gemacht hast anstatt ihr einen normalen Wert zuzuweisen.

Was das URL Encodeing anbelangt... solange deine "Values" im String keine Zeichen enthalten, welche mit der URL Kodierung kolidieren brauchst du nicht zwingend eine eigene URL Kodierung deines Inhaltes. Es schadet aber auch nicht dies von Anfang an zu implementieren. In einem der API Beispiel Scripte aus den anderen Sprachen wird dies im Übrigen gemacht. Dürfte hier aber in der Tat unnötig sein, da die API keine wirklich variablen Daten (z.B. Freitext Suchbegriffe) zulässt soweit ich das sehe.

Aus der Doku ist mir nicht ganz klar geworden was genau mit deinem Secret signiert werden muss. Nur der API Funktions Aufruf "returnBalances" selbst, oder der komplette String inklusive nonce? Die von dir verwendete HMAC Implementierung scheint jedenfalls korrekte Ergebnisse zu erzielen und ich denke auch, dass der komplette String signiert werden muss so wie du es bereits machst.

Ich würde nochmal kontrollieren ob API Key und Secret korrekt sind.

Deine Scripte sollten alle schon lange bevor überhaupt irgendwas passiert mit Syntax Fehler abgebrochen werden...

Global $tZeit = TimerInit ;Startzeit

Wie wärs mal mit einem korrekten Aufruf der Funktion timerinit ? Ob die API "0" als gültigen Integer anerkennt weiß ich nicht. Grundsätzlich würde ich ohnehin auf die Timer Funktionen verzichten und stattdessen einfach eine einfach Integerzahl beginnend mit "1" hochzählen.

Davon mal abgesehen verwende ich in meinen Scripten grundsätzlich noch eine URL Encode Funktion, da Winhttp zumindestens bei mir nicht selbsständig alle ungültigen Zeichen ersetzt/escaped hat.
https://de.wikipedia.org/wiki/URL-Encoding

Magst du uns vielleicht auch verraten welche Richtlinie genau? Dein Problem wird evtl. in den nächsten Jahren auch andere Administratoren beschäftigen.

Naja dein Problem ist schonmal, dass du die Benutzerkontensteuerung nicht triggerst (#requireadmin). Nur weil du die Software im Kontext eines anderen (Administrator-)Accounts ausführst bedeutet das nicht zwangsläufig, dass du auch mit erhöhten Rechten arbeitest. Seit Windows Vista/7 muss selbst ein Administrator zunächst erhöhte Rechte anfordern und arbeitet ansonsten nur mit Benutzerprivilegien.

Unter Windows 10 ist das Verhalten des standarmäßig deaktivierten "Superadministrator" Kontos außerdem noch ein wenig anderst. Wenn ich mich recht erinnere kann dieser zum Beispiel keine Office Anwendung mehr starten, wenn man sich mit diesem Account anmeldet. Ob es weitere Einschränkungen gibt weiß ich nicht (wir verwenden noch Windows7).

Du hast grundsätzlich aber über die Windows Aufgabenplanung die Möglichkeit den Haken für "Mit höchsten Privilegien ausführen" und bei Bedarf evtl. auch "Unabhängig von der Benutzeranmeldung ausführen" (Systemkonto) zu setzen. Hierdurch sollte die auszuführende Software maximale Rechte haben. Alternativ kannst du auch ein beliebiges Administrator Konto in der Aufgabe definieren.

Ich würde also einfach solch eine wiederkehrende Aufgabe erstellen (Rollout z.B. via Gruppenrichtlinien).

Das Script welches von der Aufgabe gestartet wird sollte dann selbständig alle vorhandenen Updates aus einem von dir definierten Quellordner installieren ('run', nicht 'runas'). Da sich die CMD Befehle unterscheiden können macht es Sinn diese in eine Konfigurationsdatei im Quellverzeichnis abzulegen. Dein Script muss dann nur noch die Datei einlesen und alle Befehle der Reihe nach abarbeiten. Zum Schutz vor Missbrauch sollte dieses Quellverzeichnis nur für Administratoraccounts beschreibbar sein. Nach Installation der Updates sollten diese gelöscht oder verschoben werden, damit dein Script nur dann tätig wird wenn du wirklich neue Updates ausrollen willst. Sind keine Updates im Ordner macht das Script einfach nichts.

Das wäre jedenfalls mein Ansatz. Da ich kein W10 LTSB habe kann ich das aber nicht testen

Mal davon ab, dass hier die wenigsten die LTSB Version haben dürften... wovon redest du überhaupt? Automatisierung von Windows Updates oder von diversen Software Updates? Wie und was genau? Wo ist dein Script? Was funktioniert denn in der LTSB Version genau nicht, aber in der normalen Professional schon? Debugging deinerseits? Irendwelche Fehlercodes bei bestimmten Funktionen? Deine Problembeschreibung ist schlichtweg ungenügend.

Naja das Windows Tool "cipher" dient laut Technet Artikel ja primär eigentlich auch garnicht zum Löschen von unbenutztem Speicherplatz, sondern zum ver- und entschlüsseln von Dateien und Ordnern. Wenn ich das ganze zum "sicheren" Löschen einer Datei verwenden möchte würde ich die Datei einfach verschlüsseln, danach meinetwegen noch mit Zufallszahlen überschreiben und dann Löschen. Das sollte letzlich ausreichend sicher sein und die Datei für normalsterbliche bzw. gängige Software unwiederherstellbar machen.

Die Kritik bzgl. SSDs bzw. nicht-magnetischen Speichermedien ist allerdings berechtigt. SSDs schreiben normalerweise nicht in die Ursprungszellen, sondern in weniger benutzte Zellen um eine gleichmässige Alterung und längere Lebenszeit der Zellen zu garantieren. Auch beim Löschen von Daten bleiben die Zellen zunächst unangetastet um eine Alterung zu verhindern. Ein physikalisches Überschreiben oder Löschen ist technisch also nicht zuverlässig möglich. Desweiteren nutzen moderne SSDs soweit ich weiß intern auch Redundanz vergleichbar mit RAID 5. Dadurch bleiben Daten auch bei Defekt einzelner Bereiche von der Fehlerkorrektur noch wiederherstellbar.

Aber auch der Hinweis auf Windows eigene Redundanz (caches, Temp Verzeichnisse, Schattenkopien, Backups) ist mehr als berechtigt.

Eine wirklich sichere Löschung lässt sich meiner Meinung nach nur durch mehrmaliges und vollständiges Überschreiben des gesamten Datenträgers realisieren. Noch besser ist aber natürlich die physikalische Vernichtung des Datenträgers.