NilsK

Moin, meine Pauschalempfehlung lautet: Keine Partitionen, nirgends. Wenn man davon abweichen will, muss es gute Gründe dafür geben (siehe lefg). Ich sehe zu oft vollgelaufene Partitionen neben leeren auf derselben Disk - und die wichtigen sind dann natürlich die vollen. Gruß, Nils

Moin, das Konstrukt wird nicht zuverlässig funktionieren. RAID richtet man normalerweise direkt auf dem Storage ein, unterhalb der Zugriffsebene. Bei einem Netzwerkspeicher kann zu viel schiefgehen, als dass man ein Software-RAID obendrüber legen könnte. Bestenfalls wird das unter Laborbedingungen gehen, aber nicht als Lösung, auf die man sich verlassen kann. Also solltest du einen anderen Ansatz wählen, z.B. eine klassische Kopiersicherung. Gruß, Nils

Moin, ich empfehle eine Kombination aus GPMC und José: José zeigt dir, welche GPOs wo verbunden sind und der GPMC-Report, welche Einstellungen dort gesetzt sind. Um alle GPOs zu dokumentieren, bringt die GPMC ein PowerShell-Skript mit (Get-GPOReport) bzw. als Download ein VBS-Skript (GetReportsForAllGPOs.wsf). faq-o-matic.net » AD-Dokumentation: José 3.2 ist da Gruß, Nils

Moin, wenn es nur um Testbetrieb geht, ist es eigentlich egal. Anderenfalls ist das natürlich eine grundsätzliche Designfrage. faq-o-matic.net » Welcher Name ist der beste für eine AD-Domäne? Da du von "betreiben" sprichst: Dir ist bewusst, dass du für jeglichen produktiven Betrieb (also auch als "privater" Mailserver usw.) die Produkte lizenzieren musst und Eval- bzw. MSDN-Lizenzen dafür nicht ausreichen? Gruß, Nils

Moin, Windows 2012 gibt es nicht als Enterprise. Für das, was du vorhast, reicht Standard. Wenn es ein Testsystem sein soll, würde ich mindestens 24 GB RAM in den Server stecken: DC 2 GB, Exchange mindestens 8 GB (besser 12), SQL mindestens 4 GB (besser 8), Rest für den Host freilassen. CPU ist heutzutage eigentlich nie der Engpass, schon gar nicht bei einem Testsystem. Die VMs auf zwei NICs zu verteilen, ist bei einem Testsystem unnötig. Plattenplatz: Plane mindestens 50 GB für das OS ein, zuzüglich das, was du an Daten ablegen willst. Ob und wie du das auf mehrere VHDs aufteilst, musst du dir selbst überlegen. VHDs nicht partitionieren, sondern bei Bedarf mehrere anlegen. Gruß, Nils

Moin, bleib mal auf dem Teppich. Gruß, Nils

Moin, korrekt. Einen DC würde ich NIE, NIE, NIE auf dem Image-Level sichern. Systemstate Backup ist hier das Zauberwort. Und für einen Fileserver reichen simple Dateikopien im Zweifel aus. Gruß, Nils

Moin, ah, OK, das hatte ich vorher nicht verstanden. :D gut ausgedrückt. Sozusagen das Standardproblem des Backup - sichern können alle, rücksichern fast niemand. Ich sage dazu immer: Backup braucht kein Mensch. Recovery ist die Kunst! Müssen die VMs denn überhaupt als VM gesichert werden? Reicht eine Sicherung der Applikationen bzw. der Daten mit Bordmitteln oder per Agent nicht aus? Gruß, Nils

Moin, falsche Fährte: Sie werden eben nicht gesammelt. Der TO versucht hier die (erwartbare) Rückfrage zu beantworten, ob alle Systeme so funktionieren, wie es gewünscht ist, wenn der Windows-Server nicht im Spiel ist. Das wird ja oft als Beispiel genannt, wenn es um die CAL-Pflicht geht. Gruß, Nils

