Bypass 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!
Windows Server OSConfig and DSCv3
Introduction I wanted to formalize putting a post out here to get some discussion going on the attempts at modernization of Windows configuration, and importantly, infrastructure-as-code. Hopefully this is a healthy discussion that others can engage in. Much of what I'm going to try and post about is stuff we already are aware of, but I want to highlight how this is an ongoing concern with the Windows Server platform that makes it difficult to encourage people to even consider Windows in their environment other than for extremely legacy purposes. I want Windows Server to be the best it can be, and I encourage others to join in on the conversation! Problem Statement Windows Server needs a modernized configuration-as-code system. Must be capable of orchestrating without cloud tools (offline orchestration) Must provide for regular validation and attestation Ideally should be easily available to 3rd party configuration tools. Since Microsoft appears to have little interest in building their own modernized system that isn't Azure-based, this means that this MUST be orchestrated easily and securely by 3rd party tools. Should be as robust as GPO at maintaining and enforcing state. Security configurations in Windows are a right pain to manage with any 3rd party tooling, with the closest coming to it being the SecurityDSC module which wraps secedit.exe and security policy INFs. Why is OSConfig not the answer? OSConfig doesn't provide for me, as an engineer, to clearly define what the state of my machines are based on my company's business requirements. While the built-in Microsoft policy recommendations are great, there are reasons to deviate from these policies in a predictable and idempotent manner. Applying an OSConfig Baseline -> Then changing settings as-needed with special PowerShell commands This is not the answer. This is a bunch of imperative code that serves nobody. And it makes implementing this feature extremely challenging in today's modern world of Kubernetes, Docker, etc. I encourage the Windows Server team to engage with the PowerShell team on DSC 3.0. I think that team has it right, but they are a small group of people and do not have the resources to implement everything that would make DSC 3.0 a first-class configuration as code platform on Windows. And this is where the Windows team should come in. Steve Lee and crew have done a bangup job working on DSC 3.0, including taking feedback from folks to leverage Azure Bicep language for configuration. Security Policy Challenge The way to access security policies need to change. Even if I were to take DSC 3.0 I'd end up having to create a similar security policy INF file to import into Windows. It just seems so silly to me to have to write all of that out when Windows really should just provide an interface for doing this. In fact, security policy remains to be one of the largest problems to getting a good platform stood up. Windows Firewall Policy and GPO - The reason why host-based firewalling is painful to manage at scale in a Windows environment. GPO is definitely not the right place to be managing Windows firewall policy at scale. Particularly when you often have a core set of management rules you want to implement and application-specific needs. Making robust changes becomes a challenge since each policy is separate, preventing you from doing things like inheriting rules for higher level policies. While this is an inherent limitation of Group Policy, it highlights the need to get off of GPO as the core policy configuration tool for Windows. My recommendations I'd like for the Windows team to implement DSC 3.0-compatible resources for managing all core functionality of Windows. If you can do it in a GPO, you should be able to do it with Configuration as Code. Please stop relying on the community to make this work. All of this should be first party to the platform itself. Furthermore, I'd like to recommend that Microsoft either work with 3rd party configuration systems (Chef, Ansible, Puppet, Octopus, etc.) OR to also provide a way to hit the ground running. Perhaps something that integrates visually into Windows Admin Center would be nice. Conclusion This is a huge problem in the Windows world and continues to seem to fall on some deaf ears somewhere in the organization. While I no doubt am confident that the engineers on all of these teams very well know these issues and maybe even have discussed fixing them, clearly there's a breakdown somewhere.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....Windows Server 2019 Detaylı Network Yapılandırması (tr-TR)
Windows Server 2019 network yapılandırmanız için faydalı olacak bu makale ile IPv4 yapılandırma temellerini ve yapının nasıl işlediğini sizlerle paylaşacağım. IPv4 network yapısını anlamak, IPv4 ağlarını kullanabilmenizi, sorun giderebilmenizi ve bakımını yapabilmenizi sağlamak için önemlidir. IPv4'ün önemli bileşenlerinden biri adreslemedir. Adreslemeyi, alt ağ maskelerini (subnet mask) ve varsayılan ağ geçitlerini (gateway) anlayarak, bilgisayarlar yada sunucular arasında uygun iletişimi tanımlayabilirsiniz. IPv4 network hatalarını tanımlamak için, iletişim sürecinin nasıl çalışması için tasarlandığını anlamanız gerekir. • IPv4 yapılandırması • IPv4 subnet • Private, public ve APIPA IPv4 adresleri • IPv4 notasyonu IPv4 ayarlarına genel bakış Ağ bağlantısını yapılandırmak için IPv4 adreslerini ve nasıl çalıştıklarını bilmeniz gerekir. Bir bilgisayar için ağ iletişimi, o bilgisayarın IPv4 adresine yönlendirilir. Bu nedenle, ağa bağlı her bilgisayara benzersiz bir IPv4 adresi atanmalıdır. Her IPv4 adresi, 32 bit uzunluğundadır, burada bit, ikili matematikteki en küçük ölçüm birimidir, ya 1 ya da 0 ile temsil edilir. IP adreslerini daha okunaklı hale getirmek için noktalı ondalık gösterimlerde görüntülenir. Noktalı ondalık gösterim, 32-bit IPv4 adresini sıfır ve 255 arasında bir ondalık sayıya dönüştürülen 8 bitlik dört gruba böler. Bir ondalık sayı, ondalık sayıyı ayırır. Her ondalık sayı, sekizli olarak adlandırılır. Örneğin, 32 bitlik 10101100.00010000.0000000000.00001010 adresinin okunması zor olabilir. Bu IP adresi, noktalı ondalık biçiminde: 172.16.0.10 olarak temsil edilir. Noktalı bir ondalık gösterimin ikili sayılarla ilişkisi IP adreslerini atadığınızda noktalı bir ondalık gösterimi kullanırsınız. Noktalı ondalık gösterimler, ondalık sayı sistemine dayanır. Ancak, arka planda, bilgisayarlar IP adreslerini ikili biçimde kullanırlar. Karmaşık ağlar için bir IPv4 adresleme düzenini doğru bir şekilde tasarlamak için, IP adreslerini ikili olarak anlamalısınız. 8 bitlik bir sekizli içerisinde, her bit konumu ondalık bir değere sahiptir. 0 olarak ayarlanan bir bit her zaman sıfır değerine sahiptir. 1 olarak ayarlanan bir bit, ondalık bir değere dönüştürülebilir. Düşük sıra bit, sekizlikteki en sağdaki bit ve 1 değerinin ondalık değerini temsil eder. Yüksek sıra bit, sekizlikteki en soldaki bit ve bunu temsil eder. 128 değerinde bir ondalık değer varsa. Bir sekizlikteki tüm bitler 1 olarak ayarlanırsa, sekizlinin ondalık değeri 255'tir, yani: 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1. 255 olası en yüksek değerdir. Binary Bit values Decimal value 10000111 128+0+0+0+0+0+4+2+1 135 01101010 0+64+32+0+8+0+2+1 106 00000011 0+0+0+0+0+0+2+1 3 00011000 0+0+0+16+8+0+0+0 24 Örnek olarak İlk binary değerimizi birlikte inceleyelim Bit values değerini nasıl çıkardığımıza bakalım. 1 0 0 0 0 1 1 1 27 26 25 24 23 22 21 20 27 = 128 - > 128 x 1 = 128 26 = 64 - > 64 x 0 = 0 25 = 32 - > 32 x 0 = 0 24 = 16 - > 16 x 0 = 0 23 = 8 - > 8 x 0 = 0 22= 4 - > 4 x 1 = 4 21= 2 - > 2 x 1 = 2 20= 2 - > 1 x 1 = 1 128 + 0 + 0 + 0 + 0 + 4 + 2 + 1 = 135 şeklinde hesaplamış olursunuz. 10000111 01101010 00000011 00011000 -> 135.106.3.24 Alt ağ maskesi Her IPv4 adresi network ID ve host ID den oluşur. Network ID , bilgisayarın bulunduğu ağı tanımlar. Hot ID, belirli bir ağdaki bilgisayarı benzersiz ( uniquely) olarak tanımlar. Subnet mask, bir IPv4 adresinin hangi bölümünün network ID ve hangi bölümün host ID olduğunu belirler. Subnet maskda ki, her sekizli 255 veya 0'dır. 255, network ID nin bir parçası olan bir sekizliyi temsil ederken, 0, host ID parçası olan bir sekizliyi temsil eder. Örneğin, 172.16.0.10 IP adresine ve 255.255.0.0 subnet mask sahip bir bilgisayar, 172.16.0.0 network ID ve 0.0.0.10 host IDye sahiptir. Örneğin, 255.255.0.0 alt ağ maskesine sahip olan 172.16.0.0 ağı 172.16.0.0/16 olarak sunulabilir. / 16, alt ağ maskesi ikili biçimde temsil edildiğinde 1 değeri olan 16 bit'i temsil eder: 11111111.11111111.00000000.00000000. Aşağıdaki tabloda, varsayılan alt ağ maskeleri ve bunların ağ öneki notasyonu gösterilmektedir. Address class Bits for subnet mask Network prefix Class A 255.0.0.0 11111111 00000000 00000000 00000000 /8 Class B 255.255.0.0 11111111 11111111 00000000 00000000 /16 Class C 255.255.255.0 11111111 11111111 11111111 00000000 /24 Gateway, TCP / IP ağındaki IP paketlerini diğer ağlara ileten genellikle yönlendirici olan bir aygıttır. Bir organizasyondaki çoklu iç ağlar intranet olarak adlandırılabilir. Bir intranette, herhangi bir ağın, hem yerel hem de uzaktaki diğer ağlara bağlanan birkaç yönlendiricisi olabilir. Yönlendiricilerden birini yerel ana bilgisayarlar için varsayılan gateway olarak yapılandırmanız gerekir. Bu, yerel ana bilgisayarların uzak ağlardaki ana bilgisayarlarla iletişim kurmasını sağlar. Bir ana bilgisayar bir IPv4 paketi göndermeden önce, hedef ana bilgisayarın aynı ağda mı yoksa uzak bir ağda mı olduğunu belirlemek için kendi subnetmaskını kullanır. Hedef ana bilgisayar aynı ağdaysa, gönderen ana bilgisayar paketi doğrudan hedef ana bilgisayara iletir. Hedef ana bilgisayar farklı bir ağdaysa, ana bilgisayar paketi göndermek için bir yönlendiriciye iletir. Bir ana bilgisayar bir paketi bir uzak ağa ilettiğinde, IPv4 paketin hedef alt ağa ulaşması için uygun yönlendirici belirlemek üzere iç route tablena başvurur. Route table, hedef alt ağ hakkında yönlendirme bilgisi içermiyorsa, IPv4 paketi varsayılan ağ geçidine iletir. Ana bilgisayar, varsayılan ağ geçidinin gerekli yönlendirme bilgilerini içerdiğini varsayar. Varsayılan gateway çoğu durumda kullanılır. İstemci bilgisayarlar genellikle IP adres bilgilerini Dinamik Ana Bilgisayar Yapılandırma Protokolü (DHCP) sunucusundan alır. Bu, her ana bilgisayara manuel olarak varsayılan bir ağ geçidi atamaktan daha basittir. Çoğu sunucu, manuel olarak atanmış statik bir IP yapılandırmasına sahiptir. Not: Sunucuların statik IP üzerinde olması erişim kolaylığı ve bilinirliğinin yanı sıra stabil olması için önemli bir etkendir. Sunucular üzerinde kullandığınız statik IPv4 yapılandırması DHCP üzerinden yeni atanacak bir IP durumunda sunucunun IP adresinin değişmesinden dolayı uygulama yada role servislerinizin sürekliliğinde erişim sıkıntıları yaratabilir. IPv4 adres sınıfları IANA organizasyonu tarafından sınıflar halinde düzenler. Her adres sınıfında, ağdaki geçerli ana bilgisayarların sayısını tanımlayan farklı bir varsayılan subnet mask bulunur. IANA, Sınıf A'dan Sınıf E'ye kadar olan IPv4 adres sınıflarını adlandırmıştır. Sınıf A, B ve C, ana bilgisayarlardaki IP adreslerine atayabileceğiniz IP ağlarıdır. Bilgisayarlar ve programlar, çok noktaya yayın için D Sınıfı adresleri kullanır. IANA, deneysel kullanım için E Sınıfını sunmaktadır. A, B veya C sınıfı kullanan bir adresleme işlemine klasik adresleme adı verilir. Class First octet Default subnet mask Number of networks Number of hosts per network A 1-127 255.0.0.0 126 16,777,214 B 128-191 255.255.0.0 16,384 65,534 C 192-223 255.255.255.0 2,097,152 254 Basit IPv4 networklarında, subnet mask, tam sekizlileri network ID ve host IDnin bir parçası olarak tanımlar. 255, ağ kimliğinin bir parçası olan bir sekizliyi temsil eder ve 0, ana bilgisayar kimliğinin bir parçası olan bir sekizliyi temsil eder. Örneğin, 256 küçük ağ oluşturmak için 10.0.0.0 ağını 255.255.0.0 alt ağ maskesiyle kullanabilirsiniz. Karmaşık networklarda, subnet mask 255 ve 0'ın basit birleşimleri olmayabilir. Aksine, bir oktet'i, ağ kimliği için olan bazı bitlerle, bazıları da ana bilgisayar kimliği için olan alt bölümlere ayırabilirsiniz. Bu, gereksinim duyduğunuz belirli sayıda alt ağ ve ana bilgisayara sahip olmanızı sağlar. 172.16.0.0 alt ağ maskesi 255.255.240.0 ile, bir B Sınıfı ağı 16 alt ağa bölmek için kullanılabilen bir alt ağ maskesi örneğidir. Modern yönlendiriciler, daha büyük bir ağı böldüğünüzde farklı boyutlarda alt ağlar oluşturmanıza izin veren değişken uzunluklu subnet masklar kullanımını destekler. Örneğin, 256 adresli küçük bir ağı 128 adres, 64 adres ve 64 adresden oluşan üç küçük ağa bölebilirsiniz. Bu, bir ağda IP adreslerini daha verimli kullanmanıza olanak sağlar. Public, private, ve APIPA Doğrudan İnternete bağlanan cihazlar ve hostlar public bir IPv4 adresi gerektirir. Doğrudan İnternete bağlanmayan host ve cihazlar, Public bir IPv4 adresi gerektirmez. Public IPv4 adresleri benzersiz olmalıdır. IANA, halka açık IPv4 adreslerini bölgesel İnternet kayıt defterlerine (RIR) atar ve ardından IPv4 adreslerini İnternet servis sağlayıcılarına (ISS'ler) atar. Genellikle ISS'niz size adres havuzundan bir veya daha fazla genel adres tahsis eder. ISS'nizin size tahsis ettiği adres sayısı, İnternete bağladığınız kaç cihaz ve ana bilgisayara bağlıdır. İnternete bağlanması gereken bilgisayarlar ve cihazlar Public IP adresleriyle yapılandırılmalıdır. Ancak, halka açık IPv4 adreslerinin sayısı sınırlanıyor. Kuruluşlar her şirket bilgisayarı için genel IPv4 adresi alamadığından, bunun yerine Private IP adreslemesi kullanırlar. Özel IP adresleri Internet üzerinden yönlendirilemediğinden, Private bir IP adresi ile yapılandırılan bilgisayarlar doğrudan İnternet'e erişemez. Ağ adresi çevirisi (NAT) gibi teknolojiler, yöneticilerin göreceli olarak daha az sayıda halka açık IPv4 adresi kullanmasını sağlar ve aynı zamanda, yerel ana bilgisayarları Internet üzerindeki uzak ana bilgisayarlara ve hizmetlere bağlanmak için özel IP adresleri ile etkinleştirir. Genellikle, Windows işletim sistemini çalıştıran bir bilgisayar (veya istemci) başlatıldığında, içinden bir IP Adresi alacak bir DHCP sunucusu bulmak için bir yayın gönderir. Ancak, Windows istemcisi bir DHCP sunucusu bulamıyorsa, Microsoft tarafından ayrılan bir aralıktan kendisine bir APIPA adresi atayabilir. APIPA IP adres aralığı 169.254.0.1 ila 169.254.255.254 arasındadır. Bir Windows istemcisi kendisine bir APIPA adresi atadığında, kendisini 255.255.0.0 varsayılan B Sınıfı alt ağ maskesiyle de yapılandırır. APIPA adresi kullanan bir Windows istemcisi, kendisine varsayılan bir ağ geçidi atamaz. Bir müşteri, bir DHCP sunucusu mevcut olana kadar her 5 dakikada bir DHCP sunucusu için yayın yapan APIPA adresini kullanmaya devam edecektir. Windows Server 2019 IPv4 ayarlarını yapılandırmak için, Network and Sharing Center Internet Protokolü Sürüm 4 (TCP / IPv4) Özellikleri iletişim kutusunu, sconfig, netsh veya Windows PowerShell'i kullanarak IPv4 yapılandırmasını yapabilirsiniz. Windows Server 2019 GUI kullananlar için Control Panel\Network and Internet\Network Connections dizininden ilgili network adapterinizi seçip Ethernet properties penceresinde "Internet Protocol Version 4 (TCP/IPv4) seçip properties butonuna basarak ilgili IP adres, subnet mask gateway ve dns ayarlarınızı girerek tamamlayabilirsiniz. CMD komut satırı penceresinde network yapılandırmanızı yapmak için netsh komut bütününü kullanabilirsiniz. <Netsh interface ipv4 set address name="Local Area Connection" source=static addr=192.168.2.35 mask=255.255.255.0 gateway=192.168.2.1> <Netsh interface ipv4 set dns name="Local Area Connection" source=static addr=8.8.8.8> PowerShell ile network yapılandırmanızı yapmak için <New-NetIPAddress –InterfaceAlias "Local Area Connection" –IPAddress 192.168.2.34 PrefixLength 24 –DefaultGateway 192.168.2.1 > <Set-DNSClientServerAddress –InterfaceAlias "Local Area Connection" -ServerAddresses 8.8.8.8,8.8.4.4>
RDP gateway session disconnects on single packet loss
Good Morning, I'm trying to troubleshoot an issue with one of my remote clients losing their RDP session through a gateway server after a single packet drops. I can run a constant ping to their firewall and see when the packet drops, which causes the disconnect. The ms response times average about 34 and the drops don't seem to be occurring in high ms situations. I've been looking for support articles to increase the threshold of that timeout but can't seem to find anything relevant to an RDS Gateway session in conjunction with windows 10 and 2012R2 beyond high ms tolerance. Non-gateway connections will attempt to reestablish session for around 60 seconds before timing out. Any connections through the gateway will immediately drop session and require a new connection. The client pc I'm working with is a Windows 10 setup utilizing a site-to-site connection between a Meraki and a Fortigate. They are still using the older rdp protocol instead of the newer client on Windows 10. Any thoughts or ideas would be great. Thanks much!
External private IP addresses registering with DNS server
Hello all, I've been trying to fine-tune our NIDS configuration (which predates my employment here) and more specifically trying to figure out why certain IP addresses/ranges that we don't use, keep appearing in reports/logs. I think I've figured out the root cause, but I'm not sure of the best way to fix it: We have a number of remote users who connect to our network by VPN. As best I can tell, when their laptops connect to the network, they're sending updates to the DNS server running on the DC with both the IP address of their VPN interface (routable on our network) and their private IP address on their home LAN (obviously not routable) - if I do an nslookup on a domain machine, the DC returns two A records, one for each address. This has a slight ripple effect through the network - which manifests mostly with Windows Update Delivery Optimization, where the peer discovery process frequently gets the non-routable private IP somehow and then tries to download Windows updates from it. Long story short: what is the best way to prevent VPN'ed machines from registering external private IP addresses with the DNS server running on the DC?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.LBFO Teaming deprecation on Hyper-V for Windows Server 2022 - Solved
While creating a virtual switch using a teamed interface in Hyper-V for Windows Server 2022, the following error is encountered. To resolve this, NIC teaming for Hyper-V needs to be configured via PowerShell. Step 1: Delete the existing teaming manually created. Step 2: Go to PowerShell and run the command: New-VMSwitch -Name "VMSwitch-1" -NetAdapterName "Embedded NIC 1","Embedded NIC 2" (Here, I have given the switch name 'VMSwitch-1' and aggregated it with two adapters—'Embedded NIC 1' and 'Embedded NIC 2' are the adapter names in the list.) Step 3: Check the algorithm of the VMSwitch command: Get-VMSwitchTeam -Name "VMSwitch-1" | FL (This command will display the algorithm. If it's Hyper-V, proceed to the next step; otherwise, you can ignore the last step.) Step 4: Set the load balancing algorithm to dynamic: Set-VMSwitchTeam -Name "VMSwitch-1" -LoadBalancingAlgorithm Dynamic (This command changes the load balancing algorithm to dynamic. Test it using the command in step 3. The teamed interface should now appear in the Hyper-V virtual switch.) This will not help to LACP mode , so If you want LACP, Then only need to do the two step This is my recommend Step 1: 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. Step 2: Then execute the below PowerShell Command to create the virtual switch based on the teaming created . New-VMSwitch -Name "VMSWITCH-1" -NetAdapterName "SR-LAG-1" -AllowNetLbfoTeams $true -AllowManagementOS $true this case name of my hyperv switch given "VMSWITCH-1" and created teaming network adapter name ""SR-LAG-1"" Go to hyper-v and check the VMSwitch That's It.....BLOG: Windows Server / Azure Local keeps setting Live Migration to 1 - here is why
Affected products: Windows Server 2022, Windows Server 2025 Azure Local 21H2, Azure Local 22H2, Azure Local 23H2 Network ATC Dear Community, I have seen numerous reports from customers running Windows Server 2022 servers or Azure Local (Azure Stack HCI) that Live Migration settings are constantly changed to 1 per Hyper-V Host, as mirrored in PowerShell and Hyper-V Host Settings. The customer previously set the value to 4 via PowerShell, so he could prove it was a different value at a certain time. First, I didn't step into intense research why the configuration altered over time, but the stumbled across it, quite accidently, when fetching all parameters of Get-Cluster. According to an article a LCU back in September 2022 changed the default behaviour and allows to specify the live migrations at cluster level. The new live migration default appears to be 1 at cluster level and this forces to change the values on the Hyper-V nodes to 1 accordingly. In contrast to the commandlet documentation, the value is not 2, which would make more sense. Quite unknown, as not documented in the LCU KB5017381 itself, but only referenced in the documentation for the PowerShell commandlet Get-Cluster. Frankly, none of the aren't areas customers nor partners would check quite regularly to spot any of such relevant feature improvements or changes. "Beginning with the 2022-09 Cumulative Update, you can now configure the number of parallel live migrations within a cluster. For more information, see KB5017381 for Windows Server 2022 and KB5017382 for Azure Stack HCI (Azure Local), version 21H2. (Get-Cluster).MaximumParallelMigrations = 2 The example above sets the cluster property MaximumParallelMigrations to a value of 2, limiting the number of live migrations that a cluster node can participate in. Both existing and new cluster nodes inherit this value of 2 because it's a cluster property. Setting the cluster property overrides any values configured using the Set-VMHost command." Network ATC in Azure Local 22H2+ and Windows Server 2025+: When using Network ATC in Windows Server 2025 and Azure Local, it will set the live migration to 1 per default and enforce this across all cluster nodes. Disregarding the Cluster Settings above or Local Hyper-V Settings. To change the number of live migration you can specify a cluster-wide override in Network ATC. Conclusion: The default values for live migration have been changes. The global cluster setting or Network ATC forcing these down to the Hyper-V hosts based on Windows Server 2022+/ Azure Local nodes and ensure consistency. Previously we thought this would happen after using Windows Admin Center (WAC) when opening the WAC cluster settings, but this was not the initial cause. Finding references: Later the day, as my interest grew about this change I found an official announcement. In agreement to another article, on optimizing live migrations, the default value should be 2, but for some reason at most customers, even on fresh installations and clusters, it is set to 1. TLDR: 1. Stop bothering on changing the Livemigration setting manually or PowerShell or DSC / Policy. 2. Today and in future train your muscle memory to change live migration at cluster level with Get-Cluster, or via Network ATC overrides. These will be forced down quite immediately to all nodes and will be automatically corrected if there is any configuration drift on a node. 3. Check and set the live migration value to 2 as per default and follow these recommendations: Optimizing Hyper-V Live Migrations on an Hyperconverged Infrastructure | Microsoft Community Hub Optimizing your Hyper-V hosts | Microsoft Community Hub 4. You can stop blaming WAC or overeager colleagues for changing the LM settings to undesirable values over and over. Starting with Windows Admin Center (WAC) 2306, you can set the Live Migration Settings at cluster level in Cluster > Settings. Happy Clustering! 😀
Windows not telling, which AD User locked the document
we have windows 2012 Domain Controllers with windows 10 clients computers in our AD environment Due to Pandemic most of our Users are logging in from home via VPN when a user try to open a document (from Windows 2008 R2 file share server) which is already opened by another user. Windows prompts a message. "word/excel document is locked for editing by a Windows user. do you want to open read only". Does anyone know why its not giving the name of AD User ?
