kaineanung

Nein, denke ich nicht das mich das Überfordert. Ich mache das ja schon recht lange als Quereinsteiger von der Anwendungsentwicklung. Ich kenne nur die Begriffe nicht (ACL hätte ich als ein Template für Berechtigungsverwaltung einer beliebigen Struktur verstanden und dabei ist es so einfach..). Ich kenne mich auch in den'neuen Philosophien' nicht aus. Organigramm-Struktur ist das Einzige was ich kenne. Umsetzen sollte das aller kleinste Problem sein... Wir würden die AD-Gruppen so übernehmen wie sie bereits sind. Die T3, T3K1, TGL301 und T301 sind jeweils auch AD-Gruppen die jedoch flach vorliegen. Die User sind dann Mitglieder einer dieser Gruppen und die Dateiberechtigung auf dem Fileserver beinhaltet ausschliesslich die Gruppen und keine Benutzer.

Ok, also sind die ACL nicht irgendwo ein Zusatztool / Steuerungsdatei für die Rechte sondern das was wir alle auf em Fileserver sonst auch machen: Rechte Maustaste -> Kontextmenü -> Sicherheit Das nennt man ACL. Ich habe mir da ehrlich gesagt nie Gedenken gemacht wie das genannt wird. Jetzt weiß ich es ja... Danke euch Oh, ok, Stimmt ja. Das hatten wir in einem der vergangenen Thread so bereits erörtert. Wie war das nochmals? Mit dem ABE kann ich steuern das die Benutzer nur die Ordnerstruktur sieht auf denen er Berechtigung hat? Dann muss ich nicht manuell 'Ordner auflisten' Berechtigung entziehen sondern ABE macht das in etwa so: Benutzer hat keine Schreib-, Ändern- und Lesen-Berechtigung und somit darf er es auch nicht sehen?

Wir nennen es andersherum aber ja, so ist es. T301 und T302 sind Gruppen die zum gleichen Team (T3) gehören. Diesen Vorschlag werde ich jetzt auf einen Fileserver für das komplette Team3 abbilden (mit allen enthaltenen Gruppen) und werde dies nächste Woche meinem Vorgesetzten präsentieren damit er es dann bei den Chefs präsentieren kann. Dazu muss ich aber vorbereitet sein und daher frage ich einfach mal: 1. Die Benutzer bekommen deren Gruppe entsprechend dann den Gruppenordner (z.B. T301) gemappt. Das Management sieht auch den Mgmt-Ordner, die Anderen nur den Daten-Ordner. Oder mappe ich den Datenordner den Anderen direkt (somit sparen Sie sich immer einen Ordner (z.B. T301 Daten) zu öffnen) und nur dem Management den darüber liegenden Ordner (weil die ja in beide Ordner rein dürfen)? 2. Was sind ACLs genau ausser das sie Access Conrol List heissen? Ich meine wenn ich auf Dateiebene die Rechte vergebe ist das dann was genau? und wo sind dann die ACLs und wie nutze ich diese und wieso sind die 'genauer' als das 'normale' Vorgehen (Dateiebene->Kontextmenü->Sicherheit->Rechte vergeben)? 3. Was meinst du mit dem 'Management-Ordner Parallel anlegen'? Managementordner in jedem Gruppenordner und Teamordner als Unterordner anlegen? Kannst du mir sagen was da dann genau einfacher ist mit ACL ist? Dabei sind wir aber wieder bei Punkt 2. Was sind ACLs? 4. Was sind die Vorteile allgemein im Vergleich zu der Dateistruktur nach dem Organigram der Firma? Das wird mich der Vorgesetzte 1000% Fragen. Ich bin mir nicht sicher bis auf daß wenn sich Gruppen ändern (z.B. einem anderen Koordinator unterstellt werden) müssen wir nichts mehr auf Dateiebene machen sondern nur in der Rechteverwaltung. Das passiert aber nicht so oft und daher brauche ich mehr als nur diesen Vorteil... Ich wurde in der Vergangenheit hier ein paar mal darauf hingewiesen daß das verrückt ist was wir machen mit dem Firmen-Organigramm auf dem Dateiserver. Ich würde sehr gerne wissen was der Vorteil ist weg vom Organigramm zu gehen und wenn das geklärt ist sind wir bereit dies durchzuziehen. Ich muss es nur begründen können was die 99,9% der Firmen besser machen weil sie weg vom Organigramm sind und nur noch 2-3 Ebenen statt 5-6 (Rechte-) Ebenen haben. Wir haben einen Chef, einen Teamleiter pro Tem, darunter 0-n Koordinatoren pro Team, darunter einen Gruppenleiter und darunter die Gruppe. Alleine das sind schon 5 Rechteebenen... Ich denke da kann man sich bissl was einsparen. Will ich auch. Ich brauche nur Munition wie ich das begründen soll... Also, falls dir auch was einfällt: schiess los ;) Meinst du damit ein Dokumenten-Archivierungssystem? Wirst du sicherlich nicht meinen da dies unpraktikabel wäre. Problem ist: nicht alles sind Dokumente die da rumliegen. Dann müssen Sie auch schnell und einfach bearbeitbar sein (z.B. Excel). Das Dokumentensystem was wir benutzen ist teil unseres ERPs und dient nur dazu tatsächliche Dokumente zu speichern und zu archivieren. Ausserdem nutzen wir das was wir jetzt haben statt nochmals viel Geld für neue Systeme auszugeben die bei den meisten Usern dann auch sicherlich auf Ablehnung stößen würde... Aber Danke für neue Ideen!

