IThome

Sehe ich auch so ... Das einzig machbare ist die Lösung mit NAT, entweder durch geeignete Router oder durch den SBS, der das Natting durchführt (dann mit 2 Karten, wobei sich die interne Adressierung des SBS verändern muss) ...

Drück Dich mal deutlicher aus ... Für wen sollen die Richtlinien gelten ? Wo hast Du den Gruppenrichtlinieneditor ausgeführt ? Welche Richtlinien z.B. hast Du aktiviert ? Warum benutzt Du GPEDIT.MSC, wenn Du Domänenrichtlinien anwenden willst ? Du kennst die Reihenfolge der Anwendung der Gruppenrichtlinien ?

Dieses Recht wird per Default NICHT über die "Sicherheitsrichtlinie für Domänencontroller" gesetzt. Wenn man das Recht via Domänenpolicy verändern will, dann sollte es nicht in einer Standardrichtlinie gemacht werden. Besser ist es, eine neue Richtlinie zu erzeugen, einzustellen und sie höher als die Standardrichtlinie zu schieben ...

Du musst die entsprechende Gruppe, die auf den Servern eine Remotedesktopverbindung herstellen soll, der LOKALEN Gruppe Remotedesktopbenutzer auf den entsprechenden Servern zufügen. Um es nicht zu Fuss machen zu müssen, kannst Du via Richtlinie und "Eingeschränkte Gruppen" konfigurieren ... Wenn es DCs sind, gehört diese Gruppe in BUILTIN\Remotedesktopbenutzer auf den DCs. Auf Mitgliedsservern musst Du das Benutzerrecht "Anmelden über Terminaldienste zulassen" nicht gewähren, da es per Default den Remotedesktopbenutzern schon gewährt wird. Auf einem DC wird dieses Recht nicht über eine Domänenrichtlinie gewährt, sondern über eine lokale Richtlinie (zu sehen mit GPEDIT.MSC) ...

Wie gesagt: mehr Informationen in einem neuen Thread ... Was ist eingestellt und wo ... :)

Per Default wird der Besitztum der Ordner der Serverprofilordner geprüft. Ist nicht entweder die Gruppe der Administratoren oder der Benutzer selbst Besitzer dieser Ordner, klappt der Zugriff nicht (auch nicht bei geeigneten NTFS-Berechtigungen). Dieses Verhalten kann man abschalten ...

Bedenke aber, dass der Besitz entweder wieder übertragen werden muss oder die Prüfung des Besitztums via Richtlinie abgeschaltet werden muss. Ansonsten können die Benutzer ihre Serverprofile nicht mehr laden (Du redest doch von Serverprofilen gell ?!) ...

Naja, zum Einrichten des VPN musst Du keinen Assistenten benutzen. Wähle "Benutzerdefinierte Konfiguration" und konfiguriere zu Fuss (so viel ist das ja nicht). Mit irgendwelchen virtuellen Adaptern, die nachher wieder deinstalliert werden ... naja ... interessanter Versuch :D

Man kann den RRAS auch als VPN-Server benutzen, wenn er nur eine Karte hat (es gibt nur keinen passenden Assistenten für dieses Szenario) ...

Schau mal in den letzten Artikel ... Zitat: "If NetBIOS over TCP/IP is enabled, Windows by default attempts to resolve host names using NetBIOS methods when standard methods fail." Standard Methods = Host-Namensauflösung , also erst u.a. DNS, dann NetBIOS-Methoden. WINS ist ein Teil der NetBIOS Namensauflösung und wird, je nach Knotentyp, an unterschiedlichen Stellen der NetBIOS Namensauflösungsreihenfolge durchgeführt. Hm, ich wüsste nicht, dass man es deaktivieren kann. Allerdings wird ohne eingetragenen DNS-Server auch keiner abgefragt, der Rest natürlich schon (Selbst, Cache/HOSTS) ...

Das ist falsch, Du kannst nur nicht den Assistenten bzw. musst die benutzerdefinierte Konfiguration benutzen und alles selbst konfigurieren ... Der Vorteil von RRAS ist die Möglichkeit, sehr fein und genau konfigurieren zu können ...

Wieso hat der Backupoperator standardmässig Lese- und Schreibberechtigung ? Er darf auch Dateien sichern/wiederherstellen, selbst wenn er keine Berechtigungen dazu hat, aber auch nur dann, wenn er es mit dem Backupprogramm macht, via Windows-Explorer nicht. C$ und D$ sind, wie der Name schon sagt, administrative Freigaben, die von Administratoren benutzt werden können. Aber im Grunde habe ich gar nicht verstanden, was Du eigentlich vor hast :D

