28
Server 2019, Privates Netzwerk nach Neustart auf dem Host
Hallo,
ich habe einen WIndows Server 2016 den ich kürzlich von 2016 per In-Place-Upgrade auf 2019 gehoben habe.
Ebenfalls die 3 Hyper-V VM's mit Server 2016 (Exchange) und 2019 ( AD/DC und SQL).
Bei den VM's trat das Probem auch auf, dasnn nach einem Neustart das Netzwerk als Privates Netzwerk angezeigt wurde.
Ist scheinbar seit dem Anfang von WIndows 2019 drin und nicht von Microsoft behoben, verrückt.
Da half der Tipp "sc config NlaSvc depend= Netlogon"
den ich hier fand: Server 2019, frische Domäne - Privates Netzwerk nach dem Neustart
SO weit so gut.
Aber bei dem Host Server auf dem Blech hilft das nicht.
Das Netzwerk wird immer als Privates angezeigt.
Das sehr Dumme an der Sache ist, dass ich das remote nicht behebn kann.
Denn dazu muss man den NIC deaktiveren (und schon ist man weg) und dann wieder aktivieren.
Danach ist es dann zumindestens funktionabel da der V-Switch in der Domäne hängt.
Der physiche NIC aber nicht.
Was tun?
Ich habe nichts dazu gefunden.
Ich hoffe hier kennt jemand das Problem schon.
Ich wollte einen Suportfall bei Microsfot aufmachen, mit dem Action-Pack habe ich ja 5 Fälle pro Jahr offen und kostenlos.
Aber die haben da jetzt (früher ging das schon mal) eingebaut und fragen am Ende nach einer Abnonnementen-ID. Die kenne ich nicht und habe nichts dazu gefunden.
Und anrufen kann man dort nicht mehr als Partner, nur Webseite, toller Service, einfach Genial.
Vielen Dank
Gruß
Reinhold
ich habe einen WIndows Server 2016 den ich kürzlich von 2016 per In-Place-Upgrade auf 2019 gehoben habe.
Ebenfalls die 3 Hyper-V VM's mit Server 2016 (Exchange) und 2019 ( AD/DC und SQL).
Bei den VM's trat das Probem auch auf, dasnn nach einem Neustart das Netzwerk als Privates Netzwerk angezeigt wurde.
Ist scheinbar seit dem Anfang von WIndows 2019 drin und nicht von Microsoft behoben, verrückt.
Da half der Tipp "sc config NlaSvc depend= Netlogon"
den ich hier fand: Server 2019, frische Domäne - Privates Netzwerk nach dem Neustart
SO weit so gut.
Aber bei dem Host Server auf dem Blech hilft das nicht.
Das Netzwerk wird immer als Privates angezeigt.
Das sehr Dumme an der Sache ist, dass ich das remote nicht behebn kann.
Denn dazu muss man den NIC deaktiveren (und schon ist man weg) und dann wieder aktivieren.
Danach ist es dann zumindestens funktionabel da der V-Switch in der Domäne hängt.
Der physiche NIC aber nicht.
Was tun?
Ich habe nichts dazu gefunden.
Ich hoffe hier kennt jemand das Problem schon.
Ich wollte einen Suportfall bei Microsfot aufmachen, mit dem Action-Pack habe ich ja 5 Fälle pro Jahr offen und kostenlos.
Aber die haben da jetzt (früher ging das schon mal) eingebaut und fragen am Ende nach einer Abnonnementen-ID. Die kenne ich nicht und habe nichts dazu gefunden.
Und anrufen kann man dort nicht mehr als Partner, nur Webseite, toller Service, einfach Genial.
Vielen Dank
Gruß
Reinhold
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: 667645
Url: https://administrator.de/contentid/667645
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
28 Kommentare
Neuester Kommentar
Hi,
Wenn die Hardware ein "echter" Server ist, sollte das Aus- und Einschalten der NIC über die Remotemanagement Karte (iDRAC oä.) gelöst werden können, dabei verlierst du nicht die Verbindung zum Server
CH
Wenn die Hardware ein "echter" Server ist, sollte das Aus- und Einschalten der NIC über die Remotemanagement Karte (iDRAC oä.) gelöst werden können, dabei verlierst du nicht die Verbindung zum Server
CH
Moin,
Gruß
em-pie
Zitat von @ChriBo:
Hi,
Wenn die Hardware ein "echter" Server ist, sollte das Aus- und Einschalten der NIC über die Remotemanagement Karte (iDRAC oä.) gelöst werden können, dabei verlierst du nicht die Verbindung zum Server
CH
Wenn solch eine Möglichkeit besteht, kann man via (IP-)KVM, die ja heute quasi in den Server integriert ist (ja, es ist eigentlich keine KVM...) sich auf den Hyper-V aufschalten und dort die Einstellung vornehmen.Hi,
Wenn die Hardware ein "echter" Server ist, sollte das Aus- und Einschalten der NIC über die Remotemanagement Karte (iDRAC oä.) gelöst werden können, dabei verlierst du nicht die Verbindung zum Server
CH
Gruß
em-pie
Du hast den Thread nicht bis zum Ende gelesen!
cmd.exe als administrator starten und "sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS" ausführen.
Es wird jetzt nur der DNS-Serverdienst zu den NLA-Abhängigkeiten hinzugefügt ohne alle anderen Abhängigkeiten zu löschen!
Danach teste mal mit Neustart.
cmd.exe als administrator starten und "sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS" ausführen.
Es wird jetzt nur der DNS-Serverdienst zu den NLA-Abhängigkeiten hinzugefügt ohne alle anderen Abhängigkeiten zu löschen!
Danach teste mal mit Neustart.
Hallo,
Zur Not z.B. per Powershell und geplanten Task die NIC Deaktivieren, 5 Sek. warten und wieder Aktivieren. Fedisch
Gruß,
Peter
Zur Not z.B. per Powershell und geplanten Task die NIC Deaktivieren, 5 Sek. warten und wieder Aktivieren. Fedisch
# Get-ExecutionPolicy
# Set-ExecutionPolicy undefined
# Set-Executionpolicy remotesigned
Get-NetAdapter -Name "vEthernet (XXXXLAN)"
Write-Output -Verbose "Karte wird jetzt deaktiviert"
Write-Output -Verbose ". . . ."
Disable-NetAdapter -Name "vEthernet (>XXXXLAN)" -Confirm:$false
Write-Output -Verbose "Karte ist jetzt deaktiviert. Bitte 5 Sekunden warten ..."
Write-Output -Verbose ". . . ."
Get-NetAdapter -Name "vEthernet (XXXXLAN)"
Write-Output -Verbose ". . . ."
ping 127.0.0.1 -n 5
Enable-NetAdapter -Name "vEthernet (XXXXLAN)" -Confirm:$false
Write-Output -Verbose "Karte wurde wieder Aktiviert"
Write-Output -Verbose ". . . ."
Get-NetAdapter -Name "vEthernet (XXXXLAN)"
Write-Output -Verbose ". . . ."
ping 127.0.0.1 -n 5
pause
Gruß,
Peter
Moin Reinhold,
die Lösung ist ganz Easy.
Power-Shell Konsole als Admin öffnen und den folgenden Befehl abschiessen.
Für Privatnetzwerk (wenn keine Domäne vorhanden)
Für Domänennetzwerk
Beste Grüsse aus BaWü
Alex
die Lösung ist ganz Easy.
Power-Shell Konsole als Admin öffnen und den folgenden Befehl abschiessen.
Für Privatnetzwerk (wenn keine Domäne vorhanden)
Set-NetConnectionProfile -InterfaceAlias "AQtion10GBit" -NetworkCategory Private Für Domänennetzwerk
Set-NetConnectionProfile -InterfaceAlias "AQtion10GBit" -NetworkCategory DomainAuthenticated Beste Grüsse aus BaWü
Alex
Hallo Alex,
Danke.
Aber ich denke das hatte ich schon gefunden und probiert. Es funktionieert nicht bzw. ist so nicht vorgesehen scheint es.
Set-NetConnectionProfile : Unable to set NetworkCategory to 'DomainAuthenticated'.
This NetworkCategory type will be set automatically when authenticated to a domain network.
Gruß
Reinhold
Danke.
Aber ich denke das hatte ich schon gefunden und probiert. Es funktionieert nicht bzw. ist so nicht vorgesehen scheint es.
Set-NetConnectionProfile : Unable to set NetworkCategory to 'DomainAuthenticated'.
This NetworkCategory type will be set automatically when authenticated to a domain network.
Gruß
Reinhold
hallo,
ja, ist ein echter kleiner Fujitsu TX1330M2 Tower Server aus 2017. Der hat einen iRMC S4 Controller dafür, habe ich aber bisher nicht konfiguriert.
War zu flaul, brauchtes das nicht, Büro und Wohnung nur 4km entfernt.
Aber im Urlaub ist das u.U. sehr blöd.
Werde ich mir mal vorknöpfen, vielen Dank für den Tip.
Gruß
Reinhold
ja, ist ein echter kleiner Fujitsu TX1330M2 Tower Server aus 2017. Der hat einen iRMC S4 Controller dafür, habe ich aber bisher nicht konfiguriert.
War zu flaul, brauchtes das nicht, Büro und Wohnung nur 4km entfernt.
Aber im Urlaub ist das u.U. sehr blöd.
Werde ich mir mal vorknöpfen, vielen Dank für den Tip.
Gruß
Reinhold
Moin Reinhold,
ups, ja das stimmt, aber du kannst mit dem Befehl auf jeden Fall vom Internet Profil auf das private Profil wechseln und auch umgekehrt.
Gruss Alex
This NetworkCategory type will be set automatically when authenticated to a domain network.
ups, ja das stimmt, aber du kannst mit dem Befehl auf jeden Fall vom Internet Profil auf das private Profil wechseln und auch umgekehrt.
Gruss Alex
Moin Reinhold,
so, jetzt habe ich etwas mehr Zeit. 🤪
Das ist vollkommen normal und hat auch mehrere Gründe.
Das erste Problem ist dein DC, hier hast du wahrscheinlich nur einen und wenn dieser hochfährt, dann startet dessen NLA noch bevor der Netlogon Dienst hochgefahren wurde.
Wie man dieses Problem behebt, hast du ja bereits gefunden. 😀
Und wenn du nun etwas auf die Startreihenfolge achtest, sprich zuerst den DC hochfahren abwarten bis dessen Anmeldebildschirm kommt und dann erst die anderen VM's (Domänenmitglieder) hochfahren, dann hast du mit diesen auch keinen Stress mehr.
Und was ist daran so schlimm?
Dein Hyper-V Node ist hoffentlich kein Domänenmitglied der normalen Produktivdomäne und seine Verwaltungsschnittstelle
befindet sich hoffentlich in einem anderen Netzsegment und hängt nicht einfach im Produktivnetz rum.
Wenn der Hyper-V über die Verwaltungsschnittstelle dann noch Zugriff auf das Internet hat, dann ist es auch vollkommen OK,
dass dieser das Internet Profil auswählt. Das ist in diesem Fall kein BUG sondern gewollt so.
Wenn dir das mit dem Internetprofil nicht gefällt, dann kannst du mit dem unten geposteten Befehl, den Verbindungstyp der NIC's jederzeit auch auf privat umstellen.
Ich verstehe immer noch nicht so genau was du beheben möchtest, warum stresst dich das Internet Profil so sehr?
Kommst du remote auf den Hyper-V nicht mehr drauf wenn dies geschieht?
Wenn ja, dann ist eher die Windows-FireWall des Hyper-V Nodes das Problem.
Ein V-Switch der in einer Domäne hängt 🤔
Du bist da glaube ich auf einem falschen Pfad unterwegs, der V-Switch selber hat absolut keine Domänenabhängigkeit.
Ich dachte du möchtest das Problem lösen und es nicht noch verschlimmbessern. 🙃
Was genau ist eigentlich der Zweck der beiden NIC's?
Die eine ist sicherlich die Verwaltungs-NIC des Hyper-V, aber welche?
Und was macht die andere?
Beste Grüsse aus BaWü
Alex
so, jetzt habe ich etwas mehr Zeit. 🤪
ich habe einen WIndows Server 2016 den ich kürzlich von 2016 per In-Place-Upgrade auf 2019 gehoben habe.
Ebenfalls die 3 Hyper-V VM's mit Server 2016 (Exchange) und 2019 ( AD/DC und SQL).
Bei den VM's trat das Probem auch auf, dasnn nach einem Neustart das Netzwerk als Privates Netzwerk angezeigt wurde.
Ist scheinbar seit dem Anfang von WIndows 2019 drin und nicht von Microsoft behoben, verrückt.
Ebenfalls die 3 Hyper-V VM's mit Server 2016 (Exchange) und 2019 ( AD/DC und SQL).
Bei den VM's trat das Probem auch auf, dasnn nach einem Neustart das Netzwerk als Privates Netzwerk angezeigt wurde.
Ist scheinbar seit dem Anfang von WIndows 2019 drin und nicht von Microsoft behoben, verrückt.
Das ist vollkommen normal und hat auch mehrere Gründe.
Das erste Problem ist dein DC, hier hast du wahrscheinlich nur einen und wenn dieser hochfährt, dann startet dessen NLA noch bevor der Netlogon Dienst hochgefahren wurde.
Da half der Tipp "sc config NlaSvc depend= Netlogon"
den ich hier fand: Server 2019, frische Domäne - Privates Netzwerk nach dem Neustart
SO weit so gut.
den ich hier fand: Server 2019, frische Domäne - Privates Netzwerk nach dem Neustart
SO weit so gut.
Wie man dieses Problem behebt, hast du ja bereits gefunden. 😀
Und wenn du nun etwas auf die Startreihenfolge achtest, sprich zuerst den DC hochfahren abwarten bis dessen Anmeldebildschirm kommt und dann erst die anderen VM's (Domänenmitglieder) hochfahren, dann hast du mit diesen auch keinen Stress mehr.
Aber bei dem Host Server auf dem Blech hilft das nicht.
Das Netzwerk wird immer als Privates angezeigt.
Das Netzwerk wird immer als Privates angezeigt.
Und was ist daran so schlimm?
Dein Hyper-V Node ist hoffentlich kein Domänenmitglied der normalen Produktivdomäne und seine Verwaltungsschnittstelle
befindet sich hoffentlich in einem anderen Netzsegment und hängt nicht einfach im Produktivnetz rum.
Wenn der Hyper-V über die Verwaltungsschnittstelle dann noch Zugriff auf das Internet hat, dann ist es auch vollkommen OK,
dass dieser das Internet Profil auswählt. Das ist in diesem Fall kein BUG sondern gewollt so.
Wenn dir das mit dem Internetprofil nicht gefällt, dann kannst du mit dem unten geposteten Befehl, den Verbindungstyp der NIC's jederzeit auch auf privat umstellen.
Das sehr Dumme an der Sache ist, dass ich das remote nicht behebn kann.
Denn dazu muss man den NIC deaktiveren (und schon ist man weg) und dann wieder aktivieren.
Denn dazu muss man den NIC deaktiveren (und schon ist man weg) und dann wieder aktivieren.
Ich verstehe immer noch nicht so genau was du beheben möchtest, warum stresst dich das Internet Profil so sehr?
Kommst du remote auf den Hyper-V nicht mehr drauf wenn dies geschieht?
Wenn ja, dann ist eher die Windows-FireWall des Hyper-V Nodes das Problem.
Danach ist es dann zumindestens funktionabel da der V-Switch in der Domäne hängt.
Ein V-Switch der in einer Domäne hängt 🤔
Du bist da glaube ich auf einem falschen Pfad unterwegs, der V-Switch selber hat absolut keine Domänenabhängigkeit.
Ich wollte einen Suportfall bei Microsfot aufmachen ...
Ich dachte du möchtest das Problem lösen und es nicht noch verschlimmbessern. 🙃
Was genau ist eigentlich der Zweck der beiden NIC's?
Die eine ist sicherlich die Verwaltungs-NIC des Hyper-V, aber welche?
Und was macht die andere?
Beste Grüsse aus BaWü
Alex
Hallo,
ich hatte den gleichen "Fehler" bei mir hat auch der folgende Befehl (Shell) gehollfen:
sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS
privates-netzwerk-neustart
ich hatte den gleichen "Fehler" bei mir hat auch der folgende Befehl (Shell) gehollfen:
sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS
privates-netzwerk-neustart
Zitat von @MysticFoxDE:
Das erste Problem ist dein DC, hier hast du wahrscheinlich nur einen und wenn dieser hochfährt, dann startet dessen NLA noch bevor der Netlogon Dienst hochgefahren wurde.
Auf sein Host (Blech) läuft eine VM als DC und SQL Server, eine andere VM ist ein Exchange. Beide starten erst nachdem der Host oben ist und vermutlich gleichzeitig. Auch sagt der TO nichts zu der Hardware und Storage usw. Also selbstgebautes Problem. Ein zusätzlicher DC (VM oder Blech) der woanders läuft würde sein Netzwerk-Problem lösen. Oder er muss per Taskplaner und Batch / Powershell nach dem Neustarten seines Hosts und der volsständiger Start der VM für den DC/SQL eben die NIC Deaktivieren und erneut Aktivieren. Dazu ist keine Anmeldung am Host (Blech) nötig. Aber nicht MS ist Schuld, sein Design ist es. Selbst ein weiterer DC (nur DC) auf einen alten PC mit 2 GB RAM reicht da schon.Das erste Problem ist dein DC, hier hast du wahrscheinlich nur einen und wenn dieser hochfährt, dann startet dessen NLA noch bevor der Netlogon Dienst hochgefahren wurde.
Und wenn du nun etwas auf die Startreihenfolge achtest, sprich zuerst den DC hochfahren abwarten bis dessen Anmeldebildschirm kommt und dann erst die anderen VM's (Domänenmitglieder) hochfahren, dann hast du mit diesen auch keinen Stress mehr.
Und es geht Schneller wenn der Storage für die VMs ( 1 * DC/SQL und 1 * Exchange) nicht aus SATA Platten mit 5400 U/min besteht. SAS und min. 10000 U/min und RAID 1 oder RAID 10. Falsches Design.Denn dazu muss man den NIC deaktiveren (und schon ist man weg) und dann wieder aktivieren.
Gruß,
Peter
Auf dem Blech laufen 3 Hyper-V VMs.
1x Windows Sever 2019 als AD (DC)
1x Windows Sever 2019 mit SQL Server fürs ERP/CRM
1x 1x Windows Sever 2016 mit Exchange 2016 (da nicht so einfach auf 2019 upzudaten, das kommt später)
Storage für Host, Exchange und DC besteht in der Tat aus Festplatten, SSD sind noch teuer. Aber SAS 10000 U/min und RAID 10. Was ist da falsch? Für 3 Leute reicht das mehr als aus! Der SQL Server hat ein SAS-SSD Raid1.
Warum sollte ich mir einen weiteren PC mit DC hinstellen und diesen Administrieren müssen plus Stromkosten etc. Empfinde ich Overkill für eine sehr kleine Firma.
Der Host (Blech) managt nur noch die Freigabe eines Laufwerks für Daten und Dokumente, ich weiss, das ist nicht empfehlenswert. Aber für 3 user ist das überhaupt kein Thema. Früher hatten wir mal einen SmallBusinesServer da hat einer alles gemacht.
Wenn der Host startet startet nach 1 Sekunde die VM mt dem DC und dann nach 120 Sekunden die Exchange und die SQL VM.
Sicher ist MS Schuld, denn in dieser Konfiguration mit dieser Hardwar lief es mit Server 2016 ohne Probleme, woran also liegt es? Nicht an mir!
Klar kann man so was mit Batch/Powershell machen, ist aber für mich eine "Bastellösung". MS soll Server so machen,dass so etwas nicht passiert. War ja bei WIndows Server 2016 und davor auch nicht der Fall.
1x Windows Sever 2019 als AD (DC)
1x Windows Sever 2019 mit SQL Server fürs ERP/CRM
1x 1x Windows Sever 2016 mit Exchange 2016 (da nicht so einfach auf 2019 upzudaten, das kommt später)
Storage für Host, Exchange und DC besteht in der Tat aus Festplatten, SSD sind noch teuer. Aber SAS 10000 U/min und RAID 10. Was ist da falsch? Für 3 Leute reicht das mehr als aus! Der SQL Server hat ein SAS-SSD Raid1.
Warum sollte ich mir einen weiteren PC mit DC hinstellen und diesen Administrieren müssen plus Stromkosten etc. Empfinde ich Overkill für eine sehr kleine Firma.
Der Host (Blech) managt nur noch die Freigabe eines Laufwerks für Daten und Dokumente, ich weiss, das ist nicht empfehlenswert. Aber für 3 user ist das überhaupt kein Thema. Früher hatten wir mal einen SmallBusinesServer da hat einer alles gemacht.
Wenn der Host startet startet nach 1 Sekunde die VM mt dem DC und dann nach 120 Sekunden die Exchange und die SQL VM.
Sicher ist MS Schuld, denn in dieser Konfiguration mit dieser Hardwar lief es mit Server 2016 ohne Probleme, woran also liegt es? Nicht an mir!
Klar kann man so was mit Batch/Powershell machen, ist aber für mich eine "Bastellösung". MS soll Server so machen,dass so etwas nicht passiert. War ja bei WIndows Server 2016 und davor auch nicht der Fall.
Hallo,
Zitat von @dlohnier:
1x Windows Sever 2019 als AD (DC)
1x Windows Sever 2019 mit SQL Server fürs ERP/CRM
1x 1x Windows Sever 2016 mit Exchange 2016 (da nicht so einfach auf 2019 upzudaten, das kommt später)
Storage für Host, Exchange und DC besteht in der Tat aus Festplatten, SSD sind noch teuer. Aber SAS 10000 U/min und RAID 10. Was ist da falsch? Für 3 Leute reicht das mehr als aus! Der SQL Server hat ein SAS-SSD Raid1.
Und vermutlich noch sein DNS und DHCP mit auf den DC. Kein Problem wenn dieser DC immer an ist (auf anderer HW)1x Windows Sever 2019 als AD (DC)
1x Windows Sever 2019 mit SQL Server fürs ERP/CRM
1x 1x Windows Sever 2016 mit Exchange 2016 (da nicht so einfach auf 2019 upzudaten, das kommt später)
Storage für Host, Exchange und DC besteht in der Tat aus Festplatten, SSD sind noch teuer. Aber SAS 10000 U/min und RAID 10. Was ist da falsch? Für 3 Leute reicht das mehr als aus! Der SQL Server hat ein SAS-SSD Raid1.
Warum sollte ich mir einen weiteren PC mit DC hinstellen und diesen Administrieren müssen plus Stromkosten etc.
Weil du dann eben kein Problem mehr hättest. Ein alter intel NUC (22 Watt tuts auch als zusätzlichen DC wenn dein Host neu startet).Der Host (Blech) managt nur noch die Freigabe eines Laufwerks für Daten und Dokumente, ich weiss, das ist nicht empfehlenswert. Aber für 3 user ist das überhaupt kein Thema. Früher hatten wir mal einen SmallBusinesServer da hat einer alles gemacht.
Selbst ein NAS kann heutzutage als DC herhalten...Und MS hatte nach / mit den SBS 2008 schnell davon abstand genommen. Hat sich viel geändert, seit dem, auch MS hat dazugelernt.Wenn der Host startet startet nach 1 Sekunde die VM mt dem DC und dann nach 120 Sekunden die Exchange und die SQL VM.
Und wei lange brauchr deine erste VM bis alles dort so läuft wie erwartet?Sicher ist MS Schuld, denn in dieser Konfiguration mit dieser Hardwar lief es mit Server 2016 ohne Probleme, woran also liegt es? Nicht an mir!
Doch dein Fehler. Warum lässt du dann nicht Server 2016 wo ja alles zu 100% läuft?Klar kann man so was mit Batch/Powershell machen, ist aber für mich eine "Bastellösung". MS soll Server so machen,dass so etwas nicht passiert. War ja bei WIndows Server 2016 und davor auch nicht der Fall.
Zeige MS Schriftlich auf wo die deiner Meinung einen Fehler haben oder Kauf den Laden auf und lasse deinen Fehler beheben oder behelfe dich mit Batch / Powershell und Taskplaner oder zusätzlichen DC / DNS. Oder ändere dein Netzdesign...
Moin Reinhold,
Für drei Läute sollte die Hardware ausreichend sein.
Da kann ich nur zustimmen. Wir betreiben schon seit über einem Jahrzehnt und selbst bei grösseren Umgebungen keine separaten DC's ausserhalb der Virtualisierung und das ohne jegliche Probleme. Die meisten dieser Systeme sind übrigens mittlerweile auf 2019 migriert.
Das ist so tatsächlich nicht ganz korrekt.
Alleine schon aus gründen der Sicherheit, solltest du niemals einen Ottonormaluser direkt auf einen Hyper-V Node zugreifen lassen,
egal ob mit SMB oder anderen Dingen!
Jetzt verstehe ich auch dein Problem, du hast den Hyper-V Server in die produktive Domäne reingehängt, damit die Benutzer mit ihren Domänenzugangsdaten auf die Freigaben des Hyper-V Nodes kommen können. 😱
Wie schon oben geschrieben, alleine schon aus Gründen der Sicherheit sollte ein Hyper-V Node niemals in eine produktive Domäne gehängt werden und auch Netzwerkseitig sollte dieser mit seiner Managementschnittstelle nicht im selben Bereich wie die User rumgammeln.
Warum machst du für die Dateifreigabe nicht eine weitere VM und packst da die Daten drauf und startest diese genauso so verzögert wie die anderen, nachdem der virtuelle DC hochgefahren ist?
SmallBusinesServer ... 😮, da kommen Erinnerungen hoch, die meisten davon sind jedoch keine guten. 🤢
Wenn dein DC auf den HDD's liegt, dann reichen dir 120 Sekunden nicht aus, um alle notwendigen Domänendienste hochzufahren.
Selbst bei SSD, dauert der Start des ersten DC's weit mehr als eine Minute.
Sorry Reinhold, aber hier muss ich dir deutlich widersprechen.
Ein Hyper-V Node gehört wie schon oben geschrieben nicht in eine produktive Domäne und ist auch nicht zum bereitstellen von SMB Freigaben empfohlen. Es ist zwar technisch möglich das so zu realisieren wie du es gemacht hast, rein konzeptionell ist es jedoch nicht korrekt und funktioniert daher auch nicht sauber.
Auch beim 2016er war dieses Konstrukt so nicht von MS vorgesehen, da hattest du, so blöd es jetzt klingen mag, einfach nur Glück gehabt.
Mach für die Freigaben einen eigenen virtuellen Fileserver, starte diesen und die anderen VM's mit 300 Sekunden Verzögerung nach dem DC und deine Probleme gehören der Vergangenheit an.
Beste Grüsse aus BaWü
Alex
Auf dem Blech laufen 3 Hyper-V VMs.
1x Windows Sever 2019 als AD (DC)
1x Windows Sever 2019 mit SQL Server fürs ERP/CRM
1x 1x Windows Sever 2016 mit Exchange 2016 (da nicht so einfach auf 2019 upzudaten, das kommt später)
Storage für Host, Exchange und DC besteht in der Tat aus Festplatten, SSD sind noch teuer. Aber SAS 10000 U/min und RAID 10. Was ist da falsch? Für 3 Leute reicht das mehr als aus! Der SQL Server hat ein SAS-SSD Raid1.
1x Windows Sever 2019 als AD (DC)
1x Windows Sever 2019 mit SQL Server fürs ERP/CRM
1x 1x Windows Sever 2016 mit Exchange 2016 (da nicht so einfach auf 2019 upzudaten, das kommt später)
Storage für Host, Exchange und DC besteht in der Tat aus Festplatten, SSD sind noch teuer. Aber SAS 10000 U/min und RAID 10. Was ist da falsch? Für 3 Leute reicht das mehr als aus! Der SQL Server hat ein SAS-SSD Raid1.
Für drei Läute sollte die Hardware ausreichend sein.
Warum sollte ich mir einen weiteren PC mit DC hinstellen und diesen Administrieren müssen plus Stromkosten etc. Empfinde ich Overkill für eine sehr kleine Firma.
Da kann ich nur zustimmen. Wir betreiben schon seit über einem Jahrzehnt und selbst bei grösseren Umgebungen keine separaten DC's ausserhalb der Virtualisierung und das ohne jegliche Probleme. Die meisten dieser Systeme sind übrigens mittlerweile auf 2019 migriert.
Der Host (Blech) managt nur noch die Freigabe eines Laufwerks für Daten und Dokumente, ich weiss, das ist nicht empfehlenswert.
Das ist so tatsächlich nicht ganz korrekt.
Alleine schon aus gründen der Sicherheit, solltest du niemals einen Ottonormaluser direkt auf einen Hyper-V Node zugreifen lassen,
egal ob mit SMB oder anderen Dingen!
Jetzt verstehe ich auch dein Problem, du hast den Hyper-V Server in die produktive Domäne reingehängt, damit die Benutzer mit ihren Domänenzugangsdaten auf die Freigaben des Hyper-V Nodes kommen können. 😱
Wie schon oben geschrieben, alleine schon aus Gründen der Sicherheit sollte ein Hyper-V Node niemals in eine produktive Domäne gehängt werden und auch Netzwerkseitig sollte dieser mit seiner Managementschnittstelle nicht im selben Bereich wie die User rumgammeln.
Warum machst du für die Dateifreigabe nicht eine weitere VM und packst da die Daten drauf und startest diese genauso so verzögert wie die anderen, nachdem der virtuelle DC hochgefahren ist?
Aber für 3 user ist das überhaupt kein Thema. Früher hatten wir mal einen SmallBusinesServer da hat einer alles gemacht.
SmallBusinesServer ... 😮, da kommen Erinnerungen hoch, die meisten davon sind jedoch keine guten. 🤢
Wenn der Host startet startet nach 1 Sekunde die VM mt dem DC und dann nach 120 Sekunden die Exchange und die SQL VM.
Wenn dein DC auf den HDD's liegt, dann reichen dir 120 Sekunden nicht aus, um alle notwendigen Domänendienste hochzufahren.
Selbst bei SSD, dauert der Start des ersten DC's weit mehr als eine Minute.
Sicher ist MS Schuld, denn in dieser Konfiguration mit dieser Hardwar lief es mit Server 2016 ohne Probleme, woran also liegt es? Nicht an mir!
Sorry Reinhold, aber hier muss ich dir deutlich widersprechen.
Ein Hyper-V Node gehört wie schon oben geschrieben nicht in eine produktive Domäne und ist auch nicht zum bereitstellen von SMB Freigaben empfohlen. Es ist zwar technisch möglich das so zu realisieren wie du es gemacht hast, rein konzeptionell ist es jedoch nicht korrekt und funktioniert daher auch nicht sauber.
Klar kann man so was mit Batch/Powershell machen, ist aber für mich eine "Bastellösung". MS soll Server so machen, dass so etwas nicht passiert. War ja bei WIndows Server 2016 und davor auch nicht der Fall.
Auch beim 2016er war dieses Konstrukt so nicht von MS vorgesehen, da hattest du, so blöd es jetzt klingen mag, einfach nur Glück gehabt.
Mach für die Freigaben einen eigenen virtuellen Fileserver, starte diesen und die anderen VM's mit 300 Sekunden Verzögerung nach dem DC und deine Probleme gehören der Vergangenheit an.
Beste Grüsse aus BaWü
Alex
1
Hallo,
habe ich jetzt getestet.
Nun ja, es ändert etwas aber so richtig toll ist es nicht.
Im Eventlog nun dies hier
Der Dienst "Netzwerklistendienst" ist vom Dienst "NLA (Network Location Awareness)" abhängig, der aufgrund folgenden Fehlers nicht gestartet wurde:
Der Abhängigkeitsdienst ist nicht vorhanden oder wurde zum Löschen markiert.
Starten lässt sich NLA auch nicht mehr. Puhhh
Und gar keine NICs mehr im Status der Systemsteuerung:
Aber die VM's sind wie bisher alle im Dömänennetz der Host (Blech) ist unbekannt, aber im Netz per RDP erreichbar. Funktioniert also noch.
Was tun ....?
habe ich jetzt getestet.
Nun ja, es ändert etwas aber so richtig toll ist es nicht.
Im Eventlog nun dies hier
Der Dienst "Netzwerklistendienst" ist vom Dienst "NLA (Network Location Awareness)" abhängig, der aufgrund folgenden Fehlers nicht gestartet wurde:
Der Abhängigkeitsdienst ist nicht vorhanden oder wurde zum Löschen markiert.
Starten lässt sich NLA auch nicht mehr. Puhhh
Und gar keine NICs mehr im Status der Systemsteuerung:
Aber die VM's sind wie bisher alle im Dömänennetz der Host (Blech) ist unbekannt, aber im Netz per RDP erreichbar. Funktioniert also noch.
Was tun ....?
Moin Reinhold,
was genau hast du denn vorher gemacht?
Hast du etwa auf allen Servern das folgende ausgeführt?
Beste Grüsse aus BaWü
Alex
Zitat von @dlohnier:
Hallo,
habe ich jetzt getestet.
Nun ja, es ändert etwas aber so richtig toll ist es nicht.
Im Eventlog nun dies hier
Der Dienst "Netzwerklistendienst" ist vom Dienst "NLA (Network Location Awareness)" abhängig, der aufgrund folgenden Fehlers nicht gestartet wurde:
Der Abhängigkeitsdienst ist nicht vorhanden oder wurde zum Löschen markiert.
Starten lässt sich NLA auch nicht mehr. Puhhh
Und gar keine NICs mehr im Status der Systemsteuerung:
Aber die VM's sind wie bisher alle im Dömänennetz der Host (Blech) ist unbekannt, aber im Netz per RDP erreichbar. Funktioniert also noch.
Was tun ....?
Hallo,
habe ich jetzt getestet.
Nun ja, es ändert etwas aber so richtig toll ist es nicht.
Im Eventlog nun dies hier
Der Dienst "Netzwerklistendienst" ist vom Dienst "NLA (Network Location Awareness)" abhängig, der aufgrund folgenden Fehlers nicht gestartet wurde:
Der Abhängigkeitsdienst ist nicht vorhanden oder wurde zum Löschen markiert.
Starten lässt sich NLA auch nicht mehr. Puhhh
Und gar keine NICs mehr im Status der Systemsteuerung:
Aber die VM's sind wie bisher alle im Dömänennetz der Host (Blech) ist unbekannt, aber im Netz per RDP erreichbar. Funktioniert also noch.
Was tun ....?
was genau hast du denn vorher gemacht?
Hast du etwa auf allen Servern das folgende ausgeführt?
Da half der Tipp "sc config NlaSvc depend= Netlogon"
Beste Grüsse aus BaWü
Alex
Weil er den Thread nicht zu Ende gelesen hat...ich hab schon weiter oben geschrieben, das er "sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS" ausführen soll. Jetzt wird er alle Abhängigkeiten bis auf Netlogon deaktiviert haben..
1
Moin FFSephiroth,
Ja, das befürchte ich auch. 😬
Aber mit dem von dir geposteten Befehl sollte sich der Fehler eigentlich wieder korrigieren lassen.
Beste Grüsse aus BaWü
Alex
... "sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS" ...
... Jetzt wird er alle Abhängigkeiten bis auf Netlogon deaktiviert haben..
... Jetzt wird er alle Abhängigkeiten bis auf Netlogon deaktiviert haben..
Ja, das befürchte ich auch. 😬
Aber mit dem von dir geposteten Befehl sollte sich der Fehler eigentlich wieder korrigieren lassen.
Beste Grüsse aus BaWü
Alex
Kling gut, er gibt aber nun bei meinem Server das Problem das der NLA Dienst gar nicht mehr starten will.
Auch mit weniger Abhängigkeiten bekomme ich das nicht mehr weg.
Nur bei NSI/TCP läuft er dann wieder: sc config nlasvc depend=NSI/TcpIp
Auch mit weniger Abhängigkeiten bekomme ich das nicht mehr weg.
Nur bei NSI/TCP läuft er dann wieder: sc config nlasvc depend=NSI/TcpIp
Der Host (Blech) managt nur noch die Freigabe eines Laufwerks für Daten und Dokumente, ich weiss, das ist nicht empfehlenswert.
Das ist so tatsächlich nicht ganz korrekt.
Alleine schon aus gründen der Sicherheit, solltest du niemals einen Ottonormaluser direkt auf einen Hyper-V Node zugreifen lassen,
egal ob mit SMB oder anderen Dingen!
Jetzt verstehe ich auch dein Problem, du hast den Hyper-V Server in die produktive Domäne reingehängt, damit die Benutzer mit ihren Domänenzugangsdaten auf die Freigaben des Hyper-V Nodes kommen können. 😱
Wie schon oben geschrieben, alleine schon aus Gründen der Sicherheit sollte ein Hyper-V Node niemals in eine produktive Domäne gehängt werden und auch Netzwerkseitig sollte dieser mit seiner Managementschnittstelle nicht im selben Bereich wie die User rumgammeln.
Warum machst du für die Dateifreigabe nicht eine weitere VM und packst da die Daten drauf und startest diese genauso so verzögert wie die anderen, nachdem der virtuelle DC hochgefahren ist?
Vielen Danke Alex für die Erklärung.
So kapiere ich es warum das bisherige Verfahren nicht gut ist.
Ich habe nun eine 4te VM, auch Windows Server 2019 installiert und werde die 2 Freigaben dorhin umziehen kommende Woche.
Das ist so tatsächlich nicht ganz korrekt.
Alleine schon aus gründen der Sicherheit, solltest du niemals einen Ottonormaluser direkt auf einen Hyper-V Node zugreifen lassen,
egal ob mit SMB oder anderen Dingen!
Jetzt verstehe ich auch dein Problem, du hast den Hyper-V Server in die produktive Domäne reingehängt, damit die Benutzer mit ihren Domänenzugangsdaten auf die Freigaben des Hyper-V Nodes kommen können. 😱
Wie schon oben geschrieben, alleine schon aus Gründen der Sicherheit sollte ein Hyper-V Node niemals in eine produktive Domäne gehängt werden und auch Netzwerkseitig sollte dieser mit seiner Managementschnittstelle nicht im selben Bereich wie die User rumgammeln.
Warum machst du für die Dateifreigabe nicht eine weitere VM und packst da die Daten drauf und startest diese genauso so verzögert wie die anderen, nachdem der virtuelle DC hochgefahren ist?
Vielen Danke Alex für die Erklärung.
So kapiere ich es warum das bisherige Verfahren nicht gut ist.
Ich habe nun eine 4te VM, auch Windows Server 2019 installiert und werde die 2 Freigaben dorhin umziehen kommende Woche.
Was genau ist eigentlich der Zweck der beiden NIC's?
Die eine ist sicherlich die Verwaltungs-NIC des Hyper-V, aber welche?
Und was macht die andere?
Die 2 NICs sind physikalisch nur 1 NIC (Aquantia (jetzt Marvell) AQtion 10Gbit Karte). DenServer-Buildin Intel 1G NIC habe ich deaktiviert.
Der vEthernet Switch ist der Hyper-V switch auf der Basis des NIC und der AQtion 10GBit ist der physische NIC nach draussen.
Den muss ich doch haben, denn der Server muss ja irgendwie ins Intranet und Internet.
Gruß
Reinhold
Die eine ist sicherlich die Verwaltungs-NIC des Hyper-V, aber welche?
Und was macht die andere?
Die 2 NICs sind physikalisch nur 1 NIC (Aquantia (jetzt Marvell) AQtion 10Gbit Karte). DenServer-Buildin Intel 1G NIC habe ich deaktiviert.
Der vEthernet Switch ist der Hyper-V switch auf der Basis des NIC und der AQtion 10GBit ist der physische NIC nach draussen.
Den muss ich doch haben, denn der Server muss ja irgendwie ins Intranet und Internet.
Gruß
Reinhold
Starte dein Blech (Horst) Server neu und alles läuft wieder. Und erst nachdem dein DC (DNS?) wieder komplett läuft, einmal das Netzwerkkabel aus deiner NIC entfernen, 10 Sekunden warten und wieder Verbinden.
Gruß,
Peter
Gruß,
Peter
Moin Reinhold,
nur das ich das jetzt richtig verstanden habe.
Du hast eine singleport Marvel10G in diesem Server, die du einem vSwitch als Uplinkport verpasst hast.
Ferner hast du bei der Einrichtung des vSwitches den folgenden Hacken gesetzt.
Dadurch wird auf dem vSwitch eine vNIC (virtuelle Netzwerkkarte) direkt auf dem Host erstellt, die quasi virtuell zu einem der vSwitch-Ports "durchgepatcht" ist. Den vSwitch selber bekommst du übrigens nur per Power-Shell so richtig zum sehen, über das "Netzwerk- und Freigabecenter" ist dieser nicht sichtbar.
Sobald eine pNIC (physikalische Netzwerkarte) einem vSwitch als Uplinkport zugeordnet wird, steht diese normalerweise nicht mehr für die normale Hostkommunikation zur Verfügung, da auf dieser nur noch die beiden folgenden Funktionen aktiviert sein sollten.
Wenn bei dir auf der pNIC die du als Uplinkport für deinen vSwitch benutzt, TCP/IPv4, TCP/IPv6 & Co auch aktiviert sind, dann ist das nicht ganz korrekt so.
Kannst du als nächstes bitte mal das Ergebnis von ipconfig /all von deinem Host posten, danke.
Gut zu wissen, auf diesen komme ich später evtl. noch zurück, aber zuerst sollten wir das mit der AQtion vollends klären.
Wie schon oben geschrieben "vEthernet (Aquantia ..." ist nicht der vSwitch selbst sondern nur eine vNIC (virtuelle Netzwerkkarte) die an einen vSwitch gebunden ist. Die kannst du übrigens per Power-Shell nachträglich noch diverse weitere vNIC's auf demselben vSwitch für diesen Host erstellen.
Ja, über die vNIC oder am besten über den noch deaktivierten Intel Adapter. 😉
Beste Grüsse aus BaWü
Alex
Die 2 NICs sind physikalisch nur 1 NIC (Aquantia (jetzt Marvell) AQtion 10Gbit Karte).
nur das ich das jetzt richtig verstanden habe.
Du hast eine singleport Marvel10G in diesem Server, die du einem vSwitch als Uplinkport verpasst hast.
Ferner hast du bei der Einrichtung des vSwitches den folgenden Hacken gesetzt.
Dadurch wird auf dem vSwitch eine vNIC (virtuelle Netzwerkkarte) direkt auf dem Host erstellt, die quasi virtuell zu einem der vSwitch-Ports "durchgepatcht" ist. Den vSwitch selber bekommst du übrigens nur per Power-Shell so richtig zum sehen, über das "Netzwerk- und Freigabecenter" ist dieser nicht sichtbar.
Sobald eine pNIC (physikalische Netzwerkarte) einem vSwitch als Uplinkport zugeordnet wird, steht diese normalerweise nicht mehr für die normale Hostkommunikation zur Verfügung, da auf dieser nur noch die beiden folgenden Funktionen aktiviert sein sollten.
Wenn bei dir auf der pNIC die du als Uplinkport für deinen vSwitch benutzt, TCP/IPv4, TCP/IPv6 & Co auch aktiviert sind, dann ist das nicht ganz korrekt so.
Kannst du als nächstes bitte mal das Ergebnis von ipconfig /all von deinem Host posten, danke.
DenServer-Buildin Intel 1G NIC habe ich deaktiviert.
Gut zu wissen, auf diesen komme ich später evtl. noch zurück, aber zuerst sollten wir das mit der AQtion vollends klären.
Der vEthernet Switch ist der Hyper-V switch auf der Basis des NIC und der AQtion 10GBit ist der physische NIC nach draussen.
Wie schon oben geschrieben "vEthernet (Aquantia ..." ist nicht der vSwitch selbst sondern nur eine vNIC (virtuelle Netzwerkkarte) die an einen vSwitch gebunden ist. Die kannst du übrigens per Power-Shell nachträglich noch diverse weitere vNIC's auf demselben vSwitch für diesen Host erstellen.
Den muss ich doch haben, denn der Server muss ja irgendwie ins Intranet und Internet.
Ja, über die vNIC oder am besten über den noch deaktivierten Intel Adapter. 😉
Beste Grüsse aus BaWü
Alex
Hallo Alex,
Den muss ich doch haben, denn der Server muss ja irgendwie ins Intranet und Internet.
Ja, über die vNIC oder am besten über den noch deaktivierten Intel Adapter. 😉
Der Intel Adapter ist nur ein 1G Model, die AQtion kann 10G. Klar, fürs Internet ist das total unwichtig, aber mein Client PC und vor allem Das Asustor NAS ist mit 2.5G angebunden. Macht schon was aus, ist flotter. Das möchte nicht nicht mit der 1G Intel wieder verlieren.
Ja, der Haken bei "Gemeinsames Verwenden ..." ist aktiv.
HIer nun das Ergebniss von ipconfig /all ohne die MACadressen
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : Majestix
Primäres DNS-Suffix . . . . . . . : EmbeddedTools.local
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : EmbeddedTools.local
Ethernet-Adapter AQtion10GBit:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Marvell AQtion 10Gbit Network Adapter
Physische Adresse . . . . . . . . :
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.1.230(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.1.100
DNS-Server . . . . . . . . . . . : 192.168.1.233
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter vEthernet (Aquantia AQtion 10GBit V-Switch):
Verbindungsspezifisches DNS-Suffix: EmbeddedTools.local
Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
Physische Adresse . . . . . . . . :
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.1.103(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Dienstag, 22. Juni 2021 14:43:30
Lease läuft ab. . . . . . . . . . : Sonntag, 15. August 2021 17:17:33
Standardgateway . . . . . . . . . : 192.168.1.100
DHCP-Server . . . . . . . . . . . : 192.168.1.233
DNS-Server . . . . . . . . . . . : 192.168.1.233
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Gruß
Reinhold
Den muss ich doch haben, denn der Server muss ja irgendwie ins Intranet und Internet.
Ja, über die vNIC oder am besten über den noch deaktivierten Intel Adapter. 😉
Der Intel Adapter ist nur ein 1G Model, die AQtion kann 10G. Klar, fürs Internet ist das total unwichtig, aber mein Client PC und vor allem Das Asustor NAS ist mit 2.5G angebunden. Macht schon was aus, ist flotter. Das möchte nicht nicht mit der 1G Intel wieder verlieren.
Ja, der Haken bei "Gemeinsames Verwenden ..." ist aktiv.
HIer nun das Ergebniss von ipconfig /all ohne die MACadressen
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : Majestix
Primäres DNS-Suffix . . . . . . . : EmbeddedTools.local
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : EmbeddedTools.local
Ethernet-Adapter AQtion10GBit:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Marvell AQtion 10Gbit Network Adapter
Physische Adresse . . . . . . . . :
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.1.230(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.1.100
DNS-Server . . . . . . . . . . . : 192.168.1.233
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter vEthernet (Aquantia AQtion 10GBit V-Switch):
Verbindungsspezifisches DNS-Suffix: EmbeddedTools.local
Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
Physische Adresse . . . . . . . . :
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.1.103(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Dienstag, 22. Juni 2021 14:43:30
Lease läuft ab. . . . . . . . . . : Sonntag, 15. August 2021 17:17:33
Standardgateway . . . . . . . . . : 192.168.1.100
DHCP-Server . . . . . . . . . . . : 192.168.1.233
DNS-Server . . . . . . . . . . . : 192.168.1.233
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Gruß
Reinhold
Zitat von @Pjordorf:
Ganz klar nicht mein Fehler. Dieses Problem gab es beim Server 2016 nicht, aber die Updates zu laden und zu installieren war ein Riesenproblem. Ausserdem ist er bald EOL, man muss alos rechtzeitg was tun.Sicher ist MS Schuld, denn in dieser Konfiguration mit dieser Hardwar lief es mit Server 2016 ohne Probleme, woran also liegt es? Nicht an mir!
Doch dein Fehler. Warum lässt du dann nicht Server 2016 wo ja alles zu 100% läuft?Klar kann man so was mit Batch/Powershell machen, ist aber für mich eine "Bastellösung". MS soll Server so machen,dass so etwas nicht passiert. War ja bei WIndows Server 2016 und davor auch nicht der Fall.
Zeige MS Schriftlich auf wo die deiner Meinung einen Fehler haben oder Kauf den Laden auf und lasse deinen Fehler beheben oder behelfe dich mit Batch / Powershell und Taskplaner oder zusätzlichen DC / DNS. Oder ändere dein Netzdesign...Zitat von @dlohnier:
Moin,eine Bitte: du musst hier nicht alles in Fett kommentieren. Das ist störend/ unhöflich. ICH SCHREIBE JA AUCH NICHT ALLES GROß
Zitat von @Pjordorf:
Ganz klar nicht mein Fehler. Dieses Problem gab es beim Server 2016 nicht, aber die Updates zu laden und zu installieren war ein Riesenproblem. Ausserdem ist er bald EOL, man muss alos rechtzeitg was tun.Sicher ist MS Schuld, denn in dieser Konfiguration mit dieser Hardwar lief es mit Server 2016 ohne Probleme, woran also liegt es? Nicht an mir!
Doch dein Fehler. Warum lässt du dann nicht Server 2016 wo ja alles zu 100% läuft?https://endoflife.software/operating-systems/windows/windows-server
Klar kann man so was mit Batch/Powershell machen, ist aber für mich eine "Bastellösung". MS soll Server so machen,dass so etwas nicht passiert. War ja bei WIndows Server 2016 und davor auch nicht der Fall.
Zeige MS Schriftlich auf wo die deiner Meinung einen Fehler haben oder Kauf den Laden auf und lasse deinen Fehler beheben oder behelfe dich mit Batch / Powershell und Taskplaner oder zusätzlichen DC / DNS. Oder ändere dein Netzdesign...Ohne selbst Erfahrung in deinem obigen Konstrukt mit HyperV und der vNIC zu haben (komme aus der VMware-Welt), aber Netzwerkkarten sind meines Erachtens nach falsch mit IP-Adressen definiert.
Dein Problem wird sein, dass der Server nicht weiss, über welche NIC nun die Pakete wohin gehen sollen und dabei spielt er dann "russisch Roulette" und schickt die Pakete mal darüber und mal darüber.
Korrigiere das als erstes mal.
Eine NIC bleibt so, die andere von mir aus mit einer IP aus 192.168.99.0/24 ausstatten.
Moin em-pie,
Nein, das wir ihm nicht passieren, dlohnier hat ein Windows und die schicken die Antwort normalerweise über dieselbe IP zurück, über die auch die Anfrage reingekommen ist . Das was du da ansprichst ist eher eine Pinguin-Krankheit 😜.
Daher sollte man z.B. bei einer RDX die sowohl eine 1G NIC als auch eine 10G NIC besitzt, niemals beiden NIC's IP's aus demselben Subnet verpassen. Und der ESXi leidet soweit ich weis auch unter demselben Schnupfen.
@dlohnier
Aber em-pie hat trotzdem nicht ganz unrecht, ganz sauber ist diese IP-Konfiguration auch bei Windows nicht. 🙃
Beste Grüsse aus BaWü
Alex
Dein Problem wird sein, dass der Server nicht weiss, über welche NIC nun die Pakete wohin gehen sollen und dabei spielt er dann "russisch Roulette" und schickt die Pakete mal darüber und mal darüber.
Korrigiere das als erstes mal.
Korrigiere das als erstes mal.
Nein, das wir ihm nicht passieren, dlohnier hat ein Windows und die schicken die Antwort normalerweise über dieselbe IP zurück, über die auch die Anfrage reingekommen ist . Das was du da ansprichst ist eher eine Pinguin-Krankheit 😜.
Daher sollte man z.B. bei einer RDX die sowohl eine 1G NIC als auch eine 10G NIC besitzt, niemals beiden NIC's IP's aus demselben Subnet verpassen. Und der ESXi leidet soweit ich weis auch unter demselben Schnupfen.
@dlohnier
Aber em-pie hat trotzdem nicht ganz unrecht, ganz sauber ist diese IP-Konfiguration auch bei Windows nicht. 🙃
Beste Grüsse aus BaWü
Alex
Also, ich habe mit 2 2TB Samsung Server SSD's gegönnt und die 3 Server VM's nun auf ein neues RAID 1 gepackt.
Das beschleunigt in der Tat die Startzeit enorm - war zu erwaren - und behebt das Problem.
Die VM's sind immer in der Domäne und das Netzwerk auf dem Host Server ist Privat. Das st aber auch kein Problem so.
Die Dateifreigabe um die sihc der Host noch kümmert packe ich demnächst in eine weitere VM, dann hat der Host nichts mehr zu tun ausser Hyper-V zu managern.
Das beschleunigt in der Tat die Startzeit enorm - war zu erwaren - und behebt das Problem.
Die VM's sind immer in der Domäne und das Netzwerk auf dem Host Server ist Privat. Das st aber auch kein Problem so.
Die Dateifreigabe um die sihc der Host noch kümmert packe ich demnächst in eine weitere VM, dann hat der Host nichts mehr zu tun ausser Hyper-V zu managern.
