Unterwegs setzen wir für die Internetverbindung unseren Mobilen Hotspot ein, einen Linksys UMTS Router, so auch hier auf der Hütte in Österreich.

Bisher genügten uns Vodafone WebSessions international, allerdings werden 50 MB Datenvolumen immer weniger und reichen für 2 Laptops, ein iPad und ein paar iPhones durchschnittlich ca. 3 Stunden.  Bei einem Preis von 14,95 € pro Session muß also eine andere Lösung her.

In Österreich bieten die Mobilfunkanbieter inzwischen auch Prepaid Datentarife an mit Kosten von rund 20 € pro Gigabyte Datenvolumen. Ein Preisvorteil von immerhin rund 93%, also bei längerem Aufenthalt durchaus etwas Arbeit wert.

Mein erster Versuch war das Internet to Go Paket von 3, ein USB Stick und 2 GB Datenvolumen für 49,90 € im Set. Weitere Gigabytes kann man dann ganz einfach mit Kreditkarte nachordern. Leider war es nicht möglich, das Paket schon von Deutschland aus zu ordern und dort zu testen, so daß ich erst in einen Shop nach Schwaz fahren mußte, um das Paket zu kaufen. Man muß sich übrigens nicht ausweisen dafür, mitnehmen, bezahlen, fertig. Ich dachte immer, Internet Provider müssten nachweisen können, wer über den Anschluß surft?

Die Installation war einfach, USB Stick ins Notebook, das blendet ein CD Laufwerk ein, Software installieren, PIN eingeben, Connect drücken und die Verbindung war hergestellt:

Ab hier wurde es nun schwieriger, denn der Huawei E1221 USB Stick wird vom Linksys UMTS Router garnicht erkannt (und auch nicht offiziell unterstützt). Die uSIM von 3 funktioniert zwar in meinem Vodafone K3565 USB Stick im Notebook, nicht aber, wenn ich den Stick in den Linksys steckte. In der Express Karte Novatel XU870 verhielt es sich genauso, im Notebook funktionerte die Verbindung, der Linksys Router brachte ständig die Anzeige “Network Name: Aquiring”. Auch eine manuelle Auswahl des Netzwerkes war nicht möglich und verschiedene Standorte in der Hütte brachten keine Veränderung.

Nächster Versuch. Meine Vodafone WebSessions sind immer im Netzwerk von A1 eingebucht, also suchte ich auf der Internetseite nach einem PrePaid Datenangebut und wurde mit B.Free Breitband von A1 (Telekom Austria) fündig, 1,5 GB für 19,90 € ohne USB Stick:

Wieder die Suche nach einem Shop, diesmal mußte ich nach Wörgl fahren, dort verkaufte man mir das Starterpaket, wieder ohne Ausweis zeigen. Nachteil dieses Paketes, daher hatte ich ursprünglich nicht gewählt – man kann es als Ausländer nur mit Ladebons aufladen, man muß dazu also in Österreich sein. Immerhin gibt es die Ladebons in allen Supermärkten und Tankstellen.

In der Anleitung steht dann gleich, man solle die SIM Karte in das Vodafone Modem einsetzen, das schafft Vertrauen, daß es in unserem Linksys Router auch geht. Zunächst aber habe ich die SIM in den Vodafone USB Stick eingesetzt, diesen an den Laptop angesteckt auf dem schon eine Vodafone Mobile Connect Software installiert war. Die erkannte die A1 Karte sofort, konfigurierte den APN und war online.

Nun der große Moment, USB Stick in den Linksys Router einsetzen, einschalten. APN, Benutzer und Kennwort müssen manuell eingestellt werden:

APN: a1.net
Benutzer: ppp@A1plus.at
Passwort: ppp

Und – es funktioniert:

Der Speedtest zeigt auch den Erfolg – der Pohle Air Hüttentraum verfügt über High Speed Internet:

Dieses steht natürlich unseren Gästen jederzeit kostenlos zur Verfügung, wie auch das iPad, das zur freien Verwendung für jeden in der Hüttenstube liegt (ich berichtete schon, daß man es schwer fotografieren kann, weil es so spiegelt):

Es ist auch jederzeit möglich, nachzusehen, wieviel Volumen noch vorhanden ist, so daß man rechtzeitig nachladen kann:

Nachtrag:

Das Nachladen des B.Free Breitband funktioniert, ist ein mehrstufiger, etwas umständlicher Prozeß.

Für Ausländer entfällt leider die Online Aufladung am Bankomaten oder über Paybox, wir müssen in Österreich sein und in einem Supermarkt an der Kasse oder an einer Tankstelle einen B.Free Bon im Wert von 20 € oder 40 € kaufen. Diese Bonnummer gibt man dann auf der B.Free Website ein und lädt damit erstmal sein Guthaben von 1 €, das man im B.Free Breitband hat, auf:

Dann kauft man auf der Website ein “Breitband-Paket”

und verwandelt so das Guthaben in € in ein Guthaben in MB:

Seit ich am das Foto unseres frisch aufgeräumten Rechnerraumes online gestellt habe, erreichen mich ständig Anfragen zu den Geräten, die man da sieht. Das überrascht und freut mich sehr. Also – hier die Erklärungen. Ich habe jeweils in das Foto Nummern eingefügt und erkläre diese Nummern dann im Text direkt darunter.

Linker Teil des Regals, oben:

