beRemote (Remotedesktopmanagement)

[beRemote]

Hallo Forum,

wir haben in den vergangenen 18 Monaten ein Remotedesktop Connection Manager entwickelt, welcher in der Lage ist in mehreren Tabs mehrere Remotedesktopverbindungen geordnet in einem Programm anzuzeigen. Vergleichbare Programme sind "mRemote" oder "RoyalTS".

Hier einige Projektdaten:
Name: beRemote
Homepage: http://www.beremote.net
Entwickler: Benedikt Kröning und Kristian Reukauff
Seit wann: März 2012
Wie: In C# mit .Net Framework 4.0
Womit: Visual Studio und Repository-Verwaltung via SVN
Bugtracker: https://tracker.beremote.net

Im täglichen Gebraucht hat man eine Liste diverser Server in einer Serverliste hinterlegt. Mit einem Doppelklick auf einen Server in dieser Liste ist es nun möglich eine Verbindung zum Server aufzubauen. Beim Aufbau öffnet sich ein neuer Tab, in dem nur die eine Remoteverbindung zu sehen ist. Bereits bestehende Verbindungen bleiben dabei in ihrem eigenen Tab geöffnet. Es kann dabei frei zwischen den Remoteverbindungen hin- und hergeschaltet werden. Auch können einzelne Verbindungen aus dem Grid herausgelöst und in einem eigenen Fenster angezeigt werden.
Auch ein automatisches Login ist möglich. Hierzu muss nur ein Credential-Set im Credentialmanagement hinterlegt und allen Servern zugewiesen werden, die diese Credentials nutzen sollen. Dies ist besonders praktisch, wenn man in Domänen arbeitet, in denen Kennwörter regelmäßig ablaufen. So muss nur das Credential-Set mit dem neuen Kennwort versehen werden und alle Server, die dieses Credential-Set benutzen, nutzen dann das neue Kennwort.
beRemote ist zum Teil bereits teamfähig. Dies bedeutet, dass mehrere Benutzer auf einer Datenbank arbeiten und sich eine Verbindung teilen können. So entfällt im Mehrbenutzerbetrieb das doppelte pflegen von Serverlisten. Diese Teamfähigkeit wird in der weiteren Entwicklung stetig ausgebaut.

Wir haben nun unser zweites Release Preview veröffentlicht, welches bei Weitem noch keine fertige Version darstellt, aber für das Arbeiten mit RDP-Verbindungen im täglichen Gebrauch sehr gut geeignet ist.
In unserem Release Preview 2 sind folgende Features enthalten:
- Komplett flexibles Docking-Grid (ähnlich wie im Visual Studio)
- IPv6 Support
- Import von mRemote Verbindungsdateien
- RDP Support
- NLA-Support für RDP-Verbindungen
- VNC Support
- Verbindungsmanagement in einem verwaltbaren Treeview
- Verlauf aller Systeme, zu denen verbunden wurde
- Zugangsdatenmanagement für Auto-Login
- SQLite basierte Datenbank
- Moderner Desktop-GUI-Style mit Ribbons
- Anpassbares (Firmen-)Logo als Wasserzeichen im Ribbon
- Komplett portable
- Freeware (kommerziell und privat)
- Schnellverbinden zu häufig genutzten Systemen
- Umfangreiches Pluginsystem zur Implementierung von 3rd Party Plugins
- und viel viel mehr

Nun entwickeln wir an unserer nächsten Vorab-Version, dem beRemote Release Preview 3
Auf dem Weg dorthin werden viele Plugins in Form von Protokollen und Tools beRemote umfassend erweitern.
Hier eine Auswahl einiger in Kürze erscheinender Funktionen:
- Telnet Support
- SSH Support
- HTTP/HTTPS/FTP Support
- HyperV Support
- Import of CSV-Files
- Übersichts-Tab über alle geöffneten Verbindungen
- Filtern von Verbindungen
- On-/Offline-Erkennung in der Serverliste
- Backup-System
und noch viel mehr

Dieses Projekt wird weiter wachsen und an Umfang hinzunehmen. Zudem ist es ab diesem Release für jeden möglich sein eigenes Plugin zu entwickeln, welche dann in beRemote eingebunden werden können und den Funktionsumfang von beRemote stetig erweitern.
Wer es nicht erwarten kann hiermit loszulegen, der kann uns gerne kontaktieren. Dann händigen wir eine Vorabversion der Schnittstellen-Implementierung aus, sodass keine Zeit verloren gehen muss.

Um unsere weiteren Ziele zeitnahe zu erreichen, suchen wir noch tatkräftige Entwickler, welche uns bei der Entwicklung von beRemote oder von Plugins für beRemote unterstützen möchten. Wer Interesse hat, kann sich dazu gerne bei uns per Mail an support-bei-beremote.net melden. Auch Testuser sind gerne gesehen.

