NilsK

Moin, Und: adprep ist obsolet. Das macht die AD-Installation automatisch. Es gibt ja auch kein dcpromo mehr. Gruß, Nils

Moin, Nein, du kannst das einfach löschen, sofern die User ihre Rechner weiter nutzen. Sie verwenden dann das vorhandene Profil weiter. Gruß, Nils PS. Ihr wollt einen zweiten DC installieren.

Moin, ja, fast. Deshalb fragte ich ja, was du eigentlich erreichen willst. Was soll mit der Ausgabe geschehen? Bei "Beschreibung" geht es um das Feld "description" aus dem Gruppenobjekt? Und dann nur einen Teil davon? Wie habt ihr mehrere Zeilen dort reinbekommen? Gruß, Nils

Moin, mir ist unklar, wovon du redest. Kannst du bitte die Anforderung und die Situation noch mal genau beschreiben? Wichtig dabei: Gib an, was du eigentlich erreichen willst, nicht was die Probleme deines bisherigen Weges sind. Gruß, Nils

Moin, vermutlich liest er gern "ja". Ja. Gruß, Nils

Moin, korrekt, aber bei den Kunden, mit denen man sowas diskutieren muss, gibt es auch keine weiteren Hosts ... Gruß, Niös

Moin, die Frage stelle ich mir auch. Aus meiner Sicht spricht nahezu nichts gegen virtuelle DCs. Es spricht aber sehr wohl etwas dagegen, nur einen DC zu betreiben. Eine 30-User-Umgebung liegt aus meiner Sicht deutlich oberhalb der Grenze, bis zu der man einen einzelnen DC tolerieren könnte. Noch dazu bei den genannten Eigenschaften. Ein physischer DC muss in so einer Umgebung nicht mehr kosten als 1500 Euro inkl. Lizenz. Wenn das zu viel ist, um im Fall des Falles viel schneller wieder arbeitsfähig zu sein und gleichzeitig verschiedene Schadensszenarien ganz vermeiden zu können ... Gruß, Nils

Moin, ich glaube, in Nordhessen wäre noch Wasser übrig. Hier in Hanau ist es hingegen eher unverdächtig. Gruß, Nils

Moin, dies hier ist immer noch aktuell und ziemlich vollständig: [Darf man einen Domänencontroller virtualisieren? | faq-o-matic.net] https://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-virtualisieren/ Ich würde auch weiterhin nicht auf einen physischen DC verzichten. Es handelt sich um ein Unternehmen? Dann ist ein einzelner DC ziemlich sicher zu wenig. Gruß, Nils

Moin, ich glaube, du willst lieber das bestehende Problem lösen statt eine Reihe neuer Probleme zu erzeugen. Ihr wollt euren SQL Server nicht nach außen veröffentlichen. Gruß, Nils

Moin, deine Syntax ist von Grund auf falsch. Du kannst die Cmdlets nicht einfach so hintereinander schreiben. Auch kannst du nicht einfach aus einem Parameter einen Vergleich machen. Und schließlich funktioniert die Mehrfachverschachtelung und der Verweis auf Werte nicht so, wie du dir das denkst. Vielleicht solltest du erst mal einfachere Codebeispiele ausprobieren und damit in der PowerShell laufen lernen. Deine jetzige Anforderung ist schon sehr komplex, da sollte man die Basics draufhaben. Gruß, Nils

Moin, ja, die betreffende Partei hat meine Haltung gut erkannt. Gruß, Nils

Moin, hm, ich glaub, ich soll in diesem Leben immer nur dasselbe wählen. 92 Prozent Übereinstimmung ... Gruß, Nils

Moin, weitergehend wäre die Frage, ob solche Accounts überhaupt im produktiven AD richtig aufgehoben sind. Aus Sicherheitssicht wäre zu prüfen, ob man für diese Tests nicht ein separates AD einrichtet. Schließlich habt ihr offenbar eine ganze Reihe von Sessions, die unbeaufsichtigt laufen - und das dann künftig vielleicht auch noch mit Shared Accounts. Gruß, Nils

Moin, ich glaube, du solltest dir noch ein paar Grundlagen aneignen. Sonst wirst du auf Basis fehlender Kenntnisse herumstochern und möglicherweise schwere Fehler erzeugen. Ein AD läuft auf einem bestimmten Modus und hat ein bestimmtes AD-Schema. Beide werden von den vorhandenen DCs vorgegeben. Das Schema muss immer dann aktualisiert werden, wenn ein DC mit einem neueren Betriebssystem eingebunden werden soll, und zwar vorher. Das geschieht (in älteren Versionen) über das ForestPrep. Da noch weitere Anpassungen nötig sein können, gibt es auch noch das ADPrep. Erst dann kann man den "neueren" DC überhaupt als DC dazuinstallieren. Hast du also ein AD mit DCs unter 2003 R2 und willst einen DC mit 2008 dazuhaben - ist ForestPrep und ADPrep erforderlich. Seit Windows Server 2012 (meine ich) ist dieser Schritt direkt in die Installation integriert - er findet immer noch statt, aber nicht mehr separat. Der Modus hingegen gibt an, welche neueren Funktionen im AD aktiv sind. Der mögliche Modus wird vom "ältesten" DC vorgegeben. Solange du also noch 2003-DCs hast, kannst du nicht vom 2003-Modus weg. Wenn du den letzten 2003-DC entfernt hast, hebt sich der Modus aber nicht von selbst an, das muss man manuell tun. Normalerweise ist das auch problemlos, aber es kann "theoretisch" Applikationen geben, die vorher geprüft werden müssen. Exchange ist da der einzige "typische" Fall, weil ältere Exchange-Versionen meist mit den neueren AD-Modi nicht klarkommen. Beide Aspekte (Schema und Modus) haben technisch aber nichts miteinander zu tun. Die Probleme in deinem Lab werden nicht ursächlich damit zu tun haben, da stimmt etwas anderes nicht. Gruß, Nils