@Dukel Danke für das bebilderte Erklären. Beugt dem 'aneinander vorbei sprechen' vor ;) Ich melde mich morgen wieder um deteilierter nachzuhaken. Aber vorab: dieses Konzept bietet keine Abgeschottete Verzeichnisse für die einzelnen Gruppen-Stänge als auch Hierarchien. Beispiel was ich mit 'Gruppen-Stränge' meine: Der Gruppenleiter der T301-Gruppe, also TGL301 nutzt den gleichen Ordner wie der Gruppenleiter der Gruppe T302, also TGL302. Beide nutzen den Ornder T3-Mgmt und können sich so gegenseitig ins Handwerk 'pfuschen'. Beispiel was ich mit Hierarchie meine: Der Teamleiter nutzt den gleichen Ordner wie seine Untergegeben Koordinatoren und deren Untergebene Gruppenleiter. Der Gruppenleiter kann Daten des Teamleiters einsehen und, manipulieren und löschen. Ist das so in dieser 'flachen' Organisation normal? Wo speichert der Teamleiter die Abmahnungen die er verteilt hat und die niemanden was angehen? Blödes Beispiel, aber eines von vielen die mehr oder weniger sinniger wären..

Ehrlich gesagt: ich weiß es nicht. Ich weiß was wir bisher haben. Ich weiß daß ich sowas in der Art wie du beschrieben hast (siehe meine Konzept 'Projektordner') angedacht habe. Ich habe meinen Vorgesetzten überzeugt das wir das ändern sollten. Jetzt will er daß ich ein Testserver aufstelle und nächste Woche ihm zeige. Dann kam noch der Satz 'ja so wie du es damals gemeint hast die ganzen Gruppenordner flach nebeneinander' -> er hat mich missverstanden aber ich habe mich daduch auch beirren lassen. Ich muss, und das ist mir wieder klar geworden, WEG von den Gruppenordner bis runter zu den einzelnen Gruppen. ABER: leichter gesagt als getan. Wir haben z.B. Gleitzeitkonten der Gruppen in einer automatisch befüllten Excel die in jeglichen Gruppen gleich heisst. Somit können die 1. nicht im gleichen Ordner sein und 2. soll nur der Gruppenleiter, sein Koordinator und der Teamleiter das einsehen können und kein anderer Koordinator oder Gruppenleiter -> das ist nur EIN Beispiel von vielen und das was mir als erstes eingefallen ist. Ich denke das wir diese Anforderung haben das es 'Granularer' ausfällt. Ich tapse aber gerade im Dunkeln wie das auszusehen hat ausser so wie wir es bisher hatten. Dein Konzept wäre also folgendes: Root | T3 <-- Einstieg aller T3x (Also T3 (Teamleiter), T3K1 (Koordinator), TGL301 (Gruppenleiter), T301 (Gruppe)). Und ALLE Tx-Gruppenmitglieder (T3, T3K1, TGL301 und T301 dürfen lesen, schreiben und ändern. |-- T3K1 <-- entfällt | | | TGL301 <-- entfällt | |-- T301  <-- entfällt | TGL302 <-- entfällt | |-- T302 <-- entfällt | |-- T3K2 <-- entfällt | | | TGL321 <-- entfällt | |-- T321 <-- entfällt | TGL323 <-- entfällt | |-- T323 <-- entfällt | |-- usw. T2 <-- Einstieg aller T3x (Also T3 (Teamleiter), T3K1 (Koordinator), TGL301 (Gruppenleiter), T301 (Gruppe)). Und ALLE Tx-Gruppenmitglieder (T3, T3K1, TGL301 und T301 dürfen lesen, schreiben und ändern. | |-- usw. usw. | Marketing <- Einstieg der Marketing-Gruppe (Also Gruppenleiter + Gruppe). Und ALLE MArketing-Gruppenmitglieder dürfen lesen, schreiben und ändern. | (Marketing ist jedoch eine Gruppe unter einer der Teams und hat ebenfalls einen Koordinator und somit wird es statt 'Marketing' eben ein T8 als Beispiel)

@Dukel Meinst du damit dann ich habe ein T3-Ordner für das ganze Team3 und jeder, egal ob T3 (Teamleiter), T3K1 (Koordinator), TGL301 (Gruppenleiter) oder T301 (Gruppenmitglieder) darf darin frei machen was er will? Dann sehen ja alle alles und dürfen alles drinn machen sofern sie alle den gleichen Teamleiter haben? Also so in etwa: Root | T3 <-- Einstieg aller Mitglieder in der T3-Gruppe (T3, T3K1, TGL301, T301->T3x-Gruppe), änderbar ebenfalls für alle T3x-Gruppenmitglieder. Alle anderen sehen den Ordnern nicht. |-- T3K1 | | | TGL301 | |-- T301 | TGL302 | |-- T302 | |-- T3K2 | | | TGL321 | |-- T321 | TGL323 | |-- T323 | |-- usw. T2 <-- Einstieg aller Mitglieder in der T2-Gruppe (T2, T2K1, TGL201, T201->T2x-Gruppe), änderbar ebenfalls für alle T2x-Gruppenmitglieder. Alle anderen sehen den Ordnern nicht. | |-- usw. T6 |-- usw. usw. | T5 Der Nachteil: jede Gruppe ist 'offen' für die nebenstehende Gruppe. Dateien können eingesehen werden und, was nocht schlimmeri st, können verändert oder gelöscht werden. Nein, das kann nicht der Sinn des ganzen sein. Oder? Oder meint ihr so das die Berechtigungen schon bestehen bleiben sollen und nur die Einstiegspunkte eben nicht in der entsprechenden Ebene sein soll sondern z.B. für alle T3x-Mitglieder in T3 und jeder darf nur Ordner auflisten ausser in seinem eigentlichen Ordner? Also in etwa so: Root | T3 <-- Einstieg aller T3x (Also T3 (Teamleiter), T3K1 (Koordinator), TGL301 (Gruppenleiter), T301 (Gruppe)). |-- T3K1 <-- Ordner (ohne Inhalte) sichtbar für ganze T3x-Gruppe, änderbar nur für T3 + T3K1. | | | TGL301 <-- Ordner (ohne Inhalte) sichtbar für ganze T3x-Gruppe, änderbar nur für T3 + T3K1 + TGL301. | |-- T301  <-- Ordner (ohne Inhalte) sichtbar für ganze T3x-Gruppe, änderbar für T3 + T3K1 + TGL301 + T301 (also alle T3x) | TGL302 | |-- T302 | |-- T3K2 | | | TGL321 | |-- T321 | TGL323 | |-- T323 | |-- usw. T2 <-- Einstieg aller T2x (Also T2 (Teamleiter), T2K1 (Koordinator), TGL201 (Gruppenleiter), T201 (Gruppe)). | |-- usw. T6 |-- usw. usw. | T5

Aber wie können die User dann auf diesen Ordner ein Laufwerk mappen? Um sich dann durch die Ordnerstruktur durchzuklicken, benötigen die ja mindestens Lesen bzw. Auflisten der Ordner, oder nicht? Wir haben bisher die Freigaben in jedem Ordner gehabt und je nachdem wer sich angemeldet hat wurde sein G-Laufwerk da direkt hingemappt. Das sah so aus (Einstieg -> Root des G-Laufwerks): Root | T3 <-- Einstieg der User in der AD-Gruppe T3 (Teamleiter) |-- T3K1 <-- Einstieg der User in der AD-Gruppe T3K1 (Koordinatoren) | | | TGL301 <-- Einstieg der User in der AD-Gruppe TGL301 (Gruppenleiter) | |-- T301 <-- Einstieg der User in der AD-Gruppe T301 (Gruppenmitglieder) | TGL302 | |-- T302 | |-- T3K2 | | | TGL321 | |-- T321 | TGL323 | |-- T323 | |-- usw. T2 | |-- usw. T6 |-- usw. usw. | T5 Hier im Board wurde mir früher gesagt das ich 1.) die Firma nicht nachbilden soll und max. 2-3 Eben 'runtergehen' soll und 2.) bekommt jeder User nicht sein Ordner gemappt sondern steigt wie jeder andere ganz oben ein und muss sich durchklicken bis zu seinem Ordner. Also in etwa so: Root <-- Einstieg aller User. Das Gruppenlaufwerk mit dem Laufwerksbuchstaben 'G' wird immer hierher gemappt. | T3 <-- Ordner (ohne Inhalte) sichtbar für ganze T3-Gruppe (T3, T3K1, TGL301, T301->T3x-Gruppe), änderbar nur für T3. Alle anderen sehen den Ordnern nicht. |-- T3K1 <-- Ordner (ohne Inhalte) sichtbar für ganze T3x-Gruppe, änderbar nur für T3 + T3K1. Alle anderen sehen den Ordnern nicht. | | | TGL301 <-- Ordner (ohne Inhalte) sichtbar für ganze T3x-Gruppe, änderbar nur für T3 + T3K1 + TGL301. Alle anderen sehen den Ordnern nicht. | |-- T301 <-- Ordner (ohne Inhalte) sichtbar für ganze T3x-Gruppe, änderbar nur für T3 + T3K1 + TGL301 + T301. Alle anderen sehen den Ordnern nicht. | TGL302 | |-- T302 | |-- T3K2 | | | TGL321 | |-- T321 | TGL323 | |-- T323 | |-- usw. T2 | |-- usw. T6 |-- usw. usw. | T5 Habe ich das richtig verstanden? Wenn ja: Root muss von jedem lesend zugegriffen werden können (Ordnerauflistung um sich zu seinem Zeug durchzuklicken). T3x-Gruppenmitglieder sollen Aber T2 und den Rest nicht sehen. Wie macht man das ausser manuell auf jeden Unterornder direkt unter Root das lesen-Recht zu entziehen? Und so nebenbei bemerkt: ist unsere bisherige Vorgehensweise nicht praktikabler? Ich suche auch gerade in den alten Beiträgen die Stellen an denen mir nahegelegt wurde daß mit den max. 2-3 Ebenen und Einstieg aller auf Root und mit irgendwelchen ACL (oder war es das mit dem ABE?) die Ordner zu verstecken vor denen die nicht zu diesem Gruppen-Strang gehören? Ich habe aber viele Themen eröffnet und manche sind irrelang. Kann dauern bis ich das finde...

