TS - Anwendungsserver für Dummies

[fred-art 10]

So, kaum kann ich mit dem TS arbeiten, schon stellen sich neue Fragen.

 

In der Hoffnung, dass mir wieder so schnell geholfen wird, stell ich sie mal hier.

 

Das Konstrukt:

Es steht ein W2K-DC standalone. Am lokalen Netzwerk angeschlossen 8 XP-Clients. Weitere 3 XP-Clients sollen über ein VPN mit TS angebunden werden. Diese befinden sich zusammen in einem entfernten Netzwerk.

Das funktioniert so weit auch schon. Zumindest mit der Remote-Konsole kann ich auf den Server zugreifen und diesen administrieren.

TS-CAL's sind vorhanden.

Auf dem Server ist eine Software installiert, die im wesentlichen aus einer Datenbank besteht. Die lokalen Benutzer greifen lediglich über eine Desktop-Verknüpfung auf das Programm zu.

 

Wie kann ich so eine Verknüpfung für die TS-Clients anlegen. Normalerweise müsste ich ja die Software nach 'Change user/install' neu installieren. Das möchte ich jedoch vermeiden.

 

Remote Desktop darf ich nur als Admin benutzen oder? Das habe ich aus den Lizenzbestimmungen nicht eindeutig herauslesen können. Kann/darf ich im entfernten Netzwerk mehrere Remote-Desktop Sitzungen gleichzeitig aufmachen? Es liegt mir fern, etwas zu tun, was ich nicht darf!

 

Vielen Dank schonmal für Eure Hilfe.

 

Fred

[Wolke2k4 11]

????

Melde die Nutzer am TS Desktop an und verknüpfe die Anwendung auf den Desktop. Der Anwendungsstart über den Programmpfad des RDP Clients ist Schnulli und funktioniert nicht sauber, da meistens die Session nicht korrekt terminiert wird.

 

Anwendungen auf einem TS installiert man generell immer erst dann, wenn dieser TS ist, nicht vorher.

Datenbanken haben eigentlich auch nichts auf dem TS zu suchen, genausowenig wie generell irgendwelche Daten auf dieser Serverart nicht liegen sollten.

Natürlich muss man sich den Gegebenheiten anpassen aber empfehlen würde ich es nicht.

 

Was mir noch aufgefallen ist. Wo und an welcher Stelle steht Dein TS? Ich hoffe nicht, dass Dein DC der TS sein soll?

[fred-art 10]

????

Melde die Nutzer am TS Desktop an und verknüpfe die Anwendung auf den Desktop. Der Anwendungsstart über den Programmpfad des RDP Clients ist Schnulli und funktioniert nicht sauber, da meistens die Session nicht korrekt terminiert wird.

 

Ja, sowas hab ich mir schon gedacht.

 

Anwendungen auf einem TS installiert man generell immer erst dann, wenn dieser TS ist, nicht vorher.

Datenbanken haben eigentlich auch nichts auf dem TS zu suchen, genausowenig wie generell irgendwelche Daten auf dieser Serverart nicht liegen sollten.

Natürlich muss man sich den Gegebenheiten anpassen aber empfehlen würde ich es nicht.

 

Nun ja, ich bin dazu gekommen wie die Jungfrau zum Kind. Ich selber würde das ja grundsätzlich anders aufbauen. Das Problem: Es gibt nur einen einzigen Server. Dieser steht in einer Arztpraxis und das schon seit mehreren Jahren. Natürlich läuft da die elektronische Karteikarte/Abrechnung drauf und die wurde vor Kurzem erneuert. in einer zweiten Praxis, 20km entfernt stehen 3 Clients, die da auch ihre Daten reinhacken sollen. Mit der alten Software wurde das über PC-Anywhere und AnalogModem gelöst, ein haarstäubendes Konstrukt, alleine was das Auslesen der Patientenkarten betrifft :)

Klar, dass ich diese Software nicht so einfach löschen und neu aufsetzen kann, sonst hätte ich den Server gleich komplett neu gemacht. Einen zweiten Server versuche ich ihnen auch schon längere Zeit schmackkahft zu machen. Oder sogar noch nen dritten im entfernten Standort, der sich repliziert.

Ich bin Nachrichtentechniker und an sich eher für die Kommunikationslösungen zuständig, mit 'normalen' Netzwerken hab ich auch Erfahrung. Terminal-Lösungen hatte ich bisher noch nie realisiert. Deshalb auch mein unbedarftes Fragen ;)

 

Was mir noch aufgefallen ist. Wo und an welcher Stelle steht Dein TS? Ich hoffe nicht, dass Dein DC der TS sein soll?

Da ich nur einen Server habe, ist das auch der DC. Zumindest bis ich die Doktores davon überzeugt habe, nen zweiten Server dazuzustellen.

Dass das vorhandene Konstrukt nicht gut ist weiß ich, aber Deiner Frage nach muß es wohl eher ein Unding sein