Moin, dazu brauche ich keinen Link - dazu muss man nur mal überlegen, was "Replikation mit einem korrupten Replikationspartner zulassen" bedeutet. Wer mag, kann sich dazu auch noch meinen Vortrag "Tu mir das nicht an, sagte der Domänencontroller" als Video ansehen. Bessere Vorgehensweisen wurden in diesem Thread bereits benannt, das müssen wir nicht wiederholen. Gruß, Nils

Moin, diese zwei Dinge passen nicht zusammen. Entweder die Umgebung ist so kritisch, dass sie einen Cluster braucht - dann braucht sie auch ein ordentliches Recovery-System. Oder sie ist unwichtig, dann braucht sie auch keinen Cluster. Ganz abgesehen davon, gibt es auch in einer virtualisierten Umgebung keine einfachen Backup-Techniken à la "One size fits all" - der konkrete Aufbau orientiert sich an der konkreten Umgebung. In der Realität sehe ich bei Kunden mit anspruchsvolleren Umgebungen immer eine Mischung aus verschiedenen Techniken. Gruß, Nils

Moin, wenn es eine größere Umgebung ist und du mit einer ordentlichen Vorplanung beginnen willst, ist dies hier evtl. was für dich: .: www.kaczenski.de :. » ITA 10/2012: Der Plan macht den Unterschied Der technische Vorgang als solcher ist von meinem Vorredner schon hinreichend beschrieben worden. Gruß, Nils

Moin, genau deshalb nutzen die Clients ja eben nicht den DNS des ISP und auch keinen DHCP-Server, der nicht die Daten der Domäne verteilt. faq-o-matic.net » Was muss ich beim DNS für Active Directory beachten? (Reloaded) Gruß, Nils

Moin, wenn deine detaillierte Abwägung der Folgen und Risiken ergibt, dass dies ein gangbarer Weg ist, kannst du das tun. Wenn es hingegen nur darum geht, dir Arbeit zu ersparen: Nein, lass es. Gruß, Nils PS. Übrigens solltest du bitte für neue Probleme eigene Threads erzeugen, auch wenn sie scheinbar sehr ähnlich sind. Das Board warnt nicht umsonst beim Fortsetzen uralter Diskussionen.

Moin, dem Konzept nach vergibst du Berechtigungen immer nur an gezielt dafür angelegte DL-Gruppen. In einem Multi-Domain-Forest legst du dann in jeder Domäne G-Gruppen an, in denen du die User nach organisatorischen Kriterien zusammenfasst. Danach hast du zwei Möglichkeiten: du nimmst die G-Gruppen aus den verschiedenen Domänen direkt in die DL-Gruppe auf, die die Berechtigungen hat du nimmst die G-Gruppen in eine U-Gruppe auf, die nur dazu dient, alle G-Gruppen zusammenzufassen. Diese U-Gruppe nimmst du dann in die DL-Gruppe auf Vorteil von 1. ist, dass du eine Ebene einsparst - vor allem dann, wenn dieselben G-Gruppen nur einmal berechtigt werden sollen. Sollen hingegen die G-Gruppen auf mehrere Ressourcen Berechtigungen bekommen, ist 2. attraktiver, weil du dann die G-Gruppen nur einmal zu einer U-Gruppe zusammenfasst und diese U-Gruppe dann in die verschiedenen DL-Gruppen einfügst, die die Berechtigungen erhalten. Du kannst es natürlich auch ganz anders machen, aber gerade in einer größeren Umgebung stößt du damit schnell an Grenzen. Die zusätzliche Planung für ein strukturiertes Modell lohnt sich auf längere Sicht meist durchaus. Gruß, Nils

Moin, um Berechtigungen für eine Ressource zu vergeben, die sich innerhalb einer Domäne befindet, sind DL-Gruppen am besten geeignet. Für Ressourcen, die sich über mehrere Domänen verteilen, sind U-Gruppen am besten. G-Gruppen dienen dann nur der logisch-organisatorischen Gruppierung, also alle Franzosen, alle Engländer, der Vertrieb aus Merchweiler usw. faq-o-matic.net » Windows-Gruppen richtig nutzen Gruß, Nils

