Win 2003 Server Dienstproblem

[Sanchooo187 10]

Hallo Leute,

 

wir haben eine Server-Software, die als Dienst unter Windows 2003 Server korrekt laufen muß. Ich versuche mal mein Problem zu schildern.

 

folgendes Szenario:

Es gibt 2 Konten, eines (Konto A) dass immer angemeldet ist und benutzt wird, dann das Konto (Konto B) unter dem unsere Server-Software als Dienst laufen soll. Beide Konten sind Administratoren-Konten.

Der Server ist unter "C:\Programme" installiert. Starte ich den Server als Applikation funktioniert es, auch als Dienst (Der Dienst läuft unter der Kennung von Konto B) funktioniert es soweit. Kommt aber noch eine Komponente ins Spiel gibt es ein komisches Verhalten.

Es gibt noch ein Konfigurationstool, dass Daten bereitstellt. Dieses Tool liegt unter "E:\[TOOL]". Das Laufwerk E: wiederum ist im Netzwerk als Netzlaufwerk verfügbar (Laufwerksbuchstabe X:). Im Server gebe ich die Konfigurationsdatei als X:\[TOOL][DATEI] an. Starte ich den Server als Applikation und dann einen Client, dann wird die Konfigurationsdatei eingelesen und der Client kann wunderbar arbeiten.

Starte ich den Server als Dienst, wird die Konfigurationsdatei nicht eingelesen und es läuft als wäre es im Auslieferungszustand. Der Client funktioniert auch hier.

Ändere ich im Server den Laufwerksbuchstaben von X:\ auf E:\ funktioniert auch hier die Applikation einwandfrei.

Der Dienst allerdings lässt den Client abstürzen, weil der Client wahrscheinlich auf E:\ zugreifen will, aber keinen Zugriff bekommt. E:\[TOOL] hat Rechtemässig Vollzugriff von Jedem.

Jetzt meine Frage: Warum funktioniert es als Applikation, aber als Dienst nicht richtig?

Vielen Dank jetzt schonmal für eure Antworten.

 

Gruß

 

P.S.: Unter WinXP gibt es dieses Verhalten nicht

[nobex 10]

Ich denke, dass Du dem User B, unter dem der Dienst im Hintergrund ausgeführt wird, das Netzlaufwerk zur Verfügung stellen oder dem Dienst den Zugriff über UNC-Pfad auf die Konfig-Datei beibringen musst.

[lefg 276]

Existiert das Netzlaufwerk zum Zeitpunkt des versuchten Zugriffs denn schon? Mit welchem Account wird versucht, die Netzlaufwerksverbindung herzustellen, wird sie tatsächlich hergestellt und ist der Zugriff auf die Ressource zu dem Zeitpunkt gewährleistet?

 

Ist es vom Herstellers der Software tatsächlich so vorgesehen? Gibt es bei dem FAQ und Support, wurde schon mal Kontakt aufgenommen?

[Sanchooo187 10]

Ich denke, dass Du dem User B, unter dem der Dienst im Hintergrund ausgeführt wird, das Netzlaufwerk zur Verfügung stellen oder dem Dienst den Zugriff über UNC-Pfad auf die Konfig-Datei beibringen musst.

Existiert das Netzlaufwerk zum Zeitpunkt des versuchten Zugriffs denn schon? Mit welchem Account wird versucht, die Netzlaufwerksverbindung herzustellen, wird sie tatsächlich hergestellt und ist der Zugriff auf die Ressource zu dem Zeitpunkt gewährleistet?

Konto B, also das Konto unter dem der Server läuft hat das Netzlaufwerk (X:\) gemappt. Das ist zunächst nicht das priorisierte Problem (aber evtl. später :D).

Das Problem ist, dass wenn der Zugriff vom Server aus stattfindet und der Client gestartet wird, er prompt abstürzt. Der Client versucht beim Start (Initialisierung) diese Datei einzulesen. Allerdings geht genau da etwas schief, deshalb der Absturz.

Wenn der Server als Applikation, also nicht als Dienst läuft, funktioniert alles einwandfrei.

 

Kann es etwas mit Zugriffsrechten oder Sicherheitsrichtlinien zu tun haben? Was kann ich übersehen haben?

 

P.S. Ich habe vergessen zu erwähnen, dass alles lokal ausprobiert wird, d.h. Server Start und Client Zugriff, unter Konto A, wie auch Konto B.

[nobex 10]

Konto B, also das Konto unter dem der Server läuft hat das Netzlaufwerk (X:\) gemappt.

