NilsK

Moin, ich wage auch zu bezweifeln, dass daraus eine Beschleunigung resultiert. Geprüft wird, ob das Access Token des Users die nötigen Einträge enthält, die in den Berechtigungen auftauchen. Das macht praktisch keinen Unterschied, ob die betreffende SID die des Users ist oder einer der Gruppen, denen er angehört. Dafür hätte man bei deinem Ansatz den Nachteil, dass die Pflege der Berechtigungen sehr aufwändig wird. Gruß, Nils

Moin, das ist ja auch nicht der Grund für eine lokale Firewall. Gruß, Nils

Moin, das wage ich zu bezweifeln, da läuft ja kein Windows. Gruß, Nils

Moin, du kannst in der PowerShell natürlich auch direkt Ordner löschen und da die Variable einsetzen. Das dürfte erheblich einfacher sein, als den Wert der Variablen irgendwie auf die CMD-Ebene zu bekommen. Wenn es CMD sein soll, könntest du dir die Rechnerei sparen und robocopy zweckentfremden. Dort kannst du ein Dateialter angeben und die Daten z.B. nach NUL verschieben. Gruß, Nils

Moin, also das, was ich gestern um 11:51 und 11:21 schon vorgeschlagen hatte. Aber schön, dass es jetzt geht. Und danke für die Rückmeldung. Gruß, Nils

Moin, ich meine auch die Fragen aus Das wären noch "einfache" Möglichkeiten, die zu dem Fehler führen können. Gruß, Nils

Moin, die Einträge sehen OK aus. Wenn meine oben gestellten Fragen geprüft und befolgt wurden und es damit kein Ergebnis gab, kann ich über ein Forum nichts mehr tun. Gruß, Nils

Moin, ah, das macht es ja noch einfacher. Ist also nur zu betrachten, ob man die Konfig übertragen will oder sich das spart. Gruß, Nils

Moin, die ist doch "ab Werk" an, oder? Gruß, Nils

Moin, "Unterbruch" - lass mich raten, Eidgenosse? Vor so einem Vorhaben sollte man immer prüfen, ob eine DHCP-Migration überhaupt nötig ist. Gerade in SBS-Netzwerken ist das selten der Fall. Also: Gibt es denn Konfigurationen, Reservierungen usw. in nennenswertem Umfang, für die man überhaupt migrieren müsste? In den meisten Fällen reicht Folgendes: Auf dem bestehenden DHCP-Server die Lease-Dauer reduzieren auf wenige Stunden. Neuen DHCP einrichten und konfigurieren, Dienst abgeschaltet lassen. Alten DHCP abschalten, neuen einschalten. Da Windows-DHCP vor dem Vergeben einer Adresse prüft, ob diese im Netzwerk schon antwortet, kann man sich in kleinen Netzen sogar das Koordinierte Umschalten der Dienste sparen und den neuen DHCP einfach parallel einrichten. Gruß, Nils

Moin, toll, dass ihr so viele Details über ESX wisst. Hier geht es aber um Hyper-V - back to topic, schlage ich mal vor. Gruß, Nils PS. auf hoher Flughöhe stimme ich Norberts Antwort zu.

Moin, hat er beides schon beantwortet. Es fehlen hingegen noch Antworten auf ein paar Fragen von mir. Gruß, Nils

Moin, ich stolpere über den "unbekannten" Knotentyp. War der alte DC mal WINS-Server? Was steht in der Registry unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters\EnableProxy für ein Wert? Dann noch ein letzter Versuch: Was gibt Folgendes in der PowerShell zurück mit dem Namen des "vorhandenen" DCs? Get-ADComputer -Identity 'DEINSERVER' -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName Gruß, Nils

Moin, ist das eine saubere Neuinstallation oder ein Klon aus einer Vorlage? Falls Letzteres: Sauber installieren. Ist schon ein Computerkonto für den Rechnernamen vorhanden? Falls ja: löschen. Ist in den DNS-Clienteinstellungen des neuen Servers etwas anderes als "Primäre und verbindungsspezifische DNS-Suffizes anhängen" aktiviert? Falls ja: ändern. Weitere Ursachen für diesen Fehler wären exotisch, aber es gäbe noch welche. Dafür wäre es hilfreich wenn du, worum ich ja schon gebeten habe, mal angibst, was das Eventlog ggf. noch hergibt. Gruß, Nils

