Wie migriert man Shares richtig?

[NullDevice]

Hallo,

Ich möchte die shares von unserem alten server (Win 2003) auf unseren neuen server (Win 2008 R2) migrieren.

Wie mache ich das richtig? Denn hier ist 24h Betrieb, und den Usern zu sagen, die Netzlaufwerke nicht zu verwenden reicht nicht. Irgendwer erfährt es bestimmt nicht und verwendet sie weiter.

Wenn ich allerdings "Freigabe aufheben" mache, lösche ich somit alle Freigabe-berechtigungen. Ich hab es mit einer unwichtigen Freigabe getestet.

Ich dachte mir zuerst, dass ich "Anzahl der zulässigen Benutzer" auf 0 stellen kann, damit diese Freigabe während dem Migrieren niemand hat. Jedoch kann man sie minimal auf 1 setzen.

Was ist hier Best-practice? Wie migriert man shares richtig?
Und wie macht man den Kopiervorgang so, dass alle Berechtigungen erhalten bleiben? Mit robocopy?

Letzesmal bin ich ziemlich eingefahren, als ich es normal per explorer unter win 2008 vom alten share kopiert hab, und alle Berechtigungen unter "Sicherheit" wurden nicht übernommen (!)
Das war eine ziemliche Katastrophe und hat ewig gedauert es zu rekonstruieren (manuell jeden Ordner - Sicherheit anpassen).


MfG,
Danke für jeden Hinweis & Tipp!
ND

 

[Graphixx]

Das Berechtigungen nicht mitkopiert werden ist relativ normal. Sobald die Daten die ursprüngliche Partition verlassen ist der Zielordner für die Rechte verantwortlich, die ursprünglichen werden aufgelöst. Das ist aber ein Thema für sich, wie man was von wo nach wo kopiert oder verschiebt und wann sich was ändert.

Aber Du hast die Lösung schon: Robocopy kann das, nur die passenden Schalter setzen.

Zum Thema Shares migrieren...http://social.technet.microsoft.com/Forums/de-DE/windows_Serverde/thread/5d2a6c97-89d3-4e39-8603-1c4f2437b76b/ da ist es recht anschaulich erklärt.

MfG

 

[knuddelbaer1989]

Also:

