NilsK

Moin, hilft dies? https://www.faq-o-matic.net/2010/05/21/sql-server-2008-admins-haben-keine-sysadmin-rechte/ Gruß, Nils

Moin, ein paar stichwortartige Empfehlungen: die Domäne nicht "neu machen", sondern beibehalten. Auch in kleinen Umgebungen ist das fast immer die bessere Wahl. Dazu einen neuen DC als zusätzlichen DC in die vorhandene Domäne einbinden und "normal" replizieren lassen. Korrekt, alle Clients (also auch alle anderen Server) müssen die IP-Adresse des neuen DCs als DNS-Server eingetragen bekommen. Die Fileserver-Daten kannst du dann einfach 1:1 auf den neuen Server kopieren, z.B. mit robocopy, das nimmt auch die Berechtigungen mit. Einen Neuaufbau der Beechtigungen würde ich immer nach einer Migration machen, alles andere ist so gut wie immer unpraktikabel. Also: Nach der Übertragung auf den neuen Server läuft alles wie bisher, und dann macht man sich in Ruhe Gedanken, was man wie neu strukturieren möchte und wie man das umsetzt. In einer Umgebung mit mehr als ca. 10 Benutzern sollte man immer mehr als einen DC haben. Trotzdem muss der 2003-DC weg, also einen "dritten" DC installieren und dann den 2003 geordnet entfernen. AD-Backups niemals mit irgendwelchen Kopien, VM-Konzepten oder sonstwas machen, sondern nur auf unterstütztem Weg. Als o über ein Systemstate-Backup (Bordmittel) oder einen AD-Agenten. AD niemals mit Hyper-V auf einem physischen Server kombinieren. Gruß, Nils

Moin, Vorsicht: meines Wissens gelten beim Downgrade immer die Lizenzbedingungen der tatsächlich eingesetzten Version. Ob das unter 2012 erlaubt war, wäre in dem Fall egal, wichtig wäre, ob man 2008 schon zweimal mit einer Hostlizenz einsetzen durfte. Ob das so war, habe ich nicht mehr im Kopf. Gruß, Nils

Moin, weil man in einem Systemhaus viele Tätigkeiten und Projekte haben kann, die mit "Servern" gar nichts zu tun haben. Ist bei uns (um 100 MA) nicht anders. Und der TO hat ja auch nicht die Aufgabe, das technisch umzusetzen, sondern er soll einen Lizenzfrage klären. Also alles ganz nachvollziehbar. Gruß, Nils

Moin, es gibt kein "Replizierrecht" und auch keine "Move Rights". Relevant ist der Grundsatz, dass auf dem Host die Lizenzen für die VMs vorliegen müssen. Vereinfacht gesagt: der jetzige "alte" Host muss, wenn dort 5 Windows-Server-VMs laufen, drei WS-Standard-Lizenzen haben (weil jede Std-Lizenz 2 VMs erlaubt) der neue Host muss ebenfalls drei Standard-Lizenzen haben Da der "alte" Host anscheinend weiter laufen soll, muss diese Lizenzzuweisung auch beibehalten werden Also eigentlich ziemlich einfach. Vielleicht sollte euer Vertrieb sich mal in diesen Basics fit machen und die richtigen Ansprechpartner beim Distributor identifizieren. Gruß, Nils

Moin, vor allem handelt es sich um ein Missverständnis. In einer Enhanced Session über VMConnect.exe kannst du "User-Devices" innerhalb der Session nutzen, vergleichbar dem USB-Zugriff in einer RDP-Session. Schließt du die Session, ist das Device weg. Für USB-Dongles usw. ist das nicht geeignet, es ist nur für den Ad-hoc-Zugriff auf USB-Sticks usw. gedacht. Unabhängig vom Hypervisor ist die einzige sinnvolle Möglichkeit für sowas ein USB-Geräteserver, denn spätestens wenn Host-Cluster ins Speil kommen, reicht auch VMwares USB-Integration nicht mehr aus. Wenn du per Hyper-V-Manager einen Konsolenzugriff erhältst, besteht kein grundsätzliches Zugriffsproblem, denn das geschieht auch per VMConnect.exe. Dann wäre bei Bedarf zu klären, warum der direkte Aufruf nicht funktioniert. Gruß, Nils

