NilsK

Moin, das wäre hier gar nicht gegeben. Ein CSV ist ja eine LUN aus einem (separaten) Storage-System. Die Zuordnung zu einem Knoten dient nur der Koordination der Zugriffe durch verschiedene Systeme. Möglicherweise verwechselst du das grad mit S2D. Gruß, Nils

Moin, die Frage ist, was du damit erreichen willst. Technisch betrachtet, kannst du das tun. Eine pauschale Empfehlung dafür kann man aber nicht aussprechen, weil so eine Aufteilung wohl nur in sehr speziellen Szenarien Vorteile brächte. Am Ende sind CSVs normale LUNs aus dem Storage. Anders als diese können aber mehrere Server gleichzeitig darauf zugreifen, eben die Cluster-Nodes. Es muss dabei sicher gestellt sein, dass diese nicht dieselben Daten verwenden. Rein technisch könnte man also durchaus die Dateien so aufteilen, wie du es angibst, denn es greift ja jede Instanz nur auf ihre Dateien zu. Bleibt aber die Frage, warum man das tun sollte. Interessant könnte das evtl. sein, wenn etwa das Log-CSV viel schneller im Zugriff wäre als das DB-CSV. Das dürfte allerdings bei den meisten Storage-Systemen gar nicht der Fall sein. Außerdem geht es dann evtl. nach hinten los, wenn mehrere Datenbanken ihre Logs auf demselben CSV haben und damit dann um die Zugriffe konkurrieren. Zudem ist das CSV die Failover-Einheit, aber da das eher die Verwaltung betrifft als die laufenden Zugriffe, ist das eher weniger relevant. Es ist eine Frage, die im Gesamtdesign des Systems zu beantworten ist, aber keinesfalls pauschal. Gruß, Nils

Moin, was würde denn aus deiner Sicht für getrennte CSVs sprechen? Mir kommt schon die Idee exotisch vor. Gruß, Nils

Moin, okay, dann passt es zu Admins. Die denken ja auch, wenn sie Monitoring machen, gibt es keine Ausfälle mehr. Gruß, Nils

Moin, möglich, dass das out of scope war. Wenn Admins jetzt auch noch fürs Wetter zuständig sein sollen ... Gruß, Nils

Moin, schon in der Bibel ist davon die Rede, und es gibt Forschungsmeinungen, die Hinweise darauf in Höhlenmalereien sehen. Gruß, Nils

Moin, Da ich eure Anforderungen nicht kenne, kann ich dazu nichts weiter sagen. Irgendwelche Analogien und Logikspiele führen hier nicht zu viel, denke ich. Gruß, Nils

Moin, Manche Entwickler arbeiten bei Microsoft. Gruß, Nils

Moin, welches A? Completely lost, Nils PS. eigentlich finde ich es schön, dass solche Fehler auch anderen passieren ...

Moin, bei den Experts tauchen manchmal so finstere Typen mit langen Messern auf, wenn man nicht antwortet. Echt kein schöner Job. Gruß, Nils

Moin, und es ist eben schlecht, um Hilfe zu fragen, wenn man nicht angibt, was man eigentlich erreichen will. Für's nächste Mal dann ... Gruß, Nils

Moin, ich glaube nicht, dass diese Diskussion weit führt, wenn wir weder das Datenmodell noch die Anforderungen kennen. Gruß, Nils

Moin, du hast es hier mit einem "Composite Primary Key" zu tun. Das ist zulässig, hat aber - wie du siehst - seine Nachteile. Um diese Nachteile aufzulösen, musst du das Datenmodell genau kennen und auch wissen, wie auf die Daten zugegriffen wird. Einfach so ändern kannst du das nicht, weil du damit die Grundlogik der Tabelle änderst. Heißt für dich also: Entweder den ursprünglichen Entwickler ansprechen oder viel Arbeit in die Analyse stecken. https://learn.microsoft.com/en-us/sql/relational-databases/tables/create-primary-keys?view=sql-server-ver16 Wenn du beides nicht tun kannst oder willst, müsstest du versuchen, deine Methode zum "Datenabgleich" zu optimieren (was auch immer darunter zu verstehen ist). Leider kann man an der Stelle wohl nicht viel mehr sagen, ohne viel Aufwand in die Problemanalyse zu stecken. Gruß, Nils

Moin, okay, das ist ja schon mal ein wichtiger Punkt. Ihr könntet also (so verstehe ich das) im AD gezielt auf einer OU (oder so) einer Mitarbeitergruppe das Recht geben, Computerkonten hinzuzufügen. Diese OU könnte das Standardziel für neue Computerkonten sein. Dann betreffen euch die Hinweise in dem KB-Artikel nicht. Ansonsten weist der KB-Artikel ja auch Wege auf, wie es mit dem Pre-Staging gehen kann. Da ich selbst kein AD betreibe und momentan auch keine passende Testumgebung habe, fehlen mir dort die konkreten Umsetzungserfahrungen. Aber für mich klingt es, als sollten sich die nötigen Gruppen und Policies recht einfach nutzen lassen. Gruß, Nils

