NilsK

Moin, OK. Dann siehe meine Handlungsempfehlung. Wenn es um eine spezielle Software geht, die Windows 2003 braucht, könnten die DCs ja trotzdem mit einem supporteten Betriebssystem laufen. Würde die Fehlerbehebung - gerade bei einer wichtigen Applikation - dann doch erleichtern. Gruß, Nils

Moin, "ungleiche" Verteilung der Anmeldungen auf mehrere DCs ist i.d.R. kein Problem. Es gibt keine "Normalverteilung". Ebenso gibt es auch kein "Failover", wie der TO das vermutet. Gruß, Nils

Moin, der ganze Aufbau hört sich überhaupt nicht gut an. Man will keinen DMZ-Server, der eine Verbindung ins LAN hat. Schon gar nicht will man da mit Kennwörtern arbeiten, die in einem Skipt hinterlegt sind. Und einem Skript-User lokale Adminrechte zu geben, ist ein No-go, vor allem in der DMZ. Also, wie Sunny61 schon sagt: Klären, was denn wirklich erreicht werden muss. Und dafür eine Lösung finden, die mit dem DMZ-Konstrukt kompatibel ist. Gruß, Nils

Moin, sind die DCs nur DC oder führen sie noch andere Software aus? Was ist nach dem Hardwareausfall passiert? Wurden die Server nur wieder eingeschaltet? Oder habt ihr was anderes gemacht, z.B. ein Image zurückgespielt? Sofern die DCs nur DC sind, ist es normalerweise am besten, den defekten DC abzuschalten und aus dem AD zu löschen. Da es sich um Windows 2003 handelt, muss man dazu ntdsutil nutzen, der Vorgang ist aber dokumentiert. Könnte allerdings sein, dass man die zugehörigen KB-Artikel nicht mehr ohne Weiteres findet. Die FSMO-Rollen kann man auf einen der anderen DCs übertragen, dabei im GUI bestätigen, dass der alte Server nicht mehr erreichbar ist. Oder mit ntdsutil und seize arbeiten. Der alte Rolleninhaber darf dann nicht mehr online gehen (Netzwerkkabel entfernen und nicht wieder anstecken). Gruß, Nils

Moin, mir scheint, ihr solltet eure Prozesse noch mal prüfen. Es sollte schon Einigkeit und Überblick herrschen, wie eure Infrastruktur aufgebaut ist. Dann: nslookup ist nicht geeignet, um die Namensauflösung von Clients zu prüfen! nslookup arbeitet völlig anders als der Client-Resolver. Die erste Prüfung sollte immer mit ping erfolgen. In praktisch allen Fällen dieser Art, die ich in den letzten 20 Jahren unterstützt habe, lag das Problem an falscher DNS-Konfiguration auf Clientseite. Dem würde ich an deiner Stelle also noch mal mit einer genauen Detailprüfung (und nicht nur Vermutungen) nachgehen. Gruß, Nils PS. und nein, entferne nicht den GC. Der hat, wie DocData richtig sagt, mit dem Problem nichts zu tun. Und jeder DC hat GC zu sein, in praktisch jeder Umgebung.

Moin, oben sprichst du von zwei DCs, aber du hast drei DNS-Server eingetragen. Was ist der dritte für einer? Und wie prüfst du während des Ausfalls die Namensauflösung? Gruß, Nils

Moin, alle Clients haben beide DCs als DNS-Server eingetragen (und nur diese, keine anderen wie z.B. den vom Provider)? Dann sollte keine Abhängigkeit von einem bestimmten DC bestehen. Was sagen die Eventlogs auf den Clients, während nur einer der DCs erreichbar ist? Gruß, Nils

Moin, normalerweise liegt sowas an falscher DNS-Konfiguration auf den Clients. Gruß, Nils

Moin, das "Argument" bringt ihr oft, aber dadurch wird es noch lange nicht zu einem Argument ... Eure Datacenter sind nun mal in Aufbau und Betrieb nicht mit dem zu vergleichen, was ein mittelständischer Kunde so hat und braucht. Und ganz sicher habt ihr keinen einzigen 2-Node-S2D-Cluster im produktiven Betrieb, auf den sich die ganze Diskussion hier gerade primär bezieht. Gruß, Nils

Moin, Wohlgemerkt: der "kostenlose" Exchange-Server ist nur für den Synchronisieren bei reinem Office 365. Er darf keine Mailboxen halten, sonst braucht man eine Lizenz dafür. Gruß, Nils

Moin, auch wenn es nicht das ist, was du hören willst: produktive Systeme und "Backup darf nichts kosten" geht nicht zusammen. Nimm was Ordentliches. Wenn es die paar Kröten nicht Wert sind, sind die zu sichernden Systeme offenbar unwichtig. Gruß, Nils

Moin, sinnvollerweise plant und entwirft man sowas mit einem Systemhauspartner. Es sind so viele Variablen darin, dass man das in einem Forum nicht gut klären kann. Man sollte etwa mit der Frage der Anforderungen beginnen, was über eine Serverliste und die Zahl der Anwender deutlich hinausgeht. Ein guter Berater kann einen durch diesen Prozess führen, das muss auch keine Unsummen kosten. Berücksichtigt vor allem das "Drumrum", das oft vergessen wird: Netzwerk, Backup, Recovery-Szenarien. Gruß, Nils

