Jump to content

Mike66

Members
  • Gesamte Inhalte

    6
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von Mike66

Apprentice

Apprentice (3/14)

  • Erste Antwort
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei
  • 1 Jahre dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Hallo, schon mal darüber nachgedacht, statt dessen einfach mehrere gleichzeitige RDP-Anmeldungen auf der Windows7-Maschine zu ermöglichen ? Entsprechende Patchanleitungen findet Google z.B. unter dem Suchbegriff: Concurrent Remote Desktop Sessions in Windows 7. Gruß Mike
  2. Hallo, ich habe folgendes Problem: Auf einem W2008R2 Foundation-Server bricht die Sicherung mit Bordmitteln ( kleiner Server und Datenbestand, keine professionelle Sicherungs-Software gewünscht ) auf einem Tandberg RDX ab. Das RDX-Drive wird offenbar fälschlich als DVD-Brenner erkannt ( obwohl die Tandberg-Treiber und Tools installiert sind ) und wbadmin verlangt die Eingabe einer Beschriftung der mutmaßlichen DVD. Nun habe ich aber keinen Kommadozeilenparameter für wbadmin gefunden, mit dem man eine Beschriftung übergeben bzw. die Abfrage überspringen kann ( -quiet führt nur zum Abbruch ). Der bisherige Aufruf lautet einfach: C:\WINDOWS\system32\Wbadmin start backup -backupTarget:E: -include:C:, F: -allCritical Wobei E: der Laufwerksbuchstabe des RDX-Drives ist. Ausserhalb eines Batch-Files auf der Kommandozeile ohne -quiet ausgeführt, führt dieser Aufruf zu besagter Abfrage der Beschriftung der vermeintlichen CD/DVD, die man einfach mit W für Weiter übergehen kann. Dann wird die Sicherung problemlos durchgeführt. Bei Abarbeitung mit dem Kommandoparameter -quite wartet die Sicherung ca. zwei Minuten auf eine Eingabe und bricht dann ab. Hat das jemand schon mal gehabt ? Ich erinnere mich an ein ähnliches Problem mit einem Iomega REV, weiss aber nicht mehr, wie es gelöst wurde. Nachtrag: Bei meinen Versuchen hierzu bin ich auf ein weiteres Problem gestoßen: Durch die Fehlinterpretation des RDX-Drives ( gilt übrigens auch für REV-Laufwerke ) als „removable drive“, durch die das RDX-Laufwerk wie eine DVD behandelt wird, wird nicht nur die störende Abfrage initiiert, sondern die Sicherung wird auch noch automatisch komprimiert. Dadurch können die entstehenden VHD-Files nicht mehr direkt gemounted werden und ein Zugriff auf einzelne Dateien ist nicht möglich: Man kann in Folge nur ganze Volumes wiederherstellen. Das ist natürlich für viele Rücksicherungsszenarien eine Katastrophe. Derzeit fällt mir nur dazu ein, für die Sicherung einen anderen Datenträger "zwischenzuschalten" und die Sicherung im Nachgang auf das RDX-Drive zu schreiben. Sehr unbefriedigend und schließt meiner Meinung nach derzeit die Verwendbarkeit von RDX- oder REV-Drives in solchen Szenarien praktisch aus.
  3. Hallo, was lange währt, wird endlich gut ... Hatte leider etliche andere Probleme, daher zog sich die Klärung dieser Frage etwas hin. Nachdem ich auch alle lokalen Routen kreuz und quer analysiert hatte und keinerlei Fehler finden konnte und die gleichen Routen bei andersgearteter Einwahl auch funktionierten, war ich fast am Ende meines Lateins. Nach aufwändigem systematischem Ausschluss aller anderen Fehlerquellen blieb logisch betrachtet nur ein Fehler bei den verwendeten Routern übrig, egal wie unwahrscheinlich mir dies erschien, zumal ich ja parallel drei verschiedene Low-Cost-Geräte getestet habe. Um es kurz zu machen: Nach ewiger Quengelei beim Support kam raus, dass es sich tatsächlich um ein Firmwareproblem hinsichtlich des IPSec-Passthrough handelt. Sobald der interne VPN-Server aktiviert wird, funktioniert das Passthrough nicht mehr !!! Mir völlig unverständlich und abwegig, aber Tatsache. Dlink hat es dann tatsächlich geschafft, eine Beta-Firmware zumindest für den DI-804HV zu basteln und siehe da: Es funktioniert !!! Für den DI-824 gibts meines Wissens nach aber noch immer kein Update. SMC hat das Problem bis heute nicht mal begriffen und hat wohl auch kein Interesse, den Fehler beizulegen, zumal der SMC Barricade mit integriertem VPN wohl nicht mehr vertrieben wird. Interessant, das sich dieses Problem völlig analog bei verschiedenen Herstellern findet. Greift man da etwa auf den gleichen Vorlieferanten zurück und verbaut den selben Mist mit oberflächlich angepasster Firmware nur in verschiedene Gehäuse ? Klingt für mich wahrscheinlich, zumal die Features der Geräte absolut identisch sind. Aber okay, Problem gelöst, Threat kann beendet werden. Gruß Mike66
  4. Hallo dippas, es gibt in dieser Umgebung keine LAN-Verbindung zu dem anderen Subnetz, eben nur via VPN-Tunnel. Ich arbeite in diesem Kontext mit einer statischen IP eben nicht aus dem fernen Subnetz, der Tunnel arbeitet ja zwischen Router und Kartenemulation. Auf Deinen Tip mit dem route add Kommando wäre ich von selbst auf einer Workstation gar nicht gekommen ( betriebsblind ), das probiere ich am Wochenende gleich mal aus. Ich poste dann das Ergebnis. Vielen Dank !!! Gruß Mike66
  5. Hallo XP-Fan, ich verstehe die Frage hinsichtlich Router -> Ausgang nicht ( wahrscheinlich bin ich zu **** ). Es handelt sich um einen einfachen DSL-Router zur Internetanbindung. Eingang lokales Netz, Ausgang zum DSL-Modem. Bei den Komponenten experimentiere ich derzeit mit low-cost Komponenten speziell nur zur Fernwartung kleinerer Netze, in diesem Falle mit DLINK DI-804 HV bzw. DI-824VUP+ und DLINK Clientsoftware DS-601 ( = NCP Secure Entry Client ), die Erfahrungen sind aber analog zu anderen günstigen Geräten wie SMC Barricade oder Netgear. Lancom ist mir für diesen Zweck zu teuer und zu aufwändig in der Konfiguration. Auf der Gegenseite findet sich auch ein DLINK DI-804HV als VPN-Server mit integrierter Firewall mit entsprechend geöffneten Ports als Tunnelendpunkt. Das läuft ja auch alles, auch in verschiedenen Konstellationen. Ich habe nur mit der beschriebenen Anordnung Probleme. Auf der Gegenseite ist ein W2003-Server als DHCP-Server konfiguriert und vergibt Adressen von .50 bis .100. Spielt aber eigentlich keine Rolle, da ich ja im entfernten Netz zwangsläufig mit einen anderen Subnetz arbeiten muss.
  6. Hallo, ich kann folgendes Problem mit meinem beschränkten Verständnis der Materie nicht lösen: Windows XP Pro SP2 Client an Server2003SP1 ( auch DNS-Server ), Internetzugang via Hardwarerouter als Gateway im gleichen Subnetz ( 192.168.101.x ) mit aktiviertem und funktionierendem VPN-Passthrough ( IPSEC ). Auf dem o.g. XP Pro Rechner ist eine VPN-Clientsoftware zur Fernwartung eines anderen, entfernten Servers ( mit Subnetz 192.168.100.x ) installiert. Interzugang dieses PCs erfolgt über den o.g. Router ( als Gateway in der Netzwerkkarte des PCs eingetragen ). Der VPN-Client emuliert eine weitere Netzkarte als Tunnelendpunkt ( anderer Endpunkt ist ein VPN-Router mit integr. VPN-Server ). Tunnelaufbau funktioniert problemlos. Ich kann nur nicht den entfernten Server vom lokalen PC anpingen. Trennt man den PC vom lokalen Netz und baut den Internetzugang testweise lokal auf ( z.B. über ISDN-Karte ), funktioniert alles. Möglicherweise liegt das Problem darin, dass der Ping über die lokale Netzkarte Richtung DNS-Server läuft und nicht über die Kartenemulation des VPN-Client. Von dort weiterzurouten brächte aber nichts, da der Tunnel schliesslich über den lokalen PC aufgebaut wird. Bei XP selbst kenne ich nur rudimentäres Routing über zwei Netzkarten via Registryeintrag und gegenseitigem Gatewayeintrag ( geht hier ja nicht wg. Internetgateway ). Bin ich wirklich in einer Sackgasse oder einfach nur betriebsblind bzw. verstehe ich die Problematik nicht ? Andere Lösungen als über den VPN-Client auf dem lokalen PC würde ich ungern wählen, da der effektive Kontext komplexer ist, als hier vereinfachend dargestellt und u.a. andere VPN-Lösungen im Netz laufen. Ergänzend bemerkt: Firewallprobleme o.ä. kann man aufgrund der Konfiguration ausschliessen. Ich wäre für jeden Tip oder Trick dankbar. Danke im voraus. Mike66
×
×
  • Neu erstellen...