1. Darmstadt – Unser Fernsehaufnamerechner. Er ist mit einer Hauppauge WinTV PVR-350 Karte ausgerüstet, die an unserem Kabelanschluß hängt und Fernsehsendungen aufnimmt. Über diesen Rechner habe ich schon mal hier geschrieben.
2. Ein Videorecorder von Sony. Er ist via Scart Kabel an die Hauppauge Karte im Rechner Darmstadt daneben angeschlossen und erlaubt uns, Videokassetten zu digitalisieren. Vorzug dabei ist – er macht das nicht nur mit VHS Kassetten, sondern auch mit den Video 8 Tapes aus Thomas allererster Videokamera.
3. Das Spiralkabel das von der Decke hängt ist ein Relikt an die Anfangszeiten unseres Rechnerraumes. Es kommt vom Deckenauslaß, führt also Strom, wenn im Rechnerraum das Licht eingeschaltet wird. Das Spiralkabel führt hinten im Rack auf Kaltgerätesteckdosen und dort waren früher die 10 Monitore angeschlossen, die in diesem Regal eingebaut waren. Licht an = Monitore an – der Theorie folgend, daß man Monitore nur braucht, wenn man im Raum ist. Die Monitore gibt es nicht mehr, das Kabel schon, aber es hängt nur noch der Flatscreen und der Lautsprecher dran, so daß der Einschalteffekt nicht mehr so atemberaubend ist.
4. Ein Lautsprecher. Der hängt an der Soundkarte von Darmstadt, damit man kontrollieren kann, ob der Rechner Sound aufzeichnet. Die Stromversorgung dieses Lautsprechers erfolgt über den Lichtschalter (siehe 3), so daß nur Sound im Raum ist, wenn auch einer da ist.
5. Ein Temperatursensor, der an der MessPC Ethernet Box hängt und die Temperatur oben überwacht. Diese wird von unserem Nagios abgefragt.
6. Ein Feuchtigkeitssensor, Rest siehe 5
7. Uranus – mein erster Tablet PC. Ein Fujitsu Siemens Stylistic aus dem Jahr 2002. Ich habe ihn etwa 2 Jahre als meinen “immer dabei” Rechner mitgeführt. Als ich ihn dann durch ein Acer Table ablöste (seither habe ich keine Slates mehr, sondern nur Convertible Tablets, die die Tastatur fest eingebaut haben) führte ich ihn einer viel nützlicheren Verwendung zu: Er besitzt ein “Outdoor Display”, man kann die Anzeige also ohne Beleuchtung auch im grellsten Sonnenlicht erkennen – ideal, um als Cockpitcomputer im Flugzeug zur Anzeige der Anflugkarten zu dienen. Er hat einen kleinen Bluetooth Stecker, mit dem ist er mit einem portablen Bluetooth GPS verbunden und zeigt mir dann auf den Anflugkarten sogar die aktuelle Position an. Wer schon mit mir geflogen ist, weiß, daß ich ihn, außer bei unseren Rundflügen, immer auf den Knien habe.
8. Die Tastatur dieses Tablet PC ist mit Infrarot verbunden. Das ist übrigens blödsinnig – hier im Rechnerraum, wo der Tablet auf einem Ständer steht, geht das ja noch ganz gut. Was aber, wenn man in einem Zug oder einem Flugzeug mit der Tastatur arbeiten möchte? Genau, das funktioniert nicht, weil man nicht weiß, wie man da alles aufstellen soll. Daher bleibt bei meinem Uranus die Tastatur und der Ständer schön im Rechnerraum und nur der Tablet PC kommt mit.
9. Ein externes CD Laufwerk für den Tablet, hauptsächlich, um die Jeppesen Software für die Anflugkarten zu pflegen, da kommen Aktualisierungen nicht immer nur per Internet, sondern auch manchmal auf CD.
10. Wir verwenden in den meisten Geräten keine Batterien, sondern Akkus. Irgendwo müssen die aufgeladen werden und so stehen hier meine Ansmann Ladegeräte für Mignon und Micro Akkus und die Ladegeräte für die Sony Videokameras und die Canon EOS 350 Kameras.
11. Über die beiden Funkgeräte müßte man ja fast einen eigenen Artikel schreiben – die dienen Thomas und mir dazu, daß wir uns, wenn ich Rundflüge mache oder wir an verschiedenen Flugplätzen dieser Welt unterwegs sind, miteinander verständigen können. Wir haben lange danach gesucht und von der Bundesnetzagentur über die Deutsche Flugsicherung viele Anfragen gestartet – diese Motorola Geräten sind die einzigen, die an den meisten Orten auf der Welt betrieben werden können. Hier werden sie aufgeladen und warten auf ihren nächsten Einsatz.
12. Mein alter Sony Vaio VGN A117 – den hatte ich schon mal beschrieben, das ist meine “Leise Konsole” für den Einsatz im Garten oder vor dem Haus – ein Laptop mit einer SSD und einem superhellen Display. Hier parkt er und wird aufgeladen.

Rechter Teil des Regals, oben:

1. Monalisa – auf diesem Rechner läuft die Serversoftware für unsere Pinnacle ShowCenter 200, die im Haus verteilt sind. So können wir alle digitalisierten Filme überall im Haus ansehen. Wir sind übrigens vollständig noch im “Nicht HD Zeitalter” und scheuen die Umrüstung.
2. Die externen Festplatten sind an Monalisa angeschlossen und uns Filesystem eingebunden. So kommt der Rechner zusammen mit den internen Platten auf etwa 3 TB Speicherplatz. Da wir, wie erwähnt, nicht HD fahren, ist noch einiges frei. Monalisa hat übrigens, ob der Datenmengen, eine eigene Sicherungsplatte und wird einmal im Monat gesichert.
3. Leonardo – das ist unser NAS Server, der via iSCSI die Datenpartitionen unseres Fileserver bereitstellt und mittels SMB/CIFS einige Shares hostet (z.B. für Musik und Photos). Er hat 4 interne Platten mit je 750 GB, die über ein Software RAID 5 zusammengefaßt sind, das ergibt etwa 2 TB nutzbaren Platz. Der Server läuft mit FreeNAS und wenn ich nicht gelegentlich aus lauter Gewohnheit ein Update installieren würde, könnte ich fast vergessen, daß er da ist – so stabil und völlig störungsfrei läuft er. Das Software RAID hat übrigens schon einen Festplattenausfall erfolgreich überlebt und sich nach dem Austausch der Platte einwandfrei rekonstruiert. Das Betriebssystem booted übrigens von dem USB Stick der vorne raussteht (siehe Pfeil), so daß die 4 eingebauten Platten vollständig zur Verfügung stehen.
4. Ein Ladesystem für Handies und iPhones und Blackberries.
5. Backupfestplatten. Ich mag die Western Digital MyBook Festplatten sehr gerne, weil die chic aussehen, aufrecht stehen (nimmt wenig Platz weg) und sich auch in ein Bücherregal stellen lassen.
6. Die Dockingstation von meinem Dell Latitude XT (ein convertible, ich bin seit 2002 dem Thema Tablet PC treu geblieben). Sie steht eigentlich nur hier, weil ich keinen anderen Platz dafür habe – ich mag Docking Stations nicht sehr gerne.

19″ Schrank, oben:

1. Hier kommen die Kabel aus den Büros an. Wir haben seinerzeit übrigens CAT 7 Kabel verlegen lassen (das war 1998 noch ziemlich futuristisch) und sind somit noch für einige Zeit gerüstet. Derzeit ist das schnellste, was wir fahren, sowieso nur Gigabit Ethernet, also reicht auch das CAT 6 Patchpanel (ein CAT 7 Panel gab es 1998 noch nicht).
2. Unser Gigabit Backbone Switch – der hat gerade keine Kabel drin, weil er bei unserem Umbau den Geist aufgegeben hat (bei Abschaltungen im Rechenzentrum geht immer was kaputt). Ersatz ist unterwegs, kam aber nicht mehr rechtzeitig fürs Foto.
3. Der Netgear Fast Ethernet Switch, der hat zwei Gigabit Ports, einen benutze ich für einen Server, einen zum Uplink zum Gigabit Switch.
4. Unser Internet Router. Das ist das AVM VoIP Gateway 5188, das sollte mal eine Fritz!Box für Unternehmen werden mit 4 internen und 4 externen ISDN Bussen. Hatte als erstes einen eingebauten VPN Server. Leider wurde das Produkt eingestellt, was ich jammerschade finde.
5. Ein GBit Switch aus meinem Unterwegs-Netzwerk. Ist solange als Ersatz eingebaut, bis der “große” Gigabit Switch da ist.
6. Eine Bianca Brick XM. Etwa Baujahr 1999. Ein modularer Router, in den Man Netzwerkkarten und ISDN Karten einbauen kann. Über die ISDN Karten wurden dann Netzwerkverbindungen hergestellt, oder die ISDN Karten wurden mit einer Netzwerk CAPI geteilt. Dieser hier hat sogar ISDN Karten mit Modemfunktion, die können als Faxmodem dienen. In ihren goldenen Zeiten war diese Bianca ein Einwahlserver für Außendienstmitarbeiter, die sich vom Laptop aus übers Handy ins Netzwerk einwählten. Direkt. Ohne Internet dazwischen.
7. Eine Bianca Brick XS. Die ist Baujahr 1997. Die kleine Schwester von der XM, dieses Modell hat ein 10 MBit Ethernet Interface und eine ISDN Karte. Das war unser erster Internet Router, der unser Netzwerk mit 64 KBit ans Internet angebunden hat, damals noch bei SpaceNet in München. Heute darf sie als Netzwerk CAPI dienen und unseren Konfigurationszugang in die Telefonanlage bereitstellen.
8. Ein Auvisio Mediaserver, der steht hier nicht produktiv, sondern ist nur ein Ersatzgerät. Man baut eine Platte ein, lädt Musik und Filme drauf und kann die dann an einem angeschlossenen Fernseher ansehen.
9. Das Gateway für unsere Netzwerkgäste. Trennt das WLAN für unsere Gäste im Büro und Besprechungsraum von unserem Netzwerk und erlaubt unseren Gästen den Zugriff aufs Internet (mit einem Ticketsystem).
10. Das Musiphone mit 6 Kanälen, hängt analog an der Telefonanlage und sorgt mit einem Kanal für Wartemusik und mit den anderen 5 Kanälen für Ansagen. Wenn Sie meine persönliche Durchwahl anrufen und eine Ansage kommt, daß Sie nun mit mir verbunden werden, dann sind Sie in diesem Gerät gerade auf Kanal 4 unterwegs.

19″ Schrank, unten:

1. Sissy – Das ist die Ansage vor Abfrage für verschiedene unserer Hotlines.
2. Sieht geheimnisvoll aus, nicht? Ist aber ein simpler CD Case. Thomas hebt dort seine CDs mit den Wartemusiken und den für uns gesprochenen Ansagen auf, damit er die immer griffbereit hat, wenn er eine Ansage ändern oder neu einspielen muß.
3. Info – Wenn Sie das Glück haben, während unseres Urlaubs anzurufen (was zugegeben, leider selten vorkommt) dann landen Sie hier und bekommen mitgeteilt, daß die Pohle & Schultes AG im Urlaub ist. Wir sollten den Info viel öfter aktivieren, denke ich mir gerade.
4. Mozart – Wenn Sie unsere Hauptnummer wählen, werden sie direkt, bevor sich jemand meldet, von feiner Musik begrüßt. Das macht unser Mozart. Die Stimme ist übrigens von Frau Klaas (falls Sie ihr mal Grüß Gott sagen möchten während Sie warten).
5. 3 Musiphone Ansagegeräte – die waren mal die wichtigsten (zumindest für Kunden, die ein Problem hatten), denn sie bildeten viele Jahre unsere Expressschaltung. Deshalb dürfen sie auch weiter auf ihrem Platz bleiben.
6. Unser Prunkstück – eine Original Deutsche Post Wartemusik. Modell “Hanau”. Das ist übrigens die Wartemusik unserer privaten Telefonanlage. Das Baujahr ist nicht bekannt, wir schätzen aber so um 1980 rum.
7. Die Schlüssel für unseren 19″ Schrank. Am besten im Schrank aufgehoben. Nein, wir schließen ihn nicht ab.

19″ Schrank, oben – von hinten:

1. Eine 4-fach schaltbare Steckdosenleiste von Infratec. Die schaltet hier unser Internet Gateway (wofür es ein Script auf unserem Nagios gibt – er stellt fest, daß das Internet nicht verfügbar ist und löst einen Reset des Gateway aus durch aus- und einschalten der Stromversorgung) und an den anderen drei Steckdosen unsere Netzwerk Switches und die beiden Biancas.
2. Hier sieht man die beiden Biancas mal von hinten mit ihren Anschlüssen.
3. Unser 19″ Schrank verfügt, wie unser gesamter Rechnerraum über 2 unabhängige Stromkreise.

Einer unserer Server von hinten, hier der Medienserver “Monalisa”:

1. Die Kabel zu den externen Festplatten, Strom und USB 2.0
2. Das Kabel zum Bildschirmumschalter. Der wird weiter unten im Detail gezeigt.
3. Eine der Infratec PM211 Steckdosenleisten. Die haben jeweils einen Netzwerkanschluß und 2 unabhänig voneinander schaltbare Kontakte mit je 2 Steckdosen. An diesem Server ist das so gelöst, daß die USB Festplatten gesondert geschaltet werden können, da der Rechner nicht startet, wenn externer USB Platten angeschlossen sind.
4. Der linke Server ist Leonardo, unser NAS System.

Unser IP-Konsolensystem (wir haben noch ein anderes, ohne Fernzugriff):

1. Unsere 4 “lebenswichtigen” Server hängen an diesem einfachen 4-fach KVM-Umschalter. Zugegeben, die Kabel sind etwas sperrig, aber es sind nur 4 Stück und der Switch ist auch nicht mehr ganz taufrisch. Er kann natürlich per Softkey umgeschaltet werden, denn es hängt ja keine lokale Konsole dran, es könnte also gar keiner lokal umschalten.
2. Unser AVOCENT SwitchView IP1020 der das Signal vom Konsolenumschalter auf dem Netzwerk per IP bereitstellt. Er braucht keine lokale Software zum Zugriff, sondern liefert ein Java Applet aus, mit dem dann die Konsolen gesteuert werden können. Das ist eine einfache und günstige Lösung für IP Zugriff, wenn man nur wenige Server hat und ist bei vielen unserer kleineren Kunden im Einsatz. Kann 1024*768, für Serverkonsolen genügt das.

Unser zweites Konsolensystem im Testlabor:

1. Das ist unser zweites Konsolensystem, auch ein einfaches Gerät. Das ist allerdings schon etwas moderner, und die Kabel sind schon dünner. Schafft übrigens 1680*1050 auf einen LCD problemlos und ohne Unschärfe!
2. Hier hängt kein IP System dran, sondern ein physikalischer Monitor auf dem Tisch.
3. Der Netzwerk Switch vom Testlabor, das natürlich per Firewall vom restlichen Netzwerk getrennt ist.
4. Die Rechner vom Testlabor.

Linker Teil des Regals, unten:

1. Hier sieht man die 4 Rechner unseres Testlabors von vorne. Die erfüllen unterschiedliche und wechselnde Aufgaben, weshalb sich eine detaillierte Beschreibung nicht anbietet – sie wäre schon nach wenigen Tagen inaktuell.
2. Der Rechner Sahara ist produktiv, denn er ist für die Datensicherung unseres ESXi Systems zuständig (mit VMExplorer) und dient als Konsole im Rechnerraum.
3. Unser Konferenztelefon Polycom SoundStation 2W, das wird hier natürlich nicht verwendet, sondern steht nur zum Laden des Akkus hier. Es ist ja ein schnurloses System, das wir im gesamten Bürobereich verwenden. Im Garten funktioniert es leider nicht. Die Reichweite des Senders würde passen, aber wir haben soviele Vögel hier wohnen, daß jedes Telefonat klingt, als würde ich aus einer Vogelvoliere telefonieren.
4. Der Laptop von Thomas, der steht auch nicht zum Arbeiten hier, sondern wird hier nur aufgeladen. Da er ihn meistens irgendwo im Haus oder im Garten benutzt, ist es unpraktisch, ihn in seinem Büro im zweiten Stock aufzuladen.
5. Unser Canon i965 Fotodrucker. Wird hauptsächlich benutzt, um Fotos auszudrucken und das kann er sehr gut und sehr farbecht. Thomas nimmt ihn auch manchmal her, um Druckvorlagen für Kataloge auf Fotopapier zu drucken, das ist farbechter, als Testdrucke auf dem Farblaser.
6. Die Festplatte der Datensicherung, natürlich nur eine davon, die werden im wöchentlichen Wechsel zwischen unserem Tresor, dem Bankschließfach und diesem Regal reihum getauscht. Ja, ich sichere zwar täglich, aber die Platte tauschen wir nur einmal pro Woche aus. Das ist für unsere Sicherungsanforderungen der beste Kompromiß.
7. Der Monitor im Rechnerraum. Kann über den Bildschirmumschalter auf alle Rechner des Testlabors, ist aber meistens auf Sahara geschaltet.

Nochmal eine Ansicht in der Totalen:

1. Wickie, das ist unser VMWare ESXi Server.

Zum Schluß noch ein Schwenk nach links, an die Wand mit den Telefonanlagen:

1. Hier kommen alle Leitungen der Telekom an und weil es soviele sind, haben wir für die NTBAs einen kleinen Kasten bekommen.
2. Notfalltelefon. Das hängt auf einer analogen Amtsleitung und funktioniert auch, wenn sonst garnichts mehr funktioniert. Die Nummer steht übrigens im Telefonbuch und wird regelmäßig von den Gewinnspielautomaten angerufen. Wir heben nur selten ab.
3. Der Splitter für DSL. Wir haben inzwischen auch einen 16 Mbit Downstream, 1 MBit Upstream DSL Anschluß der Telekom mit fixer IP Adresse. Der ersetzt die 2 MBit Leitung prächtig.
4. Ein Relikt an alte Zeiten, der Anschlußkasten unserer 2 MBit Leitung. Symmetrisch. War wahnsinnig teuer seinerzeit diese Leitung. Glücklicherweise durch DSL inzwischen obsolet. Wir lassen den Kasten einfach hängen, als Erinnerung.
5. Die Batterie für die Telefonanlagen APC Back UPS CS 650. Ermöglicht, daß wir bei Stromausfall noch telefonieren können und dient als Blitzschutz.
6. Unsere dienstälteste Telefonanlage, eine Telenorma I2. Die ist heute noch im Einsatz und funktioniert prächtig.
7. Wir lieben vor allem die wunderschönen Systemtelefone dieser Anlage, hier eines davon.
8. Diese Telefonanlage, eine Bosch I3 stieß zu uns, als wir nach Dorfen umzogen, das ist jetzt auch schon 12 Jahre her und die I3 ist nicht mehr im Angebot.
9. Der Verteilerkasten unserer Telefonanlage.
10. Hier hängt nichts mehr, denn das war der Platz der Klimaanlage. Im Zuge der Virtualisierung unserer Rechnerfarm wurde die Wärmelast so niedrig, daß wir die Klimaanlage nicht mehr brauchen. Spart Lärm, Strom und Unmengen CO2. Ein Buzz-Word habe ich auch noch dafür: GreenIT.
11. Wenn Sie uns eine Nachricht auf einem Anrufbeantworter hinterlassen, ist die Chance groß, daß Ihre Worte hier auf der Festplatte landen. Memo heißt er.
12. Hier lagern wir das Foto-Papier für den Foto-Drucker.

Man kann die Konsolen von virtuellen Maschinen, die auf einem ESX oder ESXi Server laufen, auch direkt aufrufen, ohne jedesmal den VMWare vSphere Client öffnen zu müssen. Das bietet sich an, wenn man mit einzelnen Konsolen häufig arbeitet und nicht jedesmal den gesamten VMWare ESX Server verwalten möchte (die hier beschriebene Vorgehendweise ist für vSphere unter Windows, ich bin sicher, es funktioniert unter Linux ähnlich).

Auf dem Windows Rechner muß der VMWare vSphere Client installiert sein, dann ist im Verzeichnis

C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\4.0

das Programm “vmware-vmrc.exe” vorhanden. Mit diesem legt man sich einen Shortcut mit der folgenden Commandline an:

“C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\4.0\vmware-vmrc.exe” -h HOSTNAME -u USERNAME -p PASSWORD “[Datastore 2 RAID 1] Blackberry/Blackberry.vmx”

Die Parameter HOSTNAME, USERNAME und PASSWORT ermittelt man recht einfach, es sind die gleichen, die man beim Start des vSphere Client eingibt:

Die fügt man so, wie man sie eingibt, in den Shortcut ein, also ohne irgendwelche Anführungszeichen.

Die Virtuelle Maschine zu übergeben, ist etwas trickreicher. Dazu startet man am besten den vSphere Client und geht in die Eigenschaften der gewünschten VM findet man die Angabe des “Virtual Maschine Configuration File”:

Den kopiert man sich komplett heraus und setzt ihn zwischen zwei Anführungszeichen in den Aufruf:

“C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\4.0\vmware-vmrc.exe” -h HOSTNAME -u USERNAME -p PASSWORD “[Datastore 2 RAID 1] Blackberry/Blackberry.vmx“

Diese Komandozeile kann man dann entweder aus einem Batch oder einem Icon auf dem Desktop heraus aufrufen. Die Konsole hat dann auch einen chicen blauen Rand, statt dem gewohnten grünen vom vSphere Client:

Diese Vorgehensweise ist nicht nur einfacher zu handhaben, es spart auch Zeit, denn der Start der einzelnen Remote Console aus dem Shortcut geht dramatisch schneller, als den vSphere Client zu laden, die richtige VM auszusuchen und deren Remote Console zu laden.

Man kann in den Optionen der Microsoft Windows Server Update Services zwar einen Synchronization Schedule einstellen und dem WSuS damit zumindest sagen, wann er bitte mit dem Download der Updates vom Microsoft Server oder vom übergeordneten WSuS Server beginnen möge:

Mehr, als eine Bitte ist das aber nicht. Die tatsächliche Übertragung der Patches wird durch den Background Intelligent Transfer Service (kurz BITS) durchgeführt und der entscheidet meist selbst, wann er übertragen möchte.

Das fällt in den meisten Netzwerken nicht weiter auf, zumindest wird nicht unmittelbar klar, daß die WAN Leitungen durch die Übertragung von Patches zwischen den WSuS Servern langsam sind. In einer aktuellen Installation sind die WAN Leitungen aber mit Citrix WanScaler komprimiert und der liefert erstklassige Statistiken, wann tatsächlich übertragen wird und gibt dazu auch die Nodes an. So konnten wir ermitteln, daß die Übertragun der Patches mitnichten nur in der Nacht stattfindet, wie das eigentlich im Synchronization Schedule durch die Vorgabe der Startzeit gewünscht wäre.

Abhilfe gibt es aber: Der BITS Dienst läßt sich über Group Policies bzw. direkte Registry Einträge konfigurieren. So findet man auf einem Windows 2008 Server ein Setting “Limit the maximum network bandwit (auf Windows 2003 findet man das an gleicher Stelle in den Group Policies, aber dort sind nicht soviele andere Optionen einstellbar):

Hier kann man nun die genauen Zeiten angeben, zu denen man die Übertragungsbandbreite begrenzt haben möchte. Wir haben uns entschieden, für die nächtliche Übertragung mehr Bandbreite und tagsüber weniger bereitzustellen, man könnte hier natürlich auch z.b. von 7 – 20 Uhr auf 500 MBit begrenzen und den Rest auf Maximale Übertragung setzen – das muß von Netz zu Netz gesondert entschieden werden:

Diese Einstellung muß auf jedem WSuS Server im Netzwerk lokal durchgeführt werden und anschließend wird der BITS Dienst in den Windows Services neu gestartet. Bei einer sternförmigen Architektur von WSuS Servern limitiert der zentrale Server die gesamte verfügbare Bandbreite. Ich würde also empfehlen, in den Außenstellen eine Geschwindigkeit zu wählen, die zur jeweiligen lokalen WAN Anbindung paßt und in der Zentrale entsprechend mehr Bandbreite zu genehmigen, wenn dort ein schnellerer WAN Anschluß vorhanden ist.

Gestern mittag, das war der 6. Januar 2010 erreichten uns die ersten Anruf von Kunden, daß wohl unsere Webserver nicht mehr funktionieren, http://pohle.de wäre nicht erreichbar. Eine kurze Störungsanalyse unsererseits ergab, daß die beiden Nameserver unserer Domänen nicht mehr auf PING und NSLookup Anfragen reagierten.

Das wurde per Twitter Meldung kommuniziert:

An dieser Stelle ist wohl eine Erklärung fällig, warum uns dieser Ausfall betroffen hat:

Wir hosten alle unsere Services selbst in unserem eigenen Rechenzentrum in Dorfen. Dieses ist mit einer Standleitung der Deutschen Telekom an das Internet angebunden. Wir verfügen über eine Ersatzleitung ins Internet über das Vodafone UMTS Netzwerk, ich kann manuell das Routing unseres Datenverkehrs umschalten (eine automatische Umschaltung ist wenig sinnvoll, da die Telekom in den letzten Jahren die wenigen Fehler auf der Leitung schneller behoben hat, als ich hätte umschalten können).

Internet Domänen können wir hingegen nicht selbst registrieren, sondern müssen die Dienste eines sogenannten DNS Providers in Anspruch nehmen, das ist in unserem Fall aus historischen Gründen die ehemalige Schlund und Partner AG (ein Webhoster für Geschäftskunden) heute die Schlund Technologies GmbH mit Sitz in Regensburg, deren Geschäft von der InterNetX GmbH durchgeführt wird.

Da wir alle Domänen über Schlund Technologies beziehen und verwalten, ist es am einfachsten, die DNS Server dieses Unternehmens für die Domänen zu verwenden, Schlund bietet eine geclusterte DNS Infrastruktur an, das hat auch viele Jahre sehr zufriedenstellend funktioniert.

Die erste größere Störung gab es im November 2008, da wurde gegen die DNS Server von InternetX eine DDOS (Distributed Denial of Service) Attacke durchgeführt, welche die DNS Server in die Knie gezwungen hat und die Domänen waren nicht mehr erreichbar. DDOS funktioniert recht einfach, man ballert von vielen, damals waren es 40.000, Rechnern ständig Abfragen an die Server, die unter der Last dann nicht mehr verknünftig arbeiten bzw. so überlastet sind, daß sie die “regulären” Anfragen nicht mehr zeitgerecht beantworten können (siehe auch den Artikel in golem.dedazu).

Das hat zur Folge, daß Rechner, die nach der Adresse für http://pohle.de suchen, keine Antwort vom zuständigen Namens-Server erhalten und einfach zurückmelden, daß die Website http://pohle.de eben nicht erreichbar ist. Nun sieht das für den Endanwender so aus, als wären unsere Server down, dabei ist “nur” das Telefonbuch außer Betrieb, das die gängigen Namen in Netzwerkadressen übersetzt (und aus pohle.de die Adresse 87.139.89.37 macht).

Nach der Attacke im November 2008 hat Schlund Technologies / InternetX den Kunden versprochen, daß entsprechende Maßnahmen getroffen werden, so daß so etwas nicht wieder vorkommen wird. Das ist bei DDOS recht schwierig, denn es handelt sich ja um viele Rechner, die über die ganze Welt verteilt sind und mehr oder weniger reguläre Pakete und Anfragen absetzen. Jedenfalls hat das bis gestern funktioniert und dann, ausgerechnet am bayerischen Feiertag (die sitzen in Regensburg), kommt wieder so eine Attacke und es dauerte bis zum frühen Abend, bis man dies im Griff hatte. Nachdem unsere Server wieder errechbar waren, kommunizierten wir dies auch artig:

Wir haben nun unsererseits Maßnahmen ergriffen und heute den sogenannten “Secondary Nameserver” aller unserer Domänen zu uns umgezogen. Das hat nun zur Folge, daß wir zwar die leistungsfähige Infrastruktur von Schlund/InternetX und die einfache Verwaltung für unsere Domänen verwenden, bei einem Ausfall des Nameserver sollten die zugreifenden Rechner aber den Weg zum alternativen Namensserver finden, der bei uns im Rechenzentrum steht. Wir werden bei der nächsten DDOS Attacke auf Schlund/InternetX sehen, ob das so klappt, wie ich mir das vorstelle.

Warum drücke ich mich so vorsichtig aus? Nun eigentlich ist definiert, daß sich ein Rechner immer den Weg zum Secondary Nameserver sucht, wenn der Primary Nameserver nicht verfügbar ist. So richtig nicht verfügbar sind die Nameserver aber auch nicht, wenn ein Angriff stattfindet, sie reagieren nur furchtbar langsam auf die Anfragen, weil sie so viele haben. Das kann man überprüfen, indem man im Browser immer wieder F5 drückte während der Störung – irgendwann hat es dann auch mal geklappt mit der Namensabfrage. Dadurch, daß die Nameserver “ein wenig” funktioniert haben, ist nicht wirklich sichergestellt, daß die Clients sich in so einem Störungsfall wirklich den Weg zu unserm Secondary Nameserver suchen.

Natürlich läßt sich auch der Fall konstruieren, daß ein DDOS Angriff gegen InternetX/Schlund und gegen unseren Nameserver gleichzeitig stattfindet, dann nützt das natürlich alles nichts. Hoffen wir einfach mal das beste.

Die obigen Ausführungen sind übrigens der Grund, warum wir zwar eine Verfügbarkeitsgarantie für die von uns gehosteten Server anbieten, nicht jedoch eine Garantie für den Zugriff über das Internet.

Für die Techniker unter den Lesern: Wir haben auch die Möglichkeit in Erwägung gezogen, den Primary DNS bei uns zu hosten und den Schlund Server als Secondary zu benutzen – da ist uns der Umstellungsaufwand im Augenblick aber zu groß und der Nutzen nicht direkt erkennbar. Auch könnten wir beide Nameserver bei uns hosten – aber auch hier ist Aufwand und ehrlich gesagt: Der Ausfall gestern war “nur” 8 Stunden…

So ein Hüttenausflug ist ja eine Rückkehr zur Natur, zum einfachen, zum ursprünglichen. Heizen mit dem Holzofen, rundrum nur freie Natur – so soll es sein.

Wenn Christian dabei ist, muß aber ein minimaler technischer Standard eingehalten werden… So ist ein Highspeed Internet Anschluß mit WLAN in der Hütte obligatorisch (realisiert mit UMTS/HSDPA im A1 Netzwerk und verteilt über unseren Linksys UMTS Router):

Auch die Sammlung von iPhones, Handies, Laptops und Netbooks wird in der Hütte zwar auf das allernötigste reduziert, aber das füllt immer noch eine Tischplatte:

Schließlich müssen wir ja zeitnah von unserer Pilotreise “Hüttentraum” im Blog und auf Twitter berichten und unsere Verpflichtungen für Rufbereitschaften für unsere Consultingkunden erfüllen.

Selbstverständlich steht auf unserer Hütte unseren Gästen auch ein Netbook fürs Internet zu Verfügung, bzw. kann bei Bedarf auch der eigene Laptop in unser WLAN eingebucht werden.

Vor kurzem habe ich ja den VM Explorer für das Backup von Virtuellen Maschinen auf ESXi Hosts empfohlen, nun bin ich einmal mehr entzückt, denn es geht noch besser. Mit der neuen Version 1.6.008, die heute erschienen ist, wird die Sicherung von VMs um den Faktor 2-4 beschleunigt. Ich habe die Betaversion schon einige Wochen im Einsatz und die Änderungen sind dramatisch:

• Backup zweier VMs vorher 150 Minuten, jetzt 55 Minuten
• Weitere zwei VMs vorher 48 Minuten, jetzt 21 Minuten

Ich habe natürlich auch den Restore gestestet und eine der Maschinen, die ich gesichert habe, zurückgespeichert, unter neuem Namen registriert, in ein anderes Netzwerk gehängt und hochgefahren. Läuft einwandfrei.

Das einzige, was ein wenig unbequem ist, ist daß man auf dem ESXi nun SSH einschalten muß, und nach dieser Änderung leider den ESXi neu starten muß. In der Hilfe des VM Explorer ist genau beschrieben, wie das geht:

Das läßt sich aber sicher nicht umgehen und in Zukunft weiß ich es von vorneherein, wenn ich einen ESXi einrichte, daß ich sofort SSH einschalte, denn der Geschwindigkeitsunterschied beim Sichern ist das wert.

Der Linksys WRT543G UMTS Router hat einige Optionen, die es, zumindest laut Handbuch, ermöglichen, Fehler in der UMTS Verbindung zu erkennen und diese dann automatisch wiederaufzubauen. Aus meiner Erfahrung mit nunmehr 3 dieser Router bewirken diese Optionen aber, aus ungeklärter Ursache, im Laufe der Zeit genau das Gegenteil.

Man kann hier eine Option setzten “Link Check”, da wird, soweit ich verstanden habe, das UMTS Link überprüft und man kann 2 Server im Internet anPINGen lassen. Ist das erfolglos, dann soll, wie hier eingestellt, nach 5 Fehlerversuchen die Verbindung neu aufgebaut werden und nach 10 Minuten mit Fehlerversuchen soll der Router rebooted werden.

Diese Settings führen bei meinen Routern aber über kurz oder lang dazu, daß die UMTS Verbindung, kein “Mobile Network Bearer” und kein “Network Name” mehr verfügbar ist und der Router, ohne, daß man ihn aus- und einschaltet, keine UMTS Verbindung mehr aufbaut.

Schaltet man all die automatische Linküberwachung hingegen aus, dann bleibt die Verbindung des Routers einwandfrei, auch über längere Zeiträume (beste Zeit bisher: 6 Montate) bestehen:

Wenn man nur wenige WYSE XPe Clients im Einsatz hat und den Aufwand gescheut hat, den WYSE Device Manager zu installieren, so kann man dennoch mit recht wenig Aufwand einen WYSE XPe Client auf die Werkseinstellungen zurücksetzen.

