NilsK

Moin, und genau deshalb stellen wir die Nachfragen. Wenn du dazu nichts sagen willst oder kannst, dann bleibt es pauschal bei: Ja, es ist mit gravierenden Problemen zu rechnen, wenn die Namen sich nicht unterscheiden. Da das hier offenbar jetzt ins Fruchtlose übergeht, belasse ich es dabei. Gruß, Nils

Moin, jaja - aber wie wollt ihr die Daten von Alt nach Neu übertragen? Kaum vorstellbar, dass dabei kein Trust ins Spiel kommt. Gruß, Nils

Moin, und Dateiserver, Datenbanken, Mailsystem, Applikationen habt ihr nicht? Gruß, Nils

Moin, einfach gesagt: sofern es eine Migration irgendwelcher Objekte oder Daten von der alten zur neuen Domäne geben soll, müssen die Namen unterschiedlich sein, sowohl DNS als auch NetBIOS. Gruß, Nils

Moin, und um das noch ausdrücklich zu ergänzen: Zwei Domänen mit demselben NetBIOS-Namen sind untereinander nicht migrationsfähig. Die Namen müssen sich unterscheiden. Laufende Probleme mit den gleichen NetBIOS-Namen kommen dann noch hinzu, insbesondere, wenn beide in einem Subnet sind. Gruß, Nils

Moin, naja, sooo abwegig ist das Missverständnis nun auch wieder nicht. Schaut mal in euer Windows-Startmenü, da steht "Neu starten" für einen ordentlichen Reboot, nicht für einen Reset. Nur so zur Ehrenrettung des TO. ;) Gruß, Nils

Moin, eine Alternative wäre, das per GPO zu regeln. Gruß, Nils

Moin, einen solchen "Speicherabzug" kannst du nur als Administrator machen, nicht als normaler User. Und als solcher kommst du ohnehin überall ran. Wenn man weiß, wie es geht, wird man so auch an die Speicherbereiche anderer, gleichzeitig angemeldeter User kommen. Das ist dann aber eher ein generelles Problem als eins der Benutzerumschaltung. Ein Admin bekäme das, wenn er will, auch ohne das Feature hin. Gruß, Nils

Moin, pauschal kann man es nicht als Risiko bezeichnen. Lizenzrechtlich ist es neutral, weil immer nur ein User lokal aktiv arbeiten kann. In früheren Windows-Versionen wr das Feature noch nicht ausreichend stabil, weswegen es auf Domänenrechnern automatisch abgeschaltet war. Ich meine, dass es seit Windows 7 auch in Domänen verfügbar ist. Technisch ist das umgesetzt wie eine RDP-Sitzung. Es wird also die Multi-User-Technik der Terminalserver verwendet. Das kann aus Sicherheitssicht unerwünscht sein, wenn es konkrete Einschränkungen in der Nutzung eines Clientrechners gibt. Pauschal ist es, wie gesagt, nicht zu beanstanden. Gruß .Nils

Moin, was genau meinst du mit "der Domänen-Administrator wird gesperrt"? Das Konto dieses Administrators wird im AD gesperrt? Oder wie? Um was für ein Konto handelt es sich dabei? Das vordefinierte "Administrator"-Konto? Ein anderes? Unterschiedliche? Gibt es nur das eine? Wie viele Domänencontroller hat die Umgebung? Geben die Security-Eventlogs der DCs Auskunft über das Phänomen? Ist auf dem Dateiserver irgendwas installiert, was die Anmeldedaten des betreffenden AD-Kontos verwendet? Bei dem beschriebenen Phänomen fiele mir z.B. ein On-Access-Virenscanner ein. Ist ein Task mit dem Account eingerichtet? Mit was für einem Account bist du angemeldet, wenn das Phänomen auftritt? Gruß, Nils

Moin, Gut, aber dann bleibt meine oben gestellte Frage: Wie würdet ihr das Problem lösen wollen, wenn ihr die Domain selbst kontrolliert? Es bliebe irgendwie dasselbe, oder? Gruß, Nils

Moin, Benötigt wird die Reverse-Zone für das AD überhaupt nicht. Sie ist aus dieser Sicht ein reines Komfort -Feature. Gruß, Nils

Moin, Ja: Die, über die du etwas wissen willst. Gruß, Nils

Moin, Nein, DocData, nur deine Frage ist lächerlich. Ganz abgesehen davon, kann man in diesem Thread nicht viel mehr antworten als: Technisch geht vieles, es kommt auf die Anforderungen an. Gruß, Nils

Moin, mir ist gerade nicht klar, wie ihr das beschriebene Problem verhindern würdet, wenn ihr die Domain besitzen würdet. Wollt ihr dann ins Public DNS eure internen Servernamen eintragen? Oder wie es bei zahlreichen anderen Kunden aussähe, deren interne Hosts ja schließlich auch nicht über das Public DNS auflösbar sind, selbst wenn sie keinen Fehler beim Benennen ihrer Domäne gemacht haben. Und irgendwie kommt mir dabei nur in den Sinn: Euer Problem liegt gar nicht im Namen der Domäne, sondern in dem Verbindungskonstrukt, das ihr da nutzt. An das solltet ihr ran. Nicht an den Domänennamen. Gruß, Nils

