Zugriff auf Dongel von Gastsystem aus? Mal gehts, mal nicht.

[white-horse]

Hallo Zusammen,

wir haben mit der wunderschönen kostenlosen VMware Server beta Version einen Rechner aufgesetzt. Host ist ein Debian Linux mit 2.4.27 Kernel. Als Gast läuft eine Windows XP Maschine drauf, die einen Dongel benötigt.

Nach der Konfiguration des Gastes wurde der Dongel auf gefunden, wunderbar. Es mussten lediglich vom Host einige Dienste (cron, xprint) beendet werden. Nach kurzer Zeit allerdings meckert mein Gast das kein Dongel zu finden ist, ohne das irgendeine Einstellung geändert wurde.

Ist das ein Problem von der Beta Version? Hat jemand damit schon Erfahrung sammeln können?

Danke für Tips

Gruß

Patrick

[white-horse]

Hallo,

vielleicht kann es ja mal jemand brauchen. Ich habe den Fehler gefunden.

Wenn man sich am XP Gast das erste mal nach dem booten lokal, also über die VMware Console anmeldet, geht es. -> Dongel da.

Wenn man sich am XP Gast das erste mal nach dem booten über RDP anmeldet geht es nicht -> kein Dongel da.

So einfach kann es sein.

Gruß

Patrick

[al!ve]

Was für ein Dongle ist es denn? USB, LPT oder COM?
Und um welche Software handelt es sich?

Nicht dass ich dir da helfen könnte, aber ich werde demnächst selbst eine Software aufsetzen, die durch einen Dongle geschützt ist -- einen DATEV LizenzManager. Dieser ist sowohl LPT als auch COM als auch USB verfügbar. Abhängig davon was nun geht und was nicht werde ich einen davon verwenden. Ich hatte gehofft LPT nutzen zu können, um den USB-Support in der VM abschalten zu können.

[white-horse]

Hallo al!ve

Es handelt sich um einen LPT-Dongel. Wenn man sich "lokal" anmeldet, läuft er wunderbar. Auf dem ESX-Server hatte ich damit garkeine Probleme, da ist es auch egal ob man sich lokal anmeldet oder via RDP.

Gruß

Patrick

[al!ve]

Öhm. Und wie sieht es mit der Unterstützung aus, wenn du garnicht angemeldet bist?

Aber eigentlich kann ich mir dieses Verhalten garnicht erklären. Die VM sieht doch garnicht, ob ein Benutzer an der Console sitzt oder nicht. Wenn keiner dran sitzt, denkt das Gast-System lediglich, es käme keine Eingabe.

Kann es sich hierbei vielleicht um ein Problem deiner Software handeln, dass die Dongle-Unterstützung schlicht nur bei lokalen Anmeldungen funktioniert? Dass die VM abhängig davon ob die Verbindung per RDP (also ne reine Windows-Socket-Geschichte) oder per Console (also Gast-Unaghängig, ne reine VMWare-Geschichte) die Geräte an und absteckt kann ich mir nicht vorstellen. Dass aus Sicherheitsgründen deine Software den Dongle nur sieht, wenn der Benutzer Lokal vor dem Rechner sieht, kann ich mir allerdings doch wieder recht gut vorstellen.

[white-horse]

Öhm. Und wie sieht es mit der Unterstützung aus, wenn du garnicht angemeldet bist?

Das kann ich dir leider nicht sagen da der Dongel nur für den lokalen Client gilt. Ich muss mich also anmelden um überhaupt ins Programm zu kommen

Aber eigentlich kann ich mir dieses Verhalten garnicht erklären. Die VM sieht doch garnicht, ob ein Benutzer an der Console sitzt oder nicht. Wenn keiner dran sitzt, denkt das Gast-System lediglich, es käme keine Eingabe.

..da stimme ich dir zu -> aber es ist halt so, zumindest bei meiner Konfiguration...

Kann es sich hierbei vielleicht um ein Problem deiner Software handeln, dass die Dongle-Unterstützung schlicht nur bei lokalen Anmeldungen funktioniert?

Das kann schon ein Problem der Software sein, das kann ich weder ausschließen noch bestätigen. Allerdings funktioniert das Programm - somit der Dongel - auch über RDP. Lediglich, die erste Anmeldung muss lokal geschehen, danach ist es egal wie man auf dem Client zugreift.

Dass die VM abhängig davon ob die Verbindung per RDP (also ne reine Windows-Socket-Geschichte) oder per Console (also Gast-Unaghängig, ne reine VMWare-Geschichte) die Geräte an und absteckt kann ich mir nicht vorstellen. Dass aus Sicherheitsgründen deine Software den Dongle nur sieht, wenn der Benutzer Lokal vor dem Rechner sieht, kann ich mir allerdings doch wieder recht gut vorstellen.

siehe oben

[Martin]

Kann es sein, daß über den RDP-Zugriff versucht wird, den LPT-Port zum Client umzuleiten? Eventuell geht dies dann nach einem lokalen Logon nicht mehr, da der LPT-Port dann schon im Zugriff ist und daher nicht mehr zum Client "verbogen" wird...

Martin

[al!ve]

Das klingt eigentlich sehr logisch, bei näherer Betrachtung aber auch ein wenig nicht.

Ich will hier nicht die Idee klauen, nur vielleicht etwas erweitern. Seit der neuesten RDP-Version -- die im 2003er Server und in WindowsXP verbaut ist -- lassen sich am Client befindliche Komponenten zum Diensterbringer umleiten. Neben der Soundkarte (Ausgabe des Sounds des Remote-Rechners am Remote-Rechner oder am zugreifenden) sind das Laufwerke und Drucker (beides meines Wissens über die Datei- und Druckerfreigabe, welche automatisiert beim Login angestoßen wurd) sowie Serielle Anschlüsse.

"Die Klammer machts". Da der Drucker des angreifenden Rechners per Datei- und Druckerfreigabe zum Remote-Rechner verbunden wird, sollten sich hier keine Probleme im Zusammenhang mit dem lokalen LPT-Port ergeben.

Einfach mal ausprobieren


Handelt es sich bei der VM eigentlich um eine neu installierte oder um eine vom ESX umgezogene? Vielleicht ist es auch eine Windows-Einstellung, den LPT-Port erst nach dem ersten Login zu verbinden. Wenn dies fehl schlägt, wenn der erste Login Lokal war, wäre das eine Erklärung für den Fehler.

[white-horse]

Kann es sein, daß über den RDP-Zugriff versucht wird, den LPT-Port zum Client umzuleiten? Eventuell geht dies dann nach einem lokalen Logon nicht mehr, da der LPT-Port dann schon im Zugriff ist und daher nicht mehr zum Client "verbogen" wird...

Martin

Hallo,

das war auch einer meiner ersten Gedanken. Ich hab mir natürlich die RDP-Clienteinstellungen genauer angeschaut und damit "gespielt" - sprich lokale Ressourcen (Drucker) verbunden bzw. eben nicht verbunden - allerdings macht es keinen Unterschied, der Effekt war immer der gleiche. -> ging nicht