Die derzeit aktuelle Version von beRemote ist unter folgenden Links herunterladbar:
beRemote Release Preview 2 64 Bit: http://beremote.net/?dl_name=https://sv ... 36-j28.zip
beRemote Release Preview 2 32 Bit: http://beremote.net/?dl_name=https://sv ... 36-j23.zip

Oder alternativ für alle, die nicht auf neue Funktionen warten können und dafür ggf. Bugs in Kauf nehmen, die stets aktuellen Snapshots:
beRemote Snapshot 64 Bit: http://beremote.net/?dl_name=https://sv ... LATEST.zip
beRemote Snapshot 32 Bit: http://beremote.net/?dl_name=https://sv ... LATEST.zip

Wir weisen noch darauf hin, dass beRemote eine Verbindung zum Internet herstellt. beRemote prüft auf beremote.net, ob eine neue Release-Version zur Verfügung steht. Wenn keine Verbindung zu beremote.net aufgebaut werden kann, passiert einfach nichts. Wer uns also nicht vertraut, darf die Verbindung auch gerne blockieren. Sollte eine Verbindung hergestellt werden können, erscheint lediglich ein Hinweis, dass eine neue Version zur Verfügung steht. Es wird nichts heruntergeladen und/oder automatisch installiert!

Hier noch einige Screenshots (weitere auf beremote.net):
Hauptfenster:


RDP-Verbindung:


Verbindung erstellen:

[Xin]

Moin

Name: beRemote
Homepage: http://www.beremote.net
Wie: In C# mit .Net Framework 4.0

Im täglichen Gebraucht hat man

... in meinem Fall alle Betriebsysteme im Einsatz: Linux, Mac und Windows.

