none
Probleme bei Filemigration von Win2k3 -> Win2k8 R2 RRS feed

  • Frage

  • Hallo,

    ich habe ein Problem bei der Migration von Files die bisher auf einem Win 2k3 Standard Server (32bit) abgelegt sind, künftig aber auf einem Windows 2008 R2 umgezogen werden sollen. Ich verwende für diese Migration robocopy.

    Server_alt = alter Server, Win 2k3

    Server_neu = neuer Server, Win2k8 R2

    In der Administrativen Dos-Box des Server_Neu wird das Robocopy-Skript folgendermaßen gestartet 

    robocopy \\server_alt\d$  d:\data /E /ZB /COPYALL /PURGE /V /NP /r:1 /w:1 /LOG+:c:\temp\logfile.log

    Das Skript läuft ohne Probleme durch, sämtliche Files and Folders inkl. Berechtigungen werden sauber kopiert.

    Im nächsten Schritt erstelle ich eine Freigabe auf diesen Ordner, und aktiviere die Freigabe-Berechtigung Full-Access für Everyone.

    Die Berechtigungen selbst werden ausschließlich auf NTFS Ebene gesetzt.

    Ich habe nun bei einigen Userfolders das Problem, dass trotz korrekter NTFS-Rechte das Netzlaufwerksmapping nicht funktioniert.

    Bsp: Wenn ich für User1 sein Homefolder als P:\ mappen möchte (egal ob per Skript oder manuell über den Windows Explorer), funktioniert dies zwar, wenn der Benutzer dann aber auf das Laufwerk P:\ zugreifen möchte, kommt die Meldung: "Access Denied".

    Die Berechtigungen wurden zwar richtig übernommen, aber ich habe dann zur Sicherheit nochmals den Besitz für sämtliche Ordner übernommen, und die benötigten NTFS-Berechtigungen erneut vergeben. Das Laufwerk neu gemappt, und wieder selbes Problem mit dem "Access Denied".

    Ich habe auch schon probiert, robocopy mit der Option "no copy" auszuführen, damit die NTFS-Berechtigungen mitkopiert werden, allerdings habe ich dann das Problem, dass nur die Ordner kopiert werden, aber nicht die Files ansich.

    Was mache ich falsch, bzw. kennt jemand dieses Problem?

    Grüße

    Julian

    Montag, 11. Oktober 2010 09:59

Antworten

  • Hi @ all!

    Erstmal vielen Dank für Eure Tipps. Und wie versprochen werde ich mir das abgewöhnen, die local Users auf irgendeinem Verzeichnis eines Servers zu verwenden.

    Wie schon gesagt, ich bin da selbst auch immer sehr vorsichtig mit umgegangen, und habe diese nur dann (und nur auf oberste Ebene) wie z.b. d:\ordner verwendet, aber niemals darunter, darunter habe ich dann immer brav meine AD-Gruppen verwendet. Aber das werde ich künftig nicht mehr machen, sondern ausschließlich mit AD-Gruppen arbeiten, danke für den Tipp.

    War mir einfach nicht bewusst das ich hier nen Fehler gemacht habe bzw. etwas umständlich gehandelt habe - aber ich bin ja lernfähig!

    Aber die Freigabevariante mit \\servername\userprofiles$\username muss ich verteidigen, das finde ich irgendwie besser (und das geht nicht nur mir so)! :-)

    Zu meinem Problem: Das eigentliche Problem waren die Berechtigungen gewesen. Robocopy hat hier Mist gebaut, und das hat dann dazu geführt, dass man, obwohl man in einer berechtigten Gruppe (egal ob lokal oder AD) gewesen ist. Des Lösungs Schlüssel war dann nur die Files OHNE sämtliche Berechtigungen zu übertragen.

    FSMT: Scheint ein interessantes Tool zu sein und werde ich mal auf einem Testserver ausprobieren. Für dieses Projekt habe ich noch den good-old-robocopy verwendet!

    Vielen Dank & Beste Grüße

    Juilan.

    Mittwoch, 13. Oktober 2010 07:16

