23
Warum VMware mit 2 Server2019 Maschinen wenn es nur um eine Software geht?
Hallo,
ich habe die Administration eines Servers übernommen. Komme auch soweit klar.
Was ich nicht verstehe, warum das ganze auf einer VMware esxi läuft und warum der Terminalserver und die Active Directory auf separaten virtuellen Maschinen laufen. Es laufen auch nur diese 2 Maschinen.
Hat es Vorteile in puncto Sicherheit oder Performance?
Eigentlich wäre eine direkte Installation von Server 2019 ohne VMware doch ausreichend! Wie oben erwähnt geht es hauptsächlich um die Praxissoftware.
Hat jemand eine Idee, warum man das macht (Den vorherigen Dienstleister kann ich leider nicht fragen)?
ich habe die Administration eines Servers übernommen. Komme auch soweit klar.
- Installiert ist Server 2019 Standard
- Ca. 15 User greifen darauf per RDP zu. Cals usw. sind vorhanden
- Genutzt wird das ganze für eine Praxissoftware.
Was ich nicht verstehe, warum das ganze auf einer VMware esxi läuft und warum der Terminalserver und die Active Directory auf separaten virtuellen Maschinen laufen. Es laufen auch nur diese 2 Maschinen.
Hat es Vorteile in puncto Sicherheit oder Performance?
Eigentlich wäre eine direkte Installation von Server 2019 ohne VMware doch ausreichend! Wie oben erwähnt geht es hauptsächlich um die Praxissoftware.
Hat jemand eine Idee, warum man das macht (Den vorherigen Dienstleister kann ich leider nicht fragen)?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6640784124
Url: https://administrator.de/contentid/6640784124
Printed on: June 4, 2024 at 10:06 o'clock
23 Comments
Latest comment
Ist so best practice.
1) ein DC ist ein DC und sonst nichts
2) Virtualisierung bietet einige Vorteile
3) Microsoft sagt nein
Die Lizenzkosten für Windows Server ändern sich durch die 2 VMs nicht (1 Windows Server Standard-Lizenz = 2 Windows Server VMs)
1) ein DC ist ein DC und sonst nichts
2) Virtualisierung bietet einige Vorteile
3) Microsoft sagt nein
Hat es Vorteile in puncto Sicherheit oder Performance?
Sicherheit und StabilitätDie Lizenzkosten für Windows Server ändern sich durch die 2 VMs nicht (1 Windows Server Standard-Lizenz = 2 Windows Server VMs)
1
Hallo,
Ergänzung zu 1): +DNS +DHCP
Eine Applikation oder der Terminaldienst haben nichts auf einem Domänen-Controller zu suchen.
Jürgen
Ergänzung zu 1): +DNS +DHCP
Eine Applikation oder der Terminaldienst haben nichts auf einem Domänen-Controller zu suchen.
Jürgen
DNS gehört natürlich dazu und wird auch mit installiert. DHCP bei kleinen Umgebungen auch noch okay.
Moin...
> Zitat von @hi7000:
Hallo,
ich habe die Administration eines Servers übernommen. Komme auch soweit klar.
na das sind ja beste voraussetzungen 
ok..
Was ich nicht verstehe, warum das ganze auf einer VMware esxi läuft und warum der Terminalserver und die Active Directory auf separaten virtuellen Maschinen laufen. Es laufen auch nur diese 2 Maschinen.
was ja auch richtig so ist!
Hat es Vorteile in puncto Sicherheit oder Performance?
sicherheit, support und flexibilität!
Eigentlich wäre eine direkte Installation von Server 2019 ohne VMware doch ausreichend! Wie oben erwähnt geht es hauptsächlich um die Praxissoftware.
nö.. wäre es nicht, die RDS Rolle soll nicht auf einem DC laufen, und SQL etc... sowiso nicht!
Hat jemand eine Idee, warum man das macht (Den vorherigen Dienstleister kann ich leider nicht fragen)?
warum kannst du den nicht fragen?
warum mann das macht, habe ich oben schon beschrieben!
nur so ein Tip, wenn du dich im Praxis umfeld bewegst, arbeite besser nach Standart und mach nur sachen, die auch supportet sind... supportet von MS und der Praxis Software!
auf dem DC sollte in deinem unfeld das AD laufen DNS und DHCP... von mir aus RDS Lizensierung!
Frank
> Zitat von @hi7000:
Hallo,
ich habe die Administration eines Servers übernommen. Komme auch soweit klar.
- Installiert ist Server 2019 Standard
- Ca. 15 User greifen darauf per RDP zu. Cals usw. sind vorhanden
* Genutzt wird das ganze für eine Praxissoftware.
welche?Was ich nicht verstehe, warum das ganze auf einer VMware esxi läuft und warum der Terminalserver und die Active Directory auf separaten virtuellen Maschinen laufen. Es laufen auch nur diese 2 Maschinen.
Hat es Vorteile in puncto Sicherheit oder Performance?
Eigentlich wäre eine direkte Installation von Server 2019 ohne VMware doch ausreichend! Wie oben erwähnt geht es hauptsächlich um die Praxissoftware.
Hat jemand eine Idee, warum man das macht (Den vorherigen Dienstleister kann ich leider nicht fragen)?
warum mann das macht, habe ich oben schon beschrieben!
nur so ein Tip, wenn du dich im Praxis umfeld bewegst, arbeite besser nach Standart und mach nur sachen, die auch supportet sind... supportet von MS und der Praxis Software!
auf dem DC sollte in deinem unfeld das AD laufen DNS und DHCP... von mir aus RDS Lizensierung!
Frank
Hallo hi7000
Es ist ein ungeschriebenes "Gesetz", das auf einem DC nichts anderes installiert wird als die dazu benötigten Pakete wie DNS und in kleineren Umgebungen der DHCP. in der Regel gibt es zwei DC. Einmal Bare Metal und einmal als VM so als Beispiel.
Warum nja wen sich so ein DC verabschiedet läuft eigentlich nichts mehr in einer Firma, ein Login an einem Client ist nicht mehr möglich usw.
Darum die Trennung, stell dir einmal vor du installierst ein update der Praxis Software und es befinden sich alle Installationen auf einem Server, irgend etwas geht schief, Worst Case alles komplett aufsetzten ink. DC, deshalb die Abgrenzung.
Kommen wir zum Vorteil einer VM.
Szenario update der Praxis Software, du machst vor beginn ein Snapshot der VM & ein Backup mit Veeam oder ABB etc.
Danach legst du los, und es geht schief Datenbank zerschossen was auch immer.
Dank des Snapshots oder Backup kannst du einfach wieder zurück zum Punkt davor und der Kunde kann wieder arbeiten, wenn auch mit der alten Version.
Ein weiterer Vorteil einer VM Umgebung bei guter Dokumentation kann die RTO geringer sein mit VM's:
Der Server deines Kunden gibt den geist auf. Die SSD oder Stick vom ESXI ist aber noch intakt.
Somit kannst du die Daten SSD ( wenn vorhanden) und die des OS in einen neuen Server einbauen, am besten die selbe Hardware und mit viel Glück läuft das ganze innert einer Stunde wieder.
Ich hoffe ich konnte deine Frage mit diesen Beispielen beantworten.
Noch was im Sinne deines Kunden never touch a running system
Toby-ch
Hat jemand eine Idee, warum man das macht (Den vorherigen Dienstleister kann ich leider nicht fragen)?
Es ist ein ungeschriebenes "Gesetz", das auf einem DC nichts anderes installiert wird als die dazu benötigten Pakete wie DNS und in kleineren Umgebungen der DHCP. in der Regel gibt es zwei DC. Einmal Bare Metal und einmal als VM so als Beispiel.
Warum nja wen sich so ein DC verabschiedet läuft eigentlich nichts mehr in einer Firma, ein Login an einem Client ist nicht mehr möglich usw.
Darum die Trennung, stell dir einmal vor du installierst ein update der Praxis Software und es befinden sich alle Installationen auf einem Server, irgend etwas geht schief, Worst Case alles komplett aufsetzten ink. DC, deshalb die Abgrenzung.
Kommen wir zum Vorteil einer VM.
Szenario update der Praxis Software, du machst vor beginn ein Snapshot der VM & ein Backup mit Veeam oder ABB etc.
Danach legst du los, und es geht schief Datenbank zerschossen was auch immer.
Dank des Snapshots oder Backup kannst du einfach wieder zurück zum Punkt davor und der Kunde kann wieder arbeiten, wenn auch mit der alten Version.
Ein weiterer Vorteil einer VM Umgebung bei guter Dokumentation kann die RTO geringer sein mit VM's:
Der Server deines Kunden gibt den geist auf. Die SSD oder Stick vom ESXI ist aber noch intakt.
Somit kannst du die Daten SSD ( wenn vorhanden) und die des OS in einen neuen Server einbauen, am besten die selbe Hardware und mit viel Glück läuft das ganze innert einer Stunde wieder.
Ich hoffe ich konnte deine Frage mit diesen Beispielen beantworten.
Noch was im Sinne deines Kunden never touch a running system
Toby-ch
Noch was im Sinne deines Kunden never touch a running system
Damals, als der Mainframe endlich lief...
Daily backup and patch a system sollte die Devise lauten...
Am ESX, kannst du eine 3. VM aufsetzen, die die andern beiden auf ein NAS, Cloud, ... was auch immer zu den Ansprüchen passt ... sichert.
Übrigens hast du noch "Glück", dass es "nur" zwei Server sind.
Viele Anbieter von ERP und ähnlichem wollen auf deren Servern ungern die RDSH haben. Heißt da immer den Terminalserver separat.
Viele Anbieter von ERP und ähnlichem wollen auf deren Servern ungern die RDSH haben. Heißt da immer den Terminalserver separat.
Hallo,
noch ein Punkt: Praxissoftwaresysteme sind nicht immer Musterbeispiele für Stabilität und Robustheit. Da ist es gut, wenn man deren Support sagen kann: „Nö - auf der VM läuft nur Eure Software, sonst nix“.
Grüße
lcer
noch ein Punkt: Praxissoftwaresysteme sind nicht immer Musterbeispiele für Stabilität und Robustheit. Da ist es gut, wenn man deren Support sagen kann: „Nö - auf der VM läuft nur Eure Software, sonst nix“.
Grüße
lcer
1Zitat von @lcer00:
Hallo,
noch ein Punkt: Praxissoftwaresysteme sind nicht immer Musterbeispiele für Stabilität und Robustheit. Da ist es gut, wenn man deren Support sagen kann: „Nö - auf der VM läuft nur Eure Software, sonst nix“.
Grüße
lcer
Hallo,
noch ein Punkt: Praxissoftwaresysteme sind nicht immer Musterbeispiele für Stabilität und Robustheit. Da ist es gut, wenn man deren Support sagen kann: „Nö - auf der VM läuft nur Eure Software, sonst nix“.
Grüße
lcer
Pass auf, dann kommt die Antwort
"Unsere Qualitätssoftware ist nicht für den Einsatz auf virtuellen Maschinen zugelassen. Bitte installieren Sie sie auf dedizierter Hardware. Es wird ausschließlich Windows Server 2016 auf Intel Prozessoren unterstützt. Die IP des Servers muss mit 17 beginnen und darf nicht auf 02, 25 oder 221 enden. Der Server muss sich auf mindestens 49m über dem Meeresspiegel befinden und darf keinem Sonnenlicht ausgesetzt werden. Künstliches Licht nur in der Lichtfarbe kaltweiss"
2Zitat von @3063370895:
Pass auf, dann kommt die Antwort
"Unsere Qualitätssoftware ist nicht für den Einsatz auf virtuellen Maschinen zugelassen. Bitte installieren Sie sie auf dedizierter Hardware. Es wird ausschließlich Windows Server 2016 auf Intel Prozessoren unterstützt. Die IP des Servers muss mit 17 beginnen und darf nicht auf 02, 25 oder 221 enden. Der Server muss sich auf mindestens 49m über dem Meeresspiegel befinden und darf keinem Sonnenlicht ausgesetzt werden. Künstliches Licht nur in der Lichtfarbe kaltweiss"
Zitat von @lcer00:
Hallo,
noch ein Punkt: Praxissoftwaresysteme sind nicht immer Musterbeispiele für Stabilität und Robustheit. Da ist es gut, wenn man deren Support sagen kann: „Nö - auf der VM läuft nur Eure Software, sonst nix“.
Grüße
lcer
Hallo,
noch ein Punkt: Praxissoftwaresysteme sind nicht immer Musterbeispiele für Stabilität und Robustheit. Da ist es gut, wenn man deren Support sagen kann: „Nö - auf der VM läuft nur Eure Software, sonst nix“.
Grüße
lcer
Pass auf, dann kommt die Antwort
"Unsere Qualitätssoftware ist nicht für den Einsatz auf virtuellen Maschinen zugelassen. Bitte installieren Sie sie auf dedizierter Hardware. Es wird ausschließlich Windows Server 2016 auf Intel Prozessoren unterstützt. Die IP des Servers muss mit 17 beginnen und darf nicht auf 02, 25 oder 221 enden. Der Server muss sich auf mindestens 49m über dem Meeresspiegel befinden und darf keinem Sonnenlicht ausgesetzt werden. Künstliches Licht nur in der Lichtfarbe kaltweiss"
Tja, das Leben ist hart.
Grüße
lcer
Danke für die Antworten.
Bin jetzt um einiges an Wissen reicher
Bin jetzt um einiges an Wissen reicher
Eine Frage hätte ich noch:
ist die Reihenfolge der VMs beim Neustart wichtig?
Soll heißen, wenn der TS mit der Praxissoftware einen Neustart benötigt, sollte das ja unabhängig vom DC sein.
Falls aber auch der DC einen benötigt, den dann als ersten und danach den TS? Ist die Reihenfolge relevant?
ist die Reihenfolge der VMs beim Neustart wichtig?
Soll heißen, wenn der TS mit der Praxissoftware einen Neustart benötigt, sollte das ja unabhängig vom DC sein.
Falls aber auch der DC einen benötigt, den dann als ersten und danach den TS? Ist die Reihenfolge relevant?
Hallo,
das ist normalerweise kein Problem. Für den Notfall sollte ellerdings ein lokales Administratorkonto mit Zugriff auf Hyper-V vorgehalten werden.
Grüße
lcer
das ist normalerweise kein Problem. Für den Notfall sollte ellerdings ein lokales Administratorkonto mit Zugriff auf Hyper-V vorgehalten werden.
Grüße
lcer
Zitat von @lcer00:
Hallo,
das ist normalerweise kein Problem. Für den Notfall sollte ellerdings ein lokales Administratorkonto mit Zugriff auf Hyper-V vorgehalten werden.
Grüße
lcer
Hallo,
das ist normalerweise kein Problem. Für den Notfall sollte ellerdings ein lokales Administratorkonto mit Zugriff auf Hyper-V vorgehalten werden.
Grüße
lcer
Hier läuft kein Hyper-V
Er hat VMware ESX.
Also lokales Konto in der ESX.
Jürgen
Also lokales Konto in der ESX.
Jürgen
Moin...
Frank
Zitat von @hi7000:
Eine Frage hätte ich noch:
ist die Reihenfolge der VMs beim Neustart wichtig?
Soll heißen, wenn der TS mit der Praxissoftware einen Neustart benötigt, sollte das ja unabhängig vom DC sein.
Falls aber auch der DC einen benötigt, den dann als ersten und danach den TS? Ist die Reihenfolge relevant?
ja klar... erst der DC dann der RD Host!Eine Frage hätte ich noch:
ist die Reihenfolge der VMs beim Neustart wichtig?
Soll heißen, wenn der TS mit der Praxissoftware einen Neustart benötigt, sollte das ja unabhängig vom DC sein.
Falls aber auch der DC einen benötigt, den dann als ersten und danach den TS? Ist die Reihenfolge relevant?
Frank
Hallo,
Ist aber keine Pflicht, solange der DC überhaupt startet. Zumindest, so lange kein Zugriff auf Ressourcen erfolgt, die eine Authentifizierung über den DC erfordern. Das dürfte aber bei einem einzelnen Server eher unwahrscheinlich sein.
Grüße
lcer
Ist aber keine Pflicht, solange der DC überhaupt startet. Zumindest, so lange kein Zugriff auf Ressourcen erfolgt, die eine Authentifizierung über den DC erfordern. Das dürfte aber bei einem einzelnen Server eher unwahrscheinlich sein.
Grüße
lcer
Moin...
Grüße
lcer
Frank
Zitat von @lcer00:
Hallo,
Ist aber keine Pflicht, solange der DC überhaupt startet. Zumindest, so lange kein Zugriff auf Ressourcen erfolgt, die eine Authentifizierung über den DC erfordern. Das dürfte aber bei einem einzelnen Server eher unwahrscheinlich sein.
besser gleich so machen.... Hallo,
Ist aber keine Pflicht, solange der DC überhaupt startet. Zumindest, so lange kein Zugriff auf Ressourcen erfolgt, die eine Authentifizierung über den DC erfordern. Das dürfte aber bei einem einzelnen Server eher unwahrscheinlich sein.
Grüße
lcer
Hey,
Ich installiere üblicherweise den RDS License Server auch auf dem DC.
Das ist auch so von MS so in den BestPractices so angegeben.
Den RDS Session Host aber definitiv immer auf mem anderen..entweder Blech oder VM.
S.
Ich installiere üblicherweise den RDS License Server auch auf dem DC.
Das ist auch so von MS so in den BestPractices so angegeben.
Den RDS Session Host aber definitiv immer auf mem anderen..entweder Blech oder VM.
S.
Wo?
Einfach mal nach “install rds License Server“ googeln. Da wird es sehr häufig so gemacht, dass der lizenzserver auf den DC kommt
Zitat von @SvenTej:
Einfach mal nach “install rds License Server“ googeln. Da wird es sehr häufig so gemacht, dass der lizenzserver auf den DC kommt
Einfach mal nach “install rds License Server“ googeln. Da wird es sehr häufig so gemacht, dass der lizenzserver auf den DC kommt
"Es wird häufig so gemacht" ist etwas anderes als "Das ist auch so von MS so in den BestPractices so angegeben."
Das es häufig so gemacht wird ist mir klar, du hast aber etwas anderes behauptet. Ich behaupte auch nicht, dass es falsch ist, mich interessiert allerdings die Quelle für deine Behauptung.
Okay dann möcht ich mich korrigieren.
Hier eine Seite von MS:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/ins ...
Da dort auch auf dem DC installiert wird, scheint es für den lizenzserver unproblematisch zu sein, ihn auf einen DC zu nehmen.
Den SH klugerweise nicht.
Hier eine Seite von MS:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/ins ...
Da dort auch auf dem DC installiert wird, scheint es für den lizenzserver unproblematisch zu sein, ihn auf einen DC zu nehmen.
Den SH klugerweise nicht.