Robocopy --> JA! Kann mit Sicherheitsinformationen kopieren (Kann sogar nach dem kopieren die Sicherheitsinfos abgleichen (http://support.microsoft.com/kb/323275/de))

Wie man Shares richtig umzieht: Ich würde die Freigaben "Read only" schalten. Also die Freigabe Berechtigung nur auf lesend setzen. Somit kann nichts passieren aber die Leute können dennoch ihre Dateien lesen (müssen sie aber erstmal lokal zwischenspeichern!). So wurde es jetzt bei uns gemacht um auf unser neues NAS umzuziehen.

Die Freigabeberechtigungen musst du ohnehin neusetzen, da diese Windows und nicht Dateiabhängig sind.

Gruß

 

[NullDevice]

Danke für die Antworten und Ideen!
Jetzt ist mir zu Euren Kommentaren NOCH eine Idee gekommen.
Man könnte ja, anstatt die Shares auf Read Only zu setzen, sie einfach während dem Kopieren weiterbelassen, dass die User damit arbeiten können.
Und nach dem Elends-langen Kopiervorgang schliesslich auf Read-Only setzen, und mit Robocopy NUR die geänderten Files kopieren!

Das ist dann ein relativ kurzer Vorgang, wo die User ihre Files nicht "writeable" haben, anstatt dem stundenlangen grossen Kopiervorgang.

Aber... Was ist mit den Files, die gelöscht wurden von den Usern während dem Kopiervorgang? Muss mal schauen, ob Robocopy das auch kann, nicht nur die geänderten zu kopieren, sondern auch die gelöschten zu im Ziel zu löschen...

Ist das prinzipiell eine gute Idee? Oder eher nicht?

 

[knuddelbaer1989]

Das würde ich lassen... Das kann zu GANZ massiven Problem kommen. Und selbst bei uns mit 900 Mitarbeitern die ständig auf den Servern arbeiten gab es keine Probleme. Es ist verkraftbar mal ein paar Stunden nicht auf dem Server speichern zu können und das Lokal tun zu müssen...

Und ihr arbeitet wirklich 24 Stunden an 7 Tagen der Woche?

Alternativ wäre auch: An Weihnachten kopieren aber das wäre dann mehrarbeit für dich...

Gruß

 

[NullDevice]

Es gibt keinen Tag im Jahr, nichtmal eine Sekunde, wann hier nicht gearbeitet wird. Auch nicht zu Weihnachten.
(= Hotline für Medizinische Notfälle).

 

[Andreas75]

also ohne minimale downtime wird das nicht gehen. blöde frage, warum greifen die auf dateien und nicht auf datenbanken zu? was wird da bearbeitet?

 

[NullDevice]

also ohne minimale downtime wird das nicht gehen. blöde frage, warum greifen die auf dateien und nicht auf datenbanken zu? was wird da bearbeitet?

Sie greifen AUCH auf DBs zu, aber die liegen ganz auf einem anderen Server.
Das sind nur alltägliche Files mit denen gearbeitet wird, zB. Office files with xls, pdf, word, präsentationen, etc.

Maximal Access-dbs liegen hier auf den shares, vereinzelt...


Eine downtime ist akzeptabel wenn sie Lesezugriff haben. Denn in diesem Fall können sie sich Files zum Bearbeiten auf den Desktop-rechner kopieren und später wieder auf den neuen share.

Ergänzung (28. Oktober 2011)

OK so werde ich es machen... Es auf Nur lesen setzen wie du gesagt hast. Dürfte noch die beste Methode sein.
Allerdings muss man es dann ja auch für JEDEN einzelnen User auf nur lesen setzen, sprich die Schreibrechte wegnehmen etc.

Da ist es besser zuerst die Berechtigungen der Freigabe am Ziel richtig zu setzen, sonst kann man sich hinterher nicht mehr erinnern wer vorher schreibrechte hatte und wer nicht Sind viele User die versch. Berechtigungen haben...

Danke auf jedenfall.

 

[knuddelbaer1989]

Du sollst die Freigabe READ-Only schalten nicht die SIcherheitseinstellungen!

Du machst einfach bei der Freigabe ein JEDER und Verbietest Schreiben! Verbieten geht immer vor erlauben. Und dannach löschst du das Jeder auf der neuen Freigabe...

Gruß

 

[NullDevice]

Du sollst die Freigabe READ-Only schalten nicht die SIcherheitseinstellungen!

Du machst einfach bei der Freigabe ein JEDER und Verbietest Schreiben! Verbieten geht immer vor erlauben. Und dannach löschst du das Jeder auf der neuen Freigabe...

Gruß

AHH Danke! Das ist extrem nützlich!

 

[Frightener]

Man muß ja nicht expliziert verbieten. Den Haken bei Schreiben rausnehmen reicht auch Standard ist bei 2008 und höher sowieso nur Schreiben.

Ich verstehe auch nicht, warum es zu Problemen kommen sollte, wenn man die User während des Kopierens auf den alten Shares weiterarbeiten läßt. Das habe ich so auch schon so gemacht. Bei ca. 100TB dauert das Kopieren z.B mehrere Tage. Kurz vor der 'Umschaltung' stellst Du den alten Server auf readonly, machst das letzte Deltacopy und schaltest dann den neuen frei.

Sinnvoll wäre hier ein DFS Namespace, der von den Servern unabhängig ist. Dann könnte man einfach einen neuen Server readonly unter den Namespace hängen und nach der Replikation die Server switchen.

 

[NullDevice]

Würde mich auch interessieren, was genau diese Probleme dabei sind. Wär nämlich geil wenn es gehen würde.

Und ja, DFS wäre hier natürlich super. Verwenden wir aber nciht mehr weil es in der Vergangenheit Probleme gemacht hat lt. meinem Chef. Schade eigentlich.

Ergänzung (29. Oktober 2011)

Ganz so einfach ist es übrigens nicht. Gibt man in der Freigabeberechtigung unter JEDER / Verweigern bei "Ändern" den Haken rein, springt auch der bei "Lesen" automatisch mit rein.

Beim Erlauben macht das durchaus Sinn, schliesslich wird jemand, der Ändern darf auch logischerweise Lesen dürfen. Aber beim Verweigern sollte es umgekehrt sein! Ist es aber nicht.

Deshalb konnte ich die Freigabe leider nur ganz sperren (nix erlauben, auch nicht lesen).

Beim nächsten Share das ich dann migriert hab, hab ich etwas anderes probiert:
Ich hab nicht unter Freigabe, sondern unter Sicherheit JEDER hinzugefügt und hier Verweigern gesetzt. Hier kann man, in den "Erweiterten Sicherheitseinstellungen", die Rechte durchaus genau so setzen wie man sie will. Sprich hier ist es möglich Ändern zu verbieten und lesen nicht.

Das warf jedoch zweierlei Probleme auf:

1.) Wenn es die Gruppe JEDER bereits gab, mit Erlauben Rechten, konnte man Verweigern nicht mehr setzen, denn sobald man auch nur 1 Kästchen in der Verweigern Spalte auswählte, fielen automatisch alle in der Erlauben-spalte raus.

Workaround den ich gefunden hab: Unter den erweiterten Sicherheitseinstellungen einfach JEDER NOCHMALS hinzufügen mit den verweigern-Optionen. Somit gibt es eine Gruppe JEDER mit den Erlauben Rechten und eine weitere Gruppe JEDER mit den Verweigern Rechten. Das hat hingehauen.

2.) Das Problem, dass es schliesslich auch auf alle Unterordner und Dateien durchgesetzt werden muss, siehe Haken unten bei "Berechtigungen auf allen untergeordneten Objekte übernehmen..."
Das ist zwar kein Problem, kann man ja machen, aber wie bekommt man es dann wieder weg, nach dem Kopiervorgang. Reicht es wenn man hier JEDER wieder rausnimmt und nochmal auf die untergeordneten Objekte die Rechte übernimmt, wieder? Oder ist es damit nicht getan?


