Windows-Dienst, Notification, Zugriff verweigert

[Delrabe]

Hallo,

@Sinspin: Danke für den Hinweis, die Kommunikation zwischen dem Dienst und der Notify.App ist in meinen Augen kein Problem. Die Daten könnten z.B. in einer Datei vom ini-Typ stehen, wo der Dienst unter [MELDUNG] die gewünschten Meldungs-Daten einträgt und die Notify.App anschließend unter [NOTIFY] das Ergebnis und ggf. die Fehlermeldung einträgt. Der Dienst könnte bei Bedarf eine solche Datei erstellen und beim Aufruf der Notify.App diese Datei als Parameter übergeben.

Das Problem ist aber genau dieser Aufruf der Notify.App aus dem Dienst heraus. Das ist offenbar direkt nicht gestattet, weshalb wohl ein Aufruf als "aktueller User" bereitgestellt wird. Leider funktioniert der derzeitig nicht.

Im Detail: Ich verschaffe mir das "Token" des aktuellen Users, wobei "WtsGetActiveConsoleSessionID" und "WTSQueryUserToken" verwendet werden, und rufe danach "CreateProcessAsUser" mit den entsprechenden Parametern auf (vgl. den Quellcode). Leider bekomme ich jetzt eine Fehlermeldung, die wohl bedeutet, dass Admin-Rechte fehlen. Das verstehe ich nicht. Für den Aufruf der Notify.App sind eigentlich keine Admin-Rechte notwendig. Ich selbst bin als Admin angemeldet, nicht als Sys-Admin, aber was spielt das für eine Rolle? Hier wäre ich dankbar für Erläuterungen.

Inzwischen habe ich eine Variante mit "TImpersonateUser" aus dem Netz eingebaut, die wahlweise benutzt werden kann (vgl. die neue Version des Quellcodes). Die funktioniert aber auch nicht, Meldung "Eine Anmeldeanforderung enthielt einen unzulässigen Wert für den Anmeldungstyp" (ERROR_INVALID_LOGON_TYPE). Das liegt möglicherweise daran, dass man zwar den aktuellen User bestimmen kann, aber man kennt natürlich nicht sein PW. Mein Verdacht ist, dass diese Möglichkeit für spezielle Fälle benutzt wird, wo man in einem Programm ein PW abfragt, um Zugriff auf spezielle Features zu ermöglichen.

@peterbelow: Danke für den Hinweis.

@Sinspin: Bei den "Windows Schnittstellen", die man verwenden sollte, wäre ich dankbar für ein paar zusätzliche Info's. So kann ich damit nichts anfangen.

[QuickAndDirty]

Ich mag das Problem total falsch verstehen,
aber spricht irgendetwas gegen ein Programm das in der Systemtray mit läuft und sich im Autostart in der registry einrichtet und dann den Dienst überwacht und von dem Dienst auch mitgeteilt bekommt, wenn es mal ne Meldung Anzeigen soll?
Ist das nicht mehr "state of the art"?

[Sinspin]

Das ist es, wo ich mich jedesmal frage, warum soll der Dienst was starten?
Das macht entweder die Verwaltungsanwendung mit oder man schreibt was Fensterloses fürn Systray was die Meldungen generiert.

Und Kommunikation via INI? Ich weis nicht. Ich bin auch noch aus den vorgen Jahrtausend. Aber das ist schon ne ganz spezielle Idee.
Das nennt sich "Named Pipes" dazu hat Micosoft ne ganze gute docu.

[himitsu]

Genau andersrum.

Warum soll jeder Dreck massenhaft Notify-Programme starten und dauerhaft laufen lassen,
anstatt, nur wenn benötigt, kurzzitig Jenes zu starten?

Auf einem Terminal-Server wird es noch schlimmer, wenn dutzende Leute eingeloggt sind, bei JEDEM dutzende Notify-Programme laufen,
anstatt nur das eine Programm, welches "jetzt" was sagen will, bei aktiven Usern (vielleicht sogar nur bei Admins)



Klar, Programme, welche im Tray ständig einen Status anzeigen müssen sollen, da ist es OK.

[Sinspin]

Zitat von himitsu:

Genau andersrum.

Dann erleuchte uns, anstatt noch mehr heiße Luft zu produzieren!

Wie geht es dann richtig?

[QuickAndDirty]

