NilsK

Moin, erster Verdächtiger ist DNS. Sicher, dass die Clients ihre IP-Konfiguration vom DC bekommen? Gruß, Nils

Moin, nein, so wird der Zusammenhang ganz sicher nicht sein. Warum nicht? Die einfachste und beste Lösung wäre, die Fehler auf dem virtuellen DC zu beheben, ihm die Master-Rollen zu übertragen, dann einen zweiten DC hinzu installieren und die "Reste" des ausgefallenen DCs aus dem AD und dem DNS zu entfernen. Die zweitbeste Lösung wäre, den zweiten DC auch abzuschalten und die aktuelle Datensicherung des ADs wiederherzustellen, die du ja hast. Die drittbeste Lösung ist, alles neu zu machen. Auch wenn es nur zehn User sind, ist der Aufwand dafür typischerweise höher, als man zunächst denkt. Gruß, Nils

Moin, unbenommen. In der aktuellen Situation nutzt euch so eine grundsätzliche Betrachtung ja ohnehin nicht. Akut ist mein Punkt: Hol dir kompetente Unterstützung, bevor der Schaden noch größer wird. Sowas kostet Geld, aber der Schaden vermutlich auch. Gruß, Nils

Moin, um mal fachlich zu antworten: Eine Transaktionsreplikation lässt beim SQL Server logisch sehr komplexe Konstrukte zu. Das lässt sich ohne genaue Analyse nicht ändern oder reparieren. Wir können das aus einem Forum daher nicht sinnvoll supporten. Insgesamt ist das ganze Replikationsthema eher eins der Jahrtausendwende. Heute versucht man sowas durch Zentralisierung der Ressourcen zu vermeiden. Den Grund dafür siehst du gerade: Replikation wird schnell komplex, hakelig und instabil und kann zu Datenverlusten führen. Daher findest du auch kaum aktuelle Literatur dazu, das ist einfach aus der Mode geraten. (Zu Recht.) Gruß, Nils

Moin, Welche Treiber hast du geändert? Die von der Grafikkarte? Falls nein, wäre das noch einen Versuch wert (neuer, älter oder einfach noch mal installieren). Gruß, Nils

Moin, okay, das lässt immer noch mehrere Schlüsse zu. Versuch es bitte noch mal mit "ping -4 ...". Und öffne bitte dnsmgmt.msc und schau nach, ob der Domänenname dort als DNS-Eintrag hinterlegt ist. Was steht dort dabei? Da du sagst, dass deine Domäne anstandslos funktioniert (so habe ich die Aussagen oben verstanden), kannst du auch erst mal so arbeiten, wahrscheinlich wird auch weiter alles gehen. Windows sucht sich seinen Weg, das ist in einer so kleinen Umgebung oft völlig ausreichend. Gruß, Nils

Moin, Vor allem: Fummel nicht einfach an IPv6 rum. In einem typischen Heimnetz weil man IPv6 in der Regel haben. Für Firmennetze sieht man das differenzierter. Da du ein Heimnetz hat, würde ich IPv6 zumindest nicht mal eben abschalten, ohne zu wissen, was ich tue. Dann: nslookup ist nicht das, wofür du es vermutlich hältst. Ob die Namensauflösung funktioniert, sagt dir das Programm nicht. Dafür ist ein simples ping viel besser. Können deine Clients den DC per ping erreichen? Was ist die Antwort, wenn du auf den Namen deiner AD-Domäne pingst? Gruß, Nils

Moin, gerade am Internet-Router eines Privatanschlusses würde ich IPv6 nicht einfach abschalten. Es ist nicht unwahrscheinlich, dass auf kurze oder längere Sicht dann Dinge nicht mehr gehen, die man haben will. Gruß, Nils

Moin, doch, genau das sagt die Ausgabe: Der Standardserver ist "localhost", also der Rechner, auf dem du die Abfrage ausführst. Und :::1 ist die IPv6-Loopback-Adresse. Dass dort "localhost" steht und nicht der DNS-Name, liegt daran, dass die Reverse-Lookup-Zone nicht gepflegt ist. Das ist in einer so kleinen Umgebung aber nur ein kosmetisches Problem, das du ignorieren kannst. Wichtig ist, dass der Windows-DNS-Server einen Forwarder "ins Internet" hat, also auf einen DNS-Server, der externe Adressen auflösen kann. Und ebenso wichtig ist, dass alle Rechner, die Mitglied des AD sein sollen, ausschließlich den Windows-DNS-Server als DNS-Server verwenden. Ob du IPv4 höher priorisierst, ist in so einer kleinen Umgebung auch eher Kosmetik. Windows probiert im Zweifel beides aus, die Verzögerung wird sich nicht ernsthaft bemerkbar machen. Gruß, Nils

Moin, Wie kommst du auf die Idee, dass die Namensauflösung nicht funktioniert? Deine Angaben lassen diesen Schluss nicht zu. nslookup ist kein Werkzeug, um die Funktion der Namensauflösung zu prüfen. Gruß, Nils

