Fileserver Migration ohne Trust

[SitzRieSe 0]

Hi Zusammen,

 

ich stehe von einem relativ schwierigen Problem und wollte mal Fragen ob hier jemand eine Idee dazu hat. Wir haben hier den Fall das wir einen Fileserver auf einen anderen Server in eine andere Domäne umziehen müssen. Leider ist es in dem Fall nicht möglich ein Trusts zwischen den beiden Domänen herzustellen. Das Problem was wir jetzt haben ist, das auf dem Fileserver über 600.000 Verzeichnisse mit sehr wild gewachsenen Berechtigungen existiert. Wir müssen nun sicherstellen das alle Berechtigungen übernommen werden und die Funktionen weiterhin wie bisher gegeben sind.

 

Gibt es vielleicht eine Möglichkeit die alten SID's aus dem alten AD zu exportieren und später wieder zu importieren? ADMT geht leider nur mit einem Trust welcher hier leider komplett ausgeschlossen ist. Jemand eine Idee?

 

Gruß

 

SitzRieSe

[PathFinder 10]

Hi,

 

schau doch mal hier.

 

http://social.technet.microsoft.com/Forums/windowsserver/en-US/f36ada21-63e9-4902-8951-36eafe62b497/migrate-file-server-to-new-domain-and-export-ntfs-permission?forum=winserverMigration

 

lg der Path

[SitzRieSe 0]

Das sieht interessant aus, danke! Habe schon das halbe (soviel wars mindestens) Internet durchsucht und nix gefunden :D

 

Danke!

[PathFinder 10]

Vielleicht hast du das auch gemacht, aber ich goolge sowas nur auf Englisch, das hilft oft =9

 

Bitte und viel Erfolg.

 

Feedback ist natürlich sehr gern gesehen :P

 

lg

[SitzRieSe 0]

Ja ich werde das morgen mal simulieren, bevor ich mich da an den 600.000 Verzeichnis Fileserver ran wage!

 

Gruß

 

SitzRieSe

[SitzRieSe 0]

Also ich hab jetzt mich jetzt eine Weile mit dem SubInACL Tool beschäftigt und es scheint in der Tat das Richtige zu sein. Der richtige Parameter dürfte dieser sei:

 

/offlinesam

• The task in this example is to migrate the security settings of the files on a server from one domain to another. This example assumes that you have access to the source domain and know you will not have access to it during the migration.
  1. Store a record of user names and their corresponding SIDs from the source domain in a text file named C:\Samfile.txt. Use the following format:
     • _cachefileonly_=s-1-9-cacheonly
     • [Domain\UserName | Server\UserName]=SID
  2. Type the following at the command line:
     subinacl /offlinesam=C:\SAMFILE.TXT /subdirect \\SERVER\SHARE\*.* /migratedomain=SOURCEDOMAIN=DESTDOMAIN
  3. Press ENTER.

 

Aber wie zum Teufel erstell ich so ein Record?

 

Gruß

 

SitzRieSe

Es ist zum Mäuse melken. Also ich habe mir diese SAMFILE.txt jetzt mal manuell erstellt und dann den oben genannten CMD versucht.

Ergebnis:

 

subinacl /outputlog=C:\outputlog1.txt /offlinesam=C:\SAMFILE.txt /subdirect \\DC2\share\* /migratedomain=demo1=demo2

 

Im LOG:

 

WARNING : /migratedomain=demo1=demo2 : Invalid option : \\DC2\share\*
Use :
SubInacl /help to get the usage information
or
SubInAcl /help syntax to understand SubInAcl syntax.
Current object \\DC2\share\* will not be processed
 

Kennt jemand die Lösung? Ich hab weiß grad nicht mehr weiter und habe eher den Eindruck das es mit dem Tool nicht funktioniert. der Parameter /changedomain versucht immer eine Verbindung zu der anderen Domäne herzustellen, was natürlich nicht gelingt.

 

Hat das jemand schonmal versucht? ich fühl mich etwas alleine mit dem Thema ^^

[PathFinder 10]

Sorry nie getestet .. habs nur gefunden =)

[Weingeist 159]

Das genannte Tool scheint ziemlich schlau zu sein...

 

Im Grunde gehen solche Dinge auch mit folgender dreckiger Variante. Mittels-PC welcher mit dem ADMT-Tool ausgestattet ist. Mitglied soweit ich mich erinnere in der Ursprungsdomäne. Sowie ein Migrations-User in beiden Domänen jeweils mit Domänen-Admin Berechtigungen mit  identischem Namen und Passwort. Ist nicht wirklich schön aber zumindest von 2003 auf 2008 ging das jeweils sehr problemlos. War das/mein Standardvorgehen für den SBS-Server wenn die neue Domäne sowie der Server nach der Migration am Ende identisch heissen sollten ohne das ein Inplace Update gemacht werden kann/soll. Heute sind die Migrationen deutlich entspannter.

 

Fallstricke: Die Benutzer sollten in der neuen Domäne noch nicht existieren. Alle migrierten Gruppen/Konten haben am Ende neue SID's mit der alten SID in der History sowie ein Verfallsdatum (Benutzer)! Das musst du manuell deaktivieren. Entweder per Script oder zu Fuss. Sonst hast ein paar Monate Später die Hölle in der Helpline. Wenn Du nach SBS-Migration mit identischer Domäne und Server Name suchst, solltest die entsprechende detaillierte Guides eigentlich finden und ableiten können.

 

Wenn schon bestehende Benutzer sind, sollte man besser ein Tool verwenden wo man einem bestehenden Benutzer bzw. SID mit einer Tabelle eine oder mehrere weitere SID der History hinzufügen kann. Habe ich auch schon gesehen. Oder eben anders rum, die Berechtigungen auf den Ordner ändern. Da hätte ich aber gemischte Gefühle.