NilsK

Moin, also hat die Gesamtumgebung 10 Anwender? Oder sind es insgesamt mehr? Eine Image-Lösung wirst du nur schwer automatisieren können, zudem ist sie sehr hardwareabhängig. In der Praxis wird dir ein veraltetes Image wenig bringen, ebenso die relativ lange Zeit (und das Risiko) für die Wiederherstellung. Daher würde ich so ein "Spiegel"-Konzept niemals auf Hardware-Basis machen. Wenn überhaupt, dann per VM und Replikation, das beseitigt beide Einschränkungen. Ja, das würde bedeuten, die Umgebung auf virtuelle Maschinen umzustellen. In einer 10-User-Umgebung könnte man darüber diskutieren, aber allgemein ist auch von "Mischservern" abzuraten. Je mehr Applikationen, desto höher die Fehlerwahrscheinlichkeit und vor allem die Auswirkungen bei einem Fehler. Schon in kleineren Umgebungen würde man daher dazu neigen, Funktionen auf mehrere VMs zu verteilen. Im Fall der Virtualisierung kannst du mit einer einzigen Standard-Lizenz auf einem Host schon zwei VMs betreiben und damit wenigstens eine grundlegende Aufteilung erreichen. Wichtig: Jedes Image- oder Replikationsverfahren funktioniert nur, wenn die Applikationen das vertragen, sie dürfen dabei keine Inkonsistenzen im Datenbestand erzeugen. Meist ist das gegeben, aber nicht immer, daher ist das zu prüfen. Und noch wichtiger: Ein Wiederanlaufkonzept ersetzt kein Recovery. Simples Beispiel: Eine versehentlich gelöschte Datei ist auch im Image bzw. im Replikat gelöscht. Ein Backup, das sich an den nötigen Wiederherstellungserfordernissen ausrichtet, ist also zusätzlich Pflicht. Man sollte nicht immer nur an die "Katastrophe" denken, reale Nutzungsausfälle finden meist auf anderen Ebenen statt. Gruß, Nils

Moin, so ein "Spiegelserver" ist i.d.R. nicht der richtige Ansatz. In der Praxis stellt sich das doch wesentlich aufwändiger und fehlerträchtiger dar, als man zunächst annimmt. Im Grundsatz könnte man sowas zwar etwa über eine VM-Replikation erreichen (der "Hauptserver" ist eine VM auf Virtualisierungs-Hostserver 1, die auf den Virtualisierungs-Hostserver 2 laufend repliziert wird), aber gerade bei solchen "Sammel-Servern" mit AD, ERP usw. ist das Risiko hoch, dass dann im Fall des Falles doch nicht alles funktioniert. Von Versuchen, dort mit regelmäßigen Images zu arbeiten, rate ich komplett ab. Wenn überhaupt, dann sollte man sowas - wie oben skizziert - auf Basis virtueller Maschinen machen und damit die Hardware-Abhängigkeit reduzieren. Wie groß ist denn die Umgebung, von wie vielen Anwendern sprechen wir? Gruß, Nils

Moin, das ist ja genau das, was ich meine: Erzeugen des Ordners genau einmal in dem Moment, in dem der User neu angelegt wird (Skript 1). Verbinden des existierenden Ordners beim Logon des Benutzers (Skript 2). Das kann man durchaus per PowerShell machen, aber wenn man sich damit nicht auskennt, ist Batch einfacher. Skript 1: Angabe des Usernamens und ggf. weiterer Details Erzeugen des Users im AD (PS: New-ADUser, Batch: net user oder dsadd user) Erzeugen des Home-Ordners in einer bestehenden Freigabe, ggf. mit Berechtigungen Skript 2: Verbinden des Homes mit der Angabe der übergeordneten Freigabe und der Systemvariable %username%, ist per PowerShell und Batch ähnlich einfach; Beispiele wirst du im Web viele finden Gruß, Nils PS. es wäre nett, wenn du auf Lesbarkeit deiner Beiträge achtest und grundlegende Zeichensetzung und Groß- und Kleinschreibung einsetzt.

Moin, und das bedeutet, dass das Homeverzeichnis erzeugt werden soll? Das wäre sehr untypisch, denn schließlich muss das nur genau einmal erzeugt werden. Üblicherweise wird in einem Logonscript ein bestehendes Homeverzeichnis verbunden - das ist eine ganz andere Aufgabe und viel einfacher. Solltest du vielleicht noch mal klären. Nein, sorry, aber fertige Scripte schreiben wir hier normalerweise nicht. Das wäre auch wenig zielführend, wenn wir dir deine Aufgaben erledigen, dann hast du nichts gelernt und jemand anders deine Aufgabe erledigt. Gruß, Nils

Moin, also hast du eine exakte Aufgabe gestellt bekommen? Wie lautet die denn? Sonst raten wir hier nur rum und es passt am Ende nicht. Beim Anlegen eines Users über das GUI kannst du direkt ein Home erzeugen lassen. Beim Anlegen per PowerShell gibst du halt in dem Skript, mit dem du den User erzeugst, auch das Kommando, den Ordner zu erzeugen, den Namen dafür hast du in dem Fall ja. Und wenn es darum geht, für bestehende User ein Home zu erzeugen, dann liest man die User aus und lässt in einer Schleife die Ordner anlegen. Dein Skript schlägt deshalb fehl, weil es in der ersten Zeile erwartet, einen Parameter übergeben zu bekommen. Daher stellt die PowerShell beim manuellen Ausführen auch die Nachfrage. Du müsstest diese Stelle ersetzen durch eine Funktion, die den Anmeldenamen des Users zurückgibt, der das Skript aufruft. Dafür käme z.B, die Systemvariable %USERNAME% in Frage. Noch dazu hast du das Skript offenbar von einer Webseite kopiert, weshalb falsche Anführungsstriche darin stehen. Tippe alle Anführungsstriche in einem Texteditor neu. Gruß, Nils

Moin, einmal reicht: Gruß, Nils

Moin, was genau möchtest du denn erreichen? Dass jeder User ein Homeverzeichnis hat? Das ließe sich wahrscheinlich einfacher erreichen. Allgemein würde man sowas eher zentral erzeugen (z.B. in dem Moment, wenn der User im AD angelegt wird; oder auch einmalig für alle bestehenden Userkonten) als es beim Anmelden eines Users zu tun - nicht zuletzt könnte man damit Berechtigungsprobleme vermeiden. Also beschreibe doch bitte noch mal genau die Aufgabe und das Ziel. Gruß, Nils

Moin, der Hinweis auf das Auditing ist korrekt. Vorsicht, das muss man an zwei Stellen aktivieren: in der lokalen Richtlinie (gpedit.msc oder per AD-GPO) des Rechners, wo die ini-Datei liegt, die Überwachung als solche aktivieren im Dateisystem das jeweilige Objekt (also vermutlich die ini-Datei) zur Überwachung konfigurieren, das geht über den Berechtigungsdialog. In dem Fall sollte Erfolgsüberwachung für "Jeder" ausreichen. Die Informationen finden sich dann im Security-Eventlog des Rechners, auf dem die Überwachung stattfindet. Hinterher daran denken, die Überwachung wieder abzuschalten. Und noch mal Vorsicht: Solche Auditing-Daten auszuwerten, kann sehr aufwändig sein, weil ein einfacher Dateizugriff leicht mal -zig Detailevents erzeugt. Gruß, Nils

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