IThome

Falls es nicht klappt, kann auch die Firewall der Firma die Ursache sein (sie lässt VPN-Protokolle nicht zu) ...

Du musst einmal natürlich die Berechtigung haben, PSEXEC zu benutzen und zusätzlich die Berechtigung, die Berechtigungen in der Freigabe zu verändern (dazu zählt die Freigabeberechtigung wie auch die entsprechende NTFS-Berechtigung) ... edit: PSEXEC kann man auch als normaler Domänenbenutzer aufrufen, daran wird es also nicht liegen. Wie ist die vollständige Fehlermeldung ? Poste mal Dein Script, um den Vorgang nachvollziehen zu können ...

Ja sicher, dafür ist es gedacht ... ;) Via Remote Desktop z.B., wenn die Firmenfirewall diese Verbindungen zulässt (VPN meine ich) ...

Auch da gibt es sowas ...

XP beinhaltet eine Eingehende Verbindung, die Du dafür nutzen kannst ... Also Portweiterleitung auf dem Router (sofern dort einer steht) und Firewallausnahmen auf dem Laptop und Attacke ... :D

Du bist Dir auch sicher, dass die externe und interne Schnittstelle richtig zugewiesen hast ? Zur Not mache den RRAS noch mal neu ...

Nein, gibt es nicht ...

Mit NET USE ... z.B., da kannst Du einen Benutzernamen übergeben. Das wird aber wahrscheinlich nicht klappen, wenn Du schon eine Sitzung zu dem Server hergestellt hast. Aber mit NET USE/NET SESSION ... könnte man eine vorhandene Verbindung trennen ...

Die Gruppe muss die Berechtigung in dem freigebenen Ordner haben, die Berechtigungen zu verändern ... Was genau funktioniert denn nicht ?

Weil es seit 2000 keine BDCs mehr gibt ...

BDC ? Läuft da noch ein NT4-Server ?

Was für ein Clientbetriebssystem ?

Kann sich ein Benutzer an dem Client an der Domäne anmelden (dann muss auch ein Computerkonto vorhanden sein) ? Eventuell ein Filter in Active Directory Benutzer und Computer gesetzt ?

Dann konfiguriere in der Windows-Firewall, dass verworfene Pakete protokolliert werden und schaue im Logfile nach, was verweigert wird ...

Und RSOP sagt aus, dass die Richtlinie nicht angewendet wird ? Was ergibt GPRESULT /V ? Wird die Richtlinie sicherheitsgefiltert ?

Unter Umständen musst Du dann auf dem Server noch folgenden Fix installieren, falls der im Artikel genannte Fehler dort auftritt ... Fehlermeldung "Der folgende Eintrag im Abschnitt "[strings]" ist zu lang und wurde abgeschnitten" bei dem Versuch, Gruppenrichtlinienobjekte in Windows Server 2003, Windows XP Professional oder Windows 2000 zu ändern oder anzuzeigen

Hast Du wirklich alle Ports freigegeben und auch laut Artikel in der Registry konfiguriert ...

Naja, offensichtlich funktioniert es, wenn die Regeinträge anders als über AD-GPO gesetzt werden, dann kommen die Updates vom WSUS (so habe ich das in Post #3 interpretiert). Offensichtlich ist das Problem gar nicht, dass vom WSUS keine Updates kommen, sondern dass die Richtlinien nicht greifen ...

... weil er trotz des gleichen Namens eine andere SID bekommt ...

Servergespeicherte Profile sollten NICHT offline verfügbar gemacht (deswegen wird diese Mögichkeit in der Freigabe auch entfernt), Eigene Dateien unter Umständen schon. Daher gehören die Eigenen dateien nicht in die Profilfreigabe. Was meinst Du mit Performance ?

Ich kenne keine ...

Oder wird sicherheitsgefiltert und die Computerkonten sind nicht mehr Mitglied der entsprechenden Gruppe ?

Ich benutze in der Regel beides, damit ich die Daten, die im Profil landen (auf dem Desktop z.B.) und die Eigenen Dateien in der Sicherung habe und zudem die Benutzerprofile relativ klein gehalten werden ... Auf Desktop-PCs schalte ich die automatische Synchronisierung der Ordnerumleitung ab und bei Notebooks lasse ich sie aktiv ...

Wenn man sich im Nachhinein mal überlegt, dass die erste Antwort eigentlich schon passte ... :D :D :D Mal sehen, wo das noch hin führt (C-Code eventuell ?) ... ;)

Ähm, seit Umstellung auf AD ... SBS ... Terminalserver ? Hast Du jetzt einen SBS als Domänencontroller und einen TS als Member ? Vorher hattest Du nur einen Terminalserver Standalone ?