Mist, ich sollte vielleicht nachdenken meine Gedanken, Wünsche und Aufgaben besser zu kommunizieren bzw. es zu lernen. Denn das was du gerade gesagt hast, davon bin ich schon immer ausgegangen! Ich hätte aber schwören können daß die Admins hier auch die Filestruktur meinten denn AD war bei mir nie so wirklich geplant in eine Struktur zu pressen. AD ist bei mir momentan absolut Flach (Computer sind im Computer-OU, Benutzer in der Benutzer-OU und das war es). Wenn ich die Zeit finde werde ich die betreffenden Beiträge finden und euch zeigen daß man mir nahegelegt hat max. 2 oder 3 Ebenen in der Ordnerstruktur haben sollte und alles lieber logisch organisieren und Zusammenführen auf dem FILESERVER. Und das ich ein ABE (Acces Based Enumerationmaun) oder ein ACL oder irgendwie sowas nutzen soll usw. usf.. Das kann ja gar nicht nur in der AD gemeint gewesen.... @All Denkt ihr alle also daß ich meine Ordnerstruktur, die sich nach dem Organigramm der Firma richtet, beibehalten soll? Was mache ich mit den Laufwerksmappings? Auch so beibehalten daß die User in ihrer 'Ebene' einsteigen oder in Root Einsteigen und sie nach unten druchklicken lasse? Dazu brauche ich dann das ABE damit sie auch nichtmal die anderen Ordner sehen auf die Sie kein Schreibzugriff haben oder so? Sonst wird es ja unübersichtlich für die. ODer wie macht man das dann genau sollte ich sie in Root einsteigen lassen?