Das Ganze sieht mehr sehr Windows-Lastig aus (C#, Ribbons...).
So sitze ich hier zwar gerade an einem Win7-Rechner, die Rechner, die ich von hier aus administriere sind aber Linux Rechner. Zu Hause sitze ich an einem Mac und da könnte sich die Frage ergeben, mal auf einen Windows oder Linux-Rechner zu gehen. Arbeite ich am Entwicklungsrechner (Linux) wäre es schön, sich im Hintergrund auf den Mac verbinden zu können, so dass das man den Monitor in der Zwischenzeit ausschalten könnte.

Das wäre mein Arbeitsumfeld.
Euer Zielpublikum ist Windows-Only und dann ist auch aktuelle .NET Installationen erforderlich, oder?

[beRemote]

Hallo Xin,

ja, wie du richtig erkannt hast, ist beRemote für Windows XP oder neuer gedacht. Voraussetzung ist das .Net Framework 4.0. Dadurch fallen als Systeme auf denen beRemote ausgeführt werden kann nativ alle Unix-Derivate (Linux + OSX) hinten raus. .Net 4.0 ist nicht die aktuellste Version, aber die letzte Version, die Windows XP unterstützt.
Das heißt aber NICHT, dass man sich dorthin nicht verbinden kann. beRemote stellt (noch) kein eigenes Protokoll da, sondern nutzt bereits existierende Protokolle und bündelt deren Funktionen in ein Programm, sodass es in der Anwendung keinen Unterschied macht, ob du via RDP, VNC, SSH, Telnet oder was auch immer auf ein anderes System verbindest.

Wenn du also bei dir am Windows-System sitzt und dort beRemote benutzt, kannst du ohne Probleme auf Linux- oder Mac-Systeme verbinden. Voraussetzung ist hier nur, dass dort ein Protokoll installiert ist, welches von beRemote unterstützt wird. Für Linux und Mac wären das derzeit bzw. in kurzer Zeit VNC, SSH und Telnet, wobei man in der Praxis letzteres besser nicht nutzten sollte

[Xin]

ja, wie du richtig erkannt hast, ist beRemote für Windows XP oder neuer gedacht. Voraussetzung ist das .Net Framework 4.0. Dadurch fallen als Systeme auf denen beRemote ausgeführt werden kann nativ alle Unix-Derivate (Linux + OSX) hinten raus.

Darf man fragen, wieso es zu einer Designentscheidung kam, ein Tool, das gerade für Entwickler durchaus interessant ist, auf Plattformen nicht zu unterstützen, die für Entwickler gerade interessant sind?

Wenn du also bei dir am Windows-System sitzt und dort beRemote benutzt

Auf der Arbeit nutze ich Windows, weil wir auch eine Windows-Only-Software produzieren, und verbinde mich zu Linux-Servern per putty. Die Software kommt aber irgendwo aus den 80ern, man hat sich damals mit WinAPI an Windows gekettet.

Privat mache ich seit der Jahrtausendwende keine Projekte mehr, die nicht portabel sind. Hier entwickle vorrangig unter Linux, wo es zu SSH (und telnet) auch nicht weit ist, aber ich eher mal Interesse an Bildübertragung hätte, auch in der Form wie TeamViewer. Zumal für den Zugriff auf VMs per VNC die Kiste nunmal unter Linux läuft.

[beRemote]

Hi,

natürlich darfst du das Fragen.
Die Designentscheidung war, dass in dem Umfeld, in dem das Programm eingesetzt wird nunmal 90% oder mehr der Systeme Windows-Systeme sind. Zudem lag die Entscheidung auch daran, dass dies ein Hobby-Projekt ist und wir als Entwickler sowohl beruflich als auch privat mit dem Thema .Net/C# zu tun haben und so unsere dort vorhandenen Kenntnisse in diesem Projekt mit einbringen. So müssen wir uns nicht erst mit basics einer neuen Sprache oder Umgebung herumschlagen, sondern können mit den bestehenden Kenntnissen die Umsetzung durchführen.
Primär lag die Entscheidung aber wie gesagt dran, dass dort wo die Software letztendlich eingesetzt werden soll bzw. auch bereits eingesetzt wird primär Windows-Systeme im Einsatz sind und sich so für ein Hobby-Projekt der Mehraufwand derzeit nicht lohnt.
Zudem gibt es, zumindest unter OSX, diverse Virtualisierungsmöglichkeiten für Windows-Programme, sodass jeder der das Programm wirklich benutzen will, es auch unter OSX nutzen kann. Ich selbst tue dies mit Parallels. Funktioniert wunderbar und ohne Einschränkungen.

[Xin]

natürlich darfst du das Fragen.
Die Designentscheidung war, dass in dem Umfeld, in dem das Programm eingesetzt wird nunmal 90% oder mehr der Systeme Windows-Systeme sind. Zudem lag die Entscheidung auch daran, dass dies ein Hobby-Projekt ist und wir als Entwickler sowohl beruflich als auch privat mit dem Thema .Net/C# zu tun haben und so unsere dort vorhandenen Kenntnisse in diesem Projekt mit einbringen.

Will ich als Argument durchgehen lassen. ^^

Also dass ihr mit C# vertraut seid. Mein Umfeld passt nicht in eure 90% und wenn mein Umfeld nicht so selten ist, dann sind meine 10% vielleicht auch 20%.

Ihr seid eingeladen, hier C# vorzustellen.
Ich sach's nur prophylaktisch - manchmal klappt's ja.

Zudem gibt es, zumindest unter OSX, diverse Virtualisierungsmöglichkeiten für Windows-Programme, sodass jeder der das Programm wirklich benutzen will, es auch unter OSX nutzen kann. Ich selbst tue dies mit Parallels. Funktioniert wunderbar und ohne Einschränkungen.

Hmm... ich habe einen MacMini, dem ich mit 4GB RAM nicht unbedingt noch eine Windows-VM verpassen will, um darin die .NET VM zu starten, um dann mit ssh auf einen Linux-Server zuzugreifen. Auch wenn das funktioniert, erscheint mir das nicht wirklich als eine sinnvolle Option.
Das andere ist ein MacBook Air mit 8GB RAM, da geht das mit dem RAM. Dafür aber nur 256GB SSD. Hier stellt sich die Frage, ob ich den ganzen Kram auf der SSD haben will, um eine Liste mit Servern zu verwalten. ^^

[beRemote]

Hmm... ich habe einen MacMini, dem ich mit 4GB RAM nicht unbedingt noch eine Windows-VM verpassen will, um darin die .NET VM zu starten, um dann mit ssh auf einen Linux-Server zuzugreifen. Auch wenn das funktioniert, erscheint mir das nicht wirklich als eine sinnvolle Option.
Das andere ist ein MacBook Air mit 8GB RAM, da geht das mit dem RAM. Dafür aber nur 256GB SSD. Hier stellt sich die Frage, ob ich den ganzen Kram auf der SSD haben will, um eine Liste mit Servern zu verwalten. ^^

Bei dem MacMini geb ich dir Recht. Ich hab in meinem MacBook (Pro) ebenfalls eine 256GB SSD. Da habe ich bisher aber keine Platzprobleme. Das hängt aber wohl sowieso von jedem selbst ab.
Im Moment gebe ich dir Recht, dass der "Aufwand" das auf einem Mac zu betreiben nur unter Umständen gerechtfertigt ist. Aber unser Ziel ist ja, dass sich das ändert Wir haben da noch viele viele weitere Ideen, die das Leben eines Systemadministrators seeeehr viel vereinfachen. Aber wir sind ja auch nur Menschen und müssen "nebenbei" leider auch noch normal Arbeiten. Daher ziehen sich einige Änderungen leider manchmal etwas. Aber wird sind da jetzt seit etwas mehr als 1,5 Jahren dran und ich denke so langsam macht es echt Spaß auch täglich damit zu arbeiten.
In Zukunft wird es natürlich alles noch viel besser

[Xin]

Bald ist ja langes Wochenende, ich schau's mir mal an.