23
Windows Server 2008 R2 auf Hypervisor Netzwerkerkennung regelmäßig neu ausführen - Firewallprofil
Hallo zusammen,
hier laufen mehrere virtuelle Windows Server 2008 R2 (Datenbankserver, WSUS etc.) zusammen mit einem SBS 2011 auf einem Hyper-V.
Mein Problem ist, dass immer, wenn der SBS, der auch gleichzeitig der DC ist, aufgrund von Wartungsarbeiten / Updates heruntergefahren werden muss bei allen anderen Servern die Firewall auf "Öffentlich" umspringt und alle Ports gesperrt werden.
Ist natürlich auch auf dem Hypervisor selbst.
Dies bleibt auch so lange, bis man entweder jeden Server einzeln neu startet oder die virtuelle Netzwerkkarte de- und wieder aktiviert.
Wenn ich Remote den Server herunterfahre kann ich das teilweise nicht mehr aus der Ferne geradebiegen, da ich mich dann selbst komplett aussperren würde.
Jetzt suche ich nach einer Lösung, dass die Domain Clients regelmäßig die Netzwerkerkennung automatisch erneut durchführen.
So könnte im Falle, dass durch den Ausfall des DC die Netzwerkerkennung "nicht identifiziertes Netzwerk" meldet, automatisch die Netzwerkerkennung nach einer gewissen Zeit neu starten und dann das Domänennetzwerk wieder erfolgreich ermitteln.
So würde die Firewall dementsprechend auf das Domainprofil wechseln und die Ports wieder wie eingestellt freigeben.
Hat jemand eine Idee, wie ich so etwas realisieren könnte?
Viele Grüße
Constantin
hier laufen mehrere virtuelle Windows Server 2008 R2 (Datenbankserver, WSUS etc.) zusammen mit einem SBS 2011 auf einem Hyper-V.
Mein Problem ist, dass immer, wenn der SBS, der auch gleichzeitig der DC ist, aufgrund von Wartungsarbeiten / Updates heruntergefahren werden muss bei allen anderen Servern die Firewall auf "Öffentlich" umspringt und alle Ports gesperrt werden.
Ist natürlich auch auf dem Hypervisor selbst.
Dies bleibt auch so lange, bis man entweder jeden Server einzeln neu startet oder die virtuelle Netzwerkkarte de- und wieder aktiviert.
Wenn ich Remote den Server herunterfahre kann ich das teilweise nicht mehr aus der Ferne geradebiegen, da ich mich dann selbst komplett aussperren würde.
Jetzt suche ich nach einer Lösung, dass die Domain Clients regelmäßig die Netzwerkerkennung automatisch erneut durchführen.
So könnte im Falle, dass durch den Ausfall des DC die Netzwerkerkennung "nicht identifiziertes Netzwerk" meldet, automatisch die Netzwerkerkennung nach einer gewissen Zeit neu starten und dann das Domänennetzwerk wieder erfolgreich ermitteln.
So würde die Firewall dementsprechend auf das Domainprofil wechseln und die Ports wieder wie eingestellt freigeben.
Hat jemand eine Idee, wie ich so etwas realisieren könnte?
Viele Grüße
Constantin
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 386350
Url: https://administrator.de/contentid/386350
Printed on: April 18, 2024 at 05:04 o'clock
23 Comments
Latest comment
Moin,
das kannst Du nur über einen zweiten DC abfangen, der nicht zeitgleich neugestartet wird, works as defined.
Gruss
das kannst Du nur über einen zweiten DC abfangen, der nicht zeitgleich neugestartet wird, works as defined.
Gruss
Das ist nicht gewünscht.
Es muss doch möglich sein z. B. via Script die Netzwerkerkennung erneut ausführen zu lassen, z. B. in stündlichem Intervall?
Es muss doch möglich sein z. B. via Script die Netzwerkerkennung erneut ausführen zu lassen, z. B. in stündlichem Intervall?
Moin,
mach' es richtig und installiere einen weiteren DC (darf kein SBS sein).
Gruß
mach' es richtig und installiere einen weiteren DC (darf kein SBS sein).
Gruß
bei deiner Konfiguration ist das gar nicht diskutabel! Da der Hyper-V Mitglied der Domäne ist, die er selbst hostet, ist ein weiterer DC zwingend erforderlich!
Moin
Ich habe selbst eine ähnliche Umgebung bei mir im Einsatz (kein SBS).
Warum bei dir die Netzwerkerkennung beim Host umspringt, wenn der SBS neugestartet wird, ist mir ein Rätsel.
Mein Hyper-V-Host ist laut Netzwerkerkennung in einem privatem Netzwerk und da bleibt er auch beim Reboot des einzigen DC (W2K8R2 als VM).
Zitat von @Kraemer:
bei deiner Konfiguration ist das gar nicht diskutabel! Da der Hyper-V Mitglied der Domäne ist, die er selbst hostet, ist ein weiterer DC zwingend erforderlich!
Das ist totaler Unsinn!bei deiner Konfiguration ist das gar nicht diskutabel! Da der Hyper-V Mitglied der Domäne ist, die er selbst hostet, ist ein weiterer DC zwingend erforderlich!
Ich habe selbst eine ähnliche Umgebung bei mir im Einsatz (kein SBS).
Warum bei dir die Netzwerkerkennung beim Host umspringt, wenn der SBS neugestartet wird, ist mir ein Rätsel.
Mein Hyper-V-Host ist laut Netzwerkerkennung in einem privatem Netzwerk und da bleibt er auch beim Reboot des einzigen DC (W2K8R2 als VM).
Zitat von @goscho:
Moin
und dein Gebrülle kannst du sicherlich auch belegen...Moin
Zitat von @Kraemer:
bei deiner Konfiguration ist das gar nicht diskutabel! Da der Hyper-V Mitglied der Domäne ist, die er selbst hostet, ist ein weiterer DC zwingend erforderlich!
Das ist totaler Unsinn!bei deiner Konfiguration ist das gar nicht diskutabel! Da der Hyper-V Mitglied der Domäne ist, die er selbst hostet, ist ein weiterer DC zwingend erforderlich!
Eine Aussage wie: "Funktioniert doch" zählt nicht. Eine Quelle, wo Microsoft das absegnet, ist hier von Nöten!
Zitat von @Kraemer:
Eine Aussage wie: "Funktioniert doch" zählt nicht. Eine Quelle, wo Microsoft das absegnet, ist hier von Nöten!
Ich kann unbelegte, pauschale Aussagen, wie die deine nicht ausstehen - schon gar nicht, wenn sie komplett falsch ist!Eine Aussage wie: "Funktioniert doch" zählt nicht. Eine Quelle, wo Microsoft das absegnet, ist hier von Nöten!
Daher habe ich das fettgeschrieben.
Ich gebe dir eine andere Quelle, denn von MS wirst du keine finden, die deine Aussage bestätigt:
Yes, Your Hyper-V Host Should be Domain-Joined
Zitat von @goscho:
dito!Zitat von @Kraemer:
Eine Aussage wie: "Funktioniert doch" zählt nicht. Eine Quelle, wo Microsoft das absegnet, ist hier von Nöten!
Ich kann unbelegte, pauschale Aussagen, wie die deine nicht ausstehenEine Aussage wie: "Funktioniert doch" zählt nicht. Eine Quelle, wo Microsoft das absegnet, ist hier von Nöten!
- schon gar nicht, wenn sie komplett falsch ist!
wir kommen gleich zum Äpfle/Birnen-ThemaIch gebe dir eine andere Quelle, denn von MS wirst du keine finden, die deine Aussage bestätigt:
Yes, Your Hyper-V Host Should be Domain-Joined
da geht es darum, das der Host einem AD joinen soll. Und das ist ja auch absolut richtig. Wo aber ist nun meine Aussage falsch?Yes, Your Hyper-V Host Should be Domain-Joined
Zitat von @goscho:
Warum bei dir die Netzwerkerkennung beim Host umspringt, wenn der SBS neugestartet wird, ist mir ein Rätsel.
Warum bei dir die Netzwerkerkennung beim Host umspringt, wenn der SBS neugestartet wird, ist mir ein Rätsel.
Na ja, das ist einfach. Wenn ein Domänenmitglied beim Neustart keine Domäne findet, und das kann er nicht, wenn der einzige DC nicht funktioniert, dann lädt er auch kein Domänennetzwerkprofil. Genaugenommen muss der zweite DC auch DNS bereitstellen und der zweite DNS Server auch verteilt werden (per DHCP oder manuell)
Moin,
Da könnte Dir evtl. die PowerShell helfen, schau mal unter:
Get-NetConnectionProfile
Set-NetconectionProfile
das ganze als dann als Task/Job laufen lassen.
VG
Da könnte Dir evtl. die PowerShell helfen, schau mal unter:
Get-NetConnectionProfile
Set-NetconectionProfile
das ganze als dann als Task/Job laufen lassen.
VG
Zitat von @Joker96:
Moin,
Da könnte Dir evtl. die PowerShell helfen, schau mal unter:
Get-NetConnectionProfile
Set-NetconectionProfile
das ganze als dann als Task/Job laufen lassen.
VG
Moin,
Da könnte Dir evtl. die PowerShell helfen, schau mal unter:
Get-NetConnectionProfile
Set-NetconectionProfile
das ganze als dann als Task/Job laufen lassen.
VG
Na das hört sich doch wirklich gut an!
Muss ich testen!!
Ich möchte keine Ressourcen verschwenden, einen zweiten DC installieren, nur weil ich nach dem Reboot des derzeit einzigen DC aufpassen muss, dass die Firewall nicht in das öffentliche Profil wechselt.
Das ist ja nur ~2 mal im Monat.
Zumal ja demnächst eh ein kompletter Umstieg auf neuere Versionen (end-of-lifetime) erfolgen muss...
Ich dachte an eine einfache, kleine Zwischenlösung bis dahin...
Also da scheint bei dir aber irgendwas anderes vermurkst zu sein. Solche kruden Hacks braucht man normalerweise nicht.
Der Netzwerktyp wird auch nicht dadurch bestimmt ob ein DC erreichbar ist oder nicht, sondern was du bei erstverbindung mit dem Netzwerk angegeben hast.
Ich jedenfalls kann meine DC VM im Hyper-V so oft neustarten wie ich will und trotzdem ändert sich bei den ganzen VMs und dem Hyper-V nichts am Netzwerktyp.
Der Netzwerktyp wird auch nicht dadurch bestimmt ob ein DC erreichbar ist oder nicht, sondern was du bei erstverbindung mit dem Netzwerk angegeben hast.
Ich jedenfalls kann meine DC VM im Hyper-V so oft neustarten wie ich will und trotzdem ändert sich bei den ganzen VMs und dem Hyper-V nichts am Netzwerktyp.
Moin,
ich meine mich zu erinnern, dass wenn man den NLA-Dienst (NlaSvc) neustartet, das Netzwerk auch wieder korrekt erkannt wird.
Das kannst du ja einfach in einem Task packen.
Ein 2.DC wäre in diesem Szenario sicherlich Best Pratice, aber "indiskutabel zwingend erforderlich" ist er nicht.
Es bringt aber durchaus einige Probleme mit sich.
Gruß
ich meine mich zu erinnern, dass wenn man den NLA-Dienst (NlaSvc) neustartet, das Netzwerk auch wieder korrekt erkannt wird.
Das kannst du ja einfach in einem Task packen.
Ein 2.DC wäre in diesem Szenario sicherlich Best Pratice, aber "indiskutabel zwingend erforderlich" ist er nicht.
Es bringt aber durchaus einige Probleme mit sich.
Gruß
Zitat von @Kraemer:
Du möchtest uns folgendes erklären:Ich gebe dir eine andere Quelle, denn von MS wirst du keine finden, die deine Aussage bestätigt:
Yes, Your Hyper-V Host Should be Domain-Joined
da geht es darum, das der Host einem AD joinen soll. Und das ist ja auch absolut richtig. Wo aber ist nun meine Aussage falsch?Yes, Your Hyper-V Host Should be Domain-Joined
Zitat von @Kraemer:
Da der Hyper-V Mitglied der Domäne ist, die er selbst hostet, ist ein weiterer DC zwingend erforderlich!
Es ist kein 2. DC zwingend erforderlich, zwar empfehlenswert, aber nicht erforderlich (Ausnahme: SMB3-Storage für VMs).Da der Hyper-V Mitglied der Domäne ist, die er selbst hostet, ist ein weiterer DC zwingend erforderlich!
Myth 2: The Hyper-V Domain Controller Myths
I tackle issues in this category often, and I’m very disheartened that they do not appear to be losing force. If you’re not familiar with what I’m talking about, there are a few myths that involve Hyper-V and domain controllers, with the basic premise of all of them being that if a Hyper-V host cannot reach a domain controller, something critical will not work. Every single one of these notions is false. This is not the post in which I wish to have this discussion, so I’m just going to leave it with a few simple remarks. Hyper-V does not need a domain controller to start. It does not need a domain controller to start its guests. It does not need a domain controller to allow you to log on using local credentials. If the cached credentials feature is enabled in your domain, Hyper-V does not need a domain controller to allow you to log on using those cached credentials. The only time that Hyper-V ever absolutely requires a domain controller is when it is utilizing virtual machines on SMB 3 storage. Leaving the Hyper-V host out of the domain precludes it from using SMB 3 storage at all, so that is not a solution to the problem.
I tackle issues in this category often, and I’m very disheartened that they do not appear to be losing force. If you’re not familiar with what I’m talking about, there are a few myths that involve Hyper-V and domain controllers, with the basic premise of all of them being that if a Hyper-V host cannot reach a domain controller, something critical will not work. Every single one of these notions is false. This is not the post in which I wish to have this discussion, so I’m just going to leave it with a few simple remarks. Hyper-V does not need a domain controller to start. It does not need a domain controller to start its guests. It does not need a domain controller to allow you to log on using local credentials. If the cached credentials feature is enabled in your domain, Hyper-V does not need a domain controller to allow you to log on using those cached credentials. The only time that Hyper-V ever absolutely requires a domain controller is when it is utilizing virtual machines on SMB 3 storage. Leaving the Hyper-V host out of the domain precludes it from using SMB 3 storage at all, so that is not a solution to the problem.
Zitat von @sabines:
Na ja, das ist einfach. Wenn ein Domänenmitglied beim Neustart keine Domäne findet, und das kann er nicht, wenn der einzige DC nicht funktioniert, dann lädt er auch kein Domänennetzwerkprofil. Genaugenommen muss der zweite DC auch DNS bereitstellen und der zweite DNS Server auch verteilt werden (per DHCP oder manuell)
Das Netzwerkprofil eines Hyper-V-Hosts muss nicht zwingend "Domäne" sein.Zitat von @goscho:
Warum bei dir die Netzwerkerkennung beim Host umspringt, wenn der SBS neugestartet wird, ist mir ein Rätsel.
Warum bei dir die Netzwerkerkennung beim Host umspringt, wenn der SBS neugestartet wird, ist mir ein Rätsel.
Na ja, das ist einfach. Wenn ein Domänenmitglied beim Neustart keine Domäne findet, und das kann er nicht, wenn der einzige DC nicht funktioniert, dann lädt er auch kein Domänennetzwerkprofil. Genaugenommen muss der zweite DC auch DNS bereitstellen und der zweite DNS Server auch verteilt werden (per DHCP oder manuell)
Mit dem Powershellbefehl wird es auf privat umgestellt und bleibt auch so nach erneuten Neustarts. Das sind meine Erfahrungen und die sind nicht wenige.
Zitat von @CKbeats:
Muss ich testen!!
Muss gar nicht als Task laufen.Zitat von @Joker96:
Da könnte Dir evtl. die PowerShell helfen, schau mal unter:
Get-NetConnectionProfile
Set-NetconectionProfile
das ganze als dann als Task/Job laufen lassen.
Na das hört sich doch wirklich gut an!Da könnte Dir evtl. die PowerShell helfen, schau mal unter:
Get-NetConnectionProfile
Set-NetconectionProfile
das ganze als dann als Task/Job laufen lassen.
Muss ich testen!!
Ich habe das einmalig umgestellt und beim nächsten reboot war das Netzwerkprofil "privat" (was vollkommen ausreicht).
Changing the Network Location of a Windows 2012 R2 Server Network Connection
Zitat von @bloodstix:
Also da scheint bei dir aber irgendwas anderes vermurkst zu sein. Solche kruden Hacks braucht man normalerweise nicht.
Also da scheint bei dir aber irgendwas anderes vermurkst zu sein. Solche kruden Hacks braucht man normalerweise nicht.
Ich kann es Dir nicht sagen...
Starte ich den SBS (DC) neu kommt bei den übrigen VMs "nicht authentifiziertes Netzwerk". Es wird das Domänennetzwerk angezeigt, aber durch den kurzzeitigen Wegfall des DC kommt ein Ausrufezeichen.
Starte ich den kompletten Hyper-V neu (Wiederherstellungsreihenfolge ist zuerst der DC, dann verzögert alle übrigen VM Server) fällt die Firewall auf "öffentliches Netzwerk" zurück. Trotz dass der DC wieder läuft wird das nicht mehr erkannt.
Die Lösung war bisher entweder die VM Server neu zu starten oder die virtuelle Netzwerkkarte kurz zu de- & wieder aktivieren.
Der DC stellt alles an Netzwerkstruktur... AD, DHCP, DNS etc.
Zitat von @goscho:
Mit dem Powershellbefehl wird es auf privat umgestellt und bleibt auch so nach erneuten Neustarts. Das sind meine Erfahrungen und die sind nicht wenige.
Zitat von @sabines:
Na ja, das ist einfach. Wenn ein Domänenmitglied beim Neustart keine Domäne findet, und das kann er nicht, wenn der einzige DC nicht funktioniert, dann lädt er auch kein Domänennetzwerkprofil. Genaugenommen muss der zweite DC auch DNS bereitstellen und der zweite DNS Server auch verteilt werden (per DHCP oder manuell)
Das Netzwerkprofil eines Hyper-V-Hosts muss nicht zwingend "Domäne" sein.Zitat von @goscho:
Warum bei dir die Netzwerkerkennung beim Host umspringt, wenn der SBS neugestartet wird, ist mir ein Rätsel.
Warum bei dir die Netzwerkerkennung beim Host umspringt, wenn der SBS neugestartet wird, ist mir ein Rätsel.
Na ja, das ist einfach. Wenn ein Domänenmitglied beim Neustart keine Domäne findet, und das kann er nicht, wenn der einzige DC nicht funktioniert, dann lädt er auch kein Domänennetzwerkprofil. Genaugenommen muss der zweite DC auch DNS bereitstellen und der zweite DNS Server auch verteilt werden (per DHCP oder manuell)
Mit dem Powershellbefehl wird es auf privat umgestellt und bleibt auch so nach erneuten Neustarts. Das sind meine Erfahrungen und die sind nicht wenige.
Es geht mir nicht um das Profil des Hyper-V, sondern um die anderen Server 2008, die als VMs laufen.
Der Hyper-V war früher nicht einmal Domänenmitglied, das hat der externe EDVler irgendwann geändert. Macht überhaupt nichts aus.
Durch das Fallback auf "Pivat" oder "Öffentlich" werden Ports für Datenbankschnittstellen auf den VM Servern gesperrt... die Workstations können die Betriebsprogramme nicht mehr laden.
Zitat von @bloodstix:
Also da scheint bei dir aber irgendwas anderes vermurkst zu sein. Solche kruden Hacks braucht man normalerweise nicht.
Ich jedenfalls kann meine DC VM im Hyper-V so oft neustarten wie ich will und trotzdem ändert sich bei den ganzen VMs und dem Hyper-V nichts am Netzwerktyp.
Das Profil "Domäne" wird nur eingestellt, wenn ein DC erreichbar istAlso da scheint bei dir aber irgendwas anderes vermurkst zu sein. Solche kruden Hacks braucht man normalerweise nicht.
Ich jedenfalls kann meine DC VM im Hyper-V so oft neustarten wie ich will und trotzdem ändert sich bei den ganzen VMs und dem Hyper-V nichts am Netzwerktyp.
Zitat von @CKbeats:
Starte ich den kompletten Hyper-V neu (Wiederherstellungsreihenfolge ist zuerst der DC, dann verzögert alle übrigen VM Server) fällt die Firewall auf "öffentliches Netzwerk" zurück. Trotz dass der DC wieder läuft wird das nicht mehr erkannt.
Da startet der DC wohl trotzdem noch zu langsam, so dass die anderen VMs noch keinen DC finden beim booten.Starte ich den kompletten Hyper-V neu (Wiederherstellungsreihenfolge ist zuerst der DC, dann verzögert alle übrigen VM Server) fällt die Firewall auf "öffentliches Netzwerk" zurück. Trotz dass der DC wieder läuft wird das nicht mehr erkannt.
Der DC stellt alles an Netzwerkstruktur... AD, DHCP, DNS etc.
Das ist oft so und nichts ungewöhnliches.
Hallo,
https://www.trishtech.com/2015/07/disable-active-internet-probing-ncsi-i ...
https://www.interfacett.com/blogs/configuring-network-connectivity-statu ...
https://blogs.technet.microsoft.com/networking/2012/12/20/the-network-co ...
Man kann auch einen eigene ncsi server betreiben... dann gibts auch keine gelben Ausrufezeichen mehr
Was also macht dein SBS noch ausser DND, DHCP, AD. Ist der etwa auch als GW bei deinen anderen Server bzw. Clients eingetragen?
Stell deine VMs so ein das zuerst dein SBS durchstartet und erst wenn dieser durcgestartet ist, die anderen VMs starten, dann sollte beim Visualisierer neustarten alles OK sein. Mehr als 10 Min. sollte es nicht dauern bis dein SBS gestartet ist, sonst deutet das auf weitere DNS probleme hin. Und sollten deine VMs auf Öffentliches Netzwerk umspringen, dann wenn der DC wieder da ist, eben per z.B. Skrip einfach die LAN Karte deaktivieren und erneut aktivieren. Das geht auch von der Ferne aus (aus wenn er während dieser aktion kurz weg ist) per Powershell.
Gruß,
Peter
Zitat von @CKbeats:
Starte ich den SBS (DC) neu kommt bei den übrigen VMs "nicht authentifiziertes Netzwerk". Es wird das Domänennetzwerk angezeigt, aber durch den kurzzeitigen Wegfall des DC kommt ein Ausrufezeichen.
Dir ist schon klar wan und warum dieses gelbe Ausrufezeichen kommt? Da kann ein Name von MS nicht aufgelöst werden (DNS) und es kann keine Verbindung hergestellt werden. Dein Rechner versucht den Namen http://www.msftncis.com um von dort die Datei ncsi.txt herunterzuladen. Diese IP ist 131.107.255.255Starte ich den SBS (DC) neu kommt bei den übrigen VMs "nicht authentifiziertes Netzwerk". Es wird das Domänennetzwerk angezeigt, aber durch den kurzzeitigen Wegfall des DC kommt ein Ausrufezeichen.
https://www.trishtech.com/2015/07/disable-active-internet-probing-ncsi-i ...
https://www.interfacett.com/blogs/configuring-network-connectivity-statu ...
https://blogs.technet.microsoft.com/networking/2012/12/20/the-network-co ...
Man kann auch einen eigene ncsi server betreiben... dann gibts auch keine gelben Ausrufezeichen mehr
Was also macht dein SBS noch ausser DND, DHCP, AD. Ist der etwa auch als GW bei deinen anderen Server bzw. Clients eingetragen?
Stell deine VMs so ein das zuerst dein SBS durchstartet und erst wenn dieser durcgestartet ist, die anderen VMs starten, dann sollte beim Visualisierer neustarten alles OK sein. Mehr als 10 Min. sollte es nicht dauern bis dein SBS gestartet ist, sonst deutet das auf weitere DNS probleme hin. Und sollten deine VMs auf Öffentliches Netzwerk umspringen, dann wenn der DC wieder da ist, eben per z.B. Skrip einfach die LAN Karte deaktivieren und erneut aktivieren. Das geht auch von der Ferne aus (aus wenn er während dieser aktion kurz weg ist) per Powershell.
Gruß,
Peter
Ich hatte einen Fehler!
goscho hat es schon geschrieben!
Ich hatte zwischen dem Booten des SBS und der übrigen Server nur 100 Sekunden dazwischen.
Das ist nun behoben.
Der SBS startet 60 Sekunden nach dem Hyper-V, alle übrigen Server 5 Minuten später... dann sollte das laufen.
Was meinst Du damit genau, Peter?
GW sagt mir nichts...
goscho hat es schon geschrieben!
Ich hatte zwischen dem Booten des SBS und der übrigen Server nur 100 Sekunden dazwischen.
Das ist nun behoben.
Der SBS startet 60 Sekunden nach dem Hyper-V, alle übrigen Server 5 Minuten später... dann sollte das laufen.
Zitat von @Pjordorf:
Was also macht dein SBS noch ausser DND, DHCP, AD. Ist der etwa auch als GW bei deinen anderen Server bzw. Clients eingetragen?
Was also macht dein SBS noch ausser DND, DHCP, AD. Ist der etwa auch als GW bei deinen anderen Server bzw. Clients eingetragen?
Was meinst Du damit genau, Peter?
GW sagt mir nichts...
Woher kommt denn dieser Zwang irgendwas mit Skripten erzwingen zu wollen was per default einfach funktionieren sollte. Wenn die Netzwerkerkennung rumspinnt gibts ganz wo anders ein Problem.
An den Symptomen rumdoktorn bringt temporör Ruhe, bis sich der Fehler vielleicht anderswie ausbreitet.
@Pjordorf meint mit GW = Gateway ... Standard Gateway in den Netzwerkoptionen. Zumeist der Router im Netz.
An den Symptomen rumdoktorn bringt temporör Ruhe, bis sich der Fehler vielleicht anderswie ausbreitet.
@Pjordorf meint mit GW = Gateway ... Standard Gateway in den Netzwerkoptionen. Zumeist der Router im Netz.
Ach so... nein.
Als Gateway wird über den DHCP die IP des DSL-Routers mitgeliefert.
Als Gateway wird über den DHCP die IP des DSL-Routers mitgeliefert.
Hallo,
Und nicht alle VMs danach gleichzeitig booten ausser du hast sehr sehr sehr schnelle Platten drin oder ein extrem schnells Storage (40 GBit/s oder so). Lege fest wann und in welcher reihenfolge die VMs starten sollen, dann kommen auch deine Platten hinterher. Alles eine frage deines Designs...
Gruß,
Peter
Zitat von @CKbeats:
Der SBS startet 60 Sekunden nach dem Hyper-V, alle übrigen Server 5 Minuten später... dann sollte das laufen.
Warum wartest vdu mit deinen DC noch 60 Sekunden nachdem der Hyper-V schon gebootet hat? Ist der sooo langsam?Der SBS startet 60 Sekunden nach dem Hyper-V, alle übrigen Server 5 Minuten später... dann sollte das laufen.
Und nicht alle VMs danach gleichzeitig booten ausser du hast sehr sehr sehr schnelle Platten drin oder ein extrem schnells Storage (40 GBit/s oder so). Lege fest wann und in welcher reihenfolge die VMs starten sollen, dann kommen auch deine Platten hinterher. Alles eine frage deines Designs...
GW sagt mir nichts...
GW steht für Gateway, wo ist das bei dir? Der DC?Gruß,
Peter
Zitat von @Pjordorf:
Hallo,
Warum wartest vdu mit deinen DC noch 60 Sekunden nachdem der Hyper-V schon gebootet hat? Ist der sooo langsam?
Und nicht alle VMs danach gleichzeitig booten ausser du hast sehr sehr sehr schnelle Platten drin oder ein extrem schnells Storage (40 GBit/s oder so). Lege fest wann und in welcher reihenfolge die VMs starten sollen, dann kommen auch deine Platten hinterher. Alles eine frage deines Designs...
Hallo,
Warum wartest vdu mit deinen DC noch 60 Sekunden nachdem der Hyper-V schon gebootet hat? Ist der sooo langsam?
Und nicht alle VMs danach gleichzeitig booten ausser du hast sehr sehr sehr schnelle Platten drin oder ein extrem schnells Storage (40 GBit/s oder so). Lege fest wann und in welcher reihenfolge die VMs starten sollen, dann kommen auch deine Platten hinterher. Alles eine frage deines Designs...
Einfach so, aber kann es natürlich auch auf sofort stellen... die Hardware ist für das System absolut ausreichend... Prozessorenlast liegt normal so um die 3-10%.
Die Platten sind SAS mit 1,95 GB/Sek.
GW steht für Gateway, wo ist das bei dir? Der DC?
Nein, ein Lancom Router
