By continuing to use the site or forum, you agree to the use of cookies, find out more by reading our GDPR policy

Today we are excited to release a new build of the Windows Server vNext Long-Term Servicing Channel (LTSC) release that contains both the Desktop Experience and Server Core installation options for Datacenter and Standard editions. There are some features to look for such as UDP performance improvements — UDP is becoming a very popular protocol carrying more and more networking traffic. With the QUIC protocol built on top of UDP and the increasing popularity of RTP and custom (UDP) streaming and gaming protocols, it is time to bring the performance of UDP to a level on par with TCP. In Server vNext we include the game-changing UDP Segmentation Offload (USO). USO moves most of the work required to send UDP packets from the CPU to the NIC’s specialized hardware. Complimenting USO in Server vNext we include UDP Receive Side Coalescing (UDP RSC) which coalesces packets and reduces CPU usage for UDP processing. To go along with these two new enhancements, we have made hundreds of improvements to the UDP data path both transmit and receive. TCP performance improvements — Server vNext uses TCP HyStart++ to reduce packet loss during connection startup (especially in high-speed networks) and SendTracker + RACK to reduce Retransmit TimeOuts (RTO). These features are enabled in the transport stack by default and provide a smoother network data flow with better performance at high speeds. PktMon support in TCPIP — The cross-component network diagnostics tool for Windows now has TCPIP support providing visibility into the networking stack. PktMon can be used for packet capture, packet drop detection, packet filtering, and counting for virtualization scenarios, like container networking and SDN. You're also likely to see Improved RSC in the vSwitch. RSC in the vSwitch has been improved for better performance. First released in Windows Server 2019, Receive Segment Coalescing (RSC) in the vSwitch enables packets to be coalesced and processed as one larger segment upon entry in the virtual switch. This greatly reduces the CPU cycles consumed processing each byte (Cycles/byte). However, in its original form, once traffic exited the virtual switch, it would be re-segmented for travel across the VMBus. In Windows Server vNext, segments will remain coalesced across the entire data path until processed by the intended application. Now you can keep things together or apart. When moving a role, the affinity object ensures that it can be moved. The object also looks for other objects and verifies those as well, including disks, so you can have storage affinity with virtual machines (or Roles) and Cluster Shared Volumes (storage affinity) if desired. You can add roles to multiples such as Domain controllers, for example. You can set an AntiAffinity rule so that the DCS remains in a different fault domain. You can then set an affinity rule for each of the DCS to their specific CSV drive so they can stay together. If you have SQL Server VMs that need to be on each side with a specific DC, you can set an Affinity Rule of the same fault domain between each SQL and their respective DC. Because it is now a cluster object, if you were to try and move a SQL VM from one site to another, it checks all cluster objects associated with it. It seems there is a pairing with the DC in the same site. It then sees that DC has a rule and verifies it. It seems that DC cannot be in the same fault domain as the other DC, so the move is disallowed. BitLocker has been available for Failover Clustering for quite some time. The requirement was the cluster nodes must be all in the same domain as the BitLocker key is tied to the Cluster Name Object (CNO). However, for those clusters at the edge, workgroup clusters, and multidomain clusters, Active Directory may not be present. With no Active Directory, there is no CNO. These cluster scenarios had no data-at-rest security. Starting with this Windows Server Insiders, we introduced our own BitLocker key stored locally (encrypted) for the cluster to use. This additional key will only be created when the clustered drives are BitLocker protected after cluster creation. Complete details are posted on OUR FORUM.