Moin, ich fürchte, du stellst dir das zu naiv vor. Skalierung "in der Cloud" lässt sich nicht einfach mit zwei Servern und irgendeiner Anwendung darauf simulieren. Dazu gehören komplexe Techniken. Vor allem brauchst du irgendeine Instanz, die die Anfragen auf die beteiligten Instanzen verteilt - im Fall "automatischer" Skalierung also quasi ein dynamisches Load Balancing. Das macht kein System von selbst. Dahinter benötigst du dann eine Applikation, die eine solche Verteilung überhaupt zulässt. Das geht auch nicht mit beliebigen Serverdiensten. Und, und, und ... Gruß, Nils

Moin, faq-o-matic.net » Windows-Gruppen richtig nutzen zu 1.: Hier funkt dir die UAC dazwischen. Zur Berechtigungsverwaltung auf einem Windows-Dateiserver sollte man den Explorer nicht nehmen, sondern ein Tool, das mit UAC umgehen kann. Beispiele: Total Commander, SetACL Studio. faq-o-matic.net » Benutzerkontensteuerung (UAC) richtig einsetzen zu 2.: Die Gruppe Builtin\Administratoren kannst du nur auf einem DC auswählen, weil es eine lokale Gruppe der Domänencontroller ist. Auf anderen Rechnern kannst du die dortige lokale Administratoren-Gruppe nehmen (wenn benötigt), die lokal und nicht im AD gespeichert ist. zu 5.: Ja, da gibt es eine Reihe von kommerziellen Tools, z.B. Security Explorer von ScriptLogic (jetzt bei Quest). Gruß, Nils

Moin, wenn die Zeit noch reicht, in der nächsten Woche ist der letzte Termin der heise-Roadshow zu dem Themenkomplex (in Köln, 28. November): heise Netze Tour 2012 Gruß, Nils

Moin, das Feld AccountExpirationDate taucht in deiner LDAP-Abfrage ja auch nicht auf, dann kannst du es natürlich auch nicht als Spalte im Resultset ansprechen. Aber warum baust du dir einen CSV-Export selbst und nutzt nicht csvde.exe? Gruß, Nils

Moin, du meinst, weil Microsoft dieses Geheimnis vorher so gut gehütet hat? ROTFLBTC ... Gruß, Nils

Moin, um noch ein letztes Mal darauf zurückzukommen: Das ganze Konzept ist nicht stimmig. Du hebst deine mühsam aufgebaute Netztrennung auf, wenn alle Server in jedem Netz hängen (oder auch wenn nur ein Server in jedem Netz hängt, auf den die User draufkommen). Du hast immer noch nicht beantwortet, warum die Clients netzweise getrennt sein sollen, wenn sie gleichzeitig dieselben Ressourcen nutzen dürfen. Da das Problem üblicherweise die Ressourcen sind, erschließt sich mir der ganze Ansatz nicht. Um die Clients voneinander zu trennen, reicht die Windows-Firewall üblicherweise völlig aus. Abgesehen davon, nützt reine Netzwerk-Aufteilung auch nichts, wenn keine Firewall die Netze tatsächlich voneinander trennt. Gruß, Nils

Moin, Aha. Da würden wir der Sache evtl. näher kommen - wäre nur zu klären, was der Grund dafür ist. Warum sollen die Clients auf dieselben Ressourcen zugreifen können, wenn sie in unterschiedlichen Netzen sind? Oder umgekehrt: Warum sollen sie getrennt sein, wenn sie dieselben Ressourcen nutzen? Und: Was heißt "sollen nicht kommunizieren können"? Solange nicht klar ist, was inhaltlich erreicht werden soll, sollten wir keine weiteren technischen Ideen in die Runde werfen, deren Effekt nichts als eine Steigerung der Komplexität ist. Gruß, Nils

Moin, nun sag uns bitte noch, wie du eine "physikalische Netzwerktrennung" erreichen willst, wenn der Hostserver mit jedem Netz verbunden ist? Und wie genau soll dann eine VM dazu beitragen, die ebenfalls mit jedem Netz verbunden ist? Darüber hinaus ist es kaum möglich, dir eine Empfehlung auszusprechen, wenn du die Anforderungen nicht beschreibst. Liefere das bitte nach, früher können wir nichts Sinnvolles dazu sagen. Gruß, Nils

Moin, ah, okay. Danke für die Rückmeldung! Gruß, Nils