Moin, in dem ROBO-Szenario (kleine Filiale) ist S2D in aller Regel aber schon wegen der Lizenzen zu teuer. Zweimal Datacenter - wegen der dort laufenden VMs würde die Filiale das ganz sicher nicht brauchen. Scheidet also faktisch auch aus. Gruß, Nils

Moin, warum wusste ich, dass das kommt? :D Gruß, Nils

Moin, naja. Sowohl an Storage Spaces als auch an ReFS würde ich noch ein Fragezeichen machen. Qualität und Reifegrad lassen Zweifel zu. Was RAID betrifft: Die Idee hinter S2D ist, dass die Software die Kontrolle übernimmt. Meines Wissens ist RAID an der Stelle zwar möglich, aber nicht supported, also nur für Tests usw. gedacht. Bei der Performance gilt grundsätzlich "viel hilft viel", aber spätestens an der Stelle sollte man sich schon über die Kosten Gedanken machen. Die konzeptionellen Nachteile von S2D gegenüber anderen Hyperconverged-Lösungen tun ihr Übriges - so kennt S2D keine "Data Locality", ist also abhängig von Hochleistungs-Netzwerkverbindungen. Nicht umsonst drängt Microsoft auf RDMA-Karten, was der ursprünglichen Idee, ein leistungsfähiges System aus (günstigen) Standardkomponenten zu bauen, doch deutich widerspricht. Und um noch mal den 2-Knoten-Cluster zu stressen: Wie gesagt, eigentlich war das vom Hersteller nie vorgesehen. Und das auch aus gutem Grund. Die "etablierten" Hyperconverged-Hersteller sehen aus solchen Gründen drei Knoten als Minimum an. Gruß, Nils

Moin, Pro statt Enterprise? Gruß, Nils

Moin, hat mit der Version nix zu tun. War schon immer so, auch unter anderen Betriebssystemen. Was den Timeout verursacht, könnte man noch mal separat schauen, aber offenbar ist die eigentliche Namensauflösung ja nicht davon betroffen. Wichtig ist eben: nslookup ist kein "Profi-Ping", sondern macht etwas ganz anderes. Gruß, Nils

Moin, wenn ihr einen lokalen Task erstellt, richtet ihn doch einfach mit lokalen Adminrechten oder als System ein. Wobei, wie gesagt, die meisten WMI-Daten bei lokalem Zugriff auch ohne spezielle Rechte lesbar sind. Abgesehen davon, würde diese Frage aber auch nicht das Erzeugen des Tasks verhindern, sondern höchstens die erfolgreiche Ausführung. Wenn die Tasks also gar nicht erscheinen, liegt das Problem woanders. Gruß, Nils

Moin, nutzt ihr als Domänennamen eine Domain, die es auch im Internet gibt? Dann kann das bei nslookup zu diesem Verhalten führen. [Wenn (und warum) nslookup unerwartete Ergebnisse zeigt | faq-o-matic.net] https://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/ Wie ist es bei einem ping auf den FQDN? Gibt es da auch eine Wartezeit bei der Auflösung? Gruß, Nils

Moin, da in den allermeisten Umgebungen die WSUS-Datenbank nur operativen Zwecken des WSUS-Systems selbst dient, ist etwas anderes als WID eine exotische Kombination. Sofern es also keine definierten Anforderungen gibt, die Datenbank mit höherer Priorität zu behandeln, würde ich beim Standard bleiben. Gruß, Nils

Moin, vermutlich sind das lokale Kalender. Gruß, Nils

Moin, vor allem sollte man erst die Anforderungen klären - und mit "klären" meine ich keine kurze Liste wie oben. "Eine vernüftige und bezahlbare Ausfallsicherheit" will jeder, aber das hat mit den Anforderungen der Geschäftsprozesse nichts zu tun. Erst wenn das geklärt ist, macht man ein Design. Und erst danach guckt man auf konkrete Technik. Mit der Frage nach der iSCSI-Anbindung von SOHO-grade NAS zu beginnen, ist der falsche Weg. Gruß, Nils

Moin, also, ich hab's jetzt doch ausprobiert. Geplante Tasks werden per GPP auch im laufenden Betrieb eingerichtet, ohne Neustart. Ein gpupdate oder Warten reichen aus. Klappt hier sowohl für die normalen als auch für die "sofortigen" Aufgaben. Ihr habt es über die Computerkonfiguration eingerichtet und an der richtigen Stelle im Taskplaner nachgesehen? Gruß, Nils

Moin, ich wiederhole meine Frage: Um wieviele Server geht es denn? Vielleicht wäre es ja auch eine Option, die Abfrage bzw. das Skript dafür per psexec remote auszuführen. Gruß, Nils

Moin, ohne das Gesamtdesign zu kennen, lässt sich das von hier aus schwer beurteilen. Die Grafik des Dienstleisters scheint mir auf eine Fabric-Redundanz hinzudeuten, denn auf zwei Verbindungen sind nur die Switches miteinander verbunden. Ich würde erst mal davon ausgehen, dass sich der DL was dabei gedacht hast. Wie wäre es denn, wenn du dir das noch mal in Ruhe erklären lässt? Ich würde da jetzt nicht aufgrund irgendwelcher Schnellschüsse eine Beurteilung abgeben. Gruß, Nils