Quirk18231 0 Geschrieben 13. Juni Autor Melden Teilen Geschrieben 13. Juni ich werde dies jetzt am Wochenende Vor-Ort umstellen und dann Rückmeldung geben Danke Zitieren Link zu diesem Kommentar
Quirk18231 0 Geschrieben 18. Juni Autor Melden Teilen Geschrieben 18. Juni HI, also SET wurde eingerichtet. Ich werde berichten, ob es das behoben hat. Lösung: SET-Switche kann man nur über Powershell einrichten. New-VMSwitch -Name "MeinSwitchName" -NetAdapterName "NameNIC1","NameNIC2","NameNIC3","etc" -EnableEmbeddedTeaming $true -AllowManagementOS $true Set-VMSwitchTeam -Name SETvSwitch -LoadBalancingAlgorithm Dynamic Zitieren Link zu diesem Kommentar
Nobbyaushb 1.475 Geschrieben 18. Juni Melden Teilen Geschrieben 18. Juni Wer bitte macht denn Management auf dem gleichen Adapter wie für die VM´s? Und warum drei Karten, oder sind die alle gleich schnell? Und das es nur per Powershell geht wurde geschrieben... Zitieren Link zu diesem Kommentar
NilsK 2.955 Geschrieben 21. Juni Melden Teilen Geschrieben 21. Juni Moin, Am 18.6.2024 um 10:11 schrieb Nobbyaushb: Wer bitte macht denn Management auf dem gleichen Adapter wie für die VM´s? naja, so grundsätzlich falsch ist das je nach Umgebung ja nun nicht. In vielen Netzen gibt es keine Netzwerktrennung zwischen Zugriff und Management, dann braucht man auch keinen separaten NIC dafür. Und unübersichtlich ist das Networking in Hyper-V so oder so, dafür macht das auch keinen Unterschied. Am 18.6.2024 um 10:11 schrieb Nobbyaushb: Und warum drei Karten, oder sind die alle gleich schnell? Dass das ein Beispielkommando ist, hast du aber gesehen, oder? Gruß, Nils Zitieren Link zu diesem Kommentar
Quirk18231 0 Geschrieben 26. Juni Autor Melden Teilen Geschrieben 26. Juni (bearbeitet) Hi, also das SET hat funktioniert, der Fehler ist leider immer noch da. Einmal die Woche verliert der eine Server seine Internetconnection. Innerhalb der Domäne läuft alles, die Konnektivität nach außen geht flöten. Netzwerkkarte rein raus löst das Prob, bis zur nächsten Woche. Die Eventanzeigen zeigt keinen Fehler zum dem Problem. Was kann das sein? Danke bearbeitet 26. Juni von Quirk18231 Zitieren Link zu diesem Kommentar
NilsK 2.955 Geschrieben 26. Juni Melden Teilen Geschrieben 26. Juni Moin, dann noch mal der Reihe nach. Was ist bei dir jetzt vor 32 Minuten schrieb Quirk18231: der eine Server ? Handelt es sich dabei um einen der Hosts oder um eine VM? Gruß, Nils Zitieren Link zu diesem Kommentar
Quirk18231 0 Geschrieben 26. Juni Autor Melden Teilen Geschrieben 26. Juni das ist eine VM auf einem HYPERV Zitieren Link zu diesem Kommentar
Nobbyaushb 1.475 Geschrieben 26. Juni Melden Teilen Geschrieben 26. Juni vor 7 Minuten schrieb Quirk18231: das ist eine VM auf einem HYPERV Dann würde ich die Funktionen der VM auf eine neu installierte VM umziehen Ist meist einfach... - und du bist die Altlasten los... Zitieren Link zu diesem Kommentar
NilsK 2.955 Geschrieben 26. Juni Melden Teilen Geschrieben 26. Juni Moin, vor 15 Minuten schrieb Nobbyaushb: Dann würde ich die Funktionen der VM auf eine neu installierte VM umziehen dazu würde ich auch neigen, wenn es tatsächlich die einzige VM ist, die solche Macken zeigt. Was für eine Funktion hat die VM denn? Gruß, Nils Zitieren Link zu diesem Kommentar
Quirk18231 0 Geschrieben 26. Juni Autor Melden Teilen Geschrieben 26. Juni Terminalserver mit Zugriff auf alle anderen Server/Programme im Netz. Würde es also eher gerne versuchen zu reparieren, anstatt neu zu machen. Danke Q Zitieren Link zu diesem Kommentar
NilsK 2.955 Geschrieben 26. Juni Melden Teilen Geschrieben 26. Juni Moin, und was heißt vor 2 Stunden schrieb Quirk18231: Netzwerkkarte rein raus löst das Prob genau? Was machst du da? Schätze, jetzt müsste man ins Kleinkram-Troubleshooting einsteigen: Passiert die Unterbrechung genau einmal in der Woche oder nur ungefähr? Finden in dem zeitlichen Zusammenhang noch andere Dinge statt, etwa Datensicherungen? Hilft es, die VM einfach neu zu starten? Zuerst hattest du geschrieben: "Die Einstellungen stehen alle auf einmal auf DHCP & der Server sit aber nicht mehr erreichbar", jetzt hingegen schreibst du: "Innerhalb der Domäne läuft alles, die Konnektivität nach außen geht flöten." Also hat sich das Fehlerbild verändert? Was könnte dazu geführt haben? Grundsätzlich gehe ich davon aus, dass die VM mit dem Wechsel der Netzwerktreiber einen Hau wegbekommen hat, z.B. weil doch irgendwas nicht richtig entfernt wurde. Du schreibst, du hättest dafür ein Skript eingesetzt - da ist jetzt natürlich unklar, was das gemacht hat. Allgemein empfiehlt man, die VMware-Tools über deren Installer zu deinstallieren, das ist hier evtl. nicht geschehen. Man könnte jetzt also auch auf die Suche gehen, ob da irgendwo noch was im System ist. Aber mein Gefühl sagt mir, dass es effizienter wäre, die VM neu zu machen. Gruß, Nils 1 Zitieren Link zu diesem Kommentar
Quirk18231 0 Geschrieben 27. Juni Autor Melden Teilen Geschrieben 27. Juni - also ich habe das TeamNIC aufgelöst und auf SET gesetzt, - es gibt 15 Minuten vom letzten Crash ein abgeschlossenes Backup (diese gibt es aber 2x am Tag) - Skript: Remove_VMWaretools.ps1: # This script will manually rip out all VMware Tools registry entries and files for Windows 2008-2019 # Tested for 2019, 2016, and probably works on 2012 R2 after the 2016 fixes. # This function pulls out the common ID used for most of the VMware registry entries along with the ID # associated with the MSI for VMware Tools. function Get-VMwareToolsInstallerID { foreach ($item in $(Get-ChildItem Registry::HKEY_CLASSES_ROOT\Installer\Products)) { If ($item.GetValue('ProductName') -eq 'VMware Tools') { return @{ reg_id = $item.PSChildName; msi_id = [Regex]::Match($item.GetValue('ProductIcon'), '(?<={)(.*?)(?=})') | Select-Object -ExpandProperty Value } } } } $vmware_tools_ids = Get-VMwareToolsInstallerID # Targets we can hit with the common registry ID from $vmware_tools_ids.reg_id $reg_targets = @( "Registry::HKEY_CLASSES_ROOT\Installer\Features\", "Registry::HKEY_CLASSES_ROOT\Installer\Products\", "HKLM:\SOFTWARE\Classes\Installer\Features\", "HKLM:\SOFTWARE\Classes\Installer\Products\", "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\" ) $VMware_Tools_Directory = "C:\Program Files\VMware" # Create an empty array to hold all the uninstallation targets and compose the entries into the target array $targets = @() If ($vmware_tools_ids) { foreach ($item in $reg_targets) { $targets += $item + $vmware_tools_ids.reg_id } # Add the MSI installer ID regkey $targets += "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{$($vmware_tools_ids.msi_id)}" } # This is a bit of a shotgun approach, but if we are at a version less than 2016, add the Uninstaller entries we don't # try to automatically determine. If ([Environment]::OSVersion.Version.Major -lt 10) { $targets += "HKCR:\CLSID\{D86ADE52-C4D9-4B98-AA0D-9B0C7F1EBBC8}" $targets += "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9709436B-5A41-4946-8BE7-2AA433CAF108}" $targets += "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{FE2F6A2C-196E-4210-9C04-2B1BC21F07EF}" } # Add the VMware, Inc regkey If (Test-Path "HKLM:\SOFTWARE\VMware, Inc.") { $targets += "HKLM:\SOFTWARE\VMware, Inc." } # Add the VMware Tools directory If(Test-Path $VMware_Tools_Directory) { $targets += $VMware_Tools_Directory } # Create a list of services to stop and remove $services = Get-Service -DisplayName "VMware*" $services += Get-Service -DisplayName "GISvc" # Warn the user about what is about to happen # Takes only y for an answer, bails otherwise. Write-Host "The following registry keys, filesystem folders, and services will be deleted:" If (!$targets -and !$services ) { Write-Host "Nothing to do!" } Else { $targets $services $user_confirmed = Read-Host "Continue (y/n)" If ($user_confirmed -eq "y") { # Stop all running VMware Services $services | Stop-Service -Confirm:$false # Cover for Remove-Service not existing in PowerShell versions < 6.0 If (Get-Command Remove-Service -errorAction SilentlyContinue) { $services | Remove-Service -Confirm:$false } Else { foreach ($s in $services) { sc.exe DELETE $($s.Name) } } # Remove all the files that are listed in $targets foreach ($item in $targets) { If(Test-Path $item) { Remove-Item -Path $item -Recurse } } Write-Host "Done. Reboot to complete removal." } Else { Write-Host "Failed to get user confirmation" } } Zitieren Link zu diesem Kommentar
NorbertFe 2.061 Geschrieben 27. Juni Melden Teilen Geschrieben 27. Juni vor 28 Minuten schrieb Quirk18231: Skript: Remove_VMWaretools.ps1: Weißt du, warum es hier die codeblock Formatierung im Forum gibt? ;) Zitieren Link zu diesem Kommentar
Quirk18231 0 Geschrieben 27. Juni Autor Melden Teilen Geschrieben 27. Juni nein? :) siehst Du den Code nicht? https://gist.github.com/broestls/f872872a00acee2fca02017160840624 Q Zitieren Link zu diesem Kommentar
cj_berlin 1.329 Geschrieben 27. Juni Melden Teilen Geschrieben 27. Juni OK, das Skript entfernt also die VMware-Produkte. Du müsstest aber auch die nun nicht mehr sichtbaren Netzwerkadapter rausputzen. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.