NilsK

Moin, OK, vielleicht anders formuliert: So ein Verfahren ist weitab von dem, was Windows dafür an Mechanismen und Optimierungen hat und vermutlich das am wenigsten effiziente Vorgehen - wie man im konkreten Fall ja sieht, sofern die Spekulation zutrifft. Es gibt durchaus zahlreiche SQL-gestützte Anwendungen, die direkt die vorgesehenen Mechanismen nutzen. Es gibt dafür im System ja auch eine ganze Reihe Hilfestellungen. Portabilität mag ein Argument in die andere Richtung sein, aber sie erzeugt in so einem Fall dann eben erhebliche Kosten - Vorgänge um das Fünffache verlängern, weil man eine Kompatibilitätsschicht einsparen will, ist ganz gewiss nicht Best Practice. Nur weil es viele machen, ist es ja nicht gut. Ich ergänze noch: Diese Betrachtungen helfen dem TO erst mal wenig, schließlich hat er die Software ja nicht gebaut. Aber es wäre lohnenswert, den Hersteller genau danach zu fragen, um die Handlungsoptionen einzuschätzen. Vielleicht geht erst mal kein Weg daran vorbei, die Berechtigungen selbst aufzulösen, aber vielleicht gibt es auch einen besseren Weg, das Problem anzugehen. Wir spekulieren ja hier schließlich nur. Gruß, Nils

Moin, mit "der Cluster" meinst du jetzt ein Hyper-V-System? Ja, dann ist das grundsätzlich möglich. Genau wie mit jeder anderen wichtigen Virtualisierungsplattform kann man auch mit dieser die technische Basis für VDI abbilden. Aber das ist vermutlich nicht die eigentliche Frage? Gruß, Nils

Moin, ist das eine Lernaufgabe? Oder geht es um was Produktives? Für mich klingt das nach einer Basisfrage zum Datenbankdesign, die mich überrascht, wenn es um eine lauffähige Anwendung mit dem genannten Einsatzzweck geht. Wie weit bist du mit Datenmodellierung vertraut? Gruß, Nils

Moin, so: https://www.google.de/search?q=sql+server+execution+plan In deinem Fall würde ich aber auch noch mal mit dem Hersteller sprechen, ob die Vermutung bezüglich der Berechtigungsprüfung im Anwendungscode zutrifft. Mit "echter" Windows-Authentisierung kann es zu solchen Phänomenen eigentlich nicht kommen. Gruß, Nils

Moin, nein, ist es nicht. Das hebt dieses Board von anderen Foren ab, Nein, wird es nicht. Es ist nur nicht immer notwendig, dies im öffentlichen Thread zu diskutieren. Und jetzt bitte mal am Riemen reißen und nicht mit dem Finger auf andere zeigen. Danke. Gruß, Nils

Moin, Leute - könnt ihr das persönliche Gepöbel mal bleiben lassen und auf die Sachebene zurückkommen? Wenn es fachlich nichts mehr zu sagen gibt, müsst ihr so einen Thread ja nicht auf diese Weise am Leben erhalten ... Gruß, Nils

Moin, bevor ich so eine Umstellung machte, überprüfte ich noch näher die Zusammenhänge. So wäre es sinnvoll, sich für beide Szenarien die Ausführungspläne anzusehen. Das kann Hinweise geben, aus welcher Richtung die Performanceprobleme kommen. Misstrauisch macht mich die Aussage des Herstellers. Wenn er empfiehlt, die ODBC-Verbindung (wirklich ODBC? Das ist Technik der Neunziger ...) über einen festen User herzustellen, verliert ihr nicht nur die Identifikation des Users, sondern effektiv auch sämtliche Windows-Berechtigungen - es wäre dann ja immer derselbe User. Das wiederum deutet darauf hin, dass die Datenbank tatsächlich an Windows vorbei die Berechtigungen überprüft. Das ist jetzt nur Spekulation, aber wenn es so wäre, wäre es weitab jeder Best Practice. In dem Fall wäre es ein ausgesprochen schmutziger Workaround, auf Userberechtigungen umzustellen - die Nachteile liegen ja auf der Hand. Gruß, Nils

Moin, das überrascht - und es sollte m.W. so nicht sein. Gibt es Besonderheiten in der Umgebung, sind z.B. die User in sehr vielen Gruppen Mitglied? Finden evtl. innerhalb der Datenbank eigene Abfragen der Berechtigungen statt, die am normalen Windows-Berechtigungssystem vorbeigehen? Gruß, Nils

Moin, ich wage auch zu bezweifeln, dass daraus eine Beschleunigung resultiert. Geprüft wird, ob das Access Token des Users die nötigen Einträge enthält, die in den Berechtigungen auftauchen. Das macht praktisch keinen Unterschied, ob die betreffende SID die des Users ist oder einer der Gruppen, denen er angehört. Dafür hätte man bei deinem Ansatz den Nachteil, dass die Pflege der Berechtigungen sehr aufwändig wird. Gruß, Nils

