usrlogon.cmd-Problem auf Terminalserver?

[cjmatsel 10]

Hi,

 

ich habe ein Problem und erhoffe mir Hilfe: Eines unserer "Spezielprogramme" weigert sich, auf dem Terminalserver zu laufen. Wenn man sich aber zum Server bewegt und dort anmeldet, dann klappts problemlos. Deswegen vermute ich ein Problem durch die usrlogon.cmd

 

Könnte mir jemand sagen worin Microsoft den Unterschied erkennbar macht zwischen Konsole, dem Befehl "mstsc /console" und "mstsc"? Wo gibts weitere Informationen zur usrlogon.cmd? Über Tipps und Links zu dem Thema wäre ich echt dankbar...

 

cu,

cjmatsel

[Wolke2k4 11]

- Das Programm ist also auch via mstcs /console startbar?

- Wenn Du Dich als Nutzer "physisch" am TS anmeldest geht es auch?

- Ganz wichtig und immer Nr. 1 auf der "Need to know" Liste: Was sagt der Hersteller zum TS Betrieb

[cjmatsel 10]

Hi Wolke2k4,

 

zu Punkt 1: nein, aber wenn ich es lokal starte und danach mstsc /console aufrufe, dann kann ich im Programm weiterarbeiten, also wird irgendwas beim Start geprüft...

zu 2: siehe 1; physisch am TS gehts ohne Probleme

zu 3: keine definierte Auskunft vom Hersteller, hier wird sehr mit Informationen gespart, es könnten ja Betriebsgeheimnisse sein...

 

Momentan stütze ich mich auf das Ende von Punkt 1. Es wird irgendwas geprüft. Es läuft ja ne usrlogon.cmd ab zum Beispiel. Die habe ich mal weggenommen, dann kam zumindest einen längeren Augenblick das Startfenster... Woran erkennt Windows, dass die usrlogon.cmd abgearbeitet werden soll?! Irgendwo im System muss das doch erkennbar sein. Weisst Du mehr über die Arbeitsweise eines TS an sich? Ich denke, dass mir solche Infos sehr hilfreich für die Zukunft sein werden, da wir mehrere solcher Programme besitzen (und auch solche Hersteller dazu)...

 

cu,

cjmatsel

[Wolke2k4 11]

Die Batch wird wohl über das ADS an die Nutzer gebunden sein, so ist es in der Regel in den meisten Umgebungen. Ein nackter ADS Nutzer hat kein Script/Batch was bei seiner Anmeldung gestartet wird von daher sollte auch keines ausgeführt werden... Wo Du die usrlogon.cmd kommt müsstest Du bzw. ein anderer Admin eigentlich wissen.

 

Was passiert eigentlich, wenn Du Dich am TS mit einem lokalen TS Nutzer anmeldest, dich also nicht in der Domain sondern direkt am TS?

 

Und beim Hersteller würde ich an Deiner stelle etwas hartnäckiger sein. Irgendeinen Menschen, der eine Aussage zur Lauffähigkeit auf TS geben kann wird es sicher geben.

 

Ansonsten kann ich Dir noch Filemon und Regmon ans Herz legen. Führe es einmal in der TS Session und dann noch mal direkt am TS aus.

[cjmatsel 10]

Hi Wolke2k4,

 

die Batch liegt ja in system32 und es gibt einen Reg-Eintrag, welcher dafür sorgt, dass die Datei abgearbeitet wird. Weiteres dazu findet man auf den Suchen im Internet. Allerdings stellt sich mir immer noch die Frage, woher Windows den Unterschied zwischen lokaler Anmeldung und "mstsc /console" erkennt.

 

Was meinst Du mit der Frage was passieren sollte? Am TS gibts nur nen Administrator, normale Benutzer dürfen sich doch meines Wissens gar nicht lokal anmelden, oder liege ich da falsch?

 

Bei Hersteller will ich nicht allzuviel Aufsehen erregen. Die Standard-Antwort lautet momentan:"geht nicht und wollen wir auch nicht!" Mit filemon und regmon krieg ich nen ganzen Berg von Informationen. Da was rauszulesen, was mir weiterhilft, wird sehr schwer sein. Allerdings hab ich mir schon einige Protokolle abgespeichert, mal schauen, was windiff dazu sagt ;-)

 

Nur wahrscheinlich bin ich schneller, wenn ich GENAU weiss, worin die oben gefragten Unterschiede liegen. Dann weiss ich nämlich auch, warum die Software nur beim Starten Probleme bereitet. ;-) Ist zumindest meine Vermutung, das ich dann schlauer bin, hehe...

 

cu,

cjmatsel

[Wolke2k4 11]

Lass mich lügen aber bei einem frisch aufgesetzten TS innerhalb einer Domain kommt einem Nutzer keine usrlogon Batch aus dem System32 Ordner entgegengepfeffert. Habe bis zu deinem Thread auch noch garnicht so viel von dem Ding gelesen (außer hier )

 

Wenn ich einem TS User ein Anmeldeskript zuweisen möchte nehme ich normalerweise das Script was im Sysvol Ordner liegt (also entpsrechend zugewiesen über das ADS) oder via GPO, nur bei der TS Anmeldung.

 

Wenn die usrlogon das Problem verursacht dann nimm doch einfach mal den Regeintrag raus...

 

