daabm

Weil Du in -on ein Verzeichnis stehen hast? :-) Fütter die Dateien einzeln in SetAcl rein.

Smartcard findest Du in den Sicherheitseinstellungen - Lokale Richtlinien - Sicherheitsoptionen: "Interaktive Anmeldung: Smartcard erforderlich". Mit den Silos hab ich noch nichts gemacht (demnächst erst), aber das kriegt man auch prima mit "Zuweisen von Benutzerrechten" hin :)

...wie der Dunkelmann schon schrub. DFS-R für "gemeinsam genutzte" Dateien bei schreibendem Zugriff ist eher nicht möglich. Ohne Drittanbieter gibt es kein Locking, "Last Writer Wins" ist die Devise.

Firewall Regeln und Gateway glaube ich Dir - Kerberos bestimmt nicht :D Aber ok, das läuft unter "höhere Gewalt"...

Um auf die Ursprungsfrage zurück zu kommen: Das Mappen macht kein "Dienst" in dem Sinne - das hängt im Arbeitsstationsdienst mit drin. Um das zuverlässig zu verhindern, fallen mir 2 Lösungen ein - wobei mir noch die Antwort auf die Frage nach dem Hintergrund fehlt: 1. Firewall-Regel auf dem Server, die SMB (137-139,445) von diesem Client blockt. 2. IPSec

Licht ist fast aus - aber nur fast...

Ok. Und wo ich grad so drüberschaue - da fehlt noch Set oWMI = GetObject( "winmgmt:" ) bzw. Set oWSH = CreateObject( "WScript.Shell" ) ...oder so :) :) Passiert schon mal, wenn man Funktionen aus größeren Skripts raus-"operiert"...

Da sei mir die neugierige Frage gestattet: Warum soll sich die IP nicht ändern? "Historisch" überall noch vergraben? Das wäre dann die richtige Gelegenheit, auf Hostnamen - oder noch besser CNames - umzustellen :) Tut nur einmal kurz weh und funktioniert dann bei zukünftigen Migrationen problemlos.

Sunny hat Recht - das Server-OS ist in diesem Konstrukt völlig belanglos :)

Ich sag mal so: Es ist keine "unübliche Vorgehensweise", aber sogar MS hat ja die Notbremse gezogen mit dem Supportstatement zu RUP/Homeshare und DFSR... :) MS hat ja vor 15 Jahren auch Parent/Child Domain Konstrukte empfohlen, die heute definitiv deprecated sind :D

Und auch wenn Du es "unterbindest" - wie verhinderst Du später den Zugriff? Was ist der Hintergrund dieser Vorgehensweise?

Ich dreh mal ein wenig runter - Essen ist gegessen, Trinken ist getrunken, Sehen ist gesehen, Feierabend :)

Wer funkt in der Nachbars***aft auf dem gleichen Kanal? Edit: Der "Schimpfwortfilter" hier ist etwas überempfindlich :D

VPN macht man idealerweise per Computerzertifikat mit Auto-Enrollment. Dann hast Du das Problem nicht - aber wenn das bei Dir nicht geht, ist es halt schwieriger :)

...deshalb heißt es ja auch "pre shared", weil man den "vorher verteilen" muß :)

Ja, weil Du eben NICHT die ADMX-Vorlagen von 2008 in Deinem Central Store hast, sondern neuere. Siehe die Hinweise von Daniel und auch von mir (weiter oben).

Bei AD-integriertem DFS könnte das schwierig werden, hab ich aber auch noch nie ausprobiert... Bei reinem UNC-Zugriff geht es, ja.

Wenn Du - ab Windows Vista - den Firewall-Dienst (mpssvc) beendest, solange sein Startmodus nicht auf "Deaktiviert" steht, geht das System in die Boot Time Protection und blockiert alle eingehenden Verbindungen. Wenn Du noch XP einsetzt, möchte ich Dir eigentlich nicht mehr helfen :D

PSK per GPO - tut mir leid für Dich, aber das geht schlicht nicht. Weder bei VPN noch bei WLAN.

Norbert: :jau: :D

Die eine Schleife läuft, solange etwas "WAHR" ist. Die andere läuft, solange etwas "FALSCH" ist.

Gib Deinem Task einen eindeutigen Namen und lösche ihn im Batch direkt wieder: schtasks /delete /tn <Name des Tasks> /f Oder auch nur deaktivieren: schtasks /change /tn <Name des Tasks> /disable

Wenn Du Deinen GPOs unbedingt auf dem Server bearbeiten willst, dann kopiere auf dem Server C:\Windows\PolicyDefinitions (inkl. Unterverzeichnisse natürlich) in den Central Store. Da liegen die ADMX, die 2008 "ab Werk" dabei hatte.

Probier's mal per Befehlszeile: "netdom help join"

Nachtlicht einschalt... Bis morgen, liebe Kolleg(inn)en :)