IThome

Der Server verbindet sich via DSL mit dem Internet ? Poste bitte auch mal die Ausgabe von IPCONFIG /ALL ...

Tja, das ist die Frage, ob das auch für die RAS-Verbindungen gilt. Mit XP-Home funktioniert sowas, Domänenbeitritt dagegen natürlich auch nicht. Auf Ressourcen zugreifen kann man ja (Netzwerkanmeldung - Typ 9), entscheidend sind dabei die Benutzerdaten. Irgendwas muss der Client ja an den Server übermitteln und wenn das falsch ist, meldet sich der Server. Wenn die Media Center Edition das unterdrückt und laut FAQ auch keine gespeicherte Benutzerdaten verfügbar sind (CONTROL USERPASSWORDS2 gibt es nicht bzw. dort kann man keine Kennwörter verwalten ?), dann ist es kein Wunder, dass der Server sperrt. Wenn das mit den RAS-Verbindungen auch nicht funktioniert, tja, dann ist das eine ungeeignete Version (habe ich ehrlich gesagt in einem gewerblichen Umfeld auch nochz nicht gesehen). edit: so, hab ne Media Center Edition gefunden und probiere das gleich mal aus ...

Kein Problem, Entschuldigung angenommen ... :) Das war nur ein Test zur Sicherheit (ich habe sowas vor längerer Zeit das letzte Mal gemacht), dieses Szenario ist so im Einsatz und funktioniert. Denn genau dafür ist es gedacht. Wenn Du also mit CONTROL USERPASSWORDS2 oder wie Ducke es vorgeschlagen hat etwaige gespeicherte Kennwörter, mit dem der Client automatisch versucht, den Server anzusprechen, löschst und Dich dann mit Domänenkonten verbindest UND auch mit diesen Credentials auf Ressourcen zugreifst (Anmeldedomäne einbeziehen), dann ist das Problem erledigt. Du kannst natürlich auch nur gespeicherte Kennwörter löschen, worauf Dich dann der Server nach den Benutzerdaten fragen sollte (Du meldest Dich am RRAS also ohne Anmeldedomäne an). Die kannst Du dann speichern, wirst aber wahrscheinlich beim nächsten Kennwortwechsel die gleichen Probleme bekommen. Meiner Meinung nach ist die Lösung mit dem Einbeziehen der Anmeldedomäne die beste, da immer mit den richtigen Benutzerdaten der Domäne gearbeitet wird ... Ich denke, dass es am wahrscheinlichsten ist, dass im Moment Kennwörter gespeichert sind, mit denen im Hintergrund zugegriffen wird. Normalerweise greift der Client mit den angemeldeten Benutzerdaten auf Ressourcen zu. Sind diese Daten dem Server nicht bekannt, kommt eine Nachfrage (ich gehe mal davon aus, dass der Gast dort nicht aktiviert ist). Speichert man Benutzerdaten für eine Netzwerkressource ab, verbindet man sich mit diesen gespeicherten Zugangsdaten, falsch oder nicht. Verbindet man sich via VPN, öffnen einem die dort angegebenen Benutzerdaten quasi nur die Tür zum entfernten Netz. Mit diesen RAS-Zugangsdaten greift man nicht auf Ressourcen zu. Das macht man entweder mit den Daten des lokal angemeldeten Benutzers oder mit gespeicherten Daten. Wird aber die Anmeldedomäne mit einbezogen, greift man auf die Ressourcen mit diesen Benutzerdaten zu, sie öffnen also nicht nur das Tor (RAS oder VPN).

Wenn der Drucker in die Sitzung gemapped werden soll, dann muss der Treiber auf dem RDP-Client und dem RDP-Server installiert sein ...

Hast Du die Rechner, die den SBS als DNS-Server eingetragen haben, in eine Arbeitsgruppe gebracht und danach wieder der Domäne zugefügt ? Hast Du mit NETDIAG die DNS-Konfiguration auf dem neu installierten SBS geprüft (mach das mal als erstes) ? edit: zu spät :D

