Zugriff auf Netzwerkressourcen über eine Windows-Dienstanwendung

Das Konzept der Windows-Dienste wurde mit der Windows-Version NT 3.5 eingeführt. Dabei handelt es sich um Programme, die ohne Benutzeranmeldung im Hintergrund ausgeführt werden. Meistens werden sie beim Hochfahren des Betriebssystems automatisch gestartet und haben keine Benutzeroberfläche. Mit dem SOA-Service stellen wir unseren Entwicklern eine Möglichkeit zur Verfügung, eigene Programme als Dienstanwendung zu erstellen.


Typischerweise sind Dienst-Anwendungen so konzipiert, dass für die Verarbeitung der Zugriff auf lokale Ressourcen des Systems ausreicht. Je nach Aufgabenstellung kann es aber erforderlich werden, auf freigegebene Verzeichnisse oder Netzwerkdrucker zuzugreifen.

Grundsätzlich ist ein Zugriff auf Netzwerkressourcen auch von einem Windows-Dienst aus möglich. Dazu ist allerdings der Kontext, in dem der Dienst läuft, zu ändern. Standardmäßig werden Dienste unter Windows – so auch der SOA-Service – unter dem „lokalen Systemkonto“ gestartet. Wie der Name des Kontos schon vermuten lässt, gewährt es dem Dienst umfassende Rechte auf dem lokalen Computer. Ein Zugriff auf das Netzwerk besteht in diesem Kontext allerdings nicht.

Hierzu muss sich der Dienst mit einem Benutzerkonto anmelden, welches die notwendigen Rechte besitzt. Die Einstellungen der Dienste sind über Systemsteuerung -> Verwaltung -> Dienste zu erreichen. Alternativ lässt sich die Verwaltung über den Ausführen-Dialog durch die Eingabe von „services.msc“ starten. Nach der Auswahl des Dienstes „CONZEPT 16 SOA-Service“ kann auf der Registerseite „Anmelden“ das gewünschte Benutzerkonto angegeben werden. Nach erfolgter Änderung muss ein Neustart des Dienstes durchgeführt werden.

CONZEPT 16 SOA-Dienst
Was gibt es zu beachten?

In der Praxis ist es der Anwender gewohnt, auf freigegebene Verzeichnisse über ein Netzlaufwerk zuzugreifen. Einem Windows-Dienst stehen Netzlaufwerke allerdings nicht zur Verfügung. Stattdessen muss der Zugriff auf die Freigaben im UNC-(Universal Naming Convention) Format erfolgen.

Beispiel:

// Erzeugen einer Datei
FsiOpen('\\MyServer\MyShare\Documents\MyFile.txt',_FsiStdWrite)

Bei einer Neuinstallation des SOA-Service gehen die Einstellungen bezüglich der Anmeldedaten verloren, da der Dienst mit den Standardkonto („Lokales Systemkonto„) eingerichtet wird. Dies ist auch bei einem Upgrade auf eine höhere Major-Release des SOA-Services der Fall, da bei einem Upgrade die bestehende Version entfernt wird. Idealerweise sollte programmseitig Vorsorge getroffen werden, um eine Änderung des Kontos feststellen zu können. Mit Hilfe der CONZEPT 16-Funktion UserInfo() und der Option _UserSysAccount lässt sich der Name des Kontos ermitteln.

Beispiel:

// Benutzer-ID ermitteln
tUserID # UserInfo(_UserCurrent);
// Benutzername ermitteln
tUser   # UserInfo(_UserSysAccount,CnvIA(tUserID));

Läuft Der Dienst unter dem lokalen Systemkonto, gibt UserInfo() den Namen „SYSTEM“ zurück.

2 Antworten

  1. Hallo Fabian,
    bei einem Update bleiben die Daten erhalten. Lediglich bei einem Upgrade, Beispiel von 5.6 auf 5.7, gehen die Anmeldedaten verloren.

    Wir nehmen Deinen Vorschlag gerne auf.

  2. Hallo Andreas, Du hast zwar geschrieben, dass das Benutzerkonto des Dienstes bei einem Update des SOA-Services nicht erhalten bleibt. Aber warum ist das so? Wir hatten doch dasselbe Problem bereits beim Datenbankserver. Dort wurde es zwischenzeitlich so eingerichtet, dass das Benutzerkonto auch bei einem Update des Datenbankservers erhalten bleibt. Kann dieses Prinzip nicht auch auf den SOA-Service adaptiert werden? Somit könnte man sich das mühsame Wiedereintragen des Benutzerkontos beim SOA-Service ersparen…

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Leave the field below empty!

IHRE EVALUIERUNGSLIZENZ - JETZT ANFORDERN!

TESTEN SIE DIE CONZEPT 16 VOLLVERSION - UNVERBINDLICH und KOSTENFREI

Melden Sie sich bei unserem Newsletter an

Anrede*
     
Zustimmung zur Datenverarbeitung gem. DSGVO*



WordPress Cookie-Hinweis von Real Cookie Banner