 Hi folks, welcome to the Windows Server Summit. We're excited to be here and today we're going to spend a bit of time talking about Software-Defined Networking in Windows Server Hybrid and Cloud. My name is Kyle Bisnet and I'm one of the PMs on the Software-Defined Networking Team. We have a jam-packed agenda, so we'll get started with the agenda and then now we'll get into the actual guts of the presentation. The first thing I want to mention is this is our amazing team. You're going to hear from each one of these folks today excited to be here with them and you'll learn a lot throughout the session for sure with them. The first thing we're going to talk about is, we're going to go through a little bit of an SDN overview. We'll talk about what is the value proposition that SDN provides to Windows Server 2025, and then I'll actually end up turning it over to Sam, where we'll talk about SDN infrastructure and resiliency enhancements. Sam's going to walk us through, if you have applications on two different sites, how do you help make those applications talk to each other seamlessly on Software-Defined Networking? We'll also chat about removing some of the complexity and making it really easy for you to be able to deploy SDN. Then up next, Cindy's going to take us through our amazing security features. How do I protect my virtual machines on SDN? How do I ensure I can actually audit those machines for traffic logs, and then also how can I make sure that no VM is left behind when it comes to security policies? Then next up is SDN performance and ecosystem integration. We'll talk about our high-performance Layer 3 or L3 gateway connections. We'll talk about some of our ecosystem integration that we have with Azure Kubernetes Service or AKS, which is the best place to host your applications on Windows Server. Then we'll close out with SDN evangelization, and what are we doing as a team to help you all come with us on the journey for SDN and help you ramp up on Software-Defined Networking as well? So without further ado, let's go ahead and hop into the SDN overview. Before we go right into the overview, I wanted to land with these two quotes from Pickett Security, and again, these are based off of 2022 data, so I'm sure it's changed quite a bit. The first is 45% of intrusions contain a lateral movement event that can easily be solved with micro-segmentation. If you think about that for a minute, that's almost half of intrusions could be solved from a lateral movement event, right? And then the next quote is 96% of lateral movement attack behaviors do not trigger a corresponding alert on security controls. And that's a huge amount, right? That's essentially almost 100%. SDN provides a tremendous amount of value when it comes to security, and like I mentioned, as we're going through the overview, we'll touch on this a little bit, and then Cindy will also touch on this in her portion. So let's go ahead and roll into the overview. So when we think about Microsoft SDN, it's really about bringing Azure-inspired networking to Windows Server 2025 into your data center. And we do this in a few different ways, and you'll see that these are kind of bucketized, right? We have virtual network concepts or an Azure virtual network running in your data center. We have back-in connectivity with our gateway components, and then we also have front-end access with our load balancers, right? And our load balancer is really an Azure L4 load balancer. So let's walk through each one of these. So for virtual networks, you can literally bring your own virtual network into Windows Server 2025 with software-defined networking. And that means you can also have the same IP subnet if you so choose. And we handle all of this with VX landing encapsulation on the backend. Now, when we get into security features, that's also where we talk about network security groups. So the same principles that you know and love today inside of Azure, you can now go apply a network security group on one of your virtual machines running on Windows Server 2025 with Hyper-V. And we make it a little bit easier than just that. We have these network security groups with network constructs, but say you may have a junior admin or somebody who's just learning the ropes with networking and they need to apply the same NSG to a SQL VM, right? And it's running a SQL workload. Well, tag-based segmentation is a way that we do key value pairs. And essentially you can say, hey, application SQL, assign that to a network security group and then assign that to a virtual machine. And you really don't have to have a ton of underlying network knowledge once that initial assignment is done. Now, leading into default network policies, this kind of goes with our no VM left behind act, right? Which is, hey, as soon as the virtual machine is built, we wanna make sure it's protected. And even before the virtual machine is built, we can make sure it's protected. So some really powerful security features that we have there today that you'll hear more about for sure. Now, one thing I wanna add is those three pieces do not just fall into virtual network. We kind of have two constructs here. The one is what we call an SDN logical network. The other is an SDN virtual network. And an SDN logical network, if we think about you being on your journey with SDN, more often than not, you're gonna have a ton of VLANs that are sitting in your data center that you may wanna apply network security groups to without having to have created this SDN virtual network yet, right? And maybe you're in that migration phase. So that's where these three can actually be applied to an SDN logical network. And really it's as simple as simply putting the VLAN in and then we go back and we program network controller with that VLAN and then we assign the NSG policies that you so choose. So right out of the gate, you can get some of those default security rules for your traditional VLANs in your data center with Windows Server 2025. Now, up next is being able to control traffic flow with user defined routes or network virtual appliances. So really good use cases, your security team may have blessed a certain appliance, right? And you need to route all of the traffic in your SDN virtual network to that appliance before it leaves. You can go ahead and bring in those appliances and as long as they support Hyper-V, they'll work with Microsoft SDN. And then last on the VNet side is being able to apply quality of service policies. So we all know more often than not, we may have a SQL noisy neighbor that's talking a lot on the line and we can go ahead and apply quality of service policy so that every VM gets the right amount of bandwidth. And of course, we're not starving any other virtual machines. So then we'll kind of transition into front end access. So front end access, like I mentioned, is really our load balancing services. And this is where you can use public IPs on a virtual machine so that you can do some type of a outbound connection that maybe that VM is sitting on an SDN virtual network. You also have the ability to do load balancing. So in a typical load balancing use case, you may have a few back end VMs that you need to provide a public IP to and you can do load balancing between those two VMs. Now, really neat thing, talking about the SDN logical network concept, you can use our load balancers for your traditional VLANs in your data center. So it's a really great value add where you may have some rack and stack load balancers that you're migrating away from or transitioning from. You can go ahead and take advantage of our load balancing services. And that's not all we provide there, right? We also have an inbound and outbound NAT. So in inbound NAT, it's a really great way of being able to provide a jump box into your SDN virtual network or maybe some type of like an Azure Bastion service. On the outbound NAT side, it's a really great way of being able to provide internet access to that collection of virtual machines running on your SDN virtual network out through a single public IP address. And then we'll kind of land on back in connectivity. Now, I've chatted quite a bit with you all about SDN virtual networks. They're isolated, right? We need a way to get outside of those virtual networks. And there's three scenarios that we provide today. One is a site to site gateway connection. So you can have secure site to site connectivity. The other is a GRE gateway connection for connecting over high speed WAN networks that you may already have in place. And then the third, which we see more often than not is a layer three connection. And, you know, often when customers are going through their journey with SDN, they probably have some shared services that are sitting on a VLAN in their data center such as Active Directory or file servers. So you can actually stand up a layer three connection with our gateways and we'll just forward that traffic over to an existing VLAN that you have today in your data center. And then last, but certainly not least, if you're familiar with Azure, you'll be really excited to know that we have the same capability in Windows Server 2025 with SDN, which is the ability to do hub and spoke connectivity. So if you follow any of our Azure documentation, specifically, you know, cloud adoption framework, you can actually bring that into your data center and have a shared services virtual network that is then peered with your other virtual networks. And it works really well again for those shared services concepts. Another benefit too is if you have a layer three connection in that shared services hub network, your existing spoke networks can actually utilize that. So it works out really well. So now we're gonna go ahead and transition over to Sam and he's gonna walk us through SDN multi-site and also some of our new deployment methodologies for network controller. Over to you, Sam. Thank you, Kyle, for that great intro. And like Kyle mentioned, with Server 2025 we'll have some significant SDN infrastructural and resiliency enhancements coming out, the first of which being SDN multi-site. I'm incredibly excited to showcase this feature for you all today. With SDN multi-site, you now have native layer two and layer three connectivity between applications across multiple physical locations. To begin, I'd like to level some of the key customer scenarios for needing multi-site capabilities in the state of SDN connectivity today without multi-site. So organizations today will deploy their applications across multiple locations. They need the flexibility to deploy and move parts of their applications freely across these locations without the need to reconfigure their applications or networks. This could be due to a variety of reasons. Mobility of workloads between locations, disaster recovery, multiple sites in different geo-locations to serve local offices and customers, et cetera. Let's take the case of a hypothetical customer. This customer has provisioned an application on Windows Server cluster one in California. The app has three tiers, front end, mid-tier, and backend. Now they are expanding to a new location in Norway and they want to extend the applications there to serve local offices. In order to have the flexibility for communication or migration or to manage policies across locations, these apps need to be able to connect over layer two, even though they are in different locations. This becomes quite a cumbersome process to overcome. So how do we address this? Well, with SDN multi-site, you now have native layer two and layer three connectivity across sites. What this means is that you can now have virtualized workloads spread across multiple locations, a unified policy management system, and eliminate the need to reconfigure policies upon VM migration. This last point is the crux of multi-site's infrastructure improvement to SDN. Take our previous example of two servers spread out across two geo-locations. You can now move a VM or a workload from, let's say, Norway to California without the added baggage of reconfiguring network policies or reallocating IPs. Going through the weeds of figuring out what you can and cannot provision once you migrate a workload. Now, let's take a quick look at a quick comparison of SDN today without multi-site, and then with multi-site coming in server 2025. Starting from the top, without multi-site, you can only link physical locations through an L3 connection. Practically, what this means that you have to provision additional resources to set up a GRE gateway and ensure high availability to said gateway in order to maintain network continuity. Second, because of the GRE gateway, migration or workloads across locations is cumbersome and time-costly. The bottom line is that today's policies don't migrate along with workloads if they move. Lastly, resources and configurations are localized to your physical location. Now, let's look at SDN with multi-site. Starting at the top again, you now have both L2 and L3 connectivity. Practically, with the addition of layer two connectivity, you don't have to re-provision and maintain a new GRE connection, freeing up precious resources for your organization to use on business-critical applications. Secondly, migration or workloads is streamlined as policies now move with workloads as they migrate. This streamlined migration is a result of us now having synchronized global resources in a unified policy management through multi-site period. We'll now move on to a quick deployment demonstration for multi-site through Windows Admin Center. For our demo today, we'll have two clusters, SDN-0304 and SDN-1314. These two clusters will represent server clusters at two separate physical data centers. SDN-0304 will be our primary site and SDN-1314 will be our secondary site. Before I show you how to enable multi-site, I'd like to show you that our secondary site currently has no virtual network resources. This piece of information will come in handy later in the demo. Now let's shift to our primary site, cluster SDN-0304 to set up our peering. Before I enable multi-site through our primary location, I'd like to note that on this site we have a virtual network called test. To begin peering across locations, all you have to do is go to your primary site, find your new network controller tab in your toolbar and hit the new button. From there, provide the necessary rest information for your secondary site. Once peering is enabled, you'll see your secondary site added to your Windows confirmation. Once peering is initiated, resources such as virtual networks or policy configurations that are once local to one of your sites now become global resources in our sync to cross locations. In our example, we have virtual network in our primary location. This information should now be updated to our secondary site as well, which if you can remember, didn't have any resources before peering. Now let's shift back to our secondary site, cluster SDN-1314 to confirm that our peering was successful. As you can see, at our secondary location, our primary site has been added to the list of network controllers. Additionally, you can see that our virtual network that was once at our primary site is now at our secondary site as well. With information like virtual networks and policies being shared across locations, Monari's site is able to support seamless migration of our very close, as well as providing a unified policy management system for your networking needs. The next new and exciting installment of SDN updates is that we are reducing our infrastructure footprint, starting with SDN's network controller. As a refresher, network controller is the control center for deploying your network policies and plumbing-set policies down to your workloads in addition to deploying any virtual machines that you might have. In summary, your network controller is the brains of your whole SDN infrastructure and the most critical part. Currently, this part of our infrastructure still lives on virtual machines. So what have we done to improve our infrastructure from this perspective? The story behind our footprint reduction starts with moving NC and all of its microservices that help deploy and manage your network policies to failover cluster resources. By doing so, we reduce on the amount of resources that your infrastructure needs to allocate just to run our core infrastructure components. By reducing our resource usage, we are freeing up precious CPU and database resources for you to use on your other business-critical applications. The improvements are quite significant and we'll go into a few examples in just a moment. However, let's start with a brief comparison of NC Today on service fabric and a more streamlined network controller architecture on failover clustering. Starting from the top, NC Today requires intensive CPU and memory usage. At the moment, we require around eight gigabits of memory for you to set up your NC VMs. This is a nontrivial amount. Secondly, because you're deploying VMs, you need to manage and update these VMs. This doesn't happen automatically, thus leading to more operational overhead. Last but not least, deploying NC VMs takes around 10 to 20 minutes. This becomes a speed bump if you're trying to scale up your operation. Starting with the first two points, we've eliminated the need for VMs and have built in our NC microservices directly onto the host, thus freeing up precious CPU and memory resources for you to use. And lastly, because we don't require VMs anymore, we cut down on deploying time in half. Next, we'll go through a couple of brief diagrams to showcase our performance improvements here. We'll be comparing NC on service fabric, our old architecture marked in blue, and NC on failover clustering, our new architecture marked in orange, across two scenarios. Scenario one with a thousand NICs provision and another with 26,000 NICs provision. Across the board, as you can see, we've reduced the amount of memory used by NC's working set, which is the memory allocated for your microservices by one third. And it reduced your CPU time by more than a third as you scale up your operation, which is our 26,000 NIC scenario. Additionally, we've also reduced our database requirement and time to add resources quite significantly. This is most significant when you're scaling up your operations. Looking at our 26,000 NIC scenario, we've reduced your database usage by a quarter and then have reduced the time to add resources by more than a half. Now we'll move on to a brief deployment demonstration for NC on failover clustering through our SCN express script. Currently, to deploy NC on failover cluster, you will have to use SCN express. The commandlet is the same as before. Execute the SCN express file and provide a configuration file for your setup. While NC on failover cluster is being set up, let me walk you through some of the key differences between NC on service fabric and NC on failover cluster. In addition to the performance upgrades mentioned previously, there are a few infrastructural changes as well. The first of which being that the microservices that typically manage and deploy your network policies are now hosted on your host machines instead of in VMs. These resources have the added benefit of being cluster aware while leveraging the failover cluster database instead of service fabric. Despite these infrastructural changes, your workloads will remain unaffected. Network connectivity will continue to persist. Typically deploying your NC on service fabric will take around 10 to 20 minutes because SCN express has to deploy and configure VMs, which is a more intensive process. With NC on failover cluster, this process is sped up quite significantly. As a result, let's now return to our deployment. With SCN express having completed its deployment of NC on FC, the question then comes, how can we check that we have a successful deployment? Since NC is now leveraging failover clustering, you can run your get cluster resource command. The following generic cluster resource types marked in red are your SCN microservices that are now hosted on your host servers. If these services are there, then you have a successful deployment. Thank you so much for listening in your time. Next up, we have Cindy presenting on some of the amazing SCN security features that are coming up in server 2025. Yes, thank you, Sam. So network security is a top concern for organizations today. With edge firewalls, internal assets can be protected from external unauthorized attacks, but they offer little protection against more common attacks that target organizations today, especially attacks that originate within the internal network. And these attacks are dangerous because they infiltrate the perimeter, they learn internal infrastructure, and they spread laterally inside the internal network. So that's where the next two security features that I'll introduce come in to prevent these attacks and strengthen your network security. So today, micro segmentation is already available through which you can protect your North-South and East-West traffic. With micro segmentation, granular network policies are applied between applications and services, and these policies permit only necessary communication to occur between application tiers or other logical boundaries. And as a result, it makes it very difficult for cyber threats to spread laterally from one system to another. This is achieved through a distributed five-tuple SDN firewall, which enables admins to really define their access control list to restrict access for workloads attached to traditional VLAN networks and virtual networks. But as we and our customers have seen, this requires you to ensure that you remember your network ranges so that you can provide them as part of your network security policies. And to solve that problem, we have brought in tag-based segmentation. And the value that tag-based segmentation really brings is instead of having to rely on outdated methods of specifying IP ranges for network security group control, admins are now able to use custom service tags to associate NSGs and VMs for access control. So you no longer have to remember and retype the IP ranges for your production and management machines. And instead, you can use simple self-explanatory labels. So with tag-based segmentation, you can label your workload VMs with tags of your choice. And then you can apply security tags that can be completely custom based on your requirements. So for example here, the workload VM has three tags. It's part of the production environment. It belongs to the exchange application. And even within the application, it belongs to the mailbox app tier. So now your network security group source and the NSG destination can be a tag or it can be a network segment. And with this, you no longer need to track the network segments where applications are hosted. And this is used widely in the market today. So if we look at an example here, we have two applications in this cluster, one web app and one IoT app. So the journey starts when an attacker lands on the user's personal device. And this can happen through various channels like malware or phishing, et cetera. And the attacker can get full remote control over the web app first and easily manipulated or leak data. And once the attacker already has access to the web app, they can easily gain access into the IoT app or even other apps in the data center that host really critical applications and data. So we need to define and apply network security rules to prevent the web app VMs from communicating with the IoT app VMs. Instead of having to specify every IP range for each machine, you can see how the NSG policy gets simplified with tag-based segmentation, where you can tag corresponding VMs with web or IoT network security tags. You can then create a network security group rule to prevent the web network security tag from communicating with the IoT network security tag. So that communication is blocked between the web and IoT applications. So really with security tags, management and provisioning of network security groups becomes much simpler. Here are a few screenshots from Windows Admin Center showing that you can create your network security tags under the network security groups page on the left table of contents and then assign your network security tags to VMs. Now we'll take a look at this tag-based segmentation demo where HonorBond will show two applications, one being a web app and one being an IoT app similar to the example that we just went through and how you can use security tags to deny communication between the two apps by assigning tags and applying network security rule. Here I already have an HCI cluster with SDN configured. The first step is to create the web network security tag. This tag is a type application. I create the security tag. Now the next step is to create the web VM, web app VM, with assigning the network security tag to the VM. So let's go ahead. We will create the web app VM. We will assign it to a network, first connect it to the virtual switch and then connect it to the application network. And then in the application subnet, we will provide it an IP address from that subnet. And here as you see, I select a network security tag of type application and the name is use web. I assign a storage to the VM and with that, we should be ready to create the virtual machine. So this will create the web application VM. Now we will do the same thing with the IoT VM where we are going to create a network security tag with name IoT, again the same type as application. And then in the background, I have already created the IoT app VM to save time. So now you have both IoT app VMs and the web app VM. Let's try to ping the web app VM from the IoT app VM. As you can see, communication is working between these VMs. Now we are going to create a network security group which is going to deny communication between these VMs using these security tags. So let's go ahead. I'm going to create a network security group called IoT web app. And then within the network security group, we are going to create and deny inbound rule which will prevent the IoT app from communicating with the web application. So I'll set it a priority. It's an inbound rule. In the source, I'm selecting the network security tag and in that tag, I'm selecting the IoT application. Tag. And then on the destination, we'll do the same. We are going to select the web tag. So now what we are saying is IoT app cannot communicate with the web tag in the inbound direction. So this is the network security group rule which is going to be applied. And then the final step is to apply this network security group to the virtual network subnet. So that this rule will get applied to all machines in that subnet. Now we applied it to the virtual network subnet. Let's go ahead and recheck the communication between these two VMs. As you can see here, IoT app is no longer able to communicate with the web application. So this concludes the demo. You can see how easy it is to create a network security groups between your applications simply by using tags. So like I just mentioned, it's critical to protect each asset in your cluster to ensure that it has access to and from only other necessary assets and nothing else. So we are introducing default network policies with Windows Server 2025 and Windows Admin Center. Now you can select your ports which ports on your virtual machines are exposed to other networks which makes it very difficult for compromised assets to spread threats laterally. So not only do default network policies protect your VMs from lateral attacks, but it also ensures that your VM is secured before the operating system is even deployed. When you apply a default policy to a VM, we create a network security group for that VM and then apply the relevant default NSG rules for that VM. So default policies use NSGs internally to control access to the VM. And default network policies only require network controller to be installed. And you can assign them to a VM either during the VM creation process or even after a VM is already created. And lastly, default network policies can be applied to a SDN logical network, which is just your traditional VLAN or physical network, or it can also be applied to a SDN virtual network. So how do we apply default network policies? When you create a VM through Windows Admin Center, you'll see a security level setting, which will have three options. The first option is no protection, which you would only choose if you didn't want to enforce any network access policies to your VM. And since this would expose all ports on your VM to external networks, we really don't recommend this because it would definitely be a security risk. The second option is open some ports, which applies default policies that will block all inbound access, except for specific management ports that you want enabled and allow all-album access. And finally, the third option is use existing NSG, which applies custom policies and allows you to specify an NSG that you have already created. And it's important to note here that DNP is currently available only through Windows Admin Center, but integration with VM self-service through Azure Arc will be coming very, very soon. And so now we'll take a look at a demo where Kyle will walk you through how to assign a default network policy to a VM and Windows Admin Center. Hi folks, so today we're gonna look at a demo of default network policies. So you'll notice first, I have three healthy network controller nodes. So if I look at those network controller nodes, I can see that they've been deployed, but I have not deployed any load balancers or any gateways. Keep in mind that load balancers and gateways are not required to take advantage of DNP or default network policies. So the first thing I'm gonna do is in this scenario, we want to apply DNP to a SDN logical network or LNET. And what that simply means is it's an abstraction of your physical network, right? So no SDN is actually in place. We're actually just creating a logical network for VLAN 21 that resides on your physical network. So once this go ahead and completes, we're gonna go ahead and select that and choose settings. We wanna ensure that network virtualization is not selected on this. Again, we're not using SDN at this point. We're simply plumbing network security group policies using DNP. So then we're gonna go to virtual machines. We're gonna actually create a new virtual machine. In this case, you know, we can go ahead and call this one Kintoso VMA. And then we're gonna accept all of the existing defaults except for in the network pane. Now in the network pane, we're gonna go ahead and choose our Converge Switch HCI. We're gonna choose our LNET. Again, you know, that's the physical VLAN on your physical network. We're gonna choose that logical subnet. And then this is where we're presented with DNP options. So you'll see no protection, which if we select that, we'll give you a banner saying this is a security risk and of course not recommended. If we choose open some ports, you'll see that list of ports of where you can go open those well-known ports. And then again, if you've already invested in NSGs, you can use existing NSGs that you've already created today. So since we're doing a DNP demo, it's best to look at what ports we wanna open. In this case, we did choose RDP. We're gonna go ahead and give it the virtual hard disk and we'll go ahead and grab our ISO file from here. Now again, keep in mind, before the VM even has been created, we've already applied network rules to the virtual machine. Now that virtual machine is created. You may be asking yourself, how does this look inside of the NSG pane after we've created a default network policy? You'll see that we actually have a policy there called Contoso VMA. If we select that policy and we drop down into the NSG feature set, you'll see that we actually created two rules as well. So we have RDP, which is allowed and then we're blocking all of the other traffic. Now keep in mind, we're still allowing all outbound traffic, but this is actually assigned to VMA. So it's not a real demo, right? Unless we actually go and we test this. So we've allowed RDP. We're gonna go ahead and check the Windows firewall. We're gonna ensure that the Windows firewall is disabled and then we're gonna ensure that RDP is enabled on both of these VMs. So again, this is Contoso VMA where we applied VMP and then we have another test VM, which is Contoso VMB. Again, ensuring the firewall is off on VMB and also ensuring that we can RDP from it. So we're gonna go ahead and check RDP is enabled, which it is. Okay, so our test to VMA, remember we allowed remote desktop. So we should be able to put in the IP address of VMA and connect via RDP. Now we'll get our credential prompt and then after we go ahead and give our credentials, we should get the infamous certificate pop, right? And once we have the certificate prompt, that means that we have RDP established. So we do see that and we are able to RDP to the VM. So now in this case, let's go ahead and reverse this. I mentioned that we allow all outbound access from the VM, which means we should be able to RDP to VMB. So we're gonna go ahead and try that. We'll get the certificate or the credential prompt and then once we have the credential prompt, we should get the certificate prompt. And again, this is just proving that outbound access is able to take place. That's it folks, I hope you guys enjoyed this demo. I hope you all enjoyed this demo and we'll chat soon. So in addition to the security features that I've just spoke about, Windows Server 2025 also includes other really exciting features, the first of which is high performance L3 gateways. So L3 gateways are one of the most popular gateway connectivity types used to provide layer three connectivity between your workloads hosted on virtual networks to workloads hosted on physical networks. And a lot of our customers are using L3 to ensure that they can connect to their corporate resources in their core network. But customers also use L3 for connecting to legacy apps or to physical machines in their data centers or even simply some shared services. And we have heard a lot from customers saying that they want higher performance for these connections. So we have listened and this is coming out as part of Windows Server 2025. So if you look at the chart on the slide, we have compared throughput and CPU cycles per byte for L3 connections before and after enabling the fast path. We see really impressive throughput gains ranging from 20% to almost 47%. And you can see that there's also a tremendous increase in performance in CPU reduction ranging from 27% to almost 40%. And these L3 gateway improvements are enabled by default when you create a L3 connection with Windows Server 2025. So you do not need to do anything manually to enable these performance gains. And of course, actual numbers will vary based on your environment. But as you can see, these are significant gains from the previous iteration. And now that we have a better understanding of SDN security and performance, Kyle will now talk about SDN ecosystem integration. Thank you so much, Cindy, really appreciate it. And I hope you guys are all excited as I am. I mean, the content that Sam walked you through with multi-site and NC on FC, no more virtual machines, like it's absolutely amazing. This is stuff we've been talking about for a while. So having this come to fruition where you're all able to take it up and use it is amazing. And then of course, Cindy talking about the default network policies and being able to ensure that no VM is essentially left behind when it comes to your security policies. So now we're moving a little bit away from all the core SDN pieces to our ecosystem integration. And when we think about ecosystem integration, where's the best place to host your applications on Windows Server? And that really is AKS. And we've had AKS and SDN integration for roughly a year and a half. And now we're bringing this into Windows Server 2025. And so let's talk a little bit about this. What do we actually provide when it comes to AKS and SDN integration? There's a tagline that I like to use quite often, which is empowering modern cloud native applications with a secure, scalable and adaptive SDN infrastructure. What do we really mean by that, right? And it comes down to all the benefits that SDN offers. So multi-Tennessee and network isolation. When we think about SDN virtual networks, the possibility of building your AKS target clusters on completely isolated SDN virtual networks so that they can never talk to each other. Also having your AKS management cluster sitting on an SDN virtual network that's separated from where your target clusters are. But yet the communication can still happen through the backend networking, right? So this is really useful when it comes to our manufacturing customers, especially when you're using a Purdue model or a Purdue networking model. Now, the second piece here is secure access to your Kubernetes API service. So one of the things that we do is we actually remove the HA proxy service that's running in all of your target clusters without SDN, of course. And with SDN, we use our native SLB load balancer, our Azure L4 load balancer. And we take care of plumbing all of the rules for you to that load balancer. So you have some resource savings there by not having to utilize HA proxy. And then scalability and performance optimization. I mean, really it comes down to the fact that now as you're deploying these AKS target clusters, you no longer have to go back to your network admin and say, hey, I need this VLAN. I need this VLAN. Oh, I need this VLAN because it maps to this Purdue model. You can simply just go build an SDN virtual network and you can deploy your AKS workload cluster. So it's really about making it an easier experience for you, all of our customers. So I chatted a little bit about this already, but again, AKS management cluster, it's on a virtual network, fully isolated using our inbox SLB, AKS workload clusters as you build those applications and you need to separate them into different workload clusters. You have separate SDN virtual networks. You can use our inbox SDN SLB. The last point that I didn't touch on in the last slide during the intro was about leveraging your existing SDN VNet configurations. So if I can give you a use case scenario, say you've already configured an SDN VNet, you've already went through connecting an L3 route, right? Say you're using an L3 gateway connection and like Cindy just talked about, right? We have high performance speeds now. So it's in your best interest to use those L3 gateway connections. Well, before we used to make you have to stand up a brand new virtual network and then you would have to go reestablish that L3 connection. Now you can simply just reuse that existing VNet as an input and you can keep your L3 gateway connection. You can keep any settings that you've configured inside of your SDN virtual network just like they were and then simply deploy the AKS workload cluster. So this is kind of what a deployment looks like for us. You'll notice you have your AKS management cluster on the left side here and then based on your virtual networks, you have different target clusters. You'll notice also, like I was mentioning, those API servers have different public IPs that are being assigned to them from our SLB service. So you can ensure they're fully isolated in its own SDN contained environment. And again, when we get into Purdue model, this is really useful, especially when you have separation of tiers, you can then ensure that that public IP is only going to where the traffic should be mapped on your OT network or what we call your operational technology network. And that's normally your IoT network. So I can't wait to see what you all think about our AKS and SDN integration. Now we're gonna move on to our automated certificate rotation. So for those of you that have been using SDN for a while, you may know the pain that comes with having SDN certificates and not quite knowing that they've expired. So we've worked on this for quite a bit. One, we have expirations very detailed inside of Windows Admin Center. So that way you can track along to make sure you're rotating your certificates before that expiration. However, if you happen to miss that expiration, it was a little bit of a cumbersome process to go through and change all these certificates. We have REST certificates, we have network controller certificates, we have southbound certificates. So there's a lot of points that you need to go changes on. Well, I'm really excited to announce that through SDN diagnostics, you now have full SDN certificate rotation. Before I show you that, a quick recap. So keeping my network controller, it uses certificates for authentication, authorization, and encryption. When we think about our northbound API, if you will, so think Windows Admin Center, Azure portal, et cetera, we also need to ensure that there's SSL encryption with our management clients and between our NC nodes. And then when we think southbound, that's really where SLB, our load balancers, and our hosts come in, right? Our Windows Server 2025 hosts. So these are three separate areas where you really need to ensure you grab those certificates. Now, with the automatic certificate rotation, there's three commandments that we're using through SDN diagnostics. The first is start SDN certificate rotation, which is gonna go out and replace your REST and NC node certificates. You'll be happy to know that if you happen to let these expire, it's actually gonna go figure out all of the logic to get everything back up and running again for you. You may see a little bit of errors out on the screen as it goes through this and figures out what's going on, but it will figure out that logic for you. So it's a great time saver. Today, we have the ability to do self-signed certs, bring your own certificate, and also pre-installed certs. The process is about 30 to 40 minutes, but the good thing is once you run the commandlet, you can sort of walk away and wait for your pass at the end, right? So it's very easy. Now, when we go to our load balancers, we also have a start SDN MUC certificate rotation. This will do the southbound certificates for the load balancer. Today, we only offer those in self-signed. That takes about 10 minutes. And then last, but certainly not least, is we need to go replace those Windows Server 2025 hosts, right, in our more southbound certs. So today, we offer self-signed, just like we do with our load balancers, and that process takes about 10 minutes. So again, fully automated, goes out, finds out where we need to replace such as certificates, and ultimately makes it easy for you. The awesome benefit here is we also have full stack tracing. So if you go out to see Windows Tracing SDN Diag, we're keeping track of the entire process. If something does happen and you have to call in support or phone a friend, you have those logs that you can go back to figure out where it may have failed, and we can usually get you up and running pretty quickly. But again, great reminder, make sure you're replacing your certificates and make sure you're paying attention to those expiration dates. Last thing I'll touch on before I move on, debug SDN fabric infrastructure, which is another great component of SDN diagnostics. So once you're done with all of your certificates, this will actually go out and run a health check. We'll make sure that you have connectivity with network controller. We'll make sure that you actually have connectivity to all of your southbound devices. And it's essentially a stamp of approval that, hey, things are looking healthy and you should be good to go. So again, excited to bring this to you all. Please keep the feedback coming. Let us know what you think about it. And without further ado, I'm gonna go ahead and turn it over to Adam, who's gonna walk us through a demo of going through the certificate rotation. I'll install the latest SDN diagnostics module into the system. I'm gonna do start-sdn certificate rotation and there's a few different options. So the generate certificate, this one's used for, you know, the SDN diagnostics module will handle the creation of the appropriate certificates in a self-side manner. And by default, it will default to three years. You can also configure this to be longer if you'd like. In addition to generate certificate, there is a cert path configuration, which will allow you to specify a folder directory where you may have already created your self-signed certs, or maybe you've generated certificate authority certs and you've got them in a PFX format. You can then place them all there and it will do the logic to map each one of those certs to the appropriate host. And finally, there is a cert rotate config. This allows you to kind of, if you've already installed the certificates, you know, you've generated the certs, you've installed them to the nodes, you can then create a cert rotate config, which will have kind of a mapping of each node to what certificate you wanna use. So for the majority, if you're using a self-signed cert, you can just run generate certificate and then you will need to specify credential. If you don't specify it here, it will prompt you. And the reason for this is because there's multiple hops it's gotta jump through to access all the infrastructure and stuff like that. So you need to be able to take your admin credentials to be able to do all the operations. So I'm going to specify my credentials here. And then it's gonna also prompt you for a certificate password. So this is if you need to export the cert with the private key. So go ahead and specify what you want that to be and then save it somewhere. So just a disclaimer that this is a preview feature. Go ahead and proceed with yes. And I'll move this over to the side here. So at this point, what it's gonna do is it's gonna go connect into the system. You'll pull the environment info, pull stuff related to the service fabric cluster manifests and stuff like that. Now if your certificates are already expired, you will see a lot of red in this. Just be patient. It is everything's built with full tolerance in mind that if it is expired, we will work through that and then figure out all the necessary components and we will actually go through and fix up everything. So if you're in that situation, just give yourself a little bit additional time for it to work through. All right, thank you so much Adam. And again, looking forward to hearing the feedback from you all. So the last piece, which is a big piece as well is we've been talking about SDN evangelization and community and really making sure that we're meeting all of you where you're at in your SDN knowledge and making it easy for you to learn SDN. So excited to announce the entire team has been working on our Microsoft SDN YouTube channel. We have quite a slew of videos out there, but the goal of this YouTube channel is really to ensure that we're getting the most up-to-date technical content out to you. I think SDN features that are coming out, SDN deployments that we're seeing, SDN and data plane topologies. We get a lot of requests from folks on, hey, does this architecture work for SDN or are there best practices for this architecture? So this is really our lens to you all. Of course, besides these amazing conferences like Windows Server Summit, there's a great way where we can connect with you all, read your comments and take feedback on what more would you like to see? Keep those requests coming so that we can prioritize that content for you all. And again, it's about giving free access as well. Anybody and everyone can go learn Microsoft SDN and submit video ideas. The other thing I'll add is Sam's also working on getting additional content out for you all, which is training content that's coming later this year. The amount of content that you'll have access to with this training content is pretty impeccable. We'll walk you through packet flows. We're gonna walk you through the inner depths of how SDN truly works. And again, keep the feedback coming for that. We'd love to hear more. So this is a quick splash page of our Microsoft SDN channel. That way you're no stranger to it. You'll see some of the videos that we've already launched and actually I'm gonna click in a little bit more to those videos. So we have an SDN overview 101 where we go through a lot of the scenarios, similar scenarios that we actually talked about today but a little bit deeper. And then we'll talk, Cindy actually has a video out there for SDN load balancing 101. So how does our load balancer work? What does the traffic flow look like for those packets? And then Adam has two other videos from our support team, Adam Rudell. How do you switch from a rest name to a static IP? And this is really useful if in your environment or in another environment you may have a lockdown DNS service or maybe it's a third party DNS service. And as part of SDN deployment, we require a rest name. Well, you can actually switch over to a static IP and remove those worries of having to deal with DNS. So really great way to get out of that path, if you will. And then last is the automated cert rotation that we just talked about. So while in the demo, you saw a small portion of it, Adam actually goes into great detail on the automated certificate rotation as well as any errors that you may hit and how to troubleshoot those errors, hopefully so that we can save you a support call and you don't have to worry about that as well. So again, go check out our YouTube channel, please like, subscribe, give us feedback. And it seems like it went awfully quick but that concludes our presentation. So in closing, I just wanna touch on what we talked about. We went through an SDN overview, right? We talked about some of the high level scenarios and the value proposition that SDN brings to Windows Server 2025. Sam talked about the SDN infrastructure and resiliency enhancements like multi-site and having network controller on fillover cluster. Cindy talked about the SDN security features and tag-based segmentation, default network policies. Again, really powerful pieces to ensure your environment is protected. She also chatted about the layer, a day all three performance on our gateways and how we're helping to elevate that performance so you get the most amount you can on the line speed. I chatted a little bit about our ecosystem integration with AKS, our certificate rotation and then of course our SDN evangelization. So I hope you all enjoyed it. We're looking forward to your feedback. Please remember to go scan the QR code, send us survey results, get your survey submitted to us so we can see those results. And yeah, I'm looking forward to the next one next year. Thanks all, it's been great being with you all and hope you have a great rest of your day.