MaxPath 260 MS File Migration Tool
Hallo Forum,
gibt es die Möglichkeit den Max_Path beim MS File Migrationstool höher zu stellen?
Mir zeigt das Programm als Warnung an, dass einige Dateien und Ordnungsstrukturen wegen der länge konsolidiert werden.
Wie genau wirkt sich das aus ?
gibt es die Möglichkeit den Max_Path beim MS File Migrationstool höher zu stellen?
Mir zeigt das Programm als Warnung an, dass einige Dateien und Ordnungsstrukturen wegen der länge konsolidiert werden.
Wie genau wirkt sich das aus ?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 369807
Url: https://administrator.de/forum/maxpath-260-ms-file-migration-tool-369807.html
Ausgedruckt am: 31.03.2025 um 17:03 Uhr
5 Kommentare
Neuester Kommentar
Hi Leo-le
wir haben vor etwa drei Jahren keine Möglichkeit gefunden. Unser Admin (mit frischem MCSE) wollte unbedingt einen mit Lokalgruppen vehafteten FS Umzug nur damit machen. Nach doch vielen Versuchen sind wir dann auf robocopy und setacl ausgewichen (Shares haben wir vorher via reg export+import übertragen), was mit viel rumtesten vorher besser lief als zu erwarten war.
Ab Server2016 geht aber afair ein Reg Eintrag um auch non-32k auf den gehobenen Stand der NTFS Möglichkeiten zu heben.
Gruß
Sam
wir haben vor etwa drei Jahren keine Möglichkeit gefunden. Unser Admin (mit frischem MCSE) wollte unbedingt einen mit Lokalgruppen vehafteten FS Umzug nur damit machen. Nach doch vielen Versuchen sind wir dann auf robocopy und setacl ausgewichen (Shares haben wir vorher via reg export+import übertragen), was mit viel rumtesten vorher besser lief als zu erwarten war.
Ab Server2016 geht aber afair ein Reg Eintrag um auch non-32k auf den gehobenen Stand der NTFS Möglichkeiten zu heben.
Gruß
Sam
Hi
FSMT macht afair (ich habe nie damti gearbeitet):
a) Shares von Server A nach B umziehen, inkl. neuer Mountpoints
b) Sharerechte von Server A nach B umziehen
c) benutzte Lokalgruppen von Server A nach B umziehen+befüllen
d) NTFS Rechte welche in den Shares benutzt werden 1:1 übernehmen
e) NTFS Dateieigenschaften (Dates/owner) welche in den Shares benutzt werden 1:1 übernehmen
UM einen 1:1 Umstieg von Server A nach B zu vollziehen.
Das ist afair in vielen Häkchen setzen hinterlegt und bin mir sicher das es nur bei Original MS vorgegebenen Fileserverszenarien (z.B. niemals lokale user+Gruppen mit Domänengruppen kombinieren) so klappt.
Bei einem fehlerfreien Umzug mit FSMT würde ich erwarten das die ACLs 1:1 abgebildet sind; sofern lokale Gruppen benutzt werden diese auch wieder drinenn stehen. Ich kenne deinen Aufbau nicht, daher schwer zu sagen ob er einfach die auf dem Zielserver vorhandene NTFS Struktur in die Tiefe vererbt hat oder eine 1:1 Kopie.
Gruß
Sam
FSMT macht afair (ich habe nie damti gearbeitet):
a) Shares von Server A nach B umziehen, inkl. neuer Mountpoints
b) Sharerechte von Server A nach B umziehen
c) benutzte Lokalgruppen von Server A nach B umziehen+befüllen
d) NTFS Rechte welche in den Shares benutzt werden 1:1 übernehmen
e) NTFS Dateieigenschaften (Dates/owner) welche in den Shares benutzt werden 1:1 übernehmen
UM einen 1:1 Umstieg von Server A nach B zu vollziehen.
Das ist afair in vielen Häkchen setzen hinterlegt und bin mir sicher das es nur bei Original MS vorgegebenen Fileserverszenarien (z.B. niemals lokale user+Gruppen mit Domänengruppen kombinieren) so klappt.
Bei einem fehlerfreien Umzug mit FSMT würde ich erwarten das die ACLs 1:1 abgebildet sind; sofern lokale Gruppen benutzt werden diese auch wieder drinenn stehen. Ich kenne deinen Aufbau nicht, daher schwer zu sagen ob er einfach die auf dem Zielserver vorhandene NTFS Struktur in die Tiefe vererbt hat oder eine 1:1 Kopie.
Gruß
Sam
Hallo,
Das macht man das per lokaler oder halt per Domaenen-GPO.
In der Registry "hackt" man nur bei W10 Home.
https://social.technet.microsoft.com/Forums/ie/en-US/535ec156-de98-43ed- ...
Allerdings nutzen diese Einstellungen nix, wenn das benutzte (Kopier) Programm nix damit anfangen kann.
Frohe Ostern!
BFF
Das macht man das per lokaler oder halt per Domaenen-GPO.
In der Registry "hackt" man nur bei W10 Home.
https://social.technet.microsoft.com/Forums/ie/en-US/535ec156-de98-43ed- ...
Allerdings nutzen diese Einstellungen nix, wenn das benutzte (Kopier) Programm nix damit anfangen kann.
Frohe Ostern!
BFF
Hi BassFishFox
GPOs ändern auch nur die Registry ohne viel Rauch (aber mit viel Mechanik). In größeren Domänen kann das auch eher problematisch werden bis du als admin das OK aller Abteilungen hast, dass alle ihre der Produktion wichtigen Apps das auch sicher verkraften. Unser "data reconstructor" startete damit beim Öffnen eines Volumens gar nicht mehr (obwohl der gar keine Ordner rücksichert oder beachtet, sondern nur stupide nach filestrukturen sucht+bindet). Eintrag weg, reboot und ging wieder.
Mir wurde die Einstellung so erklärt (bin ja noch in der MSDN engetragen), dass die NT Umgebung drum herum das übersetzen (abfangen der Aufrufe und übersetzen in "richtig lange namen") der Langnamen übernimmt und dem Programm das dann übersetzt wenn es den alten Aufruf benutzt. Gute Programme heiligen der ntfs.dll und nicht dem Explorer....
Ist auch egal
Gruß
Sam
GPOs ändern auch nur die Registry ohne viel Rauch (aber mit viel Mechanik). In größeren Domänen kann das auch eher problematisch werden bis du als admin das OK aller Abteilungen hast, dass alle ihre der Produktion wichtigen Apps das auch sicher verkraften. Unser "data reconstructor" startete damit beim Öffnen eines Volumens gar nicht mehr (obwohl der gar keine Ordner rücksichert oder beachtet, sondern nur stupide nach filestrukturen sucht+bindet). Eintrag weg, reboot und ging wieder.
Mir wurde die Einstellung so erklärt (bin ja noch in der MSDN engetragen), dass die NT Umgebung drum herum das übersetzen (abfangen der Aufrufe und übersetzen in "richtig lange namen") der Langnamen übernimmt und dem Programm das dann übersetzt wenn es den alten Aufruf benutzt. Gute Programme heiligen der ntfs.dll und nicht dem Explorer....
Ist auch egal
Gruß
Sam