Moin, und du möchtest jetzt einen Weg beschrieben bekommen, wie es geht? (Ernst gemeinte Frage, damit wir in die richtige Richtung diskutieren.) Falls ja, fangen wir mal einfach an: Auf das Pre-staging (Computerkonto vorher anlegen) zu verzichten, ist in dem Szenario keine Option? Gruß, Nils

Moin, was ist der Hintergrund deiner Frage? Geht es darum, dass du das ermöglichen möchtest? Oder geht es darum, das zu verhindern? Die Updates, die der Artikel beschreibt, betreffen nur ein bestimmtes Szenario, nämlich das (Wieder-)Verwenden eines bestehenden Computerkontos im AD. Sie betreffen nicht den üblichen Vorgang, einen Computer erstmalig ins AD zu bringen. Das funktioniert, soweit ich das sehe, immer noch so wie vorher. Gruß, Nils

Moin, Also, in Oberbayern haben wir diese Marke weit verfehlt. Warm, manchmal freundlich, manchmal Regen. Aber schon hübsch hier. Gruß, Nils

Moin, Sagen wir es so: Frank Carius ist sehr seriös und sehr gründlich, aber nicht unfehlbar. In diesem Fall hat er aber eigentlich auch keinen Fehler gemacht, sondern sich nur etwas ungeschickt ausgedrückt. Sein Szenario ist die Wiederherstellung eines DCs ohne vorherige Grundinstallation. Dafür reicht das System State Backup in der Tat nicht aus. Um dieses wiederherzustellen, muss man erst ein vollständig laufendes Windows haben. Warum er diesen Fall in seinem Artikel nicht durchspielt, weiß ich nicht. Die Aussage, es ginge generell nicht, ist so aber nicht richtig. Eine Sache, die aber sehr wichtig ist: das AD wiederherzustellen, kann erheblich mehr Aufwand sein, als man erst denkt. Es gibt eine ganze Menge Dinge, die zusätzlich erforderlich sein können. Das hängt von der Umgebung ab. Daher ist es, wie Frank ja sagt, eine sehr gute Idee, diesen Fall regelmäßig zu proben und die Erkenntnisse in seinen Prozess aufzunehmen. Dazu könnte es dann durchaus gehören, lieber mit einem Bare Metal Recovery zu arbeiten. Es gehören aber auch Schritte dazu wie das Entfernen der ehemaligen Replikationspartner und vieles andere. Das meiste davon kann man aber erst in dem Moment festlegen, in dem man das Recovery durchführt, weil jede Situation andere Bedingungen erzeugt. Gruß, Nils

Moin, auch keine direkte Lösung, nur den Hinweis, dass sich alles, was mit "Kalender synchronisieren" zu tun hat, schnell zum Fass ohne Boden entwickelt. Kalenderdaten sind zickig, weil sie sehr viele Varianzen haben, an denen diverse Dinge scheitern können. Dazu kommt, dass Kalendereinträge so ziemlich die einzigen Daten in der Mailbox sind, die sich nach dem Erzeugen noch ändern können und die regelmäßig parallel mit unterschiedlichen Clients bearbeitet werden, die ihrerseits sehr eigene Vorstellungen davon haben, wie das richtig geht. Wenn man den Sync organisatorisch weglassen kann, ist das oft die bessere Lösung. Gruß, Nils

Moin, "ohne Scorpions, Jane, Eloy in die 80er Jahre!" (aus dem Klappentext von "Wie der Punk nach Hannover kam") Gruß, Nils

Moin, das Szenario kommt mir ausgesprochen seltsam vor. Das sollte sich aber - wenn man es denn wirklich will - über eine Client-Regel machen lassen. Das hätte auch die hübschen Nebenwirkung, dass dann nicht der Admin schuld ist ... Gruß, Nils

Moin, in der Aufgabenplanung selbst wird das bei dem jeweiligen Task angezeigt. Reicht das nicht aus? Gruß, Nils

Moin, dann gute Besserung. Schöne Grüße, Nils

Moin, nur der Vollständigkeit halber: das Circular Logging ändert nicht die Schreibvorgänge in die Datenbank. Wie praktisch jede relationale Datenbank macht auch die ESE "Lazy Writing", was zu einem parallelen Logging zwingt. Dieser Vorgang ist immer derselbe. Das Circular Logging sorgt nur dafür, dass die Log-Dateien, deren Transaktionen schon in die Datenbank geschrieben worden sind, gelöscht werden. Damit stehen sie nicht mehr für Recovery-Zwecke zur Verfügung, belegen aber auch keinen Platz mehr. Gruß, Nils

Moin, das kommt sehr darauf an, was man denn testet. Das müsste der TO vermutlich auch noch mal für sich klären. nslookup etwa gibt Aufschluss, was im DNS steht, aber nicht darüber, was die Namensauflösung auf dem Client macht. (Ja, ich weiß, du weißt das, aber dem TO ist das evtl. nicht so klar.) Gruß, Nils