Weiters würde mich interessieren, ob Rechte auf einen dedizierten User mehr zählen als das verweigern auf eine Gruppe. User hat vorrang vor Gruppe in der der User ist, nicht wahr? Aber andererseits hat Verweigern wieder Vorrang vor Erlauben. Hmmm... werd' es einfach irgendwann ausprobieren.

 

[Frightener]

Aufgepaßt, Du verwechselst Share- mit NTFS Berechtigungen!

 

[NullDevice]

Aufgepaßt, Du verwechselst Share- mit NTFS Berechtigungen!

Nein Ich bin mir dessen bewusst! Ich habe die NTFS Berechtigungen deshalb benutzt, weil wie oben beschrieben, bei den Share-berechtigungen das Ändern nicht ohne Lesen verweigert werden kann!
Es geht mit den NTFS Berechtigungen auch, für diesen Zweck. Nämlich den Effekt zu erzielen, dass User nicht auf das Share schreiben können während des Kopiervorgangs, jedoch Lesen dürfen.

Zumindest glaube ich, dass es nicht geht, wenn sie in den Share berechtigungen das Recht haben, jedoch per NTFS Berechtigungen verweigert werden. Ich glaube dann können sie nicht auf das Share schreiben (habs jedoch nicht ausprobiert).

 

[Frightener]

Die User greifen über das Netzwerk auf die Ordner zu. Somit greifen auch die Share Berechtigungen. Wenn die User nur LESEN dürfen ist es egal, ob sie NTFS-technisch auch SCHREIBEN dürfen. Effektiv können sie nur LESEN. An den NTFS Berechtigungen rumzufummeln ist doch Blödsinn. Ich denke, diese Berechtigungen sollen vom Ursprungsshare mitkopiert werden.

Die User sollen an der Quelle (dem alten Server) bis zur Umschaltung noch alles können. Den neuen Share sehen sie doch sowieso nicht. Erst im letzten Augenblick deaktivierst Du den alten Share für die Nutzer, machst ein letztes Deltacopy und gibst dann den SHARE (nicht die NTFS Berechtigungen) auf dem neuen Server frei.

 

[NullDevice]

