NilsK

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

Moin, hm, mag sein. Das ADAC gibt es seit Server 2008, daher die Annahme, dass es im SBS 2011 auch vorhanden sei. Kann aber sein, dass das, selbst wenn es da war, den Papierkorb noch nicht konnte. Gruß, Nils

Moin, dann jetzt bitte mal systematisch: IP-Konfig des vorhandenen DCs IP-Konfig des neuen Servers was genau machst du auf welchem Server und was passiert? Gruß, Nils

Moin, nein, im ADUC sieht man die nicht. Starte mal das AD Administrative Center, dort sollte das sichtbar sein. Gruß, Nils

Moin, also ist der neue Server noch nicht Domänenmitglied, und du versuchst von diesem neuen Server aus, diesen in die Domäne aufzunehmen? DNS ist anhand meiner Hinweise korrekt eingerichtet? Versuch es mal mit einem Neustart, dann keine Verbindung zu einem anderen Rechner aufbauen, sondern direkt den Domain Join versuchen. Gruß, Nils

Moin, was genau machst du auf welchem Server, wenn du die Meldung erhältst? Schuss ins Blaue: So eine Meldung erscheint manchmal, wenn man auf dem Non-Domain-Rechner bereits eine Session zu einem Domänenrechner mit einem Domänenkonto offen hat (z.B. Dateiserver-Zugriff mit separater Konten-/Kennnworteingabe). nslookup ist kein geeignetes Tool, um die Namensauflösung zu testen (warum?). Besser und einfacher: ping auf den FQDN. DNS ist richtig eingerichtet? Hinweise Gruß, Nils PS. Und die Firewall hinterher wieder einschalten.