Moin, das klingt nicht gut. Dann ist sicher das Eventlog voller Details dazu. Ich wage mal zu vermuten, dass wir das in einem Forum nicht gelöst bekommen. Wenn es sich um eine Produktionsumgebung handelt, solltest du umgehend einen Case bei Microsoft eröffnen. Gruß, Nils

Moin, nur ergänzend dazu aufgrund deiner Anmerkung: Drucker gehören auch nicht auf einen DC, die sind auf einem dedizierten Druckserver genau richtig aufgehoben. Gruß, Nils

Moin, Idee 1: Abwarten, möglicherweise eine Replikationslatenz. Da sollte es aber eigentlich nur um Minuten gehen, wenn überhaupt. Idee 2: Da läuft was falsch. Mehr kann man anhand der Informationen dazu nicht sagen. Gruß, Nils

Moin, naja, es gibt ja keine blöden Fragen. ;) Die Alterungs-Eigenschaften gehören zur Zone, die musst du also nur einmal einstellen. Das solltest du dann auf den anderen Replikaten auch sehen. Das Häkchen auf Server-Ebene setzt du eben nur bei dem Server, der das auch tun soll. Und für den gibst du an, in welchen Abständen er nachsehen und aktiv werden soll. Bei allen anderen Servern setzt/lässt du dieses Häkchen leer. Gruß, Nils

Moin, ja, korrekt, so ist das gemeint. Nur auf die Weise kommst du zu vorhersagbaren Intervallen. Wenn mehrere DCs/DNS-Server den Vorgang ausführen, betrachtet jeder seine Intervalle separat - dadurch überschneiden die sich und man weiß nie, wann nun mit einem Aufräumvorgang zu rechnen ist. Gerade für das Troubleshooting wäre das hinderlich. Gruß, Nils

Moin, das Schema hat nichts mit dem Domain oder Forest Level zu tun. Das Schema ist immer das der neuesten Windows-Version, die als DC im Einsatz ist. Beim Modus ist es eher umgekehrt: Der Modus wird vorgegeben durch die älteste Windows-Version, die als DC im Einsatz ist. Ein neueres Schema ändert funktional nichts. Ein höherer Modus schon. Gruß, Nils

Moin, das ist immer eine Frage der Anforderungen und der Möglichkeiten. Ein Konzept mit dedizierten Admin-Workstations zur Absicherung von Admin-Anmeldungen kann Sinn ergeben, man muss aber immer definieren, welches Szenario man absichern will. Und die Prozesse müssen dazu passen. Bei Microsoft gibt es mittlerweile eine ganze Menge dazu, teils mit sehr detaillierten Vorschlägen, was man einschränken kann. Man mache sich aber nichts vor: Das ist sehr großer Aufwand. Wenn der dazu führt, dass die Admins sich dran vorbeimogeln, hat man wenig gewonnen. Gruß, Nils

Moin, uh, wer baut denn sowas? Ich denke, damit hast du deinen DNS-Server gezwungen, die Einträge zu entfernen, bevor der jeweilige Server eine Chance hatte, sie zu aktualisieren. Schau dir an, was die Werte tatsächlich bedeuten. Die im Lieferzustand gesetzten 7 Tage sind da durchaus realistisch, zumindest als Ausgangspunkt. Zudem sollte nur ein einziger DC in der Domäne den Aufräumvorgang tatsächlich ausführen, sonst kannst du die Intervalle praktisch wieder vergessen. [Endlich Ordnung auf dem DNS-Server | faq-o-matic.net] https://www.faq-o-matic.net/2006/04/30/endlich-ordnung-auf-dem-dns-server/ Parallel wäre es durchaus denkbar, dass es Probleme bei der Registrierung gibt. Dazu solltest du die Eventlogs der beteiligten Systeme prüfen. Und natürlich muss die DNS-Konfiguration aller beteiligten Systeme stimmen, siehe dazu: [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Gruß, Nils

Moin, deine Fragen lösen sich nicht mit einem bestimmten Betriebssystem, sondern mit Planung, Erfahrung und Übung. Deine Nachfrage an Tesso ist bereits beantwortet: Du musst am DC nichts einrichten. Der DC verteilt nur die Einstellungen, die du an einer Admin-Workstation zusammenstellst. Eine solche Workstation ist ein PC, auf dem du die Admintools installierst, die du brauchst. In diesem Fall also die RSAT für die AD- und Serverfunktionen. Die Konfigurationen und Einstellungen nimmst du dann mit den Tools auf diesem PC vor, nicht per RDP am Server direkt. Wenn du das so tust, hast du mit hoher Wahrscheinlichkeit auf deiner Admin-Workstation alle Komponenten zur Verfügung, die du für die "eigentlichen" Client-PCs konfigurieren willst. Im Detail können Gruppenrichtlinien durchaus verwirrend sein - hier hilft der erste Satz dieses Beitrags. Gruß, Nils

Moin, bevor es jetzt hier in gegenseitige Beleidigungen abdriftet - verkneift euch doch lieber eine Antwort, wenn es keine sachlich-fachliche ist. Danke. Gruß, Nils