NilsK

Moin, wenn es sich um das Zertifikat eures Exchange-Servers handelt, ist das auf dem RDS ja auch nicht richtig. Ein Zertifikat soll dem Client belegen, dass er es mit dem richtigen Server zu tun hat. Wenn der RDS das Zertifikat des Exchange-Servers präsentiert, trifft das ja nicht zu. Es muss schon ein Zertifikat sein, das zu dem RDS-Server gehört. Gruß, Nils

Moin, Weil es verwirrend ist, dass sich jemand extra anmeldet, um auf einen 17 Jahre alten Thread zu antworten. Gruß, Nils

Moin, also in einer Reihe mit DFS-R, PKI, ADFS, Branch Cache und Domain Trusts. Gruß, Nils

Moin, sehr gern. Viel Erfolg! Gruß, Nils

Moin, dann müsstest du aus deinem System das AD über eine der vorhandenen Schnittstellen ansprechen. Da gibt es ja Implementierungen in großer Zahl. Welche davon für deinen Anwendungsfall passt, können wir nicht sagen. Dein System kann seine Dienste dann ja weiter per REST anbieten, aber das AD kann sowas von Haus aus nicht. Gruß, Nils

Moin, sorry, aber damit kann man nichts anfangen. Deine ganze Aufgabe ist nur lösbar, wenn du die Datensätze eindeutig in einen Zusammenhang bringen kannst. Das sehe ich in den Beispieldaten nicht. Falls es dort eine Logik gibt, die diesen Zusammenhang herstellt, könnte man überlegen, wie man die in SQL formuliert. Wie man den eigentlichen Vorgang der Änderung dann ausführt, ist eher eine untergeordnete Frage. Die Selektion musst du lösen, und dazu sehe ich bislang keine Möglichkeit. Gruß, Nils

Moin, willkommen an Board! Ohne die Struktur der Daten zu kennen, werden wir dir da nichts Sinnvolles sagen können. Eine zuverlässige Lösung wirst du nur erreichen, wenn sich in beiden Tabellen die zu ändernde Reihe eindeutig identifizieren lässt, etwa durch eine eindeutige Personalnummer, die in beiden Tabellen auftaucht. Gibt es ein solches Feld? Gruß, Nils

Moin, ich danke auch. Diesmal hat Microsoft dem F5-Spiel ja noch mal eine spezielle Wendung hinzugefügt. https://www.kaczenski.de/2022/07/05/mvp-im-zwanzigsten-jahr/ Gruß, Nils

Moin, na, dann sind wir uns ja ausnahmsweise mal in allen Punkten einig. Gruß, Nils

Moin, es gibt LDAP, es gibt das ADSI und es gibt Active Directory Web Services. https://docs.microsoft.com/en-us/windows/win32/adsi/using-adsi https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd391908(v=ws.10)?redirectedfrom=MSDN Alles nicht taufrisch, aber APIs. Für alles Weitere schließe ich mich Jans Fragen an. Gruß, Nils

Moin, Naja, in Wirklichkeit ist natürlich schon etwas getan worden, nur vermutlich nicht direkt vor dem Reboot. Der Neustart wird nur ausgelöst haben, was vorher schon System schlummerte. Also entweder denn einen Knoten neu machen in der (berechtigten) Hoffnung, dass er danach wieder ordentlich läuft. Oder vorher den langen Weg gehen und analysieren, was da nicht stimmt. Dazu sind die Ereignisprotokolle meist ein guter Start Gruß, Nils

Moin, nichts für ungut. Dein Beitrag ist sehr hilfreich, aber manchmal obsiegt bei uns die Albernheit. Gruß, Nils

Moin, vielleicht ist das aber auch ein sehr entschiedener Server, quasi mit Herz, Seele, Haut und Haar richtig überzeugt. Gruß, Nils

Moin, "gar nicht" in Windows-Dimensionen, natürlich. Gut, vielleicht etwas hoch gegriffen. Ich wollte nur dem Eindruck entgegentreten, dass man ständig Ärger damit hätte und alles mögliche mit den Bach runtergeht. So ist es ja nun nicht. Gruß, Nils

Moin, das Recovery von DC und AADC war genauso gemeint. Nicht so gemeint war das mit dem Update. AADC geht nicht jeden Monat kaputt. Eigentlich geht es gar nicht kaputt. Es könnte nur eventuell mal sein, und dann möchte man die Abhängigkeit nicht haben. Man bedenke auch, dass es sich um ziemlich komplexe Software handelt, schließlich ist das in Wirklichkeit ein MIM, wenn auch ein nachträglich beschränkter. Am Ende Abwägungssache. Gruß, Nils

Moin, Ja gut ... eigentlich habe ich nur eine Meinung geäußert, weil nach meinem Verständnis der TO nach einer Einschätzung gefragt hat. Weitere Schlussfolgerungen über seine Umgebung (außer der eingangs genannten Zahl der Anwender) kann ich nicht anstellen. Wenn wir das Ganze auf eine grundsätzlich-wissenschaftliche Basis stellen, habe ich dem, was du sagst, wenig hinzuzufügen oder zu widersprechen. So war mein Beitrag allerdings auch gar nicht gemeint. Gruß, Nils

Moin, Ich bin Anhänger der "In-sehr-kleinen-Umgebungen-ist-vieles-anders"-Ansicht, aber anscheinend geht es hier um an die 200 User. Das würde für mich nicht darunter fallen. Hier würde ich dem Argument anhängen: Es ist nicht super unsicher, aber warum ein unnötiges Risiko eingehen, wenn man nur eine einzige kleine VM zusätzlich braucht? Gruß, Nils

Moin, Schmeiß den Dienstleister raus. Er ist dein Geld nicht wert. Gruß, Nils

Moin, mit "Migration" meinst du in diesem Fall ein Upgrade, richtig? Zu der Frage mit dem Umbenennen stimme ich Norbert zu und zitiere mich von vor 13 Jahren: Edit: Ach, ich Dussel. Da hab ich ja schon längst ein FAQ für gebaut. [AD-Domäne umbenennen: Was man dazu wissen sollte | faq-o-matic.net] https://www.faq-o-matic.net/2020/07/02/ad-domne-umbenennen-was-man-dazu-wissen-sollte/ Gruß, Nils

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.