Moin, Die Dateien enthalten den "Guest State", also Konfigurationsdaten der Versionen 8.2 und höher, die früher Teil der eigentlichen VM-Dateien waren. Einzeln kannst du damit nichts anfangen. Wenn sie Datensicherung sie übrig lässt, ist die dafür verwendete Software vielleicht zu alt für die aktuelle Hyper-V-Version? Du solltest mal prüfen, ob du VMs richtig wiederherstellen kannst. Alte Backup-Software, die die VMGS-Dateien nicht kennt, scheitert nämlich meist beim Restore. Gruß, Nils

Moin, naja, Quickwins sind das nicht, sondern eher Abschnitte einer sehr umfassenden Aufgabenliste. Man mache sich nichts vor, das ist richtig Aufwand. Gruß, Nils

Moin, ich ergänze mal, dass Monitoring gut und wichtig ist, dass aber der oft kolportierte "proaktive"* Gedanke fast nie hinhaut: Monitoring verhindert so gut wie keine Ausfälle, es kann nur dazu beitragen, diese kurz zu halten. Gruß, Nils * ein unsinniges Wort, das es eigentlich gar nicht gibt.

Moin, normal ist es jedenfalls nicht. Aber vermutlich ein Bedienungsfehler. Siehe Jans Nachfrage. Gruß, Nils

Moin, liebe Leute, von der TO haben wir seit dem Eröffnungspost vor fast zwei Monaten nichts mehr gehört. Lassen wir diesen Thread in Frieden ruhen. Gruß, Nils

Moin, ein Problem des Datentyps? Das SID-Feld ist sehr speziell. Gruß, Nils

Moin, wenn du mit Delegation im AD arbeiten willst oder musst, geht an dsacls ohnehin kein Weg vorbei. Das GUI hilft nicht nur nicht, sondern es verhindert, dass man vorankommt. Hier noch eine Standardquelle, da ist auch ein dsacls-Skriptgerüst dabei: [AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net] https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/ Und noch was zum Thema: [ice:2010 AD-Delegation – die Folien und Skripts | faq-o-matic.net] https://www.faq-o-matic.net/2010/08/14/ice2010-ad-delegation-die-folien-und-skripts/ Gruß, Nils

Moin, verstehe, das sind ja bestimmt auch zwei Stunden Zeit, eine Testumgebung mit VMs aufzubauen. Dann wird dir wohl nichts übrig bleiben, als weiter auf eine Produktionsumgebung zu verzichten, wenn du die vorhandene zum Testsystem umfunktionieren musst. </ sarcasm> Dann formuliere ich mal positiv: Wie du jetzt durch das Lahmlegen erfahren hast, ist es sinnvoll, Änderungen dieser Art in einer unkritischen Testumgebung durchzuspielen. Da wir aus deinen Schilderungen auch nicht jedes Detail aus der Ferne einschätzen können, wird dir das mehr Handlungssicherheit geben. Gruß, Nils

Moin, Du kannst das nicht in einer Testumgebung ausprobieren? Gruß, Nils

Moin, Ja, das ergibt Sinn. Dann scheint mir das auch ein angemessenes Verfahren zu sein. Gruß, Nils

Moin, Wie entsteht denn überhaupt der Bedarf? Warum braucht es für "die wichtigsten" Einstellungen 30-40 GPOs, und warum werden so viele Domänen erzeugt? Gruß, Nils

Moin, in dem Szenario könntest du den automatischen Start und die Verzögerung z.B. über einen geplanten Task selbst bauen. Wenn du dann keinen Autostart willst, schaltest du den Task ab. Hab ich so schon bei Kunden gesehen, meine ich. Mit der eingebauten Automatik kriegt man das vielleicht auch hin, aber dazu habe ich mangels Bedarf keinen Tipp. Gruß, Nils

Moin, was genau willst du erreichen? Dass die VM sofort startet? Oder dass sie gar nicht startet? Gruß, Nils

Moin, Jupp, das auch Gruß, Nils

Moin, Gut: 1. Gar nicht, weil es eine maximale Zahl nicht gibt. Du kannst dir am Ende nur anschauen, wie eine konkrete Umgebung läuft und das ggf. per Monitoring untermauern. Der Task Manager hilft dabei nicht, er führt normalerweise eher in die Irre. Als Faustregel: zwischen 2:1 und 20:1 trifft man alles an, das kann auch alles in der jeweiligen Situation passen. 20:1 passt aber längst nicht überall, und 2:1 ist meist übertrieben konservativ. Allerdings gibt es Software, die nur mit 2:1 von deren Hersteller Support kriegt. In gemischten Umgebungen würde ich mir bei 4:1 oder 8:1 keine größeren Sorgen machen. 2: das geben die Applikationen in den VMs vor, nicht die Host-Umgebung. Auch hier ist also keine pauschale Aussage möglich. In der Praxis sehe ich eher zu "dicke" als zu "dünne" Konfigurationen. Einem DC würde ich kaum jemals mehr als 2 vCPUs geben, ein SQL Server kann damit auch gut laufen, wird aber oft auch in kleineren Umgebungen mit 4 besser laufen, manchmal auch 8. Auch dies muss man sich konkret ansehen. Ja, auch ich stimme also den anderen zu. Und nein, eine VM, die nichts zu tun hat, läuft mit mehr CPU nicht besser. Sie langweilt sich nur schneller. Gruß, Nils