Deswegen sollst Du die Clients ja auch in eine Arbeitsgruppe bringen und danach wieder der Domäne zufügen (oder hast Du das schon gemacht ?) ...

Ist der Treiber dieses Druckers auf dem RDP-Rechner installiert ? Du verbindest Dich nicht via VPN, sondern via Portweiterleitung direkt via RDP ?

Die Meldung von NSLOOKUP kommt sehr wahrscheinlich daher, dass keine Reverse Lookup Zone existiert oder kein PTR für den Server in einer vorhandenen Reverse Zone vorhanden ist. Das ist das Verhalten von NSLOOKUP und ist für einen Domänenbetrieb nicht relevant. Lade Dir mal die Supporttools SP1 herunter und teste mit NETDIAG, ob DNS technisch alles okay ist. Windows Server 2003 Service Pack 1 Support Tools Zum Zufügen zur Domäne müssen die Clients die Adresse des SBS als bevorzugten DNS-Server eingetragen haben und Du solltest auch den Domänennamen vollständig beim Joinen angeben (also DOMAIN.LOCAL anstatt DOMAIN), dann weisst Du auch gleich, ob DNS läuft ...

Nein, leider nicht ... Ich kenne nur den IPod und damit geht das nicht ... :D

Egal, wie schon gesagt, der MCP macht das schon ...

Den virtuellen Adapter siehst Du aber auch erst, wenn das erste Mal eine Verbindung hergestellt wurde, die den Adapter benutzt (Preferred oder Required). Ob Required oder nicht kannst Du in der Konfiguration der Watchguard einstellen (dann sind die WGX-Dateien so konfiguriert) ...

Setze mal den ID-Type auf ANY und rechts daneben den Dyndns-Namen (im Client, die Gatewayeinstellung) ...

Aha, ja, das hast Du geschrieben ... Und woher hast Du das ? Sicher nicht aus der Hilfe , denn dort steht es nicht ... Und warum machst Du jetzt den falschen Teil schwarz und gross und lässt den dahinter liegenden, richtigen Teil klein ? So steht es übrigens auch in der von Dir geposteten VPN-Beschreibung von Microsoft und nix von Daten, die der Server überträgt, aber egal ... Ich weiss im Grunde gar nicht mehr, was Du eigentlich willst. Es ist getestet, es funktioniert, Du glaubst es trotzdem nicht . Du hast mehrere Ansätze, vielleicht sind die ja auch nicht richtig. Aber Du machst das schon ...

Ja, sie werden vom Benutzer angefordert und nicht vom Server ... :D Wie kommst Du bloss darauf, dass etwas vom Server angefordert wird ??? Aber nochmal, das setzt auch eine Domäne auf der Gegenseite voraus ... edit: noch was, mit CONTROL USERPASSWORDS2 kannste die gespeicherten Kennwörter prüfen und auch entfernen (falls hier das Problem liegt).

Wäre ja denkbar, dass bei den anderen Clients die Credentials synchron sind ... oder es sind die richtigen Credentials gespeichert ... oder der HAken ist gesetzt und es sind korrekte Domänendaten angegeben worden ... Ich denke schon, dass das auch mit der Media Center Edition finktioniert , mit der Home kann man das ja auch machen (sofern das in der Firma wirklich eine Domäne ist) ...

