NilsK

Moin,

der sauberste Weg besteht eindeutig darin, sich mit den Kollegen über die Anforderungen abzustimmen und dann eine geeignete Lösung zu finden. Es muss ja nicht immer ein Logonskript sein - die meisten Skripts machen nichts, was man mit GPO, GPP usw. nicht hinbekäme.

Von der Manipulation des Anmeldevorgangs oder irgendwelchen Versuchen, die Ausführung von Logonskipts zu verhindern, würde ich jedenfalls abraten.

Gruß, Nils

Moin,

bei der gegebenen Komplexität und dem allgemeinen bzw. grundlegenden Bereich der Fragen ist ein Forum nicht mehr die geeignete Diskussionsplattform. Das ist eine Sache für intensives Consulting.

Ich klinke mich hier aus.

Gruß, Nils

Moin,

Aber in dem Fall würde doch bei Ausfall der WAN / VPN Verbindung der Server gar nichts mehr auflösen können?

jein. Für die beiden DNS-Server träfe das zu, aber auch nur für die. Alle Clients und die anderen Server in der Außenstelle würden ja die beiden lokalen DNS-Server fragen.

Wenn man also davon ausgeht, dass die WAN-Verbindung innerhalb der DNS-Cache-Lebensdauer wieder da ist, hat das Design seine Berechtigung.

Müsst ich dann als 3. DNS Server zumindest nicht ihn selber eintragen?

Dann könntest du gleich die bei faq-o-matic.net favorisierte Variante nutzen ("zweiter DNS ist lokal"), denn in dem Fall hättest du ja gerade nicht mehr das von Daniel angesprochene einheitliche Design über alle Server.

Die Clients an den Außenstellen bekommen aber dann schon den DNS Server des jeweiligen Standortes?!

Selbstverständlich. Sonst könnte man sich den lokalen Dienst ja auch ganz sparen ...

Gruß, Nils

Moin,

Ab wieviel Usern nehmt ihr denn einen eigenen DC für einen Standort.

:confused: du hast den Rest des Threads nicht besonders aufmerksam gelesen, oder? Hier ging es doch die ganze Zeit darum, dass es auf solche Fragen keine pauschale Antwort geben kann.

Sowas dauert dann doch alles ewig, und die Zugriffe ... oder täusche ich mich?!?!?!

Das hängt ganz davon ab, was und wie an den entfernten Standorten gearbeitet wird. Und selbst wenn es da einen lokalen Dateiserver usw. gibt, muss es noch lange keinen DC geben.

Ich werfe nur mal das Stichwort "Terminalserver" ein - in vielen Szenarien kann man dadurch komplett auf Server am Standort verzichten und im Effekt bleiben sogar sämtliche Daten in der Zentrale. Passt nicht überall, aber erstaunlich oft.

Gruß, Nils

Moin,

Genau so ist das bei 32Bit WinDOSen.

das hat mit Windows exakt gar nichts zu tun, dafür aber alles mit der 32-Bit-Plattform.

Gruß, Nils

Moin,

der beste Ansatz ist, eine zentralisierte Softwareverteilung zu nutzen oder für die Updates einen Dienst zu entwickeln, der die Updates mit den nötigen Rechten verteilt.

Übrigens ging "das" auch schon bei Windows XP nicht.

Gruß, Nils

Moin,

gut, dann können wir ja mal auf eine Sachebene zurückkehren ... :rolleyes:

Also: Es ist durchaus möglich, einen eigenen Exchange-Server bei einem externen Hoster zu betreiben. Das sind dann aber keine 08/15-Rootserver, weil die eine andere Positionierung im Markt haben. Ein Exchange-System ist für den Betrieb im LAN konzipiert, nicht wie ein Webserver für den Betrieb direkt "am Internet".

Da sehr wahrscheinlich für deinen Zweck der Betrieb eines sinnvoll aufgebauten Exchange-Systems durch einen externen Hoster viel zu teuer wäre, hast du i.W. zwei Möglichkeiten:

1. Du baust dir eine eigene Infrastruktur intern auf und nutzt dafür deine vorhandenen Lizenzen
   
2. Du nutzt Exchange (oder ein anderes System) komplett als externe Dienstleistung (Hosted Exchange), z.B. BPOS/Office365
   

Wenn es tatsächlich um 5 User geht, wird die zweite Variante bei weitem günstiger sein.

Gruß, Nils

Moin,

also, zusammengefasst: Du kennst dich mit RODCs nicht aus, du wirst dich in absehbarer Zeit nicht damit auskennen, du siehst keinen Grund dafür, du kennst Argumente dagegen und die Argumente dafür treffen bei dir nicht zu.

Was bliebe dann noch übrig? Und was soll überhaupt diese Diskussion, in der wir dir schon gesagt haben, dass wir keine endgültige Empfehlung aussprechen können?

Gruß, Nils

Moin,

gruppenrichtlinien.de:

ADM Templates - Administrative Vorlagen, Weiter unten mal einige Sample´s und Codebeispiele:

Gruß, Nils

Moin,

Accounts go in Global Groups nested in Domain Local Groups that are granted Permissions...

ja, eben.

Benutzer in Global; die in Lokal, die hat Zugriffsrechte. Passt doch ;-)

Es ist aber unsinnig, die Globalen Gruppen mit Domänenlokalen Gruppen zu verdoppeln. Mit den DL-Gruppen legst du Berechtigungsstufen bzw. Zugriffsrollen fest. Sonst hat das ganze ja keinen Sinn.

