 Welcome to another session on the Windows Server Summit. My name is Thomas Maurer and I'm here with Ryan Willis from the Azure Arc team to talk about how you can automate your Windows servers running on premises using Azure with Azure Arc. Our goal is to show you a typical IT admin scenario of needing to configure a Windows Server role, IIS, and put some files on it so it can host a website. We're going to show you how to do that five different ways. What we're going to do is walk you through all five features in Azure Arc, and we're going to start with Windows App and Center, which allows us to give a great point and click experience to go and quickly enable that feature, and upload that file in the graphical user interface. Then we're going to move on to SSH, where we will do it interactively through the command line. Then we're going to move to Run Command, where you can actually go and say, run this script for me, I'll come back later and check when it's done. Then we're going to move on to Azure Automation Runbook and show how we can start to scale this up and be able to efficiently run this script across a bunch of machines. Then we're going to finish off with Machine Config, which is our most modern declarative way of actually configuring this machines. Now, there's no wrong or right way to do any of these. These are all valid ways to go and configure a server. We just want to help you understand in a session that there are a lot of ways you can manage servers remotely with Azure Arc. We want to show you the improvements you get as you move from left to right in terms of efficiency. With Windows Admin Center, we're going to show you, you can sit there and quickly go and troubleshoot or fix things probably a lot faster than even to go look up the individual commands, then you might need to use for one of these other solutions. But for production environments, you might want to set it and forget it, and make sure it stays in the great state. That's where the farthest right Machine Configuration option is going to really shine. Awesome. I think that's exactly. If you have hundreds or thousands of servers, you probably don't want to go through all of them one by one. They're awesome ways. I'm looking really forward to see what we have here. Yes. I think let's go ahead and get started and take a look at the Windows Admin Center example. What I've done here is I've gone into the Azure portal. We have a bunch of servers we've already connected to Azure Arc. If you want to know how to do that, we've got some great docs online and previous videos you can refer back to. But we're going to start with that baseline that we have machines running on-premises, not in the same environment we're currently in, that we're going to go and enable the IIS feature and upload a very simple website to host on that server. Let's start with our Windows Admin Center machine. We've opened up the Azure Arc view in the portal for this individual server. We'll see it's connected and we have a lot of different features that you can use with Azure Arc. Let's go over to Windows Admin Center, and I've already installed it on this machine, so I'm ready to go and connect. The first thing I want you to notice is, I didn't have to log in yet. It's using my credentials in the Azure portal, my intra ID credentials and role-based access control in Azure to decide whether or not I'm allowed to get this far. Since I had the appropriate role, I was able to go and start accessing Windows Admin Center without having to provide any creds, which is a really great experience. If you've used Windows Admin Center on-prem, you're probably very familiar with this view. This is our server running on our environment, and I'm going to go over and use the roles and features tool to go ahead and install the web server role. Very easy here, right? I can just go click and choose what I need to enable, review my options, and then install. So it's going to calculate its dependencies, got a lot of things going on here, that's fine, and we're going to go ahead and get started. Now, this may take a few minutes, but while this machine kicks off that process, I want to talk about how all this is possible. Arc has an agent running on this server on-premises, and it is connected to Azure. Connectivity in that sense means that we are sending a heartbeat every five minutes to tell Azure that we're there, and we have all the components we needed to go and install features like Windows Admin Center. When we connect to Windows Admin Center, we're leveraging something called the Connectivity Service in Azure Arc. That is a bidirectional communication that goes between the server and Azure, and then what we're looking at on the Azure portal here is the front-end of that. So this front-end in the Azure portal is talking to the Azure back-end, which is then relaying all the same information from the individual server on-premises, and that's really cool because what that means is that I don't have to be on the same network. I didn't have to open up any inbound firewall rules to get to this experience, but I get the full-fledged Windows Admin Center experience from anywhere in the world using the Azure portal. Now, some people now think, this is like, how is security working on this? From speaking with some of our customers, what I realized is it actually helps them to get the environments even more secure, because what they're using now is Entra ID as the mechanism to make sure the identity is correct and also do some additional verifications like multi-factor and location-based log-ins to the Azure portal. Then on the other hand, they were able to actually remove the local admin user accounts on their servers. Maybe for some breaking-glass accounts, but that already helps to have less things actually on the server and you have this single control plane where you can control access to it. Absolutely. We just saw an notification pop-up that our roles are now installed. That's excellent. Now, we can actually refresh this page and we should see the web server it is installed. Excellent. The next step for us is that we need to upload our extremely fancy website. I'm going to go browse the file system. Again, all this is happening remotely and this is really cool because I can say, look, I have the website on my machine here, so I can go and upload it. It's got a simple index page. Submit it and it uploaded it to the server remotely. Now, we have the IIS role installed. We have our website files in the web directory for the default web application. Now, we should just go see if it's working. Now, since I'm not on the same network and I haven't configured any firewall rules, I can't just browse to the server, but one great feature of Windows Admin Center is I can use remote desktop. I'm going to log into this machine remotely and see if it is set up correctly. Credentials are required for remote desktop and remote PowerShell via WAC, because now you're actually connecting into that server as a user who's managing it. I'm on my machine. This is where we installed IIS. It all works well. If I go localhost directly, we should see. There we are. We have our awesome website. What a beauty. What a beauty of a website. Absolutely. This was a quick example of how we set this up with Windows Admin Center. This was very easy to do because everything is very graphical. We could just point and click through. But if we needed to do this on a bunch of machines, this would be a little bit tedious. We'd have to go repeat this step multiple times. Now, I think we're going to head over to Thomas, who's going to show us how we can start to do this more in a scripted fashion. Yes. Obviously, again, I like the UI to do certain things, but after a while, you get probably tired if you have to do it more than once. You probably want to use some command line tools, or in some cases, you're probably using a server core or you're using a Linux machine, and there you need to type all the things. Let me show you the example here quickly on my side. With another machine here, we have set up and using the Arc agent basically to connect it to the Azure portal. As Ryan showed you, this is not different from the machine he showed you, but instead of now using Windows Admin Center here, I can click on the connect button. Now, this will allow me actually to create a SSH connection. And in some cases, you probably heard correctly, yes, SSH also works with Windows Server as well. So I can do some logins here. In my case, to make everything a little bit easier, we're just going to use a password, but you can also use key-based authentication as well. So I'm going to use my username here, and then it creates me the command here, and I will show that in just a bit, which I can use. Now I can even connect that through Cloud Shell, so directly into the Azure portal, or I can use my local terminal, for example, to run that command. So I already pasted it here. So it uses the Azure CLI with the SSH extension, as you can see here. I then provide the subscription, the resource group, and the name of the Arc machine, and then with the local username, I want to log in. And now what it does, it actually tunnels from my local machine, from my local client here, over the Azure control plane, to the server running anywhere in the world, basically, over a secure connection. And it asked me, obviously, for my password here. By the way, just showing you this, you can also integrate that in your local SSH client. So if you're using some SSH client you'd like very much, or SCP, for example, as well to copy files, you can do that as well. You don't have to use the full Azure CLI command all the time. So now you can see here, I'm locked into that server. If I go here, you can also see that this is actually a Windows server, where I'm connected with SSH. What I'm gonna do now is I'm gonna log in or open up PowerShell. And my first task, what I need to do is obviously, same as Ryan, I need to install the web server role. So I'm gonna do that. And you will see that I already have installed that to save some time here, but it gives me back that it's actually already installed. Next step, we need to get the website or the server files actually to that machine. So the way I'm gonna do that, I'm quickly gonna, it's going to C, EnetPUP, and then WWRoot. So you can see here, I got the default IS website in there. And now I have a command here to basically copy the website from a file share, which isn't the same network as this server. In this case, to this IS website folder, just copy that. And now, if I do here, you can see here, I copied that index HTML file and you will basically have the same website as Ryan just showed you in the WAC, now available on this server as well, all done through like command line, an interactive command line experience using SSH over Azure Arc. I love that. And especially how responsive it is, right? Like if you're used to working with the command line tools, that felt extremely natural to me. Yeah, absolutely. Yeah, if you just need to send out like some quick commands, then that's great, right? You can just log in. You can use your existing tools. I like that too, right? So if you're using an SSH client, like something or an SSH manager, you can use that too. And there's some other background things by the way, which is for example, we have this feature in preview where we do a dash RDP. In that moment, it even tunnels you an RDP session over SSH, over the Arc connection. And that's obviously handy if you do Windows Server Management. But next, we have some other cool things where we can like, if you want to scale this, this was maybe not so super helpful because I still need to log into all the machines. But I know Ryan, you're gonna show us something which will help us with that. Right, yeah. So the two options we've found so far, which are Windows Admin Center and SSH were both interactive tools, right? We were sitting there running the commands in real time. Now we're gonna shift a little bit more towards non-interactive tools so that if you imagine you got a bunch of things you gotta do, maybe you have 10 servers you need to configure. Wouldn't it be great to be able to do all of them and just wait for the responses to come back as opposed to having to do them one at a time or have 10 different console windows open. And so for that, I'm gonna demonstrate Run Command, which is a preview feature for Arc-enabled servers. And this is basically an API in the cloud where you can say, hey, on this server, please run this script and tell me the output when it's done running. So to do that, I'm gonna go ahead and open up the cloud shell here. This is just a way for us to run the Azure CLI commands in the Azure portal. And I'm gonna go ahead and paste my command here. And so this is the same stuff that you just saw Thomas do, right? I'm just telling it, we're gonna go on a connected machine which is an Arc server, run a command. We're gonna give it a name for what this command is. You could have multiple commands running it once on a machine, identify which machine we're gonna actually run this command on, and then the script. And so in this case, I just put the script right in here. You could imagine you could pull a script from storage accounts or a file share as well, really flexible experience. And my script is just gonna install the web server role and copy the files over. So when I kick that off, you'll see now it's running. I ran this in a synchronous state, so it's gonna wait for the response and then show us what that output is. You could also tell it, don't wait. And if you choose that option, you can go back later on and say, hey, AZ connected machine run command. Show me the results of all the commands that have been run on this machine. And it comes in a format that's gonna let you know when was it run, what was the output of that command, as well as some other useful information. So it's a really nice way to kind of kick stuff off. Maybe it's a long running task and let that happen in the background while you go work on some other features. Yeah, now this is actually fantastic. I like this, how this works. And I think there's also, if I'm correct, correct me here. There's also a way you can integrate in this into ARM templates and things like that, like where you can not just run the command in your shell, right? But you can just integrate it into an ARM template if you do infrastructure as code. Yeah, that's a great example. Yeah, so this is just like any other Azure resource. So you could even go to a whole extreme here where you have ARC connected to maybe your virtualization infrastructure on-premises. And if you do that, you can make an ARM template that says make a new VM on-prem using my on-prem image, my on-prem network. And when that VM is done being created, run these commands on it to go and set it up the way we want for that particular machine. And you may be familiar with that concept from the cloud, but with ARC, we're able to take that same thing and make it work on-premises for any of those resources. So we're really excited about that. That's fantastic. Oh, speaking of like, hey, we're taking an Azure concept and bringing this to on-prem. Run command is not something which is just limited to Azure ARC machines, right? Right, yeah. We actually have the same approach here as Azure VMs. So you may be familiar with this on Azure VMs as well. Same exact approach for Azure VMs as ARC servers. So we're trying to get that parity between on-prem and cloud servers. All right, and we're back. So now this command has finished. And so you'll see it kind of give us the output here. And in the output is all the information that Thomas was showing in his console that look as pretty here because it's formatted in JSON for computers to process. But we can see that the provisioning state was succeeded. And here was the script that we ran on that server. So this is kind of how run command works. You can imagine I did this on one machine. You could easily run this API on multiple machines and then wait to get the result back from each of them. One thing obviously we see is also that you probably wanna have like a central place to have like all these different run books, right? In this case, you're basically taking it, you're copying it. You need to kind of doing all that management for yourself. And now, especially if you wanna do large scale automation also against different systems, right? It's not just about like one server. You wanna probably do it against like multiple systems, different APIs maybe, maybe even like hardware appliances locally, right? You wanna have like all this together. And so we have this great automation service called Azure Automation, which can do like a ton of different things. But I'm gonna focus a little bit on like the run book part of it where you can actually create your custom run books and scripts and manage those. So if you open up an Azure Automation account, this is what you will see, right? And I'm gonna show you a couple of things later on and go through and explain this a little bit more. But the essential part I wanna show you are the actual run books, right? So you can create your own run books here and I wanna show you quickly a specific thing. So you can create PowerShell or Python run books. And if you choose PowerShell in the Windows Server world, you also have for example, like Windows PowerShell 5.1, but you can also use like PowerShell 7, right? If it's installed on the machine, you're gonna run this later on. So that's what we're gonna create, but like in a good cooking show, I already prepared something. So I have a couple of scripts here and one of them is exactly like installing the web server and copying the website on that machine, right? So I can get that up, I can get that run book and you can see here, this is now where this run book is stored and where it's also managed. So I can see here when it's recently has been run, but let's have a look at it first. So if I go to the view button, I would see the view, but I can also go and edit it directly in the Azure portal or there's also a great VS Code extension. So you can also edit it in VS Code as well. But for now, because it's pretty simple, let's just edit it in the portal. And this is how the script looks like in this case. So you can see here, I have the same command here, if I zoom in, you can see here, I've installed Windows feature web server. And then I also have the copy command here to actually put the website there. What I did here as well, you can see here a little bit of the difference. We are using Remoting here because I don't want this to run on these hybrid workers. And I'm gonna show you these in a bit, right? The way Azure automation works is that I create this hybrid worker group and those are basically the ones which are executing the scripts. And so I recommend that you then use PowerShell Remoting and other things to then go to the actual systems you want to run this script on, for example. In this case, I have created a variable which I can store also in the automation account with the server names, right? Like I cannot just have one server, I could have multiple servers in that list. And then I can also, for example, securely store the credentials for these remote systems. So I can, as you can see here when they're installing those feature commandlet, I can actually say, hey, computer name for this variable and then for the credentials to run against these systems, I can use this. So I don't have to have any credentials in that script. Azure automation can take that management of these secure assets away from me. So I can easily insert them. You can see here, I can add credentials here as well or variables, right? So I can use the same scripts, for example, with different variables as well. And then if I go back here, what I can just now do, I can go and start that run book. Now, one thing you have to understand, this is not just designed to run on-premises, right? Azure automation has also the Azure workers, basically, but you don't need to manage. They're just there somewhere in the background and you can now say, I want to run this script. Now, in our case, obviously, this would not do much because it would just run somewhere and it could not remote to anywhere because we want to run this in a local network. We're going to select our hybrid workers here. And I already created a group called the Azure Arc Workers and this is a group I created. These are a couple of on-premises machines which are now executing those run books. And in this work group, you can have multiples of these workers and that means that if you have run hundreds or thousands of these run books, right? This can scale out across all these workers. And also, if one of these workers goes down for some reason, another worker can take over that run book job. If you, for example, schedule it or you just fire it up, one of the workers is going to pick it up. And that's also a great thing, by the way. I also want to quickly show you. You can also go and schedule this directly from Azure Automation, right? So if there's something you want to do a recurring task, you want to do every Tuesday night, for example, you can absolutely do that as well. And before we go on, I want to quickly show a couple of other benefits here of Azure Automation. So the one thing is, for example, the hybrid worker group I just talked about, this is where you can add your worker servers, right? In this case, I've just added one worker, but you can scale this out, again, for availability reasons or for scaling reasons in terms of performance. So that is one thing you can do. And then you can schedule these. You can see here also the possibility of securely storing credentials, then you can reuse those in the run books. Same thing for, for example, variables, which you can store there as well. And then the last but not least, which I want to show you, there's a ton more, but is also the source control integration here. So you can, these run books are now stored in that, but it only stores like one version of it, basically, or basically two, like the published version and the version you are editing. But obviously if you want to have a history, you're probably going to use some source control, like GitHub, for example, which you can add here. And now you're able to add GitHub or Azure DevOps, for example, to connect to these repositories and link them. So you can even then enable AutoSync, for example, so that whenever you do changes in the Git repo and you edit your scripts, they will get synced to Azure automation as well. If they're in the right branch and you actually move them to production, right? So that is pretty cool. You get the whole management experience of these run books as well. So it's a good central place to actually create all these, to manage these run books and run them at scale on-premises, for example, to your different servers, but also other systems as well. Yeah, and I know automation has been around for a while and people love the features from it. I particularly really liked the ability to keep the credentials separate from the rest of the script. And it's great to see that with Azure Arc deploying that hybrid runbook workers easy because it's now just an extension that Arc can help deploy and manage. So definitely great to see the tie in there. Yeah, and again, also if you manage, for example, different locations, right? This is another great way of running these runbooks on different workers in different locations and to get all that central management. But one of the things is a little bit of like, okay, this is like a one-time thing where I run this runbook, it runs the command and then it forgets about it, right? It's there's no control. If someone goes then manually to do some changes, I don't see that on that system, but we have something here which can help us with that. So for this last demo, we're going to talk about machine configuration. Now machine configuration is our modern, desired state configuration as a service offering. You may know it through Azure Automated, you may know it through Azure Policy, but it is a feature that's built right into our servers and available for Azure VMs as well that lets you tell us what should this server be configured as. So up till now we've been kind of doing imperative programming, meaning we're telling it, go do this thing right now. Desired state configuration takes the inverse approach. It says, no, no, no, what should it look like? And if it isn't like that, how do we make it like it should be? So it's a very different way of thinking about programming, but it's very powerful because one of the first things you get with machine configuration is a compliance state, right? And the other ones we kind of already had to know was this machine set up for IIS or write our scripts in a way that if we execute it on a machine that's already configured, are we going to break anything again by running it a second time? With DSC, we have this compliance state is built in and this is regularly evaluated on that machine to check if there's any drift. So I have set up this one down here tailwind website. This is a custom policy that I made that sets up IIS on this machine. And you'll see that this machine is compliant. And so when you create a machine configuration policy, you are telling it, what do you want to happen on that machine? In this case, I said enable IIS feature. And when you assign it to one or more servers, you can say, what do you want to do? Do you just want to check for compliance and audit across the environment? Do you want to configure once and then let us know if it drifts from that point or do you want to continually autocorrect if this machine drifts? And so if I go back to the previous page, you'll see I have mindset here for apply an autocorrect so that we can go and make sure that this machine's always set up for IIS. And so this is extremely powerful. We're showing it in this example for setting up a feature on Windows Server, but you'll see I've got a bunch here as well for like security policies that are enforced by Microsoft on my resources. You could imagine extending this for your own IT policies as well as really anything that you can write a script to test on a machine to see if it's in a state you want it to be. You can turn that into a machine configuration policy and then get this audit at scale. So the scale piece is really important. Let's go to Azure policy for example and show you what this looks like for a scaled assignment. So I'm gonna go and find one here that includes some machine configuration policies. So here we are. This helps me see across my entire environment how many of my servers have insecure password security settings. And it's checking a bunch of things, right? If we look at all these individual policies, these are all the different types of things you might set up on Windows and Linux. Works on both and whether or not they're compliant. And here we're seeing that I have 32 Linux servers, 56 Windows servers. This could be a mix of Azure VMs and Arc-enabled servers running anywhere, multi-cloud, on-premises doesn't matter. And of those, how many of them are non-compliant? And so this is really powerful if you're trying to generate reports across the enterprise of, hey, I got this setting that's gotta be configured as such because maybe I'm held to a regulatory requirement, maybe that's just your company policy. Machine config is a great tool to go and do that automatically at scale. And once you set it up, you don't have to go back and fix anything, right? It's there continuously evaluating and optionally correcting settings that have drifted. Yeah, fantastic. Thank you very much, Ryan. Thank you everyone watching and I hope to see you in another session.