dlohnier
Goto Top

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.
s2019-neu

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.
s2019-neu2

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

Content-Key: 667645

Url: https://administrator.de/contentid/667645

Ausgedruckt am: 19.03.2024 um 03:03 Uhr

Mitglied: ChriBo
ChriBo 16.06.2021 um 16:21:34 Uhr
Goto Top
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
Mitglied: em-pie
em-pie 16.06.2021 um 17:02:35 Uhr
Goto Top
Moin,
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.

Gruß
em-pie
Mitglied: FFSephiroth
FFSephiroth 16.06.2021 aktualisiert um 17:59:18 Uhr
Goto Top
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.
Mitglied: Pjordorf
Pjordorf 16.06.2021 um 19:41:02 Uhr
Goto Top
Hallo,

Zitat von @dlohnier:
Was tun?
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
Mitglied: MysticFoxDE
MysticFoxDE 17.06.2021 um 07:56:52 Uhr
Goto Top
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)
Set-NetConnectionProfile -InterfaceAlias "AQtion10GBit" -NetworkCategory Private  

Für Domänennetzwerk
Set-NetConnectionProfile -InterfaceAlias "AQtion10GBit" -NetworkCategory DomainAuthenticated  

Beste Grüsse aus BaWü
Alex
Mitglied: dlohnier
dlohnier 17.06.2021 um 10:34:17 Uhr
Goto Top
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
Mitglied: dlohnier
dlohnier 17.06.2021 um 19:00:06 Uhr
Goto Top
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
Mitglied: MysticFoxDE
MysticFoxDE 17.06.2021 um 21:26:00 Uhr
Goto Top
Moin Reinhold,

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
Mitglied: MysticFoxDE
Lösung MysticFoxDE 17.06.2021 aktualisiert um 22:15:32 Uhr
Goto Top
Moin Reinhold,

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.

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.

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.
s2019-neu

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.

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
Mitglied: Nebellicht
Nebellicht 18.06.2021 aktualisiert um 13:02:33 Uhr
Goto Top
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
Mitglied: Pjordorf
Lösung Pjordorf 18.06.2021 um 13:42:47 Uhr
Goto Top
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.

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.
Mit einen Task und Batch/Powershell geht das Problemlos, aber der TO sagt Lieber das MS Schuld sei.

Gruß,
Peter
Mitglied: dlohnier
dlohnier 21.06.2021 um 16:45:39 Uhr
Goto Top
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.
Mitglied: Pjordorf
Pjordorf 21.06.2021 aktualisiert um 17:24:30 Uhr
Goto Top
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)

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...
Mitglied: MysticFoxDE
Lösung MysticFoxDE 22.06.2021 aktualisiert um 08:06:32 Uhr
Goto Top
Moin Reinhold,

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.

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
Mitglied: dlohnier
dlohnier 22.06.2021 um 14:58:19 Uhr
Goto Top
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 ....?
Mitglied: MysticFoxDE
MysticFoxDE 22.06.2021 um 15:02:10 Uhr
Goto Top
Moin Reinhold,

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 ....?

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
Mitglied: FFSephiroth
FFSephiroth 22.06.2021 um 16:20:27 Uhr
Goto Top
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..
Mitglied: MysticFoxDE
MysticFoxDE 23.06.2021 aktualisiert um 07:45:44 Uhr
Goto Top
Moin FFSephiroth,

... "sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS" ...
... 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
Mitglied: dlohnier
dlohnier 24.06.2021 um 13:55:42 Uhr
Goto Top
Kling gut, er gibt aber nun bei meinem Server das Problem das der NLA Dienst gar nicht mehr starten will.
s2019-neu4

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
Mitglied: dlohnier
dlohnier 24.06.2021 um 13:59:21 Uhr
Goto Top
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.
Mitglied: dlohnier
dlohnier 24.06.2021 um 16:25:32 Uhr
Goto Top
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.
s2019-neu2

Gruß
Reinhold
Mitglied: Pjordorf
Pjordorf 24.06.2021 um 16:38:05 Uhr
Goto Top
Zitat von @dlohnier:
Auch mit weniger Abhängigkeiten bekomme ich das nicht mehr weg.
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
Mitglied: MysticFoxDE
MysticFoxDE 25.06.2021 aktualisiert um 07:59:19 Uhr
Goto Top
Moin Reinhold,

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.

vswitch

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.

pnic


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
Mitglied: dlohnier
dlohnier 28.06.2021 aktualisiert um 15:16:30 Uhr
Goto Top
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
Mitglied: dlohnier
dlohnier 28.06.2021 um 15:35:07 Uhr
Goto Top
Zitat von @Pjordorf:
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?
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.

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...
"Kauf den Laden auf und lasse deinen Fehler beheben", ein wirklich toller konstruktiver Vorschalg der von Know-How zeugt, klasse.**
Mitglied: em-pie
em-pie 28.06.2021 um 16:00:39 Uhr
Goto Top
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ß face-wink

Zitat von @Pjordorf:
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?
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.
Der Server ist zwar in 2022 EOL, aber erst in 2027 EOS
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...
"Kauf den Laden auf und lasse deinen Fehler beheben", ein wirklich toller konstruktiver Vorschalg der von Know-How zeugt, klasse.

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.
Mitglied: MysticFoxDE
MysticFoxDE 28.06.2021 aktualisiert um 21:00:06 Uhr
Goto Top
Moin em-pie,

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.

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
Mitglied: dlohnier
Lösung dlohnier 27.07.2021 um 14:11:32 Uhr
Goto Top
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.