10
Terminalserver ruft Anwendung via Batch nicht korrekt auf
Hallo Board,
ich habe hier auf Arbeit einen Windows 2000 Terminalserver mit SP4 laufen. Darauf ist Citrix Mateframe installiert, welches eine explizite Anwendung für Mitarbeiter freigibt. Es wird kein Desktop gestartet, sprich die Taskleiste ist nicht zu sehen. Beim Verbindungsaufbau wird eine Batch-Datei aufgerufen, in der die Programme verankert sind, die gestartet werden sollen. Zur Zeit ist dies nur die Perinorm (Programm zur Volltextabfrage von DIN-Normen).
Da unser Ausdruckverfahren umgestellt werden sollte, wurde der XPrint-Client von geniusbytes auf diesem Server installiert (kurze Beschreibung: In der Druckerumgebung wurde ein Drucker eingerichtet, der Druckaufträge lokal an einen bestimmten Port sendet. Auf diesen Port lauscht der XPrint-Client, der die Druckaufträge entgegennimmt und diese dann an den XPrint-Server sendet. Dieser hinterlegt die Aufträge in einer MySQL-Datenbank. Dies ist hier jetzt aber eher unwichtig, da der Server von einer anderen Firma betreut wird.)
Beim Drucken auf diesen Drucker erscheint nach dem Absenden der Datei ein kleines Fenster des XPrint-Clients, der eine Authentifizierungsnummer, sowie einen Dokumentennamen erwartet. Dazu muss der Client im Autostart des Nutzer, bzw. in der Batchdatei stehen.
Leider erscheint diese Fenster nicht, wenn ich mich via Citrix auf dem Server anmelde, obwohl für den Nutzer die Rechte auf das Programm gegeben sind und der Aufruf in der Batch-Datei verankert ist.
Melde ich mich direkt lokal am Server an, bzw. mit Administratorrechten über Citrix funktioniert der Client ohne Probleme, bloss eben mit dem normalen Benutzer nicht.
Weiss jemand weiter? Vielen Dank im voraus.
Gruß, 127.0.0.1
ich habe hier auf Arbeit einen Windows 2000 Terminalserver mit SP4 laufen. Darauf ist Citrix Mateframe installiert, welches eine explizite Anwendung für Mitarbeiter freigibt. Es wird kein Desktop gestartet, sprich die Taskleiste ist nicht zu sehen. Beim Verbindungsaufbau wird eine Batch-Datei aufgerufen, in der die Programme verankert sind, die gestartet werden sollen. Zur Zeit ist dies nur die Perinorm (Programm zur Volltextabfrage von DIN-Normen).
Da unser Ausdruckverfahren umgestellt werden sollte, wurde der XPrint-Client von geniusbytes auf diesem Server installiert (kurze Beschreibung: In der Druckerumgebung wurde ein Drucker eingerichtet, der Druckaufträge lokal an einen bestimmten Port sendet. Auf diesen Port lauscht der XPrint-Client, der die Druckaufträge entgegennimmt und diese dann an den XPrint-Server sendet. Dieser hinterlegt die Aufträge in einer MySQL-Datenbank. Dies ist hier jetzt aber eher unwichtig, da der Server von einer anderen Firma betreut wird.)
Beim Drucken auf diesen Drucker erscheint nach dem Absenden der Datei ein kleines Fenster des XPrint-Clients, der eine Authentifizierungsnummer, sowie einen Dokumentennamen erwartet. Dazu muss der Client im Autostart des Nutzer, bzw. in der Batchdatei stehen.
Leider erscheint diese Fenster nicht, wenn ich mich via Citrix auf dem Server anmelde, obwohl für den Nutzer die Rechte auf das Programm gegeben sind und der Aufruf in der Batch-Datei verankert ist.
Melde ich mich direkt lokal am Server an, bzw. mit Administratorrechten über Citrix funktioniert der Client ohne Probleme, bloss eben mit dem normalen Benutzer nicht.
Weiss jemand weiter? Vielen Dank im voraus.
Gruß, 127.0.0.1
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 33653
Url: https://administrator.de/contentid/33653
Printed on: April 18, 2024 at 19:04 o'clock
10 Comments
Latest comment
Moin,
wie ist das, wenn Du dich als normaler Nichtadmin per ICA am Server anmeldest und Du aber einen Desktop hast. Geht das dann? Oder gibt es Fehlermeldungen?
Da es nicht eindeutig hervorgeht: Du hast den XPrint-Client aber mit in das Startskript der User mit eingebunden, so dass wenn die User die Published App aufrufen erst der XPrint-Client und dann die eigentliche Anwendung gestartet wird?
Ralf
wie ist das, wenn Du dich als normaler Nichtadmin per ICA am Server anmeldest und Du aber einen Desktop hast. Geht das dann? Oder gibt es Fehlermeldungen?
Da es nicht eindeutig hervorgeht: Du hast den XPrint-Client aber mit in das Startskript der User mit eingebunden, so dass wenn die User die Published App aufrufen erst der XPrint-Client und dann die eigentliche Anwendung gestartet wird?
Ralf
Sow, ich hab das grad mal mit nem eigenen Desktop für diesen Nutzer probiert, und auch mit Erfolg. Der Druckauftrag wurde erfolgreich versandt. An der Druckerwarteschlange, bzw. an dem eigentlich Druckverfahren dürfte es eigentlich nicht liegen, da das Drucken auf einen "normalen" Drucker ohne Probleme funktioniert.
Beim Startscript wird folgende Reihenfolge beachtet:
Erst der Druckclient, dann die Anwendung für die DIN-Normen.
127.0.0.1
Beim Startscript wird folgende Reihenfolge beachtet:
Erst der Druckclient, dann die Anwendung für die DIN-Normen.
127.0.0.1
Moin,
hmm, hast Du mal mit einer "Pause" oder einem ">" in ein Log im Skript überprüft ob der Print-Client wirklich gestartet wird? Nicht das der gleich wieder abkackelt, weil er z.B. keine grafische Oberfläche gekommt.
Oder kannst auch mit einem Taskmanager in der Adminsession schauen, ob die EXE löppt wenn der User angemeldet ist.
Ralf
hmm, hast Du mal mit einer "Pause" oder einem ">" in ein Log im Skript überprüft ob der Print-Client wirklich gestartet wird? Nicht das der gleich wieder abkackelt, weil er z.B. keine grafische Oberfläche gekommt.
Oder kannst auch mit einem Taskmanager in der Adminsession schauen, ob die EXE löppt wenn der User angemeldet ist.
Ralf
sow, ich hab mal die errormessages in ne log-Datei umgeleitet, mit folgendem Ergebnis:
src\tconfigparser.cpp(64): no such section : guiserver
src\tconfigparser.cpp(64): no such section : common
src\tconfigparser.cpp(128): can not find section common
src\tconfigparser.cpp(64): no such section : guiserver
Ich muss dazu sagen, dass im Hintergrund noch 3 Dienste laufen, die Abhängig sind, damit das Verfahren funktioniert. Zum einen die Druckerwarteschlange (bei Windows Standard), und zum anderen den guiserver und guiclient (werden bei der Installation des Clients eingerichtet). Diese 3 Dienste laufen aber zum Zeit des Aufrufs...
src\tconfigparser.cpp(64): no such section : guiserver
src\tconfigparser.cpp(64): no such section : common
src\tconfigparser.cpp(128): can not find section common
src\tconfigparser.cpp(64): no such section : guiserver
Ich muss dazu sagen, dass im Hintergrund noch 3 Dienste laufen, die Abhängig sind, damit das Verfahren funktioniert. Zum einen die Druckerwarteschlange (bei Windows Standard), und zum anderen den guiserver und guiclient (werden bei der Installation des Clients eingerichtet). Diese 3 Dienste laufen aber zum Zeit des Aufrufs...
also da würd' ich ja mal sagen, dass der XPrint-Client nicht im Kommandozeilenmodus zu starten geht, wenn er schon über GUI-Probleme meckert....
Ich kenn das Xprint nun überhaupt nicht, haben die vielleicht einen DOS-Client, oder einen Schalter, mit dem man den im DOS-Modus starten kann?
Läuft den den EXE nach dem Skriptdruchlauf, oder wird die nach den Fehlermeldungen beendet?
Ralf
Ich kenn das Xprint nun überhaupt nicht, haben die vielleicht einen DOS-Client, oder einen Schalter, mit dem man den im DOS-Modus starten kann?
Läuft den den EXE nach dem Skriptdruchlauf, oder wird die nach den Fehlermeldungen beendet?
Ralf
Naja, wenn es wirklich Probleme mit der GUI geben würde, könnte ich ja den Client nicht über die Konsole des Admins aufrufen. Dies geht aber. Ich nehme haargenau die Befehle, die ich im Startscript auch schon benutze:
m:
cd Programme\geniusbytes\X-Print\guiclient
winstarter
Leider bricht der Client ohne Fehlermeldung ab. Bzw. merkt man eigentlich nur dass der Client nicht läuft, wenn die Perinorm nicht geladen wird. Sprich er hängt...
m:
cd Programme\geniusbytes\X-Print\guiclient
winstarter
Leider bricht der Client ohne Fehlermeldung ab. Bzw. merkt man eigentlich nur dass der Client nicht läuft, wenn die Perinorm nicht geladen wird. Sprich er hängt...
Naja, wenn es wirklich Probleme mit der GUI
geben würde, könnte ich ja den
Client nicht über die Konsole des
Admins aufrufen. Dies geht aber.
geben würde, könnte ich ja den
Client nicht über die Konsole des
Admins aufrufen. Dies geht aber.
Ja, Moment, probierst Du das mit dem Admin mit published Desktop, oder auch nur mit der Application? Denn so wie ich das Problem verstehe, ist es mit Desktop bei allen Usern 8auch nicht Admins) ok. Nur ohne veröffendlichten Desktop geht der X-Print -Client nicht, auch nicht beim Admin. Richtig?
Leider bricht der Client ohne Fehlermeldung
ab. Bzw. merkt man eigentlich nur dass der
Client nicht läuft, wenn die Perinorm
nicht geladen wird. Sprich er hängt...
ab. Bzw. merkt man eigentlich nur dass der
Client nicht läuft, wenn die Perinorm
nicht geladen wird. Sprich er hängt...
Steht denn vielleicht was im Eventlog?
Ralf
So richtig kann ich dir hierauf nicht ganz folgen:
Ja, Moment, probierst Du das mit dem Admin mit published Desktop, oder auch nur mit der Application? Denn so wie ich das Problem verstehe, ist es mit Desktop bei allen Usern (auch nicht Admins) ok. Nur ohne veröffendlichten Desktop geht der X-Print -Client nicht, auch nicht beim Admin. Richtig?
Die Desktops sind alle veröffentlicht. Es meldet sich keiner lokal am Server an, sondern alle über ne ICA-Session.
BTW: Ich hab grad nach nem Eventlog von X-Print gesucht, ohne Erfolg. Im Eventlog von Windows meldet sich auch nix...
Ja, Moment, probierst Du das mit dem Admin mit published Desktop, oder auch nur mit der Application? Denn so wie ich das Problem verstehe, ist es mit Desktop bei allen Usern (auch nicht Admins) ok. Nur ohne veröffendlichten Desktop geht der X-Print -Client nicht, auch nicht beim Admin. Richtig?
Die Desktops sind alle veröffentlicht. Es meldet sich keiner lokal am Server an, sondern alle über ne ICA-Session.
BTW: Ich hab grad nach nem Eventlog von X-Print gesucht, ohne Erfolg. Im Eventlog von Windows meldet sich auch nix...
Hallo,
um mal auszuschließen, das es an fehlenden Berechtigungen im Dateisystem oder der Registrie liegt (auch wenn es mit Desktop geht) versuch doch mal mit dem Admin die published App zu starten. Mal sehen ob es bei dem mit dem Druckclient geht, wenn dieser aus dem Batch gestartet wird.
Wenn es dann auch nicht geht wir es wohl an den XPrint-Client liegen, das der wirklich nicht ohne GUI will.
Ralf
um mal auszuschließen, das es an fehlenden Berechtigungen im Dateisystem oder der Registrie liegt (auch wenn es mit Desktop geht) versuch doch mal mit dem Admin die published App zu starten. Mal sehen ob es bei dem mit dem Druckclient geht, wenn dieser aus dem Batch gestartet wird.
Wenn es dann auch nicht geht wir es wohl an den XPrint-Client liegen, das der wirklich nicht ohne GUI will.
Ralf
Morgen,
sprich, ich soll mich als Admin anmelden und die Batch, bzw. den Client ausführen? Kann ich beantworten, das geht.
Ich hab auch grad mal den Client über RUNAS und Admin versucht auszuführen, bloss kommt da dann ein Fehler beim Laden der DLL (Meldung: "Fehler beim laden einer Programm-DLL - OK"). Der RUNAS-Syntax war wie folgt: "runas /user:server1\administrator guiclient". Vorher kam natürlich noch ein Verz-Wechsel in das Programmverzeichnis.
sprich, ich soll mich als Admin anmelden und die Batch, bzw. den Client ausführen? Kann ich beantworten, das geht.
Ich hab auch grad mal den Client über RUNAS und Admin versucht auszuführen, bloss kommt da dann ein Fehler beim Laden der DLL (Meldung: "Fehler beim laden einer Programm-DLL - OK"). Der RUNAS-Syntax war wie folgt: "runas /user:server1\administrator guiclient". Vorher kam natürlich noch ein Verz-Wechsel in das Programmverzeichnis.
