Untagged VLAN - Server 2025 Hyper-V
Hi, I have a strage issue and not finding a solution. Using Server 2025 with two node Hyper-V cluster. Most of the machines using VLANs which works fine. Some machines using no VLAN config. Which usually means the "Access VLAN 1" regarding our switch configuration. With Server 2019 this worked fine. With Server 2025 same NIC port, same server/NIC hardware "Untagged" VMs don't get any network connection. If I add a second NIC to the VM "Untagged" the NIC get immidiatly an IP address and has a proper connection. If I remove the first NIC, the second NIC stop working. It looks like something has changed with Server 2025 (maybe already with Server 2022). Do you have any idea what kinde of problem I have found? Thanks Jack
Choosing motherboard for Win 2022 Server
Hello, I'm trying to build a new box that can host Windows Server 2022 Standard. One possible motherboard product I've learned of is the Gigabyte B550M DS3H AC. Has anyone used this board for a Server 2022 deployment? If not, can you recommend one? Thanks, anwr98Bypass LBFO Teaming deprecation on Hyper-V and Windows Server 2022
Starting with Windows Server 1903 and 1909, Hyper-V virtual switches on an LBFO-type network adapter cluster are deprecated (see documentation). The technology remains supported, but it will not evolve. It is recommended to create an aggregate of type SET. In practice The SET is a very interesting technology that has some constraints. The interfaces used must have identical characteristics: Manufacturer Model Link speed Configuration Even if these constraints do not seem huge, we are very far from the flexibility of LBFO Teaming. As a reminder, this one has absolutely no constraints. In practice the SET is recommended with network interfaces of 10Gb or more. Therefore, we are very far from the target of the LBFO (use of all integrated boards with motherboard pro, Home Lab, refurbish). If SET cannot be used As of Windows Server 2022, it is not possible to use the Hyper-V Management Console to create a virtual switch with LBFO, as it will prompt an error saying that LBFO have been depreciated. However, it is possible to use PowerShell to create this virtual switch. First, create the Teaming of your network cards using the Server Manager, in my case the teaming will be with LACP mode and Dynamic load balancing mode. Then execute the below PowerShell Command to create the virtual switch based on the teaming created in the previous step: New-VMSwitch -Name "LAN" -NetAdapterName "LINK-AGGREGATION" -AllowNetLbfoTeams $true -AllowManagementOS $true In detail: The virtual switch will be named "LAN" The network adapter cluster teaming is named "LINK-AGGREGATION" The aggregate remains usable to access the Hyper-V host. You will see your network teaming up and running on Hyper-V host. Thats it!
DHCP Failover Issue – Standby Server Responding When It Should Not
Hi everyone, I'm encountering an issue with my DHCP failover setup in Hot Standby mode, and I need insights into why the standby server is providing DHCP leases when it shouldn’t. Setup Overview: I manage a network with over 100 sites worldwide, each having a local DHCP server. Each site has a dedicated DHCP server running on the server VLAN. Clients reside on different VLANs, and IP helpers (DHCP relay) are configured on a Checkpoint firewall at each site. The IP helper forwards DHCP requests to: The local DHCP server (primary) in the site's server VLAN. The standby DHCP server (failover), located at an on-premises data center (DC). DHCP servers are configured in Hot Standby mode using Microsoft DHCP Failover. Issue: Despite the Hot Standby configuration, I noticed that my Cisco Meraki dashboard frequently reports a new DHCP server detected, referring to the standby DHCP server, even though the primary DHCP server at the local site is available. Cisco Meraki triggers this alert when it detects DHCPACK packets from the standby DHCP server traversing the local networks. However, in Hot Standby mode, the failover server should only issue leases if the primary server is unreachable. Example: Site-1's primary DHCP server (DHCP-1) has a failover partnership with Failover-1 at the DC. Site-1's connectivity to the DC is stable, yet Cisco Meraki occasionally detects DHCPACK packets from Failover-1, triggering alerts. Troubleshooting Done So Far: Verified that failover mode is correctly set to Hot Standby (not Load Balance). Confirmed that the primary DHCP server is healthy and responding. Checked DHCP logs on both servers but found no clear failover events. Performed packet captures of DHCP traffic, but the results were inconclusive. Investigated whether Checkpoint firewall’s IP helper can prioritize the primary DHCP server, but it appears not to support this functionality. Created a PowerShell script to check for failover-related event logs (Event IDs: 20254 and 20255). This provided better visibility but did not correlate with the Meraki alerts. Questions: Are there any known scenarios where a standby DHCP server in Hot Standby mode might mistakenly issue leases, even when the primary is active? Is there any detailed information on the failover “heartbeat” mechanism between primary and standby servers? I found that it uses TCP port 647, but I couldn’t locate official documentation on the interval and failure conditions. Could failover state synchronization delays cause this behavior? Are there specific logs or PowerShell commands I should check to confirm why the standby server is responding? Is there a way to prevent the standby server from responding unless the primary is truly unreachable (e.g., registry settings, advanced configuration)? Any guidance or troubleshooting steps would be greatly appreciated! Thanks in advance.
BLOG: CVE-2024-38063 - Disabling IPv6 binding = fix - or not?
Dear community, in today's LinkedIn Stream and other social media you might have noticed a recent CVE and the recommendation to disable IPv6 in Windows Server and Windows Client. We are talking about this one: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38063 Reading the advisory carefully, Microsoft, strictly speaking, does not directly recommend disabling (technically remove binding) of IPv6. Citing: "Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability. The following mitigating factors might be helpful in your situation: Systems are not affected if IPv6 is disabled on the target machine." Maybe I am a bit nitpicking here about old experiences and would greatly appreciate a refreshed Microsoft statement on the disablement (unbinding) of IPv6 and the side-effects in 2024. What we have learned in the past - do no disable IPv6 easily. - yes, you can face issues with IPv6 being on by default and unexpected or misconfiguration. Often caused by DHCPv6, especially in the combination of critical domain controllers, Dual Stack ISPs and SoHo routers messing up your DNS. What's the fuss about IPv6? I am not actively using it in corporate / at home. IPv6 is being used in Windows. More specifically non-routable fe80 addresses and loopback ::1 for internal purposes of Windows or other software. One may complain use cases are - unrightfully - not well and transparent documented. Have a read in the past Here are some references that Copilot brings up. Trust my memory, I've read more like this. https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ipv6-for-the-windows-administrator-why-you-need-to-care-about/ba-p/256251 https://community.spiceworks.com/t/is-it-a-bad-practice-to-disabe-ipv6/781811/9 https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows My personal conclusion Hold on, we need patches for this CVE, but we should not disable IPv6 easily. Please disable IPv6 temporarily, when you cannot patch this CVE immediately / in time. Take notes which system you have had to disable and consider re-enabling once patches have been tested and applied. If you are using IPv6 knowingly, note the NIC configs. They will be lost when using static settings rather DHCPv6. I am sad to see that NetSec people, undoubtedly experts in their area, jump on the bandwaggon esp. on Social Media to easily disgrace the IPv6 by default enablement of Windows Client and Windows Server, telling you the easier story: "Disable IPv6 and you are good / if you do not need it." Let me counter: You might not know you're "needing it" it in the first place. Whenever you are changing system defaults in Windows, mind that Microsoft and other software vendors may not consider these changes in their testing. And the Crowdstrike Black Friday showed us clearly how outlier system configs and unwell testing goes along. Not very well. IPv6 usage and defaults today One of the most recent example that Microsoft is using IPv6 can be found in the Azure Arc Agent (Connected Machine Agent) changelog: "Better handling when IPv6 local loopback is disabled" source: https://learn.microsoft.com/en-us/azure/azure-arc/servers/agent-release-notes How can I disable IPv6, if required? Many roads led to Rome. Windows + X > Terminal / PowerShell (Admin) #save current NIC config into a simple text file Get-NetAdapterBinding -ComponentID "ms_tcpip6" | where Enabled -eq $true | Out-File $env:temp\original-ipv6-config.txt #disable IPv6 on all adapters Get-NetAdapterBinding -ComponentID "ms_tcpip6" | where Enabled -eq $true | Disable-NetAdapterBinding And how to revert the change? Windows + X > Terminal / PowerShell (Admin) #enable IPv6 on all adapters (mind the text file) Get-NetAdapterBinding -ComponentID "ms_tcpip6" | where Enabled -eq $true | Enable-NetAdapterBinding TL:DR Microsoft is using fe80 addresses and loopback ::1 addresses for internal reasons. IPv6 is preferrably used over IPv4 when it is bound to a network adapter, including said special non- routable addresses. Please disable IPv6 temporarily, when you cannot patch this CVE immediately / in time. Take notes of current config. Please share the word and mind that disabling IPv6 can turn your OS into an outlier system, causing immediate or later issue due lack of testing by Microsoft or other software vendors, assuming the defaults, which is IPv6 being turned on.[server 25314] External SET Team to Internal after Reboot.
I have created SET Teaming on Windows Server 25314 (actually from a previous build) using External and 3 Intel i350-T4 ports, configured for Hyper-V and external access. New-VMSwitch -Name SETSwitch -NetAdapterName "i350t4_1","i350t4_2","i350t4_3" -AllowManagementOS $true -EnableEmbeddedTeaming $true -EnableIov $true Set-VMSwitchTeam -Name SETSwitch -LoadBalancingAlgorithm Dynamic In that case, the Hyper-V VM and OS can be accessed normally, but when I restart Windows Server, all Adapters disappear from SET Teaming and are changed to the Internal setting, and network access is lost. The above logs were obtained at WPR with Profile in Network. Since the file is large, I will post a link to OneDrive. setTeamingTrouble.etl https://1drv.ms/u/s!AoGvAA_XXMTH-dJ2gkOa6E5hP4QhLg?e=7hPgLQ In addition, if the EnableIov option is set to $false, a BSOD (KMODE_EXCEPTION_HANDLED) will occur after the Switch is created. VMSWITCH.SYS 0x0000007e (0xffffffffc0000005, 0xfffff80643a95c61, 0xffffb28989f2a6d8, 0xffffb28989f29ef0) Addition 2: LBFO Teaming is working properly. I tried to send it through the Feedback Hub and could not get it to work, so I have included it here. Addition 3: Server 25324 LBFO Teaming with New-VMSwitch failed.Edit subnet mask or scope in dhcp server running in windows server - Solved
it's not possible to directly change the subnet mask of an existing DHCP scope in a running Windows DHCP server. Here are the steps: 1. Export the Existing Scope Configuration: Open a command prompt with administrative privileges. Type the following command to export the scope configuration to a text file: netsh dhcp server \\<DHCP_Server_Name> scope <Scope_IP_Address> dump > C:\dhcp.txt 2. Modify the Configuration File: Open the dhcp.txt file in a text editor. Locate the line that specifies the subnet mask (e.g., SubnetMask 255.255.255.0). Change the subnet mask to the desired value. Save the changes to the file. 3. Delete the Old Scope: In the DHCP management console, right-click the scope you want to modify and select "Delete." 4. Import the New Scope: In the command prompt, type the following command to import the modified configuration: netsh exec c:\dhcp.txt 5. Verify the Changes: In the DHCP management console, check if the scope has been re-created with the new subnet mask. Right-click the scope and select "Properties" to confirm the subnet mask change. (Major Point - Ensure that your existing network address and subnet network address remain the same after making changes. If they are not the same, you need to modify the entire network address in the text file. For example, if the original subnet is 255.255.255.0 and the network address is 10.1.10.0, and you change it to 255.255.252.0, then the network address should also be updated to 10.1.8.0. Therefore, you must replace all instances of 10.1.10.0 with 10.1.8.0 in the entire text file (using Ctrl+H for the replacement). Thats it....
