22
Server 2019 Hyper-V Anfängerfragen
Hallo zusammen,
ich hätte mal wieder ein paar Anfängerfragen bzw. benötige eine kurze Bestätigung, ob bis dahin alles richtig ist.
Ich bin kein gelernter ITler, sondern eher einigermaßen versierter Endanwender und bitte eingangs schon um Gnade,
wenn ich mich stellenweise nicht fachlich korrekt ausdrücke.
Nachdem gestern mein neuer Server geliefert wurde, habe ich heute gleich mal mit Basteln angefangen.
Die Hardware ist ein R540 mit 2 x Xeon Silver 10C/20T, 160 GB Ram, 4 NICs, Raid 1 für den Host und Raid 10
für die Gastsysteme.
DC ist ein Windows 2016 Essentials auf separatem Blech
Für iDRAC hab ich die dedizierte iDRAC-Schnittstelle in mein Management-VLAN 1 gesetzt. Für den 2019
habe ich eine NIC als "Verwaltungs-Zugang" verwendet sowie für die VMs dann
zwei NIC in ein Team genommen. Gemeinsame Nutzung von Host und VMs für das NIC-Team habe ich
abgewählt und den virtueller Switch dann mit dem NIC-Team eingerichtet.
Den 2019 habe ich in die Domäne aufgenommen, erstmal alle Updates direkt von MS durchgepaukt,
AV-Lösung auf dem 2019 installiert und auf dem Security-Server (Trendmicro WFBS auf dem DC)
die von MS empfohlenen Ausschlüsse für den Hyper-V Host eingepflegt. Auf dem DC hab ich dann den 2019
in eine eigene OU verschoben und die GPO für WSUS-Updates (macht noch der Essentials) dort verknüpft.
Soweit ich sehen kann, fliegt bis jetzt alles ganz ordentlich.
Hab ich bisher irgendwo einen Fehler gemacht oder gibt es etwas, was ich unbedingt noch beachten sollte?
Bin wie gesagt, kein ITler und habe mich aber in der Theorie nach bestem Wissen und Gewissen vorbereitet.
Gruß NV
ich hätte mal wieder ein paar Anfängerfragen bzw. benötige eine kurze Bestätigung, ob bis dahin alles richtig ist.
Ich bin kein gelernter ITler, sondern eher einigermaßen versierter Endanwender und bitte eingangs schon um Gnade,
wenn ich mich stellenweise nicht fachlich korrekt ausdrücke.
Nachdem gestern mein neuer Server geliefert wurde, habe ich heute gleich mal mit Basteln angefangen.
Die Hardware ist ein R540 mit 2 x Xeon Silver 10C/20T, 160 GB Ram, 4 NICs, Raid 1 für den Host und Raid 10
für die Gastsysteme.
DC ist ein Windows 2016 Essentials auf separatem Blech
Für iDRAC hab ich die dedizierte iDRAC-Schnittstelle in mein Management-VLAN 1 gesetzt. Für den 2019
habe ich eine NIC als "Verwaltungs-Zugang" verwendet sowie für die VMs dann
zwei NIC in ein Team genommen. Gemeinsame Nutzung von Host und VMs für das NIC-Team habe ich
abgewählt und den virtueller Switch dann mit dem NIC-Team eingerichtet.
Den 2019 habe ich in die Domäne aufgenommen, erstmal alle Updates direkt von MS durchgepaukt,
AV-Lösung auf dem 2019 installiert und auf dem Security-Server (Trendmicro WFBS auf dem DC)
die von MS empfohlenen Ausschlüsse für den Hyper-V Host eingepflegt. Auf dem DC hab ich dann den 2019
in eine eigene OU verschoben und die GPO für WSUS-Updates (macht noch der Essentials) dort verknüpft.
Soweit ich sehen kann, fliegt bis jetzt alles ganz ordentlich.
Hab ich bisher irgendwo einen Fehler gemacht oder gibt es etwas, was ich unbedingt noch beachten sollte?
Bin wie gesagt, kein ITler und habe mich aber in der Theorie nach bestem Wissen und Gewissen vorbereitet.
Gruß NV
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 448797
Url: https://administrator.de/forum/server-2019-hyper-v-anfaengerfragen-448797.html
Ausgedruckt am: 05.02.2025 um 15:02 Uhr
22 Kommentare
Neuester Kommentar
Servus,
mal kurz OT @NixVerstehen:
Ein Server, der nicht produktiv genutzt ist, mit 160 GB RAM??
Bin echt etwas platt...
Gruß
mal kurz OT @NixVerstehen:
Ein Server, der nicht produktiv genutzt ist, mit 160 GB RAM??
Bin echt etwas platt...
Gruß
Wo liest du, dass der nicht produktiv genutzt wird? Weil er mit Essentials arbeitet in der Konstellation oder weil er überall von basteln spricht?
Zitat von @VGem-e:
Servus,
mal kurz OT @NixVerstehen:
Ein Server, der nicht produktiv genutzt ist, mit 160 GB RAM??
Bin echt etwas platt...
Gruß
Servus,
mal kurz OT @NixVerstehen:
Ein Server, der nicht produktiv genutzt ist, mit 160 GB RAM??
Bin echt etwas platt...
Gruß
@VGem-e
Soll irgendwann natürlich produktiv eingesetzt werden, aber erst möchte ich mich gerne in Ruhe in das Thema Hyper-V einarbeiten,
etwas experimentieren, dazu lernen und das Erlernte am Schluss dann ordentlich und möglichst fehlerfrei umsetzen.
Da hier im Forum oft die Rede war von unterdimensionierten Hyper-V-Systemen, dachte ich mir, das ich die Hardware gleich für die
nächsten paar Jahre ausreichend ausstatte.
@certifiedit.net
Bis ich mir das notwendige Grundwissen angeeignet habe, bezeichne ich es erstmal als "Basteln". Der Essentials war bisher der
einzige Server in unserem Kleinbetrieb und damit natürlich die eierlegende Wollmilchsau als DC, DHCP, DNS, Druckserver, Dateiserver
sowie für die Datev-Plattform und Fehlzeitenverwaltung.
Edit: Das ganze Zeug, das auf dem DC nichts verloren hat, soll dann natürlich irgendwann auf eine VM. Hinzu kommt dann mittelfristig
ggf. noch ein Zeiterfassungsprogramm für ca. 60 auswärts tätige Mitarbeiter.
Der Plan ist natürlich, den Essentials zum Ende seines Lebens durch einen Standard zu ersetzen. Die User-Cals sind je nun eh vorhanden.
Ist eh schade, das die SBS- bzw. Essentials-Reihe immer mehr von MS kastriert wurde.
Back to topic...war soweit alles einigermaßen richtig bisher? Dann fange ich morgen mal an, die erste VM aufzusetzen.
Gruß NV
Moin,
Bestimmt hast Du irgendwo einen Fehler gemacht. Das würde mich wundern, wenn nicht.
Aber die liegen dann eher im Detail. Die Grobbeschreibung klingt erstmal soweit ganz gut. Vor allem klingt das so, als hättest Du Dir vorher Gedanken gemacht und Dich informiert. Also nur Mut und weiter. Falls was wo hakt, kannst Du Dich ja wieder melden.
Liebe Grüße
Erik
Zitat von @NixVerstehen:
Hab ich bisher irgendwo einen Fehler gemacht oder gibt es etwas, was ich unbedingt noch beachten sollte?
Hab ich bisher irgendwo einen Fehler gemacht oder gibt es etwas, was ich unbedingt noch beachten sollte?
Bestimmt hast Du irgendwo einen Fehler gemacht. Das würde mich wundern, wenn nicht.
Aber die liegen dann eher im Detail. Die Grobbeschreibung klingt erstmal soweit ganz gut. Vor allem klingt das so, als hättest Du Dir vorher Gedanken gemacht und Dich informiert. Also nur Mut und weiter. Falls was wo hakt, kannst Du Dich ja wieder melden.Liebe Grüße
Erik
Hi,
Nennt mich verantwortungslos, aber ich habe auf keinem von mir betreuten Hyper-V ein AV installiert.
Ok, ich installiere auf Servern eh meist nur dann ein AV mit Basisfunktionen, wenn ein "Teilzeitadmin" aus der jeweiligen Firma mitadministriert.
So ähnlich habe ich früher auch mal angefangen mit 1-2 eigenen Servern in Blech, die alles gemacht haben.
Allerdings habe ich zum Üben eine Testinstallation mit damals Server 2008 Hyper-V genommen und erst probiert, bevor ich alles umgestellt habe.
Den 2019 habe ich in die Domäne aufgenommen,
Ich nehme die meisten Hyper-V-Hosts auch in die Domäne auf, ist aber nicht in jedem Fall nötig.AV-Lösung auf dem 2019 installiert
Echt, auf dem Hyper-V installierst du ein AV? Machst dann auch wöchentliche Scans, etc?Nennt mich verantwortungslos, aber ich habe auf keinem von mir betreuten Hyper-V ein AV installiert.
Ok, ich installiere auf Servern eh meist nur dann ein AV mit Basisfunktionen, wenn ein "Teilzeitadmin" aus der jeweiligen Firma mitadministriert.
Bis ich mir das notwendige Grundwissen angeeignet habe, bezeichne ich es erstmal als "Basteln". Der Essentials war bisher der
einzige Server in unserem Kleinbetrieb und damit natürlich die eierlegende Wollmilchsau als DC, DHCP, DNS, Druckserver, DateiserverSo ähnlich habe ich früher auch mal angefangen mit 1-2 eigenen Servern in Blech, die alles gemacht haben.
Allerdings habe ich zum Üben eine Testinstallation mit damals Server 2008 Hyper-V genommen und erst probiert, bevor ich alles umgestellt habe.
Zitat von @goscho:
Hi,
Nennt mich verantwortungslos, aber ich habe auf keinem von mir betreuten Hyper-V ein AV installiert.
Ok, ich installiere auf Servern eh meist nur dann ein AV mit Basisfunktionen, wenn ein "Teilzeitadmin" aus der jeweiligen Firma mitadministriert.
Hi,
Den 2019 habe ich in die Domäne aufgenommen,
Ich nehme die meisten Hyper-V-Hosts auch in die Domäne auf, ist aber nicht in jedem Fall nötig.AV-Lösung auf dem 2019 installiert
Echt, auf dem Hyper-V installierst du ein AV? Machst dann auch wöchentliche Scans, etc?Nennt mich verantwortungslos, aber ich habe auf keinem von mir betreuten Hyper-V ein AV installiert.
Ok, ich installiere auf Servern eh meist nur dann ein AV mit Basisfunktionen, wenn ein "Teilzeitadmin" aus der jeweiligen Firma mitadministriert.
Naja im Zweifel hast du dann ja automatisch den Defender drauf, der mittlerweile mit anderen AV Scannern gut mithalten kann und als Vorteil hat, dass er bei einem Systemupgrade keine Probleme verursacht. Bei anderen AV Lösungen kommen solche Probleme bei Upgrades ja häufiger mal vor.
Zitat von @Bem0815:
Naja im Zweifel hast du dann ja automatisch den Defender drauf, der mittlerweile mit anderen AV Scannern gut mithalten kann und als Vorteil hat, dass er bei einem Systemupgrade keine Probleme verursacht. Bei anderen AV Lösungen kommen solche Probleme bei Upgrades ja häufiger mal vor.
Der Defender wird von mir auch deaktiviert. Naja im Zweifel hast du dann ja automatisch den Defender drauf, der mittlerweile mit anderen AV Scannern gut mithalten kann und als Vorteil hat, dass er bei einem Systemupgrade keine Probleme verursacht. Bei anderen AV Lösungen kommen solche Probleme bei Upgrades ja häufiger mal vor.
Zitat von @goscho:
Zitat von @Bem0815:
Naja im Zweifel hast du dann ja automatisch den Defender drauf, der mittlerweile mit anderen AV Scannern gut mithalten kann und als Vorteil hat, dass er bei einem Systemupgrade keine Probleme verursacht. Bei anderen AV Lösungen kommen solche Probleme bei Upgrades ja häufiger mal vor.
Der Defender wird von mir auch deaktiviert. Naja im Zweifel hast du dann ja automatisch den Defender drauf, der mittlerweile mit anderen AV Scannern gut mithalten kann und als Vorteil hat, dass er bei einem Systemupgrade keine Probleme verursacht. Bei anderen AV Lösungen kommen solche Probleme bei Upgrades ja häufiger mal vor.
Ach so, na gut.
Persönlich sehe ich jetzt keinen Vorteil darin den zu deaktivieren, aber ist ja jedem seine eigene Entscheidung.
Servus,
ich persönlich hab mich dafür entschieden, auf dem Hyper-V Host und auf den VMs unsere AV-Lösung zu installieren. Allerdings hab ich auf dem TrendMicro Security Server den Host in eine eigene Gruppe gepackt und für diese Gruppe die von MS empfohlenen Ausschlüsse gesetzt.
Außerdem hab ich den Hyper-V Host in die Domäne genommen.
Meine 2 VMs mit 2019 Standard laufen.
Aktuell lese ich mich in die VEEAM B&R Community Edition ein. Ist es hier besser, Veeam auf eine physische oder virtuelle Maschine zu installieren? Dürfte ich lizenztechnisch überhaupt auf dem Hyper-V Host den Veeam Server betreiben oder verstoße ich dadurch gegen die MS Lizenzbestimmungen?
Gruß NV
ich persönlich hab mich dafür entschieden, auf dem Hyper-V Host und auf den VMs unsere AV-Lösung zu installieren. Allerdings hab ich auf dem TrendMicro Security Server den Host in eine eigene Gruppe gepackt und für diese Gruppe die von MS empfohlenen Ausschlüsse gesetzt.
Außerdem hab ich den Hyper-V Host in die Domäne genommen.
Meine 2 VMs mit 2019 Standard laufen.
Aktuell lese ich mich in die VEEAM B&R Community Edition ein. Ist es hier besser, Veeam auf eine physische oder virtuelle Maschine zu installieren? Dürfte ich lizenztechnisch überhaupt auf dem Hyper-V Host den Veeam Server betreiben oder verstoße ich dadurch gegen die MS Lizenzbestimmungen?
Gruß NV
Zitat von @NixVerstehen:
Servus,
ich persönlich hab mich dafür entschieden, auf dem Hyper-V Host und auf den VMs unsere AV-Lösung zu installieren. Allerdings hab ich auf dem TrendMicro Security Server den Host in eine eigene Gruppe gepackt und für diese Gruppe die von MS empfohlenen Ausschlüsse gesetzt.
Servus,
ich persönlich hab mich dafür entschieden, auf dem Hyper-V Host und auf den VMs unsere AV-Lösung zu installieren. Allerdings hab ich auf dem TrendMicro Security Server den Host in eine eigene Gruppe gepackt und für diese Gruppe die von MS empfohlenen Ausschlüsse gesetzt.
Auf dem Hyper-V Host halte ich zumindest eine AV Lösung von einem Dritthersteller eher für sinnfrei. Im Zweifel macht die mehr ärger als sie verhindern soll.
Außer zum Administrieren der VMs solltest man diesen Server ja nicht wirklich anfassen, also geht die Gefahr, dass sich da etwas infiziert gegen null sofern das System auch mit Updates gewartet wird.
Außerdem hab ich den Hyper-V Host in die Domäne genommen.
Ist zwar für einen Hyper-V Host nicht zwingend notwendig, kann man aber machen. Aber Achtung!
Das ganze funktioniert nur weil den DC auf einem separaten Blech ist.
Wäre der DC auch auf dem Hyper-V als VM sollte man den Hyper-V nie in die Domäne aufnehmen.
Denn im schlimmsten Fall könnte sonst folgendes Szenario passieren:
Du startest den Hyper-V und alle VMs inkl. DC neu. Willst dich mit deinem Domänenkonto am Hyper-V anmelden. Hyper-V versucht den DC zu erreichen, geht aber nicht, da dies ja eine VM ist die noch nicht gestartet ist weil der Hyper-V noch nicht angemeldet wurde. Und Zack hat man sich hier im Wurstcase Szenario eine Falle gebaut.
Einen Hyper-V deshalb nur in die Domäne aufnehmen, wenn der DC extern ist.
Meine 2 VMs mit 2019 Standard laufen.
Aktuell lese ich mich in die VEEAM B&R Community Edition ein. Ist es hier besser, Veeam auf eine physische oder virtuelle Maschine zu installieren? Dürfte ich lizenztechnisch überhaupt auf dem Hyper-V Host den Veeam Server betreiben oder verstoße ich dadurch gegen die MS Lizenzbestimmungen?
Nö gegen die MS Lizenzbestimmungen verstößt du damit nicht.Aktuell lese ich mich in die VEEAM B&R Community Edition ein. Ist es hier besser, Veeam auf eine physische oder virtuelle Maschine zu installieren? Dürfte ich lizenztechnisch überhaupt auf dem Hyper-V Host den Veeam Server betreiben oder verstoße ich dadurch gegen die MS Lizenzbestimmungen?
Jetzt wäre aber die Frage ob wir hier von einem normalen Server sprechen auf dem die Hyper-V Rolle aktiviert wurde oder von dem kostenlosen Hyper-V Server auf dem ansonsten gar nix installiert werden kann...
Bei Veeam musst du halt schauen ob du da die passende Lizenz für einen Virtualisierungsserver hast.
Morgen Bem,
Das Szenario greif ich gerne mal auf, bei so wichtigen Systemen (eigentlich bei allen), sollte man im Sonderkorb noch die lokalen Zugangsdaten haben.Auch der externe DC kann man ausfallen und ehrlich - aus jetzt 8 Jahren excessiver Nutzung des Hyper-V - wenn etwas das Problem war, dann lag das meist nicht mehr nur am nicht startenden virtuellen DC - oder der externe (ggf + Hyper-V) wurde vom Kunden oder seinen Dienstleistern, "IT-lern" oder "bestem Freund" kaputt gespielt.
Also, Hyper-V kann in die Domäne, ein externer DC ist nett, seh ich bei KMU aber nicht mehr als notwendig an, solange der Rescueplan gesichert ist. Natürlich gilt wie immer, man sollte wissen, was man tut, was meist auch bereits das Problem umreisst.
Viele Grüße,
Christian
certifiedit.net
Denn im schlimmsten Fall könnte sonst folgendes Szenario passieren:
Du startest den Hyper-V und alle VMs inkl. DC neu. Willst dich mit deinem Domänenkonto am Hyper-V anmelden. Hyper-V versucht den DC zu
erreichen, geht aber nicht, da dies ja eine VM ist die noch nicht gestartet ist weil der Hyper-V noch nicht angemeldet wurde. Und Zack hat man sich > hier im Wurstcase Szenario eine Falle gebaut.
Du startest den Hyper-V und alle VMs inkl. DC neu. Willst dich mit deinem Domänenkonto am Hyper-V anmelden. Hyper-V versucht den DC zu
erreichen, geht aber nicht, da dies ja eine VM ist die noch nicht gestartet ist weil der Hyper-V noch nicht angemeldet wurde. Und Zack hat man sich > hier im Wurstcase Szenario eine Falle gebaut.
Einen Hyper-V deshalb nur in die Domäne aufnehmen, wenn der DC extern ist.
Das Szenario greif ich gerne mal auf, bei so wichtigen Systemen (eigentlich bei allen), sollte man im Sonderkorb noch die lokalen Zugangsdaten haben.Auch der externe DC kann man ausfallen und ehrlich - aus jetzt 8 Jahren excessiver Nutzung des Hyper-V - wenn etwas das Problem war, dann lag das meist nicht mehr nur am nicht startenden virtuellen DC - oder der externe (ggf + Hyper-V) wurde vom Kunden oder seinen Dienstleistern, "IT-lern" oder "bestem Freund" kaputt gespielt.
Also, Hyper-V kann in die Domäne, ein externer DC ist nett, seh ich bei KMU aber nicht mehr als notwendig an, solange der Rescueplan gesichert ist. Natürlich gilt wie immer, man sollte wissen, was man tut, was meist auch bereits das Problem umreisst.
Viele Grüße,
Christian
certifiedit.net
@Bem0815
@certifiedit.net
Ist wahrscheinlich so, das hier jeder eigene Strategien verfolgt, die er im Laufe der Jahre für gut befunden hat. Ich lasse die AV-Lösung mal drauf
und wenn etwas rumzickt, kann ich es immer noch runter kicken.
Yep, das ist klar. Da ist auch nur die Hyper-V Rolle drauf und sonst nichts.
Ich dachte einfach, ich nehme den Hyper-V Host in die Domäne auf, damit auch der sich über den WSUS (macht momentan noch der DC) seine Updates holen kann. Das ich dazu den DC auf separatem Blech brauche war mir irgendwie klar. Sonst baue ich mir selbst so ein "Hund beisst sich in eigenen Schwanz"-Szenario
Jetzt wäre aber die Frage ob wir hier von einem normalen Server sprechen auf dem die Hyper-V Rolle aktiviert wurde oder von dem kostenlosen Hyper-V Server auf dem ansonsten gar nix installiert werden kann...
Wir sprechen von einem 2019 Standard, der auf Blech nur die Hyper-V Rolle hat und mit derselben Lizenz 2 x 2019 Standard als VMs.
Soweit ich sehe konnte, ist das ja über die Veeam Backup & Replication Community Edition abgedeckt.
Erstmal vielen Dank
Gruß NV
@certifiedit.net
Auf dem Hyper-V Host halte ich zumindest eine AV Lösung von einem Dritthersteller eher für sinnfrei. Im Zweifel macht die mehr ärger als sie verhindern soll.
Ist wahrscheinlich so, das hier jeder eigene Strategien verfolgt, die er im Laufe der Jahre für gut befunden hat. Ich lasse die AV-Lösung mal drauf
und wenn etwas rumzickt, kann ich es immer noch runter kicken.
Außer zum Administrieren der VMs solltest man diesen Server ja nicht wirklich anfassen, also geht die Gefahr, dass sich da etwas infiziert gegen null sofern das System auch mit Updates gewartet wird.
Yep, das ist klar. Da ist auch nur die Hyper-V Rolle drauf und sonst nichts.
Ist zwar für einen Hyper-V Host nicht zwingend notwendig, kann man aber machen. Aber Achtung!
Das ganze funktioniert nur weil den DC auf einem separaten Blech ist.
Wäre der DC auch auf dem Hyper-V als VM sollte man den Hyper-V nie in die Domäne aufnehmen.
Denn im schlimmsten Fall könnte sonst folgendes Szenario passieren:
Du startest den Hyper-V und alle VMs inkl. DC neu. Willst dich mit deinem Domänenkonto am Hyper-V anmelden. Hyper-V versucht den DC zu erreichen, geht aber nicht, da dies ja eine VM ist die noch nicht gestartet ist weil der Hyper-V noch nicht angemeldet wurde. Und Zack hat man sich hier im Wurstcase Szenario eine Falle gebaut.
Einen Hyper-V deshalb nur in die Domäne aufnehmen, wenn der DC extern ist.
Das ganze funktioniert nur weil den DC auf einem separaten Blech ist.
Wäre der DC auch auf dem Hyper-V als VM sollte man den Hyper-V nie in die Domäne aufnehmen.
Denn im schlimmsten Fall könnte sonst folgendes Szenario passieren:
Du startest den Hyper-V und alle VMs inkl. DC neu. Willst dich mit deinem Domänenkonto am Hyper-V anmelden. Hyper-V versucht den DC zu erreichen, geht aber nicht, da dies ja eine VM ist die noch nicht gestartet ist weil der Hyper-V noch nicht angemeldet wurde. Und Zack hat man sich hier im Wurstcase Szenario eine Falle gebaut.
Einen Hyper-V deshalb nur in die Domäne aufnehmen, wenn der DC extern ist.
Ich dachte einfach, ich nehme den Hyper-V Host in die Domäne auf, damit auch der sich über den WSUS (macht momentan noch der DC) seine Updates holen kann. Das ich dazu den DC auf separatem Blech brauche war mir irgendwie klar. Sonst baue ich mir selbst so ein "Hund beisst sich in eigenen Schwanz"-Szenario
Meine 2 VMs mit 2019 Standard laufen.
Aktuell lese ich mich in die VEEAM B&R Community Edition ein. Ist es hier besser, Veeam auf eine physische oder virtuelle Maschine zu installieren? Dürfte ich lizenztechnisch überhaupt auf dem Hyper-V Host den Veeam Server betreiben oder verstoße ich dadurch gegen die MS Lizenzbestimmungen?
Nö gegen die MS Lizenzbestimmungen verstößt du damit nicht.Aktuell lese ich mich in die VEEAM B&R Community Edition ein. Ist es hier besser, Veeam auf eine physische oder virtuelle Maschine zu installieren? Dürfte ich lizenztechnisch überhaupt auf dem Hyper-V Host den Veeam Server betreiben oder verstoße ich dadurch gegen die MS Lizenzbestimmungen?
Jetzt wäre aber die Frage ob wir hier von einem normalen Server sprechen auf dem die Hyper-V Rolle aktiviert wurde oder von dem kostenlosen Hyper-V Server auf dem ansonsten gar nix installiert werden kann...
Wir sprechen von einem 2019 Standard, der auf Blech nur die Hyper-V Rolle hat und mit derselben Lizenz 2 x 2019 Standard als VMs.
Bei Veeam musst du halt schauen ob du da die passende Lizenz für einen Virtualisierungsserver hast.
Soweit ich sehe konnte, ist das ja über die Veeam Backup & Replication Community Edition abgedeckt.
Erstmal vielen Dank
Gruß NV
@Bem0815
Ich dachte einfach, ich nehme den Hyper-V Host in die Domäne auf, damit auch der sich über den WSUS (macht momentan noch der DC) seine Updates holen kann. Das ich dazu den DC auf separatem Blech brauche war mir irgendwie klar. Sonst baue ich mir selbst so ein "Hund beisst sich in eigenen Schwanz"-Szenario
Ich möchte das auch gern mal aufgreifen:
Das ist nicht korrekt und zeugt davon, dass man sich damit nicht richtig beschäftigt hat.
Der Hyper-V startet ohne, das der DC da ist.
Die Hyper-V-Dienste sind nicht vom DC abhängig.
Die VM mit dem DC wird auf automatisch starten gesetzt und die anderen starten später (Startzeitverzögerung).
Sollte der virtuelle DC mal wirklich zu lange brauchen oder gar nicht starten, kann man sich (wie es @certifiedit.net ja geschrieben hat) mit den Credentials eines lokalen Benutzers am Hyper-V anmelden.
Bei mir selbst ist auf dem Hyper-V noch mehr (bereits seit 2013).
Da meine TK-Anlage sehr alt ist und keinen LAN-Anschluss hat, ich aber TAPI darüber nutze, habe ich diese per seriellem Anschluss mit dem Server verbunden und dort den MS Telefonie-Server eingerichtet.
Dann habe ich bei mir bspw. den WSUS und die Datensicherung auf dem Host laufen.
Der SQL-Server für den WSUS ist eine SQL-Server-VM, die Daten liegen auf einem billigen Speicher (NAS, per ISCSI verbunden).
Für die Dasi hatte ich die Option, einen weiteren Server, eine VM oder den Host zu nutzen. Da bot sich der Hyper-V-Host an.
Als Datensicherung nutze ich Backup Exec von Veritas.
Einen Hyper-V deshalb nur in die Domäne aufnehmen, wenn der DC extern ist.
Ich dachte einfach, ich nehme den Hyper-V Host in die Domäne auf, damit auch der sich über den WSUS (macht momentan noch der DC) seine Updates holen kann. Das ich dazu den DC auf separatem Blech brauche war mir irgendwie klar. Sonst baue ich mir selbst so ein "Hund beisst sich in eigenen Schwanz"-Szenario
Ich möchte das auch gern mal aufgreifen:
Das ist nicht korrekt und zeugt davon, dass man sich damit nicht richtig beschäftigt hat.
Der Hyper-V startet ohne, das der DC da ist.
Die Hyper-V-Dienste sind nicht vom DC abhängig.
Die VM mit dem DC wird auf automatisch starten gesetzt und die anderen starten später (Startzeitverzögerung).
Sollte der virtuelle DC mal wirklich zu lange brauchen oder gar nicht starten, kann man sich (wie es @certifiedit.net ja geschrieben hat) mit den Credentials eines lokalen Benutzers am Hyper-V anmelden.
Bei mir selbst ist auf dem Hyper-V noch mehr (bereits seit 2013).
Da meine TK-Anlage sehr alt ist und keinen LAN-Anschluss hat, ich aber TAPI darüber nutze, habe ich diese per seriellem Anschluss mit dem Server verbunden und dort den MS Telefonie-Server eingerichtet.
Dann habe ich bei mir bspw. den WSUS und die Datensicherung auf dem Host laufen.
Der SQL-Server für den WSUS ist eine SQL-Server-VM, die Daten liegen auf einem billigen Speicher (NAS, per ISCSI verbunden).
Für die Dasi hatte ich die Option, einen weiteren Server, eine VM oder den Host zu nutzen. Da bot sich der Hyper-V-Host an.
Als Datensicherung nutze ich Backup Exec von Veritas.
@goscho
Servus,
danke für deine Sicht der Dinge. Ich kann da als versierter Enduser natürlich (noch) nicht sagen, was richtig / falsch bzw. besser / schlechter ist. Das wisst ihr Profis viel besser. Ich bin noch in der Lernphase
Den DC zu virtualisieren, ist zur Zeit kein Thema. Der WSE 2016 läuft so sauber, das ich da nicht ran möchte. Das kommt ggf. nächstes Jahr dran. Ziel der Virtualisierungsaktion war primär, das ganze Gedöns auf eine VM zu packen, das auf dem DC nichts verloren hat. Auf der VM1 läuft schon die Fehlzeitenverwaltung, unser Bankingprogramm und momentan installiere ich gerade die Datev-Umgebung. Später kommt noch eine Zeiterfassung hinzu. Auf der VM2 werkelt bisher nur Veeam Backup. Als Sicherungsziel hab da per iSCSI mein NAS (QNAP TS-470U mit 12TB) als Ziel genommen. Für die Anbindung VMs (Virtual Switch - Switch 1 - Switch 2 - NAS) hab ich durchgehend je 2 NICs geteamt. Das schafft dann in einem ersten Test ca. 200MB/s.
Ggf. setz ich den WSUS auch auf VM2 rüber und greife deine Idee auf, die Daten des WSUS per iSCSI aufs NAS zu schubsen.
Gruß Arno
Servus,
danke für deine Sicht der Dinge. Ich kann da als versierter Enduser natürlich (noch) nicht sagen, was richtig / falsch bzw. besser / schlechter ist. Das wisst ihr Profis viel besser. Ich bin noch in der Lernphase
Den DC zu virtualisieren, ist zur Zeit kein Thema. Der WSE 2016 läuft so sauber, das ich da nicht ran möchte. Das kommt ggf. nächstes Jahr dran. Ziel der Virtualisierungsaktion war primär, das ganze Gedöns auf eine VM zu packen, das auf dem DC nichts verloren hat. Auf der VM1 läuft schon die Fehlzeitenverwaltung, unser Bankingprogramm und momentan installiere ich gerade die Datev-Umgebung. Später kommt noch eine Zeiterfassung hinzu. Auf der VM2 werkelt bisher nur Veeam Backup. Als Sicherungsziel hab da per iSCSI mein NAS (QNAP TS-470U mit 12TB) als Ziel genommen. Für die Anbindung VMs (Virtual Switch - Switch 1 - Switch 2 - NAS) hab ich durchgehend je 2 NICs geteamt. Das schafft dann in einem ersten Test ca. 200MB/s.
Ggf. setz ich den WSUS auch auf VM2 rüber und greife deine Idee auf, die Daten des WSUS per iSCSI aufs NAS zu schubsen.
Gruß Arno
Zitat von @NixVerstehen:
danke für deine Sicht der Dinge. Ich kann da als versierter Enduser natürlich (noch) nicht sagen, was richtig / falsch bzw. besser / schlechter ist. Das wisst ihr Profis viel besser. Ich bin noch in der Lernphase
Kein Problem danke für deine Sicht der Dinge. Ich kann da als versierter Enduser natürlich (noch) nicht sagen, was richtig / falsch bzw. besser / schlechter ist. Das wisst ihr Profis viel besser. Ich bin noch in der Lernphase
Mir ging es auch eher darum mitzuteilen, dass es kein Problem darstellt, nur einen virtuellen DC zu haben und den Hyper-V mit in dessen Domäne aufzunehmen.
Zitat von @goscho:
@Bem0815
Ich dachte einfach, ich nehme den Hyper-V Host in die Domäne auf, damit auch der sich über den WSUS (macht momentan noch der DC) seine Updates holen kann. Das ich dazu den DC auf separatem Blech brauche war mir irgendwie klar. Sonst baue ich mir selbst so ein "Hund beisst sich in eigenen ###"-Szenario
Ich möchte das auch gern mal aufgreifen:
Das ist nicht korrekt und zeugt davon, dass man sich damit nicht richtig beschäftigt hat.
Der Hyper-V startet ohne, das der DC da ist.
@Bem0815
Einen Hyper-V deshalb nur in die Domäne aufnehmen, wenn der DC extern ist.
Ich dachte einfach, ich nehme den Hyper-V Host in die Domäne auf, damit auch der sich über den WSUS (macht momentan noch der DC) seine Updates holen kann. Das ich dazu den DC auf separatem Blech brauche war mir irgendwie klar. Sonst baue ich mir selbst so ein "Hund beisst sich in eigenen ###"-Szenario
Ich möchte das auch gern mal aufgreifen:
Das ist nicht korrekt und zeugt davon, dass man sich damit nicht richtig beschäftigt hat.
Der Hyper-V startet ohne, das der DC da ist.
Natürlich tut er das. Es hat auch niemand was anderes behauptet.
Die Hyper-V-Dienste sind nicht vom DC abhängig.
Auch das hat gar niemand behauptet.
Die VM mit dem DC wird auf automatisch starten gesetzt und die anderen starten später (Startzeitverzögerung).
Was wenn die VM vom DC nicht automatisch hoch kommt da ein Problem besteht?
Sollte der virtuelle DC mal wirklich zu lange brauchen oder gar nicht starten, kann man sich (wie es @certifiedit.net ja geschrieben hat) mit den Credentials eines lokalen Benutzers am Hyper-V anmelden.
Ja wenn man die Logindaten vom Lokalen Benutzer weiß.
Sobald ein Rechner in der Domäne ist tendieren manche Mitarbeiter und auch Admins leider dazu nicht mehr die lokalen Credentials zu notieren.
In 99% der Fälle klappt das mit dem Anmelden. Aber wenn ich eins in der IT gelernt habe ist es, dass Murphys Law irgendwann halt mal zuschlägt.
War früher für ein Systemhaus tätig, hab genau so einen Fall mehrfach bei Kunden erlebt.
Daher gehe ich hier einfach auf Nummer sicher.
Mir deshalb wegen einem Posting pauschal zu unterstellen ich hätte mich mit dem Thema nicht beschäftigt ohne die Gründe zu erfragen finde ich ehrlich gesagt etwas daneben. Man hätte zuerst mal nachfragen können warum ich auf so eine Meinung komme.
Morgen bem,
ich glaube dir unterstellt man das unter dem Aspekt nicht, aber Admins, die keine lokalen Zugangsdaten notieren (oder absichern) sind eigentlich eher eine Sicherheitsgefahr. So oder so.
ich glaube dir unterstellt man das unter dem Aspekt nicht, aber Admins, die keine lokalen Zugangsdaten notieren (oder absichern) sind eigentlich eher eine Sicherheitsgefahr. So oder so.
Zitat von @certifiedit.net:
Morgen bem,
ich glaube dir unterstellt man das unter dem Aspekt nicht, aber Admins, die keine lokalen Zugangsdaten notieren (oder absichern) sind eigentlich eher eine Sicherheitsgefahr. So oder so.
Morgen bem,
ich glaube dir unterstellt man das unter dem Aspekt nicht, aber Admins, die keine lokalen Zugangsdaten notieren (oder absichern) sind eigentlich eher eine Sicherheitsgefahr. So oder so.
Mag richtig sein, kommt aber in genanntem Szenario immer wieder vor.
Wobei wir hier bei Kunden die von einem Systemhaus betreut werden bei "Admins" meist nicht von ausgebildetem IT Personal sprechen sondern von "einem Mitarbeiter der sich halt etwas besser mit Computern auskennt".
Was hier aber auch gerne mal vorkommt ist, dass die Daten zwar notiert wurden aber dann nicht mehr gefunden werden, da man sie ja jahrelang nicht gebraucht hat.
Wenn der Hyper-V gar nicht in der Domäne ist braucht man die lokalen Zugangsdaten doch etwas öfters. Dann verstauben die nicht sondern werden regelmäßig benutzt und damit ist auch der Ort eher bekannt an dem diese abgelegt sind. Oder es hat die dann sogar meist jemand in der Firma im Kopf (zusätzlich zur Dokumentation).
Mahlzeit zusammen,
first off all: Nicht streiten
Da bin ich ja froh, das ich als Laie von Monat zu Monat immer mehr richtig mache. Ich habe für die Clients als auch die Server jeweils
ein lokales Admin-Passwort. Das liegt in einem Umschlag zusammen mit den Domänen-Admin-Credentials im Tresor
und ist außerdem in meinem mit zunehmendem Alter schwammigeren Großhirn gespeichert
Aber prinzipiell ist es richtig, das in den meisten KMUs eben kein gelernter ITler vorhanden ist, sondern das derjenige macht, der
sich einigermaßen mit Computern auskennt. Solange man bereit ist, sich in der Richtung stetig und intensiv selbst fortzubilden,
ist da ja nichts gegen einzuwenden. In Kleinbetrieben hängt es natürlich auch meistens noch am Geld.
Gruß NV
first off all: Nicht streiten
Da bin ich ja froh, das ich als Laie von Monat zu Monat immer mehr richtig mache. Ich habe für die Clients als auch die Server jeweils
ein lokales Admin-Passwort. Das liegt in einem Umschlag zusammen mit den Domänen-Admin-Credentials im Tresor
und ist außerdem in meinem mit zunehmendem Alter schwammigeren Großhirn gespeichert
Aber prinzipiell ist es richtig, das in den meisten KMUs eben kein gelernter ITler vorhanden ist, sondern das derjenige macht, der
sich einigermaßen mit Computern auskennt. Solange man bereit ist, sich in der Richtung stetig und intensiv selbst fortzubilden,
ist da ja nichts gegen einzuwenden. In Kleinbetrieben hängt es natürlich auch meistens noch am Geld.
Gruß NV
Nochmal Mahlzeit,
nun der nächste Schritt zum Thema Hyper-V. Nachdem die Datev-Systemsoftware meine VM1 gestern während der Installation weitgehend zum Erliegen gebracht hat, habe ich nun herausgefunden, warum das so ist.
Da Hyper-V ja keine USB-Ports in den VMs hergibt, musste die Datev-SmartCard auf einen USB-Server (Silex DS-510) ins Netz umziehen.
Offensichtlich wirkt sich störend auf die Verbindung zur Smartcard aus, wenn NIC-Teaming eingerichtet ist. Nach dem Entfernen des
Teamings und Bindung des VirtualSwitch auf nur einen NIC funktioniert es nun. Was aber der tiefere Grund ist, erschließt sich mir nicht.
Gruß NV
nun der nächste Schritt zum Thema Hyper-V. Nachdem die Datev-Systemsoftware meine VM1 gestern während der Installation weitgehend zum Erliegen gebracht hat, habe ich nun herausgefunden, warum das so ist.
Da Hyper-V ja keine USB-Ports in den VMs hergibt, musste die Datev-SmartCard auf einen USB-Server (Silex DS-510) ins Netz umziehen.
Offensichtlich wirkt sich störend auf die Verbindung zur Smartcard aus, wenn NIC-Teaming eingerichtet ist. Nach dem Entfernen des
Teamings und Bindung des VirtualSwitch auf nur einen NIC funktioniert es nun. Was aber der tiefere Grund ist, erschließt sich mir nicht.
Gruß NV
Zitat von @NixVerstehen:
nun der nächste Schritt zum Thema Hyper-V. Nachdem die Datev-Systemsoftware meine VM1 gestern während der Installation weitgehend zum Erliegen gebracht hat, habe ich nun herausgefunden, warum das so ist.
Da Hyper-V ja keine USB-Ports in den VMs hergibt, musste die Datev-SmartCard auf einen USB-Server (Silex DS-510) ins Netz umziehen.
Offensichtlich wirkt sich störend auf die Verbindung zur Smartcard aus, wenn NIC-Teaming eingerichtet ist. Nach dem Entfernen des
Teamings und Bindung des VirtualSwitch auf nur einen NIC funktioniert es nun. Was aber der tiefere Grund ist, erschließt sich mir nicht.
NIC-Teaming muss daran nicht schuld sein.nun der nächste Schritt zum Thema Hyper-V. Nachdem die Datev-Systemsoftware meine VM1 gestern während der Installation weitgehend zum Erliegen gebracht hat, habe ich nun herausgefunden, warum das so ist.
Da Hyper-V ja keine USB-Ports in den VMs hergibt, musste die Datev-SmartCard auf einen USB-Server (Silex DS-510) ins Netz umziehen.
Offensichtlich wirkt sich störend auf die Verbindung zur Smartcard aus, wenn NIC-Teaming eingerichtet ist. Nach dem Entfernen des
Teamings und Bindung des VirtualSwitch auf nur einen NIC funktioniert es nun. Was aber der tiefere Grund ist, erschließt sich mir nicht.
Ich habe bei einem Kunden auch einen USB-Device-Server (SEH-UTN50a) für DATEV auf VM im Einsatz.
Auf dem Host habe ich die NICs auch per statischem Teaming verbunden, gibt keine Problem mit DATEV oder dem Dongle.
Eventuell ein Problem mit deinem Speziellen Device-Server.
Servus,
nachdem nun schon ein paar Tage vergangen sind, schreib ich mal was zu dem Thema. Das wichtigste vorneweg:
Alles rennt wie geschnitten Brot!
Auf dem Dell R540 (20C/40T, 160 GB RAM, RAID1 für HyperV-Host, RAID10 für die VMs) läuft der HyperV-Host (2019) mit zwei 2019 Standard als
VMs. In der ersten VM rödelt das ganze Gedöns (Fehlzeitenverwaltung, Datev-Umgebung, Banking), das vorher auf dem DC war.
In der zweiten VM läuft WSUS, Veeam Backup Community Edition, Veeam Backup O365 und der TrendMicro WFBS-Server.
In einer dritten VM (Windows 10) werkelt XPhone Connect für unsere TK-Anlage bzw. CTI. Und weil dann noch Platz war, läuft in einer vierten VM noch Ubuntu Server 18.04 LTS mit Zabbix fürs Monitoring.
Allen vielen Dank für die Hilfe.
Gruß NV
nachdem nun schon ein paar Tage vergangen sind, schreib ich mal was zu dem Thema. Das wichtigste vorneweg:
Alles rennt wie geschnitten Brot!
Auf dem Dell R540 (20C/40T, 160 GB RAM, RAID1 für HyperV-Host, RAID10 für die VMs) läuft der HyperV-Host (2019) mit zwei 2019 Standard als
VMs. In der ersten VM rödelt das ganze Gedöns (Fehlzeitenverwaltung, Datev-Umgebung, Banking), das vorher auf dem DC war.
In der zweiten VM läuft WSUS, Veeam Backup Community Edition, Veeam Backup O365 und der TrendMicro WFBS-Server.
In einer dritten VM (Windows 10) werkelt XPhone Connect für unsere TK-Anlage bzw. CTI. Und weil dann noch Platz war, läuft in einer vierten VM noch Ubuntu Server 18.04 LTS mit Zabbix fürs Monitoring.
Allen vielen Dank für die Hilfe.
Gruß NV