Moin, kannst du eine Konsolenverbindung direkt aus dem Hyper-V-Manager herstellen, ohne den ausdrücklichen Aufruf von vmconnect? Gruß, Nils

Moin, das heißt genau was? Was ist dort geschehen, um die VM zu erzeugen? Und wieso "die VM" - im Ausganspost war von mehreren VMs die Rede? Von welchem Host-System sprechen wir bei Quelle und Ziel? Gruß, Nils

Moin, naja, Whatsapp hat da auch eine andere Perspektive, denen geht es nicht um Schutz ... aber ein schönes Beispiel, dass Datenschutz oder auch Schutz von Geschäftsdaten nur funktioniert, wenn der Anwender mitmacht. Gruß, Nils

Moin, den Quellen nach ist das eben keine Exchange-Einstellung, sondern eine von iOS, die sich anscheinend nur per MDM steuern lässt. Gruß, Nils

Moin, es geht um Windows 10 als Host? Oder wie? Der Ex- und Import ist eigentlich in Hyper-V seit mehreren Jahren sehr einfach: Den ganzen VM-Ordner auf die Zielmaschine kopieren (ausdrücklich Exportieren ist nicht nötig) und dort den Import starten. Im Import-Assistenten gibt man nur den Ordner an, in dem die VM-Konfig gespeichert ist, die VM selbst wird dort nicht angezeigt, das ist optisch verwirrend. Wenn man den richtigen Ordner erwischt hat, zeigt die nächste Seite dann die VM an. Gruß, Nils

Moin, rein technisch spricht nichts dagegen, "zunächst" mit produktiven VMs unter 2012 R2 zu arbeiten und den CAL-Erwerb hinauszuschieben. Zumal in wenigen Wochen Windows 2019 kommt, da könnte es schlauer sein, bei Bedarf (z.B. wenn man wegen des Mainstream-Supports* dann doch 2012 R2 loswerden wollte) dann gleich 2019-CALs zu nehmen. Mit denen dürfte man auch auf 2016-Server zugreifen. Der Hyper-V könnte jetzt trotzdem mit 2016 laufen. Solange der nur Host ist und keine User direkt darauf zugreifen, erfordert das keine 2016-CALs. Technische Gründe für 2016 (oder auch 2019) gibt es leider nur wenige, abseits von speziellen Anforderungen. * wobei der Mainstream-Support bei Mittelstandskunden selten ein Argument ist, der Extended Support ist wichtiger. Gruß, Nils

Moin, das ist jetzt alles etwas verworren ... zunächst mal denke ich, sollte man die Anforderungen des Kunden klären. Ins Blaue hinein kann man schlecht Empfehlungen aussprechen. Trotzdem ein paar technische Aspekte: sobald produktive Server, auf die Anwender zugreifen, mit 2016 laufen, braucht der Kunde 2016-CALs. Mit den bestehenden 2008-CALs dürfen Anwender nur auf 2008-/R2-Server zugreifen. Eine VM auf dem Backupserver wiederherzustellen, preist Veeam zwar gern an, sinnvoll ist es aber nur selten. Schließlich ist der Backupserver ein Backupserver und kein Host und hat im Zweifel Aufgaben, die seine Ressourcen belegen. Die Standard-Lizenz erlaubt den Betrieb von zwei Windows-Server-VMs. Auf dem Host könnte man also zwei VMs betreiben. Da der Backupserver schon in der physischen Instanz eine Funktion hat. wäre dort nur eine VM erlaubt. Der Support für Windows Server 2008/R2 endet am 14. Januar 2020. Es gibt im AD keinen "Backup-DC". Ein DC sollte nur DC sein und nichts anderes ausführen. Gerade die Kombination mit einem Backupserver ist technisch zwar möglich, aber nur selten sinnvoll. Die Kombination DC, Backupserver und Hyper-V-Host birgt das Risiko technischer Probleme. Da Hyper-V in Windows Server 2016 ein verändertes Update-Verfahren nutzt, wäre der Betrieb von 2008-VMs mit erhöhtem Aufwand verbunden. Zu den eigentlichen strategischen Fragen kann man auf dieser Ebene nichts Sinnvolles beitragen. Gruß, Nils