Als "geheim" eingestuft sind z.B. Kalkulation, die Schemen und Zahlen dafür. Das betraf auch die Kalkulation der Küche und des Kiosk. Das sollen und dürfen wir nicht beeinflussen: Geheim ist das Mitarbeitergesprächsprotokoll, Die Produktionsstände, die Krankenlisten (falls das ein Gruppenleiter neben unserem ERP oder sonstwo führen sollte), Aufträge die die anderen Abteilungen nichts angehen, usw.. da kann vieles drinnen sein die andere nichts angeht ausser die direkten Vorgesetzten die dann auch Einblick haben. Wenn ich aber Gruppen habe die ihr eigenen Ordner haben, wie und wo packe ich den weg? Die brauchen ja ihren Ordner um Gruppenbelange dort abzuspeichern.. Was ist denn die Alternative? Viele hier reden von 'wart-und nutzbaren Strukturen' oder früher auch 'logisch gegliederte Strukturen'. Wenn das nicht das Firmen-Organigramm ist, was dann? Der Ansatz ist sicherlich so in etwa wie mit meinem 'Projektordner' die dann auch übergreifende Gruppenberechtigungen beinhalten kann. Aber wie mache ich das dann mit den Gruppenordnern? Denn nicht alles ist 'Projekt' und eine Entität.

1. Wenn es nichts mit der Unternehmensstruktur zu tun hatte, ja mit welcher Struktur denn dann? 2. Wenn auf Root die Freigabe ist, dann ist da die Lese-Berechtigung für alle. Wie hast du das dann gelöst das lesen in den Unterordnern nicht da war für alle sondern nur für die mit entsprechender AD-Gruppen-Mitgleidschaft? Macht man das dann mit Access Based Enumeration? Diese Technik verhindert das Lesen der Ordner obwohl Lese-Berechtigung für z.B. alle Domänen-Benutzer vorhanden ist? 3. Wieso sagen mir 80% der Administratoren auf diesem Board ich müsse weg vom Organigramm? Das sagen Sie mir schon sehr lange. Ich habe jetzt meinen Vorgesetzten bearbeitet und bearbeitet und stehe kurz vor dem Durchbruch und jetzt ist das alles gar nicht so? Das wäre jetzt fatal für mich denn ich werde nie wieder irgendwas durchsetzen können was die Filestruktur angeht wenn ich das jetzt nicht durchziehe.... Also die Frage nochmals an ALLE hier: WEG vom ORGANIGRAMM der Firma oder nicht? Wenn ja: was sind die Vorteile? Was meinst du mit EINEM Organigramm Ast nicht herumkommen? Ich habe ein Organigramm welches die Firmenhierarchie abbildet. Hier hieß es auch daß ihr alle nicht mehr als 2 Ebenen, max. 3 Ebenen nutzt im Fileserver 'nach unten'. Was für Organigramm ohne dieses 'Top-Down-Machtprinzip' gibt es denn sonst?

