 Welcome to What's New in Windows Server 2025 Failover Clustering. My name is Rob Heinman. I'm a program manager in Windows Server. For the agenda today, we'll be covering what is failover clustering, the feature parody that we're achieving in 2025, cluster OS rolling upgrade, workgroup cluster, VM live migration, GPUP, VM live migration, ExcelNet for highly available VMs, campus clusters, then finally our call to action. What is failover clustering? Failover clustering is a technique that you can use to achieve high availability for almost any application or service running on Windows Server. So a failover cluster is just a collection of Windows Server machines running the failover clustering feature and configured with the correct workload, identity, compute, storage and networking to provide high availability for your applications. So in the case of VMs, a failover cluster will automatically fail over a VM from one host to another host for you. The great thing about failover clustering is you can achieve this high availability at the same time as achieving a zero data loss and zero data corruption. Failover clustering maintains your state while avoiding data loss or corruption. In server 2025, we are bringing a lot of features that a lot of our customers really like that are in the Azure Stack HCI. We're bringing them to Windows Server 2025. So the first of those is the feature update from Windows Update. So you'll be able to upgrade from Windows Server 2022 failover clusters to a Windows Server 2025 failover cluster using cow's rolling upgrade plugin. We're also bringing single node support to you as well as stretch clustering across two sites. Network ATC and network HUD are also coming to Windows Server 2025. So the first feature here is notable and important. So of course you can upgrade your failover cluster without any downtime. We're excited because you can use clusterware updates rolling upgrade plugin to seamlessly upgrade your cluster with just a single line of code or a single line of PowerShell that will allow you, enable you to upgrade your cluster. I'd like to talk about workgroup cluster VM live migration. So we've supported workgroup clusters for a long time, but they didn't work with VM live migration. So a lot of customers said, hey, wouldn't it be great if we could lower the amount of infrastructure that we need for a workgroup cluster and still achieve VM live migration? And now we can bring that to you. So you can use local, without Active Directory, you use local accounts on each node of the cluster to configure the cluster. And then the cluster will use self-signing PKU2U certificates to achieve all of the authentication needed to move your VM from one host node to another host node without Kerberos. So this is really, we're really happy with this. It's relatively easy to build a workgroup cluster. So I built a workgroup cluster, the one I'm going to show you in the demo in a moment, it was very easy to build. And it's with the, you can see the syntax, pretty much the same syntax that you'd always use to build a failover cluster. So pretty much as easy as configuring the host systems in the new cluster, you can see I'm going to build a S2D cluster. So I'm using enable cluster S2D, and then we'll create the VMs and get them, you know, watch a live migration. So let's go ahead and do that now. So here in this, we look at this cluster. This is the cluster that I just built. So in here you can see it's a humble little two node cluster with no active directory controller in here. So this is a workgroup cluster. It's actually an S2D cluster as well. And so you can see here that I've got my virtual disk and I've got a single VM running, and it's running on that virtual disk. What I'm going to do is I'm going to move that VM from machine 15 to machine 13. What I want to emphasize here in this demo, however, is that the way that you connect to the VM is the important part. So I very intentionally made sure that the Hyper-V, I've set this up so that I'm connected to the VM in two different ways here. So I have the VM connection manager, the Hyper-V manager connection on the lower part, and you can see that it just disconnected as soon as the machine was successfully moved to the other host. But the remote desktop connection remained running, and that's the important point that I want to emphasize. So while VM live migration works great on a workgroup cluster, we always have to be very careful about the credentials we're using in the connection method that we're using to access the VM. Okay, there we go. So the virtual machine is back on this host I'm connected to, and here we have the Hyper-V manager connection. It works fine. So the moral of the story here is just be careful with your credentials when you're working with a workgroup cluster. So next, I'd like to talk about GPUP VM live migration for graphics and AI ML workloads. So this, we're very excited about bringing this particular technique to customers in Windows Server 2025. There's a lot of interest in both the graphics rendering workloads and also the AI ML workloads, which leverage the GPU cards. So this is a technique. GPUP is a technique that can be used to basically take the GPUs and divide them up, basically use them with multiple VMs. So here in this example, I have two Hyper-V host machines with GPU cards in them. Since I have two VMs that use GPUs, what I'm going to do is I'm going to create two GPU partitions on each host machine. So that's a total of four GPUP partitions on these machines. And then you'll see the VMs will be able to achieve live migration without any issues. So let's go ahead and watch this happening in a demo system. All right, so here on this demo system, this is a normal two-node cluster that is built using fairly nice host machines that are using the AMD Epic CPUs. So what we're going to do is I just want to show you that we have, this is actually a fully loaded host, which is running about 20 VMs. Two of these VMs are using the GPU partitions. So let's connect up to those VMs. Again, I'm just going to use the Hyper-V connection manager. What we're demonstrating here in this case is that, and remember, these are fully loaded hosts, right? Hosts that are busy running a lot of other VMs. So what we're going to do is we're going to migrate both of the VMs over from host machine 1 to host machine 3. And the punchline here is that the VMs are not interrupted at all. So let's go ahead and zip through this. If we zip through the video to about this point, I want to show you here there's a little bit of flicker during the blackout period where the VM connection will flicker, but the VM itself keeps running. And so the state of the application is maintained. So if this was a very expensive, computationally expensive AI training model, then the great thing is that you would not lose the state. You wouldn't have to start over again. You could move that VM, and it would maintain its state as it moved from one host to the other host. So there it goes. So you saw the flicker there. So that's the punchline. So on a fully loaded host machine, or two fully loaded host machines, we were able to demonstrate VM live migration of two VMs. And you saw that the workload was continuously running throughout that time. All right. OK, next. I'd like to talk about ExcelNet for highly available VMs. So ExcelNet is very popular in Azure. And we're bringing this technique to our on-premises customers. So you can use this technique for your on-premises VMs that have very high network requirements because this reduces the processing burden on the host machines. And it allows you to do just much faster networking because of the bypass. So basically, you can just directly use, from the virtual NIC, you can directly use the capabilities of the physical NIC through SRIOV. And therefore, you can essentially use more of the physical NIC capabilities for those VMs. Next, I want to talk about campus clusters. So in Windows Server 2025, we'll be supporting S2D campus clusters. A campus cluster is a cluster where the nodes of the cluster are separated into two different racks. Often, this is implemented in factories where the racks are in two different rooms. So we're using S2D replication to keep the state of all the applications running in the cluster consistent. So we are implementing campus cluster in two phases. So we have the existing S2D resiliency, the resiliency that we have today, which is we can achieve four copies on a two-node system with a nested mirror, or we can achieve three copies of data on a two-node system. In Windows Server 2025, we hope to add a four-way mirror so that you can also achieve four copies split between the two racks, so specifically so that you can achieve four copies on a four-node system with one copy landing on each node of the four-node cluster. OK, now finally, in our call to action, we would love to have your feedback on the features that we're bringing to you in Windows Server 2025. So we're bringing some features over from HCI. That's feature update, single-node clusters, and S2D stretch clusters. We're also bringing cluster OS rolling upgrade to Windows Server 2025 using Cal. So you should be able to seamlessly upgrade to Windows Server 2025 clusters without any downtime. We're bringing work group cluster support, or VM live migration, and we're bringing VM live migration to clusters that use GPUP. We're bringing ExcelNet VMs to Windows Server 2025, and also we're bringing campus clusters. So I'd like to encourage you to use these features to try them out in Windows Server 2025, and let me know, let us know what your feedback is on these features. We'd really like to know. So that's all I have for you. So thank you very much. Hi, I'm Demetrius Neelan, and I am the product manager for WinGit, and today I'm going to show you what's happened recently with Windows Server. I've got a VM that I've provisioned in Hyper-V. This is the current public preview, and I've just connected in and launched up terminal. So let's see what this looks like. It's kind of my first time playing with the public bits here. So I'll minimize the Hyper-V from my local machine. We're in terminal. I'm gonna go ahead and make that my default since that's my favorite. We'll get back in. Let's see what version of WinGit is already installed here, and it looks like it's 1.6. There's an upgrade. I'm curious if there's any other upgrades. Definitely gotta fix my rainbow progress bar there. All right, looks like there's an update to WinGit, which is delivered in the app installer. Looks like there's an update for Windows Terminal and VC Libs. I'll go ahead and just kick those off. And while that's running, basically, the Windows Package Manager on Windows Desktop goes down to Windows 10 RS5, and we're shipping inbox with Windows 11 and going through a lot of the challenges of kind of bootstrapping things. And the most popular command out there is this WinGit upgrade all command. It's essentially just gonna look at everything that it can find connected to one of the default sources. The two default sources today are the community repository that's open source at GitHub, as well as the Microsoft Store source. So by default, with no policies enabled, you should be able to have access to everything in the community repository and everything in the Microsoft Store. I will note on that upgrade that just finished for the app installer that includes WinGit, it's mentioning that there's a restart to complete the upgrade. That will actually happen whenever this is all complete. The 95% progress bar there is just a bit of an anomaly. It's distributed as an MSIX package, which means it's being laid down. But until we start it again, we won't see that latest version. But since it's a CLI experience, as soon as this is completed, I'll run the version again. And we should see the latest 1.7 version being present. Now it's actually upgrading terminal. Since I'm running in terminal, this might cause a restart or force me to reset the terminal. That's not unexpected when you're upgrading a package while you're using it. So it's got the same thing there. It's just gonna want me to restart. So I'll go ahead and restart it real quick. And we'll run the version. We're at 1.6 earlier. Now you can see we're on 1.7 and everything is up to date. If you run WinGet by itself, you'll see a list of all of the default commands and arguments, everything is documented at Microsoft Learn. But it's a package manager. So the first thing I mentioned was the settings. So I'm gonna run WinGet settings to edit my settings file. Oh, and I don't have an IDE on here. Let's get Visual Studio Code. VS Code is the moniker for Visual Studio Code. So that's going to do a search. And since there's only one exact match for that, it'll go ahead and install Visual Studio Code. I'm doing this just so that I can get the nice IntelliSense and tool tips. While that's running, I'm gonna go and bring up my local settings on my local box. So here's when PowerShell on my local and it'll default to the Visual Studio Code on my local and I'll grab my settings file just to get that progress bar. While that's installing, I'll talk a little bit about the work we've been doing recently with configuration management. One of the big challenges with Windows, especially when we talk to developers and in many cases IT professionals as well, is they're very interested in doing infrastructure as code or configuration as code. And what we've done with WinGet is we've partnered with the PowerShell team and we're leveraging PowerShell's desired state configuration. This is the same kind of technology that's been around on Windows Server since about 2013. But the big subtle difference here is we're using WinGet as the orchestrator. So you don't have the local configuration manager constantly reapplying the configuration and doing what it would do only in that server mode. In this case, primarily targeted at developers, you have the ability to run the configurations on demand. And if these configurations are checked into open source repositories, GitHub, or other places, this can really help bootstrap some of these scenarios. And I've got a link from one of them that I'll go ahead and share in the browser now. This is just a sample that we have at the Dev Home Repository, which is another developer tool. And by looking at this configuration file, I can see that it's going to turn on developer mode. It's going to use WinGet to install Python 3.12. It's gonna install GitHub desktop, and it's going to install Visual Studio Code. Since I'm manually installing Visual Studio Code right now, that should essentially just be a no op when I run that configuration. And we get back and currently we're downloading the installer for Visual Studio Code. That's pretty much what WinGet does. We have all of the manifests at the community repository, and they're all open source. So you can install anything from that repository and you can go contribute packages. And it's the WinGet packages repository where we have all of these. We've recently made some updates to the README to help optimize for authoring manifests, testing them, submitting them, or just filing issues to request them. And they're structured in this directory under manifest. We use the first letter of the publisher name so I can pick on M for Microsoft. I'm gonna go down and find Microsoft, and then we'll go look for PowerShell. I'm gonna go ahead and put PowerShell 7 on server. And you can see several different versions are available. We keep a pretty long history of these if that's what the publisher wants. And the WinGet show command will allow you to do that. Give me just a moment here. Sorry about that. One of the requirements for the community is that packages install without user interaction. So even though you're seeing a UI, you won't have to interact with it. I could have passed dash dash silent or dash S to get a silent install. So now that I've got VS code, I'm gonna do WinGet settings again on the server so that I can get my rainbow progress bar. And now that we've got that set up, I will do an install of PowerShell. Shouldn't be case sensitive but kind of out of habit. I go ahead and fix those things. So now you can see I've got my rainbow progress bar and we're installing PowerShell 7 on this Windows server. And right after that is done, I will kick off that configuration that I shared earlier. One of the new features that we just recently added in 1.7 is the ability to install a configuration by passing in a URL. I know on a lot of the IT Pro side of things, this is probably something you don't want to enable. And we do have group policy to manage and control how WinGet is operated. And that allows you to control whether or not the CLI is available to users. The PowerShell modules will also follow those same policies. But if you're using Intune or if you're integrating directly with the COM APIs provided in WinGet, you'll be able to have that kind of integration and still you can prevent the users from having the CLI experience. So it's kind of best of both worlds but we've gotten a lot of feedback from folks looking at Windows server, both for development and for enterprise management that are really interested in being able to leverage the benefits of the community repository or even standing up your own private REST source, which is something that we also have open source at the REST source repository. And I'll bring that one up for you. It's at WinGet CLI REST source. This will allow you to deploy an instance of a WinGet REST source on Azure, which means you can manage your own packages. You would simply go in and add that source to the WinGet client or you can do that through group policy so that you can have your private applications or your line of business applications or if you just wanna prune down and select the ones that you want to have for your enterprise users, you can do that. Now we've got PowerShell 7 installed. I'm gonna switch over to that one. I'm gonna restart terminal and now I've got PowerShell 7. So we're gonna try this configuration that I have. I'm gonna copy and paste that URL. So this is going to download that configuration file. It's going to evaluate that YAML file looking for any of the PowerShell modules containing the resources that are specified. It will download those. I get this warning because of the nature and the power of configurations. You shouldn't run them if you don't know what they're doing as well as the resources themselves. I'm gonna go ahead and accept here. And what it's doing now is it's gonna enable the developer mode for this. It's going to install Python. And like we said before, since I've already got this code on the device, it should go ahead and skip that. And in theory, when this is done, I'll be able to do work on a Python project. While that's running, I'll also talk a little bit more about the future that we're working on with PowerShell's desired state configuration. We're looking at a V3 of this. And the main difference in V3 is we won't have this dependency on these PowerShell DSE resources that are class-based objects written in C sharp. The idea is that you'll be able to have these built in any language and you'll be able to expose those configuration APIs directly in your application, which is just another simplification of the orchestration here. So you won't need to download those external modules. The applications themselves will provide those configuration APIs, which means you can integrate directly with them yourself or they'll simply run faster with a Wengit configuration. All right, you can see GitHub desktop was installed with a shortcut on the desktop. And you can see Visual Studio Code was already installed. So it looks like my configuration was a complete success. This first time running on Windows Server. And I wanted to take a moment to thank everybody for watching the presentation today. And feel free to reach out to me on Twitter or at GitHub if you've got any questions or comments. Thanks everybody.