Geht das so überhaupt nicht? Wurde von der Softwarefirma so als lauffähig angepriesen (die haben sich allerdings aus dem Staub gemacht :rolleyes: , weshalb man mich da hingeschickt hat).

 

Fred

[Dr.Melzer 191]

Mal ganz ehrlich und ohne dir zu nahe treten zu wollen.

 

Terminalserver sin dwie Mädchen. Sehr vorsichtig anzufassen und wenn du nicht aufpasst ist Gezoicke angesagt und du hast den Rest deiner Beziehung Stress an der ABcke.

 

Wenn du zum einen nicht wirklich fit in IT Dingen (du sagst selbst dass du eigentlich Nachrichtentechniker bist) und zum anderen noch weniger Erfahrung mit Terminalservern hast, lass die Fibger davon.

 

An Systemen rumzudocktern, die andere vermurkst haben ist als Vollprofi schon hart genug, aber als quasi Laie ist es aussichtslos, vor allem in Zusammenhang mit einem Terminalserver und Software die womöglich dafür weder geeignet, noch zertifiziert ist.

 

So wie es aussieht kannst du dabei nur verlieren und ich empfehle dir auf das bischen Kohle zu verzichten und dir eine Menge Ärger zu ersparen.

[Wolke2k4 11]

Na ja so stressig würde ich die Sache nicht sehen. Fred sollte nur zusehen, dass er eine einigermaßen saubere Umgebung draus machen kann (sofern er sich dazu in der Lage fühl :)).

Dazu gehört auch, dem Kunden zu erklären, dass er mit einer Zeitbombe arbeitet. Diese "Eierlegendenwollmilchsäue" sind zwar gern bei den Kunden gesehen, weil sie Geld sparen aber in der Praxis machen sie irgendwann Probleme.

Meistens gibt es diese immer dann, wenn irgendwelche dahergelaufenen Softwarehersteller meinen sie hätten Ahnung von Windows Systemen und installieren ihre Software wie ein Elfant im Porzellanladen Walzer tanzt.

 

Wir haben derzeit nur einen Kunden, der einen solchen Server einsetzt. Das Ding läuft zwar sauber und stabil (selbst nach SP2) aber "schön" ist es nicht. ;)

[fred-art 10]

Danke Euch erstmal für Eure Antworten.

Zu Windows NT-Zeiten habe ich aktiv Server betreut. Mit dem AD hat sich aber einiges verändert. Aber Angst habe ich deswegen nicht davor.

Ihr habt natürlich recht, dass dieses Konstrukt so sehr suboptimal ist, ich weiß, wie ne ordendliche Domäne aufgestellt sein sollte und habe das auch als Epfehlung an die Doktores weitergegeben. Ebenso hab ich sie auf das Risiko der momentanen Lösung hingewiesen und darauf, dass ich kein Profi im Bereich TS bin und deshalb keine Haftung übernehme. Von daher bin ich vorerst mal aus dem Schneider.

Für die Praxen soll erstmal ein funktionsfähiger Betrieb hergestellt werden, dann werden wir uns um ein neues Konzept bemühen.

 

Diese "Eierlegendenwollmilchsäue" sind zwar gern bei den Kunden gesehen, weil sie Geld sparen aber in der Praxis machen sie irgendwann Probleme.

Meistens gibt es diese immer dann, wenn irgendwelche dahergelaufenen Softwarehersteller meinen sie hätten Ahnung von Windows Systemen und installieren ihre Software wie ein Elfant im Porzellanladen Walzer tanzt.

 

Ja, das ist genau das Problem, was ich in vielen Praxen sehe. Die Anbieter dieser Abrechnungssoftwaren verkaufen eine Minimal-Hardware-ösung, um die Kosten ihrer Software zu kaschieren. Und wenn dann irgendwas nicht geht, dann beschränken sie sich auf den Support ihrer Software. So auch hier.

 

Aktueller Stand: Ich habe gestern anhand von MS-Tech- Hinweisen den Terminalserver konfiguruiert und kann mich da jetzt mit den unterschiedlichen Benutzern sauber anmelden, jeder bekommt seine Oberfläche zugewiesen und Drucken etc. funktioniert auch.

 

Aktuelles Problem: Wenn ich vom entfernten Standort eine Verbindung aufbaue, dann klappt alles wunderbar. Starte ich eine zweite Verbindung, dann kann ich den VPN-Tunnel noch öffnen, mich aber nicht am System anmelden (Fehlermeldung: Das System ist ausgelastet...)

Bei mir zu Hause hatte ich das gestern mit zwei Rechnern probiert, da klappt es einwandfrei, an der Server.Konfiguration kann es also nicht liegen, und die 10 TS CAL's sollten auch reichen.

 

Kann es sein, dass das entfernte Netz nicht im gleichen IP-Adressegment liegen darf ? Denn das ist der einzige Unterschied, zu mir nach Hause, der da zum Tragen kommen könnte.

ServerNetz: 192.168.10.100-150

Entferntes Netz: 192.168.10.0-64