Moin, korrekt, Die Berechtigungsstruktur für Hyper-V gab es mal, aber die hat Microsoft entfernt, warum auch immer. Nicht, dass die gut zu nutzen gewesen wäre, aber jetzt gibt es wirklich gar nichts mehr. Aber selbst damit hätte sich das nur auf Hyper-V bezogen, nicht auf Cluster. Hyper-V-Administratoren sind ggf. eine Alternative, wenn es wirklich nur um Hyper-V geht, nicht um den unterliegenden Host und nicht um den Cluster als solchen. Aber dann ist das eben auch nur "alles oder nichts". Ergänzend noch zu JEA, das Microsoft als Ansatz positioniert, das aber sehr aufwändig ist: [Just Enough Administration: Material von der CDC Germany 2017 | faq-o-matic.net] https://www.faq-o-matic.net/2017/06/12/just-enough-administration-material-von-der-cdc-germany-2017/ Die Videos der CDC 2017 gibt es mittlerweile kostenlos, aber nur gegen Registrierung: https://www.hyper-v-server.de/news/session-video-mitschnitte-der-cdc-germany-2017-jetzt-kostenlos-verfuegbar/ Gruß, Nils

Moin, lokaler Admin auf den Nodes? Damit dürfte er dort "alles" können. Gruß, Nils

Moin, auch zu kurz gedacht. "Einheit" ist eine Einheit, also Gramm, Meter oder was immer. Keine Zahl. Die Zahl in deinem Beispiel wäre ein separates Feld "Anzahl" - das hat aber in der Artikeltabelle nichts zu suchen, weil es eine Eigenschaft einer konkreten Bestellung bzw. eines Einkaufs ist (separates Objekt, separate Tabelle(n)). Nun wird man schnell feststellen, dass "Einheit" vielleicht lieber in einer separaten Tabelle stehen sollte, die 1:n mit der Artikeltabelle verknüpft ist. Vielleicht will man dann noch steuern, ob eine Einheit auch teilbar ist oder nicht (1,5 kg kann es etwa bei Mehl geben, aber vielleicht gibt es Artikel, die man nur in ganzen Metern verkaufen kann und nicht in halben). Und bei der Gelegenheit merkt man, dass es ohne ein konzentriertes Datenmodell eben nicht geht. Gruß, Nils

Moin, kann ich dir nicht sagen. Ist aber an der Stelle auch egal: Offenbar gibt es ja etwas in der Applikation, das die Windows-Berechtigungen (bzw. Gruppenmitgliedschaften) ausliest, das muss ja ohnehin an Windows angepasst sein. Auf einem Linux-System bräuchte man dann eine andere Logik dafür - Portabilität erfordert nun mal in der Regel Anpassungen im Detail. Wenn man der Meinung ist, das so machen zu müssen, wäre es aber vielleicht schlauer, dies einmal beim Verbindungsaufbau zu erledigen (wenn der ein paar Sekunden länger läuft, ist das meist egal) und nicht erst beim Zugriff jedes Mal mit viel Zeitaufwand aufzulösen. Speichert man das Ergebnis der Auflösung einmal in einer Tabelle, dann kann man auf die schnell zugreifen. Effektiv würde man das Access-Token-Prinzip von Windows nachbilden und nach diesem Schritt die Vorteile dieses Mechanismus nutzen. Bleibt aber weiterhin Spekulation, sodass das für den Thread hier auch nicht weiterhilft. Gruß, Nils

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