Moin, LOL! Gruß, Nils

Moin, es war sicher nicht gemeint, dafür kein Backup zu machen. Als Ergänzung kann das für größere Umgebungen sehr interessant sein. Gruß, Nils

Moin, doch, such mal nach "muller". Zauberei. Gruß, Nils

Moin, ich werfe noch mal eben ein, dass die "Rechtestruktur" üblicherweise auf Zugriffsberechtigungen auf einem Dateiserver abzielt, aber nicht auf die administrative Struktur im AD. Informationen über die Abteilungszugehörigkeit sowie die disziplinarische Hierarchie bildet man im AD an anderer Stelle ab. Ich habe bislang selten Unternehmen gesehen, in denen im AD eine stärkere Unterteilung als "Benutzer" und "Admins" auf OU-Ebene überhaupt nötig gewesen wäre. Aber wie Norbert schon sagt: Das ist für ein Forum wenig geeignet. Gruß, Nils

Moin, danke für dein Vertrauen, aber deine Frage hat mit dem Thread nichts zu tun. Bitte eröffne einen neuen Thread dafür. Danke. Gruß, Nils

Moin, jaja, das sind die Gründe, warum man das AD immer doppelt sichern sollte: Einmal mit Bordmitteln und dann (sofern vorhanden) mit der separaten Backup-Lösung. Dann gibt es immer ein Backup, das auch vom Hersteller unterstützt wird. Image-basierte Sicherungen sind immer kritisch zu beurteilen, sofern sie nicht ausdrücklich für AD freigegeben sind (wie es bei Veeam m.W. der Fall ist). [Warum Images nicht als Datensicherung taugen | faq-o-matic.net] http://www.faq-o-matic.net/2006/08/04/warum-images-nicht-als-datensicherung-taugen/ [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] http://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ [AD: Betriebsmaster-Ausfall – was tun? | faq-o-matic.net] http://www.faq-o-matic.net/2010/09/09/ad-betriebsmaster-ausfall-was-tun/ Gruß, Nils

Moin, für die oben genannte Anforderung kommt nach meiner Einschätzung nur 8MAN in Frage. (Das ist übrigens auch das Tool, das in Wirklichkeit in dem Tipp von Beitrag 2 verwendet wird.) Gruß, Nils

Moin, ignorieren. Es ist sehr unwahrscheinlich, dass ihr jemals ein Problem damit bekommt. Und sollte es tatsächlich mal nötig sein, über das Internet mit Hosts der dann nicht euch gehörenden DNS-Domain <Name>.ads zu kommunizieren, dann könnt ihr die Namen dieser Hosts manuell in euer DNS eintragen mit der IP, über die diese erreichbar sind. In dem Fall müsstet ihr maximal ein paar eigene Computer umbenennen, falls die ausgerechnet auch noch dieselben Hostnamen hätten. Halte ich aber für ein ausgesprochen bizarres Szenario. Der Aufwand, einen neuen AD-Forest mit einem von euch kontrollierten Namensraum aufzubauen und alles dorthin zu migrieren, dürfte schwerlich in einem sinnvollen Verhältnis zu dem höchst geringen Risiko stehen. "Den Namen kaufen" ist anscheinend momentan noch nicht möglich, weil die "ads"-TLD noch nicht zugelassen ist. Kann man der Vollständigkeit halber machen, sobald Preise feststehen. Eine Vorregistrierung scheint momentan durchaus ein Kostenrisiko zu beinhalten, da die "Anbieter" allesamt nicht seriös aussehen. Mit Ausnahme vielleicht von Google, die sich auch um die TLD-Registry bemühen, aber sie anscheinend eben noch nicht haben. Müsst ihr selbst wissen. Dass es schon beim Erscheinen von Active Directory vor 16 Jahren und zwei Monaten ein schlechtes Design war, eine "ausgedachte" TLD zu verwenden, deren Domänennamen man nicht selbst kontrollieren kann, erwähne ich hier nur am Rande, weil es irgendwie jetzt nicht weiterhilft. Gruß, Nils

Moin, für mich klingt das, als sollte man das Design der Struktur ändern. Gruß, Nils

Moin, mit dem Neuanlegen der VM ist hier auch nicht gemeint, sie ganz neu zu installieren. Gemeint ist, dass du in Hyper-V eine VM als "Hülle" anlegst (CPU, RAM usw.) und dieser dann die VHD(X)-Datei anhängst, die durch das Konvertieren entstanden ist. Das wäre, soweit ich es sehe, bei allen hier diskutierten Methoden nötig. Siehe oben: Auch bei dem WSB-Verfahren würdest du eine neue VM anlegen. An diese bindest du zwei VHDX-Dateien an: Eine leere, die später die Systemdisk wird. Und die VHD(X)-Datei, auf die du mit Windows Server Backup innerhalb deiner VirtualBox-VM das Backup gespeichert hast. Die VM in Hyper-V startest du dann von der Installations-DVD, installierst aber nicht, sondern wählst ganz vorne "Computerreparaturoptionen" und spielst dann von dort aus das Backup auf die neue, leere VHDX-Datei zurück. Gruß, Nils