Aber die Migration und dann in UG Umwandlung löst ja nicht mein Problem..

Doch.

Funktioniert zwar ist aber so nicht wünschenswert sondern nur als Notlösung zu betrachten.

Da die ganze SIDHistory-Migration nur eine Notlösung für eine Übergangszeit ist, sehe ich grad dein Problem nicht.

Gruß, Nils

Moin,

und nochmal: Ein AD-Konto wird von einem DC gesperrt, nicht vom Client. Daher wirst du die Einträge auch nur auf den DCs finden. Dein ganzer Überwachungsansatz ist falsch.

Und auch nochmal: Eine Computerkonfiguration an ein Benutzerkonto zuzuweisen, bringt exakt überhaupt nichts.

Gruß, Nils

Moin,

deine Frage nach "besser" lässt sich so nicht beantworten. Das musst du schon selbst einschätzen.

Bei nur 10-15 Usern pro Standort würde ich allerdings schon eher von "gar kein DC" ausgehen, zumindest als Option mit einbeziehen.

Gruß, Nils

Moin,

abgesehen davon, dass das von Microsoft vorgesehene Gruppenkonzept etwas anders funktioniert ...

... würde ich als Workaround die DL-Gruppen einmalig in den Zielforest migrieren und dann in Universal Groups umwandeln. Mittelfristig solltet ihr dann die Berechtigungen auf Basis neuer Gruppen (und des richtig angewandten A-G-DL-P-Konzepts) neu zuweisen und die SIDHistory entfernen.

Vorher testen versteht sich von selbst.

Gruß, Nils

Moin,

Dann aber natürlich in einer gesonderten GPO, die an eine OU gelinkt wird, die nur meinen User-Account enthält.

ich weiß nicht, warum du das trotz Erläuterung nicht verstehst, aber: Das wird nicht gehen ...

Gruß, Nils

Moin,

die Berechtigungseinträge sind per ADSI/LDAP nicht einzusehen. Schau dir LIZA an:

faq-o-matic.net Liza: Berechtigungen in Active Directory analysieren

Gruß, Nils

Moin,

Maintaining and Monitoring Account Lockout

Troubleshooting Account Lockout

Account Lockout Tools

Im Security-Log solltest du nach den Event-IDs 529, 644, 675, 676 und 681 suchen. Wichtig: Die Kontensperrung siehst du auf den DCs, nicht auf deinen Clients!

Übrigens ist es keine gute Idee, einfach mal so für die ganze Domäne die Überwachung zu aktivieren. Informiere dich bei einem Anwalt, das ist juristisch relevant.

Gruß, Nils

Moin,

okay, gut, dass das geklärt ist. :wink2:

Und künftig bitte Groß- und Kleinschreibung nutzen, das erleichtert die Kommunikation.

Gruß, Nils

Moin,

es gibt kein Attribut "owner" im AD.

Gruß, Nils

Moin,

"full ack" - wobei auch die grundlegende Frage zu klären ist, ob die Standorte überhaupt lokale DCs brauchen.

Gruß, Nils

Moin,

du bist auf dem Holzweg. Was du suchst, ist ein normaler Dateiserver, der per SMB/CIFS arbeitet.

iSCSI ist nicht dafür da, damit Clients sich Dateien abholen. iSCSI ist eine SAN-Technik, mit der Server ihre lokalen Platten auf einem zentralen Storage-System anbinden, und zwar 1:1 (1 Server, 1 LUN, direkte exklusive Zuordnung).

Gruß, Nils

Moin,

du sprichst in Rätseln. Warum müssen mehrere Clients auf eine LUN zugreifen? Und wozu benötigst du ein "Cluster-Dateisystem"?

Gruß, Nils

Moin,

die Sperrung wird vielleicht nicht zu den protokollierten An- und Abmeldeereignissen gehören. Das weiß ich grad nicht aus dem Kopf.

Es kann aber auch einfach daran liegen: Dein GPO ist falsch verlinkt. Wenn Computerkonfigurationen wirken sollen, muss das GPO auf das Computerkonto wirken, nicht auf das Benutzerkonto.

Im Übrigen wäre es nett, wenn du die Groß- und Kleinschreibung verwendest, um deine Beiträge lesbar zu machen. Danke.

Gruß, Nils

Gruß, Nils

Moin,

rein technisch betrachtet, könntest du einfach mehrere unabhängige Migrationen derselben Quellgruppen in mehrere Zieldomänen ausführen, auch mit SIDHistory.

Die viel spannendere Frage ist, ob das sinnvoll wäre, und da habe ich spontan so meine Zweifel, aber um das konkret zu sagen, müsste man sich so weit mit der konkreten Umgebung beschäftigen, dass es in einem Forum nicht mehr sinnvoll zu leisten ist.

Gruß, Nils

Moin,

Load Balancing geht sehr wohl auch in der Standard Edition.

@Cossack: Terminalserver und VDI sind etwa so nah verwandt wie ein Motorboot und ein Motorrad. Neben den lizenzrechtlichen solltet ihr vor allem die technischen Fragen klären, und dafür müsst ihr eure Anforderungen genau definieren und die Möglichkeiten beider Techniken evaluieren.

Gruß, Nils

Moin,

bei dieser Fehler- und Strukturbeschreibung können wir dir nicht sinnvoll helfen. Beschreibe die bestehende Struktur, beschreibe, was ihr geändert habt und beschreibe, welche Fehler genau auftreten.

Vorab: Ein User muss nicht Owner seines Home-Ordners sein.

Gruß, Nils