Dieser Haken weist den Server gar nichts an, ebenso wenig überträgt der Server irgendwas . Der Haken bedeutet, dass Domänendaten angegeben werden beim Zugriff. Diese Daten werden sowohl für die RAS-Authentifizierung als auch für den Ressourcenzugriff benutzt. Wie der Name schon sagt, funktioniert sowas nur in einer Domäne. Wenn der Client schon Mitglied der Domäne ist, kann man sich das auch sparen, da er sich mit Cached Credentials der Domäne anmeldet und somit bekannt ist. Das ist bei Deinem Arbeitsgruppenrechner eben nicht so (oder da ist irgendwas gespeichert, was nicht passt) ... Naja, gerade getestet ... XP in einer Arbeitsgruppe , dessen Benutzerdaten existieren nicht auf dem Server. VPN-Verbindung zum Server erstellt, besagten Haken gesetzt, Benutzerdaten der Domäne und Domäne eingetragen und verbunden. Danach die Verbindung zum Server , freigegebenen Ordner geöffnet. Auf dem Server FSMGMT.MSC aufgerufen, VPN-User ist verbunden, nicht der lokal angemeldete (und das ohne irgendwelche Abfragen) ...

Hm, Windows lebt, das erlebt man immer wieder ... :D

Dann schildere das Problem gleich richtig und zwar so, dass man es verstehen kann. Wenn überhaupt einer nach Authentifizierungsdaten bei Zugriff fragt, dann ist das der Server und nicht der Client. Das macht er immer dann, wenn die gelieferten Daten nicht mit Daten auf dem Server übereinstimmen. Gulps Lösung behebt dieses Problem, da die Benutzerdaten mit denen auf dem Server übereinstimmen und somit nicht gefragt wird. Eine andere Möglichkeit ist eben nicht die lokalen Daten, sondern die DFÜ-Benutzerdaten zu benutzen. Das was Du schreibst ist Schmarrn oder Du weisst nicht, welchen Haken Du setzen sollst (nicht den bei der interaktiven Anmeldung) ... edit: Nochmal getestet, funktioniert (Domäne) ... @Ducke Ja, das wäre natürlich auch denkbar. Allerdings hat der TO geschrieben, dass die Daten nicht gleich sind ...

Das hört sich alles ziemlich quer an, so dass ich wohl als erstes den Stack und Winsock zurücksetzen würde ... NETSH INT IP RESET C:\RESETLOG.TXT NETSH WINSOCK RESET CATALOG eventuell noch Download WinSockFix 1.1.0.13 - WinSockFix - A free Winsock/Tcp repair utility - Softpedia

Du hast Dir nicht die Mühe gemacht, etwas über den Browserdienst zu lernen (die Artikel sollten reichen) um das Problem in den Griff zu bekommen ?

Aaaaaah, jetzt habe ich´s . Wenn Du den Windows VPN-Client benutzt, dann setze den Haken "Windows-Anmeldedomäne einbeziehen". Es werden dann die Benutzerdaten der VPN-Verbindung benutzt und nicht die Daten der Windowsanmeldung ...

Du hast jetzt was gemacht ? Du hast den Sniffer gestartet, die Schnittstelle 192.168.x.x ausgewählt und dann den Mitschnitt gestartet. Dann hast Du auf Daten des Servers zugegriffen und diese Pakete wurden aufgezeichnet ? Vielleicht hängst Du mal einen kleinen Mitschnitt an. Du benutzt intern öffentliche IPs ... 100.x.x.x, 200.x.x.x ...

Öhm, was genau willst Du denn jetzt ? Wenn die Credentials auf dem Server nicht vorhanden sind, muss er Credentials angeben. Wenn sie passen, kann er sich authentifizieren und zugreifen. Das ist auch das normale Verhalten. Warum soll der Benutzer sich zwangsweise anmelden ? Dann gibt er doch dieselben Daten an, mit denen er dann zuzugreifen versucht ...

Mache ich in der Regel auch, allerdings nicht immer. Genausowenig halte ich mich immer an die Gruppenstrategien, die von Microsoft vorgeschlagen werden. Flexibel hin oder her, es passt weiss Gott nicht immer und verursacht mitunter mehr Arbeit und Verwaltung, als das es etwas nützt. Ist ja aber zum Glück alles nur ein Kann und kein Muss :)

Wie sind denn die Berechtigungen in der Root ? edit: eventuell auch ein korruptes Dateisystem (CHKDSK C: /F) ?