Hat er Vorlagen im Netz und der Ort dieser Vorlagen hat sich verändert (der Ort der Vorlagen wird im Dokument selbst gespeichert, daher egal, ob lokal aufgerufen oder nicht) ? Sind nicht mehr existierende Netzwerkdrucker verbunden ?

Das Schaubild bezieht sich auf Systeme vor Windows 2000, bei denen die NetBIOS-Abfrage vor der DNS-Abfrage erfolgte ...

Doch, es wird auch gecached, allerdings nicht unbegrenzt (Dauer -1). Wenn Du auswärts bist und mit #PRE vorab diesen Eintrag in den Cache lädst (beim Systemstart), funktioniert es ja wie es soll. Wenn Du den Rechner dann allerdings herunter fährst und in der Firma startest, wird eben dieser dann falsche Eintrag auch in den Cache geladen. Der Cache wird in jedem Fall VOR der LMHOSTS abgefragt. Wenn Du ohne #PRE konfigurierst, wird nichts in den Cache geladen und zum Ende der Namensauflösungsreihenfolge erst die LMHOSTS abgefragt. Vorher kommt in jedem Fall noch eine Broadcastabfrage, die dann den richtigen Namen auflöst. Du solltest aber besser RRAS und DNS konfigurieren. Eine Reverse Lookup Zone (Auflösung FQDN zu IP) benötigst Du dafür aber nicht ...

Hm, ich denke, ich würde da eine Appliance bevorzugen, die mehrere Schnittstellen zur Verfügung stellt (Watchguard X-550e, X-750e oder so) ... Sind alle seine Systeme im öffentlichen Netz von aussen erreichbar ? Wie ist das mit dem zugenagelten Router realisiert worden ?

Wie gesagt, es kommt auf die Systeme an. Ab 2000 kommt DNS-Auflösung grundsätzlich vor NetBIOS-Namensauflösung, selbst wenn zusätzlich ein WINS definiert ist ... NetBIOS über TCP/IP-Namensauflösung und WINS Microsoft Corporation Chapter 7 - Host Name Resolution

Wenn Du #PRE setzt, wird es vorab in den NetBIOS-Namenscache geladen und bleibt dort auch. Also ohne #PRE und wenn diese Auflösung nicht mehr benötigt wird, nbtstat -R (grosses R) ausführen. Willst Du kein Quick ´n Dirty, dann konfiguriere RRAS auf dem Server und benutze DNS-Namensauflösung ... Poste aber trotzdem mal die Ausgabe von IPCONFIG /ALL des VPN-Servers und dem Client ...

Übermittle auch einen Verbindungssuffix oder benutze den FQDN (\\Name.Domaene.Local) in der Auflösung. Wenn Du das gemacht hast, setze testweise mal den Haken "Remotegateway ....", ich denke, dann funktioniert es (es liegt sehr wahrscheinlich daran, dass die Standardroute nicht in das Netz zeigt, in dem sich der DNS-Server befindet, wenn eine Verbindung via VPN besteht) ...

Schau mal in der Ereignisanzeige, ob dort Fehler auftauchen und wenn ja, welche. Behebt ein Neustart das Problem ? Welcher Virenscanner ist installiert ?

Schreib mal, was Du erreichen möchtest und mit welchen System Du überhaupt arbeitest ... Wozu die Reihenfolge ändern, dafür gibt es verschiedene Knotentypen. Ausserdem bezieht sich sowas nur auf NetBIOS-Namensauflösung und moderne Systeme lösen via DNS auf. Also ... was hast Du vor ?

Dabei das GPO hoch ansetzen und sicherheitsfiltern oder die zu verwaltenden Rechner in eine OU verschieben und das GPO da verknüpfen ...

Schau mal hier ... How to recover from a corrupted registry that prevents Windows XP from starting

Rechtsklick auf die OU - Objektverwaltung zuweisen ... Um diese Objekte verwalten zu können, muss sich niemand am DC anmelden können. Eine benutzerdefinierte MMC reicht da aus. Wenn er sich aber doch anmelden soll, dann muss das in den Benutzerrechten eingestellt werden. Das Benutzerrecht "Lokal anmelden zulassen" wird in der Default Domain Controller Policy standardmässig eingestellt, das Benutzerrecht "Anmelden über Terminaldienste zulassen" in der lokalen Policy des DCs. Ich würde diese Benutzerrechte auf OU-Ebene (Domain Controllers OU) einstellen, aber nicht in der Default Policy ...

Naja, Startscript kommt vor der Anmeldung eines Users und da ist ja noch nicht bekannt, wer sich anmelden wird ...