Benutzer mit den meisten Antworten
Probleme bei Filemigration von Win2k3 -> Win2k8 R2

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
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.
- Als Antwort markiert Andrei TalmaciuModerator Donnerstag, 14. Oktober 2010 07:23
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/ -
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.
-
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/ -
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=0Wie 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.
-
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=0Leg 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/ -
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.
-
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....
-
Am 11.10.2010 schrieb Julian79:
Also ich weiss jetzt was das Problem ist:
Folgende Struktur habe ich:
d:\users\usernameSowas ä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/ -
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/ -
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.
-
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.aspxhttp://www.microsoft.com/downloads/en/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&displaylang=enCheers,Florian
Microsoft MVP - Group Policy (http://www.frickelsoft.net/blog) -
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/ -
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.
- Als Antwort markiert Andrei TalmaciuModerator Donnerstag, 14. Oktober 2010 07:23