[Episode 415 – Diving Into Ignite 2025 for IT Pros and AI Agent Management](/content/episode415/index.html)

Apps

Welcome to Episode 415 of the Microsoft Cloud IT Pro Podcast. Ben and Scott discuss the major announcements from Microsoft Ignite 2025, focusing on the dominant themes of AI agents and security. The conversation centers on three key areas: Security Copilot updates, Agent 365 for governance, and the broader security and management implications for IT professionals.

Key Discussion Topics

Security Copilot Expansion to E5 Customers
- 12 new Security Copilot agents coming to Defender, Entra, Intune, and Purview
- 30+ partner agents being added to the ecosystem
- Major announcement: Security Copilot will now be available to all Microsoft 365 E5 customers
- Rollout begins with Frontier program (Microsoft’s insider ring for Copilot)
- Expanding in coming months to all E5 customers
- Security Copilot spans four pillars:
  - Security Operations (Defender + Sentinel)
  - Data Security (Purview)
  - Identity & Access (Entra)
  - Endpoint Management (Intune)
Microsoft Agent 365 – The Control Plane for Agents
- Addresses the critical problem of agent sprawl and governance
- Think of it as “Entra ID for AI agents”
- Core capabilities:
  - Registry: Complete inventory of all agents (registered, unregistered, and shadow agents
  - Access Control: Conditional access policies and risk-based policies for agents
  - Monitoring: Real-time visibility into agent behavior, performance, and organizational impact
  - Security Integration: Defender protection, Purview data governance
- Key governance features:
  - Approve pending agent requests
  - Identify ownerless agents
  - Apply DLP policies to agents
  - Conditional access for agents
  - Secure score for agents
  - Available now through Frontier program in Microsoft 365 admin center
Overarching Themes
- Agent security is the new frontier: All major product announcements (Purview, Entra, Defender) are focused on agent governance
- 100 trillion daily signals inform Microsoft’s threat intelligence
- Ignite’s evolution: Less about big product launches, more about storytelling and connecting features released throughout the year
- IT Pro focus: Understanding, managing, and securing AI agents is becoming a core competency
Key Observations
- Ignite 2025 is heavily focused on AI and security – limited announcements for traditional products like SharePoint, Teams, or Loop
- The shift reflects Microsoft’s rapid release cadence in the cloud era
- Agent sprawl is real and Microsoft is proactively addressing governance needs
- IT professionals need to embrace this change: “The only way out is through”

Your support makes this show possible! Please consider becoming a premium member for access to live shows and more. Check out our membership options. (more…)

Episode 414 – When the Cloud Falls: Understanding the AWS and Azure Outages of October 2025

by [Scott](/content/author/scottmsclouditpro/ "Posts by Scott"/index.html) | Nov 6, 2025 | Podcast

Blubrry Player

Auto Scroll

Welcome to episode 414 of the Microsoft Cloud IT Pro podcast recorded live on 10/31/2025. This is a show about Microsoft March in Azure from the perspective of IT pros and end users, where we discuss the topic of recent news and how it relates to you. Fortunately, when we went to record this, the Internet is back online after an AWS and Azure outage, both related to DNS and both within the last couple of weeks. So what better to discuss today than what happened, how it was resolved, and what IT pros should keep in mind for future resilience planning when it comes to your cloud infrastructure. So, Scott, I saw this funny meme the other day. I'm gonna read it to you. I intentionally did not read this to you earlier. So I saw this. Somebody sent it to me. I have to go oh, I know where it is. I have to go find it. I should have pulled it up earlier. And this can tie into another topic as well. Where is that message? Wow. Okay. Here you go, Scott. After getting fired from ungrateful AWS, after an outage where my job was to Vibe code all the DNS entries to IPv six, happy to announce that it's my first today at Azure. Azure recognizes the value of Vibe coding IPv six DNS, and I just force pushed my first 1,000,000 entries. Now off to grab some coffee. Yes. I've seen this one. The Internet. Somebody has been following at wrecked on x. Yes. Actually, someone sent it. I do not follow them, but somebody sent that because DNS is apparently hard as evidenced by this last week of both AWS and Azure. I guess it wasn't quite within a week. AWS was October 20. Azure was October 29. Nine days, There was a little bit of a spread in between, but it does happen. It's always a good reminder when the cloud goes down that it really is somebody else's data center someplace else. It's just not it's not your data center. These things tend to be far reaching. I'm always amazed when Herndon goes down, so like US East Virginia for AWS, and 50% of the Internet just goes offline. Because there are so many of the modern day SaaS services, like the things that you would depend on, like, hey, I listen to music on Spotify, I stream my podcast from here, I do my banking with like, all these different things are all homed out of that region. So when bad things happen to Herndon, particularly in AWS land, bad things tend to happen on the Internet for the rest of us or at least I think the parts of the Internet that folks who listen to this podcast would go for. So for me, like I said, that's things like Spotify going down, that is Reddit suddenly disappearing and going no. Yep. There went the body of knowledge that was pulling all these things out. And then in this new world of LLMs and everything else that are doing both ingested plus real time searches of these systems, like, all that stuff starts to show its cracks along the way as well. So the AWS one, interestingly, like, manifests, I think, is a little bit of, like, oh, this all sounds like a lot of DNS. My understanding was it was actually a problem with DynamoDB and kinda light load balancing with Dynamo and the way that they push configuration and things like that into it. But I could be a little bit off there. I didn't have a ton of time to dive into theirs, especially, like you said, with the Azure outage coming on October 29, just nine days later, and that one being certainly more DNS related or at least like a I think to the spirit of it being that it was Azure Front Door and kinda some of the global load balancing capabilities of Front Door that got out of whack due to a configuration update. And in both cases, in both systems, these were configuration updates that kind of went a little bit sideways, and things got a little bit squirrely. It's hard. Stuff at that scale is very complicated, but it always amazes me how one of those configuration changes can take down everything so quickly that because we've seen it multiple times from multiple different cloud vendors where you would think they would have figured out by this time how they could do, like, small configuration changes that don't have the snowball effect, but yet we continue to see these. And, yeah, both were DNS. I was reading some on the AWS one too, and it sounds like it was it was Dynamo DB, but updating that's used to update DNS. And it was like two different services were trying to update the same DNS records tied to Dynamo DB and, oh, and two things are trying to update the same DNS record. It's like trying to update the same line in a file multiple times and SharePoint complaining that you have version mismatches? It's definitely possible to encounter these race conditions. Even small changes do have big impacts, so I think it's a little it's a little off or maybe, like, not the right color to say, like, oh, it's surprising when a little configuration change or, like, that a bigger configuration change goes out. Like, all these things go out, whether it's Amazon, whether it's Microsoft, whether it's Google. Everybody has their own deployment practices for safe deployments, for making sure that things get flighted through, like, multiple rings and they follow a general progression. You see the same thing, like, when a feature rolls out in SharePoint, for example. Right? We all know about the different rings that go in there with deployment rings and things like that. So it's the best of intentions. The interesting thing for me in the a AWS RCA was they got into some of the nitty gritty around how complex these things are with all these microservices that are running, talking to each other. So you'd like things are starting to manifest where we've built these really awesome machines, right, to go and manage this all for us and have all this underlying logic and all these other things into them. But when these, like, little subtle race conditions are coming through or other things are coming out and stuff gets out of whack, in in the case of the Dynamo thing, these workers between these various microservices becoming desynchronized, bad things happen. Right? So I think in the AWS one just pulling up their RCA real quick. So they've got a couple components. They've got this planner and these enactor workers within dyno DynamoDB that help with some some distribution of traffic and other things via DNS, but it's a bunch of basically, like, internal components. I'd encourage somebody to go read about this. Like, if you're interested in, like, distributed computing, hyperscalers, all these things, like, it's always interesting to see how these things are designed. But, you know, apparently, you had this one service, which is the DNS Enactor, which when it fires up, it verifies plan freshness, what it's supposed to do, what it's supposed to process, what updates it's or endpoints it's supposed to update, all those things. Turns out, the DNS and actor did within Dynamo does a very, like, sane thing in that it verifies the freshness of what it needs to do anytime that process starts or at the start of processing. But it's not doing, like, state management as it goes. It's always assuming that, hey. I spun up. This is current state. Let me go make some changes and then check again kind of thing. So you had these multiple actors that are talking to each other, and like you said, it's a contention issue. So by the time one spins up and it says, okay. Here's the plan. Here's what I'm gonna go do, and it goes and does it, well, it turns out that another one was spinning up with a potentially different plan because that is they haven't been in flight. And all of a sudden that check that had been performed that was fresh was now stale, and it's applying a stale configuration and overriding what was already there, and that leads to a series of cascading failures. And for services like Dynamo, they're so integral to the fabric of AWS. So there's a bunch of other services that are depending on DynamoDB. So if you're doing compute and you're using virtual machines with EC2, you're doing functions with Lambda, even things like RBAC and I'm ultimately tie back to these database systems like Dynamo, and they have these, like, just really bad, no good, horrible days. The closer to home for me on my side, I've seen when we've had outages in storage and very similar thing, like, you'd be amazed at the number of services that depend on storage for something. Right? They publish some kind of state in there. Maybe they're not even using, like, unstructured storage. It's not like they're storing logs or something, but maybe they're using, like, NoSQL tables or they're using queues or things like that along the way. So there there's just a bunch of moving pieces. There's a bunch of dependencies, and those dependencies just tend to bleed their way out. And I think what we were seeing a lot more is with these outages, at least these last couple, these two most recent ones, and I think if we look back a couple months as well, the impacts are just so far reaching because so many customers today are dependent on the cloud. Like, I saw a lot of chatter after this one, like, oh, AWS went down, and then, oh, Azure went down, and, oh, we should all be mount multi cloud, and we should all be and all these things. Right? Like, sure. Absolutely. We should. If we had infinite money, infinite time, infinite skilling, all those kinds of things that are out there, but that's ultimately not the reality for a lot of us. So I fall back to, are these things bad? Yes. Do we learn from them? Also, yes. Like like this particular race condition in the case of AWS, the thing that happened in Azure, they happened. They should not happen again because we learn from them, we implement those changes, and we go forward. And as bad as it is to have half the Internet go down, well, half the Internet was down. It wasn't just you. It was everybody else. And the fix also wasn't on you. The fix was on somebody else. Right? So while all those servers were catching fire, while everything's spinning back up and there's just this big retry storm going on and network links are getting overloaded and CPU and memory and all these things are going down, like, as bad as it sounds to say it, it was somebody else's problem to fix. It wasn't our problem to fix. So I'm still reminded of that part, like and very mindful that, like, when these things do happen, yes, they're bad. Clearly, they can be very severe and go out there and have some some crazy kind of impact. But at the same time, while you're maybe up all night trying to inform your customers or you're kind of running around trying to figure out what's going on, ultimately, that responsibility sits with somebody else to make sure that it is ultimately where it needs to be and that it's back up and it's running. And I think, like I said, like, these things happen. We're talking like these massive distributed systems. They're built by the best engineers that are out there, and they still have these issues even with testing, things like that, but they will get hardened. These are just battles in the war. They make these systems more resilient at the end of the day. Everybody learns from these. Like the AWS outage, I can guarantee you folks in Azure learn from. The Azure outage, I can guarantee you folks at AWS and Google and competitors are also learning from as well as we're all publishing these RCAs and getting things out there and kinda talking about what broke, what we're doing to make it better, how we're fixing it. Yeah. And even the whole multi cloud thing doesn't always work. Like, I was looking at the AWS and the Azure one, and under both of them, Starbucks went down. So it's like Yes. In that case, multi cloud didn't even help. Like, Starbucks crashed with AWS. They crashed with Azure. It is what it is. And the Azure one too, like, you mentioned the network storm, and I think that's some of it. We talked about how a small change can trigger a wide spread effect. Looking at the Azure outage, that one was a little bit more that way where there was a change that was applied to Front Door configuration change, and it caused a few of the Front Door nodes to fail. And then everything starts failing over to working ones, but the working ones don't handle all the failovers, and then they start failing, and it just snowballs from there where it wasn't like to your point, people didn't just go apply everything to all the front doors at once, but one cascaded to another. Do you feel overwhelmed by trying to manage your Office three sixty five environment? Are you facing unexpected issues that disrupt your company's productivity? Intelligink 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 inteliginc.com/podcast. That's intelligink.com/podcast for more information or to schedule a thirty minute call to get started with them today. Remember, Intelligink focuses on the Microsoft cloud so you can focus on your business. It wasn't our problem fixed, but I also caused a cascading failure this week, Scott. Unless you wanna talk more about AWS and Azure failures. We should talk about the front door one really quick. Alright. And I think I just wanna take this opportunity maybe as someone who's a little bit closer to the lingo that's used internally around these things to clarify some things. Yep. I saw a thread on Reddit that was diving into the front door outage. And if you go read the RCA that comes out, like, I'll go with this first sentence in the what went wrong and why. An inadvertent tenant configuration change within Azure Front Door triggered a widespread service disruption affecting both Microsoft services and customer applications dependent on Azure Front Door for global content delivery. And I'm gonna go back to the very first part of that. An inadvertent tenant configuration change within Azure Front Door triggered a widespread service disruption. There were folks on Reddit who were reading that, and they were taking that terminology of a tenant configuration change to mean that a customer tenant, like you, maybe you have a front door profile and I have a front door profile, that you would have the ability to push a configuration change to your front door profile that would take down the whole system. That cascaded to everything? Yeah. I coulda told you that from externally. Right? But I can see where that language tenant is used so broadly. So broadly. Yeah. Familiar with it could take that. So I just wanted to maybe provide a little bit of clarification there. So when we say tenant in this respect, really what we're saying is service tenant or maybe tenant that the service itself is hosted on. So may maybe another word for tenant here would be scale unit. Like, what are the scale units that host Front Door versus what are the actual customer tenants and things that are out there? And I think the confusion for this one was maybe a little bit further born out of the fact that the front door team has currently blocked all front door configuration changes. Oh, interesting. If you have a front door profile and I have a front door profile, we are blocked from making changes to those profiles right now. And I think this kinda perpetuates that thinking that, oh, you and I are blocked from making changes, and that's because I could make a change that's gonna impact you. And I don't think that's the case with this one. I think this is more like scale units, internal service things, all of that again. So there was a configuration change internally. That configuration change introduced an invalid state, very similar to those race conditions that we were talking about with Dynamo on on the other side. That inconsistent state caused a whole bunch of AFD tenants or AFD nodes, AFD scale units, whatever we wanna call them, to crash, and on that crash, to subsequently not be able to load properly. So Azure Front Door is kind of a global load balancer and a DNS load balancer. All of a sudden, you started seeing all this weird stuff, increased latencies, timeouts, connection errors for every sort of downstream service that exists out there. So, like, in storage land, you ever provisioned a ZRS storage account? A ZRS storage account, your DNS endpoint, your public endpoint is a DNS CNAME that is part of a front door profile and points to a front door profile. So, not good. Right? Like, all of a sudden your z ZRS zone zone of resilient thing, like, could be having some trouble due to lack of DNS resolution. The other one that happens in Azure land is so much of the tooling talks to API endpoints that are available via Front Door or fronted via Front Door. So you think about, like, management.azure.com, which is the restful API surface for all of Azure Resource Manager. That's behind Front Door. Lots of folks notice it when the portal goes down because you just go to, say, you're in a public Azure customer, it doesn't matter if you're in The United Kingdom or The United States. We all just go to portal.azure.com, and we get directed redirected to the closest portal instance via DNS load balancing via traffic manager. So there's actually, like, regional endpoints for the portal, but they're all masked out because they're part of this resolution chain on the DNS side that can go a little sideways in in the case of Front Door clearing out and getting to where it's knee where it needs to be. So, yeah, definitely not a good look for either Azure or AWS on this one. I'm very mindful of, like, the customer pain that's felt on these and the friction that comes with it. I think the consolation is, one, as folks who curate and look after these environments that are hosted in Azure AWS, as much as we own the message to our users that, yeah, it's broken and it's down, at least we don't have to own the fix for it, which double edged sword. I I don't think many of us could fix it faster than the folks who built these things could anyway all along the way. But it it does give us some stuff to go out and think about and see if we can do a little bit differently next time. Yeah. And while they do go down, I would say lately, and this was kinda the case of AWS and Azure, I would say, is I feel like response times and fix times for Azure and AWS have gone gotten quicker. Like, the time from when they first go down to when they come back online used to and I guess I think to several years ago where you'd see outages that would be, like, day long outages, whether it was eight, ten, twelve, twenty four hours. There have been outages in Azure, AWS, Microsoft three sixty five, all of those. I feel like the recovery time when everything like, to catch the issue starting to happen to where it's starting to resolve. Maybe it's not completely resolved, but you're not hard down for, like, eight, ten hours. Companies have gotten better at that, catching it, mitigating it, and getting things back up quickly or at least starting to get them back up quickly. That seems to have been gotten a lot better, I would say, in the last few years. It goes both ways. When the entire Internet is down, it feels like forever. And it's not just when the entire Internet's down. I I think there's economic loss that's associated with these things. So I saw some estimates talking about, like, the AWS outage even for the, quote, unquote, brief period of time that it was being as high as, like, 500 to $600,000,000 in lost revenue. Yeah. I saw some of those numbers too. For the companies that that are hosted on top of it. I think like any dark cloud, like, you gotta look for the silver linings. It can't always be glass half empty kind of thing. So I will say a couple of maybe, like, positive things that happen in both of these outages, both the AWS one and the Azure one. I'm seeing that communication's getting better. So while folks are still complaining that, like, oh, the status pages aren't updating, things like that, I do think the kind of proactive communication, like, we're finding a better balance between how many engineers do we put on fixing the problem, which I generally, I would say let's index towards putting everybody on it. But if we put everybody on it, that's at the expense of being able to communicate to customers, because we might even be taking the person who can take that message and and figure out how to get it to where you need to be. So I think the transparent communication getting way better. I've been really impressed by the post incident reviews that have come out from both Amazon and Azure recently. They're kinda going above and beyond in the things that they talk about and expose. Like, you as a regular customer, me as regular customer, we should never need to know the names of the internal microservices that are part of DynamoDB. And, like, we should never need to know about these things like AWS's internal planner and enactor workers. Like, alright. Great. Like, let's not worry about that kind of thing. So I think you are seeing, like, a level of transparency from the hypervisors that run these things and good transparent communication that's happening during the outages. The other thing I'll call out, like, these took some time in both cases to fix, but all those rollback procedures and stopping the bleeding and all that stuff, it worked. We're sitting here a week later and people are still banging their heads against the wall going, we don't know what the problem is. We don't know how to fix it. We don't know what changed. We don't know what happened. That's not the case here. Like, these things happened. There were point in time, tons of friction, tons of pain, horrible, yes. But they got fixed. They got fixed by somebody else, and they were fixed successfully. And then for whatever these failure modes are, like I said, you can be pretty confident that they're not gonna happen in the future. Are other things gonna happen? Yes. They haven't been discovered yet. But as they are, it all bleeds to more resiliency and it lends itself to more resiliency for these services. In some cases, I think there were mitigations put in place in a timely manner. So in the case of the front door outage, I saw that they actually pulled the portal out from behind front door. Like, they went and manipulated some DNS records to be able to give customers relief so that they could reach the portal without having to go through AFD and the load balancing mechanics that it brings along the way. I think the tooling's getting better. You're getting the ability in the tooling to target specific API surfaces, have other workarounds there, so that's all good. And, yeah, in general, like, sucks that it happened, but I'm actually, like, really happy with the responses here and the way they came out. Stuff could always go quicker. But that said, I think for what happened and the scale of both of these outages, stuff actually happened in a very timely way. And, ultimately, not much that I would have wanted to do as a customer anyway. Like, if I was already a multi cloud customer and I'm hosting in AWS and Azure, it's not like I'm gonna go out and bang on the door and say, well, let's go put ourselves into Oracle or Google and get yet another cloud here. Like, that's not necessarily the answer or the thing that's going to save you. You're only as resilient as your least resilient service kind of thing still at the end of the day. I think there is a little bit of an opportunity for customers to go through. Maybe you do wanna audit your dependencies a little bit, like, hey. Do I have to take a dependency on this thing? Or if I do, is there an alternative or a fallback service for me? Along the way, review your Doctor plans. So while you're not responsible, like I said, for fixing the servers and and the underlying microservices that power these things, I think you still wanna have good ways to communicate to your users about what's going on. So if you're a company that works with Azure and you have admins who are maybe more click ops and they're dependent on the Azure portal, you wanna make sure that you have, like, good documentation for your employees about what happens when the Azure portal is unavailable, What help happens when the m three sixty five portal is unavailable? What happens when this service is unavailable? Just so they know what to do, and they've got that kinda measured comfort food. You also need to think about kinda documenting recovery plans and expectations in terms of timing. So what happens if my cloud provider is down for ten seconds? What happens if my cloud provider is down for ten hours? Those are very different scenarios. And the way we react, the way we communicate with our user bases, all those things are going to be impacted. I think you also do have to think, like, I mentioned status pages. Both AWS and Azure, like, the status pages are not the greatest things at getting updated. So, like, are there alternative systems that you wanna look at? I see still lots of customers using things like down detector and things like that to see when these things are occurring or if they have broader impact within geo, outside of geo, things like that. I think those are all good to stand up. And then the last thing I would think about is as you're going through and you're figuring out maybe some of these things around recovery plans, things like that, is making sure that you're not only setting the expectations with users, but also setting the expectations with your leadership. So, like, if you work for a company that's single cloud, multi cloud, does your leadership have the right expectations around your company's dependency on the cloud? Has that been communicated in the right way? Does your leadership understand what they've bought into? Because there's the dream of the cloud, Oh, it's somebody else's cloud, it's somebody else's problem, it's 100% available. And then there's the reality of the cloud, which we know so far, no system out there is truly a 100%. So making sure that those things are ready to go so that your LT can weigh out all those options they need to, like multi cloud strategy options, ultimately understanding that whole, like, risk reward scenario or maybe risk versus cost for things like additional resiliency and redundancy and where that all falls out for you. Sounds good. What with that, Scott? I actually have family waiting for me to go do Halloween y stuff. So Halloween y stuff. You can It is the day for it. At least the weather is nice here in Jacksonville. Nice and cool out there. It's a balmy 68. Yep. I think this is the first year it's under, like, 80 degrees Fahrenheit for Halloween in a while. It's been a while since it's been this cool. So yes. Well, thanks for that. Hopefully, no more DNS cloud outages here for a while. Hopefully Yes. It's something that nobody wants to happen. Nope. So go enjoy your weekend. Enjoy the rest of your Friday, and we'll be back again in a couple of weeks. Alright. Sounds good. Thanks, Ben. Alright. 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 three sixty five 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.

Donate

Apps

Welcome to Episode 414 of the Microsoft Cloud IT Pro Podcast.This episode covers the major cloud service disruptions that impacted both AWS and Azure in October 2025. Even the biggest cloud providers face operational challenges. Learn what happened, how it was resolved, and what IT pros should keep in mind for future resilience planning.

Your support makes this show possible! Please consider becoming a premium member for access to live shows and more. Check out our membership options. (more…)

Episode 413 – Simplifying Azure Files with a new file share-centric management model

by [Scott](/content/author/scottmsclouditpro/ "Posts by Scott"/index.html) | Oct 23, 2025 | Podcast

Blubrry Player

Donate

Apps

Welcome to Episode 413 of the Microsoft Cloud IT Pro Podcast. Microsoft has introduced a new file share-centric management model for Azure Files, aiming to eliminate the complexity of managing storage accounts. This model treats file shares as top-level Azure resources, allowing for easier automation, granular access control, and independent scaling. It also simplifies billing with transparent pricing and supports up to 1,000 file shares per subscription per region in the current preview.

Your support makes this show possible! Please consider becoming a premium member for access to live shows and more. Check out our membership options. (more…)

Episode 408 – Model Context Protocol (MCP) Part 2: Getting the Most Out of MCP Servers

by [Scott](/content/author/scottmsclouditpro/ "Posts by Scott"/index.html) | Aug 14, 2025 | Podcast

Blubrry Player

Auto Scroll

Welcome to episode 408 of the Microsoft Cloud IT Pro podcast recorded live on 07/25/2025. This is a show about Microsoft three sixty five 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. In this episode, we'll move on to topics around where you can go to find various MCPs, what some of our favorite MCPs are, and how we've used these MCPs and tied them into various LLMs to help us get our work done. We are back. Part two of MCPs and the glorious functionality. It's just beautiful. Can I turn this into an Apple event and talk about how beautiful it is and magical and either that or Disney? Beautiful, magical, glorious. One big beautiful MCP? Sorry. I had to go there. Yes. You just had to. Can I ask it? Scott, no politics. We avoid politics on the podcast. Politics aside, if people are into comedy, the latest episode of South Park is absolutely glorious. Absolutely, like, pure One big beautiful South Park episode? Absolutely. Plex friend that you are. You know where to find such things if you want them. Alright. We're not appropriate for kids, but if you're in a mood and a vibe, oh. Speaking of TV shows, have you ever gone back and watched some of the old Silicon Valley episodes now that AI is becoming more mainstream and how much funnier some of them are? I just started revisiting that a couple months ago, so it's been good to go through. Yes. The Guilfoyle bot, like, the Guilfoyle bot is, like, actually could be a real thing now. Absolutely, it could. Alright. Should we build an m c we should build an MCP server for TV shows. Old if you could do that, like, build an MCP server as that ties into IMDB or something or speaking of use cases for MCP servers. Speaking of? Movie quotes, an MCP server for, like, pulling out good movie quotes. Write an entire story or an entire book pulling movie quotes from so many different movies. Yeah. You could probably do it. Should we talk about more practical use cases for MCP servers or how you get started? Like, our last episode, we kinda talked about what MCP servers are, touched on different ways you can integrate them, touched on some security stuff a little bit. We thought now it'd be fun. I know you use MCP servers. I've been using some MCP servers here in regular day to day life business use cases, and we're starting to see more and more MCP servers pop up from different companies as well, different services that allow you to start bringing that data in and bringing it together is kinda talking about what MCP servers maybe we use, how we've played with them, maybe even a little bit how you get them installed because different ones vary there and diving into more of the practical use of these MCP servers. Absolutely. So I think this conversation probably centers on our experimentation and kinda our experiences here. Like we closed last episode, I'd be very interested in hearing what others are doing, what they're finding interesting, and what they're finding helps, like, augment their workflows and kinda get going with some of this stuff because everything's moving very fast. There's new implementations. There's new updates, functionality changes from day to day kinda thing. So I'd be very keen to hear kinda others' experiences here and just what they've run into along the way. So I think step one, and you've kinda got it up on the screen here, is you hear about MCP and you're like, oh, this all sounds great. Like, how do I go and find out what servers are out there? Well, there's no, like, one stop shopping, like, definitive catalog for these things, but there are a couple catalogs out there that can help you get going. So the first one that you've got up on your screen, so this is from Anthropic. They kinda maintain a GitHub repo of active MCP servers. Funny enough, over time, these things haven't been around that long, and they're already hitting the point where they have an archived directory in there because some have come and gone already. But if you're looking for a specific thing, often, like, one of these directories is a good place to start. I think Anthropic's got a good one for that. I think the other one that's out there that might be interesting to folks, especially the more kinda security focused isolated ones, is Docker's MCP catalog. So Docker has an MCP catalog and they have an MCP toolkit. We'll kind of ignore the toolkit for now. But their catalog is really cool because it's integrated into the Docker desktop client. So now you get this whole world of containerization, super easy, like, one click install, like, if you're just, like, a gooey person kind of thing, but you also get the added benefit of container isolation for these things. So like we talked about in the last episode, you know, the these need to run either on a service as an HTTP endpoint or they need to run locally with an HTTP endpoint. If they're running locally with an HTTP endpoint, well, that means they're often running through, like, an NPM server, so you'll see, like, a lot of, like, the server definitions or, like, MPX and this thing kind of thing. So you're running all those web servers locally, so you do have to kind of make this call about, like, do I wanna do that in isolation in something of the form of a container, or do I want to just, like, go and start spinning these things up all over the place and have multiple npm instances running with multiple servers, things like that? That's a, like, you do you kinda thing, but I think it is a consideration. And the Docker folks here, like, to their credit, they've done an amazing job with just, like, integrating this into the Docker desktop client, making it super turnkey, and providing some more of that, like, abstraction isolation that containers give you in that world. So if you're running a local server, specifically a local MCP server, I really encourage folks to probably look at the Docker catalog first. And then if your thing isn't in the Docker catalog or even if you found it in some other catalog, go see if it's in Docker. And then if you really have to and you really wanna get hands on with it, then do that in a way that's safe for you to do. Yeah. And there's a lot of them here. I don't know how many there are in Docker. I should someone should ask AI how many there are here. One, two, three, four, six pages with, like, one, two I think there's a couple 100 in there today already. Yeah. And that list grows over time. Maybe one of the nice things about the Docker one too is it's not just like GitHub and a pull request away. So there's a little bit of a, hey. I want to submit my MCP server to your catalog kind of thing. I don't know, like, on the back end if that comes with any kind of agreements or anything of saying, like, hey. You'll maintain it or you'll let Docker know when it goes away, blah blah blah. But I imagine because all these spin up in in containers and things like that and isolated that you're kinda also using Docker Hub, and folks can go out and look at the Docker files and see what all these are doing. Yeah. Look at here's a LinkedIn MCP server, Scott. I might have to go try a new one. I've not played with this one yet. But a couple episodes ago, I talked about how I had used Researcher to go look up people that I may be meeting with or connecting with and have it looked at LinkedIn. It would be interesting to try some of that with this LinkedIn MCP server, see what kind of fun details I can pull out. So, yeah, these are, again, great resources when you're looking for MCP servers. You can also just go out and search for them. Like, when I started playing with them, there were some certain MCP servers. I was like, oh, are there some MCP servers for this and for ClickUp, for Microsoft Sentinel for some of those? So some of those, I just did a search for and found GitHub repos. Obviously, word of caution, if you're just going out to some random GitHub repo to grab an MCP server, proceed with caution. Like we mentioned in the last episode, MCP servers being the USB ports of AI, you don't necessarily wanna just plug in a random GitHub MCP server to your environment. But there are lots and lots of options out here. I would say the other thing I found before we get into some of those use cases when I was looking for MCP servers is I struggled a little bit where and this was ClickUp in particular. ClickUp has AI built into ClickUp, and they are building in support for MCP servers to be able to have ClickUp AI go connect to whatever MCP server. And I was like, no. I don't want ClickUp to connect to an MCP server. I want an MCP server to connect to ClickUp. And some of the search engine right. Like, some of the search engines were having problems, and I kept running into, here's how you add an MCP server into monday.com. Here's how you add an MCP server into ClickUp. Here's how you add an MCP server into Notion. Here's how you it's like, no. I want an MCP server for them to pull that data somewhere else. So, yeah, that's it's new. Everybody is trying to figure it out, and everybody wants you in their AI platform. So they're trying to get you to go use theirs. I had the same struggle with Notion going down that path the first time. So I was very interested in I I think I talked about the use case before. Like, I use, like, chat GPT and things like that or, like, Claude to create a recipe. And I was very interested in this, like, hey. Just pump it into my recipes database because I knew they had an MCP server that allowed for the ability to, like, create databases, update databases, all these things. And it took me a while to find the right path to get there. And then once you find the right path to get there, you also sometimes have to find, like, the right incantation of, hey, this is how I'm going to make it work kind of thing. So, like, for Notion, like, it's got an update database thing. Well, databases have columns, they have fields, they might have fixed data types, things like that. So just figuring out even, like, what's the raw input you need from the LLM to push the LLM to the next step of insert into my Notion database can be a little bit weird. But if you're a tinkerer, I think these things are, like, really fun. And then once you figure them out, like, boom, the light goes off, and you kinda get to the next step from there. I I think they are really fun kind of things. So there's tons of them on the consumer side. I've been using mostly Azure focused things in my day to day. Like, I spend a lot of time in Versus Code, either writing documentation for our platform, generating sample scripts, running running through and doing test cases and things for SDKs, clients, all that. So that's a place that I was already living. So having that as a client Versus code that is MCP capable and with the ability to integrate with MCP servers as client, access to all the chat models that are out there, things like that. And being that I work for Microsoft and, I mean, Azure, I found a couple that are helpful to me. So the two that I probably use the most are the Microsoft learn MCP server and then the Azure MCP server. And this is, I I think, two good ones to talk about because they also bring us back to that distinction of remote server versus local server and some of the things that go on with setting them up and kinda how they wire up and how they come together. So the Microsoft Learn MCP server is a remote server. So the folks at Microsoft Learn actually have an API endpoint that's available to you as a customer that you can integrate with your MCP client, and you it's a very simple definition. They've made this super turnkey for, like, Versus Code. Like, if you scroll down a little bit on this page, like, installing these things, or maybe it's on this page, maybe it's on another page for it. Yeah. Maybe get started or something like that. That's probably it. Yeah. So, like, right there, they've got configure Versus Code. It's literally like a button, and it just opens Versus Code for you automatically, and it wires it up along the way. Very similar to maybe installing extensions and things like that. Oh, I guess we should have mentioned that, like, Versus Code. Visual Studio Marketplace, they actually have an MCP catalog as well that's out there ready, raring to go, available, all that. Yeah. So so this is a remote one. You install it, and you're kinda ready to go. You do have to start MCP servers, particularly in Versus code. I found this to confuse me. Every time I close Versus code down and then reopen it, and I go back into my agent or my chat view, and I turn it to agent mode, and then it goes, oh, I don't know what to do because this thing isn't on. Darn it. I forgot. Maybe there's a button or something I just haven't found yet linked to Versus Code configuration to to do that. But, yeah, once once you got it up and running, then you just start chatting with it and ask it, like, hey. How do I create an Azure VM based on docs? And then just based on the context of having Azure and docs in the prompt, it knows to use that agent to reach out and do that. You can even ground it, like I talked a little bit before, and I think we talked about this in the previous episode about grounding these things with instructions and kind of base prompts to start. So in the case of Versus Code, you go in and basically you say, here's my instruction file. And in your instruction file, you can tell your instruction file. And I think if you scroll down in here to the bottom of this page, it's actually got a section here for set instructions. Yeah. Perfect. So you can actually just tell it and ground it. Like, anytime I ask a question about a Microsoft product, use this MCP server. Like like, go out and use me to to get that information and pull it back. So that that's one that I use all the time. Like, it's just there, ready to go and available. And then the other one that I use a bunch, which is a local server, is the Azure MCP server. So this one is a single MCP server with a whole bunch of agents inside of it. So when you're chatting with the Microsoft Learn MCP server, it's really just one agent that's going across all the learn docs and figuring things out. The Azure MCP server has well, as of a couple days ago, it had, like, 72 or 73 agents in it. They just collapsed it down to 28 because it was just, like, so a big list and gnarly to get a hold of. But this one offers you a bunch of domain specific functionality around Azure. So, like, list all my resource groups, list all my virtual machines, list my storage accounts. And then it has even more domain specific functionality given the resource that you are interacting with. So I work in Azure storage. That's the place I've been playing around the most. So that'll be, like, my example here. They have the ability to go in and say, like, list all the containers in my storage account. Give me the properties of my containers in my storage account. Things like that. And the docs for this one are pretty good. Like, if you click through like, you've got on the side there, like, if you go into, like, the Azure storage one or the resource group one, either one of those, it'll tell you, like, hey. Here's the types of domain specific knowledge that this MCP implementation and this particular agent can offer back to you as a customer. There's a big distinction here between that whole local and remote server thing and what it goes to to get these things wired up and get them installed and get them all working. So, like, the learn one, super easy. Right? Because it's a remote MCP server. You're just pointing it at a resource and you go. This one's local. So you gotta run it. It requires if you're running it locally on your desktop, it requires Node. If you're, like, a Windows customer and you're just doing Node for the first time and you just next, next, next to your way through the installation, Node does some weird stuff. Like, it'll install Chocolatey and some other stuff along the way, but there's definitely like this dependency chain that isn't always clear until you start using it. Thankfully, like the agent walks you through it pretty clearly, so like once you get the server started and you go run your first thing, like, hey, list my resource groups, then it'll say, oh, I wanna list your resource groups with the Azure CLI. Do you have the Azure CLI installed? Is it in your path? Yes. I'll go run that. Oh, I see Azure CLI is not installed. Let's go install that kind of thing. So there can be a little bit more of, like, hurry up and wait, particularly when you're installing local servers that have dependencies on other tools or other tool chains that are out there along the way. But once you get it all going, super turnkey. Right? Super easy. You just kinda light it up and go. Yeah. Do you feel overwhelmed by trying to manage your Office three sixty five environment? Are you facing unexpected issues that disrupt your company's productivity? Intelligink 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, Intelligink helps you with your Microsoft cloud environment because that's their expertise. Intelligink 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 inteliginc.com/podcast. That's intelligink.com/podcast for more information or to schedule a thirty minute call to get started with them today. Intelligent focuses on the Microsoft cloud so you can focus on your business. And I've been playing with this one too. The other thing I would say is, well, the difference between Learn and Azure is, like, Learn is all just open to the public documentation. Right? Like, you don't need to authenticate to Learn to go pull stuff from it, so MCP server's there. With the Azure one, you are connecting to your subscription, so there are dependencies there on you actually have access to your Azure subscription and your permissions to Azure and setting up that authentication piece between your local instance and Azure. I've started playing with the learn one. I've not used the learn one as much yet, but I do like it, and I have actually been using Claude for all my MCPs. I went out and set up Claude locally. I've been setting up a bunch of my MCPs in Claude. I do not have the problem of having to start it. I just go in and start chatting with Claude, and it pulls it all back. But I like Have you been able to get the Azure MCP server going in, Claude? I had a bunch of fits and starts there, particularly on my Mac. Like, there was something so the Azure MCP server relies heavily on default Azure credential, which is, like, this internal class within things, and I've just had, like, a bear of a time get it going. I could only get it going in Versus Code. I could never get it going in I think it is. Let me go ask in a minute. Let's see if it can fix my spell check. We'll let that go while we keep talking, but it wants a CLI. Always allow. But I like the fact, like, with learn, before if you would go out and do a if you're gonna go out and do a search, right, or if you're just using Claude or OpenAI or something to ask about certain Microsoft documentation, you do tend to I think I would say it can you don't always know that it's gonna pull it straight from learn. Right? It may pull up from some forums where people are giving incorrect answers. It may pull it from all kinds of different places, blogs, YouTube. You never really know where when you start doing the MCP, you're like, okay. It's probably gonna tend to pull at least a little bit more accurate information from learn. We could argue that learn always isn't accurate, but that's a whole another discussion. Absolutely. Discussion for another time. In regard to that, so Claude presents it a little bit differently in the UI. I think I'm, like, more immersed in that Versus Code world today for this stuff, at least for, like, my day to day job and role. You can actually tell when it's reaching out to an agent, at least in, like, the internal, like, GitHub Copilot chat window. So you do have that, like, that grounding that like, hey, this response is coming back from this MCP agent. It's not coming back from, like you said, just the base LLM and what that's been trained on or anything like that along the way. I'm gonna have to go revisit this. Maybe they updated something in Claude because I just had a weird time getting it going last time. But So this is fascinating too. I don't know. This is not pulling it from my subscription. This is using another client's Azure account that I'm signed into somewhere. So I don't know how it picked which credentials it was going to use when it went out and connected to Azure. If it's the latest one that I've connected to with Azure CLI or how it shows which credentials it was gonna authenticate, but it did not use my my internal company credentials. It used some credentials I'm signed into with the client subscription. But it was at least able to connect and go pull all the resource groups across all the subscriptions that I'm currently signed into somewhere. Oh, there you go. Yeah. That's another interesting thing too, like, Claude and Microsoft documentation for both Learn and the Azure MCP. PurePoint gets a global just a click to install from the Visual Studio directory. If you go use Claude, they do have guides for the directory install wherein opening a configuration policy, pasting in some JSON, you need to ensure you keep your JSON formatted because what I have found all this documentation assumes this is the only MCP you're installing in your configuration file. If you take the raw JSON from all of these, you end up with malformed JSONs. You have to figure out these all go inside of the servers with the commas in the right places and squiggly brackets and all of that. Claude for me was a little bit trickier, and every once in a while, I'll see weird errors pop up in Claude with formatting issues. It seems to work. We talked about it last episode. MCPs are new. There's still some WIMM every once in a while, but I've got both Learn and the Azure one working well in my instance of Claude locally. Claude's been a bit of a weird one. You kinda get into that world of editing JSON and all that stuff locally. So, yeah, it's kinda hit or miss. And it depends on your level of, I think, like, just not, like, technical acumen, like your ability to, I think, deal with some of the friction that Yes. That comes with these things. So Versus Code, I like I said, like, they've made it super turnkey. Like, I I would have to guess the folks at Anthropic aren't really happy. Like, Microsoft's out here with, like, this whole ecosystem as well that's disintegrating and doing these things, but I will say, like, the folks at GitHub have done a very good job with that. So for the learn one, does that still require you to have GitHub Copilot as well in Visual Studio Code or because it's using the web version? I didn't look at that. I don't believe so. I I haven't tried to integrate that one with Cloud yet, but it should have to stay a local definition as well. Do you wanna talk about learn or Azure anymore? Let's get into some of your list. This is the one I've been playing with a lot lately is Loca, and this is from our good friend, Merrill, who we've had on the podcast before. He went out and created a Loca agent tool. And did you read? He posted the story because everybody asked him why he named this MCP Loca. I did not. Yeah. I don't know the background there. It was because he was in front of a food truck or a coffee truck, and the name of the food truck was named Loca when he came up with the idea. So he named the MCP after that. He has a little bit of that backstory out on LinkedIn. But this is an MCP that runs locally using Node, so you need to have and he guides you through the Cloud desktop. He also has instructions on here for doing it with Visual Studio Code, but MCP that runs in Node, so Node is also a prerequisite there, to connect to the Microsoft three sixty five graph. So this will go in in query whatever graph access you care to give it. So part of the configuration here, going into a little bit more of the JSON and development aspect of it, is not only do you have to put the JSON in there to configure the MCP, but you need to make sure you authenticate to Microsoft three sixty five Graph with an originally, this again, these are all new. It was by putting your client ID and your app ID and your app secret in the JSON file, like, in plain text so anybody could have seen it. It has since been updated, so there's a few different methods now that you can use to connect to Microsoft three sixty five graph. But then with those app permissions, you do have to go in and, grant that app the appropriate access to the Microsoft three sixty five graph. If you want it to be able to go look at SharePoint sites, files, audit logs, Purview, there's not a specific Purview endpoint, but all those graph endpoints, you can kinda control the access. You give this MCP to the graph by going in and configuring those endpoints. This one for me, Scott, has been it's been really interesting, and I think one aspect of it that's been fascinating for me is comparing it with the the Security Copilot. So, like, Security Copilot, we've talked about before, Copilot for security. If you give it the wrong name, Microsoft gets mad at you. We've talked about it. The base entry point for that is, like, $3 a month, $30 a year. I can go out and pay for Claude for, like, $20 a month, connect this MCP server, and get to a lot of the same stuff. There's differences, and I'm actually working on some sessions for some conferences this fall where I might highlight some of those differences and where, Copilot for security excels or security Copilot excels versus this MCP. But once you connect it to the graph, I've done things like go pull I've gone in, asked it to go pull sign in logs, analyze the sign in logs for a particular user, or give me all the users and what licenses they have in my tenant and pull back reports on users and licenses or sign in logs. Are there any anomalies in the sign in logs? Go look at the this UPN and look at where they've signed in from and what IP addresses they've signed in from. As long as you open it up to that data for the Graph API, it's able to go pull all of that. I was playing with one where I asked it to, like, go look at my conditional access policies, go analyze conditional access policies in Entra and how those are configured or who those are applied to. Another use case was the Defender. Like, you get your incidents in Defender. You get incidents and alerts. I actually went in and found looked at my security dashboard, grabbed the incident ID, and asked Claude to go in and look at that particular incident and analyze that incident and give me a full incident response. You were showing me this report earlier. Like, it was actually pretty cool. Like, you need some formatting help and, like, less AI driven emoji happiness BS that they tend to spin up. But outside of that, yeah, like, pretty cool. Yeah. It wrote, like, an entire document with the incident details. It gave me a a table with the attack timeline of in this particular one, it was an email delivered to two different email addresses. Then Defender created an incident. Then alerts were generated for unremoved messages. Then some emails were automatically removed to quarantine. Then it found alerts for malicious URL detection. And then there was the last incident update. And it gave me that whole timeline, gave me a technical analysis of it, what the URLs were that were in the email, different risk factors, gave me an highlight of investigation findings and what those containment and eradication steps should be. It, yeah, it wrote up the whole thing and then recommendations for the next twenty four hours, the next seven days, the next thirty days based on this incident. You should show it on your screen over here. Yeah. I can throw it up here. I was trying to avoid some of the user details in there. I saw you, like, eye scrolling. So, yeah, it has I can get up partway here, like, up in here, but it has, frankly, a lot more details than what Security Copilot gave me when I asked it about the same incident. Where I found some of the niceties with Security Copilot is some of the integrations. But, again, you're looking for, like, a poor man's, not even a poor man's, a whole lot cheaper version of AI to be able to ask about some of these things as long as you're okay giving those graph permissions to Claude or to if you wanna use GitHub Copilot still using Claude or one of the other AI engines on the background or one of the other LLMs on the background, you can get a lot of information, and get really close to a lot of the Security Copilot stuff just using this particular MCP from Merrill. Super nifty. Like, I think this stuff is just, like, so turnkey. I don't know. I feel like it's gonna drive me down a path of trying to build one of these things on my own, and I'm just gonna turn into, like, one of the Vibe coders or something. We should create an MCP for the podcast. Should we, though? Ben and Scott's podcast brain MCP or something like that. I did tie an agent to it. Not an MCP, but I did tie a Copilot agent in the tenant. If you wanna go play with it in our tenant. I did create one that I pointed it at the podcast website for a podcast agent. Yeah. So I've been playing around with the Claude Azure thing because it was annoying me that it was working for you and not for me. Yep. Where I had given up is when you're in Versus Code, the first time you install this and you start it, it will authenticate you. So it'll actually drive you through, like, the device login flow, like pop up a web browser, things like that. Cloud doesn't do that by default, so you have to go and you have to actually log in to, to, like, Azure CLI, which is what it's using under the hood. And then once you've pre authenticated to Azure CLI, then you go back, run your prompt, and it works just perfectly. So that must be what it was picking up as I must have logged into a client's tenant with Azure CLI, or I wonder if it would even pick up Azure Graph or PowerShell connections. Yeah. Re reuse any of those things. That was my issue. So if anybody else using Claude on the desktop and you're like, oh, I can't use an Azure thing. Yeah. You can. Alright. Any other MCPs you wanna talk about? I know we kinda hinted at some. There's a bunch out there. There's a whole bunch out there. So, like, I would encourage folks, I think, to and I've been thinking about this more, how you combine the local tools you use day to day or the parts of the stack that you use day to day along with your other tasks. So these things, like, go and list my resource groups, list my configuration for these resources, things like that. Like, it doesn't have to be a stop there kinda thing. It could also be a, hey. Take that and then pump it out here over to this other thing or format it in this way. Right? Like, you have to create a report for your boss that says, here's the current configuration of all our VMs and which ones are using straight public IPs, which ones are behind bash and things like that. Like, you could totally output that report, have it formatted, and put into a great format for, like, an email for you. Right? Or go save it as a CSV because maybe you install an MCP agent that or an MCP server that allows you for, like, local file system access, things like that. There there's a whole ton, I think, of chained interactions that you can do. Like, if you start to think about having multiple of these things and being able to tie them together and then integrate them back because they're all integrated in that, like, overarching LLM ecosystem. So I think that's, like, the next step or next thing to think about or kinda where I'm going with it. Yeah. And this is where it would be interesting too. Like, I would love to see MCPs tied into Copilot. And I think I mentioned that on the last episode because when I'm maybe when I'm querying all my graph data, if I give this MCP access to a whole bunch of Microsoft three sixty five graph data where it's looking at users and conditional access policies and IP addresses and incident reports. If I'm being honest, I would prefer all of that to stay inside the Microsoft three sixty five tenant, not necessarily come all the way out into my local machine and come out to MCP servers that I'm again, we know Merrill. I trust Merrill, but it's his code that he wrote for this local MCP server. Having it live in my Microsoft three sixty five bubble would make me a little bit more comfortable with it. Then I could also do things like take this incident report and create a PowerPoint presentation from it a little bit easier or a Word document because of some of those other Microsoft three sixty five integrations with the Office tools and some of that. So I am. I'm really hoping that even if it's inside and I know you can do it in Visual Studio Code today or not Visual Studio Code. Sorry. Copilot Studio, it's not nearly as simple and straightforward as it is integrating it into Code or Visuals Claude or Visual Studio Code or some of those. I wanna see this a whole lot simpler in Copilot. I think that would be really cool from my perspective. Yeah. I think over time, it probably gets there. I can also see a world where you might end up with either specific forks of these tools, or things that bring those integrations together. So, like, if you think about like Cursor and all the popularity of Cursor and using it for like AI coding with LLMs and all that, Cursor's just a fork of Versus Code, right? And I mean, at the end of the day, like, it's got a bunch of, like, domain specific functionality, but ultimately, it's built on that base of Versus Code. So there's this world where somebody could just totally take, like, a prepackaged Versus Code with a bunch of MCPs already installed in it, already ready to go, think things like that. Over time, you might see people, like, spin up, like, super do do do. Like, we've got these one clicks for these installs. I over time, those probably turned into, like, bundled installers and other kinds of things. So it's all moving rapidly. Like I said, I I kinda like it because at least I don't know about you, but, like, for my day to day job, like, sometimes some of the things I work on take, like, years to manifest and come to fruition. And this is one of those places where I can just, like, oh, kid in a candy shop, go be super inquisitive, play around, stuff breaks all the time, and you're like, oh, yep. That that that broke. I'm okay with it. Move on to the next step kind of thing. Awesome. Well, thanks, Scott. Excited to see where these MCP servers go. Fun to talk about how you're using them. Would love to hear about other MCPs, again, that all the listeners have used, that you all have installed, how you're using MCPs, concerns you have about MCPs from some of that security standpoint. So feel free to reach out. Let us know your thoughts on MCPs, how you're using them. If you wanna come talk on the podcast about how you're using MCPs. We'd love to have you. Yeah. Contact us through the website. Reach out via LinkedIn, come find me at a conference, Scott. I got a bunch of conferences. I was looking down. I'm, like, at a conference a month now through the end of the year. So if you're gonna be Atlanta, I'm gonna be at TechCon three sixty five in Atlanta here in a couple weeks. That'll actually probably be before this podcast episode even airs. Going out to Branson again to the North American collaboration summit out in Branson. That's September. October might be dev intersections, cybersecurity intersections in Orlando. November, hopefully, we'll both be out at Ignite. And then December, I'm doing Workplace Ninjas, which is a security conference in Dallas, Texas. You've got, like, quite the list. Yeah. I might be at storage developer conference in September. That's about it for me. And then like you said Hopefully, night. Hopefully, podcast stuff out at Ignite again this year in San Francisco. Could be fun. Could be fun. Will be fun. Assuming we get to go. Yes. Absolutely. Alright. So, yes, if you're gonna be at a conference, reach out. Love to chat with you. If you wanna be on the podcast, talk about MCP servers, let us know. But for now, enjoy your weekend, Scott. Enjoy the 100 and whatever degree weather we're gonna be having these next few days. As I said, it's only a 106 now. It it it can only get hotter is what it feels like. And it's 5PM. A 106 at 5PM is just not right. It's got me all ready to go back to the Pacific Northwest. 70 degrees, like I said, it just it it hit a little bit different without the humidity too. That was the key part in there. Alright. Well, as always, Ben, thanks for the conversation. Much appreciated, it, and we'll see you for the next one. Alright. Thank you. 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 three sixty five 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.

Donate

Apps

Episode 399 – Azure Infrastructure as Code with Greg Suttie

by [Scott](/content/author/scottmsclouditpro/ "Posts by Scott"/index.html) | Apr 10, 2025 | Podcast

Blubrry Player

Auto Scroll

Welcome to episode 399 of the Microsoft Cloud IT Pro podcast recorded live from the MVP Summit on 03/28/2025. This is a show about Microsoft three sixty five 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. This week, Ben and Scott get a chance to catch up with Greg Sutti at the MVP Summit. While there, Scott and Greg have a chance to sit down and discuss infrastructure as code in Azure. They discuss what Greg has been working on when it comes to Bicep, Azure verified modules, Bicep configuration files, and more. I'm here at MVP Summit with Gregor, who decided to sit down and was gracious enough to join us today. Gregor is an MVP in Microsoft Azure infrastructure and code, cost resource and configuration management, and probably a bunch of other things where it has a bunch of other skills. So, Gregor, why don't you take a couple minutes, go ahead, introduce yourself, and then we'll get into things. Thank you, Scott. Yeah. My name is Gregor Sutti. I'm an Azure architect for a company in The Netherlands. I am from Scotland, so I will try and speak slowly so that everyone can understand me. My background, I was a developer from from v b sixties, then I moved over to .net, and then I was doing SQL. So I've got a bit of a data background, but I have a development background, and then I moved to become an Azure architect for Intercept in The Netherlands. I have been doing that for five years now. Yeah. And I'm Azure MVP. I'm also an MCT, so I do a lot of Azure fundamentals training, Azure AI training. And, yeah, that's basically my background. Training near and dear to my heart. Mhmm. Love training. Love training. I probably annoyed a bunch of people. I I I was one of the writers for the AZ 100 before I became the one zero four. So you you get a lot of stuff in there to blame me for. Nice to know. So tell me a little bit about your experience as an MVP. I think folks always ask that question. Yeah. How do you come become an MVP? What goes into it? Like, what's your Lyft experience there? Good question. So, yeah, my background, I always wanted to be an MVP. I wasn't really sure what it was to begin with, so I reached out to one of another fellow Scottish person called Kenny Lowe, and I asked him and he told me quite a lot about the program. Really interested in it. I had to say to myself, I would love to become an MVP. So my first step was I wrote the letters MVP above my monitor at home, and I thought that is my goal. I want to become an MVP. You you put together a vision board. No. I just put I just put the letters MVP right above it. I thought I'm gonna go for this. This is my goal. I started off I don't have any Azure experience, so I was working as a dot net developer. The cloud is obviously a big thing five, six years ago. I wanted to learn Azure, so I started off with just learning the exams. So I started off with the development exams, and I started off blogging about my experience of learning, like, the developer exams. Like, how am I what study material am I gonna do? How am I gonna go about learning this? I'm a hands on learner, so the way I learn is by I don't read much. Basically, I read the docs and then hands on learning. So open up the Azure portal, deploy the resources, and learn from that. Then I did some practice tests, took the exam and failed it the first time around because I didn't have enough hands on experience. I thought I knew enough to pass the exam, but it turned out I didn't. So I took a lot of learnings from that, but I needed to spend more time hands on. Took the exam again and passed it, and today, as of now, I've done 13 exams. So I am quite exam heavy. Kind of got a routine of studying hands on, looking at the docs, blogging about my experiences of what I've learned, what you need to focus on for the exams. And, yeah, from that, I then started attending the Glasgow Azure user group where Sarah Lynn runs that. She approached me because I was going quite regular, and she said, would you like to help? So I'm kinda helping her with that. That that's been very helpful for MVP. So I've been blogging. I would do some talks and helping out the Azure user group. So that's kinda how I got started in becoming an MVP. And a lot of people reach out to me on LinkedIn and say, how do I become an MVP? So I always say it's all about the community. It's all about giving back. So whatever you learn, blog it, write about it, share your knowledge, share your things you've run into. Lots of times I Google for for an issue and I end up look at ended up on my own blog. So I started blogging because I've got terrible memory. Oh, yeah. And sometimes I still still end up on my own blog. So, yeah, blogging, giving back to the community, user groups are always helpful. But I would say you don't have to a lot of people say that you'd have to do public speaking. I don't think you do. There's one of my friends, Thomas Thornton, he's got an amazing blog and that's all he does, and he's become an MVP from from blogging. He's not into public speaking. So just giving back to the community as much as possible is is kinda how you go about becoming an MVP. Gotcha. Yeah. One of the other things, or at least my experience there is I I I did a similar thing. I wanted to be an MVP. I never became an MVP, but that was okay because the things that I were doing, I still got to go out and meet people and interact with user groups. And that experience of like, yeah, oh, I just landed from Google on my own blog. Yep. It's definitely a thing that happens. So I I often tell folks don't do it with the expectation that you want to be in a VP. Absolutely. Do it with the expectation that you want to participate in a community. You want to become a better technical writer. You want to become a better presenter. Whatever dimension or or mix or match of those things are so that you're getting something out of it. Yeah. And and and that's really kind of the the goal and where you want to land. So I I I have to inquire. So your Azure infrastructure as code is one of your categories. Yep. Dot net developer. Yep. Have have you crossed to the dark side? Do you consider yourself an IT pro these days? No. I'm not an IT pro. Generalist. Yeah. I'm more so when I worked for JP Morgan, they came up with this term t shaped developer. So the idea is you are kind of broad, but you go deep in one area. So I thought that was quite good. So my not my problem, but my background is I am a bit of a master of a jack of all trades, master of none, and I decided I would try and do infrastructure as code as kinda my deep thing. So, yeah, I do data. I do AI. I do infrastructure as code, cost management. I do most of Azure. Probably the only thing I don't really do is EKS, and that's the one thing I've kinda because people at my work to do all that. And I'm like, you can you can stick with that and I'll do the rest. So, yeah, I get asked lots of questions about lots of different things. Infrastructure as code, and I have a very lucky background. I work for a lot of people, a lot of managers who taught me how to do things properly, document things, do pull requests with good comments, and and I was just I've just got a really good background for working for good people who showed me how to do it the right way. So infrastructure as code, build pipelines, doing everything professionally. So that's why I got into Bicep. I wanted to learn how to deploy resources for customers across different environments and do it properly. So, yeah, I'm a big Bicep fan. That that was gonna be my next question. Mhmm. So Azure Resource Manager arm has changed a bunch over the years Yep. From declarative templates to Bicep and and having a domain specific language and and a DSL. And there there are certainly folks out there, I think, that have done infrastructure as code either on the arm side. They've done maybe Terraform, tends to be like my canonical one that I go back to and and near and dear to my heart. How how how are you finding Bicep, like, the transition from traditional resource manager templates and and kinda coming over that? And then are you is are you just a a Bicep fan? Are you using it with customers? Like, how is how is kind of the getting past the documentation and the POCs to, hey, here's how this goes in the world for you? Great question. I did luckily, I didn't spend too much time in my career doing ARM templates because ARM templates are a little bit tricky to kinda understand. When you look at them, you're like, what is the dependency chain? How are things working? So I kind of got on board with Bicep from the very start. I open up Versus Code. I just write Bicep. I basically just learned it by, again, hands on. How do I deploy a storage account? Let's start with some simple deploy it like that. How do I parameterize it? How do I deploy it? Do I deploy it from my machine? Do I deploy it from Azure DevOps or GitHub workflows? Runners. Sorry. So, yeah, just learning it by hands on and doing it, and I've been doing it for five years now. Probably, I feel good at it now, I would suggest. I've got lots of experience. So when I'm at work, I always do infrastructure as code using Bicep. Everyone kinda asks me how to do things because I I spend probably 70% of the week doing Bicep for different customers. Absolutely. I love it. I love the idea that I can show customers how to deploy their environment to dev and test in production using the same templates. So all of the same standards. The only difference is the config for the actual deployment resources. So dev might be a a cheap VM, and acceptance of prod might be a more expensive VM. So, yeah, I'm using Bicep a lot, and I absolutely love it. Even today, we're talking to the Bicep team, and I think that stuff's great. Gotcha. And and before we started recording, you had mentioned that some of the projects you work on with customers might be around migrations, things like that. How do you see your customers kinda going through those motions? And maybe if I'm migrating to Azure, I I I don't know your experience with it. I'd be curious to understand. I I see a lot of customers that kinda start in the portal, and they just go next, next, next. And I've I've got my virtual machine, and I've got my VNet. And oh oh, I I need a database. I might stand up like a PaaS instance, like manage instance, something like that. And then they do it once and they go, how do I do it again? Correct. And and and what does that look like? So I'm curious like, do your customers move kind of more traditionally? They come up, they go through that same kind of motion, and then you step in and help them take those environments to a more repeatable stamped out model? Yep. So it depends on the customer, obviously. Some customers are already using doing ClickOps and they're already in Azure. ClickOps? Yeah. We call it ClickOps. Yeah. Yeah. And the port then the portal just and then you show them the value of Bicep and you show them how you can repeat the environment. Because I always I always worry that potentially a region may go down. You never know. And they're in West Europe and they might need to move to North Europe. And if you've deployed that by hand using ClickOps, how do you remember all the settings? The person who's deployed it might move on from the company and then you're kinda left not sure what to do. So I will show them that from a PowerShell file, we call our Bicep templates. We deploy dev. We roll it out. They kinda have a look at it. They check the settings. They deploy their workload on top of that. All good. Then we move on to acceptance and production. So once they see the value of it, they're all in. And when I'm doing my architecture designs upfront, I always put in a section about why infrastructure of code's important, and they kinda get it. The the buy in to nobody's ever said, no. We're doing click ops. But what I still see is sometimes I'll deploy dev acceptance prod and some people manually change things, and then then they realize that there's drift. And then when they deploy the resources, all of a sudden acceptance isn't working, but dev is. And then they're like, yeah, what's going on? And then you have to show them, like, you have to use infrastructure as code, you have to use build pipelines, no touch deployment, like, but but I always want to do click ups to get things working quickly. I I get that. But sometimes you just have to, like, teach these people that that's gonna lead to pain. So, yeah, we've we've had a customer recently who we deployed dev acceptance and prod. We set up the workload and then they manually changed some things and, like, dev and acceptance was was working but dev wasn't and then it was because of the changes. Yeah. So just a learning curve, but that's the way to go. E easier to click run once on a pipeline Yeah. Or or an action than it is to click next, next, next, next, next, next Well, we have we have 10 web apps and one of the customers was basically changing all the settings on the web apps and acceptance and dev was working and acceptance wasn't. And sometimes it's difficult to compare two different environments, and they're in the same region and they're in the same subscription, but, I'm sorry, they're different subscriptions, but, yeah, for for, like, web apps, there's a lot of settings, and I had to go through and manually compare them all. And, yeah, that was a bit of a painful exercise, but you kinda teach them that that's not the way to go. So we've kinda put delete locks in them or or making sure that there's PIN so that they don't they don't have access to go and do things unless they elevate and and and do that kind of stuff. Gotcha. Do you also find that you like, maybe those more traditional migration customers to teach them a little bit about I I imagine you need to wear a little bit of your software development hat and and kinda get into software development life cycle Yep. Because infrastructure as code Mhmm. That needs to live someplace. Yep. That that Bicep file and the history of it and the versioning of it, it's Yep. Gotta be in Azure DevOps or GitHub or hopefully some type of repository that's not your OneDrive or your desktop or a little thumb drive over in the corner. Yeah. That's the thing. You you have to source control the the infrastructure as code. And then, normally, what I do is internally, where I work, we we will create the repos for our customers. And then I'll I'll lay all the bicep. And then if they want, we'll give them the bicep and put it into their Azure DevOps, and then they can run pipelines. But we tend to do it in our repos. So it's me that's writing all of the code, and then they just they just review it and and check it. But, yeah, it needs to make sure that it's source controlled without doing proper proper proper pull requests and and rep approvals and all that kind of good stuff. Yeah. I also help build the pipelines for them because a lot of customers like, we've got infrastructure as code, but how do we deploy it? It's like, they don't want I'm gonna introduce you to our friend Gamel. Yeah. They they don't want me to deploy to production from my machine, which is totally fine. Well, I have to set up the pipelines for them, and then sometimes customers don't know how to do that as well. So I will build the ammo and build all the pipelines for them, and then then they're in a good place. But sometimes they just don't quite understand because on on prem, they're just manually changing things, and then they wanna do the same in the cloud. And they're like, no. Please don't. That's not really best practice. So so I learn and you just have to keep keep on the on this case and make sure they're doing the right things. It's quite funny sometimes. That reminds me of like sitting down with my kids maybe and like, no, don't do that. Yeah. Exactly. I I really need you to go do your homework. I mean, you tell them don't do that, they'll let it. But we've got it working then. And I'm like, yeah. You got it working, but it's not repeatable. And and eventually, it's things in that they need to do things properly. Gotcha. Yeah. Do you feel overwhelmed by trying to manage your Office three sixty five environment? Are you facing unexpected issues that disrupt your company's productivity? Intelligink 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 intelleginc.com/podcast. That's intelligink,.com/podcast for more information or to schedule a thirty minute call to get started with them today. Remember, Intelligink focuses on the Microsoft cloud so you can focus on your business. And how much do you find that you you you kinda spend your time just keeping up with the churn of Azure? And and as you see so you mentioned maybe, like, deploying, like, a web app for a customer, and they had two environments and a setting changed over here and over here. Web apps are also changing as as they go, things like that. Like, how do you think about that as an architect and incorporating maybe additional parameters into your templates and Yeah. It's it's challenging. Yeah. I mean, I I do a lot of training and and when you're doing training and have the slides and you're like, let's go into a storage account and deploy a storage account and the settings will change because the the the UI of the the portal updates quite a lot and yeah. It's challenging. It definitely is. So to kinda keep on top of that, we are making use of what's called the Azure verified modules. So within Bicep, Microsoft are working on this Bicep kind of ex they extract the modules for you, they write the modules for you, and then we just call them. So they've got an ongoing GitHub project called Azure Verified Modules. They've pretty much got all of the Azure resources built, and we just call that. So we make use of that, which is which is awesome. Going forward, Microsoft are kinda trying to push everybody towards using Azure Verified Modules. So that helps a lot. So, yeah. So I I work in Azure storage. Mhmm. I'm I'm one of the people that signs off on those on the on those verified modules for for the team that that builds them and pushes them out there. I think it's a a very interesting model that that's kind of moving there. If you think about, like, being a customer in the past, you might have gone to Microsoft and read the documentation or landed up in a samples repo, things like that. But you were largely left to your own devices. Yep. And and sure, there's support there. Yep. And and you can reach out to CSS, but they might have to Microsoft customer support. But they they kinda have to do some debugging and and things with you along the way. So one of one of the niceties of AVM or those Azure Terraform modules in there Terraform modules in there as well. So it's not just Bicep. It's Bicep and Terraform. They're there. And and one of the things that I like about those is not only the kind of nice sample nature that's there, they've also implemented a bunch of best practices and learnings that come in. Like, I I know when we were working on the storage modules and kind of working through that partnership, there was a lot of kind of things around best practices, best default state. What's what's what's just like the best configuration? If somebody picked this up and they did a fire and forget deployment, what's the best state that customer needs to be in and where they need to be? So there there's a lot of that in there as well. Like, zone of resiliency is a consideration from the front and being able to tie that all together. So I I think as AVM matures, it'll definitely become a a good place for customers to to look to. I have a lot of my customers come to me today and say, why EVM? Especially my Terraform customers, why EVM versus the HashiCorp modules or the or or something else that's out there in open source. And, really, I think the biggest thing is the supportability built, maintained, supported by Microsoft, and customers get that support as well. So I'd encourage anybody to go out and take a look at APM. Some of the modules are kind of in a beta state, alpha state. They're they're they're in various states of release. But as that gets sealed up across all the services that are out there, it becomes kind of a broader ecosystem over time. One of the best things I think is you can you can put that in a design for a customer. So I'm designing right now, design document, I can tell them all this. And the documentation for the Azure verified modules references the Well Architected Framework. And one of the best things about the docs for EVM is you can go to usage examples and the bot one is always well well architected framework and it shows you the Bicep. So the docs for Bicep alone are sometimes a little bit tricky to to figure out what is the ID reference, what is what it says it's an array, the property might say an array and you're not sure what goes in that array. But the AVM, the well architected framework, has very nice examples of how to deploy things with best practice in mind to that. That's one of the keys of using it, I think. Yeah. And it will it will make it better going forward. Yeah. Yeah. Not just just raised, but, like, the the fixed enums, the fixed values. I think it's a kind of good set of, if not best practices, certainly like guardrails or referential material. Yep. In the case of, like, a storage account, you you don't we might want the underscore, like, standard underscore LRS versus just standard LRS. Like, whatever it happens to be as as you're pumping those things through. I I I'm curious because you you you mentioned kind of architectural docs and design docs and things like that. Do you take advantage of kind of any of the tooling that's out there? Maybe do you have a favorite one for, like, visualizing your templates and the resources that are visualizing, I Yeah. Sometimes I just when I deploy the bicep in Visual Studio Code, you can get a a resource visualizer. But one tool I'd really like to call out is what's called the AZ quick review, AZ QR. I don't know if not a lot of people know about this. I have not heard of this. So it's an ex It's a cool name. It's a GitHub project. It's a open source GitHub project. And if you run that, so what we do is we run this tool after we've built the the bicep. We've run the pipeline. The last step of the pipeline is you can point it at your subscription where you've just deployed it. And against the way I'll architect the framework, it'll generate a CSV that lists all the resources. It will tell you your security scores. It will recommend what you've not done, what you should do. And it's very in-depth and it is very good for finding out like, oh, I'm using service endpoints. I should really be using private endpoints. I'm not using TLS 1.3 or 1.2. It'll tell you all that good stuff that is built in. So we just call this tool. You can run it against a tenant and do all the subscriptions. You can run it against an individual subscription or you can even do it against a resource group and even a resource. And it prompts out a CSV file at the end and you redo that as part of the build. You get the art artifact from Azure DevOps, and you've got something to show the customer. And you can do that. You can run that tool at any point. So if you're not even using Bicep, you can still run the tool against your environment, and it'll give you a list of recommendations. So excellent. It's really good. I wish Microsoft would look take maybe even do something towards using something like that because it's really useful. Once you've deployed your your infrastructure's code, it basically gives you a score and says here's the good parts, here's the not so good parts. Go and fix that. And that's, again, against the well architected framework. So it's building on top of AVM as well. Gotcha. Yeah. So what what's your favorite feature in Bicep? Favorite feature in Bicep? Oh, that's a good question. Let me think. I only think. Favorite feature in Bicep. I like the Bicep parameters. So that's a kind of when you have a a main dot Bicep file, and we talked about before where you're deploying the dev environment, the test environment, and the production environment, these three environments may differ just from the the size of the VM, let's say. So the VM for dev may be like a a small VM, and then you can have a para a bisect parameter file for the the dev environment. We've also got one for acceptance and prod. So the acceptance and prod variables will consider a larger VM, more disk size, maybe an extra disk. So you can configure all that and bicep. So that means that you're deploying all these resources with three different environments with the three different settings. So that, I really like that. I think that's really cool. That's been out for a while. Yeah. It's it's a good way to rationalize things through, like, because often it's t shirt sizing. It's small, medium, large. And that's much easier for somebody to figure out than what's a d sixteen Yep. V five or v six or Yep. Oh, oh, no. A d 16 s versus a d 16. And and and you can kind of bake that logic in into your own custom enums along the way. What what do you see as kind of the biggest kind of stumbling block or or pitfall with your customers and bicep today? Like if somebody is new to it, like, what are one or two things that they should look out for? A lot of our customers believe us to write the bicep, which getting them on board is quite tricky. You just have to, like, we will write the bicep and kinda sometimes they want to take the repo off of us and look at it and and they don't have the skills to learn bicep. So scaling them on on that is is sometimes a bit of an issue. Yeah. They they just want someone else to deploy it and then then they'll they'll put their workload on. So we tend to just look at the device that fall and deploy that. So it'd be nice if some of our customers had people who learn the device as well just to just to so when we are not that not around and they want to change it, then I've got other people to do that. Gotcha. And how about when you're out there training? You mentioned you're an MCT Mhmm. So a Microsoft certified trainer. Yep. Kinda what are the things that you point out to students to look out for? In terms of In in terms of maybe maybe not pitfalls of bicep, but here's some things that you should think about. And because like any other language, like it is a domain specific language, it's got a set of constraints and kind of guardrails in it and and and rules. Yep. But those also often come with new ways of thinking about things, and here's how you have to adapt your thinking. Or the way you did it over here in Arm might be a little bit an Arm template, a resource manager template might be Mainly around structuring the code. So what I like to do is I put all the parameters at the top, and then I'll have the variables, and then I'll draw like a line and the styles across the code, and no hard coding from that point onwards. So I try and teach people to make sure that the modules that you're calling, there's no hard coded locations. It's all parameterized at the top. It's all well documented. In Versus Code, you can use, a Versus Code Copilot and you can get it to document everything for you. Put descriptions above all your modules so that everyone knows what what the code does. I'm a firm believer of leave the code in a good state so that some if I'm off, someone could pick up the bicep and try and figure out what it's doing. I'll generate a diagram as well and put leave that in the repo so people can see what I've deployed. Some of the pitfalls I always think are when you're using Versus Code as a beginner in anything, they say generate generate this for me and you never really learned, you know, I'm always worried that like you can let it fly from reading a book, but the minute you're sitting in a cockpit and try and fly a plane, you really struggle. So you need to get hands on and learn what things do. A good example is in a module in Bicep, you have the name of the module, you have the name of the deployment, and you have the name of the, like, the storage account for example, and those three names are different. And I see a lot of people creating the module called create storage and then they'll put the name of the deployment, create storage, and then put the name of the storage account, create storage, and then they'll start there and go, why is that not working? Because they haven't learned the reason these three parameters are slightly different even though they're all called name. So So, yeah, there are one or two pitfalls of learning it. But the other thing to do is if you're really stuck, deploy the resource using ClickOps and then go into the arm. You can export the template. Now the feature's coming out, but you can click on generate bicep and it'll actually show you the bicep. So sometimes you need to figure out, like, a good example might be TD encryption SQL Server. You deploy in the portal. You type the you type the portal, and then you can see the bicep and see what the setting is to turn that on. And that that's always a good way of kind of reverse engineering your bicep. I think if you're doing things like Azure firewall rule collections, the the documentation is quite tricky to kind of follow it. So you you deploy it by hand and then work out what goes where and then it needs to be in the right order. So that's that's always that's always a good way of doing it as well. That's one of the biggest pitfalls is figuring out what does the parameter mean? What what's it expecting? Yeah. Yeah. I do that with customers a lot. They they come in often they they I I think their intentions are good. Mhmm. So and and I I tend to be the same way. Like, I I'd rather get hands on with it than go read a book about it. Yep. And so I'll often just start opening Versus Code and and then, oh, it doesn't work. It's broken. But that trick of going to the portal and let me see how the portal does it because I I always used to when I was a trainer and and doing the the infrastructure exams, the the one point I always wanted my students to take away was the Azure portal, when you're deploying something or you are updating something, it is an ARM expression generator. Yep. So it it's great at expressing those values in a way that, like, you can go get to the end and and get the template. Get the ARM template. Great to hear that they've got get a bicep template coming. That that that's certainly a a nicety that's there. You also mentioned working in Versus Code, GitHub, Copilot, things like that. I haven't played around with ARM templates too much or really gotten hands on with with Bicep with GitHub Copilot, but I do a lot of PowerShell and Bash. Super helpful there. What's your experience been? Is is it a good Oh, fabulous. Good augmentor Yes. Where even for, like, new thing where it's Yeah. Yeah. You can actually one of the things that people might not know is I talked about AVM modules. You can go into GitHub Copilot and reference that external GitHub repo and ask it to generate bicep based off of that project. So instead of it gen writing generic bicep, it'll actually write bicep that's targeting the Azure verified modules, which is really good. So I use it to generate documentation. If I'm doing if I'm even if I'm doing bash scripts or I'm looking at someone else's script, I always do slash explain and it'll it'll explain to me what the script's doing. That's also very helpful. Mainly generate documentation, putting your variables at the top, making sure there's descriptions on everything, and kind of explaining I was trying to write a little bit at the top of the file on explaining what I'm trying to do. Like, what I've maybe I've taken a what I sometimes do is I'll go to the Azure Architecture Center. I'll look for the zero trust diagram. I'll deploy that as an example when I'm teaching someone Bicep, and I'll put in the link to the diagram, explain all of the resources at the top of the the Bicep file so that people have got some understanding before it's doing. Because that's what I tend to see is when people are deploying Bicep for the first time, they don't know how to make resources talk to each other. So someone will create a storage account, someone will create a manager of the entity and a SQL Server, and then they'll say, how do I get the manager of the entity to talk to the SQL Server to get to go to the storage account? And then that's where it starts to get tricky. You you just need to read the docs and spend a lot of time in figuring it out or deploy it manually and reverse engineer. That's that's the way forward. I think it's always been hard to figure out the Mhmm. Dependencies. Yep. And I don't know if there's just an easier way to do it. It's just the the way the system comes. Yep. If I give you a bunch of Legos, your Lego house needs to look different than mine sometimes. Yep. And sometimes that just turns into, like, oh, we dumped the whole thing out in front of us, and now we now we gotta figure out how that composes and and and how all that goes. Some of the other nice things is the Bicep configuration files. So if you're not used to that or you don't know about that, you can add a configuration file where you can say, like, don't show warnings. You can say, only use the latest version of AVM modules. That's a nice one. So if a new version of the module comes out, your code won't build and you have to go and change the code or you can make an error or a warning. Kinda kinda like, you know, I I might with the container. Yeah. Exactly. Say, hey, play all the latest image tag kind of thing. The one thing that we were talking about earlier is it would be nice to know if the underlying API has changed from version 0.12 to 0.13, what are the changes? That's one thing we've we've we've asked for for some sort of feedback on, like, what was the difference between the previous API and this API? Because nobody really knows and it's really hard to find the docs. So that that would be an interesting nice change. I use I use Copilot all the time. And the more you use it, it starts to get frightening. You you start you may write Bicep for an Azure Firewall and it just knows that you're gonna write an Azure Firewall policy next. It's like it's like how did you know that? It's really, really smart. It's super useful and saves a lot of time. Thanks for taking the time to chat with me today. Thanks for having me. Let you get back over to MVP Summit and get some good learnings and and give us some good feedback and Will do. Thanks for coming in. Thank you. Thanks for having me. 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 three sixty five 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.

Donate