Mein Netz: 192.168.1.XXX

 

(DHCP etc. sind so konfiguriert, dass sich die Adressbereiche nicht überschneiden.)

 

Hat da jemand nen Tipp für mich?

 

Fred

[Wolke2k4 11]

Kann es sein, dass das entfernte Netz nicht im gleichen IP-Adressegment liegen darf ? Denn das ist der einzige Unterschied, zu mir nach Hause, der da zum Tragen kommen könnte.

ServerNetz: 192.168.10.100-150

Entferntes Netz: 192.168.10.0-64

Mein Netz: 192.168.1.XXX

 

Der Server wird Anfragen vom 10-er Netz nur lokal beantworten. Das die Pakete für das entfernte Netz über ein Gateway geroutet werden müssen kann er nicht wissen. Das würde nur gehen, wenn Du die VPN Verbindung bridgen würdest. Ich bezweifle jedoch, dass das so ohne weiteres mit der vorhandenen Technik möglich ist.

[fred-art 10]

Servus Wolke,

 

na ja, aber einen Terminal-Teilnehmer aus dem entfernten Netz bekomme ich ja an den Server. Erst der zweite wird nicht mehr zugelassen. Von mir zu Hause bekomme ich meine beiden Rechner an den Server, allerdings mit anderem Adressbereich. Genau das versteh ich nicht.

 

Das VPN vergibt ja für die Verbindung eine eigene IP-Adresse, allerdings auch im 10er Bereich.

 

Ich werd wohl mal vor Ort fahren und den Adressbereich des entfernten Netzes ändern auf 192.168.20.xx

Damit sollte ich ausschließen können, dass es vielleicht doch irgendwelche Duplikate im Netz gibt, auch wenn das von der Konfiguration her ausgeschlossen sein sollte.

 

Fred

[Wolke2k4 11]

Frag nicht warum, ich weiss nur, dass es eigentlich garnicht gehen darf. ;) Hab in der Beziehung schon die dollsten Dinger erlebt.

 

Lancom z.B. bietet die Möglichkeit über eine Funktion (hab den Namen leider nicht parat) zwei gleiche IP Netze miteinander zu routen. Aus Faulheit habe ich mal diese, auf den ersten Blick, geniale Funktion nutzen wollen. Als es dann später darum ging eine bzw. mehrere ICA Sessions darüber zu fahren schlug dies fehl. Das interessante war, dass Ping und benutzerdefinierte ICA Verbindungen sehr wohl funktionierten... IP technisch stand also die Verbindung und ICMP war ok.

Wir haben es dann sein gelassen und das Außenstellennetz umgestellt (betraff Gott sei Dank nur 6 Clients und einen NT Server).

[fred-art 10]

Das ist schon mal ne Aussage.

Damit bestätigt sich mein Verdacht auch insoweit.

Das Schlimme dabei: Das entfernte Netz habe ich damals neu aufgesetzt und per VPN angebunden, mit einer 192.168.20er IP-Adressierung. Anforderungen von Seiten des Kunden hatte ich keine.

 

Dann kam die Softwarefirma, die damals schon die alte PC-Anywhere Lösung verkauft hatte und hat ihre neue Software eingespielt. Soweit lief alles ganz normal. Nur die Kartenleser für die Chipkarten haben im entfernten Standort nicht funktioniert (am Serverstandort wurden sie nicht gewechselt). Der Grund läge daran, dass die Rechner, an denen diese angeschlossen waren, im falschen Adressbereich lägen.

Da ich keine Ahnung hatte, wie genau deren Software was macht, hab ich das halt umgestellt. Leider ohne Erfolg :)

Der nette Herr, der die Software aufgespielt hat, war am nächsten Tag weg und die Karten konnten noch immer nicht eingelesen werden. Angeblich, weil meine XP-Rechner falsch konfiguriert wären. Ich hätte ihn gern gewürgt, wenn ich ihn noch erwischt hätte. Da ich halt noch greifbar war, wurde ich mit der Problemlösung beauftragt und hab die Ursache auch schnell gefunden: RX und TX-Leitung am Schnittstellenkabel der Kartenleser mußten getauscht werden.

 

Na ja, sind auch nur 4 Rechner, zwei Drucker und der Router, also sooo dramatisch ist es auch nicht, das wieder umzustellen. Die Mädels dort sind auch alle nett, von daher lohnt die Anfahrt allemal ;)

 

Danke für Deine Antwort, ich werd Dich auf dem Laufenden halten, wie es ausgeht ;-)

 

Fred

[Wolke2k4 11]

Der Grund läge daran, dass die Rechner, an denen diese angeschlossen waren, im falschen Adressbereich lägen.

Da ich keine Ahnung hatte, wie genau deren Software was macht, hab ich das halt umgestellt. Leider ohne Erfolg :)

 

:D Wir lieben sie doch alle, unsere Third Party Softwarehersteller. Ich sehe das so... ohne sie hätten wir weniger zu lachen... :D