Alle Antworten

  • Am 11.10.2010 schrieb Julian79:

    Ich habe nun bei einigen Userfolders das Problem, dass trotz korrekter NTFS-Rechte das Netzlaufwerksmapping nicht funktioniert.

    Bsp: Wenn ich für User1 sein Homefolder als P:\ mappen möchte (egal ob per Skript oder manuell über den Windows Explorer), funktioniert dies zwar, wenn der Benutzer dann aber auf das Laufwerk P:\ zugreifen möchte, kommt die Meldung: "Access Denied".

    Hast Du den LANMANSERVER auch mal neu gestartet?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 11. Oktober 2010 10:33
  • Hi Winfried,

    danke für Deine Antwort! Puh LANMANServer, da kommt mir was in Erinnerung... ;-) Habe diesen bisher noch nicht neu gestartet, blöde Frage, wie kann ich abfragen, welches der LANMAN-Server ist!? Wenn ich es noch richtig weiss, gibt es normal einen Server der diesen Dienst aktiv ausführt, oder liege ich da komplett falsch?

    Würde es dann reichen nur den LANMAN-Server-Dienst zu beenden und zu starten oder wirklich den kompletten Server durchstarten?

    BR

    Julian.

    Montag, 11. Oktober 2010 10:45
  • Am 11.10.2010 schrieb Julian79:

    danke für Deine Antwort! Puh LANMANServer, da kommt mir was in Erinnerung... ;-) Habe diesen bisher noch nicht neu gestartet, blöde Frage, wie kann ich abfragen, welches der LANMAN-Server ist!? Wenn ich es noch richtig weiss, gibt es normal einen Server der diesen Dienst aktiv ausführt, oder liege ich da komplett falsch?

    Der LANMANSERVER ist ein Dienst.
    http://technet.microsoft.com/de-de/library/cc738437%28WS.10%29.aspx
    Schau dir
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares
    an. Dort solltest Du deine eingestellten Berechtigungen wieder finden.

    Würde es dann reichen nur den LANMAN-Server-Dienst zu beenden und zu starten oder wirklich den kompletten Server durchstarten?

    Normalerweise reicht es aus den Dienst neu zu starten. Geht über die
    GUI oder auch per Win + R: cmd /c net stop lanmanserver && net start lanmanserver [ENTER].

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 11. Oktober 2010 11:03
  • Hi,

    ich habe den LANMANSERVER-Dienst neu gestartet, das Problem konnte dadurch aber nicht behoben werden. Die Settings in der Registry für meine benötigte Freigabe sieht wie folgt aus:

    CSCFlags=0
    MaxUses=4294967295
    Path=d:\FOLDERNAME
    Permissions=0
    Remark=
    ShareName=FOLDERNAME$
    Type=0

    Wie schon gesagt, wenn ich nun von dem Client des Benutzers den Windowsexplorer öffne und \\server_neu\foldername$ eingebe, funktioniert alles.

    Wenn ich selbigen Pfad als Netzlaufwerk verbinden, kommt die Access Denied-Fehlermeldung!

    Irgendeinen Tipp welchen Wert ich mir da ansehen muss, bzw. muss ich bei Windows 2008 R2 als Fileserver etwas bestimmtes beachten bzw. eine bestimmte Rolle/Feature installieren??

    Bisher habe ich nur Fileserver und wbadmin installiert.

    Grüße

    Julian.

    Montag, 11. Oktober 2010 12:41
  • Am 11.10.2010 schrieb Julian79:

    ich habe den LANMANSERVER-Dienst neu gestartet, das Problem konnte dadurch aber nicht behoben werden. Die Settings in der Registry für meine benötigte Freigabe sieht wie folgt aus:

    Hast Du den neuen Server auch schon durchgestartet?

    CSCFlags=0
    MaxUses=4294967295
    Path=d:\FOLDERNAME
    Permissions=0
    Remark=
    ShareName=FOLDERNAME$
    Type=0

    Leg doch mal einen neuen frischen Ordner an und gib den frei.

    Wie schon gesagt, wenn ich nun von dem Client des Benutzers den Windowsexplorer öffne und\\server_neu\foldername$ <file://\\server_neu\foldername$> eingebe, funktioniert alles.

    Du kannst auch auf den Ordner und die Unterordner zugreifen? Dateien
    erstellen, verändern und löschen funktioniert? Auch in den
    Unterordnern?

    Wenn ich selbigen Pfad als Netzlaufwerk verbinden, kommt die Access Denied-Fehlermeldung!

    Beide male ist es wirklich der komplett gleiche Pfad?

    Irgendeinen Tipp welchen Wert ich mir da ansehen muss, bzw. muss ich bei Windows 2008 R2 als Fileserver etwas bestimmtes beachten bzw. eine bestimmte 
    Rolle/Feature installieren??

    Nein, IMHO ist es die gleiche Vorgehensweise wie bei den bisherigen
    Betriebssystemen.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 11. Oktober 2010 13:17
  • Also ich weiss jetzt was das Problem ist:

    Folgende Struktur habe ich:

    d:\users\username

    Das Verzeichnis ist mit users$ freigegeben.

    Auf d:\users\ habe ich folgende Berechtigungen gesetzt:

    - lokale Admin-Gruppe = Full Access

    - lokale User-Gruppe = read (inkl. List folder contents)

    - lokaler system-user = full access

    auf d:\users\username sind die folgenden NTFS-Berechtigungen gesetzt:

    - lokale Admin-Gruppe = Full Access

    - domain\username = full access

    - system = full access

    ---------

    Problem: Wenn der Benutzer sich nun versucht das Laufwerk mittels Netzlaufwerk zu verbinden, kommt eine Access-Deny-meldung.

    Wenn ich den UNC-Pfad im Explorer eingebe (\\servername\users$\username) klappt es.

    -------

    Wenn ich nun List-Folder-Kontents für die Gruppe Domain Users auf den Ordner Users erstelle,

    dann funktioniert das ganze. Aber eigentlich haben die Domain Users schon dieses Recht durch deren Mitgliedschaft der lokalen User dieses Servers...

    Muss ich das verstehen???

    Grüße

    Julian.

     

    Montag, 11. Oktober 2010 13:36
  • Ups, habe ganz vergessen deine Fragen zu beantworten:

    Server durchgestartet = JA

    Unterordner browsen, Files anlegen etc geht alles vom UNC-Pfad aus = JA

    Gleicher Pfad = JA

    Kann es sein, dass die lokalen Gruppen irgendwie deaktiviert sind und man diese erst wieder in der Local Security Policy aktivieren muss oder wie?

    Ich hab das schon immer so gemacht, auf Ordnern bei denen eine allgemeine Lese-Berechtigung benötigt wird, habe ich einfach die lokale User-Gruppe genommen, da darin ja die Domain Users drinnen sind....

     

    Montag, 11. Oktober 2010 13:48
  • Am 11.10.2010 schrieb Julian79:

    Also ich weiss jetzt was das Problem ist:

    Folgende Struktur habe ich:

    d:\users\username

    Sowas ähnliches hab ich mir schon gedacht. Den Benutzern fehlt die
    NTFS-Berechtigungen auf ihre eigenen Ordner.

    Das Verzeichnis ist mit users$ freigegeben.

    Weshalb? Brauchst Du nicht. Gib die darunter liegenden Ornder für die
    jweiligen Benutzer frei und mappe direkt:
    net use H: \\Server\%username%

    Auf d:\users\ habe ich folgende Berechtigungen gesetzt:

    - lokale Admin-Gruppe = Full Access

    - lokale User-Gruppe = read (inkl. List folder contents)

    Mit Vererbung nach unten?

    Problem: Wenn der Benutzer sich nun versucht das Laufwerk mittels Netzlaufwerk zu verbinden, kommt eine Access-Deny-meldung.

    Zum letzten Mal gefragt, wie genau verbindest Du? Per net use H:
    \\Server\users$\%username% oder \\server\%username%?

    Wenn ich den UNC-Pfad im Explorer eingebe (\\servername\users$\username <file://\\servername\users$\username>) klappt es.

    Kannst Du Dateien erstellen und löschen?

    Wenn ich nun List-Folder-Kontents für die Gruppe Domain Users auf den Ordner Users erstelle,

    dann funktioniert das ganze. Aber eigentlich haben die Domain Users schon dieses Recht durch deren Mitgliedschaft der lokalen User dieses Servers...

    Welche lokalen Benutzer? Du hast ein Active Directory, Du brauchst
    keine lokalen Gruppen mehr. Leg Sicherheitsgruppen im AD an und benutz
    die. Wie hattest Du es auf dem "alten" Server eingestellt? Genauso
    ganz bestimmt nicht.

    Muss ich das verstehen???

    Ich weiß noch nicht genau was Du da machst, ich weiß nur das die
    ?-Taste bei kaputt ist.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 11. Oktober 2010 13:57
  • Am 11.10.2010 schrieb Julian79:

    Kann es sein, dass die lokalen Gruppen irgendwie deaktiviert sind und man diese erst wieder in der Local Security Policy aktivieren muss oder wie?

    Hast Du denn die lokalen Gruppen auf dem neuen Server auch wieder neu
    angelegt? Wenn ja, Namen sind Schall und Rauch. Auch wenn alle
    Buchstaben gleich sind, die SID ist eine andere. Schon knallts.

    Ich hab das schon immer so gemacht, auf Ordnern bei denen eine allgemeine Lese-Berechtigung benötigt wird, habe ich einfach die lokale User-Gruppe genommen, da darin ja die Domain Users drinnen sind....

    Verabschiede dich von der Vorgehensweise. Benutz die Werkzeuge die das
    AD dir zur Verfügung stellt. Arbeite mit Gruppen aus dem AD. Ansonsten
    kannst Du das AD ja auch wieder einstampfen und alles lokal pflegen.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 11. Oktober 2010 14:00
  • Hey,

    also folgendes habe ich gebaut:

    1. Nach dem Robocopy-Job die Berechtiungen folgendermaßen angepasst:

    - d:\users -> Besitz übernommen für alle Ordner, Unterordner, Files etc...

    - d:\users -> NTFS-Berechtigungen neu vergeben auf: lokale Admin-Group = Full-Access; lokale Users Gruppe = read, execute, list folder contents ; system = full access

    -d:\users\%username% -> NTFS Berechtigungen gesetzt: lokale Admin-Group = Full-Access; system = Full Access; %username% = Full Access

    - Den Ordner d:\users freigegeben: Freigabename: users$; Freigabe-Berechtigungen = Everyone = Full Access

    Im Loginskript verwende ich dann den Pfad \\servername\users$\%username% . Das mach ich deswegen so, um den Überblick der Freigabenamen zu wahren... :-)

    In der lokalen Gruppe "Users" sind die Domain-Users Mitglied. Somit sollten die Domain-Users über die erfoderlichen Rechte verfügen. Ich hab das halt immer so gemacht, fande dies irgendwie selbsterklärend und verständlich... :-)

    Aber kann dies auch gerne abändern auf eine Domain-Group. Aber du stimmst mir schon auch zu, dass dies eigentlich auch so funktionieren müsste, oder?

    Auf dem alten Server war es etwas chaotisch, daher wollten wir das etwas aufräumen. Da waren diverse Domain-Groups auf den Users-Ordner berechtigt, und auf den Username-Ordner die benötigten Benutzer.

    Wie schon gesagt, habe das schon oft so wie oben beschrieben gemacht, und ich meine, ich hab das mal auch bei irgendeiner Schulung so aufgeschnappt...!

    Mach mich jetzt bitte nicht völlig fertig, dass mein Weg komplett falsch und abwegig ist...!

    Zu deinen Fragen:

    Zugriff mittels UNC-Pfad: \\servername\users$\%username% = Dateien können erstellt werden und gelöscht werden, alles läuft also "normal".

    Wenn ich nun denselben Pfad als Netzlaufwerk mappe = kommt Access Denied!

    Wenn ich nun wieder sicher stelle, dass das List-Folder-Contents-Recht auf die Domain-Users-Group direkt gesetzt ist, kann der User das Netzlaufwerk mappen, und sowohl im Netzlaufwer als auch im UNC-Pfad Änderungen durchführen oder Dateien neu erstellen, löschen etc....

    Aber um sicherzustellen, dass MEIN Weg auch funktioniert habe ich mal nen anderen User verwendet mit den Berechtigungen die ich verwenden wollte: Da hat es sofort geklappt.

    Also nur um Irritationen und Verwirrungen zu vermeiden:

    Ich habe mir irgendwann mal angewöhnt für Ordner, bei denen eine generelle Berechtigung wie z. B. lesen gesetzt werden soll eben die lokale Gruppe zu verwenden, da dort somit automatisch alle Domain Users mit drinnen sind. Wenn es dann um generelle Berechtigungen geht, verwende ich natürlich auch die Security-Groups vom AD! Das trifft dann meißt nur auf Ordner der höchsten Ebene zu, wie z.b. das Verzeichnis users in der alle Userverzeichnisse drinnen liegen! Und alle Berechtigungen drunter werden entsprechend mit dem AD sauber geregelt.

    Selbiges mit Verzeichnisse die für Gruppenlaufwerke benötigt werden!

    Ich habe nun heute festgestellt, dass mein Testuser nicht Mitglied der Domain Users war, und das habe ich dann heute Morgen geändert, leider hat das nicht zum Erfolg geführt, was darauf schließen lässt dass dieser Testuser ein prinzipielles Problem hat!

    Naja sei es drum, ich würde sagen, wir haben das Problem gelöst, oder? Wenn du mir jetzt noch zustimmen könntest, dass mein Weg nicht ganz falsch ist, könnte ich heute Nacht auch gut schlafen...

    Ich hoffe ich hab dir jetzt die ganze Situation gut erklärt und bei dir sind keine Fragen mehr offen, wenn nicht frag einfach noch mal! ;-)

    Grüße und thx!

    Julian.

     

      

     

    Montag, 11. Oktober 2010 14:58
  • Howdie!
     
    On 11.10.2010 11:59, Julian79 wrote:
    > ich habe ein Problem bei der Migration von Files die bisher auf einem
    > Win 2k3 Standard Server (32bit) abgelegt sind, künftig aber auf einem
    > Windows 2008 R2 umgezogen werden sollen. Ich verwende für diese
    > Migration robocopy.
     
    Blöde Frage: warum hast du FSMT deine Daten nicht anvertraut?
    http://www.microsoft.com/windowsserver2008/en/us/fsmt.aspx
    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&displaylang=en
     
    Cheers,
    Florian
     

    Microsoft MVP - Group Policy (http://www.frickelsoft.net/blog)
    Montag, 11. Oktober 2010 15:07
  • Am 11.10.2010 schrieb Julian79:

    also folgendes habe ich gebaut:

    1. Nach dem Robocopy-Job die Berechtiungen folgendermaßen angepasst:

    Also war das alles auf dem alten Server anders?

    Im Loginskript verwende ich dann den Pfad \\servername\users$\%username% <file://\\servername\users$\%username%> . Das mach ich deswegen so, um den Überblick der Freigabenamen zu wahren... :-)

    Welchen Überblick? Hauptsache das Script beinhaltet viele Zeichen? Mit
    \\Server\%susername% kommst Du zum gleichen Ziel und spart Zeichen und
    evtl. Tippfehler.

    In der lokalen Gruppe "Users" sind die Domain-Users Mitglied. Somit sollten die Domain-Users über die erfoderlichen Rechte verfügen. Ich hab das halt immer so gemacht, fande dies irgendwie selbsterklärend und verständlich... :-)

    Eine Domain Gruppe in eine lokale Gruppe zusätzlich einpflegen ist
    nicht gerade effizient. Es ist auch nicht selbsterklärend und für mich
    auch nicht verständlich.

    Aber kann dies auch gerne abändern auf eine Domain-Group. Aber du stimmst mir schon auch zu, dass dies eigentlich auch so funktionieren müsste, oder?

    Benutz in den Freigaben Sicherheitsgruppen aus dem AD. Alles andere
    ist unübersichtlich und chaotisch.

    Auf dem alten Server war es etwas chaotisch, daher wollten wir das etwas aufräumen. Da waren diverse Domain-Groups auf den Users-Ordner berechtigt, und auf den Username-Ordner die benötigten Benutzer.

    Also doch anders als jetzt auf dem neuen Server.

    Wie schon gesagt, habe das schon oft so wie oben beschrieben gemacht, und ich meine, ich hab das mal auch bei irgendeiner Schulung so aufgeschnappt...!

    Bring Beweise und stell keine Behauptungen auf.

    Mach mich jetzt bitte nicht völlig fertig, dass mein Weg komplett falsch und abwegig ist...!

    Auf einem Domain Member Server legt man keine lokalen Gruppen auf
    Freigaben. Die lokale Gruppe von ServerA ist nicht die gleiche wie auf
    ServerB.

    Zu deinen Fragen:

    Zugriff mittels UNC-Pfad: \\servername\users$\%username% <file://\\servername\users$\%username%> = Dateien können erstellt werden und gelöscht werden, alles läuft also "normal".

    Wenn ich nun denselben Pfad als Netzlaufwerk mappe = kommt Access Denied!

    Weil der Zugriff auf \\server\Users$ vermutlich schon fehlschlägt. Du
    hast auch noch nicht geschrieben wie genau Du als Netzlaufwerk
    mappst.

    Wenn ich nun wieder sicher stelle, dass das List-Folder-Contents-Recht auf die Domain-Users-Group direkt gesetzt ist, kann der User das Netzlaufwerk mappen, und sowohl im Netzlaufwer als auch im UNC-Pfad Änderungen durchführen oder Dateien neu erstellen, löschen etc....

    Was genau willst Du mit diesen Rechten erreichen? BenutzerA hat darf
    nicht die Ordner von Users$ auflisten. BenutzerA soll in seinen Ordner
    kommen, nicht mehr und nicht weniger.

    Ich habe mir irgendwann mal angewöhnt für Ordner, bei denen eine generelle Berechtigung wie z. B. lesen gesetzt werden soll eben die lokale Gruppe zu verwenden, da dort somit automatisch alle Domain Users mit drinnen sind.

    Dann gewöhn dir das wieder ab.

    Wenn es dann um generelle Berechtigungen geht, verwende ich
    natürlich auch die Security-Groups vom AD! Das trifft dann meißt
    nur auf Ordner der höchsten Ebene zu, wie z.b. das Verzeichnis
    users in der alle Userverzeichnisse drinnen liegen! Und alle
    Berechtigungen drunter werden entsprechend mit dem AD sauber
    geregelt.

    Lokale Gruppen verwendet man dafür nicht.

    Selbiges mit Verzeichnisse die für Gruppenlaufwerke benötigt werden!

    Oje, wird ja immer schlimmer.

    Ich habe nun heute festgestellt, dass mein Testuser nicht Mitglied der Domain Users war, und das habe ich dann heute Morgen geändert, leider hat das nicht zum Erfolg geführt, was darauf schließen lässt dass dieser Testuser ein prinzipielles Problem hat!

    Gruppenmitgliedschaft.

    Naja sei es drum, ich würde sagen, wir haben das Problem gelöst, oder? Wenn du mir jetzt noch zustimmen könntest, dass mein Weg nicht ganz falsch ist, könnte ich heute Nacht auch gut schlafen...

    Die Nach versau ich dir. Lokale Gruppen haben IMHO in Freigaben für
    Domain User nix verloren.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 11. Oktober 2010 15:56
  • ich tippe mal...weil er es nicht anders "aufgeschnappt" hatte. ;-) Aber naja, das Skript ist bei der FS Migration ja das geringste Problem :-).

    Gruß

    Martin

    Montag, 11. Oktober 2010 19:27
  • Hi @ all!

    Erstmal vielen Dank für Eure Tipps. Und wie versprochen werde ich mir das abgewöhnen, die local Users auf irgendeinem Verzeichnis eines Servers zu verwenden.

    Wie schon gesagt, ich bin da selbst auch immer sehr vorsichtig mit umgegangen, und habe diese nur dann (und nur auf oberste Ebene) wie z.b. d:\ordner verwendet, aber niemals darunter, darunter habe ich dann immer brav meine AD-Gruppen verwendet. Aber das werde ich künftig nicht mehr machen, sondern ausschließlich mit AD-Gruppen arbeiten, danke für den Tipp.

    War mir einfach nicht bewusst das ich hier nen Fehler gemacht habe bzw. etwas umständlich gehandelt habe - aber ich bin ja lernfähig!

    Aber die Freigabevariante mit \\servername\userprofiles$\username muss ich verteidigen, das finde ich irgendwie besser (und das geht nicht nur mir so)! :-)

    Zu meinem Problem: Das eigentliche Problem waren die Berechtigungen gewesen. Robocopy hat hier Mist gebaut, und das hat dann dazu geführt, dass man, obwohl man in einer berechtigten Gruppe (egal ob lokal oder AD) gewesen ist. Des Lösungs Schlüssel war dann nur die Files OHNE sämtliche Berechtigungen zu übertragen.

    FSMT: Scheint ein interessantes Tool zu sein und werde ich mal auf einem Testserver ausprobieren. Für dieses Projekt habe ich noch den good-old-robocopy verwendet!

    Vielen Dank & Beste Grüße

    Juilan.

    Mittwoch, 13. Oktober 2010 07:16