Go back

Unified Tenant Management with Nik Charlebois-Laprade

33m 33s

Unified Tenant Management with Nik Charlebois-Laprade

The transcription is from an episode of RunAsRadio featuring a conversation between host Richard Campbell and guest Nick Charlotte Bois, a principal program manager at Microsoft. They discuss the challenges of managing configuration drift in Microsoft 365 tenants, where settings can unintentionally change over time. The guest explains the evolution from an open-source tool called Microsoft 365 Desired State Configuration (DSC), which required PowerShell expertise, to a new official product in public preview: Unified Tenant Management exposed via Microsoft Graph APIs. This new solution allows IT professionals to take snapshots of tenant configurations, monitor for drifts, and manage settings at scale across multiple tenants—such as synchronizing development and production environments or managing hundreds of customer tenants. The goal is to provide a supported, easier-to-use platform that integrates with existing DevOps pipelines, though automated drift remediation is planned for a future release. The conversation also touches on practical use cases, like using temporary tenants for safe testing and training.

Transcription

6471 Words, 35452 Characters

English
[Music] From RunAsRadio.com, you're listening to RunAsRadio. The Internet Audio Talk Show for IT professionals with Richard Campbell. This is Brandon Wen announcing show 1029, Unified Tenant Management with guest, Nick, Charlotte Bois, La Pra day, Recorded Friday, February 13, 2026. RunAsRadio is produced each week by Sound Thoughts LLC. For more information, visit soundthoughtsLC.com. You can follow us on [email protected]/runasradio. [Music] Hi, this is Richard Campbell. Thanks for listening to RunAsRadio. After entirely too long, last show is 2020. Bring it back, my friend, Nick. It's Charlotte Bois. You did it. Charlotte Bois. Close enough. Charlotte Bois, La Pra day, too, right? Oh, I mean, you can't forget to get formal about it. You're so kebacua, man. You kill me. [Laughter] Because there's a very normal part of kebacua culture that you blend your names together when you get married, right? And you've been married for a while. I just never had said the full name before. My wife has two last names as well, right? So magic and speech. We literally did draw a name out of the hat for the kids. Oh, okay. Just sort of could solidate it together. I love that. That's awesome. It's one of the many parts that kebacua culture for folks who haven't ever spent any time there. But, I mean, once upon a time, you were a premier field engineer, which in my opinion is the best job of Microsoft, but they've largely done away with that title now. Today, a principal program manager at Microsoft, leading the Microsoft 365 cura configuration as code efforts, but a former MVP, a speaker, a blogger, an author, and he leads configuration code efforts for M365. Thanks for coming on, friend. Hey, thanks for having me. So I can't believe it's been that long. I was actually one that was last show. So it's been over six years now. Yeah. Yeah. And we're past episode 1000 now. Like this show's been going on for a while. Yeah. Okay. Next April will be 20 years of run as radio. Okay. Well, we'll have to make sure that I come back later this year, or early next next year to actually talk about some of the real things that I've been doing. I'm not going to be shipping, but yeah, it's been way too long. Oh, for sure. I mean, the, I mean, the reality these days with M365 is like the, there's so much to deploy. Like the product only gets bigger. They keep adding more to it. So I appreciate the whole configuration control system just because there's so many options. You're poor at men's here just trying to keep hand a lot of it. Yeah. So it's fun, right? So I was actually, you mentioned that it's been that long. I was looking at thing to very first show was in 2018. And then we did that one. The first one was on the first. Yeah. You were the driver behind reverse DSC from the outset. I was right. And then second show we had was on the open source. Microsoft 365 is our stake in television. It was kind of using the. So it's in line. Well, we're going to be talking about today. Still in line with what I've been talking about on the previous show. And it's kind of the evolution of these all open source project. I've just trying to maintain consistent configuration knowing it's going to drift. And how do you resist that? Exactly. Yeah. And that is a problem that most enterprises are facing still in 2026, right? Sure. No. I mean, it seems silly at the time. It's like, why is this a big deal? It's like, because it is because things happen. Even in, I mean, I remember talking about reverse DSC from the concept concept of WebFarm. Right. Back when that was a thing, we'd have a set of web servers. And it's like, well, these are all going to be identical. They're literally identical hardware. They're in the same rack. We could figure out the same image. And then you go and look at them after a few months of operation. And they are not the same. Like, stuff happens. Big time. Right. That's not like. Yeah. That's not like, effect happens right moment. You give the keys back to the, the, the, the, the, the, the, the, right. I mean, that's just nature of things. Things will actually drift. But the goal here is kind of keep some control over that drift. Right. And, and, and, and at least be aware when it does happen, right? Like, just that indicator that something's gone on and it's, it's delightful. I mean, I see it as a smaller problem these days when we're living in container land and very much like servers as cattle where the fact that we're updating these machines weekly or even daily means they never live long enough to drift anymore. They're going to be wiped out and rebuilt in the matter of hours. Sure. Yeah. It's a little different when you're talking about, like platform service or software and service like what we have here, right? So the thing is, you can't just go and, and kill the container and then just restore it, right? So you get away, there's got to be a way to actually take a snapshot of your configuration and make sure that this doesn't drift, right? So there needs to be a point in time where you say, my tenant is currently configured like I wanted to and anything that changes moving forward, that becomes a drift, right? Yeah. Yeah. And I think that that was always the conversation we had from the outset. It's like how it's one thing to lay out what I want to make a configuration. It's another thing to point at an existing instance and say, snapshot that configuration and keep it that way for me. Yeah. Yeah. Exactly. So when you're talking about tenant management, are we talking about a given organization having sort of always ends up with multiple tenants and how do they keep that configuration in sync? That could be one scenario. That is definitely one scenario. We do have customers right now that are managing say hundreds of tenants, right? Oh, I get this. And you need to be the next. So what they want to do is they want to have a golden image and make sure that all of these tenants are in sync. Right. We'll have organizations when it's want to do is kind of manage outstate verticals, right? Where you would actually have say a prod tenant, where you would have a dedicated dev or sandbox tenant that needs to be in sync with that product, but you would have multiple verticals like this. And it's being able to make sure that they're all in sync, but also be able to promote some of the changes, right? You want to make sure that you test your stuff in your sandbox environment. If there's a new feature that gets released and you want to understand what the behavior is going to be on the rest of the organization, you go and try it out in that sandbox tenant, then once you're fine with the change, you actually go and you promote it to the next era, which is your production. Okay. And so people are actually using tenants as the barrier between those different roles in an organization. Like that is it treating me like I'm used to a pre-prod resource group. But I mean, I got to admit, if you're in a separate tenant, your chances of crossing between them are extremely low. Like it has to be very intentional to get a from tenant to tenant. You're absolutely right, right? But that is the nature of things. A lot of folks will use this for training purposes, right? For example, when you're on your features, they want people to go and try it out with data that is not production data, right? So they'll have a site. And there's nowhere near the production system. It's literally in a different tenant. So you go do what you want. You can't hurt anything in here. Exactly, right? Then we also have that's an era where a lot of dev folks will go and they'll create like a trial or 90-day temporary tenant where they would just want to be able to clone the settings from production. So imagine that's an era where you go and you take a snapshot of your prod settings. You replicate that on a dev box, right? That is a temporary 90-day trial. Right. You go, you have to do whatever development, if you're deploying some types of, say, teams app. For example, you try that in there. And then once it's done, you just promote it to prod and that tenant disappear. So going back to that concept of container previously, I mean, the lifespan is a little different. But still you're able to spin off those temporary tenants. Yeah. Do your stuff in there and then just let them expire. Yeah, tenant as container. That's bad-ass. That's really cool. But I get it. As soon as you say it, it's like, oh, that's obvious. I should do that just because the lines are very, very clear. And also recreating in a different tenant means you really do have a real clear template. You really got all of the code there to remake that configuration somewhere else. Yeah, exactly, right? And that is a very common scenario. Like I mentioned previously, taking a snapshot of an environment. A lot of customers I talked to that they're mentioning that they do have those sandbox tenants. The first question I have is, how line configuration wise is that dev tenant, which are pro-tenant? And the answer is always the same thing. It's completely out of sync. To a point where it doesn't even make sense for us to test anything in that sandbox tenant anymore. So what a lot of these folks will do is they'll take a snapshot of production, a fresh snapshot of the config. They'll overwrite what's in the dev tenant, making sure that they're now in sync. And then from that point on, they'll start promoting changes from their back-up to production. Okay. Yeah. So I mean, the safe way, again, production is, production is, we're working fine. We want to make significant changes. So we're basically snapshotting production, putting it somewhere else, doing whatever we want to do to it. And then deciding, is this now all going to be production? Exactly. And then it's just rolling over DNS settings, I imagine. Because that always goes well. Exactly. Okay. So what are the snapshotting tools? How do we do this? Yeah. So basically, I mentioned previously that I think the last show was, I think it was in May 2020, right? From what we've talked about, this open source solution of mine called Microsoft 365. five desired state configuration. And the promise there is that the tool will allow you to do what we call snapshots. So essentially the backup of an existing tenants configuration. So it will go and it will analyze the current state of the settings on the tenant and at the end of it, it will output a configured code representation of those settings. So the current state of that environment. So that's the main feature that the solution offered. Then there's of course the way to be able to go and push out config changes at scale. So we'll give you the example previously of that customer that manages hundreds of tenants. You manage a single config, a scope template. You make a change there and automatically gets propagated to those hundred tenants without you having to log into each one and maybe change. Wow. And then the last one is of course monitoring. Being able to continuously run a scheduled type of job that will go and detect any unwanted configuration and be able to act upon it. So for example, if you define that, if you want to make sure you have your conditional access policy that enforces NFA on all users with the exception of such group, somebody goes in and for by mistake adds another group in there. You definitely don't want to disable and make a favor that group. So that is treated as a drift say the tool detects it and automatically goes and updates that policy so that that group gets removed. So that becomes your source of truth to manage all the config for your tenants. Interesting. Okay. And would this be sort of a once a day thing and then would it remove the group or would it apply MFA to it in the air scenario? Well, that's an error. So let's say the excluded groups. All right. You're defining in your template. You're saying that only the say security in men group needs to be excluded. I'm sorry. The group that should be MFA the most, but okay. Let's use the included groups. In this case, you have some. Okay. Let's say included group, but then somebody goes in and adds a second group to it. Right. Right. And your template, your configuration says that should only be one group. So that would be your configuration drift there. And then the tool would go and essentially reapply to good known configuration, which only contains one group. So effectively, we're going to second. Right. So the other group would die. So in a nutshell, this is the feature set that the open source solution offered. One of the challenge we had with the open source solution was well, first off, the support. Right. So that was being maintained by the community, led by Microsoft, but maintained by the community. So there was no real SLA around it. If you want to open a support case, it was really best effort where you had to go and get up open and issue it. And our team would get to it when we got time. Sure. But there was no true official support. So that was number one. Second thing is the learning curve. With the open source solution, everything was based on PowerShell. So you need to be fluent in PowerShell, which to be honest, the audience that we're targeting are mostly IT and men. So that was never really a problem. Right. But then you need to understand the desired state configuration aspect on top of it. And then all the different things that were specific to the Microsoft 365 workloads. Right. So under the cover, there were about, I want to say, 20 different PowerShell modules you had to go and get and just getting started, wasn't that straightforward? Oh, wow. Yeah. Just getting the base config together is not a small thing then. Oh, that was exactly right. So what we wanted to do was really address these two items by investing and making this into an official product. So we wanted to reduce the learning curve. And we also wanted to make sure that people were able to open the support case and be fully supported. So about two years ago, our team decided to invest into building this into an official platform. Right. That would be exposed to graph APIs. So to answer your question, what you would actually go and take a snapshot today is by calling our configuration management APIs on graph. That would start a background job that would go and collect the current settings of the tenant. And at the end of it, it would go and it would output the JSON representation of what the configuration of that tenant looks like. Okay. Same goals as trying to monitor. Right. So you can actually go and create a scheduled job that would go and monitor your tenant. Again, all exposed to graph APIs. That's cool. All right. So this is now because I've got the link to the M365DSC, which I think was the open source product. It still exists. But then also in-learn there is the unified tenant configuration under graph. And that is the officially supported product. That is correct. Right. So right now we earned public preview. Public preview was launched back in January 27th. Right. So about by the time of recording this about two weeks back. So this is public preview right now. Fully supported. You can go and use it in any of your tenants that you have. So you can go and start getting snapshot. The one thing we don't have as part of public preview today is the ability to remediate Drifts. Right. So we'll let you detect Drift. We'll actually let you go and retrieve details about those Drifts. But the ability to have the tool or might be fixed them is not yet in the preview. It will come out later. Okay. That's fair. But you know, it's still you're formalizing this thing that's been I mean, haunting your dreams for ages. So. Yeah. But just in talking to customers, right? I mean, this was a long time coming. Like this is something that people have been asking for for years. The ability to just be able to control all those settings. Right. Beyond top of that, be able to manage multiple tenants. Right. Be able to see what differences you have between tenants. So this is a problem. The team has been trying to solve for many years now. But we decided to invest in building this into an official product. Nice. All right. I get it. Okay. With that, we should take a brief break for these most important messages. Reimagine what's possible for your career, your team, your business, and for work itself at the Microsoft 365 Community Conference April 21st to 23rd, 2026 at the Low Sapphire Falls Resort in Orlando, connect with hundreds of Microsoft executives, subject matter experts and product makers to unlock solutions to accelerate your AI transformation. The Microsoft 365 Community Conference is your opportunity to spark inspiration, build connections and deepen your skills, feature speakers at the Microsoft 365 Community Conference include Jeff Teeper, president of Microsoft collaborative apps and platforms, Adam Harmaz, vice president of product, Carolina Gautima, director of M365 customer advocacy and Heather Cook, principal PM manager of global community evangelism for M365. Let's just to run as radio can get a discount on registration by using the code run as at m365.com. The Microsoft 365 Community Conference is at the Low Sapphire Falls Resort in Orlando, April 21 to 23rd, 2026 go to m365.com to register. And we're back. It's running as radio. I'm Richard Campbell. Let's Nick Shalibra, and we are talking a little bit about this Microsoft Graph preview of unified tenant configuration management. So this is a set of APIs. It's got a dashboard as well. Like you do give me a view of what's going on. And this is something we're working on. So right now, the preview is API based. We will be working on an actual user interface. So you can imagine down the road having some central place where you can go and view the drifts across all the tenants that you manage, be able to manage them, be able to remediate them, tenant by tenant if you want to. So we are working on this. But right now, the solution is API based. Because that was the first part we wanted to release. So that people can start right now replacing some of the workflows they have that are using Microsoft Graph 365 ESC, start calling those instead. Because at the end of the day, this really integrates with some of the application lifecycle management tooling that you have in your organization. Right. You will want to say manage that configuration file, that source of truth. You want to manage it in something like Azure DevOps GitHub where you actually have version history where you're able to make changes, submit that as a pull requires that gets approved, then wants to get to prove a workflow or pipeline gets triggered, calls our APIs and actually go and deploy that change. So that's the first part is having the APIs out when you want to. It also seems like that's the majority of your customers right now. They've already been solving this problem. They've rolled their own bits, working with open source tools and stuff they've done themselves. And now you're giving them an official set of APIs to work from to adapt to. That's exactly it. Like right now, on one point with the open source solution, there needs to be a point in your pipeline where you're going to go and execute a command called star DSC, right? Basically go and apply this and this runs locally on an agent or on a machine you can spin it off in containers. But basically this starts a power shell process. Right. What we're saying is now we're replacing this by an API call. So we want to get that in the customer's hand as soon as possible so that they can start replacing some of the bits of their logic and their pipeline to start calling our UTM APIs. My presumption is a graph API call is going to be faster than a power shell invoke, but that's a pretty good thing. It really is, right? And the other thing we're doing is we're doing a lot of improvements on performance aspect, whereas with the power shell solution to have DSC unfortunately runs on something. But the version of DSC we were using was using something called local configuration manager. So serve as that run on the machine itself and that was all sequential. Right. So the configuration was executed from beginning to end in a sequential order, whereas now we're basically executed in bunch of stuff in parallel. So performance wise, it's not even comparable. Yeah, no, again, if I can't imagine several with hundreds of tenants, but clearly you've seen this that people are doing this. The interface and approach to this is going to vary between I have four tenants, right? My dev training prod, pre-prod, prod kind of thing versus I have a couple of tenants for every customer I've God and its hundreds or so. 1000. Yeah, no, yeah, but so I mean we do have customers right that are using a solution to manage just a single tenant as well. I want to make sure this is not something we're positioning as in multi-tenant only solution. Right. What you're right. We do have customers that scale to the thousands of tenants as well. We want to make sure that this scales however you see fit. So yeah, I mean the customer I was mentioning there 800 that is not at typical. We have customers that do way more than hundreds of tenants. Yeah, yeah, yeah, and the visualizer for that is a different follow-axe. It really is right and that's why we don't have the UI as well that we're talking about visualizing this from a UI perspective as well. Right. How do you actually go and you drift across thousands of tenants? That is a challenge that our designers are trying to solve. But yeah, you're right. But again, there's this piece that's missing today is being able to have that single pane of glass across all the tenants that you manage. Right. And that's what we're building with that UI that's that we'll be coming later. I mean it is essence is nice to visualize. The most important thing is do I know where the drift is? Do I know how to correct the drift? And do I have some kind of record of who's drifting most often like? Yeah, I'm wondering if this is the another part of a Sentinel or a scene piece. It's like wow, something's happening with these tenants. They're constantly drifting. There's some there may be a bad actor involved there. Yeah, I mean, those are type of signals that the solution will provide. Right. So absolutely. Yeah, we and we integrate with all these seems systems and stuff. So you can get the logs and you can ingest that into whatever type of detection mechanism you have in place. So yeah, yeah, feed that back into Defender in some way. I mean, also I'm thinking we don't really have a golden image. Right. Like any organization running this, they've probably got a dozen or at least three or four, right. They have a V2 and a V3 and a V4. Different customers at different places. Like there's goldens free. You're getting from hundreds to a few. But you demand part of that manager problem is going well, how many people are still in V2? Like I've been here with products with various customers where it's like we really want to get you over to V3. But we have to keep care of these V2 guys. And they've got all the same drift problems and so forth. So multiple golds depending on the customer. It's just a hard problem. Yeah. And you bring up a good point. One thing I want to point out is that the unified 10 configuration management APIs that we're building are not going to do the file management piece. Right. So being able to version your templates and stuff, that's not the business work. Yeah. We have all the tools out there that will do a better job. Right. This is more about the process of the organization. Basically what we do is we take the template you have and we apply it to the tenant. Right. Yeah. So your management of the templates is up to you. You're the tool that says put this template where I want it to be put. Exactly. Right. We have customers that told us from the get go look we're going to use your tools to take daily backups of our tenants. Well the thing is right now when you take a snapshot that file is available for seven days for you to retrieve after that we purge the results. So it's not as if you can use the APIs as a file management system or as storage. Right. You're responsible for grabbing that content that we've generated from that time. It's storing it somewhere safe. That you can actually now use as your source to our Azure backup. I'll pick or these snapshots. I'm just contemplating that. It can be big. Some of them can be very big depending on what you're backing up. Right. Right. That is always the challenge is figuring out where to draw the line. Yeah. I'll give you an example. Right now some of the things we allow you to manage to monitor our groups users and stuff like this. Of course you don't want to go and monitor 100,000 users. But there are certain and users that are critical right that you want to make sure you have some groups as well. So we allow you to manage those specific groups. We don't allow you to go and back up 100,000 groups. That's definitely not what the tool is next to work. However if you're starting to take a snapshot and the snapshots are very granular by the way. So you can go and say I want to capture all of my entry and decedings that will give you a fairly big snapshot. You could even go and say I want to capture all my entry, all my team stuff in one snapshot that will also work. It will make for a large file. But you can go. Is that MIGs or gigs? So it would be MIGs. It would be MIGs. We still have MIGs. We still have the limit of about, I believe it's around 158 that we can return. So there's a limit where we can look this snapshot is going to and we don't want it to run forever either. So it's not. No, no. And you've got to haul those files around and there could be 100's of them. So all this costs. Yeah, exactly. And so we have to draw the line somewhere. But those files can be up fairly big. Yeah. Yeah. Yeah. And again, it's because you've got a bunch of them and you're doing comparisons with them. Exactly. Yeah. And the one thing I should mention as well is I just mentioned that the file will contain settings about say, "Entreall your team's stuff." The files themselves reside within the tenant. So they're not as important as an external store or something. And the only way for you to go and retrieve those snapshots is again by calling her APIs. So every time you call her APIs, we evaluate the permissions. Right. So what I mean by this is not as if anybody in the organization can then go and retrieve a snapshot that was created. Right. They need to have really permissions for what's in that snapshot. So if you're backing up exchange configuration, well, you need to be an exchange to be able to retrieve your global reader. But something that gives you read access to the settings contained within it. And some of it could be sensitive information, right? Well, without a doubt. I mean, it's not the data itself, but configuration is configuration. It has knowledge of the system. So it's an issue. Certainly exploitable. And they are fairly secured. Like I would also think everything about that is audited because it's not that common. So, you know, log it all. It can even be red flashy light kind of. We only do this once in a while. So it's a big deal. Everybody gets notified when it's happening. But yeah, you know, you do want automation around this because it's got to be done routinely. You got to catch drift as often as possible. Yeah. Yeah. Okay. Now you got my head spinning again. It's just like, oh, all these possibilities for shepherding all of that stuff at once and being able to push it back into configuration. And then be able to go in and say, well, what happened? Like, why did we drift? Press against it. And one thing that that's probably worth mentioning here is that today we right now during preview, we support some of the major workloads so that would be an ID exchange online into teams. We have some defender. We have purview support for SharePoint. One drive will be coming. But we do have plans to extend beyond just that moving forward. Right. We have plans to even touch some of the other clouds as well. So things like fabric, things like some of the configuration around Azure DevOps. Azure DevOps itself has some settings, right? That's probably one one. So we have plans both GA to go and expand to all of those other workloads as well. Yeah. And it's just in the Azure world. Like there's so much there's so much to explore there. There's more that. Yeah. But we got to make sure you don't overstep on arm templates. Right. So that's all. Yeah. So yeah. Yeah. You've definitely got an interesting line as to what what you're going to responsible, what you're not going to use for core. Because this is mostly about M365 stuff. It is. But clearly people are going to want more. Of course. You know, you mentioned fabric explicitly. But you know, info workers are info workers. And the fabric falls in their cap purview as well. Yeah. But this is not so much targeted at a a production scaled website. Like I use reverse DSC for that. But this is a little different. And yes, yes. So the scale is a little different here. Right. Yeah. Most subo managing the tenant drift and how they can figure out the sort of the things. What's the big customer here? Is this like management companies that manage tenants for customers? They would be the ones using this tool. I mean, that is definitely one of the heroes in error, right? That we are looking at. But anybody that has, like as I mentioned, like we have customers right now using the API, it's managed a single tenant. Sure. Some customers only have that one production tenant and they want to manage it. Right. Being able to be aware of what's there. Some users are even just using the snapshot tool to do auditing. Right. They're not even using it to manage or to monitor the configuration. You just want to be able to take snapshots and do audits and playing time. Well, yeah. Just to have a graph of how the configuration has changed, not even talking about reverting anything, but no. Yeah. This is what changed and win. Yeah. Well, okay. So that brings up with point, right? A lot of customers mentioned that that was once in error. Where they want to go and do a snapshot say the first of every month and then compare it with what was there the month before. Now that shouldn't be your change management. No. Um, solution, right? I mean, if you have good change management processes, nothing should come as a surprise. But yes. No. This is an audit to change manager. Exactly. Right. Yeah. So that's definitely once in a while. But to answer your initial question, any enterprise customers really like bigger small. It's anybody that wants to have some control over their configuration settings and make sure that nobody goes in and changes something without following the official process. If you're getting real about doing config is code, all your changes should be done to configure scope. Sure. No more point and click. No more ad hoc power. So I'll script running on your IT and then machines. Yeah. Now this is the way to hunt that down that people are still fudging configuration. Now I do appreciate that this is the tool for auditing a change management process. Like we've here's a set of changes as we've outlined they were going to they were going to occur that should result in this state. Now what's our actual state? Exactly. compare the two. Yeah. And that's, you know, it's, that's the difference between looking at the totals at the bottom of the spreadsheet and looking through the number. So you know, both are, you know, you want to validate that way, like it should get to, it should be the same number. It's almost certainly not. So now you can go through and find out, well, why? What's the thing that people are still fludging that isn't in part of the automation or needs to be changed or has some other cause of drift? Get exactly one of the things that we are working on and this is not something we have right now, but it's to cross reference with some of the other audit logs, right? It's one thing to know when a drift happens. It's another thing to go because right now you can still do it, but it's a lot of manual hunting where you need to figure out who may change what principle, what user might that change? Yeah. That information is there is just right now we don't have a cross reference between the signal that we get and that information, but that is, of course, something we're working towards so that when you get a drift, you also know who that that principle is, right? What I call the the finger pointing feature, right? Right. Being so it don't likely without you having to spend another 15 minutes trying to hunt that data down. Well, that's sometimes really difficult. And again, it's like doing the spreadsheet compare. There's a difference in checking the total saying these are different. It's another thing going through every number in that column, saying which number is different and when was it different? So yeah, they're two different mechanisms, but both are valuable. And this is just about having more confidence that you're deploying what you think you're deploying, as well as this broader, managing many tenants and trying to keep everybody happy and in a known state, like that's another picture of this. Once again, this product has too many possibilities. Like, he's a lot of different ways you could use this, but I see the case for everybody should have this on in some degree, another just for the audit, just for the change management audit. Yeah, I mean, it's there right now. I mean, it's available, right? Anybody that has so from from a licensing perspective for preview, anybody that has a need tree or entry P1 license can go and start using it today. So you can just look up the tenant configuration management APIs and you can get started right away, right? Like jump into a graphics floor and start getting snapshots of them. So seeing where you're at, how long in preview any sense of that? So as I mentioned, preview was launched about two weeks ago. We are targeting to do the GA in two phases, right? First thing we'll do will have a GA of the monitoring and the snapshot feature. So being able to be in control. And as I mentioned, we'll work on that drift for mediation piece. Once we have the GA of the monitoring. Right. So that right now, we are targeting some time in the spring for GA, but we don't have an official date for that just yet. Okay, so soon, and then we can. Yes, and then hopefully it'll just be part of any three or P1 and we won't have to incur an additional charge for this, but that's not up to you. That is exactly that is about right right now. Yeah, absolutely. Well, Nick, it's been way too long since you've been back on the show. I'm am amazed to see you still working on the same problem, just trying to keep our machines doing what we think they're doing just at a different scale now. This is really cool. Yeah, thanks. No, I'm having blast. That's for sure. After you bet. But thanks so much for coming back on. Thank you. Pleasure to have mine. And yeah, let's do this again. More on the exact. Yeah, you bet. And we'll talk to you next time. I'll find out.