Die User greifen über das Netzwerk auf die Ordner zu. Somit greifen auch die Share Berechtigungen. Wenn die User nur LESEN dürfen ist es egal, ob sie NTFS-technisch auch SCHREIBEN dürfen. Effektiv können sie nur LESEN.

Das ist schon richtig was du sagst. Nur dass es darum ging, ihnen Leserechte OHNE Schreibrechte zu geben, und dass ihnen diese Schreibrechte mittels Verweigern genommen werden. Da dies aber per Share-berechtigungen anscheinend nicht möglich ist (Verweigern -Ändern kann man nicht reingeben, ohne dass auch das Lesen verweigert wird (warum auch immer, Haken wird automatisch gesetzt), hab ich mir mit den NTFS Berechtigungen geholfen, wo dies durchaus möglich ist (Ändern auf Verweigern setzen, ohne Lesen ebenfalls zu verweigern). Und zwar ging es hier bei den Speziellen Berechtigungen, die es jedoch anscheinend bei Share-Berechtigungen nicht gibt.

 

[Frightener]

Aber warum willst Du verweigern? Das ist nicht nötig. Aber mache es, wie Du willst. Du fragtest nach Best Practices und ignorierst dann die Antworten...

 

[NullDevice]

Aber warum willst Du verweigern? Das ist nicht nötig. Aber mache es, wie Du willst. Du fragtest nach Best Practices und ignorierst dann die Antworten...

Wieso, ich ignoriere die Antworten doch nicht. Zeig mir eine bessere Lösung. Knuddelbärs Antwort war die beste für meine Zwecke. Und deine Antworten ignoriere ich auch nicht, wir diskutieren ja.

Wieso ich verweigern will? Weil ich ihnen das Recht zum Schreiben nehmen will. Wie sonst könnte ich es machen? - Die Berechtigungen sind komplex und es gibt viele User und Gruppen. Ich könnte nur zu jedem einzelnen gehen, und dort das Schreibrecht raus nehmen. Was sehr viel Arbeit ist. Bzw auch schlecht ist, weil später unklar sein wird, wer bzw welche Gruppen vorher Schreibrechte hatte und welche nicht. Schliesslich muss man es ja nachher wieder zurückstellen.

Somit -> JEDER: Schreibrecht verweigern. Ist das nicht die einfachste Lösung? Bin für alles offen.

 

[Frightener]

Ich habe das gleiche geschrieben, wie Knuddelbär mit der Ergänzung, daß es nicht notwendig ist, zu VERWEIGERN, sondern daß es reicht, lediglich LESE
RECHTE zu vergeben. Dies allerdings über die SHARE-Berechtigungen, NICHT über NTFS-Berechtigungen. Bitte lese Dich an das Prinzip von Shares und NTFS Berechtigungen ein. Aus Deinen Aussagen lese ich, daß Du an den NTFS-Berechtigungen rumspielst. Auf dem Share konfiguriert man nach Best Practices KEINE zusätzlichen Security Groups, dies macht man bei den NTFS-Berechtigungen.

Von der Arbeit ist es egal, ob Du den Haken bei VERWEIGERN reinmachst, oder den Haken bei SCHREIBEN raus.Best Practices: KEIN Verweigern benutzen, wenn es auch anders geht.

 

[NullDevice]

Sorry aber das ist so nicht richtig, denn wenn du NUR für JEDER das Leserecht hinzufügst, können die User und Gruppen die explizit MEHR Rechte als das haben, trotzdem auch schreiben.
Kannst du ausprobieren, ist leider so.

Ergänzung:
OK ich verstehe, du meinst dass du zuerst alle anderen Rechte in der Freigabeberechtigung löscht, und dann JEDER hinzufügst mit Leserechten. Stimmts?
Das ist eine Möglichkeit. Jedoch muss man dann dazusagen, dass man ZUERST am Ziel-share, also am neuen, die Freigabeberechtigungen genauso einstellen muss, da sie ja dann bereits weg sind, wenn man es so macht. Sprich man kann sich daran hinterher nicht mehr errinnern wie es am alten share eingestellt war.

Aber es ist eine Möglichkeit, das stimmt. Hast du Recht