Ich bin zwar nicht Himitsu...aber vielleicht denkt er an sowas:
In Windwows 11 gibts ein Windows Notification Center ... ich denke(Ich weiß es nicht!!!) da haben sie endlich mal eine Lösung geschaffen die vergleichbar mit Android oder IOS ist, wo man Pushnotofications auf den Desktop zaubern kann?

Aber auf älteren Windosen muss man mit der Systray weiter machen...

[Delrabe]

Hallo,

danke für die Anworten. Und sorry, ich bin zwar ein versierter Delphi-Entwickler, habe aber auf diesem Feld noch Defizite.

Wenn die Notify-App also ebenfalls permanent gestartet ist und es "nur" darum geht, dass der Dienst die Notify-App über ein anstehendes Update informiert, dann verstehe ich natürlich auch den Einsatz einer NamedPipe. Und bevor ich mich darin vertiefe, wie in etwa sieht das auf der Seite der Notify-App aus? Die App muß wohl beim Start ein MS-Objekt erzeugen, in dem ein entspr. Handle angefordert wird. Aber wie geht es jetzt weiter? Gibt es dabei irgendeine Form von Event/Message, auf die die App. nur reagieren muß, oder muß die App. ähnlich wie beim Dienst vorgehen, also permanent die Update-Situation prüfen und dann eine kleine Zeit (1000 Milli.Sek.) schlafen.

Inzwischen habe ich allerdings eine andere Idee. Man könnte auch ganz auf einen Dienst verzichten, und stattdessen die Arbeit von einer Kontroll-App. erledigen lassen, die unsichtbar im Hintergrund läuft und im Autostart eingetragen ist, ähnlich wie das jetzt für die NotifyApp vorgeschlagen wurde. Diese Kontroll-App müsste einen Kontroll-Thread erstellen und starten, der permanent eine anstehende Aktion prüft, ggf. einen Client-Thread zur Durchführung startet und anschließend ein kleine Zeit pausiert. Bei dieser Konstruktion sollte das Notify-Problem entfallen, oder?

Ich sehe nur ein Problem, wenn die Sache auf einem Client-Rechner läuft und der angemeldete User nur über geringe Rechte verfügt. Die Kontroll-App. müsste vom Sys-Admin so eingerichtet/installiert werden, dass sie über das Recht verfügt, Daten von unserem Server herunterzuladen, bzw. vorerst würde sogar der Download der entsprechenden Konfig.-Textdatei genügen. Ich weiß leider nicht, was da möglich ist.

[himitsu]

Hab ich doch beschrieben?
Kannst'e lesen?

* du bist dafür, dass jeder eine App unsichtbart oder im Tray laufen lässt, selbst wenn die meistens nicht genutzt wird

* ich bin dafür, dass man diese "permanenten" Nachrichten-Apps abschafft und stattdessen der Dienst im Falle des Anzeigewillens den Prozess zum Anzeigen im aktiven Kontext vorübergehend startet,
damit eben nicht sinnlos tausende Anwendungen aktiv sein müssen.

Und ja, das NotificationCenter ist auch nett.
OK, die Komponente von Embarcadero ist schrott, aber per se muß das Programm nicht dauerhaft laufen, nach der Anzeige dort. Wenn sich die Anwendung/Komponente richtig mit der Notification verbunden hätte, würde Windows unser Programm wieder starten, wenn man auf die Notification klickt und das eigene Programm schon wieder weg war.

[Delrabe]

@QuickAndDirty: Danke für den Hinweis.

Inzwischen habe ich allerdings entschieden, ganz auf Windows-Dienste zu verzichten. Die Update-Kontrolle wird von einer unsichtbare Kontroll-App erledigt werden, die im Hintergrund arbeitet. Das Programm wir über ein Monitor-Programm gesteuert werden, wobei der Anwender u.a. einstellen kann, dass sich die Kontroll-App. nach dem Ende einer Überprüfung selbst beendet. Damit können überflüssige Ressourcen vermieden werden. Der Anwender muss lediglich sicherstellen, dass die Kontroll-App im Autostart oder im Task Scheduler eingetragen ist, wobei es am besten ist, wenn der Update-Monitor die entsprechenden Einstellungen vornehmen kann. Dies muss ich allerdings erst noch ausknobeln.

Der Anwender wird die Update-Kontrolle über ein InnoSetup installieren müssen und dort sollten auch die benötigte Rechte abgehandelt werden.