- Welcome to episode 372 of the Microsoft Cloud IT Pro podcast recorded live on March 8th, 2024. This is a show about Microsoft 365 and Azure from the perspective of it pros and end users where we'll discuss a topic or recent news and how it relates to you. Today we'll be continuing our discussion on Microsoft Intune, one of the most powerful tools for managing your organization's devices, apps, and endpoint security.
In this episode, we'll be focusing on the app pillar of Intune, which includes app protection, app configuration, and office apps. We'll explore the many tools and features available to help you manage and secure the apps your organization uses. Join us as we dive deeper into app capabilities of Microsoft Intune. I should like script this out so I don't have to hit two buttons. You - Should automate yourself out of a job, - Not the way my day went today with a automation .
- Yeah, you having some automation woes at work? I, I'm gonna get you into it just so you rant a little bit. - Okay. You're gonna get me into it. One quick one. We do not need to spend time figuring out why this happened because I don't know why it happened. I just turned everything back on. After I turned it all off, I essentially rebooted the cloud and it worked.
So I had a client call me the other day and like the SharePoint list was getting, I have an automation that runs daily from A CSV to update a SharePoint list. Short story email gets sent to mailbox CSV gets picked up by Logic apps. Logic apps or the email tells logic apps to go fire off a runbook, which essentially grabs the CSV outta blob storage, runs a PowerShell script against it to update a SharePoint list. It's a daily process. My Logic app is literally three steps.
New email, copy the attachment to blob storage, run a runbook done. They call me yesterday and they're like, we're getting all kinds of duplicate things in this SharePoint list and we just killed the Logic app and we don't know what's going on. It's like, okay, I've been dealing with issues like this all week, so why not another one today? I went in and looked at it, the logic cap worked as it should have.
Email came. I saw where it triggered, I saw where it went and added the file to Blob Storage and I saw where it triggered the runbook only it ran for longer than it should have. When it triggered the runbook, it was like it normally the nor Runbook normally runs for like 45, 50 minutes. It had been running for two hours and 15 minutes. Okay, maybe my PowerShell script took longer to run.
I went and looked at Azure Automation, a single go run, an Azure automation Runbook created like 50 or 75 jobs of running this one PowerShell script running this one Runbook a single action to Logic Apps. Somehow told it to run the runbook 75 times and it wasn't even running it properly because the PowerShell script wasn't doing what it was supposed to.
Thus creating all these duplicate items in the SharePoint list, we shut it all down, canceled everything, turned it all back on today and sent an email and everything's working fine. - Sounds like a good Logic app gone bad. I don't know. Yeah, also sounds like a little bit of a complex process you've instituted there. So can I, can I ask you some probing questions? Sure. Well can the client uploading the CSV upload it directly to Blob Storage?
- Potentially it comes from, I could go into the whole depth of the solution. It's an automated email that comes daily from another service. So there's another third party application they have that runs, it's - Like an EDI kind of thing. - Yeah. Ish. And it like sends the CSV from this system to this set email address that triggers the Logic app.
- One of the thoughts that went through my head is if you can send it directly to storage, either via Blob or maybe like if it is an EDI ISH thing, most support P just SFTP, that thing straight in there and then leverage event grade events to go and kick off that stuff. Right? Like simplify the process like kick. 'cause if the, if the mailbox is only there for automation purposes, it's just overhead, right? It just kind of sits in the middle short circuit the mailbox.
Yeah. I don't know that it, I - Don't know that it fixes my issue though. - It doesn't fix your underlying issue with Logic Apps. Like whatever Logic Apps did and and went wrong there it was, but it could fix your issue with Logic Apps 'cause you could have a, an event that kicks off something that's maybe not a Logic app and drive things through that way. Yeah, - I don't know. It was just kind of bizarre.
- It sounds like, like when you described it it's like wow that's a lot of moving pieces so it it's maybe worth one of those things. Investing in simplification, getting - Rid of one of them. Do - Some like self-op optimization and kind of tech debt removal. - Yeah, I could we have - Backup in the chat too. Like you you got folks telling you it's a bad idea. Yes. Get rid of the mailbox. I know this is your first inclination for many things. it's going in a mailbox.
- Yeah. I'd have to see like what the options even are from this other system to export that CS V or how it can, where it could go, what they could do with it. Yeah, - If there's something that's generating a CSV, it's probably worth investigating and seeing how that can be simplified. Conceivably there's a world where it might be easier for you to like stand up a proxy service in the middle, right? Like and that doesn't need to be too complex or anything like that, right?
That can kind of broker that communication back to SharePoint for - You. Other thing we've talked about it, we've just never implemented it. That would short circuit even more of it is I believe this third party service also has an API that we could in theory call with like an Azure function or just have the PowerShell script call the API directly and query the API and copy the data to the SharePoint list and just have a PowerShell script and then it simplifies it even more.
But it's time and money to go recreate a process that was working fine up until it didn't. It was one of those classic cases too where like automation is great for the last year, year and a half. Absolutely no complaints. It's been running flawlessly and then for whatever reason automation blows up and it just creates a mess because it's automated
and you just expect it to work. I - Would also be worried about some underlying thing changing like in the logic apps connector, like the whole mailbox flow, right? Like given the stuff between exchange and their API surface and they're always moving things around these days, you're also taking a dependency on that Logic apps connector which is ultimately like built by another team, right? So at some point they probably come in and they go, Ooh, we're just gonna change functionality today.
Then you break on the other side. - Yeah and that breaks not a big deal. You just go figure out why the mailbox isn't there. And that actually happened yesterday to like the connection to the mailbox dropped. We just went in and reconnected. Reconnected it - TLDR. You like the pain that you're gonna continue to to live with it? - No, I wanna go do it with the API. That would be the ideal goal and the ideal thing is that Logic Apps doesn't go and create 75 instances of a runbook. There you go.
- It's, it's time to write a statement of work and go, go get some money, - Some type of error checking for an error I never thought I'd have to check for - It happens. It's, it's another from the trenches thing for us. - Okay, so Pirate wants me to get the mailbox forward it to a team channel and then I go call an instance of copilot and have copilot ask copilot and teams with a prompt that says go get the CSV file and process it this way and go do this and that and all of that.
Ha get copilot in. There - You go. It can be AI driven. - I was playing with that in Excel today but that's another episode we should get into our real topic since we promised part do - Real topic. Yes. So just to play things back, the last episode we talked started talking about the suite of products that comprise Microsoft Intune and kind of how that composes together. So we started our conversation framing out Intune.
I'll say again, I still really like the way you think about it as kind of three pillars across devices, apps and point security. And it turns out that our initial conversation only let us get through devices. So we still have two more pillars to get through. We've gotta get through apps and endpoint security.
So you know, go back and listen to part one where we covered devices, how you can enroll them, onboard them, a kind of high level overview of configuration options that are available, things like that. And then we've got the continuation of things here. So let's see how far we get today. And let's start with our second pillar of applications. How does that sound? Well - The applications sounds like a plan and I didn't put up, I should have started with another tab.
We'll get to app protection policies. We are sharing the screen for those of you. If I ever can find the time and if the cloud stops breaking, I will try to get some of these up on YouTube too because that's ultimately been my goal. But applications. So I like applications in Intune. This is, I would say there's a couple different facets to it. One of it maybe kind of drifts into security a little bit. One of it kind of drifts into devices.
But one of the things I've been doing a lot with lately when it comes to apps and Intune is actually the deployment of applications in using Intune to publish applications installers for various, various applications so people can install 'em. So I think last episode when we talked about some of the devices, we talked about autopilot and Intune when it came to imaging devices.
And this is what I've seen a lot of is companies wanting to get away from the, let me get a device, let me go install my own custom image on it and then I have to box it up again and then maybe send it to a user. Especially with all the remote work. So they've been saying, well what can I do with autopilot and Intune to lessen this overhead?
And I've had some people, I don't know if we mentioned this or not, I've had some people come in they kind of think of like, oh autopilot is now my remote imaging tool . And I'm like, not really. And this is going back a little bit to devices really in a nutshell, all autopilot does is it says this device belongs to my organization and therefore you need to use an organization ID on it.
At its core that's about auto all autopilot does, there's a few things in like the profiles in terms of with that organization device, are you a standard user? Are you an admin? And then some of the out of the box setup scenarios like maybe hide the EULA or take default keyboard settings, some of that. But really autopilot doesn't have much. And then from there it gets into Intune.
So autopilot is this device belongs to my organization and you're going to log in with an organization id, you're not gonna use a local id, you're not gonna go create an MSA account. You are going to use your organization ID to sign into the device and you're gonna be a standard user, you're gonna be an administrator. Typically when you have an imaging scenario, you have a bunch of applications pre-installed.
Now that part of the new device onboarding moves into this application pillar of Intune where you can go in and start creating these applications. Whether it's Adobe Creative Cloud or Adobe Reader, I know it's Microsoft, it's Google Chrome, it's Spotify, it's Citrix, it's your office applications.
Any of those applications that maybe you install, you can now go package up and actually upload that install package or that Intune package into your applications and Intune and now go in and start assigning them to users or to devices. So in some cases I've had like maybe it's an MSP app for remoting into devices or it's like a fresh service discovery, some type of agent that you use for something and you're like, this really isn't a user application. It's really more of a device application.
Every device that's onboarded should have this application regardless of who the user is. So you can assign applications to devices, you can assign them to users and then as users log in or as devices are onboarded, these applications that are required can be pushed down to those devices. So it, it's not the image in the sense that it's let's bundle all this together in image.
It's this device is forced into my organization, it's forced into this user and once that user logs into that device, I'm gonna force all these applications down and install them on their device. It's - A little bit of, I mean it's the layering that you used to do in the past with maybe like a golden image. Yep. Your desktop deployment and the difference being, hey, I might go out and say I'm taking like a Windows client device, right?
And I'm, I'm gonna go ahead, I'm gonna install my applications on it and then like you said, I'm gonna take it back through sealing that image, you know, and, and run it back to the out of box experience. Like whatever you need to do to assists prep it and get it going. The layering approach, like it can be a little bit slower 'cause it's not all baked in. Yes. But the nice thing is like you get the dynamicism of a policy driven approach to application deployment, which is kind of cool.
So at the end of the day, like like you said, you can take an organizational set of policies for things like devices could be like IOT devices multi os, right? Like like all and package that up and make it policy driven. So users in this security group maybe get this set of applications, users in this security group get this other set, everybody gets this thing.
Which is really kind of cool because you get away from managing images and you're effectively managing access to applications maybe kinda like on the identity side where like you can be really locked down or you can leverage things like, like you can do MDM on your device or you can do mam like what's the most important thing to manage? Is the most important thing to manage the device itself or is the important thing to manage the, you know, the application and access to the application.
Usually it's the latter. Like you wanna manage the application and access to the applic and access to it, right? Like, and make that flow more seamless. I'll tell you like if you're stuck in the kind of mentality of hey we still need to do the golden image thing and that's how we deploy and you know, we come down from our centralized repository of images and we bootstrap internally and that's, you know, how we do everything.
Like you're maybe missing out a little bit on, on like that world and that dynamicism and, and just to cover it. So there's a question in the chat about app protection policies and are those App v, app V is app virtualization, which is different 'cause you're actually going and in this case like you're pushing an application like let's take, well let's do a whole bunch of applications. Let's let's imagine like office. Alright - So are we gonna go into this?
Yeah. Are we done with the app deployment? All right, so app protection policies are the next thing that we're gonna dive into. I just, I I wanted to make sure. Okay. It's your show. No it's not, it's your show. Okay, keep going. Nope, we're done with app installment. Okay, so app protection policies 'cause yes, this was a question in the chat now they're apologizing for derailing us. Don't apologize. It is way too easy to derail us to apologize about derailing us .
Okay, so app protection policies Scott, so once you've deployed these applications, let's say you've deployed these applications and they're on devices or users have installed applications, what are app protection policies? - You're the Intune expert. I told you this was your show. - Nope. You started down this path so you get to continue it. Oh my gosh because you know what, they're just as much as me. 'cause I think you actually introduced them
to me like six years ago or seven years ago. I have - A lot of gray hair, I can't remember back that far. So I, I mean protection policies are, you know, I think at a high level they, they're just that they're, they are policies that are applied to applications. I think about them primarily as data protection policies, like remove the word app protection and really think about like data protection but within context of the operational controls that are available within an application.
So let's say back to the office example, let's say you either deploy office to your end users or your end users do the BYOD thing and they bring office along the way. What you want to do is you wanna say like regardless of how this came in, whether it came from one of my images, it came from one of my deployments or it came from a user who just happened to go to office.com and download office like as one of their installs through there. The most important thing is probably protecting the data.
And so the cool thing here is you kind of, again you, you go from MDM device management to mam you're, you're back to application management to a certain degree. So sometimes you wanna layer both of these. Sometimes you wanna do one and not the other. But the nice thing is effectively you're, you're pushing policy downstream to based on the user that is accessing the application, enforce this set of policies on top of it.
So that can be a little bit limiting in some situations because maybe the application itself doesn't support a particular policy that you need for data protection or things like that. And that's when you go down the MDM route, right? Like you actually enroll the whole device and and maybe do some other things on top of it. But I think it's always best to kind of start from a, from kind of a mish perspective versus the MDM thing.
So like I'll give you a sense like where I am at Microsoft, like we do a multi-layered approach where you can get to some things without being M DMed and there's a set of applications and things that I can do where I'm in one world and then if I want to go to like the next click stop, like let me say I want to open a Word doc on an internal SharePoint site that's gonna require me to have a lockdown version of Word, which means my device needs to be MD MD
but if I don't want MDM my device, my employer also offers me virtual desktops. So I can go to a virtual desktop which is protected by a policy that lets me in through identity and like conditional access and things like that. And then I can just get to office from there. And then I don't need to MDM my device in any way. They are this nice flexible way to have additional operational controls on top of applications that are deployed in your environment and make data protection policy driven.
Which is kind of cool when you think about it. And it's not just office stuff that you can protect either, which makes it even better. - Do you feel overwhelmed by trying to manage your Office 365 environment? Are you facing unexpected issues that disrupt your company's productivity?
Intelligent is here to help much like you take your car to the mechanic that has specialized knowledge on how to best keep your car running Intelligent helps you with your Microsoft cloud environment because that's their expertise. Intelligent keeps up with the latest updates in the Microsoft cloud to help keep your business running smoothly and ahead of the curve.
Whether you are a small organization with just a few users up to an organization of several thousand employees they want to partner with you to implement and administer your Microsoft Cloud technology, visit them at intelligent.com/podcast. That's I-N-T-E-L-L-I-G-I-N k.com/podcast for more information or to schedule a 30 minute call to get started with them today. Remember intelligent focuses on the Microsoft cloud so you can focus on your business. That's why these are my favorite.
We were talking a little bit too even in the chat about especially like you said the BYOD scenario where the way I always think of it is that like puts in, I can't remember if this is exactly what you said, but it puts that container around your corporate data in an application where like Outlook and you gave the example of Word and some of those where that typical MDM scenario, you are giving that employer or whoever M DMed your device, full control of your device, right?
They can do stuff with your camera, they can do remote wipes, they can do all of that App protection policies only gives them access to affect the corporate data in the application. So your example of I think Outlook where let's say I went and added my Gmail account into Outlook or I added my MSA, my personal email into Outlook and I also added my company email into Outlook.
It only lets my company access or wipe or control that data within an Outlook that's in my company account, not my personal account. So they can do things like I pulled it up here, some of the examples of requiring a pin or a fingerprint to access corporate email. So I can open up Outlook, I can go browse my personal email all day long. As soon as I jump over to my corporate email, it's going to force me to enter a pin or do some type of fingerprint or face id.
If I wanna protect data from being copied, I can say again personal email, I can copy and paste data in and out of it all day I want to but my corporate email, you can't copy an email and paste it into a text message or copy an email and post it into the notes application on your phone. That corporate data stays within that corporate bubble within that application on your device. And you can put a whole bunch of different policies and restrictions around it.
But also if a user leaves you can say it's their personal device. I feel really bad if I deleted all your family pictures Scott, because IM DMed your device. Mm-hmm and you ran away with it and I had to do a remote wipe with ma'am. I can say okay Scott, you ran away at your device. You can keep all your pictures but I'm gonna completely remove all that corporate data from those applications on your device. Yeah it gives a great middle ground, - It's a little bit different.
It does take you kind of being open to a new way to do things. Particularly if you're coming from that world of everything's super locked down by default. Like you do kind of have to take a step back and maybe think about like hey what's the goal or the end state that I wanna be in? So I am a huge fan of ma m like I think like you should really come from the approach of ma m first and not MDM first.
Like convince me that we do need to do MDM rather than let's do MDM by default because like every time you do this and you go down this path, like usually is the data that's the most important thing to protect. The more locked down you make things, the harder it is for your users. And there there's a series of trade-offs that come with that, right?
Like you're introducing not only friction maybe in accessing and working with the data, you're also introducing a bunch of ancillary processes on the side. Like if you make it harder to log in to access your data and SharePoint and pull that up and word on your desktop, that's probably additional load that you're putting on things like your help desk and your support organizations. 'cause there's gonna be more questions from your users in those areas.
So great you protected the data and the device but if you didn't need to go to that path, all you're doing is costing yourself more money in other places. It's an interesting kind of TCO exercise to come back and think through. Yeah to a certain degree. Like it, it does, it depends on the devices like you mentioned like the containerization and things like that. Or I guess the segmentation of data is the way I would put it.
Like there's a big difference between like a work profile and an Android device and the way that segments versus the way like an app protection policy for for say like Outlook on iOS works versus office or Outlook on a Windows device, right? They're all very different in the operational controls that are available to them and how they behave.
And that's okay. Like I think you can get through that 'cause you're, you're probably gonna have multiple OSS and multiple flavors of the same application across OSS and things like that. But it definitely is kind of like a consideration for you like how that segmentation containerization of data occurs and how that manifests for users at the end of the day. But I think like, like I said, if you can do the the the managed thing first you're making your users' lives easier.
Which selfishly if you're like an admin who has to support this stuff or you're on the help desk side or anything like that, it also makes your life easier, right? And the easier your life is that typically means reduce cost better cogs like that, that's not a bad thing. Yep. - And I would say even from the admin perspective, it makes your life easier in terms of that initial enrollment onboarding of devices.
Like you go the full MDM route and you start dealing with the Google management, whatever the work management, whatever their work management thing is, now you deal with the Apple management side of things, you have to start dealing with certificates from these different vendors and there's a lot more setup and certificates that can expire on you. Not that anybody ever has certificates expire on 'em - Now it was just DNS.
It's never a certificates - That can affect the MDM process versus the application management for me feels it's, there's a lot less from the administrative side in terms of what you're managing, how you set it up, how you configure it. So I'm with you, I'll go into a lot of companies, they'll be like yeah we wanna manage the devices. And I'm like, so have you heard about app protection policies and how these work? And they're like whoa, that's awesome. We don't need an MDM.
We can just do app protection policies and protect all the data and all the apps and segment it out and go that route.
So I think it is, everybody's heard of mobile device management, everybody's been doing it for so long, whether it's been through Intune or whether it's been through some of the other third parties, the airplay or whatever some of the other ones are, they all have their own that not a lot of people have heard of or fully understand what these app protection policies are And yeah I am. I'm a huge fan of them.
- When you mentioned that maybe not a lot of folks have heard what these are, I bet they have heard about them, they just don't maybe know that - Realize - We're talking about the same thing. So you mentioned management experience, maybe we should kind of touch on that a little bit because you know you do have multiple oss, you do have multiple flavors of applications, things like that.
One of the things that's kind of maybe disappointed me I been a friction point for me in this space is that sometimes the admin experience for this is bifurcated and it's kind of split up, right? Like so for something like managing office, you might be doing cloud policies in one part of the admin center for something for managing OneDrive. You might be over in like the OneDrive admin center like what? Like admin.onedrive.com for managing this other thing over here.
You might be inside of another part of the Intune suite. So the, it starts to get a little bit weird 'cause we start to kind of fall into the oh isn't a product, it's a suite . Yes. And now because it's, it's not cohesive across these admin experiences for a application of policy in different flavors, it can be a little bit difficult to get to that way.
I will say like if you can get there, I really do believe like at the end of the day, like the ROI is there like you know somewhat flippantly like the juice is worth the squeeze. You can make it happen because a lot of this too is like you kind of set it up once and then you just, you're done, right? Like you, you really don't come back and reconfigure office too often.
So once you get all those policies set up, cool, you know, we're ready to go think about it like how many times do you come back, coming back and reconfiguring OneDrive, how many times are you gonna come back and reconfigure the way Outlook behaves on mobile devices? Like you gotta go through the pain once and hopefully, you know, like I said there there is ROI down the road there. - As long as nothing changes stuff - Is gonna change. But I think that makes it easier too, right?
In the world of the, the old days of you know, hey let's layer all our applications into a quote unquote golden image, right? And, and deploy that out to our devices. Like you know when you wanted to update an application on that you either had some form of slipstreaming that you had to do or you were going back and you were effectively deploying that thing again, right?
Updating the application, installing the next version, resealing it like that never worked like not as well as it was supposed to in my experience. I used to hate doing that stuff, right? It was effectively like rebuild from scratch every time. So yeah, you gotta go to different places maybe like it's, it's different in how you interact with it. I would argue even for like the segmentation and the admin experience, it's still easier at the end of the day.
'cause now rather than going in back and redoing a whole image and redeploying and and figuring out how to get that stuff out to users on the desktop side and, and what does that look like and how do you do either app streaming or app installation updates with like you just go and figure out the policy and then and and then you're done. It's far simpler. I - Would agree with that too.
Like from a, I don't even know that I wanna call it a segmentation, but from like you said the whole layering approach and the whole almost like an a la carte type approach, you can make changes to small portions of it. Change a single app, deploy an update to a single app, make a slight tweak to a configuration without going through and redeploying everything.
I would even say a lot of these and I don't know where, so configuration policies kind of falls into devices, kind of falls into apps, kind of falls into endpoint security. Those kind of span all of them, even from that aspect like the configuration policies that Microsoft has in place now are getting pretty close to being on par with what you could do with GPOs.
Let me tell you from a GPO perspective, I go into some of these organizations and look at their GPOs of like we have these all these GPOs way up at the top level and then we have GPOs down layer all the way down layers and layers of GPOs and it's like by the time you get down here you have like 500 GPOs applying but you don't know which o use they're inheriting from.
And all of this, I think the app confi or not the app, it is app configuration policies, device configuration policies, all of those configuration. I will say you can absolutely still end up with 500 policies layered. I have seen organizations that have 30 or 40 layered not 500 yet. I actually don't know there may be a limit but it feels a lot easier to me because it's all flat.
It's like here's all of our policies all in a nice list and now instead of all this weird inheritance, these just apply to a user or to a group or to all your devices where it's, I need to go test a new policy and I don't, maybe I just wanna push it out to three devices. Now I'm not figuring out, okay, where in my OU structure can I put these three devices so they'll only get these settings, not these, it's just let's go into a configuration policy and assign it to those three devices.
Yeah, I think that segmentation, that layering in intune across policies, across application deployment, across some of the device security, it just, it's a different way of thinking about it but I think once you wrap your head around it, it's a lot simpler way to organize it. And I also have found, Scott, you mentioned like going different places to set up different policies and all of that.
I feel like Microsoft is trying to improve on that because more and more I have noticed the, I call it almost like the iframe approach where if you go into like app configuration policies and go set up a policy, it's really just giving you maybe a little different ui, but at the end of the day it's still setting up a configuration policy and that same policies shows up if you go look at like all your configuration policies where maybe there's five or six different places you can configure them,
but it's just all looking back to the same central spot. And I noticed that earlier, I can't remember, remember if it was this way with security before where, and this may be a bridge into security, I'd go to endpoint security and set up a BitLocker or disc encryption policy and it's really giving me the same UI as if I go to the devices and set up a configuration policy and go select BitLocker, it ends up all being two different ways to get to the same thing or set up the same thing.
- I think they're better at it today than they used to be. Like you go through the admin experiences, but there's still the potential for disconnect there as just there is, hey like I'll, I'll go to OneDrive as an example again, right? Admin dot OneDrive can be a slightly different experience than you see over in Intune itself. Like hey, when you're going to like the Intune admin center and things like that.
So you, you have to be mindful of like where you're working in the stack and how that composes for you, right? Like but I, I think that's all stuff that can be figured out, right? Like it's not the end of the day , it's not hard at at the end of the day to think through some of this stuff.
I also think it's worth like if you're an organization maybe that you know is imaging exclusive for deployment, your GPO exclusive things like that, taking a step back and doing a little bit of like the rationalization exercise. Like hey, what's our North star and where do we really want to be for some of these things? Because I think the easy answer is yeah, let's do the GPO thing, right? And we'll figure it out later. We don't know what we don't know today.
And I think that gets you into a little bit of trouble too if you're not thinking about the, not only the applications that are deployed, but again the data that's deployed about that's deployed with them. Like how is the data accessed? How is the data used and what does that look like? It's kind of an eye-opening experience if you've never gone through and rationalized it within your organization.
I always found it to be an interesting thing to go through and, and even use like that opportunity to talk about how we protect data as a way to leverage other parts of the stack, right?
Like, like there's all these intertwined things between DLP and sensitivity labels, app protection policies and all the things that come together and when you put 'em all together, like you do really get kind of a cohesive experience from from the user side, which arguably like the most important thing, like the easier you make security for your users, like I said, like the less burden it is on everybody else in your organization and it means they'll actually use it
and won't try and subvert the process. - Yes, absolutely. So should we try to tackle, should we keep this to two, should we jump into security for a little bit before we wrap it up today - Real quick I guess. Okay. I mentioned the multi OS thing. So you know you have protection policies today, like there's a whole set of overarching maybe like global or like more generalized settings that are available to you across things like Windows devices and, and kind of common apps there.
Android and iOS is also available to you and it's one that I haven't played with, I don't know if you've had a chance to play with them, but conditional, conditional launch policies is another thing that you run into and can be another that you area that you kinda play around with. And then, and then you've got various like conditional launch policies across, you know, windows and iOS and things like that.
So for example, like a conditional policy might be, I need, you can't launch this app unless you're on this version of Windows. So even though you don't manage the device, you can dictate that hey the app can't launch, like you can't launch Outlook basically until you get to this point release of Windows or you know, this particular patch so that you're protected from the things that we want, we want you to be protected from. So you can get to all that stuff like you mentioned without GPOs.
And I think without the, the complexity of GPOs and the layering other things that, that come in there like are there trade-offs? Yes. Do you have to go out and like figure out like are the trade-offs worth it also? Yes. I would argue that it's worth spending the time to do that rather than just diving straight into GPOs or kind of like the legacy I'll, I'll, I'll call it the legacy way to do things. Yeah, - I have not played with conditional launch yet.
The other one I wanna play with since we're talking about secured apps is this I think is technically an intra feature, but the secure tunneling between your corporate apps and Office 365 where you can now set up those policies that say yeah, if you're gonna open up Outlook, if you are opening up Outlook on a mobile device, you have to have it over like a, essentially it's encrypted VPN tunnel directly between that app.
Well not directly, you're still going over the internet, but be that encrypted tunnel between that application and Office 365. But I think that's more of a conditional, I can't remember if it's conditional access or if it's those other, there were those new enterra. Yeah, Enterra. SSE is what Pirate is saying in the chat that came out at the same time as Enterra was renamed to Enterra. - As Enterra was renamed Enterra - As Azure ID was renamed to intra,
I guess would be the proper way to phrase it. Yeah, - I was giving a talk the other day and I always like to say the artist formerly known as Azure ad when I talk about intra and I don't see people get my joke at all, but I'm gonna keep going with it. - You should keep going with that one. Absolutely. Let's - Talk, you wanna, you, you think we can do endpoint security? I think we, it's up to you. It's your show. What - Is it already, man?
Time flies when we're having fun. Time - Flies when you're talking. App protection policies said no one ever . - Let me look. What do we have in endpoint security? - Let's see, we're gonna have all the encryption stuff you talked about. Lockers, - Encryption, firewall. - Yep. Yeah, all all stuff. - I, I don't, I don't know. Let's wait with security, let's wait. I feel like if we dive into security, we're gonna end up with like an hour and 15 minute show or something.
- Part three I have manifested the reality that you wanted with the way I posted about this on social media. So all right, perfect. So this will wrap up part two and we will get back with part three next time. - And point DLP. Ooh, there's a topic too. Hey Pirate, you want to come on and talk? We should have Pirate as a guest. Yeah, that's a cool feature. I have not done a ton of time with it, but I am familiar with it. But yes, before we go down another rabbit hole,
part three part try part, what is it? Part Tray. - I'm not good at French. Well - You started down French. You better be able to finish French. Do - Dunes. No, do do - Trey. It's got, yeah, Trey, I think maybe some. I should ask my sister-in-law. . She knows French . Alright, well that Scott, go and enjoy your weekend. I am off to Seattle on Sunday morning. - All right. MVP summit coming your way. All right, someday we'll talk about that too. But - Yes, I will give you all the recaps
that I'm allowed to when I get back. Perfect. - As always, I'll be short up. Thank you. Thank you. We will chat again. Well you and I'll chat again week. We'll - Chat again soon. But yeah, - For everybody else we'll chat again in two weeks. All right, - Thanks Scott. No - Thanks. - If you enjoyed the podcast, go leave us a five star rating in iTunes. It helps to get the word out so more it pros can learn about Office 365 and Azure.
If you have any questions you want us to address on the show or feedback about the show, feel free to reach out via our website, Twitter, or Facebook. Thanks again for listening and have a great day.