IThome

Entferne mal die Registryeinträge (ausser Default) unter ... HKLM - Software - Microsoft - SQMClient - Windows - DisabledSessions Natürlich vorher Registry sichern ...

Im Internetinformationsdienste-Manager (owa) ist festgelegt, dass SSL benutzt werden muss ...

Du kannst in der VPN-Verbindung des Clients den Haken "Standard-Gateway für das Remotenetzwerk verwenden" entfernen (Split-Tunneling) ...

Gar nichts, denn es werden ohne weiteres keine Browserlisten über Router weitergegeben. Die Netzwerkumgebung hat auch mit DNS nichts zu tun, sie ist eine NetBIOS-Anwendung. Da Broadcasts im VPN nicht weitergeleitet werden, bekommst Du die aktuelle Browsingliste nicht. Eine Möglichkeit wäre einen WINS-Server einzusetzen. Ich muss allerdings dazu sagen, dass die Netzwerkumgebung ein Relikt aus älteren Tagen ist ... geschwätzig, ungenau und langsam. Ich verzichte schon längere Zeit darauf ... Description of the Microsoft Computer Browser Service

Möglicherweise den Bitmap-Cache des Clients ?

Der Name des Profilordners ändert sich nicht durch Umbenennung des Benutzers ...

Was hast Du nicht gefunden, das exportieren von virtuellen Maschinen ? http://www.petri.co.il/importing-and-exporting-your-virtual-machines.htm

Merkwürdige Ausgabe von Netdiag. Poste bitte IPCONFIG /ALL (vollständig) eines Clients und des Servers. Wie heissen die DNS-Zonen des DNS-Servers der Domäne ? Wer ist 213.129.232.1 und 213.129.226.2 und welche Zonen hosten diese beiden ?

Schildere bitte, wie Deine OU-Struktur aussieht und wo Du welche Richtlinie mit welchen Einstellungen gelinkt hast. Wir benötigen nicht jede OU/Richtlinie, nur die relevanten (die zugrundeliegende Struktur ist natürlich auch wichtig). Wo z.B. überall Loopback eingeschaltet wird, wo Benutzereinstellungen gesetzt sind, welche Richtlinie eine höhere Priorität hat (falls mehrere gelinkt sind) ... Edit: Für die Übernahme einer Richtlinie gilt "Gruppenrichtlinie übernehmen", dort sollten es nicht die "Authentifizierten Benutzer" sein ...

Auf der Gegenseite ist RRAS und IAS eingerichtet ?! Der RRAS dort ist so konfiguriert, dass er den dortigen DHCP zur Adressvergabe benutzt ?!

Dafür muss man aber erst die RSAT installieren ... ;)

Kommt darauf, was Du für Betriebssysteme hast. Bei Vista und höher klappt das mit einer Gruppenrichtlinie, bei XP ab SP1 mit Regkeys (mit Group Policy Preferences oder REG.EXE per Startscript oder ADM-Template z.B.) ... Update to disable Volume Shadow Copy Service restore options on Terminal Server client computers that are running Windows Server 2003 or Windows XP http://www.gruppenrichtlinien.de/adm/tsvss.txt

Mit GPEDIT kannst Du keine Domänenrichtlinien verwalten. Welche Version von Windows 7 hast Du und welche Version von RSAT hast Du geladen ?

Eigentlich setzt der Client die Berechtigungen des Profils (auch die für die Administratoren), wenn er es das erste Mal zurückschreibt und damit die Ordnerstruktur erstellt ...

RSAT installiert und dann die Gruppenrichtlinienverwaltungskonsole installiert und aufgerufen ? Was hast Du auf dem Client denn aufgerufen ?

Die Gruppenrichtlinienverwaltungskonsole des Windows 7 Clients benutzen und von dort die Gruppenrichtlinien einrichten ...

Naja, falsch ... Es ist jedenfalls kein Standard und würde alles erklären. Diese Richtlinie ist normalerweise nur auf der Domain Controllers OU verlinkt und hat deswegen schärfere Sicherheitseinstellungen ...

Hast Du auf einem Client mal RSOP.MSC ausgeführt und dann die relevanten Einträge in den Benutzerrechten überprüft ? Dort kannst Du auch sehen, von welcher AD-Richtlinie eine Einstellung kommt. Wenn Benutzerrechtseinstellungen bezüglich der interaktiven Anmeldung tatsächlich aus der Domäne kommen, dann frage ich mich, aus welchem Grund das passiert ...

Ja, die kann man benutzen, muss man aber nicht. In einigen Fällen allerdings (wie oben beschrieben), muss man sie benutzen, da man sonst keine Verbindung herstellen kann. Diese Dateien werden auch nicht importiert (so wie beim IPSec-Client), sondern sie werden nur ausgeführt. In dem Teil, wo man sonst die Zieladresse oder den Zielnamen eingibt, steht dann ausgegraut "FILE". Diese Datei wird aus der Watchguard Konfiguration extrahiert, welche Du im System Manager finden kannst ...

Manchmal ist man eben jenseits von Gut und Böse ... :D

Du brauchst diesen Port aber trotzdem nicht, denn man kann fertig vorkonfigurierte Verbindungsdateien zum Client übermitteln (client.wgssl). Ich habe mal einen Fall gehabt, da wurde ebenfalls für die iPhones der Port TCP 443 nach innen geleitet. Der Port für SSL war auf TCP 4343 eingestellt. Bis zur Version 11.1 funktionierte das noch, da der Client die Konfigurationsabfrage auf dem Port TCP 4100 durchgeführt hat, welche ihm dann den TCP Port 4343 (in meinem Fall) zum Verbindungsaufbau mitgeteilt hat. Ab der Version 11.2 allerdings wurde die Konfigurationsabfrage an den Port TCP 443 geschickt, was durch die Umleitung wegen der iPhones natürlich in die Hose ging. Die Angabe des Ports im Client klappte ebenfalls nicht. Daher wurde also die Konfiguration der Watchguard entpackt und die "client.wgssl" an die Clients übermittelt. In dieser Datei steht schon der anzusprechende Port (hier TCP 4343) und der Client verbindet sich gleich, ohne die Konfiguration vorher abzufragen ... Ich weiss, das hilft Dir bei Deinem Problem rein gar nichts, aber im Moment gibt es offenbar keinerlei Abhilfe ... :(

Den Port brauchste nicht angeben, die Konfiguration wird beim Starten des Clients geladen (bei der 11.2 über den Port 443, nicht mehr 4100 wie vorher). Der Client kennt also weder den Aussteller des selbstsignierten Zertifikates der Box, noch die austellende CA des gekauften Zertifikates ?

Welche CA hat dieses Zertifikat ausgestellt (ist dem Client die Stamm-CA bekannt) ? Warum gibst Du 444 als Zielport an ? Welche Softwareversion ist auf (was für einer) Box installiert ?

Danke für die Rückmeldung ... :)

Wie verbindest Du Dich (welches Ziel gibst Du ein) und welche Fehlermeldung bekommst Du ? Auf welchen Namen ist das Zertifikat ausgestellt ?