Nachteile/Probleme permanente RDP-Session

[overlord 10]

Guten Morgen,

 

ich könnte etwas Argumentationshilfe gebrauchen, zunächst zum Hintergrund:

 

Ich bin gerade in ein Entwicklungsprojekt gerutscht, bei dem ua eine Schnittstelle inkl. Monitoringtool extern programmiert wird/wurde.

Auf dem Client wird eine .exe gestartet, die Produktionsrückmeldungen in eine DB schreibt.

Die Serveranwendung läuft auf einem 2003er, setzt aber einen angemeldeten User voraus, da das Monitoringtool den Clientconnect visuell darstellt und ohne angemeldeten User so etwas ja nicht geht.

 

Was ich nicht verstehe, wieso man die Applikation nicht als Dienst programmiert hat und die Visualisierung vom Client aus (sofern man es zwecks debugging oder Kontrolle benötigt) aufruft. So...vorgeschlagene Lösung:

 

Eine Useraccount-Session per RemoteDesktop bleibt immer offen!

 

--> Für mich eine Bastellösung in einer Produktivumgebung!

 

Meine Bedenken:

- die Maschine muss ein autologin für den User haben mit anschließendem locked desktop

-> hatte schon Maschinen, bei denen sich das autologin warum auch immer zurückgesetzt hat

 

- die RDP Session muss dauerhaft gespeichert bleiben

-> ist das garantiert...was is wenn die session crashed/doch mal geschlossen wird - vom user, vom System...?!

 

- einen Dienst könnte man überwachen (zB Nagios), den kann ich stoppen/starten - habe Kontrolle darüber......die Usersession?! hm...den AdminAccount dazu zu missbrauchen? ...NO!

 

- ist die Session auch nach div. Windowsupdates oder einem erforderlichen Reboot immer noch garantiert vorhanden?!

 

:suspect:

 

 

Ich suche also ein paar handfeste Argumente, diese Art der Programmierung noch zu kippen. Welche Probleme seht ihr, die Verfügbarkeit eines Produktivsystem von einer permanenten RDP-Session abhängig zu machen?

 

Wenn jemand Ideen oder stichfestes Material hat, bitte gerne her damit!

Danke!

 

 

 

PS: RunasService, instsrv,.... funktioniert nicht

[nerd 28]

Hi,

 

also RDP kannste normal vergessen. Damit müßtest du die ganzen timeouts raus konfigurieren (wäre vielleicht noch machbar). Die Session würde jedoch beim Neustart des Servers oder des Clients (der die Session aufgebaut hat) wieder abbrechen. Mir wäre dabei auch keine Möglichkeit bekannt diese wieder neu Aufzubauen (das muß also jedes Mal von Hand gemacht werden).

 

Grundsätzlich ist eine solches Design einer Anwendung mehr als schlecht. Ich kenne das an sich nur noch aus NT4 Zeiten... Entwickler heute sollten das besser wissen...

[overlord 10]

Ja, das sagt einem eigentlich doch schon der gesunde Verstand.....kennst du zufällig Quellen, die auf Timeout-"Probleme" mit rdp hinweisen?...oder etwas was in die Richtung geht?

[phoenixcp 10]

Mahlzeit

 

Alleine beim lesen der "Planungen" wird einem ja schlecht... *Schüttel*

Aber sie liefert ne schöne Grundargumentation:

1. Es handelt sich um eine Schnittstelle / Monitoring. Dieses wird nicht interaktiv durchgeführt, sondern ist ein Hintergrundprozess. Daher sollte es auch als Hintergrundprozess gestaltet werden ==> Dienst

2. Ein angemeldeter User für eine Connection per wasauchimmer sollte kein Problem darstellen, da der Dienst ja im Kontext eines entsprechenden Users laufen kann / sollte.

3. Die von Johannes aufgeführte Problematik rund um RDP

 

Insgesamt würde ich alles daran setzen die Implementierung zu stoppen, das ganze neu zu designen und anschließend anders zu realisieren. Ich wage mal glatt an der Kompetenz der entsprechenden Entwickler zu zweifeln. Wie Johannes schreibt: Sie sollten es eigentlich besser wissen.

 

Spannend wäre vielleicht auch mal die Argumentation der Gegenseite, warum die Applikation so aussehen soll, wie du es beschreibst.

 

Ich drück dir die Daumen das sich da noch was drehen lässt.

 

mfg

Carsten

[LukasB 10]

Ich suche also ein paar handfeste Argumente, diese Art der Programmierung noch zu kippen. Welche Probleme seht ihr, die Verfügbarkeit eines Produktivsystem von einer permanenten RDP-Session abhängig zu machen?

 

Neben offensichtlichen Punkten die von anderen bereits genannt wurden möchte ich hier noch ein paar Dinge hinzufügen:

 

- Die Änderung einer Applikation dass diese als Service läuft ist weder schwer noch kompliziert.

 

- Das Unwillen der Entwicklung diese Änderungen vorzunehmen ist ein klares Zeichen von mangelnder Erfahrung mit der Entwicklung von Windows-Serverapplikationen.

 

In meinen Augen stellt sowas das ganze Projekt in Frage, da der ausführende Teil hier nicht wirklich weiss was er tut - aber auf der anderen Seite scheinen bereits im Vorfeld des Projektes schwere Fehler hinsichtlich Planung / Pflichtenheft / Definition von Anforderungen gemacht worden zu sein, da hier die Tatsache das die Applikation als Windows-Service läuft wohl nicht Vertragsbestandteil ist.

 

Wenn du Glück hast zeigen sich die Entwickler einsichtig und werden es ändern, aber falls nicht seid ihr in einer schwierigen Position.

[LukasB 10]

Doppelt Gemoppelt

[overlord 10]

- Die Änderung einer Applikation dass diese als Service läuft ist weder schwer noch kompliziert.

 

Richtig...Problem ist eher die verkorkste Art der Visualisierung direkt am Server. Das sollte vom Client aus gestartet werden.

 

 

- Das Unwillen der Entwicklung diese Änderungen vorzunehmen ist ein klares Zeichen von mangelnder Erfahrung mit der Entwicklung von Windows-Serverapplikationen.

dazu schweige ich....

[Sanic 10]

Ich finde es auch einfach mal aus Sicherheitsgründen nicht elegant dass ein User auf den Server über RDP zugreifen kann.

Wenn jetzt ein Dienst auf dem Server installiert ist, können ja nur bestimmte Funktionen abgerufen werden, die auch in dem Dienst implementiert sind und von euch abgesegnet werden. Über RDP kannst du ja prinzipiell viel mehr Unheil anrichten.