 Hey, my name is Thomas Maurer. I'm here with Ryan Puffer from the Azure Management Team, and we're here to talk about Azure Arc-enabled servers and how you can manage and govern your server in your hybrid environment using Azure. So stay tuned. Hi, Ryan. How are you doing today? I'm really well. How are you? Doing great is an honor to have you here on this show. So you are part of the Azure Management Team. Can you tell me a little bit what you're working on? Definitely. I work on a product called Azure Arc, and that is a group of services that we are working on to go and help you manage your hybrid assets from Azure. I specifically work on the server aspects, so being able to manage your Windows and Linux servers that are running on premises or any other cloud perhaps. Okay. That is awesome. I think I have to write person here because many of our viewers obviously are wondering how can they leverage Azure to make their on-premises environment, that their hybrid environment even better using actually Azure itself without moving everything to Azure. So since I have the right person here, what are we going to have a look at in this session? Yeah. So we're going to start by talking about why Azure Arc came to be what problems we're trying to solve with it, and then we're going to dive a little bit deeper into the architecture. So we can understand why is it designed the way it is, what are we trying to accomplish with the way we set it up, and then we'll go through a demo of how it works and talk about how, for you as an IT professional, where is Arc going to help you simplify your management and monitoring experiences? That sounds awesome. So before we actually dive into all of that, I know that we have a couple of viewers who probably heard Azure Arc, like the name before, but actually didn't really know what it addresses and why we actually created it and what it is. I mean, we're going very deep into what it actually is and what it allows us to do. But can you explain a little bit like why we do have it and what's the reason why we actually, why you're working on that? Definitely. So Azure Arc came from our long-standing approach of making sure that hybrids included in our cloud strategy. We always know customers are going to be running some stuff on-prem perhaps for the next couple of years, perhaps forever, depending on variety of regulatory and internal policies. And so we're trying to find solutions that help bridge the gap. We don't want you to feel like you have a cloud team that only does cloud stuff, which is really cool and modern. And then you have your legacy stuff on-prem that's kind of just been the same for the last 10 years. We can do better. And we know that the bridge there is really to enable you to use the same tools across hybrid and in Azure. So the idea of Azure Arc is to be able to go and take your stuff that's running on-prem or in another cloud and make it show up in Azure. And by having a representation of your server in Azure, you can start seeing everything in one spot. You can use the same tools and processes to manage all of your servers. And then from there, you'll be able to start adopting modern management practices for these assets, which are not necessarily running in the cloud. Oh, that's awesome. So actually, if I understood that correctly, you basically can use these modern management technologies we have in Azure and actually take resources or servers in that case, which are living outside of Azure. Doesn't matter if they're on-prem or if they're running even at another cloud provider and basically bridge them, as you said, into Azure and start managing them as they would be Azure resources. So that's pretty cool. So I know, obviously, since you're behind that feature, especially when you work on that, I'm sure you can tell me a little bit more about how that works and what the architecture on that is. Yeah, let's head over to architecture slide here and talk through what does it really mean to be part of Azure? So it's kind of a busy screen. I'll walk you through it piece by piece. But the main thing we wanna do is make sure that you can see and control that server from Azure. And the Azure control plane is this box here in the middle called Azure Resource Manager. It's really where any action you ask us to do in Azure is gonna be routed through. So for example, if you ask us to provision a VM for you in our data center, that request comes through the portal or command line through Azure Resource Manager where we have a common set of experiences to control things like access and security, being able to govern it with policy and ensure it's set up correctly, template deployments so you can group everything you need for an end-to-end product together. And of course, being able to tag, organize and search for all those resources. So ARM is kind of a brain of Azure. And after it makes all of its checks, keeps track of everything you've got going, it'll go off and provision that VM for you or do whatever it is you asked Azure to do on your behalf. And it's a very cloud native experience. When you think of the cloud, you think of point click go, being able to automate things with scripts. And the beauty of the cloud is since we control the whole stack, meaning the physical hardware on which the machine is running, the network, the configuration around that machine, we make it really easy for you to onboard anything that's an Azure Resource Manager to management services, which is kind of a broad grouping of all these kind of value add things we have, like being able to monitor the logs on your machine, managing updates, securing it with Azure Defender. And it's very easy to connect those to things in Azure because we know about everything. We can just ask Azure Resource Manager how many resources do you have? Are any of them not being monitored? And if we find any, we can just say, hey, Resource Manager, please go and turn on monitoring for that machine. They can go around that request. But when we think about hybrid stuff, it's kind of sitting in your environment, whether that's a data center you own or another cloud provider, you got some existing tools that can go and manage those resources. But in the end, it's still you, it's still your company. You still wanna manage it the same way. And we have a ton of hybrid services today. So that top box of monitoring and update management, those all work on-prem today. You can go and use those with these existing servers you have, but it's not that same one-click experience because Azure's not aware of them. You have to kind of opt into the management for each individual service. And after that, everything else lights up. So the idea of Azure Arc is, well, how do we make the experience the same? And we do that by taking these resources, running in your environments and projecting them into Azure Resource Manager. And by that, I mean, we're making a representation like a metadata of your server in Azure that we can kind of reference and provide these same controls and connections with the Azure native virtual machines already have. Okay, that is pretty cool. Like, so I remember the times, like when we were like started with Azure where we had, like it was called Azure Service Management, I think the management service management API. And we start to have a lot of Azure resources and it became very difficult to manage all of that. Like to have actually organized them and you just ended up with these huge lists. And then this cool kid came around the corner which was like Azure Resource Manager, which also obviously then was the kind of like new portal as well for a lot of people. It was just a new portal as they were thinking of, but it was actually the whole logic for it and really helped us managing resources at scale. And what you're now telling me is that with Azure Arc, I can basically use the same Azure Resource Manager to manage resources which are actually not hosted in Azure at all. So that is pretty cool. Definitely, yeah. And so, you know, we make it really easy as well when you're in the portal or using the command line to manage your Azure subscription. You know, we'll denote that, hey, this is a server not running in Azure. So, you know, some of the capabilities might be different, but I know everything we're trying to provide here about management services should be just the same as if it were a native Azure resource. Okay, that is cool. So I can use like tagging as you mentioned and all that and like it looks like it really feels like that. That's already very cool. Like for, especially for inventory and stuff like that, even like this is awesome. Definitely. And when we think about, you know, IT pros trying to upscale and keep up with the current technology, it's also a great opportunity for them to be able to learn how to work with the cloud even though the day-to-day management they're doing might still be on-prem. Okay, that makes sense. So I can actually use Azure to manage resources, which again, like I work, I'm basically working with my servers in my data center, but I actually use Azure to manage them and organize them and whatever. Yeah. Okay, cool. Awesome. So, you know, getting it projected in sounds interesting. What does it mean to have metadata about that server in Azure? And the reality is we need to kind of have a bi-directional communication. So it's more than just telling Azure that there is a server somewhere else. We need to be able to actually go and talk to that server so that we can actually manage it from the cloud. And so let's dive a little bit deeper into how this is all kind of implemented. So at a high level, all of the Azure Arc products, which means, you know, Arc for servers, which manages Windows and Linux, Arc for Kubernetes, which manages Kubernetes clusters, et cetera, we're all agent-based, meaning that you install an agent on your server or Kubernetes cluster and connect that with Azure. And that connection process is your authorization to say, I would like to have my server placed in this Azure resource group and subscription, and I would like to be able to manage it from the cloud. And from there, we have a connection from Azure, our resource provider, which actually has all the logic of what to do with this machine on-premises and the agent on-premises, which actually can go and perform actions on behalf of the request you make in Azure. And a key point I wanna drive here is, you know, it's a very lightweight agent. The entire goal of it is to connect it to Azure. So it's not trying to replace anything you already have, it's really just trying to bring that end-to-end management and cohesive experience that you have with Azure VMs to the on-premises world. So all those existing tools and processes you've already invested in, you can keep using those, that's totally fine. We're just enabling you to make it easier if you want to use Azure services on that machine to be able to do all that from the cloud and not have to go sign into those servers or use local management tools to go and onboard them to Azure services. Okay, that is handy. I also good to know, like that is there's no, like I don't need to replace all the tools I'm currently using because in many cases, they're working, right? I'm using them for years probably and know they're working to manage my stuff, but obviously there are some gaps. And so I can actually start using both at the same time to actually fill out those gaps, right? So that's cool. Definitely. And so I actually wanna take one quick side step of, all right, so we have metadata about the machine. We have an agent. What is it? What can Azure do to a server instance running anywhere? And in our case that since it's agent-based, you can really install this on physical machines, virtual machines, Windows, Linux. We don't really care. As long as you can install the agent, then you can start managing it with Azure. So I wanna quickly step over to the Azure portal and talk about Azure VMs for a second. What does it mean to be an Azure VM? And so if you go and ask us to provision a VM for you, there's really two distinct attributes that make it an Azure VM. One, it's running on our hardware. Somewhere in the world, one of our data centers, your machine is consuming memory, CPU, power resources. On the second level, it has that deep connection into Azure to do things like if you go on the side here to see all these great tools available to go and enhance that machine. We have this concept of like extensions, which allow you to go push down software onto the machine or run scripts on it. And that makes it easy onboarding for a ton of other Azure management services that you see here on the left. And that's all possible because of agent running in each of these VMs, part of the template that you get when you deploy the VM called the Azure VM guest agent. And that agent is just responsible for handling requests to, for example, run a new agent on that machine for monitoring purposes or run a script on your behalf, reset your password. It's kind of the connection point for a lot of the UX experiences you see here where those actions have to take place inside an operating system. So when we think about ARC, we have a representation of that server in Azure. We need to manage that server. Well, our agent is doing the same thing as that Azure VM agent. And so if we head back to our architecture, what we actually do inside the agent is three different tasks. So when you think of the ARC connected machine agent, it has three functions. The first one is called the hybrid instance metadata service. Now this is doing a couple of different things. First is doing all the syncing with Azure. So we don't collect a lot of data from your machine we really only know your host name, your fully qualified domain name, operating system name and version. That's about it, we don't collect much. But we use this agent on the server to go and regularly sync that information with Azure. Now in the reverse direction, we also pull some information from Azure to your machine. So for example, if you go and tag your machine in Azure, you can use this agent will go and sync those down and it exposes an API that any app on that machine can call to ask about the Azure representation of itself. So if you wanted to know what tags are associated with you, you can just call an API that's hosted by the hybrid instance metadata service and get that information. Similarly, you'll get your resource ID in Azure, what physical data center that metadata is being stored in, et cetera. Now, if you're familiar with IMDS from Azure VMs, it's the same. So we re-implemented an existing service that is natively part of the Azure fabric on-premises so that apps on your machine think they're in Azure. They can have a very similar experience even though they're running on-prem. One of the great capabilities of that though means that we're able to take Azure Active Directory managed identities and bring them on-prem. So in addition to providing metadata about the server, every Arc server also gets a unique AAD identity assigned to it. And so if you are writing an app that has to go talk to other Azure services, whether that's a storage account or a key vault, well, now instead of actually having to put a password in your code, you can use the managed identity and just make a request to the endpoint and say, hey, I need a token to go talk to an Azure storage account. And we will use the identity for that machine. We take care of the password. You don't ever see it. You don't have to worry about it and you'll get a token to go and reach out to the other Azure service. So that alone is really exciting for the app developers who are trying to figure out how do we better secure apps on-prem? So if you are an app developer working with Azure services to build your end-to-end app, this alone is gonna be a huge new capability for you to leverage. All right, this is awesome because again, when you build these apps and when you start using Azure, for example, let's say, as you said, as a great example, you wanna have access to a storage account, right? You have a server which does some uploads, for example, to a storage account, like without the managed identity, I basically always had to somehow store a password in a script file or somehow, like obviously there are ways of doing that, but it was like every time a lot of effort and super annoying and I'm sure secure it doesn't have a much fun when we do that. So with that, we get already the benefit of having like that managed identity and I think a lot of people underestimate that. So that is pretty cool. Definitely. And then the next part of our agent is called guest configuration. And this is all about being able to govern your machine from Azure. So Azure has a service called Azure Policy which is constantly working with Azure Resource Manager to help you determine whether your resources are meeting your own standards. And those might be regulatory standards, they might be internal policies that you've published and it could be any kind of setting. So it could be making sure that your machines are tagged correctly, like every resource has to have a department associated with it or a cost center. It could be every machine needs to have its logs sent so that we can monitor it for security risks. And a subset of those policies are actually checking OS and software settings. So things like what is the password setting configuration on my server or do I allow SSH connections from users without passwords, that kind of thing. Anything operational or security that you have to go inside the computer to actually ask it, you can't just look at the metadata about the machine in Azure. Well, we include the Azure Policy Guest Configuration Agent in the Arc agent. So every Arc server is able to be monitored and governed through Azure Policy. Today that is an audit only experience but we are working hard to enable remediation as well. So you can imagine kind of a future where you'll be able to define your IT policies in Azure once and it will be able to apply to any of your resources, whether they're in Azure or in another cloud or on-prem. So that sounds a little bit like group policies on steroids to me. This is like I can use that and do my all my, basically my policies across all my servers, doesn't matter where they're running. So one thing I have to ask though, it means this sounds awesome, especially when you speak about regulatory stuff as well, but do I need to write all these policies by myself because that seems to be a lot, that was usually a lot of work, right? Creating all these GPOs usually and finding out the settings. Do I need to do that by myself or is there anything which helps me? Yeah, that's a great question. So we have a pretty extensive library of built-in policies. They cover a lot of common scenarios we see and we'll do a demo later and kind of show a few of those, but they cover things like security settings making sure your password policy is secure as well as operational things like do you have any certificates that are about to expire on the server? Additionally, we have tooling available to take existing group policies you might spend time authoring and converting those into Azure policies. So if you want kind of a centralized monitoring console to go see group policy compliance for both domain joint and non domain joint servers, well, you can use Azure policy as your auto mechanism for that. And that way in case you're applying settings through different means, you'll still be able to see all the compliance results in a single place. And then lastly, if there is something custom that you just can't find already or you really found a new setting you wanna test, awesome, it's a flexible framework. Under the hood, it's running PowerShell DSC on Windows, Chef inspect on Linux and as long as you can write a script to go and test for the presence or configuration of a setting, but you can turn that into an Azure policy and get those compliance results in hour or less. Okay, wow. So you're not just providing people and I wanna make sure that everyone heard that because that was really like something I wanna highlight. So it's not just that we build, like build, give you built-in policies and you can create your own policies. There's also tooling available, like so far, if I have already GPOs to actually convert these to these Azure guest configuration policies. Okay, so this is, okay. I'm sure that not a lot of people have heard of like that conversion tooling. So that is great stuff. Definitely, and we're excited to see where it goes. I think this is gonna be a great tool for customers who are starting their journey towards more cloud-native policy and governance. Obviously it's a long journey. Group policy has been around longer than some IT evidence. So it's a step in the right direction for sure. Awesome. And then the last component of our agent. So we talked about identity and metadata sync. We talked about policy and governance with guest configuration. The last one is extension manager. So I mentioned how Azure VMs have the ability to push down agents and run scripts on the machine without actually having to log into them. Well, we're bringing that same exact functionality with the same extensions on-prem. And so that means if you want to think about onboarding a server to other services, a lot of Azure management services collect log data to make their analysis. So for example, Azure Automation, Azure Monitoring, Security Center Sentinel, they need log data to be able to understand the current state of your machine. Now those are all usually using the log analytics agent or the forthcoming Azure Monitor agent to go and collect those logs. You could install that separately today on-prem that's been supported for many years now. But we offer you the ability to go right to the portal and say, hey, I really want to monitor this machine. Can you just install that for me and configure it? Because I don't want to have to sign into that machine and do it myself. And so the extension manager is the piece responsible for downloading the latest version of those agents, configuring it with the right settings that you specified on the Azure side and then reporting back whether or not that was successful on your machine. And so we have a variety of extensions available today, everything from monitoring to being able to run your own scripts or desired state configuration files to being able to sync certificates down to your servers. And we're going to keep expanding what extensions are available. So if you have one that you love and you don't see it available on Arc yet, just reach out to us. I'm sure we can look into making that happen. And definitely keep an eye on what new capabilities are coming out on our blog as well. Awesome. No, this is great stuff. So now obviously you showed us a little bit how that all works. Basically on the architecture side, I want to see that live. So you were speaking about the agents and how do I actually add a server and all that? So can you show me that a little bit? Definitely. So let's head over to the portal. So this is our Azure VM. We're done with that. We're in the hybrid mode. So let's take a look at this resource group here where I have a couple of Arc resources. So Arc resources, you'll also quickly see right away, they have a different type server, Azure Arc. And they've got this purple icon with a blue ring. Most of the Arc things are gonna have that blue ring underneath to help you figure out what's hybrid very quickly and visually. But let's go and open up my web server here. So this is a machine running my server here in Boston. And you'll see right away, we have given a very similar portal experience to an Azure VM. So previously for hybrid servers, this was every service you chose to onboard a hybrid server to, you kind of had to jump between them to get all the data from them because there was no representation or common identifier of that server in Azure. Whereas an Arc server gets an Azure resource ID, we can link all of your data together and say, hey, this machine is using all of these services. We can pull all of that together in the portal. So you as a server admin can come here and see all the information relevant to you about the state of your server. And so you'll see, this machine's got a couple of tags already set to help me organize and find my resources. The agent has been sending heart beats up every five minutes to just check in and see if there's anything that needs to happen. And then from here, we make it really easy to onboard to the other Azure services, which can help you manage these hybrid assets. So this is kind of what it looks like for an existing machine getting to this point. Installing the agent is really easy. So if we head up to the top and we head over to Azure Arc, we can go to servers and we've got a wizard here that will kind of walk you through what it's gonna take. You know, in general, it's three steps. You got to install our agent and then you have to configure it with Azure and then you smile because it's all done. Nice. So, go ahead. Can you quickly go back to that? Don't try now, I don't want to interrupt you, but this was also interesting to me. I mean, we're speaking about that agent for quite a bit and I know that a lot of people need to deal with firewall rulings and stuff like that. So this is interesting. It says here, I need to have an HTTPS connection to Azure, right? So it's a 4.4.3 connection. So that doesn't mean I need to have full internet access. I can actually limit that connection or how does that, like, what actually do I need there? Yeah, that's a great point. So obviously, you know, in the Azure world, everything's communicating internally from an Azure VM to all the services running underneath. But on-prem, you know, since we don't control your entire environment, we expose our service as any other Azure service with a public endpoint. And, you know, as far as what you need to be able to manage it with ARC, it's outbound access only. We're never gonna reach into your network. The agent's always sending a heartbeat and asking you what to do. And we publish a list of the endpoints which you'd need to allow. If you have a proxy server, we do support those. And very shortly, we will also support private links. So if you don't want to open your machine to the internet and you need a private connection into Azure, you have ExpressRoute set up, well, we'll be able to do ARC over that as well so that all the communication can happen off public internet, but, you know, for the average user, this is all happening over secured, you know, TLS protected sessions over the internet. So if that's an option for your servers, that's gonna be your easiest way to get started. Okay, okay. So it sounds fairly simple and fairly like secure in a way that I don't need to just like open up random internet access for these servers. No, that's awesome. Good. Sorry. Yeah, no worries. That's a great question. And just one other point on that, you know, if you do manage the firewall, you know, we do publish what we call service tags in Azure. Those are groups of IP addresses allocated to each service. So we have our own service tag for Azure ARC. And so if you're managing that firewall and you only want to allow access to just those Azure services you're currently using, well, we'll give you that list of IPs you need to grant access to. So a lot of capabilities there if you need to go and lock things down in your environment. So yes, we will assume at this point that we've already done that part and internet connections available. I just got a server, I need to go on board. The next step is where are you gonna make that server show up? So you pick the subscription of resource group. This is just like any other resource that you would have in Azure. I'm gonna go find my resource group here. So we're gonna put it in the ARC demo. Next up, you pick a region. This is very important. The region of an ARC server is just where do you want the metadata for that machine in Azure to reside? So it's just for data residency purposes. It doesn't have to match physically where that server is. It is just where you want us to keep like that machine name and an OS type inversion. Next up, of course, Windows or Linux. This is really just changing the onboarding script at the end. And if you have a proxy server, go ahead and let us know. Now I mentioned that the region doesn't necessarily have to match where it's physically located. So we provide some suggested tags to add so that you can help organize your resources more accurately for these hybrid ones. So for your data center, you might pick whatever internal name you're using for that, your city, mines in Boston. And of course, you can add any custom tags you want. And you don't have to add them all now. You can, of course, modify these over time or automatically with policy. And the outcome of this is, it looks like a lot here, but it's really just a script that's gonna go and download the latest version of the agent. It installs it and then goes and connects it to Azure. Now in the default setup, this is kind of for a test environment. So if you're setting up your first machine, when you get to this step here where it says, you know, let's connect this machine you'll see the information we asked earlier is just being passed on the command line where it's saying, here's where we wanna put it in the tags we asked to add. The next step it's gonna do is it's gonna prompt you to log in as yourself. And that's the authorization step. Someone with access to that resource group has to be able to say that you're allowed to connect to it. And so in the default case, you would just sign in in your browser and just say, yep, let's go and add this server and off you go. That obviously doesn't scale to the enterprise wide scenario. So when you get to the pre-production and production rollouts, there's two additional parameters you can add to provide a service principle for at scale onboarding. Now we mentioned earlier, putting passwords in files is not the greatest. This is kind of a chicken and egg problem. We need somehow to prove that you're allowed to get into Azure before we can stop using the passwords on-prem. And to help you mitigate the risks of that, we have a built-in Azure role-based access control profile that is very limited. It's called the Azure Connected Machine onboarding role. And all it lets you do is onboard new Arc servers. So when you create that service account and you say, hey, this is gonna be the one we used to onboard to Azure, but you can just assign the role to the resource group or subscription where you're gonna put those servers and you can even set the lifetime of the secret to be just a day, two days, however long it's gonna take you to roll out. And then use whatever automation tool that you have today on-premises to go and push this agent out and onboard all of them to Azure. Yeah, okay, that sounds like much more fun if you need to onboard like hundreds or thousands of servers and just log in on each of these servers, yeah. Yeah, for sure. And yeah, once that's done, your server will show up in Azure and we kind of think of Arc as the agent to manage other agents. We want this to be the only one that you actually had to go and get on that machine. And from here, you can do everything straight from the cloud. So let's head back over to that server and take a look at what that means. Awesome. So we're back on this front-end server here. There's a lot of different things you can do and I wanna start first with extensions. These are really powerful because they really take a lot of the management of keeping things up to date and installed agent-wise. Makes it a whole lot simpler. So you'll see here, I've got four different extensions deployed to this machine already. It's very easy to see what versions installed. You could, of course, query for this information in the Azure Resource Graph if you wanted to go and compare across all your machines what versions are installed. But I have the monitoring agent installed. I have the insights agent installed and we'll take a look at what that means in a minute or two. I've got a security center agent and then a keyfile one. And I didn't have to sign into the server for any of these. I just, you know, you go here, you click add. You'll see I got a couple options. If you wanted to actually go and configure the roles on this server, also, PowerShell DSC can help with that. And so you could actually go here and say, look, I've defined the configuration of my web server and browse to that DSC script, provide any optional arguments and we'll take care of downloading it to that server and initializing the configuration on it so that the machine is set up as you expect. So a lot of flexibility here with extensions and, you know, as we go forward, especially in like the monitoring world, the new Microsoft monitoring agent known as Azure Monitor Agent is going to be extension-based. So we're really going all in on this model because it makes it a whole lot easier to manage and keep things up to date when it can all be done right from the Azure portal wherever you happen to be, whether it's a coffee shop or in your data center, not actually have to sign in and use your local management tools to do the same. Awesome. And, you know, next up, the other big capability we talked about with Arc is policy. So, you know, policy is really flexible. You'll see here, I've got a couple different policies already applied to this machine. We're looking at the scope for a single machine. So if I were the admin of this particular server, this screen is telling me that overall, there is at least one policy that's non-compliant. So, you know, someone might come yelling at me soon and I go down this list. You'll see, of course, you know, I've got plenty that are compliant, but three of these are not. And, you know, you can drill in and figure out exactly why a machine may or may not be compliant. You'll see here, I've got one here, audit machines with the insecure password security settings. That's one of those built-in policies. You know, we've got, it has a bunch of sub-polices that it's checking, like, you know, making sure you have maximum password age, minimum password age, preventing reuse. And you'll see compliance for each of those different metrics that we're looking at when you drill in through this view. And, you know, as a server admin, now I know what I need to do to go be compliant with, you know, what my central IT security organization is asking me to. We also have, you know, operational ones. So, I mentioned earlier, we have policies for checking, like, if certificates are expiring. And policies generally are parameterized. So, this policy, when I assigned it, I said, you know, for me, 60 days is when I want to be warned. Because at that point there is risk of the service going down and I need to have time to actually go get the new certificate created and actually go and push that out. So, I set this up, I deployed it, and you'll see this machine is non-compliant because I have a certificate there that I think it's already actually expired. And so that tells me something's gonna go wrong very soon or already has. I need to go take a look. I think that is a very, very useful policy for many, many people out there. Because again, like, if you manage all your certificates, like, it happens from time to time that people forget that they need to renew the certificates. So. Yep. Happens to the best of us. Awesome. And then, you know, there's also ones that talk about integration with Azure. So, let's take a look at this one here. Enable Azure Monitor for VMs. The last two policies we're looking at settings inside the OS, they use guest configuration. Some policies work on the metadata, the representation of that server in Azure. And so this one says, I wanna make sure all my servers, no matter where they're running, Azure or out of Azure, are being monitored by Azure Monitor. And as we mentioned earlier, Azure Monitor is kind of the gateway to a lot of different tools in Azure. Now, you'll get your update status from Azure Monitor. You can enable Azure Defender for servers that reads the data from there, Sentinel to go query across your security events. And so this one has policies here that says, hey, look, my, you know, Windows ARC machines and also my Linux ones need to have the Log Analytics agent deployed. And so what it's doing is it's actually checking the metadata on the server and it says, hey, do you have that Log Analytics extension deployed? And that tells us whether or not the agent's installed. And if not, it will actually go and trigger a deployment for you so that you can automatically have these machines onboarded to that agent with a standard configuration that's set in the policy. So you don't, nobody has to actually know the workspace ID and the onboarding key. That's just part of the policy. And it will automatically go ahead and push that out to the servers. If you find a server that for whatever reason someone went and uninstalled that extension and it shows up as non-compliant, you can just create a remediation task and you don't have to worry about what it's doing. Because like, hey, I'm non-compliant, I don't know why. Can you fix that for me? And since it's modifying the Azure resource, it's able to go and just say, oh yeah, I'll just go deploy the extension again and bring you back into compliance. Okay, that is cool because so that does, like if I understand that correctly, I could also like set that policy, let's say on a resource group level or let's say on a subscription level. And so as soon as I join a new ARC enabled server to that specific resource group or subscription, it will then like have a look at that policy at one point and then it will say, hey, you need to have that Azure monitor extension enabled and then it will just like enable that. You got it. Okay. And that's a great point because since this affects any brand new server you onboard, you can really define a lot of the configuration of the server through policy. So the ones we've been talking about so far are built-in policies, but you can also, as I mentioned, write your own custom policies. And so I wanna talk about a really cool one that I created for this demo here, which is to leverage the Azure Key Vault extension, which is able to go and synchronize certificates from a Key Vault in Azure to your server. So on Windows that puts it in a cert store on Linux, it drops it to a well-known directory or you can change the directory if you have a preferred one and use this to help simplify that certificate management. So we have a policy to go say, hey, you got stuff expiring, but we also have the tools to enable you to prevent that from happening. So the idea here is let's make Key Vault the central place where we manage the certs. It's nice and secure. The agent, which is again deployed as an extension, leverages the unique Azure Active Directory managed identity of that server to go reach out to Key Vault and grab the certificates that you asked to be synced to that server. So you have a nice secure end-to-end connection. Key Vault still has access policies that control which arch servers can actually request and use those certificates. But this policy here is written kind of from the, more like a DevOps perspective. So I said, when I define this policy, find me arch servers that have a specific tag and if they have that tag, go and deploy these certificates. So let me go look at the assignment here. So I'm doing a web app in this demo. So I wanna make sure that my TLS certificates are being sent down. So my parameters are very simple. Hey, what are the certificates we need to sync? You can provide more than one, they don't have to be in the same Key Vault. And what tag are we gonna use to decide for automatic deployment? So I said certs and config and a www.prod is the value. And so that means we back out of here and look at this server. I applied that tag to this machine because that's the role of this machine. It's a front-end web server. It needs to have that config. And so the policy said, ah, yes, this is an arch server. It's running Windows, it's got that tag. I need to go and deploy that Key Vault extension. So you'll see here, it did deploy that extension. And if we were to sign into that server, you would see in the certificate store that the certificate I specified is being synced down. Now the extension is gonna keep checking every hour if that certificate and Key Vault has been updated. So I have a very short exploration policy on this certificate. It's only every month. And Key Vault of course has its capability to automatically renew certificates with your CA. So you can kind of imagine a beautiful world where Key Vault is every 20, 25 days going and actually renewing the certificate. The agent installed on the arch server detects that change, syncs it down. And if you're using an app that's leveraging the app channel to bind to those certificates, they'll actually be notified that the certificate was updated and can rebind to the new version of it without rebooting. So it's kind of a seamless end-to-end certificate management experience that's all handled here. And in case something were to go terribly wrong, well, you have this other audit policy to go and check if you have any certificates that are at the exploration window of where you need to potentially take manual action. Okay, that is really, really cool. I like you showed like this is something I want now and I will definitely try this out like immediately after that session. So what I also like is so two other things I want to add, I mean, like except for having that solution. So you're using instead of just using like a policy assigned to a subscription or a management group or a resource group. You're also using like tags to actually filter and say, okay, this server should have it. This one doesn't need it. So that means I could actually have a server which doesn't have that tag. And for some reason, like in a month or so, I suddenly think, okay, I need that. Like that server needs the certificates as well. Then I would just add that tag or modify the tag depending on how the setup is. And it would go out and suddenly have that policy and get like that certificate. Exactly, yeah. And you could even have different values on it. So like this is the production server. If you had a dev test one, you could have a different certificate sink down. And if the role of that server changed over time, just change the tag. It'll trigger policy to reevaluate and it will go and push down the changes. Okay. And the other thing you just highlighted was also like you spoke about it before, the managed identity part. So that means it uses the managed identity from that server. So it obviously goes now out and renews all the time and has access to the keyboard. But if I decide that that server is like for somehow not used anymore or whatever, or like does not belong to my organization for some reason anymore, I would just go out and remove it from ARC for example. And at that moment, my guess is it will not have access to the keyboard anymore, right? Yeah, you got it. If you were to delete the ARC server representation, it would lose access to that certificate. Or if you found out that server was compromised, you can just go to Key Vault and remove access. It's that easy. It's not like someone can just go add the tag and suddenly they're getting access to whatever they want. You know, there's checks and balances in place through the whole Azure authorization stack. Okay, no, that's cool. Awesome. So let's talk about a few other features that kind of light up in this portal here for ARC servers. Everything I show you is going to be for a single server view, but there's always an equivalent multi-server view. So keep that in mind because if you're in that higher level central IT role looking across the organization, the same data is going to be available to you for all the machines in one view. So security Azure Defender for servers, this is obviously a huge focus of Microsoft, making sure that we enable the best security experiences for your on-premises and cloud resources. You know, we've always offered Azure Security Center for on-premises machines. And we're excited to say that when you use Azure Security Center Azure Defender for servers with an ARC server, you actually get a little bit more value for your money because one of the capabilities that is included with Azure Defender is the vulnerability assessment solution. And so that is going, and if you were actually drill in here, when you look at your secure score for the machine and the recommendations available for it, some of these are gonna be something you can't pick up from logs. So things like, hey, you're running Adobe Flash, that's not good, that's no longer supported. And other OS settings that just need to be checked by an additional tool. Well, a license for the vulnerability assessment solutions included with Azure Security Center, but we didn't have a way to push it down to on-prem machines before because it's deployed as an extension. But if you arc enable the server, well, now extensions work. So you'll actually be able to start getting more insights into the security of your on-prem machines just because it's arc enabled, because we're able to push down that vulnerability assessment solution. And it's really easy to, one of the things, we showed you a fully set up machine, but if we look at this second server here, this is just a Linux server I've got that I haven't yet onboarded to it. Recommendations show up in the portal just like they would for an Azure VM. And so you'll see here, look, this machine doesn't have a vulnerability assessment solution installed. Of course, you could automate this with policy, but if you're doing one-off stuff, you can just click here and go remediate and be like, oh, well, what do I need to do to be better and assess my machine with more details? Oh, I just need to deploy the scanner, click proceed, off you go. And behind the scenes, what this is doing is it's going and deploying an extension. So that was really easy. And now in a couple hours, I'll have more information about the security of my servers on right here on that security tab. All right, that was super easy. I like when the security stuff is easy. That is a good thing. Not always the case, but we try our best. Awesome. So, you know, other things that work on-prem and these are all optional services. So when you think about ARC itself is the connection to Azure and the ability to see it in the portal to tag it and deploy extensions. Everything else I'm showing is an optional service that you can choose to use or if you have something else already in place, that's fine. You can try it out if you want or you can just ignore it. That's also totally valid. And so, you know, going down the list here of things that we highlight, you know, update management is a great tool to keep track of which updates are missing on your systems. You know, you'd be able to see the current status from the Windows Update client or your Linux package manager. We honor, you know, the, if you're connected to WSUS for Windows or custom package repository on Linux, we'll make sure that we obey that and only show you those updates which you can install from your configured sources. And, you know, you can go and actually say, look, I'm way out of date. I need to go get my January update pushed out. And you can go and schedule those. You can do it one-off. You can do a regular update. So if you want to set up like Sunday 1 a.m. schedule, you can configure whether or not we reboot it. And of course, you can pick and choose exactly which updates you want to go and push out. One of the nicest things about update management is this pre and post script feature. So if your app needs some TLC before it goes and gets rebooted or after you reboot the system, you know, you need to make sure that it's actually running correctly. Well, you can actually specify scripts that will be executed before and after the update starts so that you can make sure that your application comes back online and as expected. So that's a pre capability of Azure for both hybrid and Azure machines. So definitely recommend taking a look at this, even if it's just to get insights on which updates are missing across all your machines. You know, if you go to the multi machine view, you would be able to see all the updates missing across your enterprise and how many of your machines are missing each of those updates. So it makes it really easy to get that organization wide view of your updates status. Oh wow, okay. So this is like, this is obviously now also the place where I would do like, like obviously, like if I have one server I want to update, I would do it like directly from the one single view we have there. But here I would actually see all my servers and that's also where I would schedule probably updates to a group of servers to make sure that they are up to date. And I also saw that you were able to not just say update now but also schedule it. I guess you can also make it a recurring task, right? What I also think, and that is like, can you repeat that? Did you say this is free for Azure and Azure like on-prem or Azure Arc machines? It is, yes. So update management is just included with your Azure subscription. You know, when you enable it, you do have to deploy the log analytics agent that's where it collects its data from. But they have an included quota for that log analytics data to say, look, update data doesn't take a ton of space. So we'll give you some free quotas so that we can go and collect that information, analyze it and present it back to you. If you want to stay up to date, that's very important for us. We want to make sure we give you the tools to be as secure as you can be. Yeah, oh wow, this is awesome. You cannot imagine how many customers I have seen, like building their update orchestration and tools and to manage all these updates in their environment. And now you're telling me basically, I can use that like the Azure Update Management, which I use for my Azure VMs. I can use that on-prem and it don't even pay anything for it. So I like just, yeah. This is a great tool now to use. Definitely. Well, cool. So kind of in the same vein, we see a lot of customers using the tags on Arc servers as like a basic level of inventory. Some of them are using it to supplement their CMDBs. Others have an existing tag governance strategy for Azure stuff that now they can start applying to on-prem as well. But in addition to tagging, kind of the, I want to say physical server, even though it might be virtual, but like the existence of a machine somewhere, you can also enable a software asset inventory tracking. And so there's an optional solution available in Azure Automation that goes and keeps track of all the software you've got installed across your machines. And you can optionally even keep track of changes over time. By default, we're looking at packages on Windows and Linux and what services or demons are running. You can also ask us to monitor specific files for changes or on Windows registry keys. And this is great because if you're trying to figure out your update strategy for things that don't come from Microsoft, like your line of business apps. Well, if we have your version data, then you can actually write a query in Log Analytics and say, hey, find me, everyone who's running our internal HR app that's not running the latest version. And you can actually do that all from Azure and then you can use that information to help build your update strategy and perhaps migration strategy based on the workloads and features you're looking for. So yeah, I think there's a lot of insight you can get from being able to see what is actually running in your enterprise. Yeah, yeah, definitely very handy. Like again, like same thing as I mentioned before, like obviously when we speak about these management technology, we usually think about things which will actually take actions. But even getting these insights like inventory data, like the server exists, we know what operating system it's running on. We know what the update level is and now also knowing, okay, what applications are actually installed on that machine or like let's say, if you look at multiple machines in my environment, I think that is absolutely fantastic to get that overview. And now I basically with Azure Arc and I get it for my Azure VMs, I get it for my on-prem VMs in my home data center, I get it for VMs running in my branch office, my factories, my retail stores, or even at all the cloud providers, right? So I have like that one, like the single control plane to see all of that. And I think even just without having these actions like update management and policy and all that, which is absolutely awesome. Just even having the view, I think like getting the inventory, I think that is what a lot of people are or customers are looking for. And then if you give him also the additional features again, then to also take action, I think that that is super cool. Definitely. And you know, the other thing, as I mentioned before about right here, the beauty of having an Arc interface in the portal is if you're the admin of this machine, you didn't have to go filter for any of this. We did all that for you because all the logs we upload get annotated with the resource ID. So we just know that all of this information is relevant for this particular server even if for some reason you had two servers with the same computer name. So we're really helping make unique identifiers for this data so that we give you the most accurate information every time. Awesome. And you know, kind of on that vein, when we talk about log data in general, having that resource ID also unlocks resource context log access. So if you're thinking about how do I give my server the access to the logs we collect on their machines? For hybrid machines, it used to have to be that you would give access to all of the logs that you collect across the log analytics workspace. And that's because again, we didn't have a way for you to say like, only these four machines get access because we didn't have an identifier for these hybrid machines. We just had computer names. But when you have Arc installed log analytics agent checks, the instance metadata service API running on the Arc agent. And says, hey, do we have Arc resource ID? And we'll reply and say, yes, we do. Here it is. And they'll just go in and attach that to all the logs they send up. And so, you know, if I just do heartbeat from the log analytics agent, if we go and take a look, you'll see here, you're gonna get the computer name which could be shared across multiple machines, but we keep scrolling down and you'll see, here's the resource ID. This is how we know it's related to this machine. And therefore, if you enable resource context log access on the log analytics workspace, folks who have the right permission on this server can get access to see their logs and only their logs. They don't have to get access to everything. Okay, this is huge because this was exactly one of the questions I had was the role-based access stuff. I mean, you showed me this, you showed me multiple, like how do I manage multiple machines? But then having access to that specific machine. And my question really was like, for Azure resources, I have a role-based access. And so it looks like, I also have role-based access for the Arc machine. So I could say, hey, SharePoint admins, you only see your SharePoint applications or your servers running like SharePoint and I would limit that for that view. And with that, they would also just have access to the log analytics data which they should see and not more. Yep, you got it. Yeah, and that's a great point. I should talk about how role-based access can for all effects in Arc server. So just like any other ARM resource, we have role-based access control that you can go and assign roles to it. We have built-in roles for, here's like the onboarding role who's allowed to go and actually create these machines in your resource group. And we also have like an administrator of Arc servers. But the most important part is this controls access to the metadata in Azure. It is not changing who can actually log-in to the server on-prem. So it's two different sets of authorization checks. You have your existing local users and groups that control access to RDP and SSH into that machine. And this is separate for that management at scale from the Azure world. So if those two roles don't perfectly align, that's totally fine. You can enable that because there are two different implementations. So in theory, I could like, okay. So I could give like administrator and tell them, basically you don't even need the like, let's say Windows access or Linux access on that machine. You just go through the Azure like management experience. You have access to that. Of course they could obviously then probably run and like decide state configuration and add users and get access. But if, for example, that would work if they would like, let's say network-wise, they will not have access to that machine directly. They could go over the Azure experience and actually manage that server. Okay, that is cool. Yep. Definitely. And there's also cases where, you know, if you're hosting an app on behalf of another business group or a customer, you might give them view-only access in the portal and no access on the network. That's totally valid as well. That makes sense. Yeah. And also like, to be honest, I don't like locking into servers. Don't get me wrong. I like servers and all that and doing that. But like, if I need to manage like a large set of servers, I'm just happy if I can do that centralized one place and just go out and run the script or press a button or whatever it is and actually enable that for every server I want to. I'm not needing to like RTP into that server or SSH into that server and run something. So I think that is really cool, really helpful. Definitely. Well, awesome. I just have one last thing I wanna show. This is the insights experience. So this is an optional add-on to Azure Monitor that's gonna go and give you some better analysis of the performance counters of your machine and network connections that machine has both incoming and outgoing. So while this is a web server, you would normally expect a lot of things coming in. This is my demo web server. So I apologize, I didn't fully set up inbound connections because I don't browse my demo site often. But you'll see here, my server has 29 unique processes which are making network connections out to other servers and it groups it by the ports they're talking to and as red line indicates that this was unsuccessful and that's because I blocked unauthenticated HTTP out of this machine. And if you have multiple servers talking to each other, you kind of build a graph here. So you can go and figure out like, hey, we wanna go decommission this server over there. Is that okay that they would talk to the server? And the dependency graph here kind of helps you build out understanding of who is communicating with that machine. Yeah, very useful. Also very useful for migration scenarios and stuff like that. So like for example, if you wanna move, like if you wanna migrate servers and you wanna like, you obviously don't wanna migrate an application server which still needs to then talk probably to the on-prem environment. Then you have all that traffic going back and forth. You probably wanna move both machines at the same time. So this is also a very helpful view, I guess. Definitely. And another great feature is, you know, the performance counters so you can keep track of your disk usage, CPU memory over time. So if you get an incident, someone says, hey, my server's running slowly. Well, you don't have to sign in again. You can just go here and look at the historical data and say, ah, well, maybe there was a spike at one point. Or if you know you're running like a cluster of servers, again, that multi machine view helps a lot. So if we head over here to the insights experience, now we're seeing all of my servers in the same resource groups. I've got front end, middle tier and database. And you can see their utilization across all of them. You could also, since this is being stored as log data, you could write an Azure alert on this. So you could say, hey, shoot me a mail or call this web hook if we find a server that keeps having errors in some sort or is running out of disk space and then being able to go act on that information when you get those alerts. Nice, nice. Well, cool. So that is the end of my demo here in the portal. Again, this is, we're living in a single machine. ARC is really designed for the, at scale, long-term configuration of your servers. It's not necessarily here for your day-to-day troubleshooting of an individual machine. It's really designed to help make sure that machine is monitored. It's governed with policy. It's got the right agents installed to enable that monitoring governance. And of course, from the inventory perspective, being able to go and tag it and find it alongside all of your resources that you have in Azure. Okay, that is really cool. You know, I really love what I see here. And one thing I also want to mention now, obviously you mentioned now, we looked at this and all in the portal, right? We used the portal to manage all that. But since, I guess, since this is a resource manager, this would also work like some of the features work we're using templates and like using the APIs and stuff like that. Definitely, yeah. So we have PowerShell, we have Command Line, ARM templates work as well. The only thing a little different about us is since, you know, we require that agent to be on-prem and establish the connection from the server to Azure. Whereas like in Azure VM, you can go and write a template to say, hey, go make me a server. We can't really make your existing server on-prem, but it's already there. So the creation of an ARC server is always going to originate from our agent. And that is that script I showed earlier, where it's going to go and say, connect me to Azure to this subscription resource group using this identity. Awesome, awesome. No, this is perfect. This is, thank you very much for that demo. That was a lot of stuff I just learned here. And so that's awesome. Definitely. So one question I have is now I saw all of that and like I also want to try out things now. I really want to figure out, okay, what I'm going to do. What do you recommend? Where do I go? Yeah, so we have a lot of good resources for you. Starting, of course, with our docs, there is a Microsoft Learn module as well for Azure ARC. So you'll have a quick intro to all of the ARC products that are currently available. Azure ARC-enabled servers is generally available. We also have ARC-enabled Kubernetes currently in preview as well as ARC-enabled data services. I'm going to talk about data services today, but I believe we've got another session coming up to talk more in depth about how we're bringing some of the best of Azure's managed database products on-premises with Azure ARC. Then after Learn, when you're ready to get your hands dirty and start playing around, we have a great site called the Azure ARC Jumpstart. And this is a collection of scenarios that are based on real-world experience that we saw from customers during our preview as well as what we keep hearing from folks who are actively using it. And it's meant to be very practical, ready-to-go examples. So if we head over to the Jumpstart scenarios here, you can filter by your ARC product. So if we go to ARC servers, it has everything from onboarding. And this includes both easy onboarding, like I showed you, as well as, hey, how do we automate onboarding for something like AWS or VMware, where there's perhaps other tooling that's available to simplify the running of that script on your machines, as well as kind of going down and looking at specific use cases of Azure ARC and what you might want to configure like monitoring. And so these include ARM templates that go and set everything up for you if you don't have anything pre-built as well as written guidance for each of the scenarios in case you want to do it yourself and just understand what are we encouraging you to do in this kind of scenario. Okay, that is pretty cool because I mean, I want to try things out. That is actually a good place to get actually started and helps me really, really quickly set things up and try things and actually get my own demo environment basically up and running. No, that's cool. Yeah, we would definitely put the links for this in the description below. So people, if you want to actually go out, check out the links underneath this video and you will have the links to the log module documentation and jumpstart as well. So Ryan, do you have any more things you want to show us or talk about? Not today. I think this was a really great intro to kind of the architecture and capabilities of Azure ARC. Next step I think is really just try it out. Azure ARC enabled servers itself is free. You only pay for the optional services that you choose to use with it, like the storage of log data. So I definitely encourage you to go out, install on your server and see what kind of experiences you can build with it. No, this is awesome. No, Ryan, thank you very much for being in this session. I really have learned a lot of interesting things. I've really a good view on some of the deep dive stuff we do with Azure ARC enabled servers. And so thank you very much for joining. For the viewers here, if you want to learn more, obviously, as I mentioned, we have the link into the description of this video. If you want to watch more videos from our ITOps talks hybrid event, check out aka.ms slash ITOps talks and you will find more sessions, as you mentioned, like when it comes to Azure ARC, data services, Azure Stack HCI, AKS and Azure Stack HCI, Windows Server related sessions. We have much, much more there. So please check it out and hopefully see you in the next session.