Einleitung
Ziel soll es sein, in einem größeren Netzwerk (30+ PCs) eine Remote Desktop Lösung einzurichten, mit der ein Administrator jederzeit auf den Desktop anderer Benutzer schauen und diese kontrollieren kann. Die Installation und Einstellungen sollen komplett automatisch über Gruppenrichtlinien eines Windows Active Directory laufen. Die Fernwartung soll für Windows XP und Windows 7 funktionieren wobei der eigentliche Fokus natürlich auf Windows 7 liegt.
Voraussetzungen
Ich beschreibe das Szenario in einem Windows Netzwerk mit Active Directory und aktiven Gruppenrichtlinien für fast alle Computer im Netzwerk.
Zugriff auf die Gruppenrichtlinien ist genauso notwendig wie der Zugriff auf ein Netzlaufwerk, das alle Netzwerkuser benutzen können.
Konzept
Die Fernwartung wird komplett mit TightVNC realisiert. TightVNC ist Open Source und kostenlos, derzeit (Dez. 2010) in der Version 2.0.2. Diese Version verwenden wir für Windows 7 und Windows XP in der Installations-Variante. Für Windows XP mit manuellem Start müssen wir die ältere Version 1.3 verwenden (mein Mirror der Version 1.3 unten bei „Downloads“).
Für Windows 7 muss TightVNC 2.0.2 als Dienst auf allen Clients installiert werden. Andernfalls scheitert die ThightVNC Fernwartung bei der UAC. Näheres dazu später. Diese Installation des Dienstes funktioniert ebenfalls für Windows XP und ist 1 von 2 Wegen, das System bei Windows XP zu realisieren.
Alternativ kann für Windows XP ein manueller Start des Servers gewählt werden, das wäre Methode 2. Dazu werden die ausführbaren Dateien auf einem Netzlaufwerk abgelegt, wo alle Mitarbeiter Zugriff haben. Auf Wunsch startet der Mitarbeiter TightVNC und der Administrator klinkt sich ein.
Alle 3 Systemarten sind unten beschrieben.
Die Einstellungen von TightVNC, die für den Betrieb notwendig sein (wie z.B. Verbindungspasswörter, Sicherheitsrichtlinien etc) werden automatisch in die Registry integriert. Bei Windows XP mit Version 1.3 werden die Einstellungen beim ersten Start übernommen, alternativ geht auch hier die Registry-Lösung.
Downloads
TightVNC 2.0.2
Offizielle Downloadseite für die aktuellste Version
Mirror auf hannes-schurig.de
.exe Installer – Viewer Source – Server Source
TightVNC 2.0.2 msi Installer
TightVNC 1.3
Offizielle Downloadseite für die ältere Version
Mirror auf hannes-schurig.de
.exe Installer – .zip Archiv – Portable
Deployment
Windows 7 / Windows XP (Installation)
Windows 7 ist dank der optimierten Benutzerkontensteuerung ein spezieller Fall. Die UAC springt ein, wenn der Benutzerkontext, mit dem etwas ausgeführt werden soll, geändert wird. Das kommt zum Beispiel vor bei „Als Administrator ausführen“ oder „Als anderer Benutzer ausführen“ -> „.\Administrator“. Windows 7 mit aktivierter UAC verdunkelt dann den Bildschirm, fragt nach den Benutzerdaten und aktiviert etliche Sicherheitsfeatures. Diese Sicherheitsfeatures sind der Grund, warum TightVNC 1.3 (die ältere Version) sofort die Verbindung der Fernsteuerung trennt, sobald die UAC aktiv wird.
Ziel soll es deswegen sein, die neueste Version 2.0.2, die zusätzlich für Windows 7 optimiert wurde, als Dienst auf allen Computern zu installieren.
Daraus ergeben sich mehrere Vorteile wie z.B. die Verbindung schon im Windows Login Bildschirm, möglich An- und Abmeldungen oder Benutzer wechseln, ohne dass TightVNC abbricht und keinerlei Benutzeraktionen sind nötig, um eine Verbindung aufzubauen.
Wer also in der Fernsteuerung hin und wieder diese Funktion nutzen möchte („Als Administrator/anderer Benutzer ausführen“, runas /user) und auch die anderen Vorteile braucht, muss den nächsten Schritten folgen.
Auf Windows XP wirkt sich diese Art der Installation ebenfalls aus. Es ist also für beide Systeme geeignet.
Schritt 1 – Download und Installation:
Download von TightVNC 2.0.2 und installieren/entpacken. tvnserver.exe starten, unten rechts im Infobereich erscheint das TightVNC Server Icon, ein schwarzes V auf weißem Hintergrund (noch) mit rotem Rahmen.
Schritt 2 – Passwort und Einstellungen:
Öffnet das Einstellungsfenster von TightVNC und geht die 3 Tabs mit allen Einstellungen durch. Wichtig sind vor allem die Passwörter, weil TightVNC ohne eingestelltes Passwort nicht ohne Weiteres funktioniert. Konfiguriert TightVNC so, wie es auf allen Computern aussehen soll; Passwörter, Port, Web Access, IP Access Control, Konfigurationspasswort etc.
Schritt 3 – Einstellungen exportieren:
Wenn ihr alle Einstellungen gemacht und übernommen habt sollte das ThightVNC Icon nicht mehr rot umrahmt sein. Wenn das so ist, öffnet die Registry und begebt euch zu dem Schlüssel
HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server
. Exportiert den Schlüssel mit Rechtsklick->Exportieren.
Legt die exportierte .reg Datei auf einem Netzlaufwerk ab, wo jeder User Zugriff hat. Vorzugsweise dort, wo ihr Installationskram von Gruppenrichtlinien zu liegen habt. Dort müssen später auch der TightVNC Installer und ein Script rein.
Beispiel: \\server\EDV\GPOs_Install\Remote_Control\settings.reg
Schritt 4 – Registry-Import automatisieren:
Zuerst testen wir den automatischen Import der TightVNC Einstellungen durch ein Script.
Erstellt dazu ein neues Batch Script und kopiert folgende Zeilen hinein:
@echo off
reg import \\server\EDV\GPOs_Install\Remote_Control\settings.reg
Anmerkung: Bei einem Netzwerk, indem sowohl 32bit als auch 64bit Computer im Einsatz sind, muss das Script so aussehen:
@echo off
if %PROCESSOR_ARCHITECTURE% == AMD64 goto 64bit
if %PROCESSOR_ARCHITECTURE% == x86 goto 32bit
:64bit
reg import \\server\EDV\GPOs_Install\Remote_Control\settings64.reg
exit
:32bit
reg import \\server\EDV\GPOs_Install\Remote_Control\settings32.reg
exit
via – Danke an Markus Brunner für die Ergänzung.
Packt das .bat Script ebenfalls auf das Netzlaufwerk.
Zum Test: löscht den Key
HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server
und überprüft mit dem Registrierungseditor, ob der Key wirklich gelöscht wurde. F5 – Aktualisieren nicht vergessen.
Key gelöscht? Dann führt dann das Batchscript aus. Das Script sollte nur kurz aufploppen und das wars. Im Hintergrund wurde die .reg Datei in die Registry eingepflegt.
Wieder F5 und der Server Key müsste wieder da sein.
Dieses Script spielt also die exportierten Einstellungen eurer TightVNC Installation später auf alle PCs. Dadurch bekommen später auch alle PCs das richtige Passwort, dass sich leider nicht automatisiert in die Installation von TightVNC integrieren lässt. Aber Schritt für Schritt…
Schritt 5 – Installation von TightVNC auf alle PCs per Gruppenrichtlinie:
Die Installation von TightVNC 2.0.2 erfolgt mit einer .msi in der Softwareinstallation einer Gruppenrichtlinie, die auf alle Computer angewendet wird, die zu diesem fernsteuerbaren Netzwerk gehören sollen. Die .msi ist oben im Download Part des Beitrags verfügbar. Passt ggf. noch die Properties Parameter mit Orca an, wenn ihr wollt.
Erstellt ein neues Paket im Softwareinstallationsbereich, Erweitert, „auch für 64bit bereitstellen“, „Sprache ignorieren“, Sicherheitseinstellungen (Rechte) richtig? Gut, fertig.
Testet die korrekte Installation von TightVNC auf einigen Test-Clients: in den Diensten müsste „TightVNC Server“ und unter den laufenden Prozessen „tvnserver.exe“ auftauchen, wenn die Installation korrekt lief.
Je nachdem ob ihr die Einstellung „Show icon in the notification area“ deaktiviert habt oder nicht ist auch das TightVNC Icon zu sehen.
Testet mit dem vncviewer die Verbindung: gebt in den Viewer die IP ein, die Passwortabfrage sollte erscheinen. Dann läuft zumindest der Dienst korrekt. Ein Passwort wurde noch nicht gesetzt, also egal was ihr eingebt, „Service is not configured correctly“ (oder Ähnlich) wird nur angezeigt. Ist ja auch korrekt, eure Einstellungen wurden ja noch nicht verbreitet.
Schrit 6 – Einstellungen verteilen:
Das machen wir natürlich nicht von Hand sondern per Startscript.
Also tragt die oben erstellte Batch als Startscript in die Gruppenrichtlinie ein. Das Script enthält den Befehl, die .reg Einstellungen einzupflegen. Alle Dateien (.msi Installer, .reg Export, .bat Script) liegen wie gehabt auf einem Netzlaufwerk, wo für alle User Leserechte bestehen.
Habe das hier mal auf einem Blick:
Schritt 7 – Test
Ein Client PC startet, Tight VNC wird installiert und als Dienst gestartet. Beim diesem ersten Start werden die Einstellungen nocht nicht übernommen!
Also einen neuen PC in die GPO zu nehmen und mit nur 1 Neustart die Remote-Lösung nutzen funktioniert nicht!
Erst nach einem 2. Neustart, bei dem TightVNC bereits installiert ist, werden die Einstellungen übernommen.
Also einen PC 2, 3 Mal neustarten und dann das System testen. Verbinden, Passwort eingeben, dass ihr vor dem Reg Export eingestellt habt, ihr müsstet dann auf dem Rechner sein.
Fragen und Probleme
Ich versuche mal zusammenzufassen, womit ich beim Einrichten dieses System so konfrontiert wurde.
Das Programm wird nicht installiert!
Wenn die .msi in die GPO integriert ist und trotzdem nicht installiert wird, überprüft euer komplettes GPO Kontrukt auf Rechte-/ oder Pfadfehler. Prüft die Ereignisberichte usw. Eine lange Anleitung zum Troubleshooting von GPOs und Softwareinstallationen habe ich hier.
Die Einstellungen werden nicht übernommen!
Wenn das Programm installiert aber auch nach mehreren Neustarts die Einstellungen nicht übernommen werden, stimmt etwas mit der .reg oder der .bat nicht.
Löscht den Server Key wie in Schritt 4 beschrieben, vergewissert euch und fügt den Key durch Doppelklick der .reg wieder hinzu. Hat funktioniert?
Dann löscht den Key erneut und führt die .bat vom Netzlaufwerk aus. So, wie die GPO es machen würde. Hat funktioniert?
Seht ihr einen Fehler wenn ein Client PC die Batch ausführt? Teste es an einem Windows XP Rechner, da sind die Startscripts sichtbar.
Teste mal meinen Workaround für das Ändern von Regkeys von Diensten. Vorher den Dienst mit net stop beenden und danach mit net start wieder starten.
Dann überprüft die Rechte der Startscripte. Lassen sich andere, simple Startscripte aus diesem Ordner (wo .reg und .bat liegen) ausführen? Z.B. ein echo bla pause Script. Ja? Nein? Troubleshooting von GPOs, irgendwo muss ein Fehler sein 😉
In HKEY_CURRENT_USER UND HKEY_USERS sind auch TightVNC Schlüssel, muss ich die nicht auch ändern?
Meiner Erkentnis nach nicht. Änderungen an
HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server
wirken sich nach einem Neustart auch auf die TightVNC Einstellungen der anderen 2 Hives aus. Zudem ist das Editieren der Schlüssel in diesen 2 Hives verdammt kompliziert.
Kann ich nicht TightVNC 2.0.2 (tvnserver.exe) manuell starten wie bei der Windows XP Variante?
Nein, meines Wissens nach geht das nicht. TightVNC 2.0.2 manuell gestartet übernimmt keinerlei Einstellungen, selbst wenn diese bereits korrekt in die Registry eingetragen wurden. Zusätzlich ist TightVNC 2.0.2 beim manuellen Start im „Not listening“ Status. Das heißt, dass keine eingehenden Verbindungen angenommen werden.
Ich habe etwas rumprobiert aber hier keine anständige Lösung für beide Lösungen gefunden. Stattdessen habe ich mich für das Installieren von 2.0.2 für Windows 7 und die ältere Version 1.3 für Windows XP entschieden, bei der das noch funktionierte.
Bei den nächsten 2 Problemen stand mir Kevin Niehage mit seiner kompletten IT Security Expertise zur Seite.
Kann es sein, dass nur die ersten 8 Zeichen des Passworts geprüft werden?
Korrekt, TightVNC nutzt für das Passwort leider eine Verschlüsselungsmethode, die nur 8 Zeichen überprüft. Also wenn euer Passwort „abc123!!“ lautet, dann könnt ihr mit allen Passwörter verbinden, die diese Zeichen am Anfang beinhalten; „abc123!!??“, „abc123!!abc123!!“, egal. Also Vorischt bei der Passwortwahl, komplex sollten die ersten 8 Zeichen schon sein 😉
Das Passwort wird in der Registry abgespeichert, ist das nicht unsicher?
Mit gutem technischen Know How und ausreichend kritischem Forscherdrang lässt sich das Passwort herausfinden. Dazu muss man ziemlich im Quellcode von TightVNC wühlen und sich ein eigenes Decrypterprogramm schreiben. Aber es ist theoretisch möglich. Verwendet also keine kritischen Passwörter, die auch sonst im Unternehmen genutzt werden. Denkt euch ein neues, irrelevantes Passwort aus. Wechselt es regelmäßig, der Aufwand kostet nur max. 2 Minuten.
Meine Frage ist nicht dabei…
Dann schreib mir, Kommentar oder Mail oder Kontaktformular, her damit! Ich gebe mein Bestes zu helfen.
Windows XP Alternative (manueller Start)
Diese Variante für Windows XP ist einfacher einzurichten aber die Handhabung beim täglichen Gebrauch ist nicht wirklich schön. Damit eine Fernsteuerung stattfinden kann, muss der Mitarbeiter den TightVNC Server selber starten. Diese Alternative hat den Vorteil, dass eine Fernsteuerung nur möglich ist, wenn der Mitarbeiter den TightVNC den Server startet. Hier muss also erst eine Kommunikation stattfinden und nicht jeder Computer ist jederzeit kontrollierbar.
Schritt 1 – Download und Installation
TightVNC 1.3 als Installer oder Archiv herunterladen und die 2 Dateien „VNCHooks.exe“ und „WinVNC.exe“ auf einen für alle Benutzer verfügbaren Netzlaufwerkordner kopieren.
Schritt 2 – Konfiguration
Als Test: WinVNC.exe starten, beim ersten Start sollte das Konfigurationsfenster angezeigt werden. In dem Konfigurationsfenster alle nötigen Einstellungen übernehmen.
Schritt 3 – Test
Ein beliebiger Client startet WinVNC.exe. Zuerst mit „Ausführen“ bestätigen, dann erscheint das Konfigurationsfenster (wenn es der erste Start ist). Hier muss der Benutzer selbst das Passwort eingeben, dass der Administrator ihm mitteilt und mit [OK] das Einstellungsfenster schließen.
Nun kann sich der Administrator mit der IP und dem gerade vom Nutzer eingestellten Passwort auf den PC verbinden.
Fragen und Probleme
Kann ich nicht TightVNC 1.3 auch per GPO installieren lassen?
Natürlich. Dazu notwendig wäre nur eine .msi oder eine andere Installationsmethode. Wer noch ausreichend Windows XP Computer im Netzwerk hat sollte diesen Weg beschreiten.
Und was ist mit den Einstellungen? Geht das auch über den Registryimport Trick?
Bestimmt, ich gehe davon aus, dass auch TightVNC 1.3 die Einstellungen in der Registry speichert. Also das selbe Verfahren wie mit Windows 7. Ihr brauch nur den korrekten Schlüssel, wo TightVNC 1.3 schreibt.
Kann ich diese manuelle Methode auch bei Windows 7 verwenden?
Nein, zumindest habe ich nach einigem Aufwand eingeschätzt, dass man bei Windows 7 besser beraten ist, eine Installation des Dienstes durchzuführen. Es wird manuell immer Probleme oder Fehler geben. Siehe Einleitungsabsatz im Windows 7 Part.
Meine Frage ist nicht dabei…
Dann schreib mir, Kommentar oder Mail oder Kontaktformular, her damit! Ich gebe mein Bestes zu helfen.
The End
So, ich habe das Gefühl ich habe irgendwelche wichtigen Schritte vergessen aber das kommt bei etwas komplexeren Dingen schonmal vor.
Ihr habt Fehler entdeckt, gebt mir bitte Bescheid. Verbesserungen, Kritik, Fragen, Wünsche, wie immer per Kommentar oder Kontakt(/Mail).
Weitergabe oder Verwendung dieser Anleitung nur mit voller Quellen- und Autorangabe! Ich bitte euch, seid fair.
Ein paar Anmerkungen zum Artikel hätte ich:
„Mit gutem technischen Know How und ausreichend krimineller Energie lässt sich das Passwort herausfinden.“
Diese Aussage möchte ich so nicht stehen lassen. Natürlich benötigt man ein wenig technisches KnowHow – zumindest solange, bis ich selber so ein Tool schreibe, wenn ich Lust dazu habe. Für das Auslesen und Entschlüsseln „kriminelle Energie“ vorauszusetzen, halte ich jedoch für falsch. Du hast in den letzten Tagen mehrmals Pro-Wikileaks-Artikel geschrieben und plötzlich bringst du selber solch eine platte, verallgemeinernde Aussage?
Generelle finde ich die Idee, alle Rechner mit dem gleichen Passwort auszustatten nicht sonderlich gut. Wie bereits erwähnt, ist es möglich, das Passwort auszulesen und zu entschlüsseln. Sollte jemand wirklich „kriminelle Energien“ aufweisen, hätte diese Person anschließend die Möglichkeit, die Kontrolle über alle anderen Rechner zu übernehmen. Hätte ja eine Idee, wie man das ganze besser (und sicherer) lösen könnte. Wäre allerdings die Frage, ob man überhaupt pro Rechner ein separates Passwort verwalten möchte.
Letzte Frage: Warum kann man das Installationspage für Windows7 nicht auch direkt für WindowsXP nutzen? Hast du das getestet und falls ja: Welche Probleme gab es, dass du für WindowsXP eine andere Variante empfiehlst?
Mit „krimineller Energie“ ist schon allein der Wunsch gemeint, andere Mitarbeitercomputer fernsteuern zu können.
Ich sitz hier in einem Bildungsforschungsinstitut. Wenn hier jemand andere Mitarbeiter-PCs fernsteuern wollen würde und dafür den Quellcode von TightVNC „reversed“ um an das Passwort zu kommen, dann ist das für mich kriminelle Energie.
Der Normalfall ist, dass hier jeder seinen Job tut und keine Hilfsmittel, die ich extra dafür entwickel, den Leuten schneller und besser helfen zu können, gegen mich/uns verwendet.
Daher dieser etwas verallgemeinerte Ausdruck.
Achja was deine 2. Frage angeht, ob man das nicht auch bei Windows XP machen könnte, hast du die „Fragen und Probleme“ von Windows XP gelesen?
Den „Fragen und Probleme“-Bereich von WindowsXP habe ich gelesen. Du schreibst, dass man die automatische Variante (von TightVNC 2.0.2 unter Windows7) auch auf TightVNC 1.3 unter WindowsXP anwenden kann UND, dass man die manuelle Variante (von TightVNC 1.3 unter WindowsXP) bei TightVNC 2.0.2 unter Windows7 nicht anwenden sollte, da sie durch die UAC nicht funktioniert. Meine Frage war aber, ob man die automatische Variante von TightVNC 2.0.2 auch unter WindowsXP nutzen kann 😉 . Muss ja einen Grund geben, weshalb du weder TightVNC 2.0.2, noch die Dienst-Funktion von 1.3 unter WindowsXP verwendest.
Und zur kriminellen Energie: Du hast doch gerade gesagt, dass du in einem „Bildungsforschungsinstitut“ arbeitest. Gerade dort würde ich erwarten, dass die Leute ihre Arbeitsumgebung erkunden! Andersrum unterstellst du damit jedem Security-Analysten, dass er durch kriminelle Energien angetrieben werden würde.
Ich glaube jetzt habe ich es gepeilt 🙂
TightVNC 2.0.2 lässt sich zwar ohne Installation starten, aber er funktioniert einfach nicht. Und ich glaube das selbe Verhalten war unter Windows 7 auch, was der eigentliche Grund war, warum ich den Dienst installieren musste. Stimmt! Das ist noch ein guter Part für „Fragen und Probleme“.
Wenn TightVNC 2.0.2 manuell gestartet wird dann ist der Status von TightVNC auf „Not listening“. Es kann keine Verbindung aufgebaut werden.
Es sind auch keine Einstellungen übernommen, kein Passwort und auch andere Einstellungen nicht.
Obwohl in der Registry der Schlüssel mit dem vollen Inhalt (Passwörter, Einstellungen) vorhanden ist.
Der manuelle Start übernimmt also die Einstellungen nicht und öffnet auch keinen Remote Eingang.
Glaube da habe ich dann noch einiges probiert und bin dann auf die Installation ausgewichen (in Win7) und auf die ältere Version (in WinXP), bei der das noch ohne Probleme funktionierte.
Na davon gehe ich doch aus… warum liest man denn meisten Bücher, in denen gezeigt wird, wie etwas angegriffen werden kann? Weil man nur so wirklich effektiv kennenlernt, wie man sich am besten absichert. Wenn ich weiß, wie angegriffen wird, kann ich abwehren.
Warum werden denn vor allem (bzw. wurden, kp ob das noch gang und gebe ist) „Virenprogrammierer“ und „Hacker“ bei Softwarefirmen eingestellt, die Antivirensoftware schreiben? Weil das eine super Quelle von Wissen und Informationen ist.
Ich glaube es gibt für echte Security-Analysten keinen besseren Antrieb als etwas kriminelle Energie und Experimentierlust.
Ich sage nicht, dass dieses „kriminelle“ Wissen dann angewendet werden soll. Aber wenn es vorhanden ist kann der Analyst profitieren, indem er Gegenmaßnahmen entwickelt.
Sehe ich das falsch? Ist eindeutig nicht meine Szene aber so war mein Eindruck von damals, als ich da kurz reingerutscht bin.
Der Grund, weshalb Sicherheitsfirmen durchaus auch Virenschreiber und Hacker einstellen, ist, weil diese Leute gezeigt haben, dass sie die Fähigkeit haben, Lücken ausfindig zu machen und so miteinander zu kombinieren, dass sie eine Gefahr für das System darstellen. Beim Abwehren von Angriffen wird das natürlich benötigt.
Trotzdem dürfte der Großteil der Security-Analysten einfach nur Spaß am Erforschen von unbekannten Systemen haben – der eigentliche Ursprung der Hacker-Szene. Glaubst du wirklich, der CCC und Konsorten greifen Dinge wie den neuen Personalausweis an, weil sie sich dadurch einen Vorteil verschaffen können? Diese Vorteilsverschaffung ist nämlich ausschlaggebend, um eine „kriminelle Energie“ attestieren zu können. Ich erinnere dich mal an den Flattr-Fall – dort ging es mir lediglich darum, zu gucken, ob es überhaupt möglich ist. Aus dem gleichen Grund habe ich Monate später nochmal eine Analyse vorgenommen.
Wie gesagt: Jedem, der die Sicherheit von IT-Systeme analysiert, kriminelle Energien zu unterstellen, halte ich persönlich für falsch.
Und zu TightVNC 2.0.2: ich glaube, du hast es immernoch nicht ganz verstanden xD . Deswegen nochmal:
Warum kann man nicht einfach TightVNC 2.0.2 unter WindowsXP installieren und die *.reg-Datei einspielen, so, wie du es bei Windows7 gemacht hast? Gibt es da irgendwelche Probleme?
Es muss ja einen Grund geben, weshalb du bei WindowsXP einen völlig anderen Weg mit einer völlig anderen Version gegangen bist.
Okay vielleicht hab ich es diesmal verstanden 😀
TightVNC 2.0.2 wird nicht auf Windows XP installiert, frag mich nicht warum. Ich habe in der Gruppenrichtlinie sowohl Windows 7 als auch Windows XP Computer. Bei Windows 7 funktioniert alles einwandfrei, 2.0.2 wird installiert. Bei Windows XP funktioniert die Installation von 2.0.2 nicht. Ich bin ehrlich gesagt der Sache nicht weiter nachgegangen, warum die .msi Installation bei XP nicht greift. Mach ich nachher vielleicht nochmal kurz.
Oder ich finde den Grund gleich wieder, hab ihn nur mal wieder vergessen. Who knows.
EDIT:
Okay, TightVNC 2.0.2 wird auch auf Windows XP normal installiert und funktioniert ebenfalls. Da muss ich beim letzten Versuch noch irgendwas anderes falsch gemacht haben.
Der Weg über die 1.3 mit manuellem Start ist also alternativ. Der Vorteil: Fernsteuerung ist nur möglich, wenn der Client den Server (manuell) gestartet hat. Vorher muss also eine Absprache stattfinden.
Wer lieber diesen Weg bevorzugt, Server manuell nur bei Bedarf starten, wird diesen Weg nehmen müssen.
Hi,
das kommt fast wie gerufen :
Ich hadere seit einiger Zeit mit TightVNC 1.3, es läuft nicht unter Win7 und W2k8. (Grund ist bekannt). Wir verwenden für unser AD „Hyena“ und nutzen intensiv das enthaltene Tool „STRCM“, mit dem man aus der Anwendung raus per Rechtsklick ne VNC Sitzung starten kann. Könnte.. wenn man vorher am VNC Server die zulässigen IP Adressen der SteuerPCs hinterlegt.
Trotzdem ne super Man, danke. Werd mich wohl mal intensiver mit den Regkeys befassen müssen und versuchen die zu verteilen.
Registry Sachen im Netzwerk mit Active Directory und GPO aber bitte nicht immer mit Startscript und .reg Exports machen! Das ist an sich ne unsaubere Methode und macht nur in wenigen Fällen Sinn. Auch hier bei diesem System könnte man es hübscher lösen, das wäre vom Umfang hier aber kaum zu erklären gewesen.
Für Regverteilung per GPO:
Computerverwaltung -> Einstellungen (im neuen GP Editor) -> Windows-Einstellungen -> Registrierung.
Dort am besten eine Sammlung für jedes Projekt, damit Übersicht erhalten bleibt und dann erstellen, editieren oder löschen von Keys über die Aktionen.
Aber beide Möglichkeiten, GPO und .bat funktionieren natürlich.
Hallo,
ich habe deinen Artikel kurz überflogen. Eine Menge Aufwand für eine Funktion, die die genannten Systeme out-of-the-box mitbringen: RemoteDesktop und Remoteunterstützung.
Warum nutzt du nicht einfach das, was ohnehin vorhanden ist?
Beschäftige dich lange genug mit den Fernwartungssystemen, den Feature, dem Deployment, der Administration etc und du wirst die Antwort von alleine finden.
Und wirklich viel Aufwand ist es eigentlich nicht. 6 Schritte plus Test, das ist mit meiner Anleitung an nem Tag umgesetzt.
Ich wollte dich nicht angreifen.
Zum Punkt ‘Beschäftige dich lange genug…’:
Ich bin seit 8 Jahren im Geschäft und seit knapp 2 Jahren IT-Leiter in einem der Top 5 Unternehmen in Europa.
Zum Punkt ‘wirklich viel Aufwand ist es nicht’:
Richtig, ‘nur ‘EIN Tag, den man sich aus meiner Sicht sparen kann!
Sei doch so gut und kläre mich über die Vorteile auf? Ich kann keinen sehen…
Du führst Deployment an: RDP braucht keins. Out-of-the-box
Welches Feature bringt mir VNC, das RDP nicht hat?
Administration? Von RDP? Falls eingesetzt muss man die Windows Firewall konfigurieren. Per GPO – ist alles schon da.
Wo ist jetzt der Vorteil?
VNC hat im Vergleich zu RDP einen großen Vorteil: RDP nutzt eine eigene Session für Leute, die sich remote anmelden. Gerade für Remote Support ist das sehr unpraktisch.
VNC funktioniert auch unter Windows XP Home – das sieht bei RDP anders aus. Das ist erst ab Win XP Pro verfügbar. Dort gibt es nur diese merkwürdige Remote-Support-Request-Irgendwas-Dingsbums. VNC ist also das „Ding“ der Wahl für private Nutzer.
Last but not least habe ich es bisher auch nicht hinbekommen, RDP so zu konfigurieren, dass es nur auf die Loopback-Adresse hört (z.B., um es über eine vorgeschaltete SSH-Verbindung abzusichern). Bei VNC ist diese Einstellung ein Kinderspiel.
Ein weiterer Vorteil, der je nach Anwendergruppe Sinn macht, ist der, dass man sich mit TightVNC ohne jegliches Zutun der Nutzer auf den PC schalten kann. Bei RDP sind vorher Aktionen des Nutzers nötig.
Wir arbeiten vor allem mit technikscheuen Wissenschaftlern der oberen Altersgruppe, da kommt das ganz gelegen.
Hallo und danke für die Antwort. Inhaltlich bin ich nicht ganz einverstanden.
zu 1)
RDP ist das Protokoll. Eine Remote-Desktop-Session, wie du sie beschreibst, ist nicht für Remote Support vorgesehen. Da nimmt man die sog. ‚Remoteunterstützung‘. Das Protokoll ist ebenfalls RDP, im Gegensatz zur Remote-Desktop-Session arbeiten hier zwei Benutzer auf dem selben Desktop. Nach Freigabe des Hilfesuchenden kann der Supporter auch die Steuerung des Zielsystems übernehmen.
zu 2)
Da hast du Recht. Eine Remote-Desktop-Session ist hier nicht möglich. Remoteunterstützung hingegen schon. Abgesehen davon betrachten wir hier doch die Situation in professionellem Umfeld. Deine Anleitung bezieht sich auf den Einsatz in einer ActiveDirectory Domäne und XP home kann nicht in die AD aufgenommen werden. Dafür gibt es XP prof. Für private Nutzung ist meiner Ansicht nach Teamviewer das ‚Ding‘ der Wahl – aber das tut nichts zur Sache. Wir betrachten ja den Einsatz in professioneller Umgebung.
zu 3)
Das ist sehr wohl möglich, auch wenn ich die Notwendigkeit in diesem Szenario nicht sehe.
@Hannes:
Eine Session für Remoteunterstützung ohne Interaktion des Nutzers kann durchaus nützlich sein. Das stimmt sicher.