Dazu kann man sich auf der WYSE Downloadseite z.B. für den V90L Client das aktuelle Firmware Image herunterladen und ganz am Ende der Seite den “Wyse Simple Imager” und das dazugehörige Handbuch im PDF Format. Letzteres ist unbedingt zu empfehlen, weil man durch reinen Augenschein nicht zurecht kommen wird.

Üblicherweise hat man einen Windows 2003 oder 2008 Server im Netzwerk und einen DHCP Server hat man auch, so daß die Benutzung des WYSE Simple Imager kein Hexenwerk sein wird. Dieser installiert auf dem Windows Server einen TFTP Server und sich selbst und steuert den TFTP Server fern. Genaue Anweisungen gibt es, wie gesagt, im Handbuch.

Ich möchte nur folgendes empfehlen, das steht zwar im Handbuch, aber wir IT Leute meinen ja immer, daß wir alles besser wissen

• Im Handbuch steht, daß der verwendete Server nur ein Netzwerkinterface haben darf. Das heißt genau: Bei der Installation des WYSE Simple Imager müssen alle Netzwerkinterfaces, die nicht an dem Netzwerk angeschlossen, sind, an welchem später der zu ladende Client angehängt wird, disabled sein. Ansonsten möchte der Client beim Booten garantiert das falsche Interface ansprechen und das läßt sich im Nachhinein im WYSE Simple Imager nicht mehr umstellen, sondern nur so: Deinstallieren, Server rebooten, falsches Interface disablen, Installieren.
• Während der WYSE Simple Imager aktiv ist, schlagen Boot Requests per DHCP fehl. In kleinen Netzwerken ist das nicht schlimm, in größeren Netzwerken oder wenn man länger braucht, weil man mehrere Clients neu laden möchte, sollte man die WYSE Clients und den Server in ein extra Segment bringen. Und: WYSE Simple Imager nach Gebrauch beenden.

Wenn man das alles beachtet, dann funktioniert das so: Der WYSE Imager wird gestartet, das heruntergeladene Boot Image wird eingefügt, dann wird der zu ladende Client gestartet, der booted aus dem TFTP heraus, lädt das Boot Image, restarted, führt ein paar Scripten aus und fertig. Nach 10 Minuten ist er wieder frisch. Prima.

Für das Backup unserer VMs auf dem ESXi Host habe ich ein Produkt gefunden, daß perfekt für ein einfaches und gutes Backup geeignet ist: VM Explorer vom Schweizer Hersteller Trilead. VMExplorer verbindet sich, einmal auf einer Windows Station installiert, mit dem oder den ESX Servern und bietet für jeden Server die Möglichkeit, ein Backup durchzuführen. Dabei wird dann von der VM ein Snapshot erstellt und dieser Snapshot auf den Backup Speicherplatz übertragen, dieser ist in unserem Fall eine 2 TB Festplatte, die an der Windows Station angeschlossen ist.

In der Free Edition war’s das auch schon, man braucht dann die Pro Edition, damit man einen Backup Scheduler aktivieren kann. In diesem legt man dann die Backups nach eigenem Gusto und gewünschter Häufigkeit an. In unserem Falle wird die externe 2 TB USB Festplatte jeden Freitag ausgetauscht und so sind die Backup Jobs darauf ausgerichtet, den Exchange, den SQL Server und die Kundensysteme täglich zu sichern und die restlichen VMs im Laufe der Woche jeweils einmal:

Einmal am Tag schickt VM Explorer dann ein E-Mail mit der Nachricht, ob alle Backups gut verlaufen sind:

Die Sicherungen selbst werden standardmäßig in Verzeichnissen abgelegt, die mit dem Namen der VM und Datum und Uhrzeit der Sicherung gekennzeichnet sind. Hier sind die normalen Dateien der VM abgelegt, diese können dann mit VMExplorer auf den ESXi Host zurückgesichert werden, auch unter anderem Namen, so daß die laufende Instanz nicht beeinträchtigt wird.

Es ist auch möglich, aus dem Sicherungsverzeichnis heraus eine VM mit vCenter Converter ins VMWare Workstation Format zu konvertieren – für Notfälle beim Totalausfall des ESXi sicher eine mögliche Option.

Insgesamt macht das Produkt einen runden Eindruck und ist die Lizenzkosten von 490 EUR absolut wert, wenn man regelmäßige Backups anfertigen möchte. Für Einmalbackups oder gelegentliche Backups von Hand genügt die Free Edition, die es glücklicherweise auch gibt.

Ich habe natürlich auch einige Restore Tests gemacht und dabei festgestellt, daß ich die Option “Compress Disk Files” im Tab “Connection” keinesfalls aktivieren darf, da sonst mein ESXi bei der Rücksicherung abbricht. Die Option ist allerdings standardmäßig beim Einrichten eines Backups auch nicht aktiviert.

Wenn man die Handbücher von McAfee studiert, um genaueres herauszufinden, wie man die Einstellungen für Client Tasks im ePolicy Orchestrator optimal setzt, dann wird man nicht wirklich fündig – ich fand in den Handbüchern zum ePolicy Orchestrator nur Hinweise, wie “Make the desired settings” oder “Change as required”.

Aber, was will ich denn eigentlich:

• Der Agent von McAfee soll installiert werden
• VirusScan soll installiert werden
• Aktualisierungen der Virensignaturen sollen möglichst schnell auf die Clients kommen

So kann ich das aber nicht anklicken, daher habe meine Fragen an McAfee adressiert und eine wirklich unglaublich klare und deutliche Antwort von Ravindra Sharma aus dem Support (Thank you for the Clear and precise Answer) erhalten:

1. Die Option “Run at every policy enforcement” meint, daß immer dann, wenn der Agent sich neue Policies zieht, weil diese geändert wurden oder wenn man “Wake Up Agents” durchführt und dort “Force complete policy and task update” markiert, der Task ebenfalls startet.
2. Ein Deployment Task jeglicher Art hat immer ein Detection Script vorweg, welches prüft, ob die Software / die Dateien, die ausgerollt werden sollen, schon drauf sind. Man braucht also keine Sorge haben, daß ein Virus Scan Setup mehrfach ausgeführt wird.
3. “Run Immediately” bedeutet, daß der Task läuft, sobald der Agent von diesem Task erfährt. Das bedeutet für einen Deployment Task für Virus Scan, daß der Agent diesen durchführt, sobald er selbst installiert wurde (wie auch immer) und zum ersten Mal Kontakt zum ePolicy Server aufnimmt.
4. Die DAT Dateien werden einmal täglich von McAfee aktualisiert, es genügt also, diese auf den Clients auch einmal täglich zu aktualisieren, man sollte sich eine Zeit aussuchen, wo die Clients idle sind, weil das Systemressourcen braucht.

