Hallo allerseits, ich hab folgendes Problem: Ich habe unter W7 Ultimate einen Service laufen der zu einer APC USV gehört. Wenn auf der USV Events wie z.B. Power Failed auftreten kann man Batchfiles angeben die dann ausgeführt werden. Soweit so gut. Das funktioniert auch, nur werden die Batchfiles asls SYSTEM User ausgeführt. Angemeldet bin ich aber als User123. Wenn ich im Batch definiere er soll mir eine .exe mit GUI ausführen, dann tut das auch, aber die Gui ist nicht zu sehen. Wenn ich unter Prozesse -> Prozesse aller Benutzer schaue sehe ich das die Applikation läuft. Ich hab auch schon versucht was mit dem Command RunAs zu machen, aber ohne Erfolg. Hat jemand ne Idee was ich tun könnte um das Programm als Benutzer ausführen zu lassen? Danke schon mal Elias
Setz in den Eigenschaften des Dienstes im Reiter "Anmelden" das Häkchen bei "Datenaustausch zwischen Dienst und Desktop zulassen" und checks nochmal. Alternativ dort gleich die Anmeldeart auf Benutzer ändern.
Icke ®. schrieb: > Setz in den Eigenschaften des Dienstes im Reiter "Anmelden" das Häkchen > bei "Datenaustausch zwischen Dienst und Desktop zulassen" und checks > nochmal. Alternativ dort gleich die Anmeldeart auf Benutzer ändern. wenn ein wenig wert auf sicherheit legt macht das nicht. Man hat dann eine Anwenung als system laufen, wenn in der Anwendung dann z.b. ein Dateiöffnen dialog ist kann man mit systemrechten alles machen. Ein Dienst darf nicht mit der GUI arbeiten für sotwas muss ein eigener Prozess bei dem angemeldeten user laufen, der auf das event vom dem Service wartet.
Hi, das mit dem Häckchen habe ich schon probiert, keine Änderung. Ich habs schon mit dem Runas commad mversucht aber das klappt gar nicht. Danke schon mal
Schon versucht, die Anmeldeart des Dienstes auf Benutzer (user123) einzustellen?
Ja, aber dann muss ein PW gesetzt sein (Was nicht der Fall ist) und ohne geht nicht!
das ist doch alles sinnlos - so macht man es nicht. Villeicht bekommt man es irgendwie hin dann geht es eventuell nach dem nächsten SP oder Update nicht. Ein dienst hat keine Programm zu starten, was eine GUI anzeigt. Alles Programm müssen in der Nutzer session gestartet werden und können dann auf events vom Dienst reagieren. Spätestens wenn mal mehre nutzer an dem system angemeldet sind (z.b. über RDP) geht es eh nicht mehr so. Mach es doch gleich richtig.
Elias B. schrieb: > Ja, > > aber dann muss ein PW gesetzt sein (Was nicht der Fall ist) und ohne > geht nicht! Das kann man in der Registry abstellen. DenyBlankPasswords oder sowas heißt das...
Hallo erst mal Danke für die Antworten. Hab mittlerweile herausgefunden das es von M$ eine Lib gibt über die man die USV abfragen (Batteriebetrieb/Netzbetrieb/...) und auch herunterfahren und ausschalten kann. Für alle die auch nach so was gesucht haben hier mal der Link: http://msdn.microsoft.com/en-us/library/windows/hardware/ff536317%28v=vs.85%29.aspx Sehr wahrscheinlich wird die die beste Lösung sein.
Elias B. schrieb: > Hab mittlerweile herausgefunden das es von M$ eine Lib gibt über die man > die USV abfragen (Batteriebetrieb/Netzbetrieb/...) und auch > herunterfahren und ausschalten kann. Da hast Du was falsch interpretiert. Das, was Du da gefunden hast, ist die Dokumentation, die nötig ist, um eigene Devicetreiber für USVn zu entwickeln. Das hilft Dir nicht. Wenn es Dir aber nur darum geht, herauszufinden, was eine am PC angeschlossene USV von sich gibt, dann geht das viel einfacher. Der windowseigene Dienst zur Überwachung der USV (oder in Deinem Fall der zur APC-USV gehörende Dienst) erzeugt Einträge im Eventlog - und genau die kann Dein Programm auswerten. Was das eigentliche Thema mit dem Service (Dienst) angeht: Von einem Service gestartete Prozesse laufen im selben Benutzerkonto wie der Service selber. Es gibt zwar eine API-Funktion, um Prozesse in anderen Benutzerkonten auszuführen, diese aber ist in den letzten Windows-Versionen eingeschränkt worden, Services können diese nur noch nutzen, wenn sie im SYSTEM-Benutzerkonto laufen. Wenn der entsprechende Service nicht so geschrieben ist, daß er diese API-Funktion (CreateProcessAsUser oder CreateProcessWithLogon o.ä.) nutzt, dann helfen diese Betrachtungen nicht.
Windows 7 ist Scheisse! Egal ob 32bit oder 64bit. Dont feed the Yankees and Google-Verbrecher.
Das ist natürlich ein technisch äußerst fundiertes Urteil, dem wir hier uns wohl beugen müssen.
Peter II schrieb: > Ein dienst hat keine Programm zu starten, was eine GUI anzeigt. Alles > Programm müssen in der Nutzer session gestartet werden und können dann > auf events vom Dienst reagieren. Auf Prinzipien zu reiten kann manchmal ziemlich einschränkend sein. Beispielsweise dann, es es wie hier um ein Event geht, dessen Abarbeitung u.U. nur dann mit den Rechten des angemeldeten Benutzers zu machen ist, wenn der zufällig auch Adminstrator ist. Wenn man dann das Pech hat, dass man beim zwangsweisen Shutdown aufgrund von akut drohendem Mangel an Betriebsmittel ein Programm starten sollte, dass eine grafische Oberfläche hat, dieses aber Admin-Recht benötigt ohne x-mal den Anwender um Zustimmung zu bitten, dann kommt man schlecht drum herum. Und solche Mistviecher gibts in den besten Familien. Nicht jede grafische Komponente enthält Mechanismen, die als sicherheitskritisch betrachtet werden müssen. Beispielsweise wenn die keine nennenswerte Benutzerinteraktion hat, sondern sowas wie "shutting down database engine" zeigt, vielleicht noch mit nem "cancel" Knopf garniert.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.