AutoRun bei System-Ereignissen
Analog zur AutoRun-Funktion kann USBDLM bei System-Ereignissen eine Kommandozeile ausführen.
Die unterstützten Ereignisse sind:
- OnServiceStart Dienst-Start, vor dem Überprüfen der Laufwerksbuchstaben
- OnServiceStarted Dienst-Start, nach dem Überprüfen der Laufwerksbuchstaben
- OnServiceStop Dienst-Stop
- OnServiceShutdown Dienst-Shutdown (beim Herunterfahren von Windows)
- OnUserLogon Nach Nutzer-Anmeldung
- OnUserLogoff Nach Nutzer-Abmeldung
- OnUserLock Nach "Sperren der Arbeitsstation"
- OnUserUnlock Nach "Entsperren der Arbeitsstation"
- OnUserConnect "Verbinden" von Maus und Tastatur mit dem Desktop (z.B. nach Anmeldung)
- OnUserDisconnect "Trennen" von Maus und Tastatur vom Desktop (z.B. nach Abmeldung, Arbeitstation sperren)
- OnUserActivated Benutzer hat sich erstmals oder erneut angemeldet (Benutzer-Wechsel)
- OnUserDeactivated Benutzer hat sich abgemeldet, die Arbeitsstation gesperrt oder einen Benutzer-Wechsel eingeleitet
- OnSleepRequest Beim Standby und Ruhezustand, es wird aber nicht auf Fertigstellung gewartet; nicht ab Vista/Win7
- OnSleep Nach Auslösen von Standby und Ruhezustand, praktisch u.U. erst beim Aufwachen...
- OnResume Nach Aufwachen aus Standby und Ruhezustand
- OnUndockRequest Beim "Abdocken" über das Startmenü
- OnUndock Nach erfolgtem "Abdocken" über das Startmenü
- OnDock Nach erfolgtem "Andocken", aber nur wenn das "Abdocken" über das Startmenü erfolgte
OnUserConnect und OnUserDisconnect meint das "Verbinden" von Maus und Tastatur mit dem Desktop, z.B. nach An- und Abmelden eines Nutzers.
Unter XP mit aktiver "Schneller Benutzerumschaltung" wird Disconnect erst gemeldet wenn ein neuer Nutzer angemeldet wird - ist also nicht wirklich sinnvoll einzusetzen.
Ab Vista werden OnUserLock und OnUserUnlock nur dann getriggert, wenn die wirklich "Arbeitsstation sperren" gewählt wird, unter XP dagegen (fast) immer:
OnUserUnlock wird in folgender Situation unter XP nicht getriggert: Mit "Schneller Benutzerumschaltung" wird mit "Benutzer wechseln" der aktive Nutzer gesperrt, über die Anmeldeseite ein zweiter Nutzer angemeldet, dieser wieder abgemeldet und der erste Nutzer wieder aktiviert. Obwohl zuvor ein Lock getriggert wurde, generiert XP hier kein Unlock.
Da unter XP weder auf die Lock noch auf die Connect-Ereignisse Verlass ist, gibt's ab V4.6 OnUserActivated und OnUserDeactivated.
Diese werden USBDLM-intern anhand o.g. Ereignisse generiert, wenn ein Nutzer in irgend einer Weise aktiviert bzw. deaktiviert wird, also bei "Arbeitsstation sperren", "Benutzer wechseln", "Abmelden" gibt's ein OnUserDeactivated, und beim "Anmelden" und "erneut Anmelden" ein OnUserActivated.
Für Ereignisse bei denen der Nutzer bereits abgemeldet ist, muss ein system=1 angegeben werden, so dass das jeweilige Programm im Kontext "LocalSystem" ausgeführt wird - den Nutzerkontext gibt's ja schon nicht mehr.
Bei OnSleepRequest wartet Windows leider nicht bis die Nachricht verarbeitet wurde, sondern nur maximal zwei Sekunden. Es gibt also keine Garantie, dass irgendwelche Aktionen noch vor dem Standby oder Ruhezustand ausgeführt und vor allem fertiggestellt werden. Ab Vista gibt es OnSleepRequest nicht mehr.
OnSleep wird u.U. erst beim Aufwachen ausgeführt.
Wenn die Windows-Option "Kennwort beim Reaktivieren aus dem Standbymodus anfordern" aktiviert ist, wird unter XP die Arbeitsstation beim Aufwachen gesperrt, dementsprechend kommen OnUserLock, OnUserDisconnect und OnUserDeactivated erst dann. USBDLM kann das Sperren schon beim Standby veranlassen, dann kommen auch die Ereignisse vor dem Einschlafen:
[Settings]
LockWorkstationOnSleep=1
Hundertprozentig zuverlässig ist das aber nicht.
Beispiel fürs Anlegen eines Netzlaufwerks nach Nutzer-Login:
[OnUserLogon]
open=net user X: \\server\freigabe /user:nutzername passwort
openstyle=min
Die sonstigen, von [OnArrival] bekannten Parameter, wie openstyle, system usw. sind auch hier gültig, mehrere open-Zeilen können durch Anhängen einer Ziffer 1..9 genutzt werden. Ab V5 geht's auch ohne Ziffern, eine open-Zeile beginnt dann einen neuen Parametersatz.
Ab V4.5 sind mehrere Abschnitte eines Typs möglich, die einzigen Kriterien sind die des aktiven Nutzers, ein laufender Prozess und die für das Vorhandensein einer Datei.
Beispiel zum Start des WIA-Dienstes für Admins und zum Stoppen desselben für Nicht-Admins beim Login:
[OnUserLogon]
IsUserAdmin=1
open=net start stisvc
system=1
[OnUserLogon]
IsUserAdmin=0
open=net stop stisvc
system=1
system=1 bewirkt, dass die NET.EXE im Kontext "LocalSystem" ausgeführt wird. Somit sieht der Nutzer das eigentlich aufpoppende Konsolenfenster nicht und der Nicht-Admin hat kein Problem mit fehlenden Rechten.