Server-Client Struktur - Umbau/Erweiterung zu Terminalserver

[#1]

Hallo,

ich hätte ein paar grundlegende Fragen zum richtigen Verständnis hinsichtlich DATEV Server-Client und Terminalserver Struktur.

Im Moment ist die Lage sehr einfach, es gibt einen Fileserver+darauf der Lima, diverse Clients, kein KommServer o.ä.

Laut den Beschreibungen die ich in den DATEV Dokumenten gesehen habe, ist die Struktur bei einem Terminalserver erweitert auf Clients, FileServer (nach wie vor nötig) und den Terminalserver.

Ist es somit möglich unsere Server-Client Struktur um einen (kleinen) Terminalserver zu erweitern, auf dem z.B. 2-3 Mitarbeitrinnen die in Elternzeit sind den Zugriff auf DATEV zu ermöglichen?

Würde in diesem Falls die restliche Server-Client Struktur ohne eine Änderung machen zu müssen weiter funktionieren? Könnten auch die DATEV Updates weiter installiert werden?

Wäre dies somit ein Mischbetrieb und hat diesen Aufbau jemand vielleicht?

Könnte man den Terminalserver dann auch nach und nach erweitern (mehr Ressourcen geben, Hyper-V) und so nach und nach alle Clients auf den Terminalserver umziehen?

Ist hierbei von DATEV Seite aus eine Lizenzanpassung oder ähnliches vorzunehmen, oder kriegt das DATEV im Grunde gar nicht mit?

An Lizenzen würde den ersten Überlegungen nach eine (virtuelle) Windows Server Lizenz + RDS Cals anfallen. Ggfs. Office Lizenzen. Gibt es dabei noch mehr?

Danke schon mal vorab für Hinweise zu diesem Thema bzw. Aussagen ob diese Überlegungen zutreffen.

Gruß
Matthias Sammel

[#2]

Hi,

alle Überlegungen sind soweit korrekt. 

Mischbetrieb ist kein Problem.

DATEV ist es "egal" ob die Anwendung auf Client oder TS läuft.

Die DATEV-Lizenz wird zur Laufzeit einem Benutzer zugeordnet (Betriebsstättenzähler).

Bzgl. der Office-Lizenzen sei auf OpenLizenzen hingewiesen oder ein passendes M365-Paket (TS-Fähigkeit).

http://www.datev.de/fachschriften --> Terminalserver einrichten

Dies ggf. zur groben Richtung bei dem Einrichten des TS. Die eigenen Gegebenheiten sollten entsprechend adaptiert werden.

Beste Grüße

Chr.Ockenfels

[#3]

@matthiass ,

die Idee ist 'charmant' und klingt nach einer Universallösung.

Allerdings befürchte ich, dass man dann die 'alten' Nachteile eines Client-Server-Netzwerks beibehält und sich neuen Aufwand, neue Probleme und Kosten 'einbrockt'.

... hatte auch schon gedanklich mit einer ähnlichen Konstruktion 'gespielt' 😉

[#4]

Kleine Ergänzung zu @chrisocki , die Office Lizenzen auf dem Terminalserver müssen zwingend OpenLicense sein, bei Microsoft365 min. E3 Plan. Darunter lässt sich nichts lokal installieren. Es empfiehlt sich, die Lizenzfrage mit einem Fachvertrieb zu diskutieren, nichts ist ärgerlicher als eine falsche Lizenz.

[#5]

---

@einmalnoch  schrieb:

Kleine Ergänzung zu @chrisocki , die Office Lizenzen auf dem Terminalserver müssen zwingend OpenLicense sein, bei Microsoft365 min. E3 Plan. Darunter lässt sich nichts lokal installieren. Es empfiehlt sich, die Lizenzfrage mit einem Fachvertrieb zu diskutieren, nichts ist ärgerlicher als eine falsche Lizenz.

---

Und da wird der Mischbetrieb zu Arbeit....

[#6]

---

@einmalnoch  schrieb:

Kleine Ergänzung zu @chrisocki , die Office Lizenzen auf dem Terminalserver müssen zwingend OpenLicense sein, bei Microsoft365 min. E3 Plan.

---

Es muss keineswegs mindst. Microsoft 365 E3 sein. Reichen tut auch ein Microsoft Apps for Enterprise, alternativ Office 365 E3/E5 oder Microsoft 365 Business Premium/E3/E5.

Auch die Abhängigkeiten zwischen Betriebssystem und Office Version sollten Beachtung finden.

Darunter lässt sich nichts lokal installieren.

---

Lokal kann man fast alles betreiben, auch Home & Business.

[#7]

---

@matthiass  schrieb:

Hallo,

ich hätte ein paar grundlegende Fragen zum richtigen Verständnis hinsichtlich DATEV Server-Client und Terminalserver Struktur.

Im Moment ist die Lage sehr einfach, es gibt einen Fileserver+darauf der Lima, diverse Clients, kein KommServer o.ä.

Laut den Beschreibungen die ich in den DATEV Dokumenten gesehen habe, ist die Struktur bei einem Terminalserver erweitert auf Clients, FileServer (nach wie vor nötig) und den Terminalserver.

Ist es somit möglich unsere Server-Client Struktur um einen (kleinen) Terminalserver zu erweitern, auf dem z.B. 2-3 Mitarbeitrinnen die in Elternzeit sind den Zugriff auf DATEV zu ermöglichen?

Ja.

Würde in diesem Falls die restliche Server-Client Struktur ohne eine Änderung machen zu müssen weiter funktionieren? Könnten auch die DATEV Updates weiter installiert werden?

Ja.

Wäre dies somit ein Mischbetrieb und hat diesen Aufbau jemand vielleicht?

---

Das Szenario ist nicht unüblich.

---

Könnte man den Terminalserver dann auch nach und nach erweitern (mehr Ressourcen geben, Hyper-V) und so nach und nach alle Clients auf den Terminalserver umziehen?

---

Ja.

Ist hierbei von DATEV Seite aus eine Lizenzanpassung oder ähnliches vorzunehmen, oder kriegt das DATEV im Grunde gar nicht mit?

Hier ist nichts anzupassen.

---

An Lizenzen würde den ersten Überlegungen nach eine (virtuelle) Windows Server Lizenz + RDS Cals anfallen. Ggfs. Office Lizenzen. Gibt es dabei noch mehr?

---

Das kommt auf die jetzige Ausstattung an. Minimal nur RDS CALs. Zusätzlich dann ggf. Server Betriebssystem, Server CALs, Office CALs, VPN, Arbeitsplatz nach ArbStättV/DSGVO, Telefon, ...

[#8]

@chrisocki , @MBehrens , @einmalnoch ,

... wenn ein Mischbetrieb technisch tatsächlich 'kein Problem' ist, hätte ich schon große Lust, mich mit dem Thema "Umstieg von Client-Server- auf WTS-Betrieb" ganz vorsichtig vertraut zu machen, also quasi erstmal einen Fuß in's kalte Wasser zu strecken, bevor man eine "Arschbombe" in ein seichtes Gewässer riskiert😀.

Office-Volumen-Lizenzen hätte ich bereits zur Verfügung. An zusätzlichen PCs wird es auch nicht scheitern. Die Windows-Terminal-Clients stellen ja keine großen Ansprüche.

... habe ich das richtig verstanden, dass es keinen "Point of No Return" gibt und dass man also versuchsweise damit experimentieren könnte, z.B. mit einem WTS und zwei zusätzlichen Arbeitsplätzen ?

[#9]

---

@vogtsburger  schrieb:

@chrisocki , @MBehrens , @einmalnoch ,

... wenn ein Mischbetrieb technisch tatsächlich 'kein Problem' ist, hätte ich schon große Lust, mich mit dem Thema "Umstieg von Client-Server- auf WTS-Betrieb" ganz vorsichtig vertraut zu machen, also quasi erstmal einen Fuß in's kalte Wasser zu strecken, bevor man eine "Arschbombe" in ein seichtes Gewässer riskiert😀.

Office-Volumen-Lizenzen hätte ich bereits zur Verfügung. An zusätzlichen PCs wird es auch nicht scheitern. Die Windows-Terminal-Clients stellen ja keine großen Ansprüche.

---

Es ist kein Problem. Was sollte das Problem sein? Wurde ja eindrucksvoll von @MBehrens oben dargestellt. Das war aber schon immer so.

[#10]

---

@MBehrens  schrieb:

---

@einmalnoch  schrieb:

Kleine Ergänzung zu @chrisocki , die Office Lizenzen auf dem Terminalserver müssen zwingend OpenLicense sein, bei Microsoft365 min. E3 Plan.

---

Es muss keineswegs mindst. Microsoft 365 E3 sein. Reichen tut auch ein Microsoft Apps for Enterprise, alternativ Office 365 E3/E5 oder Microsoft 365 Business Premium/E3/E5.

Wo liegt der Unterschied von min. E3 Plan und Office 365 E3/E5 oder Microsoft 365 Business Premium/E3/E5?

---

@MBehrens  schrieb:

---

Auch die Abhängigkeiten zwischen Betriebssystem und Office Version sollten Beachtung finden.

Darunter lässt sich nichts lokal installieren.

---

Lokal kann man fast alles betreiben, auch Home & Business.

---

Lokal bedeutet nicht in der Cloud. Wie wollen Sie Home & Business auf einem TS installieren?

[#11]

---

@einmalnoch  schrieb:

---

@MBehrens  schrieb:

---

@einmalnoch  schrieb:

Kleine Ergänzung zu @chrisocki , die Office Lizenzen auf dem Terminalserver müssen zwingend OpenLicense sein, bei Microsoft365 min. E3 Plan.

---

Es muss keineswegs mindst. Microsoft 365 E3 sein. Reichen tut auch ein Microsoft Apps for Enterprise, alternativ Office 365 E3/E5 oder Microsoft 365 Business Premium/E3/E5.

Wo liegt der Unterschied von min. E3 Plan und Office 365 E3/E5 oder Microsoft 365 Business Premium/E3/E5?

---

Im Preis und Featureset. Man kann auch mit Microsoft 365 Apps for Enterprise auf einen TS starten. Etwa 2/3 günstiger als Microsoft 365 E3.  

---

@einmalnoch  schrieb:

Lokal bedeutet nicht in der Cloud. Wie wollen Sie Home & Business auf einem TS installieren?

---

In dem Szenario bedeutet lokal ganz klar nicht Terminal Server 😉

[#12]

---

@matthiass schrieb:

Danke schon mal vorab für Hinweise zu diesem Thema bzw. Aussagen ob diese Überlegungen zutreffen.

---

Was für eine Server-CPU ist es denn? Bitte unbedingt wie bei DATEV zum Thema Virtualisierung: Erfahrungen aus der Praxis steht den SingleThread Wert von 2000 Punkten bei CPU Benchmarks beachten.   

Einfache / reine Fileserver haben ja meist viele Kerne bei ca. 2GHz. Das wird mir DATEV bedingt bzw. keinen Spaß machen. Speziell kein WTS, auf dem zu max. 12 User gleichzeitig gearbeitet wird. Setzen Sie einfach mal einen Intel Core i5-10500 als Vergleich daneben bzw. die CPU, die jetzt in den Client verbaut ist. Desktop CPUs schaffen so ca. 2500 Punkte. Spitzen CPUs schaffen auch 2800 Punkte. Als VM mit einer Host CPU mit 1600 Punkten als Beispiel: was Sie an Zeit beim Update sparen, werden die User an Kaffee vertrinken.

Nicht umsonst verbaut DATEV im DATEVasp CPUs Intel Xeon Gold 6254 mit 3,1GHz; 2381 Punkte. 

Ob das jetzt Gold/Silver/Bronze CPUs sind, egal. Hauptsache der SingleThread Wert passt. 

Ich kenn eine Kanzlei mit Server-CPUs mit einem Wert von tatsächlich ca. 1600 Punkten. Dort geht der Bilanzbericht von DATEV bei großen Mandanten erst nach ca. 1min auf. Kein Scherz. Dabei muss man auch sagen, dass da so ziemlich alles andere (DNS, Laufwerk L:, Festplattenkonfiguration, VM Konfiguration, Storage, ...) auch nicht passt. Aber selbst wenn das alles passt: Spaß macht DATEV dann nach wie vor nicht und auch kein Scherz: der alte Server der Kanzlei hatte CPUs verbaut, die mehr als ca. 1600 Punkte lieferten und subjektiv sagte der Kanzleiinhaber: "neuer Server aber DATEV ist langsamer? Wie geht das?" - genau an der CPU hapert's leider. Tauschen in dem Fall nicht möglich, weil Lenovo für das Modell keine CPU mit ca. 2000 Punkten anbietet oder der nachträgliche Invest in keinem sinnvollen Verhältnis steht. 

[#13]

Hallo Herr Behrens,

danke für die eindeutige Beantwortung meiner Überlegungen.

Es wäre wohl tatsächlich einen Versuch wert. Von der Hardware Ausstattung ist es keine Problem, die aktuellen Hyper-V Hosts wurden vor 9 Monaten beschafft und entsprechen voll den DATEV Vorgaben. Dies wurde als erstes geprüft, ansonsten würden die weiteren Überlegungen keinen Sinn machen.

Eine Frage wäre noch. Bisher setzen wir bei uns keinen Kommunikationsserver ein. Bisher gab es noch nie eine wirkliche Notwendigkeit dazu.

An einem PC ist eben die RZ-Kommunikation eingerichtet. An diesem wird Lodas/ReWe/Update RZ Kommunikation erledigt.

Wäre dies bei einem teilweise/kompletten Umstieg zu Terminalserver zu ändern und ein Kommunikationsserver notwendig, oder kann dieser Aufbau beibehalten werden?

Gibt es einen wirklichen Vorteil bei einem Kommunikationsserver (Stand jetzt reicht es bei uns, wenn nur ein PC an DATEV senden kann), ich sehe keinen Bedarf dazu.

Gruß

Matthias Sammel

[#14]

Hi,

---

Wäre dies bei einem teilweise/kompletten Umstieg zu Terminalserver zu ändern und ein Kommunikationsserver notwendig, oder kann dieser Aufbau beibehalten werden?

---

 Nein. Ein KommServer ist nicht notwendig, auch wenn er die Arbeit durchaus erleichtert... 

Sie können für den Terminalserver auch das DFÜ-Profil "DFÜ via Internet" einrichten und nutzen. Notwendig ist hier auch wieder eine DATEV-SmartCard. 

Einen DFÜ-Sammler könnte man auch einrichten, würde dann aber meines Erachtens nur bei einem Benutzer einzurichten sein und dann auch nur aktiv sein, wenn dieser angemeldet ist.

Wie gesagt, KommServer nicht notwendig, erleichtert aber manches...

Beste Grüße

Christian Ockenfels

[#15]

---

@matthiass schrieb:

Eine Frage wäre noch. Bisher setzen wir bei uns keinen Kommunikationsserver ein. Bisher gab es noch nie eine wirkliche Notwendigkeit dazu.

---

Kann man, wenn man's klein halten will, am DATEV SQL mit installieren. Dann muss dort aber auch der Arbeitsplatz inkl. aller Programme drauf. Technisch kann man den KOMMSRV auch als Dienst einrichten. 

Am WTS macht man keinen KOMMSRV sowas nicht. 

[#16]

Hallo,

ich finde das Thema auch langsam interessant.

Die "Fat"-Clients werden aber vermutlich nie ganz verschwinden.

Das Prinzip habe ich allerdings noch nicht ganz verstanden.

Installiere ich den Server und installiere einfach die RDP-Rolle.

Oder installiere ich den Server, darauf dann noch einen virtuellen Server und darauf dann die RDP-Rolle?

Verhält sich der Server dann wie ein Client während der DATEV-Installationsroutine?

Kann ich mich mit VNC o.ä. auf die Sitzung von Kollegen schalten und dort was zeigen?

Oder ja, könnte mich ja auch dann auch auf den Thinclient schalten... ja, naja..

[#17]

---

@Gelöschter Nutzer  schrieb:

Installiere ich den Server und installiere einfach die RDP-Rolle.

Ja

---

Oder installiere ich den Server, darauf dann noch einen virtuellen Server und darauf dann die RDP-Rolle?

Kann man machen, muss aber nicht

---

Verhält sich der Server dann wie ein Client während der DATEV-Installationsroutine?

---

Ja

---

Kann ich mich mit VNC o.ä. auf die Sitzung von Kollegen schalten und dort was zeigen?

Oder ja, könnte mich ja auch dann auch auf den Thinclient schalten... ja, naja..

---

Ja und Ja

Der Versuch einer Übersicht:

Server(Blech) + Fat Clients

auf dem Server läuft ein Windows Server 2012R2 od. 2016 od. 2019
hier ist der Datev SQL installiert

auf dem Fat Client läuft ein Win 10 Pro
hier sind die Datev Programme und Office installiert

---

Server(Blech) + Terminalserver(Blech) + Clients

auf dem Server läuft ein Windows Server 2012R2 od. 2016 od. 2019
hier ist der Datev SQL installiert

auf dem Terminalserver läuft ein Windows Server 2012R2 od. 2016 od. 2019
hier sind die Datev Programme und Office installiert

auf dem Client läuft ein Win 10 Pro
hier sind KEINE Datev Programme installiert
Nur eine RDP od. ICA Verbindung zum Terminalserver

---

---

Server(Blech) + Terminalserver(Blech) + Fat Clients + Clients

auf dem Server läuft ein Windows Server 2012R2 od. 2016 od. 2019
hier ist der Datev SQL installiert

auf dem Terminalserver läuft ein Windows Server 2012R2 od. 2016 od. 2019
hier sind die Datev Programme und Office installiert

auf dem Fat Client läuft ein Win 10 Pro
hier sind die Datev Programme und Office installiert

auf dem Client läuft ein Win 10 Pro
hier sind KEINE Datev Programme installiert
Nur eine RDP od. ICA Verbindung zum Terminalserver

---

---

(Blech + Hypervisor + Server + Terminalserver) + Clients

auf dem Blech läuft ein Hypervisor (VMWare oder MS Hyper-V o.a.)
hier KEIN Datev SQL installiert
hier sind KEINE Datev Programme installiert

und KEIN AD, DNS, DHCP, und anderes Gelump

auf dem Server läuft ein Windows Server 2012R2 od. 2016 od. 2019
hier ist der Datev SQL installiert

auf dem Terminalserver läuft ein Windows Server 2012R2 od. 2016 od. 2019
hier sind die Datev Programme und Office installiert

auf dem Client läuft ein Win 10 Pro
hier sind KEINE Datev Programme installiert
Nur eine RDP od. ICA Verbindung zum Terminalserver

---

---

All-in-One Server + Clients

auf dem AiO-Server läuft ein Windows Server 2012R2 od. 2016 od. 2019
es ist die RDP Rolle installiert

hier ist der Datev SQL installiert
hier sind die Datev Programme und Office installiert

auf dem Client läuft ein Win 10 Pro
hier sind KEINE Datev Programme installiert
Nur eine RDP od. ICA Verbindung zum AiO-Server

---

---

Peer-Server (bei Datev) + Fat Clients

auf dem Peer-Server läuft ein:
Windows Server 2012R2 od. 2016. od. 2019 OHNE Active Directory
od. Windows 10 Pro
hier ist der Datev SQL installiert
es KÖNNEN die Datev Programme und Office installiert sein

auf dem Fat Client läuft ein Win 10 Pro
hier sind die Datev Programme und Office installiert

---

---

ASP

(ganz viel Blech + ganz viel Hypervisor + Server + Terminalserver)

ansonsten wie oben

---

[#18]

Weiß jemand, wie das mit den Lizenzen aussieht?

Wenn ich jetzt auf dem Blech Server 2019 Standard installiere, darauf die Hyper-V Rolle und darauf dann nochmal Server 2019 Standard als WTS.

Es ist ein Single-Core-System mit 12 Cores.

Die Lizenz wäre - eine - Server 2019 Standard mit 16 Cores. Reicht das für 2 x Server 2019-Installation und Hyper-V?

Dazu dann noch User CAL's und RDS's Cals.

[#19]

Den reinen HyperV gibt's kostenlos von Microsoft und meiner Meinung nach kann man 1x den reinen HyperV und 2x VMs mit dem Key installieren. Der HyperV darf dann aber nichts anderes machen (weder AD, DNS, DC, WTS - gar nichts). 

Achtung bei HyperV: Virtualisiert man den DC auf dem HyperV und möchte man das Blech später tauschen und die VMs nur auf das neue Blech schubsen, müssen beide HyperVs in der Domäne sein, damit diese sich gegenseitig vertrauen und ein HyperV in einer auf sich selbst virtualisierten Domäne? Dann fragt der HyperV nach der Domäne beim Neustart, welche von der VM noch gar nicht im Netz vorhanden ist ... 

HyperV ist uncool in meinen Augen und macht nur Sinn, wenn man einen DC schon hat und dann kann man den HyperV auch via Remotetools (RSAT) von anderen Windows Server 201x fernwarten und kann den HyperV ohne GUI aufsetzen. So würde ich das machen aber wenn man nur 4 oder gar 2 VMs hat?! Ist VMware Essentials schöner in meinen Augen. RDX kann man via USB 3.0 nun auch in eine VM durchschleifen. Klappt super! 

[#20]

Hallo Herr Bohle,

danke für die Erklärung.

Es geht nur um den WTS. 

Mit VMWare würde ich mir ungern noch einen dritten Anbieter dazu holen.

Deswegen würde ich mehr Richtung Hyper-V schauen.

Die Vorteile sind: Images kann man theoretisch hin und herschieben und der (virtuelle) Serverneustart sind wesentlich schneller? Kann man das so stehen lassen?

Nachteile: Die Ressourcen müssen vernünftig zugewiesen werden.

[#21]

---

@Gelöschter Nutzer schrieb:

Kann man das so stehen lassen?

---

Aus Erfahrung: nein. VMs starten wohl unter jedem Hypervisor fix. Ein Neustart von Server 2019 ohne Domäne, ohne alles dauert in VMware wohl so ca. 7 Sekunden, bis man sich wieder anmelden kann. 

In VMware sind *.vmdk Dateien, in denen die VM arbeitet. In HyperV sind *.vhdx. Das Prinzip ist das gleiche und wenn man mehr als VMware Essentials betreibt, kann man VMs auch im laufenden Betrieb auf einen neuen Host, neues Storage live verschieben und niemand merkt's, wenn die Performance / Bandbreiten passen. 

Und Achtung beim Verschieben der HyperV *.vhdx: Das soll nach meinen Kenntnissen nicht einfach so beliebig funktionieren. Ich meine da hängen Signaturen an der VHDX, die der HyperV dann anmeckert. 

---

@Gelöschter Nutzer schrieb:

Nachteile: Die Ressourcen müssen vernünftig zugewiesen werden.

---

Müssen sie bei jedem Hypervisor. Vergibt man in VMware 64C hat aber nur eine 4C CPU drin und 64GB RAM statt 512GB swappen auch hier die VMs rum. Das wird bei XenServer nicht anders sein. 

Ich halt eine "Glaubensfrage" mit den genannten Erfahrungen zu HyperV von mir. Weil: wenn man dann sagt, man kann am HyperV schön die VMs drauf sichern via LTO: Dann ist der HyperV nicht mehr HyperV allein und muss lizenziert werden, wenn man Veeam und Co. installiert (afaik). 

Und wenn der Hypervisor schon monatlich Windows Updates wegen GUI braucht ... HyperV Neustart habe ich leider auch keine guten Erfahrungen sammeln können. VMware als Hypervisor läuft Jahre ohne Neustart durch. Braucht meiner Meinung nach auch keine monatlichen Updates und ist allg. sicherer in meinen Augen. Dann müsste man schon einen HyperV ohne GUI aufsetzen, um ein ähnliches Sicherheitsniveau zu erreichen. Aber ohne GUI kann man den HyperV schlecht verwalten und ist der HyperV in keiner Domäne, kommt man mit RSAT nur sehr umständlich dran. Und dann sind wir wieder beim Thema des auf sich selbst virtualisierten DCs ... 

[#22]

Hi,

---

@Gelöschter Nutzer  schrieb: Die Vorteile sind: Images kann man theoretisch hin und herschieben und der (virtuelle) Serverneustart sind wesentlich schneller? Kann man das so stehen lassen?

---

 Das dürfte in jedem Virtualisierer kein Problem sein. Voraussetzung sind hier schnelle Storages und Netzwerke. Da muss ggf. ein entsprechender Spezialist ran.

Wichtig: Bei einem MS Hyper-V dürfen VM's nur "hin-und-her" verschoben werden, wenn für beide Hyper-V eine SA abgeschlossen wurde. Ansonsten gilt eine 90-Tage Sperre. D.h. die verschobene VM muß 90 Tage auf dem Ziel-Hyper-V verbleiben.

---

@metalposaunist schrieb: Und Achtung beim Verschieben der HyperV *.vhdx: Das soll nach meinen Kenntnissen nicht einfach so beliebig funktionieren. Ich meine da hängen Signaturen an der VHDX, die der HyperV dann anmeckert. 

---

 Ist mir noch nicht untergekommen, wenn die Verschiebung über die Hyper-V-Mechanismen erfolgt. Aber auch eine abgehängte VHDX hab ich schon problemlos auf einem anderen Hyper-V angehängt bekommen.

Interessanter ist hier die "Festschreibung" der MAC-Adresse. Wenn dies nicht im Vorfeld in den VM-Eigenschaften erfolgt ist, ändert sich diese auf dem neuen Hyper-V. Somit ist die Netzwerkkonfig dann auch "fritte".

---

@metalposaunist schrieb: Ich halt eine "Glaubensfrage" mit den genannten Erfahrungen zu HyperV von mir. Weil: wenn man dann sagt, man kann am HyperV schön die VMs drauf sichern via LTO: Dann ist der HyperV nicht mehr HyperV allein und muss lizenziert werden, wenn man Veeam und Co. installiert (afaik). 

---

 Korrekt! Nur der Hyper-V darf auf dem Host genutzt und betrieben werden. Die Praxis ist wahrscheinlich eine andere... 

---

@metalposaunist schrieb: Und wenn der Hypervisor schon monatlich Windows Updates wegen GUI braucht ... HyperV Neustart habe ich leider auch keine guten Erfahrungen sammeln können. VMware als Hypervisor läuft Jahre ohne Neustart durch. Braucht meiner Meinung nach auch keine monatlichen Updates und ist allg. sicherer in meinen Augen. Dann müsste man schon einen HyperV ohne GUI aufsetzen, um ein ähnliches Sicherheitsniveau zu erreichen. Aber ohne GUI kann man den HyperV schlecht verwalten und ist der HyperV in keiner Domäne, kommt man mit RSAT nur sehr umständlich dran. Und dann sind wir wieder beim Thema des auf sich selbst virtualisierten DCs ... 

---

 In grösseren Umgebungen würde man die Hyper-V in einer eigenen Domäne betreiben. Und dann sind auch virtuelle DC's auf dem Hyper-V kein Problem. Aber Produktion und Administration sind dann getrennt. (Eigene Domäne / eigene VLAN / eigene IP-Bereiche). Dort sind dann auch sinnigerweise die Backup-Funktionen untergebracht, damit ein Trojaner, u.s.w. keinen Unfug anrichten kann.

Das gehört aber alles in Hände von Spezialisten und ist mit Sicherheit eher für grössere Umgebungen. Oder im Bereich des persönlichen Sicherheitsbedürfnis. 

Beste Grüße

Christian Ockenfels

[#23]

---

@Gelöschter Nutzer  schrieb:

Wenn ich jetzt auf dem Blech Server 2019 Standard installiere, darauf die Hyper-V Rolle und darauf dann nochmal Server 2019 Standard als WTS.

Die Lizenz wäre - eine - Server 2019 Standard mit 16 Cores. Reicht das für 2 x Server 2019-Installation und Hyper-V?

---

Der Erwerb einer Windows Server Standard 201x Version erlaubt die Installation einer Hyper-V Rolle und darunter zwei Windows Server Standard 201x. Auf dem Hyper-V ist sonst NICHTS!

Und wer glaubt auf dem Hyper-V noch einen DC, SQL und sonst was installieren zu dürfen/wollen kann sich auch gerne in eine Omnibus setzen wo der Fahrer gleichzeitig hinten die Fahrscheine kontrolliert 😉

---

Dazu dann noch User CAL's und RDS's Cals.

---

User Cals für den Zugriff auf den Fileserver

RDS Cals für den Zugriff auf den WTS Server

Und Office Cals

---

Mit VMWare würde ich mir ungern noch einen dritten Anbieter dazu holen

---

 Wieso drei?

---

Es ist ein Single-Core-System mit 12 Cores.

---

Die "normale" Windows Server Standard 201x kann bis zu 16 Kerne und 2 Sockel, korrekt

Also z.B. 2 CPU mit je 8 Kerne

oder 1 CPU mit 12 Kerne

es müssen immer ALLE Kerne lizensiert werden, ob diese zugewiesen werden oder nicht!

Wenn man also in den besagten Srv eine zweite CPU nachschiebt hat man 24 Kerne -> schlecht

[#24]

---

@metalposaunist  schrieb:

---

@Gelöschter Nutzer schrieb:

Kann man das so stehen lassen?

---

Ich halt eine "Glaubensfrage" mit den genannten Erfahrungen zu HyperV von mir. Weil: wenn man dann sagt, man kann am HyperV schön die VMs drauf sichern via LTO: Dann ist der HyperV nicht mehr HyperV allein und muss lizenziert werden, wenn man Veeam und Co. installiert (afaik). 

Und wenn der Hypervisor schon monatlich Windows Updates wegen GUI braucht ... HyperV Neustart habe ich leider auch keine guten Erfahrungen sammeln können. VMware als Hypervisor läuft Jahre ohne Neustart durch. Braucht meiner Meinung nach auch keine monatlichen Updates und ist allg. sicherer in meinen Augen. Dann müsste man schon einen HyperV ohne GUI aufsetzen, um ein ähnliches Sicherheitsniveau zu erreichen. Aber ohne GUI kann man den HyperV schlecht verwalten und ist der HyperV in keiner Domäne, kommt man mit RSAT nur sehr umständlich dran. Und dann sind wir wieder beim Thema des auf sich selbst virtualisierten DCs ... 

---

Wer nicht mit VMWare warm wird kann auch gerne Proxmox nutzen.

Und Updates bei VMWare gibt es auch, dafür braucht es einen VCenterServer, ab der 6er ist der sogar recht brauchbar. Was da nicht geht sind spezielle Versionen die von den Herstellern (HP oder Dell) für die Servermodelle "gebaut" werden. Da etwas falsch gemacht und es erscheint der "PSoD" (Purple Screen of Death). VMWare flickt im Übrigen relativ viel zwischen den Builds, sind meist "nur" Fehlerberichtigungen, manchmal sind da auch sicherheitsrelevante Dinge dabei.

Die Möglichkeit VMs im laufenden Betrieb zu verschieben lässt sich VMWare auch fürstlich bezahlen, daher wird Proxmox für kleinere Infrastrukturen interessant. Das neue Lizenzmodell von Veeam ist auch nicht ohne Tücken.