In-Place Upgrade auf Windows Server vNext 2004

Ein 13-teiliger und atemberaubender Bildband zum In-Place Upgrade auf Windows Server vNext 2004 (Build 20201) ausgehend von Windows Server 2019 (1809 Build 17763):

Wird man nach dem In-Place Upgrade nicht zufällig von einer nicht funktionierenden Netzwerkkarte (Intel® Ethernet Connection I218-V) im Intel NUC5i3RYH überrascht, kann man sich direkt per RDP verbinden und sich der getanen Arbeit erfreuen:

Und jetzt? Die für mich interessantesten zwei Neuerungen konnte ich in zwei verschiedenen Blogs bei Microsoft ausfindig machen:

1. Eine (sehr stark verbesserte) Affinität / Anti-Affinität für virtuelle Maschinen im Failover Cluster!
2. Transport Layer Security 1.3 (TLS 1.3)!

Aus „Announcing Windows Server vNext Preview Build 20201“:

In the past, we have relied on the group property AntiAffinityClassNames to keep roles apart, but there was no site-specific awareness. If there was a DC that needed to be in one site and a DC that needs to be in another site, it wasn’t guaranteed. It was also important to remember to type the correct AntiAffinityClassNames string for each role.

There are these PowerShell cmdlets:

New-ClusterAffinityRule = This allows you to create a new Affinity or AntiAffinityrule. There are four different rule types (-RuleType)
DifferentFaultDomain = keep the groups on different fault domains
DifferentNode = keep the groups on different nodes (note could be on different or same fault domain)
SameFaultDomain = keep the groups on the same fault domain
SameNode = keep the groups on the same node
Set-ClusterAffinityRule = This allows you to enable (default) or disable a rule
Add-ClusterGroupToAffinityRule = Add a group to an existing rule
Get-ClusterAffinityRule = Display all or specific rules
Add-ClusterSharedVolumeToAffinityRule = This is for storage Affinity/AntiAffinity where Cluster Shared Volumes can be added to current rules
Remove-ClusterAffinityRule = Removes a specific rule
Remove-ClusterGroupFromAffinityRule = Removes a group from a specific rule
Remove-ClusterSharedVolumeFromAffinityRule = Removes a specific Cluster Shared Volume from a specific rule
Move-ClusterGroup -IgnoreAffinityRule = This is not a new cmdlet but does allow you to forcibly move a group to a node or fault domain that otherwise would be prevented. In PowerShell, Cluster Manager, and Windows Admin Center, it would show that the group is in violation as reminder.

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 remain 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 site with a specific DC, you can set an Affinity Rule of 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 sees there is a pairing with the DC in the same site. It then sees that the DC has a rule and verifies it. It sees that the DC cannot be in the same fault domain as the other DC, so the move is disallowed.

There are built-in overrides so that you can force a move when necessary. You can also easily disable/enable rules if desired, as compared to AntiAffinityClassNames with ClusterEnforcedAffinity where you had to remove the property to get it to move and come up. We also have added functionality in Drain where if it must move to another domain and there is an AntiAffinity rule preventing it, we will bypass the rule. Any rule violations are exposed in both Cluster Admin as well as Windows Admin Center for your review.

https://blogs.windows.com/windows-insider/2020/08/26/announcing-windows-server-vnext-preview-build-20201/

Aus „Taking Transport Layer Security (TLS) to the next level with TLS 1.3“:

Transport Layer Security (TLS) 1.3 is now enabled by default on Windows 10 Insider Preview builds, starting with Build 20170, the first step in a broader rollout to Windows 10 systems. TLS 1.3 is the latest version of the internet’s most deployed security protocol, which encrypts data to provide a secure communication channel between two endpoints. TLS 1.3 eliminates obsolete cryptographic algorithms, enhances security over older versions, and aims to encrypt as much of the handshake as possible.

https://www.microsoft.com/security/blog/2020/08/20/taking-transport-layer-security-tls-to-the-next-level-with-tls-1-3/