NilsK

Moin, und es kommt immer noch keiner raus?! Gruß, Nils

Moin, dann solltest du das Gerät mal prüfen lassen. So lange sollte das Zapfen nun wirklich nicht dauern. Gruß, Nils

Moin, du machst ja keine Migration. Du richtest eine Failover-Beziehung ein. Das ist ganz was anderes. Schau dir die oben verlinkte Doku von MS an, von da aus solltest du weiterkommen. Gruß, Nils

Moin, jetzt noch mal 180 Grad drehen, oder? Gruß, Nils

Moin, Ich lerne ja gern dazu - wie erreichen die Clients im Failover-Fall den Server? Ist dann da an jedem Standort noch ein Relay im Spiel? Kann auch sein, dass ich falsch lag, aber so ein Konstrukt erschiene mir eher unsinnig, weil ziemlich komplex und damit fehleranfällig. Edith: okay, ich sehe, ich lag tatsächlich falsch mit meiner Vermutung. Sorry für den Fehler und die Verwirrung, die ich erzeugt habe. Wie Evgenij richtig sagt, ist das genau so vorgesehen: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn338979(v=ws.11) (Ich würde es trotzdem nicht so bauen, weil ich es für zu komplex halte.) Gruß, Nils

Moin, Was ich damit meine: so, wie du dir das ausgedacht hast, ist DHCP Failover nicht gedacht. Selbst wenn es keine Broadcast-Grenze in deinem Aufbau gäbe, wäre er jenseits der Spezifikation.* Damit könntest du dich nicht darauf verlassen, was dem HA-Ansatz grundsätzlich widerspricht. Falls es wirklich so sein sollte, dass an mehr als einem Standort HA für DHCP erforderlich ist (was aus meiner Sicht schon ausgesprochen ungewöhnlich wäre), dann sollte es an den geringen Mehrkosten eines vollständigen Failover-Sets pro Standort nicht scheitern. Gruß, Nils * Édit: auch hier ist die Vermutung mit der Spezifikation falsch, siehe unten.

Moin, Ich würde allerdings auch noch mal nach dem Sinn des Ganzen fragen. Meiner Erfahrung nach wird HA für DHCP weitgehend überbewertet. Es gibt einzelne Umgebungen, die das brauchen mögen. Die meisten aber eher nicht. Und wenn es denn benötigt wird, dann würde ich es auch richtig machen und kein Spar- und Bastelkonstrukt aufbauen. Gruß, Nils

Moin, Ich glaube nicht, dass dein Konstrukt mit DHCP funktioniert. Die Clients versuchen den Server per Broadcast zu erreichen, das wird über die Grenze des Standortes nicht klappen. Gruß, Nils Édit: hier lag ich falsch, siehe unten.

Moin, Du kannst das gern versuchen. Gruß, Nils

Moin, du hast gesehen, dass du in der ersten Antwort schon Hinweise bekommen hat, wie es gehen sollte? Gruß, Nils

Moin, wenn es a) nicht mehr läuft und b) die Betriebssysteme unverantwortbar alt sind, wäre es dann nicht evtl. schlau, das DFS mit aktuellen Betriebssystemen einfach neu einzurichten? Ich kann mir gut vorstellen, dass der Aufwand eher geringer ist, als das wieder zum Laufen zu bringen. Immerhin scheint das ja schon tagelang anzuhalten. Gruß, Nils

Moin, achott ... das hatte ich ganz übersehen. Das ist mit DFS-R immer kritisch. Hier drohen Datenverluste. Such mal nach "DFS Last Writer Wins". Gruß, Nils

Moin, das ist ein Problem, wenn man Instanzen einrichtet, obwohl man sie gar nicht braucht. In den meisten Situationen wäre das gar nicht nötig, sondern man könnte einfach mehrere Datenbanken in derselben Instanz nutzen. Eine andere Instanz ist aus Sicht des SQL Servers ein separater Server. Wenn ich nicht ganz falsch liege, müsstest du diese also so ansprechen wie einen Remote-Server. Siehe z.B. diese Fundstellen: https://duckduckgo.com/?q=sql+server+query+across+instances&ia=web Parallel würde ich aber prüfen, ob es nicht schlauer wäre, die Dinge innerhalb derselben Instanz abzuwickeln. Gruß, Nils

