NilsK

Moin Kopfsalatkopf, weist du das nächste Mal bitte darauf hin, wenn du einen Crosspost in mehreren Foren machst? Es ist nicht nötig, dieselbe Diskussion an mehreren Stellen zu führen. Danke. Virtualisierung - Sinnvollster Ablauf Gruß, Nils

Moin, was genau sollen wir denn darauf antworten? Gruß, Nils

Moin, auch schon gesehen: Ein Skript legt die User nicht nur ohne Kennwort an, sonden setzt gleich noch die Option "password not required" ... Und auch schon gesehen: Ein Skript legt nicht die gewünschten zehn User an, sondern mehrere hunderttausend ... Und auch schon gesehen ... aber vielleicht ist die Message schon rübergekommen. Gruß, Nils PowerShell hat allerdings hier keine grundsätzlichen Vorteile gegenüber VBS/ADSI - man nehme das, das für die konkrete Aufgabe am besten passt und das man (wichtig!) am besten beherrscht. Das könnte auch Batch-Scripting sein ...

Moin, adrestore wird nicht klappen, weil im Tombstone das Kennwort fehlt. Es müsste schon ein Authoritative Restore sein. Gruß, Nils

Moin, wie immer, ist es auch hier nicht so einfach. Auch in einer Xen-, VMware- oder Hyper-V-2012-Umgebung gibt es oft Abhängigkeiten von AD, die über das reine Windows-Clustering hinausgehen - beispielsweise beim Recovery. Die Empfehlung eines separaten DC sollte man also in keiner Situation einfach so abtun. Ansonsten stimmt natürlich auch hier der Hinweis, dass strategische Fragen der hier aufgeworfenen Art in einem technischen Forum nicht sinnvoll diskutiert werden können. Hier kommt es auf Detailanalysen und genaue Definition der Abhängigkeiten an. Gruß, Nils

Moin, wie heißt der Server und wie hast du genau gesucht? Gruß, Nils PS. "der DC" heißt, es gibt nur einen? Das ist nicht genug.

Moin, du hast bereits eine Suche nach dem Computerobjekt ausgeführt? Vielleicht ist es ja nur nicht an der Stelle, wo du es vermutest. Gibt es Fehlermeldungen in den Eventlogs des Servers und der Domänencontroller, die mit dem Problem zu tun haben könnten? Gruß, Nils

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