 Hi, folks. My name is Danny Martins. I'm the product manager for SSH-related projects within Windows and Azure and Microsoft. Today, I'll be showing you how to manage Windows Server via SSH and Arc. Jumping straight into it, today I'm going to show you in about 10 minutes how to connect to your Windows Server without a public IP address via SSH and Arc. How are we going to do this? First, we're going to enable Azure Arc. If you're not familiar with Azure Arc, Arc allows you to bring the Azure Management plane onto a non-Azure-joined piece of hardware. This could be something where it's your local computer. It could be a machine that's running in a private data center or a machine that's in a different Cloud provider. Next, we're going to enable SSH on our Windows Server. SSH has long-binned industry standard for promoting. Windows has been the exception. If you look at connecting to a Linux machine, a networking device or an IoT device, you're probably going to use SSH to connect to that machine. Historically, WinRM or PowerShell Remoting, or RDP has been used to connect to Windows Servers. But if we look at WinRM, WinRM is no longer receiving any feature updates, and all of PowerShell Remoting's future is based off of SSH. If we look at RDP, it's difficult to audit the actions performed over RDP. You can't audit a mouse click. Next, we're going to look at how to use Azure PowerShell and native SSH commands to can actually connect to that machine without that public IP address. This is possible using the Arc connectivity back into Azure. Next, I'll show you how to enable Keybase login for administrator. SSH keys are a more secure way of authenticating to your machine compared to user and passwords which are generally standard for the RDP connection or a WinRM connection. Lastly, I'll show you this a fallback to using RDP access over SSH, and if you're not ready to fully commit to transitioning to SSH at this point. Let's just jump straight into our environment. Here, I have a Windows Server 2025 Insider Build. This is the latest Insider Build. If I look at my local server, we have added an option to enable remote SSH access. We'll start by enabling both Arc access and SSH. When I click to enable Arc, I've already installed the Arc agent just for the sake of time, but we still need to configure it and connect it to our Azure account. I'll do a quick sign into Azure, go through my two-factor flow. I've successfully signed into Azure, and next I'll connect it to my specific tenant. Subscription and resource group. Lastly, I'll add the region. Great, so while this is connecting to Azure, I'll show you that I have, already have some Arc machines here. So now in the Azure portal, you can see I have two existing Arc machines, and once this machine is onboarded, we'll see another machine pop up here. Give it one more second just to show you it's there. We can see it's complete and we'll refresh one more time. There it is. Now I've onboarded my machine into Arc, and I can see it in the Azure portal. Next, let's enable remote SSH access. When we enable SSH on the machine, this is going to run a PowerShell script to start the SSH service and set the startup type to be automatic. Great, so now we've already enabled Azure Arc on this machine and we've enabled, say the SSH server side component running on this machine. And so if I want to connect, I can open a local terminal experience. So here I have PowerShell running on my local client. We'll minimize out of this RDP view just so you can see that, yes, I am not running on my remote server. So here I can connect my server by running enter AZVM. And in this case, I can specify my resource group, in this case Arc servers, the machine that I've just onboarded and I may be connecting as an administrator. I've also specified the resource type as a hybrid compute machine because this is an Arc enabled server. This command can also be used for Azure VMs as well. So when I execute this command, it's going to say, hey, we need to set up SSH connectivity on this Arc server. This is purely for the connectivity that Arc is going to provide. And so here I'm going to say yes, I want to enable SSH based connectivity over Arc to this machine. This is something that's specific for an owner of that resource. If you have someone who is a reader or a contributor access to this machine, they will not be able to enable this. So now that this is running, it's going to try to connect. And if you're familiar with SSH based connections, the first time you connect to a new machine, it asks you to validate your fingerprint. This is a standard process for SSH or connecting to any machine. And I know that this is the correct machine. So I will say yes to that. Here I'll supply my administrator password and I've connected to this machine. And so in this case, I've connected to my new Windows server that I've onboarded into Arc and I've enabled SSH and able to connect from my local client and probably less than five minutes. And so now you have this ability to go from any public machine that you can authenticate into Azure into any of your Windows servers without domain joining, without having to have a VPN or a public ID address on that machine, you can connect via SSH and Azure Arc. If you already have existing automation, let's just say you're in a heterogeneous environment where you have Linux machines and Windows machines. And let's say you already have existing SSH based tooling. Maybe you're running Ansible. Maybe you like to use SFTP for file transfers. How can you leverage this connectivity? Again, without that private public IP address to be able to connect to that machine. And so we also support an export, exporting an SSH config file. But here you can say export azsshconfig. Again, supply that resource group name, user login resource type and also create an SSH config file. So here I provide a config file path. We'll just create a foo.fig and this will take the proxy that's used in order to connect to my machine that I have packaged as part of Azure PowerShell. And it's gonna say for any SSH connection that's connecting to the host, it's gonna use a proxy command to be able to connect. And so in this case, if I say SSH and provide the config file I just created so my foo.fig, I supply the resource group of my connection the machine name and the user I'm gonna connect as I can then run the same command. Again, I'll get prompted for my password. I'm in that same machine just through a native SSH experience. This also applies if you wanna use something like SFTP so I can easily change this into SFTP and connect to that machine again. And again, I'll hear I'll get prompted for the password but we'll just kill that command now. Let's say instead of having to want to enter your password each time you wanna set up an SSH key. How do we do that? I already have an SSH key that I use to connect to all of my arc machines and so I'm going to create a key variable that has the content of that key. So now I have a PowerShell variable with my key value and there we can build some remote PowerShell script. To add a file in the SSH folder on my remote host with the administrator authorized keys with the value of the key file that I'm passing. So here I will create that remote PowerShell and now I can go back to that same SSH command that I have previously and I can just supply this remote PowerShell command. Here it's going to connect to the machine. It's going to make me authenticate with my username and password one final time and it's going to execute that remote PowerShell script. But you can see it's successfully run the one command and there's zero failed commands that have run. And so now if I go back to that original enter AZVM command, I no longer have to use a username and password. I can just supply the private key file that I wanna use to connect. And so in this case, the private key file that I use for my art machines, I can run this command and I'm not gonna be prompted for a username and password because I've supplied the key into that onto the server. Great, so now we have the ability to connect over a private IP address and we have the ability to more securely connect without a username and password using an SSH key. And so if you're building any automation that's cross platform across Windows Server or in other environments, you can use SSH connectivity to reduce the amount of scripts and tooling that you have to have to do Windows administration and Unix administration. And you can merge those to build at the one automatic processing across both over SSH. Let's say you're not quite ready to move completely over to SSH. You still wanna have a fallback and be able to RDP into your machines. The nice thing about SSH is it supports arbitrary port forwarding. And so in this case, we've built a parameter dash RDP. And so when I execute this command, it's going to create an SSH connection, but it's gonna use that as a tunnel for an RDP connection to my remote server. And so it's opening a tunnel to my remote server and it's using SSH to connect from the local host port to my remote server. In this case, it's failed. And we know this was going to fail because just like how we enabled SSH and Arc on my remote server, we have enabled remote desktop. And so it's expected to fail. So in the case that you want the fallback default to use remote desktop, just enable RDP back on this machine, apply that and say, okay, and we'll run this command one more time. In this case, it's using my SSH key to create that tunnel. And I'll be prompted for an RDP authentication into the machine. In this case, I still have to use my username and password for the administrator because RDP does not support key base login. And I now have a new RDP section connecting to that machine. And you can see the difference here because on the connection, it's showing that I'm connecting to a local host port, but this is indeed that same remote Windows server that was connecting to previously. Great, so what have we done? So in the past 10 minutes, we were able to easily enable Azure Arc, enable SSH server component on Windows Server 2025, connect the machine without a public IP address via Azure PowerShell and a native SSH command. You could also use that with other open SSH based tooling. We enabled key base login and we've also shown how to fall back to RDP if you need that and you're not ready to forward transition. That's all the time I have today. Thanks so much for your time. If you have any questions, I'm Ganey Martins. You can find me on Twitter or message me on GitHub. Thanks so much. Welcome to Windows Server Engineering Summit. Today I'm talking about disaster protection with SR, storage replica in Windows Server 2025. My name is Ned Pyle. I'm a Principal Program Manager in Windows Server. You may know me from SMB, DFSR, Active Directory, File Services, but I'm also a designer and creator of Storage Replica, which we first released in Windows Server 2016. And we have a lot of big news in that space that I'm gonna talk about today. I've only got 15 minutes. I gotta be fast. So let's talk enhanced performance, compression, and I will show you lots of practical demos. Let's go. Storage Replica helps organizations survive disasters. It helps you keep your job. SR is designed for you to be employed. It protects companies, organizations, businesses, from gigantic forces outside of their control. And those forces can be earthquakes, hurricanes, wildfires, and they can happen at a city level. They can happen at a regional level. They can happen at a town level. And depending on the size of the organization, that's a big enough disaster that could affect you. Just even the last year, this is a National Weather Service data. These are the billion dollar natural disasters that happened just in the United States in 2023. So every one of these things, whether it's a wildfire or flood or a tornado or giant snowstorm or whatever, each one of these represents at least a billion dollars worth of damage. And SR is here to protect you from that, to give you continuity, to make sure that your place can keep running. So what do we got? In 2025, we have something called the Enhanced Log. Storage Replica writes data blocks above the partition, IO blocks into these logs and chips them between machines using to reconstruct the data blocks on another machine. And so the performance of this log is key to Storage Replica's performance. It is the engine. It is the thing that does the replication. And this new Enhanced Log, we sometimes call the raw log reduces latency, increases throughput, and is based on a different type of technology. So it requires a new partnership. It is in Windows Server 2025 only. And, but you can still use 25 servers with SR and in its older mode called CLFS logs on 22, 2019, 2016, anywhere where SR lives. And then there's compression. So Storage Replica uses SMB, you know me from SMB as its fabric, as its transport. And because SMB does compression, we plumbed SR to do compression. And that can give you really significant network savings. It can save you a lot on inefficient IOs that write a lot of effectively empty blocks of stuff into the data. And so on a crappier network, you can see real significant savings on a highly congested network. You can see real savings. And this is now in server 2025 and all of its additions. It was actually shipped in 22, but only in Azure edition. So you may not have been aware that this functionality was there. Now it's available for everybody for all things. And it's primarily for asynchronous replication. Obviously SR does synchronous and asynchronous. All right. So this new log and compression and asynchronous gives me, I think, a very viable alternative to using DF-SR. Everybody's seen DF-SR, it came out 2003 R2. It's what you use to keep your sysfalls in sync automatically. But its custom replication is a very complex, large system, a file replication that's been around for almost 20 years. And it's got some real limitations, especially in age as being a disaster recovery, disaster prevention option. It only works on unlocked files. So locked files, in-use files don't replicate. It's extremely latent. Minutes, hours, days, latent on changes. It has, at this point, pretty small maximum size limitations just because it was designed for a world that no longer exists. It's extremely slow in initial sync. It's multi-writer, which is advantageous in some ways, but can cause its own set of disasters with data overrides from multiple users accessing multiple copies of the data at various points in between replication. It has a very complex and rather finicky staging system that requires a lot of tuning and careful math in order to make sure your replication works optimally. And a lot of space reservation in order to make sure that it will replicate at all as your file sets get larger. And because it's so old, again, it's from 2003 R2, it never knew things like REFS and newer file systems. It was completely incompatible with them. And really, most of its really significant development ended in 2008 R2. There was some changes in 2012, some smaller changes in 2016, but for the most part, DFSR has just been a maintained product now that's as good as it's ever going to get. So when could I use storage replica instead of DFSR? I need zero data loss, minimal data loss. I can't be dealing with locked files. I can't be worried about replication being out of sync for very, very, very long periods of time. I've got lower latency in higher bandwidth networks, although compression will help here. Ideally, if you're gonna push this much data, you're gonna wanna have better networks. And DFSR was designed to work on, you know, modem networks, extremely narrow networks. And I only need two copies of the data. As DFSR supported thousands and thousands of copies of the same file, SR just does a source server and a destination server. And that's it. And finally, I don't care about this multi-user case. I don't want users writing to 14 different copies of the file and then a complex algorithm deciding who won. Okay, so let's talk about tackling some of DFSR's disaster prevention failings with storage replica. So the initial sync, here is DFSR, the old DFS management snap-in. Familiar to anybody who grew up on Windows Server 2003. I'm gonna go ahead and add a couple of servers here. These are decent servers. They've got all flash. They've got 10 gigabit networking between them on TCP. I'm trying to make this a fairly reasonable case. I'm gonna set up replication. I'm gonna set up primary. In this case, it's gonna be 421. Keep that in mind. And I'm gonna set up what folder I'm gonna replicate. In this case, it's on the eDrive, RF1 folder. And then I'm gonna add the other server, which is 423 and turn on replication. Give it a place to replicate two and let it rip. And that's sort of an optimistic way of putting things because this is, of course, DFSR, there's not a whole lot of ripping going. So, we'll go look at the event logs. And I find my, I'm looking for my 4112 event. That's my, I've started event. There it is, okay. So here's where I've initialized the replicated folder. I've got a primary member and I'm waiting for all that data to get pulled by the secondary. So I'm calling the secondary and I'm looking for a 4102 event that says I've heard about this and I'm starting. So, we're gonna catch this and just watch and see how long it takes. We can see how big this is. I'm replicating about 400 gig of data, about 10,000 files, a mixture of all kinds of files, some big, some small. And so, we've been waiting for a while. We're doing 72 gig of wait for, let's wait longer. All right, we waited a lot longer. We waited three hours and it's finally done doing 400 gig. Over 10 gigabit, that's not great. And what's worse is I sort of cheated here on DFSR's behalf. I tuned staging. I made a bunch of little, you know, fine configuration changes as a real, you know, I own DFSR, I'm supposed to be an expert on this. So I made DFSR as fast as I could really make it. Honestly, if this had been an out-of-the-box setup and I hadn't touched any of that stuff, this initial sync, especially with these types of files I was replicating, some of them very large, multi-gig files, it might have taken 24 hours. It might have taken 48 hours to finally reconcile getting its way, forcing it through the staging and the high water marks and the flushing operations and all this shenanigans that DFSR does. Anyway, let's get on to the good stuff. Here's storage replica. Now, why do I call it the raw log? Check out this volume I just created. It is, in fact, raw. And we're sort of restoring this log. It's actually based on storage spaces. Technology is where this log is actually kept. And so now I'm going to put in my server. It's 421 again. I'm just picking a different drive. So instead of using the eDrive, which is where DFSR was, I'm just picking another exactly the same hardware, gDrive, another flash drive. And I'll add my other server and pick another drive. And I'm going to set this for asynchronous just because I'm trying to match up to my use case where it's a file server that I want to be working on worse networks. I don't need synchronous replication. And I'm probably going to use compression. So it started. I'm watching. Notice I'm using Windows Admin Center for all of this, not Grosold Snap-ins from 1999. And time has gone by. It's now continuously replicating. And if I go look in my event viewer here, which is in whack, and I don't need to go wandering off to another tool, I can see here that my replication started at 8.09 and it finished at 8.17, eight and a half minutes is how long it took. That's all. So not three hours, not 24 hours, not 48 hours, eight and a half minutes, not too shabby. And if I was being like, cool, I would have used RDMA and SMB Direct and 40 gigabit network cards here. It would have been even faster, but I'm giving DFSR a fighting chance because I don't want to be super rude. All right, let's talk about just protecting a file. So I'm going to take on my DFSR server. I'm going to copy this big file. It's about 14 gigabytes and just drop it into my replicated folder on the source machine. And here it's copying. And then it's going to be replicated over to the other server using DFSR. And so it's taking me, I don't know, 20 seconds to copy the file here onto the machine. And, but it's not really protected yet, right? It's got to actually be copied. So let's take a look at this thing. And last access at about a minute, it's a helpful little timestamp. So let's go over and look on the other server and figure out how long it took for this thing to show up. And we take a look. It's still not here. Should start with an S. Let's just wait a while. We ended up having to wait about, well, about 10 minutes. When I open this file, you can see my last access time. It took quite a while for it to show up, actually. Let's try this with storage replica. Now, this is not files anymore, so I can't go look at a file, right? It's blocks. So I'm gonna go and use perf counters and just use them to let me eyeball the transfer of this particular file. The same file, I'm gonna do it again. So I'm gonna set my log writes per second. I'm gonna set my bytes per second on sent. And then I'm just gonna do the same thing. Just copy a file into the storage replicated g drive. Let's just copy this thing over here. Here it goes. Now, I'm copying the file onto the disk, but really what am I doing, right? I'm replicating the file onto the other server simultaneously. So this copy, when it's done here, being on the disk, it's done being on the other one as well. There's no 10 minutes. There's no, like, let me unlock the file. There's no, well, I'm waiting for the staging folder to clear out. None of that nonsense. Like, the IO here is the IO on both machines. And you can see it's going. I'm getting a pretty good throughput there. And when we're all said and done, I'm waiting for this to finally finish flushing out. Here we go. 35 seconds. Not bad. Not 10 minutes. Not two hours. Not a week. 35 seconds. So here's the old log and the new log. CLFS log versus raw log. The exact same operation. How much better is it than, say, Windows Server 2022? Copy my file. Everything's being happening at the same time. You can see that I'm actually getting more consistent throughput and higher throughput on my raw one. By now, if you haven't guessed, it's the number, it's the top one is where raw is going. And so it's cranking and cranking, consistently cranking, no dropouts, moving along consistently, doing about 500 megabytes a second. That's looking good. This, by the way, is synchronous replication this time. And when it's done here, flush, 32 seconds. The other one's gonna keep going. This is still being protected pretty fast, way better than the FSR, but it's taking much longer to be done because this is the old log from 2022 server. And there it is, 48 seconds. So a vast improvement over the old storage replica, not just over the FSR. So better performance, better network usage, excellent disaster protection. It's in all editions of 25. It's included, there's no extra price, there's no special subscriptions or anything. And I have written an entire article on being able to go and do a migration you can use from the FSR, storage replica. It's on the FileCab blog. And I wanna thank you for your time. Please enjoy the rest of Windows Server Engineering Summit.