cj_berlin

Das hatten wir mal gemacht für Genehmigungen, aber da war ein Reverse Proxy mit Cert Preauth davor.

Moin, das ist alles irgendwie sehr konfus. Wenn nur Clients dieses Programm aus einer Freigabe starten, muss es doch nach dem Umzug lediglich diese Freigabe wieder geben, idealerweise unter demselben Namen. Nun habe ich Foundation nicht mehr so im Kopf, glaube aber mich zu erinnern, dass er zwingend Domain Controller sein muss. Somit hast Du ein Active Directory, in dem (wieder Annahme) die Clients Mitglied sind. Wenn das alles zutrifft, sähe die Migration wie folgt aus: BACKUP!!!!!! Server 2019 wird zur Domäne hinzugefügt und zum DC hochgestuft Datenordner werden per Robocopy kopiert und unter den gleichen Namen freigegeben FSMO-Rollen werden vom 2012R2 auf 2019 verschoben, der 2012R2 heruntergestuft und aus der Domäne entfernt, danach vom Netz getrennt oder zumindest umbenannt. Server 2019 wird gemäß Rename Domain Controller - Der Windows Papst - IT Blog Walter in den Namen des 2012R2 umbenannt Theoretisch müssten die Clients die Anwendung wieder finden und auch aufrufen können. Wenn jetzt auf dem 2012R2 ein Datenbankserver irgendeiner Art läuft (SQL, Firebird, MySQL, was weiß ich), dann lass lieber den Hersteller der Anwendung die Migration machen. Das werden wir hier im Forum nicht gelöst bekommen.

Was wir in solchen Szenarien meistens getan haben, war folgendes: Accounts im Ziel anlegen (wegen mir per PowerShell, insbesondere wenn auch OU-Strukturen stark unterschiedlich sind) Die Attribute, die im Ziel wichtig sind, so konfigurieren, wie im Ziel vorgesehen, und aus der Quest-Sync ausschließen Dann die Sync anschalten (irgendein Attribut muss ja zum Matching vorhanden sein, zu Not benutzerdefiniert) und Kennwort, sidHistory, Gruppenmitgliedschaften, managedBy und den ganzen Beziehungsrotz synchronisieren lassen Wenn euer DL nicht gerade "Facts & Figures" ist (aber die verstehen ihr Handwerk, das wäre euch da nicht passiert) können sie mich gern kontakiteren und die Ideen mal mit einem frischen Satz Augen von jemandem, der jahrelang auf der "PSO Waiver"-Liste für dieses Produkt gestanden hat, begutachten lassen

Du nutzt bei manage-bde den -SkipHardwareTest switch und bei Enable-Bitlocker nicht

ADD: Im Quest Migration Manager kann man die Synchronisierung des "name" anfordern, was einer Umbenennung des Objektes gleichkommt, falls es bereits vorhanden war aber unter einem anderen CN...

https://www.rlmueller.net/Name_Attributes.htm Das sollte es klarer machen. Du kannst name nicht getrennt von CN verwenden.

Das meinte ich auch. Im OP wird die Kerberos-Fehlermeldung zitiert. Diese kann nur auftreten, wenn die Knoten im AD Mitglied sind.

Nee, die fehlt nicht, denn Nicht-Domainmember sprechen bis heute kein Kerberos miteinander, auch wenn das versprochen wurde.

Shit, Du hast recht: Vermutlich nachts gebootet, ohne dass ich's mitgekriegt hatte, weil *aufgefordert* wurde ich mit 100% Sicherheit nicht dazu.

Für Windows 10? Ich habe bisher keine gesehen, mit oder ohne ESU. Insofern @xrated2 Du bist definitiv nicht allein.

Das ist nichts, was man in einer intakten Umgebung nachstellen könnte.

Für das aktuelle Ding? Ja, Server 2025 erlaubt derzeit (unabsichtlich) doppelte Attribute und Klassen im Schema beim Schema-Update, aber (sinnvollerweise) nicht bei der Replikation des Schemas...

Klar wird das funktionieren. Schön ist sowas nicht, aber doppelte OIDs z.B. sind auch früher schon aufgetreten...

Wenn das Interface mit dem Gateway höhere Prio (geringeres Gewicht) hat, hat das Vorrang.

Es ist neben den Definitionen der Routen auch deren Gewicht von Bedeutung. Früher konnte man Adapter explizit gewichten, inzwischen hat Windows da einen fest verdrahten Automatismus, aber ich meine, dass route print dennoch das anzeigt, was in Kraft ist