Moin, also sind die Dokumente, die da repliziert werden, vom Typ her Read-only? In dem Fall würde ein typischer Einwand gegen DFS-R wegfallen. Grundsätzlich könnte man schauen, ob der verteilte Ansatz heute noch richtig ist. Oft stellen Kunden bei einer Neubewertung fest, dass die Gründe für die geografische Verteilung gar nicht mehr vorliegen und man z.B. mit RDS lieber eine zentrale Datenhaltung unterstützt. Passt nicht immer, aber oft. Sofern es bei dem verteilten ERP bleibt, wäre vermutlich auch die Replikation der Dokumente sinnvoll. Zu der dann nötigen Reparatur kann ich aber leider nichts beitragen. In dem gegebenen Szenario könnte ein Workaround evtl. darin bestehen, die Daten z.B. mit Robocopy zu verteilen. Es gibt viele Umgebungen, in denen man sowas durchaus anstelle von DFS macht. Gruß, Nils

Moin, welches Problem oder welche Aufgabe versuchst du denn mit DFS zu lösen, wenn es richtig läuft? Ich weiß nicht, ob du das dann als "konstruktiven Beitrag" akzeptierst, aber für manche Dinge ist DFS gar nicht die beste Lösung. Wenn wir wissen, wozu es dienen soll, können wir umfassender überlegen. Gruß, Nils

Moin, "helfen". Gruß, Nils

Moin, ich habe dir geantwortet, weil ich deinen Beitrag gelesen habe. Wenn es bei euch Gründe für eine Replikation gibt - gut, dann ist das so. Dann kommt jetzt meine zweite Empfehlung, auch wenn ich so ein Gefühl habe, dass die dir vielleicht auch nicht so gefällt: Sprich das in Ruhe mit einem Dienstleister durch, der sich damit auskennt und euch da architektonisch beraten kann. Wie gesagt, vorstellbar ist vieles, und das hat sich dein Kollege vor über zehn Jahren sicher auch gedacht. Jetzt stehst du aber vor dem Problem, dass die Dinge "nicht so einfach" sind, und durch viel Erfahrung mit Infrastrukturen, Datenbanken und Applikationen ist mein Vorschlag an dieser Stelle, die Lösung nicht über Foren-Tipps zu suchen. Replikation ist nun mal leider schnell sehr komplex, und da ist ein Forum dann kein guter Ort mehr. Für den Entwurf eines Service wären wir hier ohnehin nicht das richtige Board. Gruß, Nils

Moin, nun ... denkbar ist vieles. Aber in solchen Situationen weise ich Kunden meistens darauf hin, dass solche Replikationskonstrukte eigentlich eine Idee aus den Neunzigern sind, als man noch lange nicht von Breitbandverbindungen zwischen Standorten sprach. Heute würde man normalerweise gar nicht mehr so kompliziert denken, sondern die Daten zentral halten, weil es einfach keine guten Gründe mehr gibt, Daten geografisch zu verteilen. Damit braucht man auch diese ganzen anfälligen Konstrukte nicht mehr. Wenn euer Aufbau noch funktionieren würde, wäre das vielleicht eine andere Sache, aber offenbar müsst ihr da sowieso mit Aufwand ran. Und dann würde ich prüfen, ob der Aufwand denn an einer sinnvollen Stelle ansetzt. Gruß, Nils

Moin, mehr erfolgreich oder weniger erfolgreich? Wenn was nicht klappt, dann bitte genau beschreiben, sonst können wir nicht helfen. ADFS ist leider nie "intuitiv" zu administrieren. Darauf muss man sich einlassen. Gruß, Nils

Moin, schön, freut mich. Danke für die Rückmeldung. Gruß, Nils

Moin, "magic phrase" ist ironisch gemeint. Der Autor will ausdrücken, dass das Suchfeld von einer KI ausgewertet wird, die errät, was du brauchst. Das kann besser klappen oder schlechter. Wenn es besser klappt, dann ist das so, als hättest du einen Zauberspruch aufgesagt. Es gibt aber keine vordefinierten Zaubersprüche, die man nachschlagen oder kennen könnte. Gruß, Nils

Moin, Es dürfte ja nicht das große Problem sein, auf den Wagen noch einen Switch zu bauen, oder? Dann habt ihr LAN, ohne einen neuen Wagen kaufen zu müssen. Gruß, Nils

Moin, Was heißt denn "es klappt nicht"? Mit so einer Fehlerbeschreibung kann man ja nicht viel anfangen. Auf Anhieb fällt bei dem Code auf, dass die Anführungszeichen nicht passen. Ein Blog ersetzt die oft durch typografische Zeichen, so auch hier. Mindestens die müsste man also korrigieren. Gruß, Nils

Moin, wobei der zweite Schritt automatisch geschieht. Man führt also nur Enable-RemoteMailbox aus, der Rest geschieht von allein. Der User, für den man das tut, darf lokal noch keine Mailbox haben. Entweder on-prem oder in der Cloud, nicht beides. Gruß, Nils

Moin, ja, eigentlich hab ich mir das auch gedacht. Ich wollt nur noch ein wenig schlaumeiern. Gruß, Ni"wer hat hier Besserwisse gesagt?"ls