Moin, du hast aber auf dem neuen DC das AD noch nicht eingerichtet, oder? Ich würde als nächstes Folgendes tun: den neuen DC völlig neu installieren Updates drauf, aber keine Rollen IP-Konfig korrekt setzen noch mal versuchen erst nach dem Domain Join die Rollen hinzufügen und das AD einrichten als zusätzlichen DC der vorhandenen Domäne Meldet der vorhandene DC sonst irgendwelche Fehler, die (auch nur entfernt) mit dem Problem zusammenhängen können? Gruß, NIls

Moin, DNS-Cache gelöscht? ipconfig /flushdns Gruß, Nils

Moin, die DNS-Konfig des vorhandenen DC ist falsch. NIEMALS einen DNS-Server angeben, der andere Daten enthält. Sowas macht man über einen Forwarder im DNS-Server, nicht in der Client-Konfig. Die DNS-Konfig des neuen DC ist auch falsch. Er versucht erst, bei sich selbst zu gucken, da wird er aber nichts finden. Genau darum habe ich auf meinen FAQ-Artikel verwiesen ... Gruß, Nils

Moin, hm, mag sein. Das ADAC gibt es seit Server 2008, daher die Annahme, dass es im SBS 2011 auch vorhanden sei. Kann aber sein, dass das, selbst wenn es da war, den Papierkorb noch nicht konnte. Gruß, Nils

Moin, dann jetzt bitte mal systematisch: IP-Konfig des vorhandenen DCs IP-Konfig des neuen Servers was genau machst du auf welchem Server und was passiert? Gruß, Nils

Moin, nein, im ADUC sieht man die nicht. Starte mal das AD Administrative Center, dort sollte das sichtbar sein. Gruß, Nils

Moin, also ist der neue Server noch nicht Domänenmitglied, und du versuchst von diesem neuen Server aus, diesen in die Domäne aufzunehmen? DNS ist anhand meiner Hinweise korrekt eingerichtet? Versuch es mal mit einem Neustart, dann keine Verbindung zu einem anderen Rechner aufbauen, sondern direkt den Domain Join versuchen. Gruß, Nils

Moin, was genau machst du auf welchem Server, wenn du die Meldung erhältst? Schuss ins Blaue: So eine Meldung erscheint manchmal, wenn man auf dem Non-Domain-Rechner bereits eine Session zu einem Domänenrechner mit einem Domänenkonto offen hat (z.B. Dateiserver-Zugriff mit separater Konten-/Kennnworteingabe). nslookup ist kein geeignetes Tool, um die Namensauflösung zu testen (warum?). Besser und einfacher: ping auf den FQDN. DNS ist richtig eingerichtet? Hinweise Gruß, Nils PS. Und die Firewall hinterher wieder einschalten.

Moin, tja ... keine Arme, keine Kekse. Also entweder einen der DCs umbenennen oder auf den Trust verzichten. Gruß, Nils

Moin, doch, es ist supported, einen DC per Hyper-V Replica zu replizieren. Ob es sinnvoll ist, ist eine andere Frage. In den meisten Designs empfiehlt man, dass "auf beiden Seiten" je ein DC läuft und man diese dann nicht repliziert (wie ja auch hier schon angemerkt wurde). Dadurch ist in (fast) jedem Fall die Anmeldung schon mal möglich. Exchange hingegen ist nicht supported - heißt: Es kann gehen, aber wenn nicht, wird Microsoft einem nicht helfen. VMs über Subnets hinweg zu replizieren, wirft immer die Frage nach den Netzwerkeinstellungen auf. Die wird man in der Regel anpassen müssen. Hyper-V Replica ist, wie schon angedeutet wurde, nicht als Hochverfügbarkeitslösung gedacht, sondern als "mittelschnelle" Möglichkeit zum Wiederanlauf. Es ist ja ohnehin manueller Eingriff erforderlich, selbst im selben Subnetz. Gruß, Nils

Moin, Aber deshalb gleich eine Vollbremsung? Anfangs hieß es doch, dass die Deutschland-Cloud denen aus den Händen gerissen würde. Vermutlich hält die Unberechenbarkeit der amerikanischen Justiz die Leute davon ab, das eigentlich sehr interessante Modell zu buchen. Gruß, Nils