Podcast Summary

Key Points:

  1. The discussion centers on unified tenant management for Microsoft 365, addressing the challenge of configuration drift across multiple tenants.
  2. The evolution from an open-source PowerShell tool (Microsoft 365 DSC) to an official, Graph API-based product (Unified Tenant Management) is highlighted, offering better support and reduced complexity.
  3. Key use cases include managing hundreds of tenants, synchronizing development/production environments, and using temporary tenants for testing, with features for snapshotting, monitoring, and planned drift remediation.

Summary:

The transcription is from an episode of RunAsRadio featuring a conversation between host Richard Campbell and guest Nick Charlotte Bois, a principal program manager at Microsoft. They discuss the challenges of managing configuration drift in Microsoft 365 tenants, where settings can unintentionally change over time. The guest explains the evolution from an open-source tool called Microsoft 365 Desired State Configuration (DSC), which required PowerShell expertise, to a new official product in public preview: Unified Tenant Management exposed via Microsoft Graph APIs.

This new solution allows IT professionals to take snapshots of tenant configurations, monitor for drifts, and manage settings at scale across multiple tenants—such as synchronizing development and production environments or managing hundreds of customer tenants. The goal is to provide a supported, easier-to-use platform that integrates with existing DevOps pipelines, though automated drift remediation is planned for a future release. The conversation also touches on practical use cases, like using temporary tenants for safe testing and training.

FAQs

Unified Tenant Management is a configuration-as-code solution for Microsoft 365 that allows IT professionals to manage and synchronize settings across multiple tenants using APIs, enabling snapshotting, deployment, and drift monitoring.

UTM detects configuration drift by comparing the current tenant settings against a defined source of truth, such as a JSON configuration file, and can automatically remediate unwanted changes to maintain consistency.

Common use cases include synchronizing hundreds of tenants from a golden image, managing separate dev, sandbox, and production tenants, and creating temporary trial tenants for testing or training purposes.

The open-source Microsoft 365 DSC is community-maintained and PowerShell-based, while UTM is an official Microsoft product with Graph API support, reduced learning curve, and full support options, including SLA-backed assistance.

Organizations can start using UTM during its public preview by calling the configuration management APIs on Microsoft Graph to take snapshots, deploy configurations, and monitor drifts across their tenants.

UTM automates configuration deployment and monitoring at scale, reduces human error, ensures consistency across tenants, and integrates with DevOps pipelines for version control and automated workflows.

Chat with AI

Loading...

Pro features

Go deeper with this episode

Unlock creator-grade tools that turn any transcript into show notes and subtitle files.