Wie hast Du das für den Dienst geregelt?

[Sanchooo187 10]

Wie hast Du das für den Dienst geregelt?

In den Serviceproperties, Reiter Log On -> Log on as -> This Account, dort habe ich Username und Passwort von Konto B eingetragen.

[nobex 10]

In den Serviceproperties, Reiter Log On -> Log on as -> This Account, dort habe ich Username und Passwort von Konto B eingetragen.

Dadurch wird aber nicht automatisch das Netzlaufwerk verbunden.

[Sanchooo187 10]

Wie geschrieben, das Problem stellt zunächst nicht das Netzlaufwerk dar. Ich habe im Anfangsposting schon erwähnt, dass ich statt X:\ E:\ verwende.

Meine Frage ist, warum verhält sich der Dienst anders als die Applikation?

[Gulp 266]

Höchstwahrscheinlich, weil Dienste bereits vor der Anmeldung starten und das Laufwerk E:\ oder X:\ mit der Konfigurationsdatei dann eben noch nicht zur Verfügung stehen. Entweder Du gibts der Applikation, die als Dienst läuft einen UNC Pfad zur Konfigurationsdatei mit oder musst sicherstellen, dass das Laufwerk ohne Anmeldung eines Users bereits zur Verfügung steht.

 

Grüsse

 

Gulp

[Sanchooo187 10]

Wenn ich aber den Dienst restarte, dann sollte doch das Verzeichniss bzw. die Datei zur Verfügung stehen oder habe ich einen Denkfehler?

[nobex 10]

Für den Dienst (angemeldet mit User B im Hintergrund) stehen nicht die Netzlaufwerke des an der Konsole angemelden Users A zur Verfügung. Es ahndelt sich um 2 separate Sessions.

[Sanchooo187 10]

Für den Dienst (angemeldet mit User B im Hintergrund) stehen nicht die Netzlaufwerke des an der Konsole angemelden Users A zur Verfügung. Es ahndelt sich um 2 separate Sessions.

Das ist der Punkt. Ich habe gerade gesehen, dass in der Konfigurationsdatei alle Pfade mit L:\ beginnen. Da bringt es mir auch nichts, wenn ich im dem Server sage, er solle sich die Datei von E:\ holen. Der Server kommt zwar an die Datei, aber nicht an die relevanten Informationen. Gleiche ich es überall an, also UNC oder E: (also die physikalisch korrekte Adresse), dann funktioniert es. Da es aber im Netzwerk verfügbar sein muß, ist die einzig korrekte Einstellung UNC-Pfade. Vielen vielen Dank für eure Hilfe, wäre selbst wohl nie draufgekommen.

Eine abschliessende Frage hätte ich dennoch, wie schaffe ich es, dass das Netzlaufwerk für den Dienst gestartet wird? Gibt es da eine Möglichkeit?

 

Gruß

[nobex 10]

Habe ich so noch nicht ausprobiert, aber eine Idee wäre:

Wenn nur ein LW benötigt wird, könnte man dies evtl. über den Basisordner des Useraccounts erledigen, keine Ahnung ob das Mapping im Hintergrund auch stattfindet ... *grübel*

 

Nachtrag:

Im hier

Using Mapped Drives with IIS

beschriebenen Fall wird das LW einfach durch eine Anmeldung und das Setzen von 'Persistent-Mappings' verbunden. Diese Mappings werden dann wohl auch im Hintergrund ausgeführt.

[Gulp 266]

Wenn es nicht über den UNC Pfad (was die eigentlich korrekte Methode ist) gelöst werden soll, so kann man eine entsprechende Batch erstellen, die zuerst das entsprechende Laufwerk mappt und dann die gewünschte Applikation startet. Nimmt man nun das Resourcekit Tools srvany.exe und konfiguriert die Batch als Dienst, dann sollte man das gewünschte Ergebnis erhalten. Ob das aber im Sinne des Erfinders ist ....... zumal in der Batch im schlimmsten Fall Logindaten des Dienstaccounts im Klartext hinterlegt werden müssen.

 

Hat ein Dienstaccount die entsprechenden Rechte für die Freigabe, so reicht der UNC Pfad ja völlig aus und man muss sich nicht mit Batchdateien "verrenken".

 

Userbezogene Laufwerkmappings werden ohne Batch oder manueller NET USE Verwendung erst nach der Anmeldung aktiv (wie auch sonst, sie sind ja userbezogen ....)

 

Grüsse

 

Gulp

[Sanchooo187 10]

Das hilft mir weiter, vielen Dank für eure kompetente Antwort.