Damit ist es dann schon einfacher, meine eigenen “Recommended Settings” zusammenzustellen:

• Ein Deployment Task für die Aktualisierungen des Agent und Virus Scan (man kann mehrere Software in einen Task eintragen mit dem Pluszeichen rechts). Dieser soll “Run at every policy enforcement” und im nächsten Bild “Run Immediately”.
• Ein Task für Update Signatures, der die Engine und die DAT aktualisiert für die in meinem Netzwerk installierten Produkte, der Läuft “Daily”, ist für 30 Minuten randomized und läuft um 12:30 Uhr PM. So sollten alle Clients im Netzwerk zwischen 12:30 und 13:00 Uhr die aktuellen DAT Dateien ziehen, während wir in der Mittagspause sind. Ein Bild zeigt mehr:

• Den Task für die Rogue System Detection setze ich wieder auf “Run at every policy enfocement” und “Run Immediately”.

So sind meine Anforderungen von oben perfekt umgesetzt und die Clients werden rasch mit Software und im Rahmen der Möglichkeiten mit Updates versorgt.

Es gibt Situationen mit Kunden, die mich tatsächlich überraschen. Heute rief ein Kunde an, er hat ein Netzwerk mit 30 Arbeitsplätzen. Ich war zum letzten Mal vor 4 Jahren dort, das war die letzte Reorganisation des Netzes mit neuer Serverhardware und Aktualisierung aller Software und ich habe seit gut 2 Jahren nichts mehr von dort gehört und wähnte den Kunden bereits in den Händen eines anderen Betreuers.

“Guten Tag Herr Pohle, wir müßten mal wieder unser Netzwerk modernisieren, aktuelle Versionen, vielleicht was Virtualisieren, na, Sie wissen ja, was man heute so macht” – “Gerne, schön, daß Sie an mich denken, Sie haben Glück, ich bin nächste Woche bei Ihnen in der Gegend, da komme ich mal zur Istaufnahme vorbei” – Pause – “Wieso Istaufnahme? Sehen Sie einfach in Ihre Dokumentation, Sie wissen doch, was bei uns installiert ist”

Wenn im HP Insight Manager für DL360 und DL380 Server der “Integrated Lights Out” Port degraded gemeldet wird, weil kein Kabel angeschlossen ist und weil man ihn eigentlich auch garnicht benutzt, dann schaltet man die Überwachung des Ports am besten im Control Panel – HP Management Agenst ab. Dort ist der “Remote Insight Information” zu markieren und mit einem Klick auf “Remove” aus der Überwachung zu entfernen:

Dann ist der Gesamtstatus des Systems (hoffentlich) grün:

In einem lokalen Netzwerk ist es zur Fernsteuerung von Windows-PCs und Windows Servern nicht notwendig, extra ein Remote Control Programm zu installieren. Man kann mit OpenSource Programmen bei Bedarf die benötigten Komponenten auf dem Rechner, der fernzusteuern ist, installieren und starten, dann die Fernsteuerung durchführen und anschließend automatisch die Komponenten wieder deinstallieren, so daß auf dem ferngesteuerten Rechner nichts zurückbleibt.

Die Fernsteuerung an sich läuft mit TightVNC, das ist dasjenige VNC, das über RAS Verbindungen in meiner Erfahrung am besten funktioniert. Das übertragene Passwort geht als Hash über die Leitung, die Fernsteuerungssitzung an sich ist aber nicht verschlüsselt, so daß sich dieses VNC nicht für reine Verbindungen übers Internet eignet. Hier geht’s aber um das Fernsteuern im LAN und da setzen wir die Abhörsicherheit einfach mal voraus.

Zum Aufruf benutzt man nun den “System Tools Remote Control Manager“. Dieser kopiert die VNC Dateien auf den Client Rechner, konfiguriert die Registry, startet den Service und startet dann den Viewer. Das alles wird über eine einfache Textdatei konfiguriert:

Zunächst lädt man STRCM herunter und führt die enthaltene SETUP.EXE aus. Im Programmverzeichnis findet man dann die folgenden Dateien:

Als nächstes lädt man sich das aktuelle TightVNC herunter und installiert es ebenfalls. Man erhält folgendes Installationsverzeichnis:

Aus diesem Verzeichnis habe ich die Dateien VNCHooks.dll, vncviewer.exe und WinVNC.exe genommen und in mein Verzeichnis G:\MOBILE\PSAG\RC kopiert, das auf allen meinen Adminrechnern verfügbar ist.

Aus dem STRCM Verzeichnis habe ich die Dateien strcm.exe und vnctight.rcm genommen und auch dort hineinkopiert:

Das Passwort welches in der Config Datei codiert ist, erhält man, indem man im installierten VNC auf dem Rechner ein Kennwort vergibt:

und den gewonnenen Hash dann aus der Registry auslist:

Zu guter Letzt habe ich noch einen Shortcut angelegt auf die Kommandozeile

G:\MOBILE\PSAG\RC\strcm.exe /rcm=G:\Mobile\PSAG\RC\vnctight.rcm

damit die Fernsteuerung einfach zu starten ist. Ruft man nun diesen Shortcut auf, erhält man den Dialog, in den man den Namen des fernzusteuernden Hosts eingibt:

Nach einer Sicherheitsabfrage, wo man zum Beispiel noch ein anderes Kennwort eingeben könnte:

wird TightVNC auf dem fernen Rechner installiert und gestartet:

und es erscheint die Passwort Abfrage vom Viewer:

Nach erfolgter Fernsteuerung, wenn der Viewer geschlossen wird, werden die Dateien wieder vom Zielsystem gelöscht:

So bleibt auf den Rechnern kein Port offen, es muß kein Programm auf allen Rechnern gepflegt oder aktualisiert werden und man kann trotzdem jederzeit zugreifen. Einzige Voraussetzung, daher empfehle ich das nur für’s LAN: Man hat einen Administrativen Zugriff über einen Netzwerkshare auf den Rechner, einfach gesprochen: Sie müssen den Share Admin$ auf dem Zielrechner erreichen können und dort reinschreiben dürfen.

Diese Programme müssen auf jeden Windows Rechner, PC und Server:

• SysInternals Suite
  • von Microsoft herunterladen
  • ZIP Datei nach “C:\Program Files\SysinternalsSuite” auspacken
  • “C:\Program Files\SysinternalsSuite” in den Pfad aufnehmen

• Showman
  • Download von David Taylor
  • ZIP Datei nach “C:\Program Files\SHOWMAN” auspacken
  • Shoman.exe aufrufen
  • Nach dem ersten Aufruf findet sich ein Menüitem “Usage Pie Chart” im Explorer an jedem Laufwerk/Verzeichnis
• Die notwendigen Sicherheitseinstellungen sind hier beschrieben.