Patching Without the Ticket Tax: Better End-User UX with Prebuilt apps
Today, we are talking about prebuilt apps, patching without the ticket tax, better UX with prebuild apps. For anyone who is an Addigy customer, you’ve known me. You’ve talked to me. You’ve heard me talk about this endlessly, but it’s just kind of some new stuff that we’ve been doing with prebuild apps and refresher for those of us who have never used it or maybe have been curious about it but wanna know a little bit more. I’m Selena, and if we go to the next slide. I am a senior product manager here at Addigy. I was one of the the people who helped build prebuilt apps. And if you ever have a question or a problem or you email us about feature requests or whatever, it’s going to my inbox. Throughout all of this, I like to always drop our product email. It’s product at Addigy dot com. That goes to all of us. If you ever have any questions, frustrations, feature requests, whatever it may be, and you wanna get our attention, go ahead and send an email. It will go to my inbox as well as the rest of the product managers. And I’m joined here by Daniel. Daniel Allen’s our senior solutions architect here at Addigy. If you’ve ever done any of our Addigy certifications, you might have had him as your instructor or some onboardings or whatever it may be. I think we’ve got Addigy Boost that he does. You’ve probably come across him. But this is his first pseudo talks, so, no pressure, Daniel. And I thought it’d be nice to bring in someone else so you’re not constantly hearing from me because anyone who’s been following knows it’s just me. So different perspective. Alright. And if we click to the next one. With every one of these webinars, please post your questions in the q and a. You should see it down at the bottom. I we’re monitoring chat the best that we can, but the q and a is the best place for it to go. Is here for anyone who’s ever dealt with Addigy in any way. You’ve probably met Ponce. He’s here to help us with the q and a as those come in and answer some questions while we’re doing the presentation. Please drop them, and we will have a q and a session at the end where we’ll go over with with what’s there. So great. Next. So we’re gonna do a little bit of an intro on why prebuild apps, what is it, and then we’re not gonna have a lot of screenshots. We’re actually gonna do a live walk through of prebuild apps. We’re doing it live. Everything that you see will be in production, and then we will pop back over to the slides for the end user’s experience, some best practices, tips, and tricks, forward looking, and then we’ll end on our q and a. So just diving right into it. The next one. Why prebuilt apps? So for anyone who is new to Addigy or new to this product and hasn’t played with it before, we all know the problem that a lot of us have when we’re managing macOS devices is the endless packaging. Right? Software updates, especially things like our browsers, like Chrome, updates what feels like multiple times a day. And back in the day, you had to manually package those things. It consumes a lot of hours doing a repetitive task. Patching also is something that you need to do with vulnerabilities as AI has been growing and we have more and more CVEs, more and more zero day vulnerabilities out there. Not keeping up to date on your software updates is leaving your, fleet vulnerable. So it’s something that we constantly have to do, and it’s kind of a chore. And, of course, there’s always the user disruption. I always like to tell people I’m the worst end user. I make work really hard as our Addigy admin because I never update anything. I never close anything. I never reboot my machine. I never log out. And a lot of that’s difficult when you’re trying to manage a fleet and make sure that these apps are getting updated. How do you do it in a way that disrupts the users the least amount so they’re not losing data and productivity? And I think we have a poll coming out here if that wants to get launched. And while that’s cooking, there we go. So for anyone who is currently packaging or repackaging, how much are you actually spending time? So, yep, while that’s going, let’s go to the next slide. So the main features of prebuilt apps is we have the latest in auto update. It’s kind of a set it and forget it. My goal with prebuilt apps is always to be something that you don’t actually spend a lot of time configuring or going back to the page. We have scheduling options if you wanna have updates only happen during certain windows. We have days to delay the auto update, so maybe you don’t want the latest and greatest apps going out immediately. You have a a fleet of people who are, like, QA testers or early access adoptees. They get the latest and greatest immediately as kind of a smoke test before it goes into the rest of your the rest of your fleet. We have update only, which means that, hey. I don’t wanna install this app, but I want it to be up to date because of those security vulnerabilities or anything like that. A good use case for this that I have on my personal machine is Spotify. You know, Addigy isn’t pushing Spotify to my machine. I downloaded it because I’m a rascal. And so our IT team wants to make sure that Spotify is at least kept up to date. So we have that. We do include most of the MDM profiles. There is a little asterisk there. We are constantly adding to our PPPC, and it’s something we’re doing our best. But we do include any relevant system extension or other profiles, more details in the app details of what’s actually included there. It kinda depends on not every profile needs it. And we along with everything in Addigy, we have policy inheritance. Whatever you set at the top level will inherit down. But unlike everything else in Addigy, we actually opened up a can of worms and introduced inheritance override to give you the full customizability no matter where you are in your policy hierarchy. We do have a menu bar, and we do have it in self-service. And, of course, we have it in Addigy Assist. I’ll talk a little bit more about Addigy Assist later, but Addigy Assist is our onboarding app. So it’s something that we’ve built, and we’ve been adding it throughout most of the product. And, basically, I wanna have a set it and forget it type thing. And as some of these polls come in, you know, some people here are spending five to ten hours packaging or even two to five hours. Hopefully, this is something that we can get into off your plate so you can be focused on other things. Alright. Next slide. The catalog. The catalog is growing. We have officially two hundred and twenty apps. Now if you go into the catalog, you’ll be like Selena. There’s actually two hundred and forty one. We do have some duplicates in there depending on the architecture, if it’s Intel or Silicon, And there’s also apps in there that are actually end of life, so I didn’t include them in this count. This is two hundred and twenty apps that we are actively updating. It’s not at the end of its life, and it also does not include our OS update blockers, which are also in the prebuilt apps catalog. Those are kind of special one offs. The last time I gave this talk, it was a hundred and sixty. So we are growing. We are constantly taking in requests. And if we go to the next one, if you want to request an application, there are a few requirements. It does need to be a publicly available installer and outside of the Mac App Store. If it’s an app that only lives in the Mac App Store, then using Apple apps is gonna be your best bet for that. It cannot have any license keys or anything that needs to be configured during the installation. And another thing about the publicly available installers, something we’ve been noticing is that some installers are publicly available, and then as the company goes through some shifts or they rename their product, they put that installer behind a login window. Once it’s behind a login authentication, it’s not something we can keep up to date, and so we unfortunately have to end of life it on our side. So that’s a thing. If you are sending these requests, please give me a download to exactly what you want. Something I’ve noticed and something that all tech companies do is we have a name that is totally nonsensical and spelled with unnecessary letters or not the way you want. So it’s easier for me and faster to get that request processed if you can give me a download link or at least a link to what the developer is. But, ideally, because it doesn’t need to be publicly available installer, if you just send me the download link or even the link that will will trigger the download, that’ll be perfect. You can request apps through the in app product feedback. We’ve got them all over the place, or you could email me at product at Addigy. Both things go to my inbox. Both things are things I look at every month, and I go through and add it to our backlog, and we do it. I already mentioned this known issue. We are always working on the PPPC profiles. These are something that’s kind of interesting, and we do need public help on occasionally because we don’t actually use all of those two hundred and twenty apps in our environment. And so some of these these prompts that we need to approve, we don’t you won’t know unless you’re using the app and you’re actually trying to do with it. So it’s something that we’re doing our best to make sure it has the minimum required permissions and nothing more. We’re not just gonna blanket allow everything. And as changes with macOS happens to that profile as it moves to declarative, that’s another thing we’re keeping aware of right now. So there we go. And next slide, please. So, that’s kind of the high level of what it is. And, now I’m gonna kick it over to Daniel to do a live walk through, and you can stop listening to me for a little bit. Awesome. Appreciate it. I know Selena said she’s one of the worst end users because never restarting. I’d argue that’s an average end user. And the ones that do restart, those are the anomalies. I put myself in the same boat. Never restart. I always get the notification. Hey. Your computer’s been up for x amount of days. I’m like, I’ll defer until later. So prebuilt apps. Let’s get started here. I know we’ve got some people that have been using Addigy for a while, maybe new to prebuilt apps. We’ve got some others on here that are new to Addigy in general. So we’re gonna start here on go live. If you’re unfamiliar with go live, think of this as one to one management. If you need to take action on an individual device, find out info about an individual device, go live is gonna be the best place to go. Lots of stuff in here, but what we’re worried about today is gonna be prebuilt apps. So I’m gonna come down here to software, go to prebuilt apps, and we see all of our catalog right here for very quick and easy deployment. Now call out, when we, click into one of these, few call outs actually, we can see the description in here. So Selena mentioned the PPPC profiles. If we come up here and we search for Defender, we’ve got it right there. You can see the release notes on here. Always check those, especially if it’s an app that you know, like, has, you know, configuration profiles that go along with it. Check and see what’s included and, what’s not included. But if we wanna deploy an application from here, all we have to do is find the app that we want, come over here, and we hit deploy, and it’s gonna run, and it’s gonna install right now. Now call out with this another one. This is always gonna be the most recent version. So when we hit deploy, we’re deploying the most recent version. We can check details in there. I should have Aircall installed now. So if I can look for it, sure enough, there it is. Spotlight search, by the way, best feature on the Mac. But this is gonna be one off. Right? Hey. One person needs this. One person needs this. Always the most recent version of the app. But we don’t wanna have to do everything one off. So let’s, zoom out a little bit. We’re gonna go from here, and we’re gonna jump over into our catalog. So we’re gonna go catalog software. Think of your catalog as kinda like the toolbox. This is where most of our resources are going to live. So we’re gonna go to prebuilt apps and we see I’ve got a bunch of stuff that’s already configured. Now as we click into one of these, we can see where this is going. So in this case, I’ve got that one going out to the entirety of iteration one ten. Of course, our inheritance means this is gonna go down to, you know, everything underneath there. But if I wanted to, right, right now, my settings let’s go see what’s going on. I’ve got it going out to iteration one ten, going with latest and auto update, and I want my update enforced, in this case, every ten days. But if I wanna override that, right, Everwood might be, you know, one that needs something else. So I can come in here and I can check that box. And now if I go back into my settings, you’ll notice that I’ve got, a new thank you, Addigy, for the handy tag right there. I’ve got a new settings entry. Notice the change over here. It’s already different. Right? It defaults to fourteen days. For Everwood, I may wanna say, hey. I want you updating every five days. I don’t wanna wait ten days. I wanna go ahead and update you every five days. When we save that, that’s gonna now become the new setting for anything underneath there. So Dreadnought City is gonna have the same setting right there as ever would. And that’s gonna be looking at this in our catalog. So, again, one of the new features in here is that policy override, because, you know, you may want Chrome going out everywhere, but you may want update settings different. We all know how often Chrome wants to update. So you may have some customers. You may have some departments to get that update sooner rather than later. But, yeah, that’s gonna be looking at, prebuilt apps over here from catalog. Now we can also go back, say that we wanna assign something new. Aircall, for instance. Right? I already deployed that one off for my one user that needed it, but now I’m getting a bunch of other requests. I don’t wanna go into a bunch of different computers and deploy Aircall. So I can just come over here. We’re gonna say, hey. Everyone over here at Ashwind is going to need that. So we can check that box right there. And then if we wanted to, again, we can go and adjust their settings so that Ashwind, we’re saying, hey. Deploy latest in auto update. Set your update frequency to ten days, but then maybe Sky’s Edge. We wanna keep that at fourteen. So you can finagle this. You can make it how you need it to be. Or for Sky’s Edge, you may say, hey. Just update only. Lots of different options that we’ve got in here, but we can go ahead and save that. And that’s gonna get now assigned to that policy, and everything that’s underneath there, of course, is gonna start getting deployed, and landing on those devices. So your catalog, think of this again as your toolbox. We can come in here, and we can affect multiple policies from one location. But you may rather navigate and work through from the policy level instead of working through at the catalog level. So let’s, shift gears. We’re gonna jump over here on the left. We’re gonna go in our policies, and I’m gonna come down here to my iteration one ten. Software from that middle column, and then there’s our prebuilt apps. So as that loads, we see everything that’s going on in here. You’ll notice air call is not assigned. We assigned to that one down here to I think it was Ashwind. Yeah. There it is. So there’s air call coming down in the policy. Got my one password coming down from that parent policy. So that’s all good right there. We can add more stuff just like anything else. We can come in here and we can say, hey. Let’s go ahead and I’m gonna jump back up here. We’re gonna say, let’s deploy eight by eight. So we’re gonna add that in here, add the policy. Again, I’ve got my settings right there for latest versus auto update. Most of the time, we’re probably gonna be going with latest and auto update except for those policies maybe where you’re testing or something that. I know this is what I use most often is that latest and auto update. The other thing too though, like Selena mentioned, maybe we don’t wanna deploy it out, but if it’s there, we wanna make sure that it’s kept up to date. So if we just check that update only, then whenever it runs and it does its condition, it’s gonna look and see is eight by eight, installed. If it’s not, cool. We’re gonna exit. No need for us to do anything here. But if eight by eight is installed, then we’re gonna check and see if that application is up to date. And if it’s not, that’s when we’re gonna prompt the update. Now the user is gonna be forced to get that update in, you know, however many days we put right here. Generally, I usually personal preference. Right? I usually go anywhere from three to seven days for most applications. Five is a nice in between right there. I know that’s what I do with a lot of customers during onboardings. So I can come in here, hit assign on that, and that’s gonna keep the app up to date anywhere that it’s currently being deployed. But I can still jump down here, say go back to Ashwind. There’s my eight by eight work. Got my little briefcase icon right there. But I can click that and I can do override parent and I may say, hey, over here, I want it updating every two days instead of every five days. Once we select that and we confirm and I love the little notification right here saying, hey, if you do this, here’s the other things. Right? This is gonna be what’s affected. So please make sure that you read this. I know I’ve gotten on with customers before that had an unintended unintended consequence, because we didn’t read a notification. And I know I’m really bad about that. I’m just like, click click. Yes. Confirm. But please take a moment, read it, make sure it’s gonna do what you want it to do. Confirm that right there. Now we have that handy little broken briefcase, showing us that, hey, your policy inheritance is being overwritten right here. I can always come back later, and I can say, you know, I don’t need to have this going out every two. I can, you know, revert back to five and just say use that parent setting. And now it’s gonna go back, and you’ll notice it changes over here on the far right when we look at our enforcement deadline right there. So that’s gonna be how we do it from the policy level. Now if you’ve been using prebuilt apps for a little while, you’ll know that whenever it first came out, we had some notifications that notified the users that, hey, updates were ready. And we need to notify the users, but sometimes things may have been a little bit, you know, noisier than what we wanted. So Selena and the team have done a lot of work in that, and one of the newer features here is gonna be the menu bar. So if we go to settings over here at the top right, there’s an option, and I’ve got mine currently turned on. Now the menu bar is turned off by default. So if you’ve never made a change in here and you go into the settings for your software within the policy, you’ll notice that your menu bar is gonna be off by default. But what this is gonna do is it’s now gonna put your notification up there in the menu bar versus being blasted with notifications all of the time. So it’s gonna make it real handy to see what’s going on. The other one in here, Selena mentioned, you can add that delay. That’s gonna happen right here if you wanna delay, you know, until an update is gonna be sent out. Basically, until it’s applied to your catalog or applied to your policy, you can set that delay right there. But the menu bar is gonna pop up in the top. Obviously, it’s a menu bar item. And mine’s already configured now. We can uncheck that box. And, again, we get a notification right here saying, hey, these other policies are going to be affected. So if you have certain policies that you don’t want the menu bar turned on for, you can come in here, you can deselect that, you can hit override, and that menu bar is gonna disappear next time that policy runs if it’s currently turned on. Or if you’re doing all of this, you know, setting it up from scratch, then that menu bar would never show up, in those child policies if you defer it. Now I’m gonna leave mine on. I I toyed around with turning this on, deploying policy, turning it off, deploying policy. Ninety seconds is usually about how long it took. That’s not a long time for me to wait personally, but when there’s eighty three other people that are watching you, that’s a long time to wait. So I’m not gonna sit here and do that, but I want you to know, you you can do it. Go over there, hit deploy now. My experience, it’s usually about ninety seconds, two minutes before that lands on the device. But with the menu bar oops. Sorry. Cancel. I’m gonna get out of this whole thing. Alright? Scroll down. Prebuilt apps. Here we go. So I’ve got my menu bar up here. You can see it does not have the normal Addigy icon on it. We should have put a poll in here for what everybody thinks the Addigy icon is. This one that we see over here at the top left. Is it a laptop that’s opening? Is it a, you know, a fancy looking a for Addigy? I’ve heard both. But, normally, the default icon right there is gonna be that little miniature Addigy icon. If we have self-service configured and we have a menu bar item for self-service, then it’s going to use that setting, and that’s what you can see up here. So if I were to go into my self-service config, you would see that custom icon, living on there. But if you don’t have self-service or you don’t have the custom menu bar icon, it is gonna default to the fancy Addigy a slash laptop opening logo. So right here, I can see what updates are available. I can see Anka, Anka, not sure on pronunciation, very similar to Raleigh versus Raleigh. By the way, I’m gonna go with Raleigh, whoever that was in the chat that said it’s not Raleigh. But, anyway, Anka, Anka, whatever the pronunciation is, I’ve got that update gonna be forced in eleven days at ten o one AM. Brave’s gonna update in twelve days. Microsoft Edge is gonna update in thirteen. I did not do this on purpose to have those go eleven, twelve, thirteen. It just worked out that way. But those updates are gonna show right there. Now if I wanna update one, I can click update, and it’s gonna say, hey. We need to close the app, obviously. Click okay. It’s gonna do its update, and then that is going to disappear from the menu bar item. Once that update is finished and everything’s done, it’s checked back in. We see the progress right there saying we’re currently installing. And there we go. Thank you, Anko, for popping back up. So that’s gonna be how we deploy those apps, how we update them, the menu bar, great way to minimize notifications and and, you know, blasting the end user with stuff. The other call out on this, I’ve got these apps purposely running down here, because if not, they’re just gonna update automatically. So if an application is not running, right, it will run that update during that by the time that deadline happens. It’s we get the notification if it’s not running or sorry. We get the notification if it is running. But, yeah, we have another poll now that’s, I think, it for the live demo, at least according to the outline that I’ve got right here. We’ve gone through a bunch of pieces. Pull time coming back up again, and we’re gonna shift back over into the slides. Selena does have some screenshots to kinda show the difference in here between using the menu bar with a custom icon versus no menu bar icon and all of that good stuff. But, yeah, let’s swap back over to those slides. And, Selena, I’ll pass it back over to you. Perfect. Thank you for that. And just a reminder, I see some people are answer are asking in the q and a. But for folks who are asking things in the chat, q and a is the other place that we’re monitoring. So if we go to the next slide. There are some things that I wanna talk about with about conflict resolution, because a lot of you folks and a lot of our customers take advantage of flex policies, which are super duper powerful and very fun and, personally the bane of my existence. When prebuilt apps exist in multiple policies on a device, we’ve had this question of what to do when you have conflicting settings. Do not have an answer across the board for all settings. It’s something that I am actively working on, to try to figure out every single one of these conflicts, but here are some of the ones that we do have rules for. As we update this, I threw in the chat a prebuild apps inheritance policy inheritance guide. As we update conflicts and things like that, especially with, like, things schedule or or, you know, install versus update only, which currently doesn’t have a resolution yet, it’s it’s gonna be documented here. So that’s one of the KBs that I’ve been trying to show exactly what the behavior it is. But the philosophy we’re taking when it comes to conflict resolution is the most restrictive wins. So for any user notifications, you can have either four or eight hours. If you have a poll a flex policy that says eight hours and a location policy that’s four hours or vice versa, the four hours is going to win. Daniel mentioned this, but with the end user notifications when an app update is available and the app is open, we are throttling that now. So instead of getting, you know, like, ten or however many I don’t close any of my apps, so I used to be bombarded with a baton. We are, for real, only showing one notification. For the menu bar visibility, when for those of you who are around Slack, probably saw the busiest week of my life here at Addigy, we changed the way we were deploying menu bar, I think is the way I’m gonna say that, and we’ve taken a cautious approach. So it is off by default, and we have very clearly documented all of the different scenarios for when the menu bar will be visible. The one thing we tried to show it in the policy inheritance, as Daniel demoed, with, like, you know, if you turn it off, what it’s going to affect. The other place that this includes is the self-service configuration. Prebuilt apps can be assigned to self-service so end users can install and update whenever they want from self-service. But if you are not if you’re using the self-service app and not the menu bar, so you have the menu bar off in your configuration, even if you have the menu bar on in your policy, it will not be displayed because we treat that as a conflict as well and the most restrictive wins, most restrictive being don’t deploy it. Same thing with schedules. In previous webinars and as we launched prebuild apps, I highly recommended folks use schedules, and a lot of that was because of the end user notifications can be happening throughout the day and bothering people. Since we’ve made that change in throttling those notifications so you’re not actually getting hit with a million notifications, when an app needs an update, I’m now taking the other stance of schedules is something that we no longer recommend. That’s not to say that they’re not valuable and have a place. They do. And at some workflows, I do still recommend schedules. But if you’re someone that doesn’t necessarily think about, you know, having those tighter update windows or you’re someone who wants to use the menu bar, or if you put in the schedule because I recommended it to you because of that notification fatigue we had in the earlier days of prebuilt apps, Now it’s something that I recommend trying to play with it. An important call out with schedules is if you have conflicts, tightest schedule wins. And by that, we mean the, excuse me, the least amount of minutes available for an update and days. That KB about inheritance will document exactly what we mean and give a few scenarios. I’m always open to feedback. I know the next one I’m we’re going to tackle is if you have an install and update versus an update only in two policies. We need to configure that to what the most restrictive is, which is install and update. So if you’re seeing weird things in your fleet, please open a support ticket. Please email me at product at Addigy. If there’s other conflicts you want to resolve or have questions about, please email me. It’s something that we’re thinking about documenting and working on, making it clear, reproducible, and predictable. So right. Next next slide. And fine tuning your deployments. So it’s always a balance between that end user notification and the user productivity versus making sure your fleet is up to date. So update only is something I recommend just across the catalog that will update any existing apps that maybe you’re not explicitly managing. Things that I know is happening on my personal machine that’s being managed by pawns is things like Spotify and Discord. Right? I have those things installed because I’m a rascal again, and they are being enforced and updated on a regular cadence because of prebuild apps as update only. When you’re thinking about setting the enforcement deadline, we only give two weeks, and part of that’s intentional. For some apps, it doesn’t really matter because they only update maybe once a quarter, but other apps will update multiple times week. So we wanna make sure that apps aren’t falling too far behind when you think about that cadence of the user has up to fourteen days to get to the version that’s being deployed. That’s to stop people from deferring things indefinitely. I know me. I never close anything. I will keep trying to not update things for as long as humanly possible because I’m always on my browser. When is there ever a time where I’m not where I’m okay with closing my million tabs? So think about what works for your org. Think about what works for the apps. Some apps, maybe you could be more lenient on versus critical apps, and also think about what compliance frameworks you have. I know we have some folks from the UK, and Cyber Essentials is fourteen days, which is what our maximum is. So whatever works for your environment, that’s kind of what we’re working with. And with the menu bar, menu bar is fairly new. I’m a big fan of it personally. And what I really like about menu bar is it gives people the ability to update out of sync. Self-service does this too. We do have the feature request to have it in the updates its own updates section in self-service right now, and I’ll show you a picture of what it looks like when there’s an update available today. But what menu bar gives you that self-service does not give you is visibility into when that update will be forced. Right? As Daniel showed, he had the time and the date on, hey. You have this to update. Now that we’re using it internally, I always look at it and go, oh, no. My Brave browser’s gonna update right when I’m playing D and D. I guess I I guess I’ll do it before then so I’m not, you know, forced to update in the middle of a campaign. Also, think about your delay buffers if you’re have testing windows between vendor releases and your fleet deployment. I know we use that internally as well of people who are on early access stuff. Make sure your critical apps are being tested before you go out so you’re not downgrading unnecessarily or even catching those issues before they come a wider problem. So if we go to the next slide, an important thing is is prebuilt apps will not downgrade. We take the stance that the more updated app the most updated app, more recent version is the most secure version, generally. So if you’re pushing a version, let’s say, a one dot o version on the policy and the end user has updated on their own or through some other process to one dot one, one dot two, whatever the new version may be, we are not going to downgrade them to the one dot o version on the policy. We just check. Is it older than the version? If it’s newer, we don’t do anything. So we will not downgrade. We do not have removal scripts. That’s kind of intentional as well. We don’t want people accidentally pressing a button and uninstalling a critical app across their whole fleet. So if you remove the prebuilt app from your policy, the app will stay on the device, but it’ll no longer be kept up to date by prebuilt apps. If you need to remove them, it also depends a little bit on the app. Most apps can just be a pseudo r m dash r f, you know, path to application. Obviously, whatever the removal is, some other apps, like I know Adobe and things like that, they’ve got more complicated removal scripts. Whatever it is, test in before you deploy to production or whatever the removal process to make sure it works, you’re not doing anything crazy. Zero day responses. So we do reserve the right to pull versions from the catalog if they have a critical vulnerability. And if there is a new version, it’s something to keep an eye on to see, hey. If you’ve got days to delay the auto update by that new version that maybe has a critical security fix may not being pushed down on your policy. You may need to go and actually check that it’s pushing it because by default, we don’t do that. We follow whatever settings you’ve configured. But it is important to think about that, look at your fleet, and say, hey. Maybe I should change the deployment window. Maybe I should go to go live. Maybe there’s something I can do to make this a little bit smoother. It’s kind of a balance. I’d like to say zero days are less common, but that is the opposite of what is actually happening these days. So as you’re configuring your enforcement windows, also kinda think about what apps have you read about in the news that regularly seem to have zero days. And helper tool pop ups. I get this a lot. Things like Slack, Postman, Discord’s got one, Versus Code, Visual Studio Code, if people are using that, and Firefox, all the browsers, they have these helper tool pop ups. For now, we always recommend people create a separate MDM profile if the developer allows it. Not every developer has a MDM profile or a key that can be configured to turn off those helper tool pop ups. If you are working with one of those developers, I know, for example, Asana is one of them that does not have a a tool a way to turn off those updates, please reach out to those app developers because as in the enterprise, it’s something that we wanna see, and those help where pop ups are very annoying. But for the ones that do have it, create the MDM profile and push it. It’s just a important thing to know. Alright. Next slide, please. And a little bit about the end user experience. So prebuilt apps came out two years ago, I feel like. It’s been out for a while. It’s been a part of my life since my first moment at Addigy, and we have been adding it across the full device life cycle. So if we go to the next one, this is Addigy Assist. I mentioned it earlier. Addigy Assist is our onboarding app. As devices enroll, whether it’s through automated device enrollment or you’re doing a manual enrollment, whatever it may be, you can have this app pop up and give you a little bit of information of what’s happening. You’ve got the company logo. You could customize the name, the message, contact information, and it kind of holds users at the screen so they can see exactly what’s happening and gives them insight into preparing the device, what apps are installing, what things getting them ready for their first day. If we go to the next one. Prebuilt apps can be assigned to Addigy Assist along with MDM profiles and Apple apps and anything smart software. Anything that you can imagine, you can probably assign it to Addigy Assist, and it’ll display this way. So this is something that is in progress saying, hey. We’re almost Here’s all the things that we’ve done so the end user has full visibility. It can be as a little app like this, or it could be full screen and take over the whole screen and lock them into it. Here, it’s triggering a restart. And if we go to the next one, this is what it looks like in full screen. Says, yep. We’re good. Everything’s set up. It’s ready to go. They hit close, and it closes out. So prebuilt apps is now included in this, and that also does not follow schedules. So if you’re trying to do strange things, then that’s that’s outside of a schedule and you wanna do for deployment. This is the the way. So if we go next from Addigy Assist. What is actually happening for prebuilt apps? How does it work? Every thirty minutes when the policy runs, we do a silent check. And the very first thing that we check is, hey, is there a schedule configured? If you there is a schedule configured and you were outside of that schedule, we stop. Nothing else happens, and we move on. That’s kind of the pros and cons of having a schedule. It’s very powerful and also very limiting, especially if you are onboarding new new devices and you’re not using something like Addigy Assist. If you’re onboarding outside of that schedule, the apps won’t install. It’s the same thing with smart software. It’s a little bit of a hammer. But say you’re in schedule. Is the app closed? If the app is closed and it is out of date, we’d run a little check. It’s basically a condition script, what version is on the machine, what version should be on the machine. Is the app closed And the version, it needs to be updated. Great. We’re just gonna update that. End user will never know. I do that regularly when I know I have an app update, things like Spotify, is I actually intentionally close it because I don’t necessarily wanna deal with the menu bar or hit that that thing. If I’m not using an app, I try to close it so Prebuild apps will take care of it and clean up my menu bar. If the app is open and it needs an update and it’s been four or eight hours since the last notification, the user will see a branded notification, and I’ll show what that looks like in a second. And it’s basically like, hey. This app needs an update. Would you like to update it or defer it? It times out after sixty seconds. And if you do nothing, the it’s gonna auto defer. It’s gonna say deferred. Great. The menu bar will show a little red dot on when there is an update, and it’ll also show them, when it’ll be enforced, and it’ll allow people to update on their own. And we show the deadline in that pop up of when it’s going to be updated and also in the menu bar app of how long do you have. If you’ve never set up a prompt frequency, we default to eight hours. The idea between four or eight hours was how many times in an average workday, Once a day or twice a day will the user see it. If you’re someone like me that logs on during weird hours, that may get a little bit skewed around the workday, but most users probably aren’t working at strange hours like I am. Yep. So if we go next, this is what I mentioned of what the prompt looks like. It can be branded based on your self-service configuration if you are using one. And if you are not, we use the default whatever we think the Addigy icon is and say this is what it look like, and it does give an enforcement date. This is how long you have. If it has reached that enforcement date and and they are out of time, it says, hey. This has gotta update. It’s gonna update in sixty seconds. Or do you wanna do it now? It’s it’s gonna go. And it says, yeah, it’s it’s reached its enforcement. I don’t think I have a picture of that, but that’s what happens when it hits the enforcement date. And if we go to the next one. In self-service. So this is what it looks like in the self-service app if they want to install it. So this is something that is assigned from prebuilt apps, Microsoft Teams. You’ve get the install button. You know, the app details can can come up. It’s something that you can set for people to install whenever they want if they want it. And next one. And if there is an update. As I mentioned, we don’t have an update tab yet to show only the app updates. The menu bar will show only the apps that need updating. But in cell service, the install button will change to update. And this is what it looks like if you click update and the app is open, is it’ll be closed to install an update. This window will close automatically, and it’ll time out and and do the thing. When we close an app for prebuilt apps to do an update and it’s been open, we will reopen that app. We’ll relaunch it when it’s done. It’s not gonna stay closed, they have to go and and do it. So that is something to note, and it shows what version and things like that will be, updated to. If we go to the next one. More pictures of the menu bar. This is the default icon, and with a red dot. If you’re using self-service, I think in Daniel’s example, he had all three of the options to chat and open a ticket. Otherwise, you can control all of that in your self-service configuration. And it shows the app updates, only the updates, not the things to install, and when it’ll be forced. And we also have an update all button up there if there is more than one. If you have only one, it’s not gonna show an update all button. And if we go to the next one, we do have some reporting on prebuilt apps in historical dashboards. Always open a feedback on this if people are using it, if it’s useful, If you have feedback on it or if more importantly, are other things you’d like to report on that is not covered in here, please send me an email at product at addigy dot com. I’m always interested in exactly what type of reports folks are after when it comes to their prebuilt app catalog. So next one. This is a new one, and I let me grab this KB. This is brand new. I have mentioned this to several customers directly, and, actually, this is a shout out to Global Mac IT, Jeremy Kenny, one of our customers. He actually built a support app prebuilt app plug in as an open source thing. So if you are not using our menu bar, but you want to you’re using the support app menu bar, which I don’t blame you. It’s a great menu bar app. You can do a lot with it. But you wanna utilize prebuilt apps. That exists. And part of the way that’s working is when we built the menu bar, we actually changed the way prebuilt apps was working on your machine, and we we got really intentional about status tracking. And we do that through an SQLite database on the Mac OS. Every Apple device has a SQLite three database that comes with it, and prebuilt apps is utilizing it. And that gives you the real time status of exactly what’s happening on your machine. There are also terminal commands that you can run to do ad hoc installations if you wanna pull, say, your scripting and things like that. And we have an API that’s available where you can update configurations. You can query what’s in the catalog. If you have some of those programmatic workflows that you want, maybe it’s something you wanna replicate in just script, Our API is there to help you. And combined, you can create some really cool tools. The support app was the first one, and I think I’ve only mentioned it in passing. I’ve never actually officially documented that SQLite database. As always, if you’re using the API, make sure you’re treating those keys as passwords. You’re doing the minimum, you know, least privileged permissions that You’re not giving this API key anything crazy. You’re not posting it in scripts and plain text. And please, for anyone who is gonna tap into the SQLite database, please keep it to query only. If you modify anything that’s in the database, things will probably break, and we will not be able to diagnose it, and it’ll be a head scratcher for my engineers. So read only. Please don’t do anything to change it. And if you do, do it at your own risk. As always, test. Don’t do any of this in production. Please test before you do anything. And if you have any questions about these resources, reach out. I it’s a brand new article that I I literally, I think it was just created yesterday. And just for those advanced users, for anyone who wants to go above the UI. If you’re new to prebuilt apps, obviously, I recommend just starting in the UI and then thinking about these things later. Use at your own risk. So there we go. And if we go to next. Forward looking. We are working on a CVE detection data dashboard for prebuilt apps. This is in progress. If you want to see this and give feedback to it, please email me product at Addigy dot com. I am actively looking for feedback for the next iteration of this, which is going to happen immediately for the auto remediation. So if this is something that you’ve been thinking about and you wanna give feedback and get in early, I am desperately looking for UI feedback on our first iteration. I know it’s not quite there where I want it to be, and I want your feedback to make it something that’s actually useful, especially when it comes to reporting. Product at Addigy dot com. Reach out to me. We are always aware of updating the end user notification UI. We do use a MacManage. We do wanna move it to Swift. We are also trying to provide the helper tool MDM profiles to you for eligible apps. That’ll be something you have to opt into. We’re not gonna force it on you because I’ve learned the hard way about forcing anything on anyone when it comes to any prebuilt apps. So it’ll be opt in. Yes. It does not respect do not disturb. We are we are in discovery. I’m painfully aware. It happens to me too. I hear you. We’re in discovery for it, and then the same with unified notifications. And by that, I mean having one notification that says, hey. Some apps need to update. Where can I see those updates? Instead of it being app specific. Something to note with unified notifications, when I do eventually do that, it’ll only apply for people who are using either self-service or menu bar, not at the same time. We’ll probably do one first and then the other one later. But if you do not use either of those products, I’ve got nowhere to send you for those unified notifications. So you’re probably we can talk about it, but I I don’t have a solution there yet. But it is something that I’m looking for. And next one. Before I jump into q and a in the last ten minutes, I just wanna let everyone know, I always rush this at the end. This recording will be sent to you. It’s gonna be available on the website. If you wanna come to more, go to Addigy dot com forward slash events. Leave us feedbacks on things that you wanna do deep dives into. We’re always open instead of us guessing, hey. Let’s talk about this. We love to hear what what y’all are are are focusing on or wanna know more about. If you wanna demo, see a demo. That’s this you know, that’s the contact information. And then the next slide is something that’s new and exciting. We’re doing a virtual conference. It’s free to attend. It will be recorded. So if you are in a time zone that doesn’t isn’t conducive for this, which many people are, you know, international world, we get it. It’s it’s recorded. It’ll be available. And if you have any questions or anything, reach out to your account team, but here’s the QR code. It’s called Frontier. It’s gonna be fun. I’ll be there. I think all of us will be there. It’ll be well, virtually, we’ll be there from our offices. And, yeah, and with that, we’ve got a poll for anyone who wants to learn more about prebuild apps. We’ll reach out to you if you wanna raise your hand. If not, I won’t take it personally. That’s okay. And if you decide you wanna read learn more about it and talk about it, reach out to your account team or product at addigy dot com. I’m always happy to have my inbox blown up. And with that, let’s hop to the q and a. Selena, just to get you started, there was two questions, I think, that are very similar by Pedro and Jerome. And it sounds like they like the menu bar, but they want that same functionality in the self-service app. Jerome, Pedro, if I’m misspeaking, let me know, but that’s the way I interpreted your question. Yeah. So to show the updates, are you and I know I I I saw your email this morning, Pedro. But just to make sure I’m understanding, I know it’s the having a section to just see the available updates in the self-service. I am assuming you also want to know the deadline for when the app is going to be yep. Cool. Yep. You’ve by least Pedro’s confirmed in the chat in here, and if you wanna con confirm in the chat too that you want the deadline and the updates only in self-service. I am now the PM for self-service. So before, it was both me and Mikaela that were kind of coordinating on this, but now it’s just me. So I am looking into it. I’m grabbing some metrics right now, and it’s something that I’m actively working on to try to get prioritized imminently. I don’t have a day on when that’s going to happen, but I’m just looking for a little bit more data. Pedro, I got your email this morning. And, Yaron, if you can also just send me an email, product at Addigy, you know how to reach me, that will help me when showing folks the the demand, right, for the feature request. But it’s not available now. I am trying to get to it. Because we’re working on the CVE stuff, we actually have an interesting window of time in between this iteration of of the dashboard reporting to the auto remediation. So I’m trying to get some quality of life improvements happening around there. So perfect. So is it a good idea to select the most common applications in a high level policy and set them to update only? Then in the lower policy, you could set them to install and latest to cover updates even if the user has self installed the apps. Yes. We do have a lot of people that do that. A lot of folks just bulk select everything in the catalog and do update only, and then they have the install and latest down in the lower policies. It’s fine when you’re working in a hierarchy like that. One thing I wanna caution, and this actually came in through in app feedback, so I don’t know if the person who’s here gave me that feedback, but it was super helpful, is dealing with conflicts in flex policies. So if you have a flex policy that’s set to update only and you have a location policy or something in the hierarchy that’s install and latest, right now, it’s a little random on whether it’s actually going to install, which is not the behavior I want. I want to do a conflict resolution in and have it the install win. So today, if you’re doing it with flex policies and your policy hierarchy, it can be a little unpredictable. I don’t recommend having conflicts between those two things. If you’re doing it in a policy hierarchy, then that’s absolutely the way I would do it, is update only at the top level and then install and latest as an override below it. That override will work. It’s only when flex policies come into play that things get weird. And the prebuilt app in self-service to let me and you I’m I’m gonna send you an email, Yaron, and we can talk about that. I see Daniel’s also typing, but we’re overdue for a chat anyways. So, I’ll reach out and see if we could get, something scheduled. If a Prevost app is set to update on a time frame that is longer than the release frequency, does that mean the app is never updated or updated when the app is closed? Potentially. Yes. If you’ve got something set to fourteen days and the app is is constantly updating multiple times, then you could be in a situation where it’s it’s constantly potentially out of date. So I guess the other factor in there so let me let me rewind. It gets complicated quickly. I’m gonna use Google Chrome as an example and pretend that they only update once a week, which we know isn’t true. If you have it set to to two weeks, that’s whatever’s happening in the policy for the enforcement, then, yeah, the enforcement’s gonna keep getting reset when the new version comes out, and so you’re you’re stuck unless the user closes the app. It gets even more complicated if you have that days to delay the auto update because that can extend it by another week. So say you’re not even pushing that on the policy for a week, then you’ve got this three week window before things get enforced. I highly recommend not setting fourteen days just across the board for all apps and take a look at what is actually happening for the app updates. Things like Microsoft pretty reliably update every Tuesday. Chrome pretty reliably updates randomly throughout the week multiple times at every hour and the other browsers are. Other app developers are a little bit more they don’t have as many updates. So it kinda depends, and it’s something that you just gotta look at the update frequency. And if you don’t know, look at the app details. You’ll be able to see exactly when we’ve published every version of the app, and you can go back for the last few versions and see, oh, okay. This is we’ve updated it on the catalog, like, six times in the last week. This app needs a a tighter enforcement date than others. So, Ken, my issue with prebuilt apps is that if a user hits the deadline and has not updated several running apps, you’ll receive a pop up to update the app, then another pop up. Yep. I’m looking on that unified app. The enforcement date is is interesting because that’s the only pop up that we’re not throttling right now, and that’s because I don’t wanna start closing apps without telling people that an app needs to be updated. Unifying it and showing all of the apps is something that I’m looking at. The only issue I also have when we’ve been looking at that is if a user’s like me and maybe they’ve got ten apps or fifteen apps, how long does that list and what does that notification look like in the extremes? So it’s something that we’re we’re hoping to to we’re still brainstorming on what that will look like. And for anyone who’s listening, if you reach that deadline, it’s the pop up saying this app is out of date, needs to be updated now, and you get it per app that hits that enforcement. It’s not just a single one. We’re not throttling that because, again, I don’t wanna close apps without telling people why it’s being closed. So I don’t have a good answer for that. Alright. I’ve got two minutes left. One minute. Go on once. Go on. Selena, I I answered one in the chat that wasn’t in QA, but, the best place to request apps, I told them, is the feedback button in the prebuilt apps page in the catalog or in the policies. There’s a, like, a little button that says feedback, and you can just type it in there and hopefully link us to that app you’re talking about. Is that still the best way? Yeah. Right? Yes. Yeah. Okay. Email me that feedback. Exactly. It’s everywhere. And if you don’t know it, product at Addigy, it will will show up. And if you come up with any other questions or you wanna chat more, I’ll be emailing at least one of you after this to chat more. But, please, if you want to do a deep dive, you wanna talk about CVE dashboard and remediation, product at Addigy dot com, you’re you’ll get me and every other product manager, and I’ll start sending out Calendlys to talk with us and our designer. But thank you all for joining. If you’re building cool stuff with that that new KB too with the advanced users, please let me know. I I just you know, I I I love to see it. I love to see what people are coming up with in the community. So, have a good rest of your day, and, look forward to my inbox being blown up.
Video Transcript: Patching Without the Ticket Tax — Better End-User UX with Prebuilt Apps
Introductions
Selina: Today we are talking about Prebuilt Apps: patching without the ticket tax, better UX with Prebuilt Apps. For anyone who is an Addigy customer, you’ve heard me talk about this endlessly, but there’s some new stuff we’ve been doing with Prebuilt Apps, plus a refresher for those who have never used it or have been curious and want to know more.
Selina: I’m Selina, a senior product manager here at Addigy. I was one of the people who helped build Prebuilt Apps, and if you ever have a question, a problem, or a feature request, it’s going to my inbox. I always like to drop our product email: [email protected]. That goes to all of the product managers. If you ever have questions, frustrations, or feature requests and you want our attention, send an email.
Selina: I’m joined by Daniel Allen, our senior solutions architect at Addigy. If you’ve done any of our Addigy certifications, onboardings, or Addigy Boost, you’ve probably come across him. This is his first SudoTalks. Please post your questions in the Q&A at the bottom — we’re monitoring chat as best we can, but Q&A is the best place. Ponce is here to help answer questions as they come in, and we’ll have a Q&A session at the end.
Selina: Here’s the plan: a short intro on why Prebuilt Apps and what it is, then a live walkthrough — everything you see will be in production — then back to slides for the end-user experience, best practices, tips and tricks, forward-looking items, and Q&A.
Why Prebuilt Apps
Selina: For anyone new to Addigy or to this product: the problem many of us have when managing macOS devices is endless packaging. Software like browsers — Chrome updates what feels like multiple times a day — used to require manual packaging, which consumes hours doing a repetitive task. Patching also matters for vulnerabilities: as AI has grown, there are more and more CVEs and zero-day vulnerabilities, and not keeping up with software updates leaves your fleet vulnerable. And there’s user disruption. I’m the worst end user — I never update anything, never close anything, never reboot. That’s difficult when you’re trying to manage a fleet and keep apps updated. How do you do it in a way that disrupts users the least, so they’re not losing data and productivity?
Main Features
Selina: The main features of Prebuilt Apps: we have “latest” and auto-update — set it and forget it. My goal with Prebuilt Apps is that you don’t spend much time configuring it or going back to the page. We have scheduling options if you want updates only during certain windows. We have days-to-delay for the auto-update, so the newest apps don’t go out immediately — you can have a group of QA testers or early-access adopters get the latest immediately as a smoke test before it hits the rest of your fleet. We have update-only, which means “I don’t want to install this app, but if it’s there, keep it up to date” because of security vulnerabilities. A good use case on my personal machine is Spotify: Addigy isn’t pushing Spotify to my machine — I downloaded it because I’m a rascal — but our IT team wants to make sure Spotify is at least kept up to date.
Selina: We include most of the MDM profiles, with an asterisk: we are constantly adding to our PPPC profiles. We do include any relevant system extension or other profiles — more details in the app details of what’s actually included; not every profile needs it. And as with everything in Addigy, we have policy inheritance: whatever you set at the top level inherits down. But unlike everything else in Addigy, we introduced inheritance override to give you full customizability no matter where you are in your policy hierarchy. We have a menu bar, we have it in Self Service, and we have it in Addigy Assist, our onboarding app. Some poll responses are coming in — people are spending five to ten hours packaging, or two to five hours. Hopefully this is something we can get off your plate.
The Catalog
Selina: The catalog is growing. We officially have 220 apps. If you go into the catalog you’ll count 241, but there are some duplicates depending on architecture (Intel or Apple Silicon), and there are apps that are end-of-life, which I didn’t include in this count. This is 220 apps we are actively updating. It also doesn’t include our OS update blockers, which are also in the Prebuilt Apps catalog — those are special one-offs. The last time I gave this talk it was 160, so we are growing and constantly taking in requests.
Requesting a New App
Selina: If you want to request an application, there are a few requirements. It needs to be a publicly available installer, outside of the Mac App Store — if an app only lives in the Mac App Store, using Apple apps is your best bet. It can’t have license keys or anything that needs configuring during installation. One thing we’ve noticed: some installers are publicly available, and then as the company shifts or renames the product, they put the installer behind a login. Once it’s behind login authentication, we can’t keep it up to date, and we unfortunately have to end-of-life it on our side.
Selina: If you’re sending requests, please give me a download link to exactly what you want. Tech companies love names that are nonsensical or spelled with unnecessary letters, so it’s faster for me to process the request if you give me a download link, or at least a link to the developer. You can request apps through the in-app product feedback — it’s all over the place — or email [email protected]. Both go to my inbox, I look at them every month, and we add them to our backlog.
Selina: One known issue: we’re always working on the PPPC profiles. We don’t actually use all 220 apps in our own environment, so for some of these permission prompts we need community help. We’re doing our best to make sure each app has the minimum required permissions and nothing more — we won’t blanket-allow everything — and as macOS moves those profiles to declarative, that’s another thing we’re tracking. Now I’ll kick it over to Daniel for a live walkthrough.
Live Walkthrough: GoLive
Daniel: I know Selina said she’s one of the worst end users for never restarting — I’d argue that’s an average end user. The ones that do restart are the anomalies. I’m in the same boat: I always get the “your computer’s been up for X days” notification and defer it.
Daniel: Let’s get started with GoLive. If you’re unfamiliar, think of GoLive as one-to-one management. If you need to take action on an individual device or find info about it, GoLive is the place. I’ll go to Software, then Prebuilt Apps, and we see the whole catalog for very quick deployment. When we click into an app we can see the description. Selina mentioned the PPPC profiles — if we search for Defender, it’s right there, and you can see the release notes. Always check those, especially for an app you know has configuration profiles that go along with it — check what’s included and what’s not.
Daniel: To deploy an application from here, find the app and hit Deploy, and it installs right now. Callout: this is always the most recent version. When we hit Deploy, we’re deploying the most recent version. Sure enough, Aircall is installed — Spotlight search, by the way, is the best feature on the Mac. But this is one-off: one person needs this app, always the most recent version. We don’t want to do everything one-off.
Live Walkthrough: The Catalog
Daniel: Let’s zoom out and jump over to Catalog > Software > Prebuilt Apps. Think of your catalog as the toolbox — this is where most of your resources live. I’ve got a bunch of things already configured. Clicking into one, I can see where it’s going: in this case, out to the entirety of Iteration 110, and inheritance means it goes down to everything underneath.
Daniel: Looking at my settings: it’s going to Iteration 110 with latest and auto-update, and the update is enforced every ten days. If I want to override that for a child policy — say Everwood needs something different — I check that box, and now in settings I have a new entry (thank you, Addigy, for the handy tag). Notice it defaults to fourteen days; for Everwood I may say update every five days. When we save, that becomes the new setting for anything underneath — so Dreadnought City gets the same setting as Everwood. That’s one of the new features: policy override. You may want Chrome going out everywhere, but with different update settings — we all know how often Chrome wants to update. Some customers or departments can get the update sooner.
Daniel: We can also assign something new from the catalog. Take Aircall: I deployed it one-off for one user, but now I’m getting more requests, and I don’t want to go into a bunch of computers individually. From here I can say everyone at Ashwind needs it, check the box, and adjust settings — Ashwind gets latest and auto-update with a ten-day frequency, and maybe Sky’s Edge stays at fourteen, or gets update-only. Lots of options. Save, and it’s assigned to that policy, and everything underneath starts getting the deployment. Your catalog lets you affect multiple policies from one location.
Live Walkthrough: The Policy Level
Daniel: You may prefer working from the policy level instead of the catalog. In Policies, I’ll open Iteration 110 > Software > Prebuilt Apps. We can see everything going on: Aircall assigned down at Ashwind, 1Password coming down from the parent policy. We can add more, just like anything else — let’s deploy 8×8. Add it to the policy with the same settings: latest and auto-update. Most of the time you’ll go with latest and auto-update, except maybe in testing policies.
Daniel: Like Selina mentioned, maybe we don’t want to deploy the app, but if it’s there we want it kept up to date. If we check update-only, then when the policy runs its condition, it checks: is 8×8 installed? If not, we exit — nothing to do. If it is installed, we check whether it’s up to date, and if not, we prompt the update. The user is forced to take the update within however many days we set. Personal preference: I usually go three to seven days for most applications — five is a nice in-between, and it’s what I do with a lot of customers during onboardings. Hit Assign, and that keeps the app up to date anywhere it’s currently deployed.
Daniel: I can still jump down to Ashwind, see 8×8 with the little briefcase icon, click it and choose Override Parent — maybe I want it updating every two days instead of five. I love the notification here saying “if you do this, here’s what else is affected.” Please take a moment and read it — I’ve been on with customers who had an unintended consequence because we didn’t read a notification. Confirm, and now we have the handy broken-briefcase icon showing policy inheritance is being overridden. I can always come back later and revert to the parent setting, and the enforcement deadline on the far right changes back.
The Menu Bar
Daniel: If you’ve been using Prebuilt Apps for a while, you’ll know that when it first came out, the update notifications were a little noisier than we wanted. Selina and the team have done a lot of work there, and one of the newer features is the menu bar. In Settings at the top right there’s an option — mine is currently on, but the menu bar is off by default. If you’ve never changed the software settings within the policy, your menu bar will be off. What it does is put the notification in the menu bar instead of blasting notifications all the time, making it easy to see what’s going on. The days-to-delay setting also lives here if you want to delay when an update is applied to your catalog or policy.
Daniel: If you have certain policies where you don’t want the menu bar, deselect it, hit Override, and the menu bar disappears next time that policy runs — or never shows up in child policies if you’re setting up from scratch. In my testing, turning it on or off and deploying the policy takes about ninety seconds to two minutes to land on the device.
Daniel: Here’s my menu bar. Notice it doesn’t have the normal Addigy icon — if you have Self Service configured with a menu bar item, it uses that custom icon. If you don’t have Self Service or a custom icon, it defaults to the Addigy logo. (We should have run a poll on what the Addigy icon is — a laptop opening, or a fancy A? I’ve heard both.) In the menu bar I can see available updates: Anka will be enforced in eleven days, Brave in twelve, Microsoft Edge in thirteen — I didn’t plan the 11/12/13, it just worked out. If I want to update one, I click Update, it says it needs to close the app, I click OK, it updates, shows the install progress, and the item disappears from the menu bar when it’s done — then the app relaunches.
Daniel: One more callout: I have these apps purposely running. If an application is not running, the update just happens automatically by the deadline — you only get the notification if the app is running. That’s it for the live demo. Selina has screenshots showing the menu bar with a custom icon versus no menu bar icon. Back to you.
Conflict Resolution and Policy Inheritance
Selina: Thank you. Reminder: Q&A is the place we’re monitoring for questions. Now, conflict resolution. A lot of our customers take advantage of flex policies, which are super powerful, very fun, and personally the bane of my existence. When Prebuilt Apps exist in multiple policies on a device, what happens with conflicting settings? We do not have an answer across the board for all settings yet — I’m actively working through every one of these conflicts — but here are the rules we do have. I dropped a Prebuilt Apps policy inheritance guide in the chat; as we resolve conflicts (like schedules, or install versus update-only, which doesn’t have a resolution yet), it’s documented in that KB.
Selina: The philosophy for conflict resolution is: the most restrictive wins. For user notifications you can have four or eight hours — if a flex policy says eight hours and a location policy says four (or vice versa), four wins. Daniel mentioned this, but end-user notifications when an app update is available and the app is open are now throttled: instead of getting bombarded, we only show one notification.
Selina: For menu bar visibility, we’ve taken a cautious approach. It’s off by default, and we’ve clearly documented all the scenarios for when the menu bar will be visible. One place this matters is the Self Service configuration: Prebuilt Apps can be assigned to Self Service so end users can install and update whenever they want. But if you have the menu bar off in your Self Service configuration, even if the menu bar is on in your policy, it will not display — we treat that as a conflict, and the most restrictive wins (“don’t display” being most restrictive).
Selina: Same with schedules. In previous webinars I highly recommended schedules, largely because end-user notifications could interrupt people throughout the day. Since we’ve throttled notifications, I now take the other stance: schedules are something we no longer recommend by default. They’re still valuable and have a place in some workflows. But if you added a schedule because of the notification fatigue in the early days of Prebuilt Apps, I recommend revisiting it. Important callout with schedule conflicts: the tightest schedule wins — meaning the least amount of minutes and days available for an update. The inheritance KB documents exactly what we mean with scenarios.
Selina: I’m always open to feedback. The next conflict we’re tackling is install-and-update versus update-only in two policies — we need the most restrictive to win, which is install-and-update. If you’re seeing weird things in your fleet, please open a support ticket or email [email protected]. We’re working on making this clear, reproducible, and predictable.
Fine-Tuning Your Deployments
Selina: It’s always a balance between end-user notifications and productivity versus keeping your fleet up to date. Update-only is something I recommend across the catalog — it updates any existing apps you’re not explicitly managing. On my own machine, things like Spotify and Discord are enforced and updated on a regular cadence via Prebuilt Apps as update-only.
Selina: When setting the enforcement deadline, we only allow up to two weeks, and that’s intentional. Some apps only update once a quarter; others update multiple times a week. We want to make sure apps aren’t falling too far behind when the user has up to fourteen days to reach the version being deployed. That stops people from deferring indefinitely — I’ll keep trying not to update things for as long as humanly possible, because when am I ever OK with closing my million browser tabs? Think about what works for your org and for each app: you can be more lenient on some apps versus critical apps, and consider your compliance frameworks — for folks in the UK, Cyber Essentials is fourteen days, which is our maximum.
Selina: The menu bar is fairly new and I’m a big fan. What I really like is it lets people update out of sync — Self Service does this too. We have a feature request to add an updates-only section in Self Service. What the menu bar gives you that Self Service doesn’t is visibility into when an update will be forced. Using it internally, I’ll see “oh no, my Brave browser is going to update right when I’m playing D&D — I guess I’ll do it before then.”
Selina: Also think about your delay buffers if you have testing windows between vendor releases and fleet deployment. We use that internally for early-access folks. Make sure your critical apps are tested before wide rollout so you catch issues before they become a wider problem.
No Downgrades, No Removal Scripts
Selina: Important: Prebuilt Apps will not downgrade. We take the stance that the most recent version is generally the most secure version. If the policy is pushing version 1.0 and the end user has updated on their own to 1.1 or 1.2, we won’t downgrade them. We just check: is the installed version older than the policy version? If it’s newer, we do nothing.
Selina: We also don’t have removal scripts, intentionally — we don’t want people accidentally pressing a button and uninstalling a critical app across their whole fleet. If you remove the Prebuilt App from your policy, the app stays on the device, but it’s no longer kept up to date by Prebuilt Apps. If you need to remove apps, it depends on the app: most can be removed with sudo rm -rf and the path to the application, while others (like Adobe) have more complicated removal scripts. Whatever it is, test before you deploy to production.
Zero-Day Responses
Selina: We reserve the right to pull versions from the catalog if they have a critical vulnerability. If there’s a new version with a critical security fix and you have days-to-delay configured, that fix may not be pushing to your policy yet — you may need to go check, because by default we follow whatever settings you’ve configured. It’s worth looking at your fleet and asking: should I change the deployment window? Should I go to GoLive? I’d like to say zero-days are less common, but the opposite is happening these days. As you configure enforcement windows, think about which apps you regularly read about in the news for zero-days.
Helper Tool Pop-Ups
Selina: I get asked about this a lot. Apps like Slack, Postman, Discord, Visual Studio Code, Firefox, and all the browsers have helper tool pop-ups. For now, we recommend creating a separate MDM profile if the developer allows it — not every developer has an MDM profile or key to turn off those pop-ups. If you’re working with a developer that doesn’t (Asana, for example, has no way to turn off those update prompts), please reach out to those app developers, because in the enterprise those helper pop-ups are very annoying. For the ones that do support it, create the MDM profile and push it.
End-User Experience: Addigy Assist
Selina: Prebuilt Apps came out about two years ago, and we’ve been adding it across the full device lifecycle. Addigy Assist is our onboarding app. As devices enroll — through automated device enrollment or manual enrollment — this app can pop up and show what’s happening: your company logo, a customizable name and message, contact information. It holds users at the screen so they can see exactly what’s happening while the device is prepared — what apps are installing, getting them ready for their first day.
Selina: Prebuilt Apps can be assigned to Addigy Assist along with MDM profiles, Apple apps, Smart Software — pretty much anything you can imagine. It displays the progress (“here’s everything we’ve done”) so the end user has full visibility. It can appear as a small app window, or full-screen where it takes over and locks them in. It can trigger a restart, and at the end it says everything is set up, they hit Close, and it closes out. Note: Addigy Assist does not follow schedules — so if you want deployment during onboarding outside a schedule, this is the way.
How Prebuilt Apps Works Under the Hood
Selina: What’s actually happening? Every thirty minutes when the policy runs, we do a silent check. The very first thing we check is whether a schedule is configured. If there is one and you’re outside of it, we stop — nothing else happens. That’s the pro and con of schedules: very powerful and very limiting, especially if you’re onboarding new devices outside the schedule without something like Addigy Assist — the apps won’t install. Same with Smart Software. It’s a bit of a hammer.
Selina: If you’re in schedule: is the app closed? If the app is closed and out of date, we run a condition check — what version is on the machine versus what version should be — and we just update it. The end user will never know. I do that regularly: when I know an app like Spotify has an update, I intentionally close it so Prebuilt Apps takes care of it and cleans up my menu bar.
Selina: If the app is open, needs an update, and it’s been four or eight hours since the last notification, the user sees a branded notification: “this app needs an update — update or defer?” It times out after sixty seconds, and if you do nothing it auto-defers. The menu bar shows a red dot when there’s an update, shows when it will be enforced, and lets people update on their own. The deadline shows in the pop-up and in the menu bar. If you’ve never set a prompt frequency, we default to eight hours — the idea behind four or eight hours is whether users see it once or twice in an average workday.
Self Service and Update Prompts
Selina: The prompt can be branded based on your Self Service configuration; if you don’t have one, we use the default Addigy icon. It shows the enforcement date — how long you have. When the enforcement date is reached, it says: this has to update, it’s updating in sixty seconds, or do it now.
Selina: In the Self Service app, an assigned Prebuilt App (Microsoft Teams, say) shows an Install button and app details, so people can install whenever they want. When there’s an update, the Install button changes to Update — we don’t have a dedicated updates tab yet; the menu bar is what shows only apps needing updates. If you click Update while the app is open, it will be closed to install the update, and the window closes automatically. When we close an open app for an update, we relaunch it when it’s done — it doesn’t stay closed. It also shows what version things will be updated to.
Selina: More menu bar details: with Self Service you can also expose options like chat and open-a-ticket, all controlled in your Self Service configuration. The menu bar shows only updates (not installs) and when each will be forced, plus an Update All button when there’s more than one.
Reporting
Selina: We have reporting on Prebuilt Apps in historical dashboards. Please send feedback if you’re using it, whether it’s useful, and — more importantly — what else you’d like to report on that isn’t covered. Email [email protected]; I’m always interested in exactly what reports folks want for their Prebuilt Apps catalog.
Advanced: SQLite Database, Terminal Commands, and API
Selina: This one is brand new. Shout-out to Jeremy Kenny at Global Mac IT, one of our customers, who built an open-source Support App plug-in for Prebuilt Apps. If you’re not using our menu bar but you use the Support App menu bar — which I don’t blame you for, it’s a great app — you can still utilize Prebuilt Apps. When we built the menu bar, we changed how Prebuilt Apps works on the machine and got intentional about status tracking. We do that through a SQLite database on macOS — every Apple device ships with SQLite3 — and Prebuilt Apps uses it to give you real-time status of exactly what’s happening on the machine.
Selina: There are also terminal commands you can run for ad hoc installations if you want to use scripting, and an API where you can update configurations and query the catalog. If you have programmatic workflows, the API is there — combined, you can build some really cool tools; the Support App plug-in was the first. As always: treat API keys like passwords, use least-privilege permissions, and don’t post keys in scripts in plain text. And for anyone tapping into the SQLite database: query only, please. If you modify anything in it, things will probably break, we won’t be able to diagnose it, and it’ll be a head-scratcher for my engineers. Read-only — and if you do modify it, at your own risk. Test — don’t do any of this in production first. This KB article was literally just created. If you’re new to Prebuilt Apps, start in the UI and think about the advanced stuff later.
Forward Looking
Selina: We’re working on a CVE detection dashboard for Prebuilt Apps — in progress. If you want to see it and give feedback, email [email protected]. I’m actively looking for feedback on the next iteration, which is auto-remediation, and I’m desperately looking for UI feedback on our first iteration, especially around reporting.
Selina: We’re also aware of updating the end-user notification UI — we currently use macmanage and want to move it to Swift. We’re working on providing the helper-tool MDM profiles to you for eligible apps; that will be opt-in — I’ve learned the hard way about forcing anything on anyone. Yes, notifications do not respect Do Not Disturb — we’re in discovery; it happens to me too, I hear you. Same with unified notifications — one notification saying “some apps need to update” instead of app-specific ones. Note: when we do unified notifications, they’ll only apply if you use Self Service or the menu bar (we’ll probably do one first, then the other). If you use neither, I have nowhere to send you for unified notifications yet.
Selina: Before Q&A: this recording will be sent to you and available on the website. For more sessions, go to addigy.com/events, and leave feedback on topics you want deep dives into — we’d love to hear what you want to know more about instead of guessing. And something new and exciting: we’re doing a free virtual conference called Frontier. It will be recorded, so if your time zone isn’t conducive, it’ll be available. Reach out to your account team or scan the QR code. And if you want to learn more about Prebuilt Apps, raise your hand in the poll and we’ll reach out — or contact your account team or [email protected].
Q&A
Daniel: Two similar questions from Pedro and Yaron: they like the menu bar, but they want the same functionality in the Self Service app.
Selina: So — a section to see just the available updates in Self Service, and I’m assuming you also want the deadline for when the app will be enforced. Pedro’s confirmed in chat. I’m now the PM for Self Service, so I’m looking into it and gathering metrics to get it prioritized imminently — I don’t have a date. Pedro, I got your email this morning; Yaron, if you can also email [email protected], that helps me show the demand for the feature request. It’s not available now, but because we’re working on the CVE work, we have an interesting window between the dashboard iteration and auto-remediation, and I’m trying to land some quality-of-life improvements there.
Daniel: Next question: is it a good idea to select the most common applications in a high-level policy set to update-only, then in a lower policy set them to install-and-latest to cover updates even if the user self-installed the apps?
Selina: Yes — a lot of people do that. Many folks bulk-select everything in the catalog as update-only, then use install-and-latest in the lower policies. That’s fine in a hierarchy. One caution, which came in through in-app feedback: conflicts in flex policies. If a flex policy is set to update-only and a location policy in the hierarchy is install-and-latest, right now it’s a little random whether it actually installs — which is not the behavior I want. I want conflict resolution where the install wins. Today, with flex policies, it can be unpredictable, so I don’t recommend having conflicts between those two settings. In a policy hierarchy, update-only at the top level with install-and-latest as an override below it will work — it’s only when flex policies come into play that things get weird.
Daniel: If a Prebuilt App is set to update on a time frame longer than the release frequency, does that mean the app is never updated, or only updated when the app is closed?
Selina: Potentially, yes. If you’ve set fourteen days and the app is constantly updating, you could be in a situation where it’s potentially always out of date. Let me use Google Chrome as an example and pretend it only updates once a week (which we know isn’t true). If your enforcement is two weeks, the enforcement keeps getting reset when a new version comes out, and you’re stuck unless the user closes the app. It gets more complicated with days-to-delay, which can extend it by another week — then you’ve got a three-week window before things get enforced. I highly recommend not setting fourteen days across the board. Look at what’s actually happening for each app: Microsoft pretty reliably updates every Tuesday; Chrome updates randomly, multiple times a week; other developers update less. Check the app details — you can see exactly when we’ve published every version. If the catalog updated an app six times in the last week, it needs a tighter enforcement date.
Daniel: Ken says: my issue with Prebuilt Apps is that if a user hits the deadline with several running apps not updated, they get pop-up after pop-up.
Selina: Yep. I’m looking at unifying that. The enforcement-date pop-up is the only one we’re not throttling right now, because I don’t want to start closing apps without telling people the app needs to be updated. Unifying it and showing all the apps is something we’re looking at — the open question is, if a user has ten or fifteen apps, how long does that list get, and what does the notification look like in the extremes? We’re still brainstorming. To be clear for everyone: when you reach the deadline, you get the “this app is out of date and will update now” pop-up per app that hits enforcement — not a single combined one. I don’t have a better answer for that yet.
Daniel: One from chat: the best place to request apps is the Feedback button on the Prebuilt Apps page — in the catalog or in policies — and link us to the app you’re talking about. Is that still the best way?
Selina: Yes — or email [email protected]; it will show up either way. If you come up with other questions or want to chat more, I’ll be emailing at least one of you after this. If you want a deep dive on the CVE dashboard and remediation, email [email protected] — you’ll get me and every other product manager, and I’ll send out Calendlys to talk with us and our designer. Thank you all for joining. If you’re building cool stuff with that new advanced-users KB, please let me know — I love seeing what people come up with in the community. Have a good rest of your day, and I look forward to my inbox being blown up.
Frequently Asked Questions
What are Addigy Prebuilt Apps?
Prebuilt Apps is Addigy’s catalog of pre-packaged, automatically updated macOS applications. Instead of manually packaging and repackaging software like browsers that update multiple times a week, admins deploy apps from the catalog with “latest” and auto-update settings, and Addigy keeps them patched — including relevant MDM, PPPC, and system extension profiles for most apps.
How many apps are in the Addigy Prebuilt Apps catalog?
The catalog contains 220 actively maintained apps (241 total entries, counting Intel/Apple Silicon duplicates and end-of-life apps), up from 160 at the previous talk. It also includes OS update blockers as separate one-off items, and the catalog grows continuously based on customer requests.
How do I request a new app for the Prebuilt Apps catalog?
Request apps through Addigy’s in-app product feedback button on the Prebuilt Apps page, or email [email protected] — ideally with a direct download link. The app must have a publicly available installer outside the Mac App Store and require no license keys or configuration during installation.
How does Prebuilt Apps handle conflicting settings across policies?
The guiding philosophy is that the most restrictive setting wins. For example, a four-hour notification frequency beats eight hours, the tightest update schedule wins, and a menu bar turned off in the Self Service configuration overrides a policy that has it on. Some conflicts, like install-and-update versus update-only in flex policies, are still being resolved and are documented in Addigy’s policy inheritance KB.
What is the update-only option in Prebuilt Apps?
Update-only tells Addigy not to install an app, but to keep it up to date if it’s already on the device — useful for self-installed software like Spotify or Discord. When the policy runs, it checks whether the app is installed; if not, it does nothing, and if it is installed and out of date, it updates it.
Will Prebuilt Apps downgrade an app to an older version?
No. Prebuilt Apps only checks whether the installed version is older than the catalog version. If the user has a newer version than the policy specifies, Addigy leaves it alone, on the principle that the most recent version is generally the most secure.
What happens if I remove a Prebuilt App from a policy?
The app stays on the device — Prebuilt Apps intentionally has no removal scripts, to prevent accidentally uninstalling a critical app fleet-wide. The app simply stops being kept up to date by Prebuilt Apps. To remove it, use the app’s own removal process and test before running it in production.
How does the Prebuilt Apps update process work on the device?
Every thirty minutes when the policy runs, Addigy performs a silent check. If a schedule is configured and the device is outside the window, nothing happens. If the app is closed and out of date, it updates silently. If the app is open, the user gets a branded notification (throttled to every four or eight hours) to update or defer, with the enforcement deadline shown in the notification and menu bar; at the deadline the update is enforced, and the app relaunches after updating.