Zur lokalen Anmeldung:

 

Erstelle auf dem TS einen Nutzer und gewähre diesem das Recht sich am TS anzumelden (in der Regel via Mitgliedschaft der Remotedesktopnutzer). Dann testest Du wie es mit diesem Nutzer ausschaut. Allerdings wird bei diesem dann wohl auch die usrlogon ausgeführt.

[zuschauer 10]

Hi !

Ist das eine dongle-geschützte Software ?

geht nicht und wollen wir auch nicht!"

Das ist doch eine eindeutige Aussage, die Nutzung der Software in TS-Sessions ist nicht erwünscht vom Hersteller ! :suspect:

[cjmatsel 10]

@Wolke2k4: Ja, irgendwie so einen oder sogar den gleichen Thread meinte ich. Ich weiss jetzt zwar nicht, wie sich NT4 oder NT5 verhält, aber bei dem Terminalserver (W2k3-SR2), den ich gerade testweise aufgesetzt habe, läuft die usrlogon.cmd durch. Dann scheint Winzigweich das erst später eingebaut zu haben. Das mit dem Nutzer werde ich morgen mal testen. Hast Du jede Software auf dem TS zum Laufen bekommen?

 

@Zuschauer: Nein. Grundsätzlich haste ja recht, und schliesslich bezahle ich die Windows-Lizenzen ja nicht (bin ja nur der Admin, nicht der Geschäftsführer), aber trotzdem ist das ganz schön nervig, wenn irgend ein Software-Hersteller mir Klötze zwischen die Beine (oder die meines Systems) wirft. Ich will hier ja niemanden um Lizenzen prellen (von wegen weil die Software ja nachher nur noch auf dem TS liegt), aber grundsätzlich muss es doch möglich sein, als Administrator die Hoheit über seinem Netz zu haben?!

 

Ich habe mittlerweile gehört, dass es von Citrix sowas wie eine Sand-Box-Umgebung geben soll, die störrischen Programmen auf die Beine hilft. Dumm nur, dass ich noch keine Zeit hatte, unsere Citrix-CDs mal zu installieren und für unsere User freizugeben. Da muss ich noch n bisschen darüber lernen und lesen, denke ich...

[Wolke2k4 11]

Spontan fällt mir keine Anwendung ein, bei der ich sagen musste: Geht nicht, nicht TS fähig. Allerdings habe ich das Glück, dass wir viele kommunale Kunden betreuen. Die Softwarelandschaft hier ist zwar nicht gerade klein aber letztenendes sind es immer die gleichen Anwendungen auf die man stößt.

Die Softwarehersteller haben erkannt, dass sie um die Lauffähigkeit ihrer Anwendungen auf TS nicht mehr herum kommen und haben diese dementsprechend angepasst.

 

Aber natürlich gibt es auch Anwendungen, die nicht für den TS Betrieb geeignet/programmiert sind. Und auch wenn eine Anwendung auf einem TS läuft, also sich starten lässt, heisst das nicht automatisch, dass man sie dann auch nutzen kann. Interessant wird es meist erst, wenn es um das Drucken geht.

 

Aber jetzt wo du W2K3 R2 erwähnst muss ich mal überlegen... Das letzte TS Kundensystem war noch ein "nicht R2". Mein letzter R2 Server war ein einfacher Datenbankserver. Muss wohl mal einen R2 TS aufsetzen. Ich war bisher der Meinung, dass sich für den TS mit R2 nichts geändert hat, lasse mich aber gern eines Besseren belehren. Der nächste Kunden TS kommt bald... :)

 

Übrigens ist der Presentation Server von Citrix auch keine Eier legende Wollmilchsau und die AIE (die Du wahrscheinlich meinst) hat auch ihre Macken. Aber Tests können sicher nicht schaden.

[zuschauer 10]

Hi cjmatsel !

 

Mein Frage zu dem Dongle rührt daher, dass genau Deine Problembeschreibung beim Einsatz eines Einzelplatz-Dongles an einem TS-Server auftritt (wenn er vom Softwarehersteller dementsprechend vorbereitet war).

 

Solang der Dongle direkt am PC angesprochen wird, funktioniert es, aber selbst mit mstsc /console funktioniert es nicht (daher ist diese Consolen-Session für mich auch nicht wirklich eine Original-Session, merkt man auch bei anderen Gelegenheiten ;) ).

Wenn man die Console nach dem Prüfen des Dongles in mstsc /console übernimmt, läuft es.

 

Was ein Dongle-Hersteller mit seinem Kopierschutz bewerkstelligen kann, kann auch jeder andere Softwarehersteller realisieren. Ich gehe daher davon aus, das Dein Problem vom Softwarehersteller so gewollt ist, dieser es aber in der Deutlichkeit nicht publiziert, warum auch immer.

 

An der usrlogon.cmd liegt es ganz sicher nicht. ;)

[cjmatsel 10]

Hmm,

 

es gab mal donglegestützte Software von dem Hersteller, aber diese wird per Netzwerksserver gesteuert... Ist natürlich die Frage, ob mehr dahinter steckt... Kann man sowas nicht trotzdem irgendwie umgehen? Allerdings sollte ich erstmal hierzu die Lizenzbedingungen konsultieren *hüstel*

 

Trotzdem danke für den Tip...

 

cu,

cjmatsel