Hallo Leute, wir sollen gleich nach der Migration unserer Domäne von W2K3 auf W2K16 auch den Fileserver (welcher bisher auf dem DC lief) auf ein W2K16 bringen (dieser wird gleich als VMWare-VM erstellt). Der bisherige Fileserver hatte das Organigramm der Firma abgebildet und auf diesem Board wurde ich in dem Thema DC-Migration darauf hingewiesen daß man Organigramme niemals als OUs und nicht als Filestruktur abbilden solle. So, nun habe ich mir ein paar Gedanken darüber gemacht und soll in meinem Testnetz ein Server aufsetzen wie es richtig gehen sollte so daß dies mein Vorgesetzter seinen Chefs beim nächsten Meeting demonstrieren kann. Das war bisher so: Nehmen wir an wir hätten bisher diese Ordner: T3 = Ordner des Teamleiters des Team 3 T3K1 = Ordner des Koordinators (welchem mehrere Gruppen unterstehen) des Unterteams 1 TGL301 = Ordner der Gruppenleiters 301 T301 = Ordner der Gruppe 301 So, bisher waren diese Ordner wie die Struktur der Firma verschachtelt: T3 -> T3K1 -> TGL301 -> T301 Und in jeder Dateiebene ist die entsprechende Berechtigung mit Vererbung hinzugekommen so daß der Teamleiter T3 alle untergebenen Ordner sehen und ändern konnte, alle Koordinatoren (T3K1, T3K2, usw.) darunter Ihre Gruppenleiter-Ordner lesen und ändern konnten, alle Gruppenleiter (TGL301, TGL302 usw.) ihre Ordner und die darunterliegenden lesen und ändern kontnen und schliesslich die Gruppen (T301, T302, usw.) in Ihren Ordnern Dateien lesen und ändern konnten. Ich habe mir hier sagen lassen daß wir das logisch zusammenfassen sollen. Damit denke ich an 'Projektorientiert'. Wir brauchen aber nach wie vor die Ordner für alle Gruppen denn da sind dann Gleitzeitstände und sonstige Gruppenrelevante Dateien enthalten die nichts mit Projekten oder Aufgaben zu tun haben, Somit bleiben diese Ordner ja nach wie vor enthalten, dann aber eben Flach nebeneinander und mit entsprechend manuell festgelegten Berechtigungen statt die Vererbung zu nutzen. Also habe ich Ordner direkt unter 'Gruppenordner' angelegt die nebeneinander liegen (T3, T3K1, T3K2, TGL301, TGL302, T301, T302) und die Berechtigung gesetzt (T3 -> nur T3-AD-Gruppe, T3K1 -> T3- & T3K1-AD-Gruppe, T3K2 -> T3- & T3K2-AD-Gruppe, TGL301 -> T3- & T3K1- & TGL301-AD-Gruppe, T301 -> T3- & T3K1- & TGL301- & T301-AD-Gruppe) Natürlich habe ich auch einen Ordner neben 'Gruppenordner' erstellt in welchem dann Ordner bezüglich verschiedener Themen enthalten sind und die Berechtigungen nach Bedarf gesetzt werden. Dann kann das Team 2 mit der Gruppe TGL351 an einem Projekt arbeiten und sonstige Kreuzungen entstehen. Dieser Ornder heisst dann 'Projektordner' und ist der Rootordner. Dann gibt es noch ein 'Austauschordner' (wir nennen sie auch Müllhalde ;)) in dem jeder Änderungsberechtigung hat (dienst zum zwischenspeichern, austauschen und der Gleichen. Meine Ordnerstruktur der Gruppen sah also bisher in etwa so aus: Root | T3 |-- T3K1 | | | TGL301 | |-- T301 | TGL302 | |-- T302 | |-- T3K2 | | | TGL321 | |-- T321 | TGL323 | |-- T323 | |-- usw. T2 | |-- usw. T6 |-- usw. usw. | T5 Jetzt sieht sie so aus: Arbeitsgruppe (Root) | T3 | T3K1 | T3K2 | TGL301 | TGL302 | TGL321 | TGL323 | T301 | T302 | T321 | T323 | usw. Und das wesentliche ist jetzt in den Projektbezogenen Ordnern: Projektordner (root) | Produktgruppe 'Produktname' | Arbeitgruppe X | Projekt Y | Firmen-Ausflug | usw. So, dazu habe ich jetzt mehrere Fragen: 1. Ist das 'IN ETWA' so wie sich hier einige Administratoren vorstellen wenn sie meinen daß ich weg vom Organigramm der Firma gehen soll? Themenbezogen, Gruppenbezogen, Projektbezogen und einfach logisch zusammengefasst? 2. Der Root-Ordner, welcher dann JEDEM in der Domäne per GPP gemappt wird, muss ja mindestens 'Domänen-Benutzer' -> 'Lesen' haben. Die darunterliegenden Ordner aber natürlich nicht. Wie mache ich das am Besten dann? Immer daran denken jedem neu angelegten Ordner in der direkt darunter liegenden Ebene das 'Domänen-Benutzer' -> 'Lesen' entziehen oder gibt es da eine andere (einfachere bzw. sinnvollere) Vorgehensweise? Bisher war es ja so das die entsprechenden Ordner (T3 -> Root des Mitglieds der Gruppe T3,.. T301 -> Root des Mitgliedes T301, usw..) direkt gemappt wurden und sich diese Frage ja nie gestellt hat mit dem gemeinsam genutzten Root-Order 'darüber'? 3. Ich sehe ja den Vorteil bei der flachen Gruppenordnern wenn sich im Organigramm was ändert muss man nichts umbiegen (was eine harte Arbeit war) und man hat weniger arbeit. Aber man nutzt die Vererbung der Rechte nicht mehr und muss bei jedem Ordner manuell die Berechtigungen eintragen die wiederrum dem Organigramm entspricht. Wiegt das eine das andere nicht auf? Es muss doch noch mehr Vorteile geben, nur ich komme gerade nicht darauf. Kann mir das jemand noch ein wenig deutlicher erklären bitte? Ich hoffe ich bin nicht ganz auf dem Holzweg weil mein Vorgesetzter so ungefähr dieses Bild von mir erklärt bekommen hat und er ist bereit das wir das so umsetzen und wirklich wegkommen vom Organigramm (Was ich bisher für unmöglich hielt daß wir das jemals machen würden). Ich danke euch allen schon einmal jetzt für das sicherlich nicht ganz einfache lesen meiner Frage bis hierher und eurer Mühe!

Das ist sehr schade. Ist die Migration kompliziert oder schafft man das an einem Arbeitstag incl. Aufsetzen eines W2K16 Servers auf einer VM und der Gleichen?

Funktioniert das alles auch auf einem W2K3 Server? Ich habe wenig Lust jetzt auch den noch umziehen zu müssen da ich ja gerade mitten in den Vorbereitungen für die Domänenmigration bin und anschliessend Fileserver-Migration und erst dann kommeich zu anderen Dingen... Wenn ich was Neueres benötigen müsste: wie migriere ich das am besten?

Hallo Leute, heute habe ich mal eine weniger kompliziertes Anliegen (hoffe ich): wir setzen schon seit Jahren einen KMS-Server für unsere Office-Produkte ein. Wir haben viele Office 2010 Standard-Lizenzen und einige Office 2010 ProfessionalPlus-Versionen. Die Aktivierung der Produkte funktioniert seit Jahren auch tadellos und innerhalb von 180 Tagen muss diese Aktivierung erneuert werden. Was mich damals ein wenig gestört hatte, war daß der KMS-Server ohne jegliche Verwaltungs-Oberfläche auskommt. Man kann in der CMD zwar ein paar Befehle eingeben die aber nichtssagen sind (z.B. die Anzahl der verfügbaren oder vergebenen Lizenzen, welche aber nur bis 5 (!!!!) anzeigt und der Rest unter den Tisch fällt. Somit weiß ich ja nie wie viele Lizenzen wir verbraten haben, wieviele noch frei sind. Wie viele Standard und wieviele PP-Versionen aktuell eingesetzt werden. Auch habe ich keine Möglichkeit Lizenzen wieder zu entziehen, was bisher aber auch nie notwendig war da wir genügend Lizenzen hatten daß wir auch die 180 Tage überbrücken konnten bis wieder eine frei geworden ist von einer nicht mehr genutzten Installation. Wir stellen aber immer wieder Leute ein die 'aufgebaut' werden und ich befürchte das wir bald eben nicht mehr 'überbrücken' können sondern 'haushalten' werden müssen. Also kurz und bündig: Gibt es mittlerweile Tool von MS die mir den KMS-Server visualisieren können und mir eine Oberfläche bietet in welcher ich genau sehen kann wie viele Lizenzen in Nutzung sind, wei viele frei sind und Aktivierungen verwalten kann (z.B. Lizenzen den Clients entziehen)? Gestattet mir bitte noch eine Nebenfrage zum gleichen Thema: wir haben Aussendienstler die mitterweile nicht mindestens einmal in 180 Tagen im Hause sind und somit die Aktivierung nicht verlängert werden kann (passiert ja automatisch beim Start von Office im LAN). Wir nutzen natürlich ein VPN (globalprotect von paloalto) und da würde ich gerne fragen welche Ports ich denn freigeben müsste und was ich noch beachten müsste damit sich die Office-Installationen unserer ADler aus der Ferne 'reaktivieren' könnten?

Metadata Cleanup habe ich noch nie gemacht und daher suche ich einfache Lösungen. VMWare-Snapshot ist ein Klick und ab da kann ich zu diesem Zeitpunkt zurückspringen und jedes einzelne Bit so wiederherstellen wie es zu diesem Zeitpunkt war. Daher ist das ganz praktisch um wirklich 100% alle Rückgängig zu machen. Voraussetzung ist aber: ich halte mein ganzes Netzwerk bzw. die Domäne an. Ich fahre sicherheitshalber die DCs herunter. Da ist dann auch nichts mehr mit 'zwischenzeitlich geänderten Computerkennwörtern'. Denn die Migration MUSS an diesem einen Wochenende über die Bühne gebracht werden und da sind keine anderen Nutzer zu Gange ausser wir Administratoren und da sollte es zwischenzeitlich keinerlei Änderungen an der AD geben. Keine User ändern Passwörter und der Gleichen. Und was die DNS-Server angeht: klar kann ich die DNS-Zonendateien manuell wegkopieren / sichern. Das werde ich Sicherheitshalber auch machen für alle Fälle. Ein Bind-Server ist schenll aufgesetzt und die Konfigurationsdateien sind bereits gesichert. ABER: was spricht gegen einen einfachen Klick auf 'Snapshot erstellen'? Ist doch einfacher... danach 'Snapshot löschen' und gut ist und im Worst-Case 'Snaptsho wierderherstellen'. Wichtig ist nur die Synchronität -> entweder alle DCs und DNS-Server oder keiner wird wiederhergestellt. b***d ist nur: der DC auf W2K3 läuft nativ und da muss ich mir halt anders helfen: Statt Snapshot eben ein Image fahren. Die Frage ist nur: übersehe ich da etwas? Könnte das klappen oder kann es vielleicht sogar gar nicht klappen? Was ist eigentlich ein 'USN Rollback'? Und welche Computerkennwörter meinst du mit den 'zwischenzeitlichen geänderten Computerkennwörter'? Du meinst Userkennwörtern, oder? Wenn keine User da sind dann ist diesbezüglich keine Grund zur Sorge da, oder? Wenn du Computerkennwörter meinst (was auch immer das dann sein soll): wer ändert die, warum und wo? Ist doch bestimmt Benutzerkennwörter welche du meinst, richtig? Da informieren wir alle Homeoffice-USer, alle Aussendienstler und eben alle das an dem WE keiner Arbeiten soll und sich nicht einwählen soll. Dann fahren wir die Kisten runter und stellen so sicher das keiner angemeldet ist. Dann ist nichts mehr mit ändern... und wenn doch und wir müssen im WorstCase zurückspringen -> dann ändert der User es später eben noch einmal wenn uns einer durch die Lappen gegangen ist...

Hallo Leute, ich hatte ja vor unsere Domäne aus dem Steinzeitalter (W2K3) in die Neuzeit (W2K16) zu bringen. Dafür entwickle ich schon recht lange eine Strategie und mache mir ToDo-Listen und Wikieinträge mit Vorgehensweisen, Befehlen und der Gleichen. Ein Punkt davon war: Domäne sichern um im Falle einer mißlungenen Migration zurückspringen zu können. Das war auch recht einfach da wir nur 1x DC (ohne DNS) haben und 2x separate DNS-Server im Netzwerk betreiben. Das sind sozusagen die 'neuralgische Punkte' und wenn man die gesichert hat, kann ja eigentlich nichts schief gehen weil man ja jederzeit zurückspringen kann. Richtig? Mein Plan war: das Netzwerk wird heruntergefahren, alle Clients abgeschaltet (was an den Wochenenden sowieso der Fall ist) und dann kann ich von dem einzigen DC ein Image erstellen (Nur von der C-Platte da auf der D-Platte Daten des Fileservers liegen (DC ist auch Fileserver den ich in diesem Zuge dann auch trenne)) und die DNS-Server per Snapshot (sind beide auf unterschiedlichen VMWare-Servern -> Snapshot ist die einfachste Lösung) sichern. Ich habe eine Testumgebung in einem eigenen (VMWare-) Testnetz erstellt und dort geübt (Mit W2K16 Evaluation-Installation die ich alle 2 Wochen erneuern muss und von Installation zu Installation migriert habe). Am Montag früh ist mir was blödes passiert: ich habe den falschen Netzadapter angegeben (also nicht den des virtuellen Netzwerkes sondern des echten physikalischen Netzwerkes) und da ich in dem virtuellen Netz die Domäne 1:1 abgebildet habe, habe ich erst spät bemerkt daß ich jetzt einen 2. DC in der Produktivumgebung erstellt habe (Rollen wurden aber noch nicht übertragen). Ist ja nicht schlimm, ABER: wie sieht die Sicherung der Domäne nun aus? Ich habe ein 'neuralgischen Punkt' mehr. Kann ich das jetzt noch überhaupt sichern um wieder zurückspringen zu können? Ich will kein demote durchführen, ja nicht einmal die FSMO-Rollen übertragen oder gar von FRS nach DFSR konvertieren bevor ich nicht sichergestellt habe das ich 'safe' bin und im Worts-Case-Szenario wieder am gleichen WE vor dem Montag wieder zurückspringen kann. Meine angedachte Vorgehensweise: 1. Alle Clients herunterfahren (Am Wochenende ist das der Normalfall) und alle zwei DCs herunterfahren (1x W2K3 und 1x W2K16). 1. DC (W2K3 mit Acronis oder CloneZilla ein Image erstellen von der C-Platte wo auch das FSR / SYSVOL ist.) 2. Snapshots von neuem DCs (W2K16) erstellen 3. Snapshots von beiden DNS-Servern erstellen (ebenfalls VMWare) 4. Alle DCs wieder starten und dann FSMO-Rollen übertragen, 1. DC (W2K3) demoten, Gesamtstruktur und Domänenstruktur anheben auf W2K16, FRS nach DFSR konvertieren, GPOs einspielen und alles testen. 5. Aufräumen (Snapshots entfernen) P.S. wir wollen es gleich richtig machen und haben eigentlich 2x neue DC (W2K16) nur das der 2. eben noch nicht in der Produktivumgebung promotet wurde. Meint ihr das es auch nichts mehr ausmacht den jetzt vorab zu promoten und die Sicherung wie oben beschrieben zu machen nur daß eben dieser DC dann noch zusätzlich auch gesichert werden muss? Beide neuen DC laufen auf VMWare (physikalisch und verwaltungstechnisch komplett getrennt) und können mit einem Snapshot leicht gesichert werden.

Also in meinem Fall nur 'HBA' (Die Sicherheitsgruppe als String eben), oder? P.S. wo finde ich so eine LOG-Datei wie du sie gepostet hast? Wenn ich in der gpsvc.log unter C:\Windows\debug\usermode\ suche finde ich das so nicht? Die gpsvc.log ist natürlich vorhanden nachdem ich das in der Registry aktiviert habe ([HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPsvcDebugLevel"=dword:00030002)

Also irgendwie mache ich was falsch... Nehme ich diese 'Variable' dann funktioniert es weder in der Quell-Domäne noch in der Ziel-Domäne. In beiden Domänen steht dann auch brav diese %DomainName% (oder eben %LogonDomain%), aber diese Regel 'greift' gar nicht. Die Sicherheitsgruppe wird nicht erkannt. Ich habe ein Test gemacht: Ich habe eine Test-GPO in der nur eine Sache eingestellt ist: Eine Verknüpfung auf dem Desktop (der User-Desktop) zu C:\Windows\notepad.exe erstellen. Wähle ich in der Zielgruppenadressierung das Element 'Sicherheitsgruppe' und über den Picker die Gruppe 'HBA', dann funktioniert es mit meinem U_Txxx-User (so ist der Username des Testusers) welcher Mitglied der Sicherheitsgruppe 'HBA' ist. Es wird also eine Verknüpfung zum Notepad auf dem Desktop erstellt. Mache ich das wie von euch erklärt mit den Variablen, und ich damit meine ich beide Varianten, also %LogonDomain% und %DomainName%, funktioniert es nicht. %DomainName%\HBA oder %LogonDomain%\HBA werden so nicht aufgelöst und greifen nicht. Die Test-GPO habe ich so natürlich nicht einmal in eine andere Domäne übertragen um zu sehen ob es auch dort läuft (was ja meine Intention ist) da es ja bereits von vornherein nicht funktioniert. An was könnte das liegen? Ich glaube euch ja das %DomainName% bei euch funktioniert. MS hätte es ja auch nicht implementiert an dieser Stelle würde es nicht funktionieren. Bei mir funktioniert es aber leider nicht. An anderer Stelle, z.B. wenn ich den Verknüpfungsnamen variabel gestalten möchte nur um zu sehen ob %DomainName% dort aufgelöst wird, so bekomme ich das zu erwartende Ergebnis. Der Verknüpfungsname beinhaltet dann tatsächlich den Domänen-Namen.

Ich hätte es einfach einmal ausprobieren sollen und dieser Teil meiner Frage wäre beantwortet gewesen. Egal wo ich es erstelle, es wird natürlich syncrhon in beiden Tools angezeigt. Somit hast du selbstverständlich Recht. Ja, das habe ich auch vermutet. Nur was soll es dann abbilden? Reicht dann eine 'Benutzer'- und 'Server'- und 'Desktop'-OU? Vielleicht noch eine Aussendienst-OU bzw. Notebook-OU? Wäre das eine OU-Aufteilung die man im Schnitt und so in etwa in der weiten Welt der Domänen vorfindet? Ich habe das ja schon richtig verstanden das die übergeordneten OUs ihre verknüpften GPOs nach unten vererben, richtig? (Ausser man kann die Vererbung deaktivieren, was man ja dann bewusst machen würde)?

Hallo Leute, da wir bisher mit der AD relativ wenig zu tun hatten und mit GPOs fast gar nichts (ausser die Kennwortrichtlinie in W2K3 in der Default Domain Policy), stehe ich vor der Frage ob man OUs benötigt, wie die am besten aufgebaut sind und vor allem ob ich diese in der AD oder in dem Gruppenrichtlininen.Editor (da kann man ja auch OUs erstellen)? Ich habe die auf gruppenrichtlininen.de die Anleitung 'Erstellen einer Gruppenrichtlinie' gerade angefangen zu lesen und dort steht man soll als allererstes OUs erstellen (Meine Benutzer und Meine Computer). So wie ich das lese, wird dort von der AD geredet, als Bildbeispiel ist aber der Gruppenrichtlinien-Editor zu sehen. Das ist aber nicht das Selbe, oder? Und wenn es das nicht ist: was ist der Unterschied und wo soll man es anlegen? Die andere Frage ist: wie soll ich die Struktur am besten anlegen? Firmenhierarchie (Abteilungen -> Teams -> Gruppen -> Untergruppen), erscheint mir zu komplex und viel zu viele Ebenen. Ändert sich eine Gruppe (und das passiert relativ häufig) muss man wieder umkrempeln. Reicht es da grob einzuteilen Benutzer, Server, Desktops, Aussendienst u.ä.? Ich habe jetzt GPOs erstellt die alle betreffen und jeweils für unsere Abteilungen. Diese werden per Sicherheitsfilter selektiert, also über die Gruppenzuordnung angewandt. In der gpresult sehe ich alledrings dann in einem Abschnitt viele GPOs die nicht angewandt werden. Mich stört das jetzt nicht, aber ich denke das machen die Administratoren in der weiten Welt wahrscheinlich nicht so, oder? Ich würde mich freuen wenn jemand mal sein Aufbau der OUs erklären / zeigen könnte damit ich eine Orientierung habe wie das gemacht werden sollte.

Gibt es denn die Variable %LogonDomain% in der Commandline, wenn Du ein SET [ENTER] eingibst? Woher hast Du die Variable? Wenn ich im Feld 'Gruppe' der Zielgruppenadressierung bin und F3 drücke, werden alle Variablen aufgelistet. U.a. eben diese %LogonDomain% und eben auch genauso wie die zwei Vorposter es auch erwähnt hatten. In der Zielgruppenadressierung sieht es dann wie folgt aus: Benutzer ist Mitglied der Sicherheitsgruppe "%LogonDomain%\HBA" Und das es diese Variable gibt und die auch in den GPOs 'gültig' ist und aufgelöst wird, habe ich getestet indem ich statt eines fixen Namen für diesen Link diese %LogonDomain%-Variable benutze. Der Link wird dann mit dem Domänennamen erstellt wenn ich die Ziegruppenadressierung weglasse oder mit dem Picker die HBA-Gruppe auswähle (und somit die SID dann auch angezeigt und fest hinterlegt wird). Das habei ch nur gemacht um einmalig zu sehen ob die GPO diese Variable überhaupt kennt. Und ja, das tut sie, zumindest in diesem Zusammenhang.. In der Ziegruppenadressierung greift dies so jedoch nicht.. :(

Leider funktioniert das mit den Variablen nicht. Ich habe jetzt eine TEST-GPO erstellt in der folgendes (nur zum Testen) eingestellt ist: Benutzerkonfiguration\Einstellungen\Windows-Einstellungen\Verknüpfungen Reiter 'Allgemein': Verknüpfung hinzufügen Aktion: Aktualisieren Name: Test-Link Zieltyp: Dateisystemobjekt Speicherort: Desktop Zielpfad: C:\Windows\notepad.exe Starten in: C:\Windows Tastenkombination: Keine Ausführen: Normales Fenster Reiter 'Gemeinsame Optionen': - Haken bei 'Im Sicherheitskontext des angemeldeten Benutzers ausführen (Benutzerrichtlinienoption) - Haken bei 'Zielgruppenadressierung auf Elementebene' Zielgruppenadressierung: %LogonDomain%\HBA (HBA ist eine Sicherheitsgruppe in der Domäne) So, wenn ich das jetzt teste (schon in der ursprünglichen Domäne ohne es erst noch zu migrieren) wird KEINE Notepad-Verknüpfung auf dem Desktop erstellt. Benutze ich den Picker und picke mir die Gruppe 'HBA' aus, so wird die Verknüpfung erstellt. Somit ist klar: irgendwas läuft schief. Hilfeee?

Ok, wenn ich jetzt 100 Gruppenzieladressierungen habe, muss ich bei jedem einzelnen das nachholen bzw. den fixen Wert 'Domäne/Gruppe' durch das o.g. ersetzen? Da gibt es nicht zufällig eine Vorgehensart dies auf Dateiebene in der Sicherung der GPOs zu ersetzen? ISt ja XML... Aber ich würde es auch überleben jede einzelne manuell zu ändern... Fragen kann ja mal trotzdem ;) Jedenfalls: VIELEN DANK EUCH ALLEN ;)

Ich verstehe aber leider nicht was ich da dann eingeben soll? Wir haben eine Gruppe die T0 heisst. Es gibt eine Sicherheitsgruppe auf dem AD die 'T0' heisst. Wenn sich ein User, nehmen wir mal an der Max, sich einloggt, dann soll auf dem Desktop irgendeine Verknüpfung erstellt werden die nur die User der Gruppe 'T0' bekommen. Alle Anderen nicht. Ist der User nicht in 'T0', so wird die Verknüpfung, sofern Sie denn auf dem Desktop vorhanden ist, gelöscht. So, wie kann ich jetzt eine Zielgruppenadressierung realisieren wenn ich nicht konkret sage das die Gruppenmitgliedschaft in der AD-Sicherheisgruppe 'T0' vorhanden sein muss?

Jep, Parameter ist " /MigrationTable:Pfad\Dateiname.migtable" Jetzt habe ich das so gemacht und trotzdem enthält die Testumgebung die SID der Quelle wenn ich in die GPOs reinschaue! Somit machei ch irgendwas falsch. Daher die nächste Frage: Wie erstelle ich korrekt eine Migrationtable? Übrigens hattest du Recht mit den Sicherheitsfilter: diese gehen wohl auf den Namen und nicht SID und funktionieren dementsprechend korrekt. Ich nutze aber auch häufig Zielgruppenadressierung und benötige also die korrekte Auflösung "alte SID = neue SID".