Welcome to episode 349 of the Microsoft Cloud IT Pro Podcast recorded live on August 18th, 2023. This is a show about Microsoft 365 and Azure from the perspective of it pros and end users where we discuss a topic or recent news and how it relates to you today. Ben and Scott talked through some considerations when using Azure policy to enable diagnostic settings at scale. They discussed various tools, oddities, permissions and more to help you get your environment configured the way you
want even quicker. Ben, the button. Clicker stitching . There you go. That's it. We just kinda started talking and didn't bother hitting record buttons today. Now we're all recording. That's what we were waiting for Pirate. We were waiting for us to click the record buttons . All right, now that we got that out of the. Way, now that we got that out of the way, are we gonna talk about clicking more buttons? We are going to talk about how to get away from clicking buttons
and having the system do the work for you. Once you, now you might have to click a few buttons. You still. Have to click buttons. Does the energy count as a button? Click. Unless you don't have the permissions to not click the buttons and you still have to click a big bunch of buttons to avoid clicking buttons. A button, click here a button, click there a button, click everywhere. This is spiraling downhill. Quickly, Scott, maybe we should just start talking about diagnostic settings.
Should we talk about diagnostic settings and Azure policies and monitoring things in Asher ? Joey said if I were a professional wrestler, the button clicker would be my nickname. I wonder how that would go in professional wrestling. Like I feel like there could be some, I don't know, some unique inferences drawn from a wrestler called the button Clicker. Yeah, I, I don't know. , I mean Stone Cold had the stunner. You know, we'd have to think about what your move is gonna be.
I can't think of anything that's uh, safe for work . I was just thinking, I was like, yeah, we're just not even gonna go where that secret special button clicker move. What? That would be Okay, enough with button clicking. Do you wanna talk about diagnostic settings and Azure policies and initiatives today? Scott? So you've been doing some fun stuff here and there were a couple things
we were chatting earlier this week to kind of prepare. I, there's, there's like some new stuff in just initiatives and policies when it comes to discovery that like I wasn't aware of. So I think there's some cool new things kind of going on out there. And I run into this one a lot. I see a lot of customers who want to take action in their environments.
Like they have some type of proactive action, they want to take on a bunch of resources at once and they don't always know that policy exists or they don't know that these types of settings are available to them and they potentially run into issues in other places. Like practical example, I, I was having a conversation with somebody and they have hundreds of storage accounts and these storage accounts are managed in Terraform. Okay great. Like we've got this whole ecosystem for doing that.
But one of the things that they run into is the way the Terraform provider for Azure is currently written. It's not too great when it encounters throttling in the management plane. So one of the considerations for customers is like, hey, I have N resources that I need to manage. And one of the things that you need to think about is the types of operations that you fire off against ARM and the specific resource providers.
'cause there's like limits for Arm and then there could be other specific limits within a resource provider like compute, storage, networking, all those kinds of things. And sometimes this external tooling, like it just doesn't deal too well with say like an HT P 4 29 and you should just kind of hang out and retry this request a little bit later.
Like if you're trying to manage say a thousand resources in your subscription and you know, whatever the limit is, it's like oh you can make 500 read requests or 800 read requests every five minutes. You can't even do the read requests for the thousand resources at once, right? Like you have to have these long running processes that kind of come back and figure these things out.
So I've been kind of trying to have conversations with folks and and steer them in different directions like, hey, like Terraform might be really good for what you want it to do here, but it's only really good when you have 10 of these things. It might not be good when you have hundreds or thousands because of these constraints. And let's be clear, like there are constraints, right?
There are limits that are that are there in arm and you know, maybe there's a different way for you to do it and you know, maybe you do think about things like policy instead of having all these things managed in like Terraform Plan and policy can just run remediation tasks in the background. And it's not that it's performing different activities, it's performing different activities at the same scale. Like hey I need to manage the same number of resources but in a slightly
different way. Like listing can be different. Even like application of policy, like practical effect. Like okay, I have a policy that's in an initiative that you know, potentially alters a bunch of resources with like D N E employee if not exists kinds of configurations on them. So I thought it was a good one to talk about 'cause I didn't even realize that maybe Microsoft had started to publish some guidance out here.
Like you pointed me to this nifty article about creating diagnostic settings at scale using Azure policy and initiatives. It was interesting, like I found that and then when we were talking about this earlier, you also pointed me to the GitHub repo. But kinda where this started coming up for me was a client we're working on, and it ties into our conversation last week, two weeks ago, I'm trying to remember where we started talking about Sentinel. The defender stuff. Yeah.
Yes. Defender Sentinel. And for me it was, hey we have all these resources out there already. Now we wanna start onboarding Sentinel and we wanna start pushing all these logs into Sentinel. And really Sentinel relies very heavily for a lot of these resources on these policies and on the well not on policies, on diagnostic settings coming from these resources.
And when you actually go into Sentinel and you go into what's now the content hub, new feature in Sentinel, instead of going into connectors, you deploy these solutions. They include all the different connectors,
workbooks, analytics rules, all of that. But a lot of these different resources, storage accounts, SQL databases, app services, when you go in and click on the connector, really all the connector is for all of these is just go set this Azure policy to go enable this diagnostic logging and send it to the log analytics workspace that is associated with your Sentinel instance or the di the diagnostic, the log analytics workspace Sentinel is installed into.
'cause really Sentinel isn't its own resource. It doesn't even show up in a resource group, it just gets added into log analytics. So that's where I kinda started with all these policies was, okay, I have all these storage accounts, I have app services, I have SQL servers and the button click reference. I don't want to go click through every single one of these and go set up policies for all of the, or go manually enable diagnostic logging.
This ended up leading me down a completely different rabbit hole. But these policy definitions in this PowerShell script you I pointed you to that we came up with was really out of this. I went and installed all these connectors that were out of the box but I ran across a lot of resources in Azure that don't necessarily have a built-in policy for diagnostic logging. And I wanted policies for some of these other resources.
And this article kind of points you to, there's this PowerShell script out there and if you have the AZ module, the Azure module for PowerShell installed, you can go install this script and you really run a very basic command. And this is where I should actually have the PowerShell script in front of me and I have lost it. You install the script, create AZ diag policy and once you install this script you can go run create AZ policy PSS one and add a parameter onto it. That's export la.
If you want a policy that exports these diagnostic policies into log analytics, you can do a export eh for event hub export directory to export them to or no export directories where you want these policies to get exported to. And you can add additional parameters in here if you wanna point it to a specific subscription id, a specific resource type, all of that. Or the other option is that's really nifty is you go just do create az diag policy.ps one dash export la which is what I did.
And then it actually enumerates all of your subscriptions that you have access to. You obviously have to log into Azure and it says go type in number one through 23 for each one of your subscriptions. So it gives you a whole numbered list of subscriptions. So instead of having to find the subscription, ID copy and paste that you just type in like 16, that's a subscription I want.
After you type in the subscription, it goes in and enumerates all of your resources within that subscription and you get the same type of thing, a very numerical list of one through 50, one through 75. You obviously have to make sure your buffer's big enough on your command line that you can see everything, but it's all of the different resource types that are in that
particular subscription and same type of thing. You hit, I don't know, resource type number five for Azure data factory or something.
And it goes through and look figures out, looks at the arm template, I don't know what it actually looks at, but says here's all the diagnostic settings that are on this particular resource type and spits out the J s O files to define the Azure policy for that specific resource type truth be told, you can go grab all that Jason and just copy and paste it right into creating
new Azure policy. And it works. I actually found it was a little, I did not like what it generated, it generated some extra parameters like every single one. One of the parameters was the location that you wanna limit creating resources in. And I was like, this is policy, I don't, I want diagnostic logs, I don't care about the location. I. Gotta stop you for a second. Okay. So I didn't realize I, oh my gosh, like this was one of the first things I worked on when I joined Azure Storage.
So I went and looked at the GI repo for this project. Yeah, I'm looking at who, who wrote it. So the gentleman's name is Jim Britt, he's awesome. But basically what this thing does is it reaches out to the arm APIs and then it performs dynamic discovery of what diagnostic settings are available on that resource. So one of the things that I worked with him on on this particular project was there are resource types in Azure that present
via arm that aren't all the way arm resources . So, uh, one of the biggest areas like uh, that I'm aware of is storage. So in storage we have this concept of proxy services. So when you create a storage account, a storage account has blob, it has d f s files, tables queues, and uh, a web endpoint, right? Like every single storage account has those endpoints.
If you've ever actually like dug into arm like and these diagnostic settings, when you deploy a diagnostic setting for a storage account, in many cases you're not actually deploying it at the parent storage account resource level, you're deploying it at the proxy service. So what happens is you end up with, you know, an arm management u R I that goes like, you know, forward slash resource groups resource name blah blah blah, Microsoft storage and your account name.
And then if you wanna do blob diagnostics you have to append forward slash default services forward slash blob if you wanna work with files forward slash default services forward slash files. And it's, it's weird because you can't perform this dynamic discovery because like ARM isn't really aware of the proxy resource which is is the challenge, which is why you don't see like your blob endpoint in resource graph. You only see your parent storage account basically like you see like the parent
resource but not any child or proxy resources that are after it. Like oh man, this is bringing back nightmares for me. I remember this is a gnarly problem . So yeah with that and same thing like the policy it spit out, it's great, it gives you a lot of details and for me the biggest thing that it gave me was all the different diagnostic settings that you could do.
So what I actually did is I used this to kind of enumerate what are those properties behind the scenes for the different check boxes that you check in diagnostic logs. I want to monitor antivirus or H T T P calls or whatever that is. And I kind of took what this spit out along with going and looking at the definition of the default ones that Microsoft provided, like going and looking at an app services one or something and kind of merging the two of 'em together.
Just doing some quick copy and paste to make some modifications. I tweaked a few of the rules in terms of when that particular policy would apply. Specifically when you get into things like app services where technically a function is an app service but you don't want the same policy applied to a
function that you maybe wanna apply to an app service. So you have to, to put some of that logic in there to help determine when you have a function and the policy should apply versus when you have a web app that the policy should apply to. Yeah, but this at least for me was really valuable and being able to pull out different properties around diagnostic logging that I wanted to include in these custom policies I started building. It's.
A weird problem to solve. I don't Did you have a chance when you, so when you did this, like there's kind of two paths you can take. So one is take the policies like the definitions, parameter files, everything Yep. That create AZ diag policy spits out and then you can go off and apply that however you'd like, like you said,
like tweak it and do all that. There's actually, uh, the other part that goes along with this repo is there's scripts in there to trigger a policy evaluation and also trigger initiative remediations. Like did you have a chance to play around with those at all or did you just go down the other path? Did not. I just went down the other path and I don't know if you wanna go down the path of an issue I ran into with applying policies yet and remediation of these.
It's. Your show, we can go wherever we want. No, I already told you that earlier that it was your show . So I did it just for creating policies and this was a little bit of a weird scenario. So I'm curious Scott, have you ever, when you've done policies, not had anything but read access to the subscription and just had contribute access on the resource group and tried to do all of the policy stuff at the resource group level?
No, I'm a spoiled Brad. Every time I play around with policy, it's in some place where I'm effectively a deity at subscription. You know what? Let me tell you that makes it a whole lot easier . Turns out. Turns out. So there's a couple different things I ran into with this. I don't know which path I want to go on first. Let's go, let's keep going down this path since this is the one I started on. Turns out if you're a contributor you can't assign policies at the resource group level.
You need to have an additional permission and it'll tell you, I should have pulled up the article, I'll have to dig through it, we can throw it in the show notes. There's an additional permission level you need to be able to go in and actually create policies. And it's actually at the resource group, I think it was at the resource group level. I had to have them go in and grant me these additional permissions and then I was actually able to create policies that solved. My first problem was,
okay go grant me this permission level. Great, that's done. I can go create policies. So then I went in and created a remediation task. Guess what? Remediation tasks require managed identities. Uh, yes. And guess what you can't create in a resource group . It's a tough one. Like with, with all of these, right? Because the kind of boxed roles I think make some assumptions and
sometimes to make like overly broad assumptions, right? Like hey, we can potentially give you a little bit more than we when you need because we really do want you to be successful. So there's this weird line between lock it down too much and make it so hard nobody can do it and making it so easy that everybody can do it. Like maybe there's gotta be a little bit of friction in there. But policies an interesting one.
Like if you ever go and dig around in like Microsoft policy insights, there's everything from management actions to data actions. 'cause of course you have data plan operations as well as management plane kind. I like storage. It's another little bit of a confusing one to wrap your head around the first time if you're customizing it or trying to get into that. That's. What I was doing as I was trying to create these policies.
I wanted remediation tasks so I could actually leverage policies to go in and enable diagnostic logging because I had permission to do diagnostic logging and to go enable it. I had permission to create policies but because those policies required the management or the managed identity, I didn't have permissions to create managed identity. So I couldn't do a remediation task to turn on diagnostic logging.
The other thing kind of along these lines that I've found, and this is another interesting thing with policies, is if you've gone in and used these out of the box policies to go in and enable diagnostic logging, these policies have a parameter that defines the name of the diagnostic log that it wants to create. It's by default it's set. So it's a hidden parameter when you go in and create policies.
And if you create, and let's say this scenario we were talking about, maybe we have two different policies. One to go to this log analytics account for app insights and for kind of the developers to use. But then another log analytics for all the sentinel stuff to go into where
sentinel's kind of isolated. But if you go in and apply the same policy, they start fighting over each other because now you're trying to deploy the same policy with the same name on the same resource group to go to two different log analytics workspaces. So what I started doing with my custom policies is actually unh. And you could do this one of two ways.
You could go in and customize the out of the box policy so that that's not set to a default invisible and it makes you go in and define a value for the name or you can actually go in and click the checkbox to show all parameters, not just the required parameters. And then you go in and change the name and then if you deploy a policy one of these outta the box policies twice, but give it two different names, it'll actually set up that logging and diagnostic storage to log analytics workspace.
It'll set up or you can set it up to set up both of them so they don't start fighting over each other really. They can even end up overriding each other based on the order these policies get evaluated. So one will be compliant, one will be not compliant, it'll go in and fix it, the other one goes non-compliant and they just keep fighting back and forth because these diagnostic setting policies or these diagnostic
logging names set by policy have the same name. I. Wonder how much of that is like just by design, like it's not, it's meant to be purposely obfuscated, like the scenario that you're in. Like sure there's the functionality and like day-to-day aspect of it. Yep. And then there's the whole like just rationalizing cost piece of it. Like you're targeting multiple log analytics workspaces with the same dataset. Like there's a penalty there for paying to store those two times.
Yeah, and it's an interesting discussion and we started talking about this the other day too, is how do you, how do you manage this? So I think there's an article out there that's in preview around table level permissions for log analytics, but you also start thinking like your developers want some of this diagnostic logging, but then from a security perspective you don't really want your developers maybe seeing all of the Azure activity because Azure activity is a subscription.
You need subscription owner level access to deploy the Azure activity policy to ingest all of that data into Sentinel. Maybe you have things like Microsoft Defender for cloud coming into Sentinel and you're absolutely right in that there is definitely data getting ingested into log analytics that you end up paying for them twice.
But how do you set up log analytics and Sentinel in a singular workspace while limiting maybe what developers can get to or what people that are doing some app insight stuff, what they can get to, to architect it in a way that people only have access to what they need without paying for duplicate data within those log analytics environments. It's not an easy problem to solve .
That's where some of this started coming up, at least for me was in this case in particular, and this is the other thing to think about, in this case in particular, they had a dev resource group, a QA resource group and a prod resource group. They already had log analytics set up, they had all their app insights, all the logging, all the devs were used to it. And then they came in and said we wanna deploy Sentinel and
Defender. How should we do this? And it's like, well at this point in time now, do I deploy Sentinel to all those log analytics workspaces in each of the environments? Do I apply Sentinel at one outside of that? But then do like cross log analytics queries and do a bunch of joins and modify a bunch of the rules and the alert queries to kinda look at all these different log analytics workspaces.
I know there's a preview coming with Sentinel too, where you can kind of have a management sentinel instance and then have all these sub sentinel instances, but it doesn't work in that. It kind of pulls everything in. It's more let's make sure we're deploying the same alerts and workbooks and all of that from this parent Sentinel instance to all these child sentinel
instances managed. It just, it leads to a very interesting discussion about how do you architect this and make sure you are seeing all the relevant data, especially with something like Sentinel where you're maybe relying on some of those incident alerts and that type of stuff. That really does depend on a broad swath of data, uh, being within those scheduled queries that are running. It's tough. I I put a link in the chat and I'll have it in the show notes.
So it's one thing that I think the Sentinel team did a good job on. Like I'm sure they encountered this early on with customers that had this split between single-tenant, multi-tenant access control. You mentioned like table level security, there's maybe considerations like as log analytics improves its capabilities over time for table level retention and, and what that gets in there. There's a whole bunch of moving pieces and I don't know that
there's a whole bunch of good answers. , like you're probably bound by reg, you know, just pure regulation and like regulatory compliance. Like thinking about like having to split data because you're doing business in the US and eu, right? Like so you're company that's doing the global international thing, like the, you're gonna have those kinds of drivers in there that are gonna push you one way or the other, but you're gonna pay for all of it. . Yes.
Cost is, cost is gonna be a consideration for you. Which is, it's probably the roughest one of all these like I think you can given the capabilities in like custo today and all these data sources like resource graph monitor, so like Microsoft Insights, resource provider, Sentinel, like all these thing log analytics, like all of them being built on top of Custo as like an underlying data engine. Like it, it's been a lot easier with like cross cluster queries and all that kind of stuff.
Like I do things today where a lot of the time I don't even go to the Azure portal anymore to query things like there's end points that you can hit. I, I forget what they're off the top of my head. It's like ad dot log analytics do us or something like that for, for like GovCloud for log analytics.
But if you spin up like basically if you spin up a log analytics workspace, you can connect to that log analytics workspace just through default tooling like Custo explore and all that stuff from your desktop. So it makes it like a lot easier to frame your head around like the cross cluster query join and all those kinds of things. But it's, it's muddy. Yeah it really is. Do you feel overwhelmed by trying to manage your Office 365 environment?
Are you facing unexpected issues that disrupt your company's productivity? Intelligent is here to help much like you take your car to the mechanic that has specialized knowledge on how to best keep your car running Intelligent helps you with your Microsoft cloud environment because that's their expertise. Intelligent keeps up with the latest updates in the Microsoft cloud to help keep your business running smoothly and ahead of the curve.
Whether you are a small organization with just a few users up to an organization of several thousand employees they want to partner with you to implement and administer your Microsoft Cloud technology, visit them at intelligent.com/podcast. That's I N T E L L I G I N k.com/podcast for more information or to schedule a 30 minute call to get started with them today. Remember intelligent focuses on the Microsoft cloud so you can focus on your
business. Ken, to your point we started talking about this is could you set up Sentinel in a way where if you went in and started modifying some of those built-in queries and set all that up is could you set it up in a way that you could take advantage of all those other log analytics instances and start doing those cross log analytics queries within your sentinel rules and your sentinel alerts to set it up in a way where you aren't paying for that data twice and you're
able to figure out how to ingest it from all these different places. I think then the trick also comes in is going back to the policy thing. It's easy to set up policies that ingest everything into one resource group. Like you go put it at the tenant root group, right? And maybe you say all of my storage accounts or if you're depending on how you're doing your management groups, you have it set up.
But now if you start doing different log analytics for various subscriptions or resource groups, how do you know when a new log analytics instance gets spun up that you need to go now add to all these cross log analytics queries. This feels like it could be a whole project in and of itself that I don't have time for . Yeah, it takes you back down, it's back down the rabbit hole. Yeah. The other thing that I found out, this is a little, it's still policy related.
The other thing I found out in going through all of this was, okay I can't set up policies without subscription level permissions is do I set up these policies in a way that now I can just report on, get a compliance report, do I have this particular policy added to all of these different resources? Are they sending to the right log analytics workspace for Sentinel? Do they have the right name? All of this stuff because now I am doing some click, click, click.
It wasn't enough resources that I went in and scripted it all out but I wanted to make sure everything was set up the right way. Come to find out while doing the deploy, if not exist works great if you change the name. If you just look for the right setting in the policy to report on compliance or not and you have multiple diagnostic policies in there, it doesn't look at all of them and it doesn't say okay this is one of the three in there so it's compliant.
It like looks at the first one and says, uh, no that diagnostic setting isn't configured to go to the right resource group. So this resource is now not in non-compliant with your policy but when in fact it was in this case it was the third one in the list of where these diagnostic settings were going. So it was compliant but these policies weren't able to evaluate all of those settings on those particular resources. Yeah.
I wonder if you can back to the resource graph thing if you can make your life a little easier. So policy, so things in Microsoft dot policy insights, like that resource type, they bubble up into resource graph and you can actually see compliant and noncompliance state in there. So I wonder if you could craft 'cause 'cause you can. So the other thing you can do is resource graph queries can be fired off via like C L I or PowerShell and then you can bring 'em back and parse 'em however you want.
So I wonder if you could have this kind of like hodgepodge of like say like Azure PowerShell fire off a call to resource graph for this query and then based on that query output, figure out like where the deficiencies are and then actually go query those resources natively using like Azure, PowerShell diagnostics commandlets and then figure out like what the true and and meaningful state of them is.
Yeah, I may have to go explore some of that. And again, this whole working through all of this in this particular case was just fascinating because like you, I've always been at that level before where it's like we want you to come in and help us with all this stuff here. We'll just make you a subscription owner, a subscription, even a subscription contributor so you can actually see some of this stuff.
And I, I felt like I was very much working with one hand tied behind my back in this case in terms of what I was able to get to, what I was able to see, what I was able to access. Like in this case I even saw places these diagnostic logs were getting sent to. I didn't know where they were going or what they were for. Like there were these settings and it was going off somewhere.
So I was like okay, I have to be careful not to mess with these because , if I delete one, I can't even go in and fix it because I don't have access to the log analytics workspace it's going to or wherever it was getting shipped off to to go set it back up again.
It's the joy of being a consultant sometimes I can't say I miss those days where like you , I I that that struggle of walking into a customer and saying like, hey uh, we've got the s, you've signed it off like and I'm ready to do the work by the way I need you to do this, this and this and this for me because you didn't give me the ability to do it myself. And then they kind of come back and look at you and they go, wait,
I'm paying you for what? , oh you're paying me 'cause you made it harder to . Yeah. To get out along the way here. So. It's been interesting. There's a whole nother rabbit hole we could go down to around the deploy if not exists. But we should probably wrap it up unless you want me to bring up this last one. Is. It a quick one? Because we can, we can actually like close out the whole thing at. Once. Okay. So let's close out the whole thing with this.
So here's the last interesting thing I found. We've talked all about policies, right? And deploying these diagnostic settings. What if you wanna make these an initiative and you don't want to go in and apply 10 policies and go set deploy if not exist and you wanna wrap it up as one initiative that has all your policies for all your diagnostic settings but you also need a deploy if not exists on those. It gets really you. Struggle a little bit uh. You do.
'cause you can only set one deploy if not exist when you set up the initiative. So you kind of guess which one it is because the other thing that ended up, and I haven't gone back in to figure out if there's a way around this, all the deploy if not exist for policies have the exact same name in it.
So you like put 10 of these policies in there, go to deploy if not exist and click the dropdown for what you wanna do and you get a list of 10 things all with the exact same name , you pick one and you deploy it after the fact. You can go in and start going through this list and you can actually add all the rest of the deploy if not exists. So there is a way to do it through that policy or through that initiative.
But it's the same thing where now as you're going through and like adding another remediation, add this deploy if not exist, add this one, add this one, add this one. Yeah. Trying to keep track of which ones you've deployed. I don't know like if you could go into the policy definitions for all of these create custom ones. I think you can, you could go in and actually rename those deploy if not exist to something meaningful within these policies. You.
Should be able to, like the D N A task is like that's fixed. That's part of the schema and the, and the j ss o n for the definition, but the name should be fungible. Yeah for that particular like d n a task inside that given like definition, but Right. It's not the easiest thing to like figure out . Yeah. 'cause now you're going in and instead of just using all these policies that are built in, you're having to go in and create custom versions of all of these.
Again, big enough environment, it might be worth it to go in and figure all of those out. But there are definitely some challenges that I have run into in this case when it comes to policies and initiatives and diagnostic settings and permissions and duplicate policies. But it's been interesting to dive into some of these policies specifically around diagnostic settings this much. Have you ever seen or tried, there's a project out there, Julian Hayward maintains.
So he did some of the uh, arm visualization stuff that I made initially eventually made its way into Lake vs code and all that. But there's a project out there that's called the, it's, it's basically the Azure governance visualizer. So it's back to PowerShell again. It's a PowerShell script that you can run and it spits out some HT m l it can also do like j ss, o N and C S V,
all that kind of stuff. But depending on how like you wanna visualize it, it actually goes and enumerates a given subscription or set of subscriptions. Like it can start at a management group scope and then walk that hierarchy all the way down to the bottom. So policy from the MG policy at the subscription group, scope pol at the subscription id, uh, subscription scope rather like at the subscription ID resource group. Like all that kind of stuff. So you just kind of walk it top to bottom.
And one of the cool things that it does, like, and, and this is where it might be interesting to you, is that it can, uh, it has a component called Definition Insights. So it actually walks like all the way down to that definition level and it tells you how things are applicable, how they're being configured. Like you might wanna check that one out. I'm gonna have to go check this out, Scott. It's on my list. I have not seen this before.
All sorts of fun stuff out there if you know where to look. Yes, absolutely. And the other thing, so to wrap it up also with resources, you also pointed me to another resource. We talked earlier about that PowerShell script and me going in and creating a bunch of my own policies. And then you pointed me to this GitHub repo with a whole bunch of policy definitions for monitoring that has a bunch of the ones in there that I already
created again. Yeah, I just did not know to look in the right spot. Two different ways to get the same results. The PowerShell was interesting for me just to gimme insight into it. But this is also a very handy GitHub repo to be aware of if you're working on policy definitions for. Anyone who's made it this far. Pro tip, this thing is called the Azure Community Policy repo. It's a GitHub repo. It's, it's out under the azure org. I'll, I'll put a link in the show notes.
But if you've ever looked at an Azure resource, like you're back at that resource type level and you're looking at the built-in definitions for policy and you're going like, huh, it really feels like it should be able to do this. Like this seems like a common thing that lots of people would ask for. Like why doesn't a built-in definition do that, do this yet?
It could be that we actually wrote the definition and it just hasn't made its way all the way over to like be an actual default definition in
the system yet. So I know for like me personally, like back to that stuff that I did with Jim Britt, like in the way back when I was pushing a lot of my policies that I was writing for him around the proxy services over to the community policy repo because it's a super quick, it's not even like a quick and dirty, it's just a super quick way for me to get policies out there that I know are gonna be helpful to a bunch of people while then we go work with service teams to get 'em integrated in and,
and where they need to be and all that good kind of stuff. So there's a whole bunch of services that are covered in that repo, like it's not just Azure Monitor, so things like diagnostics, storage, cosmos, db data lake, virtual machines, security centers in there, synapse is in there, tags, key vault, Kubernetes, all that could kind of stuff. So I'll, I'll put a link to that in the show notes as well 'cause it is a great and wonderful resource. Like usually my step is,
is there a built-in definition like or a built-in policy? Oh no, that doesn't exist off to community policy. And then if it's not in community policy, go and create it myself. Yes. Very cool. Well thanks Scott. Lots of good resources, lots of interesting stuff about policies and things to think about, but with that indeed. Always things to think about. I should go back to my midlife crisis, just debates of what I do with the rest of my life. What do I wanna do when I grow up? Scott? Nothing.
When you figure it out, come back and tell me what I wanna do when I grow up though. Alright, we just need to get like a thousand more members to the podcast and then we can, no, not a thousand. We need like 10,000 more members to the podcast and then we can retire. We're we're. We're not gonna get there. Yeah, no, those think, think unless those that are out there think we make money off membership. We don't make many money off membership.
We lose money on this sucker website hosting and editing and things every week is, uh, not an inconsequential amount, but yes, it's for the community. 'cause Ben's an M V P. I'm not an M V P, so I just do fun. But you just love community. Scott has a big heart for the community. , Sean says, I better consult Pirate says to monetize YouTube and Joey says to become a pro wrestler that is quite a wide swath of future endeavors for Ben. But.
I feel like if you did that, like you would be living that content creator lifestyle, right? Like every YouTuber that you like, not all of them are making you know enough to live off every year. Like some, some could be your barista at Starbucks, but in your case you can go be a wrestler. It all works out. There you go. I could monetize my YouTube or monetize on YouTube. My wrestling bouts as been the button pusher . Oh man, we gotta go, Scott, before. This on that note.
Yeah, on that note, let's call it a day. . Uh, thanks bud. All right. Thanks Scott. If you enjoyed the podcast, go leave us a five star rating in iTunes. It helps to get the word out so more it pros can learn about Office 365 and Azure. If you have any questions you want us to address on the show or feedback about the show, feel free to reach out via our website, Twitter, or Facebook. Thanks again for listening and have a great day.