Moin, das ist ja auch nicht der Grund für eine lokale Firewall. Gruß, Nils

Moin, das wage ich zu bezweifeln, da läuft ja kein Windows. Gruß, Nils

Moin, du kannst in der PowerShell natürlich auch direkt Ordner löschen und da die Variable einsetzen. Das dürfte erheblich einfacher sein, als den Wert der Variablen irgendwie auf die CMD-Ebene zu bekommen. Wenn es CMD sein soll, könntest du dir die Rechnerei sparen und robocopy zweckentfremden. Dort kannst du ein Dateialter angeben und die Daten z.B. nach NUL verschieben. Gruß, Nils

Moin, also das, was ich gestern um 11:51 und 11:21 schon vorgeschlagen hatte. Aber schön, dass es jetzt geht. Und danke für die Rückmeldung. Gruß, Nils

Moin, ich meine auch die Fragen aus Das wären noch "einfache" Möglichkeiten, die zu dem Fehler führen können. Gruß, Nils

Moin, die Einträge sehen OK aus. Wenn meine oben gestellten Fragen geprüft und befolgt wurden und es damit kein Ergebnis gab, kann ich über ein Forum nichts mehr tun. Gruß, Nils

Moin, ah, das macht es ja noch einfacher. Ist also nur zu betrachten, ob man die Konfig übertragen will oder sich das spart. Gruß, Nils

Moin, die ist doch "ab Werk" an, oder? Gruß, Nils

Moin, "Unterbruch" - lass mich raten, Eidgenosse? Vor so einem Vorhaben sollte man immer prüfen, ob eine DHCP-Migration überhaupt nötig ist. Gerade in SBS-Netzwerken ist das selten der Fall. Also: Gibt es denn Konfigurationen, Reservierungen usw. in nennenswertem Umfang, für die man überhaupt migrieren müsste? In den meisten Fällen reicht Folgendes: Auf dem bestehenden DHCP-Server die Lease-Dauer reduzieren auf wenige Stunden. Neuen DHCP einrichten und konfigurieren, Dienst abgeschaltet lassen. Alten DHCP abschalten, neuen einschalten. Da Windows-DHCP vor dem Vergeben einer Adresse prüft, ob diese im Netzwerk schon antwortet, kann man sich in kleinen Netzen sogar das Koordinierte Umschalten der Dienste sparen und den neuen DHCP einfach parallel einrichten. Gruß, Nils

Moin, toll, dass ihr so viele Details über ESX wisst. Hier geht es aber um Hyper-V - back to topic, schlage ich mal vor. Gruß, Nils PS. auf hoher Flughöhe stimme ich Norberts Antwort zu.

Moin, hat er beides schon beantwortet. Es fehlen hingegen noch Antworten auf ein paar Fragen von mir. Gruß, Nils

Moin, ich stolpere über den "unbekannten" Knotentyp. War der alte DC mal WINS-Server? Was steht in der Registry unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters\EnableProxy für ein Wert? Dann noch ein letzter Versuch: Was gibt Folgendes in der PowerShell zurück mit dem Namen des "vorhandenen" DCs? Get-ADComputer -Identity 'DEINSERVER' -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName Gruß, Nils

Moin, ist das eine saubere Neuinstallation oder ein Klon aus einer Vorlage? Falls Letzteres: Sauber installieren. Ist schon ein Computerkonto für den Rechnernamen vorhanden? Falls ja: löschen. Ist in den DNS-Clienteinstellungen des neuen Servers etwas anderes als "Primäre und verbindungsspezifische DNS-Suffizes anhängen" aktiviert? Falls ja: ändern. Weitere Ursachen für diesen Fehler wären exotisch, aber es gäbe noch welche. Dafür wäre es hilfreich wenn du, worum ich ja schon gebeten habe, mal angibst, was das Eventlog ggf. noch hergibt. Gruß, Nils

Moin, du hast aber auf dem neuen DC das AD noch nicht eingerichtet, oder? Ich würde als nächstes Folgendes tun: den neuen DC völlig neu installieren Updates drauf, aber keine Rollen IP-Konfig korrekt setzen noch mal versuchen erst nach dem Domain Join die Rollen hinzufügen und das AD einrichten als zusätzlichen DC der vorhandenen Domäne Meldet der vorhandene DC sonst irgendwelche Fehler, die (auch nur entfernt) mit dem Problem zusammenhängen können? Gruß, NIls

Moin, DNS-Cache gelöscht? ipconfig /flushdns Gruß, Nils

Moin, die DNS-Konfig des vorhandenen DC ist falsch. NIEMALS einen DNS-Server angeben, der andere Daten enthält. Sowas macht man über einen Forwarder im DNS-Server, nicht in der Client-Konfig. Die DNS-Konfig des neuen DC ist auch falsch. Er versucht erst, bei sich selbst zu gucken, da wird er aber nichts finden. Genau darum habe ich auf meinen FAQ-Artikel verwiesen ... Gruß, Nils