Softwareverteilung auf Windows-Terminalserver

[Stefan W]

Es scheint zu funktionieren. Es kam zumindest zu keiner Fehlermeldung. Ich muss gleich nur noch mal überprüfen ob ich das ausführen der change.exe user /install irgendwo in dem Log finde.

[ueluekmen]

Das klingt doch erstmal gut. Vor und nach dem actionprocessor start müsste das eigentlich gelogged werden. Aber um sicher zu gehen, würde ich in der Ereignisanzeige nachschauen, der WTS Server müsste den Moduswechsel in die Ereignisanzeige eintragen. Dann kann man sich auch sicher sein, das der Moduswechsel tatsächlich klappt.

[Stefan W]

Leider wird der Modus in der Ereignisanzeige nicht angezeigt. Ich habe versucht in der pre-action die Ausgabe in eine Datei zu pipen, jedoch wird diese Datei mit dem entsprechenden Inhalt nicht erstellt. In der post-action habe ich den Eintrag für execute entfernt. Nach der Installation befindet sich das System noch in dem Installationsmodus. Jedoch kann ich nicht sagen ob das System in den Modus gewechselt hat oder ob es wirklich das Skript war. Kann ich in den Aufruf irgendwo in der Opsi-log finden?

[ueluekmen]

Hi,

tja... ich wäre jetzt davon ausgegangen, dass man so einen Moduswechsel schon irgendwie aufzeichnen sollte. Aber das beweist mal wieder, das in Redmond die Uhren etwas anders ticken als auf dem Rest der Erdkugel.

Das es funktioniert, zeigt dein Test mit dem Post-Command eigentlich.

Such mal in der opsiclientd.log nach einer Logmeldung wie:

Code: Alles auswählen

Starting pre action processor command

Was der genau loggt, hängt ein bisschen von dem Loglevel ab. Aber ich würde behaupten, der tut.

[Stefan W]

FYI
Also in der log-Datei sehe ich, dass der Befehl ausgeführt wird und es kommt auch zu keiner Fehlermeldung. Auf den Terminalserver scheint der direkte aufruf der change.exe im System32 Verzeichnis zu funktionieren. Wir haben das jetzt folgendermaßen gelöst. Wir haben für die Installation von XenApp ein update script gebaut. Dieses macht nix anderes als nach der Installation von xenapp die opsiclientd.conf in das tmp verzeichnis zu sichern und passt die originaldatei mit "patchtextfile" an. Bin gerade dabei es auf den Servern zu testen. Aber die ersten Tests waren erfolgreich.

[ueluekmen]

Hi,

verstehe jetzt nicht wirklich, was genau bezweckt wird mit der Aktion, aber ich würde die opsiclientd.conf nicht aus dem Verzeichnis rauskopieren. Das Verzeichnis von der conf ist mit hohen Rechten geschützt, da sich dadrin der Hostkey des Clients befindet. Da bohrt man sich ein riesen Loch in die Security, denn das tmp Verzeichnis ist auf Durchzug geschaltet, was die Rechte angeht.

Wenn damit bezweckt wird, die Einträge für die pre und post action ein zu tragen, empfehlen wir eher diese Konfiguration per Hostparameter im Webservice zu lösen.

[Stefan W]

Wir sichern die Datei nur an eine andere Stelle und modifizieren sie dann im opsiclientd verzeichnis wo sie standardmäßig abgelegt wird

[Konstantin]

Hallo Zusammen,

ehrlich gesagt verstehe ich nicht ganz die Problematik und wieso es auf einmal so komplex werden muss!

Soweit ich weiß gibt es seit Windows 2000 unter einem WTS Server unabhängig von Processor Architecture, ein Registry DWORD TSAppCompat, zu finden unter HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server.
Ist der Wert von TSAppCompat gleich 1, sind die Terminal bzw. Remote-Desktop-Dienste auf dem Rechner aktiviert.
Bei Desktop OS gibt es solch einen Dword Eintrag nicht.

http://support.microsoft.com/kb/243215/en
http://support.citrix.com/article/CTX123097

Also, muss ich nur aus dem opsi Script die Existenz und den Wert prüfen und zwei Dosbatch oder Dosinanicon Subs definieren.


Gruß

Konstantin