Transcript
Hello. These lights are very bright. I can't see any of you. I'm pretty nervous. Can I have another clap? Is that all right? That was purely for ego. I was totally joking. Thank you very much. I will take it, though. Thanks. Yeah, so my name is Luke. It's nice to meet all of you. I have worked in the kind of the Apple admins community for 13 years at this point, and I have listened to customers struggle with software updates every year that I've worked in this industry. So I worked first at Apple, came out of university, and I worked in the systems engineering team in the UK. Some of those folks are here today. I did eight years doing that, and then I left, and I've come to work at Jamf, and I've done five software updates for a long time. Who attended my talk last year? Not that I can see any of you, but who didn't see me talk last year? It's probably what I should have asked. Good. For those of you that were here last year, know that it's a little bit different than last year, so you don't need to get up and leave. Please stay where you are. It is worth mentioning, though, that we do a software update talk every single year, and, of course, this year is no different. The reason that we do that is because it's one of those topics that is perennially difficult. It's really challenging for a lot of people. It touches every person's life as an Apple admin, and it's one of the most difficult parts of being an Apple admin. So what I'm going to do is take you on a bit of a journey, and we will look at OS upgrades at scale and what they look like in 2026. Does that sound reasonable? Cool. You're still awake after lunch, which is nice. So the first thing that we need to do is to understand why software update is important, why we even bother with it. Why not just lock in on a version and then come back to it three years later and do it again? Why do we need to keep up with the pace of releases? So, like I said, I used to work at Apple, and it's really interesting to see how, over time, the narrative that supports software update has changed. So when I was at Apple, the story that we would talk to customers about was around ensuring that the experience in enterprise and education deployments mirrored as closely as possible with the consumer experience. You wanted people to have a really great experience in those environments. And, of course, that's still true today, and if you talk to Apple people, they will absolutely talk to you about that, and it's important. It really is important. We want people to be happy using those devices, but there is also another strand of the narrative that becomes more and more important every year. And of course, that's the security element of it. So at this point, every Fortune 500 company has Apple devices in some kind of scope and size, and so that represents a much larger attack and threat vector for people out there who are trying to target your organizations. And so, with that in mind, I'd like to show you some numbers that help to bring this into a bit of context. Now, none of you have a clue what this means, right? 495, I would ask you to guess, but none of you have any context for this. So 495, it's an interesting number. 495 is the number of CVEs that existed or that have been addressed by Apple in macOS Tahoe. So what do I mean by that? I mean by from 26.0 to 26.5.1, and all the software updates that existed between those two versions, 495 common vulnerabilities and exposures. For those of you that are not security-inclined, what CVE effectively means from a simple layman's perspective is when a vulnerability is identified in software, it's kind of given a serial number so that you can look it up and see information about that particular vulnerability. So Apple has done a fantastic job. There is a very, very, very small source in the bottom right-hand corner if you'd like to take a screenshot and go and look at it on your own time. But That 495 means about 58 CVEs every month since the release of macOS Tahoe. Also really important to think about this in the grand scheme of all of the operating systems. We're just looking at Tahoe in this case, so we're not looking at iOS 26, iPadOS 26, TVOS 26, watchOS 26, VisionOS. We're just looking at macOS Tahoe. So that's about two every day since the release of macOS 26, which is quite significant. Just for your information, if any of you are still running anything below 26.1, that had the biggest number of CVEs addressed with that release. There was 111 CVEs that were addressed in that particular release. So if you are running that version or if you're running anything less than that today in your organizations, that's the one thing that you take away from this is that you go and update your software. You have no context for this number. Does anybody want to guess what it is really, really quickly? I have no idea what you said, but it sounds like two of you said it at the same time, so you must be on the same wavelength that I'm on. I'm going to say yes. I have no idea what you said, but yes. What it actually is, are you all right? I have no idea what you said. Seven known exploitative vulnerabilities. Of those 495, still talking about Tahoe, of those 495, seven of them we know were exploited. We know that they were used by attackers out in the world somewhere. Known exploitative vulnerabilities were found in the releases that were addressed by Mac OS 26.1, 26.2, and 26.3. So again, if you have anything less than 26.3, it's very important that you get on that immediately. Really, really simple stuff. It helps to illustrate, it's actually a good thing. It's great to see Apple documenting this stuff. It's excellent that us as Apple admins are able to go out and become aware of this stuff. We know when an important release drops, so we can make important changes within our organization to protect our end users and our organization, which is great. It's really nice to see that Apple stays on top of this stuff, because it hasn't always been the case that you've been able to see this information. So it's really good. But obviously, update your devices. For those of you that did see me talk last year, there's an additional strand, and it's probably been evident in all of the sessions that have been talked about today. It is AI is inescapable. So a really short anecdote. Back in April 2026, Anthropic heavily marketed Mythos, which is their vulnerability-finding AI model that they had trained, that was, in their view, it was too powerful to release to the general public. So what they did was they created this internal project called Project Glasswing, and the idea was that they were approaching organizations around the world, big software vendors, to allow them access to this model to hopefully find vulnerabilities in their A few of you. For those of you that haven't, Curl is a really mature and very security review, because it's open source, piece of software that kind of underpins pretty much everything that we do in terms of remote access communication calls on the internet. It underpins HTTP and HTTPS. Billions of people use it every day. It's about 30 years old, and as a result of that, it's been pretty well looked after. So the folks at Anthropic approached the folks that work on the project, and it was found that there was five vulnerabilities that this piece of software that had been worked on in public for 30 years that Mythos had found. Three were actually false positives. One was a bug. And there was one vulnerability, but it was very low, and in fact, they didn't feel that it warranted pushing out an immediate release. They rolled it into the next one. However, contrast, this pretty much speaks for itself. You can kind of see where AI has really taken off and how that's impacted software development over time. So this graph is from Mozilla, and it shows security fixes by month, and you can kind of see where they got access to Mythos. So I think the takeaway from this is that AI dramatically reduces the effort that's required to discover the vulnerabilities, to analyze software, and one of the things that's really powerful about it is the ability to not only discover the vulnerabilities really quickly, it's to be able to then chain them on top of each other and do that from an automated perspective. So this is just another reason that it has never been more important to have a really good plan in your organization around how you plan to take one device from this version of the OS to this version. If you were in my talk last year, I presented exactly this slide, and I will tell you why I'm presenting it again. I even kept the same theme. I don't know if James is in here, but he will be furious. I should say, James and Udita, thank you very much for all the hard work you do. They're the people that do all the cool graphic design for everything that we do at Jamf, so thank you very much to those guys. Yeah, so following W3C last year, Apple put out this statement. It was in the very first What's New document that they released, and they said, we are deprecating the old commands, restrictions, com.apple.softwareupdatepayload, and the queries associated with all those things are going to be deprecated next year. Why is that relevant? This is next year. So I bring this up now because if you are still clinging to kind of old methodology, like this is a really interesting pivotal year, both from a Jamf perspective and from an Apple perspective. From an Apple perspective, because if you are clinging to things that have just worked, and of course that's totally reasonable. If it's worked, why change it? If you are not yet using modern declaration-backed ways of being able to upgrade your devices, now is the time to start thinking about that over the summer before the 27 releases show up. Fortunately, you saw Katie and I demoing Blueprints this morning on the main stage, and Jamf customers are ready to be able to use DDM-backed software update. It's been available in the product for a good number of years at this point, but I would be remiss if I didn't mention that you absolutely do need Jamf account single sign-on to be able to do that. So once again, if you are in this position, now is the time. Spend the summer figuring out how to pivot to Jamf account single sign-on. I know all the Jamf people in the room would be more than happy to talk to you about that. This is normally the part in the story where, when it comes to on-prem customers, this is where the narrative stops. It's like, hey, it's all great for cloud customers, but one of the things that's really great is that not only if you're in the cloud, if you are on-prem now, you are able to take advantage of DDM-backed software updates, which is really great. And I know a lot of customers, I've spoken to a lot of customers, who are still using on-prem to deploy their devices at scale, but now you can feel safe knowing that you have modern, supported, DDM-backed technology to be able to help upgrade your devices come new release territory, which is really good. Huge win for our on-prem customers, especially important for those folks who are in environments like high security, regulated environments, government, and so on. So, software update, it's never been more important. This year has also been coincidentally huge because of the deprecation stuff and because of the changes that we're making at Jamf. Apple's footprint in the Fortune 500 means that Apple devices that are deployed into enterprise and education are more at risk than they've ever been, but it's evident that Apple's doing a really great job at ensuring that they publish regular fixes and that they're documenting that stuff as well, which is great. We know that if you're running anything less than 26.1, 2, or 3, you absolutely need to get on that right away as soon as you get back home from this event, maybe even beforehand. And we know that AI is getting smarter and faster, and it's become democratized. People are able to get access to it very easily, and that represents risk in terms of vulnerabilities, like finding vulnerabilities in software. However, you folks, being Jamf customers, are in the best position that you've ever been in to be able to take advantage of things like blueprints and things like set and forget that we showed this morning so that you can automate this stuff and kind of forget about it, which is great. So, hopefully, this reinforces why software update is important and it has never been more important to your day-to-day lives as Jamf admins. So, my Mac has gone to sleep. Strong. I've got a little question for you. There it is. I have a little question for you. If you wouldn't mind all pulling your phones out, pointing at the QR code, it's all anonymous. No one's going to be taking your information or pointing you out specifically. or pointing you out specifically, so I will give you a second to join. What I'd like to know from you is, what tools are you relying on for software update today in your organization? I can see that seven of you have joined, 14 of you have joined. I'll wait for that number to creep up a little bit, and then we'll have a look at the results. Say again? Ah, yeah, that's reasonable, fair enough. Pick the one that's most relevant to you. Pick the one that's most contentious. I will make the results public so you can all see what the room thinks. I have no idea, I've got no clue what you folks are doing. Cool. Cool. Six percent of you living the dream. Cool. That's great, it's good to see. Okay, great. And I've got one more question for you. Most important one. Have you read the software update section of Apple's deployment guide, yes or no? Bear in mind, this is absolutely anonymous, and nobody in your organization is gonna find out what the truth is. Oh, significant, okay. Are you in the right place? Which is good. Now, I'm not gonna speak to that right now, but I will speak to this as I go through because I had a hunch around how this was gonna go. So, let me carry on. So, last thing I'll ask you, and I'll show our hands. So, what I'd like you to do is take your preferred hand. I'd like you to cover your eyes. This is a safe space in this room. We're all gonna keep each other honest. And what I would like you to do is, if you think this is a fair statement, software update is generally really hard. I'd like you to raise your hands. Honestly, come on now. A good chunk, probably a majority of you. Okay, put your hands down, and then you can all look. All of you found it really difficult. I have been doing this for a really long time. I know a lot about Apple technology and Jamf technology, and I think that this is one of the broadest, most complex topics across all of deployment, security and management. I think it is the thing that people struggle with most. In terms of the user experience, and the actual ability to deploy software updates, it's super easy. But the actual topic of software update is very broad and complicated. I have a lot of opinions on why that is. But I think that there were some things that were immediately obvious to me based on what you all voted for. First takeaway, none of you read the documentation. None of you read the documentation. It might help, but to be fair, there is a lot of it. It's pretty dense, and in terms of documentation, what is written in the documentation and what actually transpires, like the difference between the documentation and the process are not necessarily one-to-one, which is a challenge. And also, probably worth mentioning is that the reason that you all invest in mobile device management is so that you can have us do all of that hard work for you. Why should we have to go read the documentation? I have read it. I've done a lot of testing. It is complicated, it's very deep, and it's pretty complex. It was also evident that from a community perspective, there's no kind of, like there was definitely, like it was good to see Jamf at the top of that list, absolutely, but if you were to add up all of the other categories, I think it probably made a majority, I think. I can't remember off the top of my head, but I think it was a majority, which means that even in 2026, there isn't like one agreed best practice Apple admin's way of doing this. Like some people are using super, some people are using something else. Some 6% of you are living chaotic lives and you let your users do it themselves. But it was evident that a big chunk of you, like a significant chunk of you, are not using your MDM tool of choice to upgrade your devices. I think one of the, if we look beyond the Q&A, the kind of slider thing that we just did, there are some things that I think make it quite difficult. From a visibility perspective, you send the commands out, regardless of what flavor of MDM you're using, you send the commands out, and it lands on the device, and from there, you kind of lose a bit of visibility to what's happening. It's great from the user's perspective, and they're guided through the process, but once you've sent that command, you don't know what's happening. Kind of couples really nicely with this one, which is, if it does fail, why did it fail? What went wrong? Again, the process is great from a user's perspective, but from an admin's perspective, there isn't a lot of information that comes back to us to be able to make informed decisions when things go wrong. And things do go wrong. I think I'm a big proponent of the current format of software update from Apple. I think it's the best that's been for a really long time, but it is very user-side focused, rather than admin focused. And there are, people in the audience will be very quick to tell me that there are status channels that give you information about failure of software update, but unfortunately, if you've ever done any research into it, it's never human-readable error codes. There will just be undocumented error codes, so you don't really know why it's gone wrong. And of course, you have to kind of proactively go out there and find those devices that have failed, which requires a little bit of digging, which is quite difficult. And then there's the kind of the emotional element, like the people element. All of you folks in the room, presumably, or most of you, you might be in a regulated industry, you might be working in government, you might be working in healthcare. If something goes wrong, and you are deploying those 26 zero devices, and you're using devices that are known to have vulnerabilities, and something goes wrong, people will come and point fingers at you. So it's quite hard, right? You all, in fact, I asked you all, and you all stuck your hands up. Well, most of you stuck your hands up, it is hard. So to summarize, we mostly agree that software update is really hard. We've covered the why behind it. I've been in this career for a really long time, and I've seen a huge range of workflows that come and go. I've seen manual stuff, like people physically touching glass, it's disgusting. I've seen netboot, like net install. I've seen scripted stuff. I've seen different apps. I've seen different tools that are on top of each other. The landscape has changed a lot. But when it comes to software update, I think that we've normalized the complexity that comes around with it. It's like, hey, it's software update, it has to be hard, right? And of course, one of the promises, what we try to do every day here at Jamf is to abstract you away from that complexity layer and make it easy for you. But I think that from a software update perspective and the way that Apple has crafted it, it's kind of evolved into one of those bits of the job that has become a bit operationally challenging to manage. It's very good, though. But it is very difficult. I've already referenced it, but different environments have different constraints. So if you're in security, you're in higher education, you're in healthcare, you're in banking, you're in government, whatever, all of those different verticals will come up against this in some shape or form. So ultimately, I think over time, we've collectively become conditioned that software update has to feel difficult. So yeah, thanks very much for listening. I'm just kidding. I'm just kidding. Wouldn't it have been great there if that was the end? Like, thanks for those tough out there. Good luck. So over the years, wouldn't that have been amazing? I'll see you later, guys. Over the years, I have thought a lot about all these challenges, and I wanted to build a solution to this problem that felt modern, and it gave people a tool that they could use without having to read any documentation, which is entirely evident that you folks definitely need. I wanted it to work on whatever device felt most appropriate to you, whether that's your iPhone or your Mac or your iPad. And I wanted it to work whether you were on the go or whether you were at your desk or whatever. And I also wanted to do it in a way that would feel like the best of Jamf whilst also providing like a really, really great Apple native experience. So I spent the last two years working on this, and I would like to introduce you to Upgrade Manager. Go on then. Thank you, mate. Two years, thank you. So Upgrade Manager. Like I said, I've been working on it for a couple of years. The idea of Upgrade Manager is that it'll help you automatically find devices in your organization that are not currently up to date, and will do all the heavy lifting for you to be able to figure out what version of the operating system it can currently run. It'll help you schedule it, and then it will give you real-time feedback as it moves through the process. It's a really, really powerful tool. It's underpinned with push notifications, so if something goes wrong, you'll get a notification on your device. And the best part about it, in my view, is that it works on the device that's most appropriate for you. So if you're on the go and you wanna use it on the iPhone, that's great. If you're sat at the desk on your Mac, it also works there as well. So what I'm gonna do is I'm gonna give you a quick demo. So I appreciate this is a little bit small, but hopefully you folks at the back can see it. This is it running on my device. What you can see here in this list is my Jamf Pro instance, and I appreciate that I only have nine devices. You probably have a few more in your organization. But the reason I'm showing this on the iPhone is because, and the reason that I targeted the iPhone as the original platform is because I wanted to make sure that for those of you that are deploying in any kind of scale, I feel like if we can get it right here, and it feels like a great experience here with the scale of devices that you have, you know, it's gonna be a great experience overall. So what you can see here is the main devices tab. All I need to do is pull down to refresh, and what you'll see in this list are all the devices in my Jamf Pro instance right now that are currently not running on the latest version of the operating system. So what I'll do is I'll dig you into a detailed view to show you a little bit about a device. So we've got my MacBook Air here. You can see that Luke's MacBook Air has the user underneath, Luke Allen. I appreciate this is a little bit fuzzy for those of you at the back, but what I'm looking at is that currently this MacBook Air is running 26.3.0, and currently for this device, it is capable of running 26.5.1. I didn't have to do anything. I didn't have to read any documentation. I can immediately choose to upgrade the device from this screen, or I can go back and delve a little bit deeper and select a few different devices. I mentioned targeting lots of devices and doing this at scale. One of the things that I've built into this that I think is pretty cool is the ability to filter specifically to devices that you want so that you can really get granular with devices in your organization. So from the list, you saw that I had iPhone, iPad, and Mac. Well, let's say that I want to focus on my Mac and my iPad devices, and then I want to get even more granular, and I want just to look at the virtual machines that I have in the organization and the iPad, and then I'm going to go even further and say, hey, I want to look at my virtual machines and my 10th generation iPad, and I'll hit Accept, and we've got that menu that's narrowed. We can go even further and say, hey, I want to select all these devices and I want to upgrade them. So what I'm going to do is show you how this looks for real and do a really compelling demo and upgrade a device. Okay. So if we find Samantha in the list, this is Samantha, and you can see that Samantha is running macOS 15.5.0, which is fairly out of date. Have a look there. We're running macOS Sequoia 15.5. That's pretty out of date. We should probably do something about that. So you can see from the application that I have the option to upgrade it to 15.7.5, or I can take it to the latest and greatest, which is 26.5.1. So what I'll do is I'll tap on Upgrade. I'll choose a date. I'll say, hey, I'm actually going to do it right now. I'm actually going to do it right now. I'll do it right now. One of the great things about software update and the process and the user experience that sits behind it is that if I set the deadline as now or in the past, it'll push the device straight through it. So the app has brought to our attention that, hey, this is all out of date, and we need to do something about that. So what I'm going to do is I'm going to choose the latest OS that is currently available of running, and I'm going to hit Upgrade. So I immediately get a response from the device. Again, I appreciate this is a little bit small, but what you can see here is that this particular device has already gone through to the prepared stage. I think one of the things that's been, I think the automatic software updates are all enabled on this particular VM, so it's been pulling it down while I'm talking. But you can see that you get timestamps on the device as it goes through the process. You can see that this device is now overdue. And it's scheduled to upgrade. And you can see, if we go into Software Update Settings, your organization requires an update to macOS Tahoe 26.5.1. You can choose to upgrade now, or your device will restart today at 2.29. Well, I'm not going to make you wait till 2.29. But you can see in the menu that it's ready to go. It's already resident on the device. It's ready to go. So I know, as an admin, I've scheduled this device. I know it's going to upgrade. Really, really helpful. One of the things that's also great about this that I didn't mention earlier is, let's say that some of you mentioned in the Slido poll that you're already using things like Set and Forget. Hey, why would I need this if I'm using Set and Forget? This is a really excellent companion to Set and Forget. So if you've already got a method to upgrade your devices that's working for you, and it's great, you can still use the app to be able to monitor upgrades that exist beyond this application. So you can see here that I've got another device in this list already that's currently downloading an upgrade. And you can see further down the screen there that it says Blueprint Set and Forget. So this device is upgrading itself right now. It's downloading the new OS. And you can see the timestamps and everything like that. And we can see that, in this case, the origin was Set and Forget. So really, really helpful in terms of visibility and monitoring. So I have complete control and visibility into everything that's going on in my organization from a software update perspective. So in terms of roadmap, we don't often do roadmaps. But this is my philosophy in terms of roadmaps. I have a cruel walk-run approach to how I'm thinking about this. Before I started in the Apple admin space and my career at Apple NGF, I did a computer games development degree. And I'm a huge games nerd. And so my inspiration for everything to do with software development is based on one of my favorite games designers, Jeff Kaplan. And if you are familiar with Overwatch, he had a 10-year plan for Overwatch. And he modeled it on this idea of cruel walk-run, which is, I don't have a 10-year plan for this application. But the idea is really simple. I have some really simple, quick things that I want to get done immediately. And then we have a bit of a medium term and a bit of a longer term. The reason I am showing you this is because I want this to be a tool for you folks, like a tool for the community to make things easier for you, to help you folks out. And so if you look across this, and this is not an all-encompassing, comprehensive list, but if you look across this list and you think, hey, there's stuff that's missing, or I want something to be further up, please come and talk to me about it. And I will publish this somewhere that's public so that you can comment on it and make suggestions. The things I will call out immediately, I did show this on an iPhone today. Some of you in this room have been beta testing this since January. And I thank all of you a lot, because it has changed significantly since then. The Mac OS version is coming in the next few weeks. An iPad support will come shortly after. It will be a fully-fledged native Mac OS experience with everything that you'd expect. Under the hood, it was built with Swift data in mind. So one of the really great features with that is that if you are using this app today and the app comes out in a few weeks' time, you can sit down at your Mac, and all of the things that you've done on your phone will just automatically show up and sync for you. Currently, it doesn't have platform API support. It will do very shortly. And you've probably heard lots of people talking about platform API today. It actually allows me to do things in a much more efficient way. So I'm looking forward to being able to put that in there. And currently, at the moment, it doesn't inform you with push notifications, although all of the tracking for that stuff is under the hood. So again, in the next couple of weeks, you will get push notifications for failure, for updates, and notification when new things come out, and stuff like that. Big thanks to Jordi and Lab9 for allowing me to use the screenshot. They were one of the folks that have been using this. The simple call to action is this. Use the QR code or go to jamf.it slash upgrade manager. Please try this out. Give me feedback. I will say it is in private beta. It is being released ultimately with Jamf Concepts. So if you saw Setup Manager this morning, or you saw Setup Checklist, that's the kind of the program that we have internally to be able to allow people at Jamf to be able to release software that's not productized. I will say that because this is a Jamf Concept, it doesn't come with any kind of warranty or support. Use at your own risk, but it's really good. With that, I look forward to hearing any feedback that you have, and hope that you all get the opportunity to use it. I have probably five minutes left if anyone has any questions. I don't know if we have any mics. There is a question. Sorry, Michael. Hello there. Hello. So with this tool, the user will be notified via push notification on the top right of the screen. Alternatively, within system settings general about, sorry, software update, they can see there that the update will be applied at that time. If the user has focus mode set on, for example, to suppress the notifications, does it still appear? And also, for example, if they're in a Zoom call or an app that also toggles the focus mode, does Upgrade Manager get around that, or does it use another method to notify the user other than the user having to manually go into system settings and then the software update to see that message? Thank you very much for your questions. Good one. So the magic here is very much as a product of me being, I flatly should say this, the reason this is possible is because of all the incredible tools that Jamf has made available, right? The Jamf API is what underpins this, and it's a really rich ecosystem that's been built on for the last, like, 15 years or something. It's been around for a really long time. The application effectively does a nice job of being able to hook into all of the bits of information that we are able to pull from the device, like surrounding software updates. So that's status channels that talk about where it is in the process. So it didn't get a great look at it just then because it's quite difficult to do on stage, but when I say real-time software update, I mean you literally can watch it, and it will change, and it will be to the second. The reason that all that stuff is possible is because Apple has done a really great job of building a really nice system around software update that provides, like, to the second changes, and I'm kind of like hooking into all the status channels and then building a model around that, like building some logic around that. So when it comes to the user experience side of it, I'm not in charge of any of that. That is purely me just sending a command to the device in the same way that we would with Jamf Pro, in the same way that we would with things like Blueprints and Set and Forget. In terms of what the user experience feels like, you saw that notification slide in. In the documentation, there is a really excellent image that shows what the user-facing side of software update looks like as the deadline lapses. So again, in the demo that I did, you saw that, like, hey, the deadline is right now, and so it pushes the update now. If I said it was two weeks from now, the user notification side of it depends how long there is between the deadline and where we are right now. And effectively, without getting really nerdy about it, as that time to the deadline creeps up, those notifications become more and more prevalent, and they will ultimately, I think, when it gets to the last hour, they will break through typical suppression things in the operating system to the point where it'll ultimately force you over the line. There are situations where it won't, but they're kind of edge-casey. So it's worth having a chat with you afterwards and anyone else who's interested. There are situations where it can go beyond the deadline, and for good reasons. So, for example, if I'm away on holiday and you've scheduled an update to my device and I close the lid of my machine and I walk away for two weeks and it's two weeks over the deadline, Apple does a really nice job of handling that as well. So the first time I open the device, it'll say, hey, you're overdue for an update. You've got 30 minutes to get stuff in order before we'll trigger that. So, yeah, I don't have any way to influence the user experience like in front of the user currently. But on the roadmap, there was maybe some suggestion of stuff that will come in further down the line. If that's something you're after, there's really great tools that are out there to be able to do things like that. And I would actually say that's probably why most of those tools exist is to handle the experience where Apple's process has gone beyond the deadline and we now wanna force people over the line. So Nudge is a prime example of that. It's a great tool, it's a community tool that allows you to customize getting people over the line if they've gone beyond it. So hopefully that gives you a good answer. Anyone else? Do you mean what you just said just now? Hi, sorry. You just mentioned there are community tools out there that might help you in something that you just mentioned as what might be down the line. I mean, in the end, I think this is a similar question as my previous speaker. It's the user experience and how, I mean, I don't know, also with your Apple colleagues, maybe you know about what is in the pipeline. The crucial thing about DDM is that there is only scheduled updates and nothing else. Is there anything else that was in other tools like, for example, we use Super, which is actually a really good thing because it nudges and nudges and nudges and you can deadline it. Apple don't seem to be doing that. Is there anything? I would say that in most cases, it sounds like I've been talking it down. Like I said earlier, I think it's like the best it's ever been. It is actually a really great process and it works like 99% of the time, but the time that doesn't work is the time where you're, there's an admin sat there going, why is it not working? And that's where a lot of the tools that exist, that's why they exist, like Nudge is a prime example, right? It's a user-facing experience that kind of picks up where that gray area is, where if they do fall into a pit where they haven't done it, it kind of pushes them over the line. In terms of, there is currently nothing in Upgrade Manager that allows you to be able to do anything like that, but I have plans in the future to be able to pair it and have like a user-facing experience, like an end user-facing experience to like do something similar. Not to denigrate Nudge, I think it's an incredible tool, but we use it internally at Jamf, and my personal view from like a UX perspective is that I'd much rather try and provide like a carrot on a stick rather than harassing people to get over the line. It's called Nudge because it, please upgrade now, upgrade now, upgrade now. You've got the DDM OS reminder, right? Sorry, you've got DDM OS reminder. Yeah, another great tool. Similar thing to Nudge. Yeah, 100%, another excellent tool. It ties into the Blueprint. Which, yeah, ties into the Blueprint you set up. So it's a little bit easier to manage that way, I suppose. Yeah, it's another excellent tool. I should have put it up on the Q&A, actually. It's a wonderful tool. I have 10 seconds. Does anybody have a 10-second question? I have a pocket full of devices that have the bootstrap on them broken, so the DDM updates don't work. Do you have a fix for that? So if you're interested to have a broader conversation, I expect, given that you asked the question, that you're very aware of how to fix those problems generally. But, oh, OK, cool. If you don't, that's fine. We'll have a chat. If any of you have bootstrap token questions, let's have a chat afterwards, because it's pretty esoteric. But it's a really great point to mention. Although I didn't show it, the application uses TipKit. And when you launch Upgrade Manager for the first time, it will talk to you about the syncing conditions. Like, hey, I showed you that all the stuff just shows up in the application. You don't need to do anything. One of the things that it does is, if you don't have bootstrap tokens escrowed for your device, in terms of the Mac, and for those of you that aren't aware what I'm talking about, to be able to achieve a fully silent automated software update, where when the deadline elapses, the user is just pushed through the process, rather than having to give their permission first, you need to have escrowed a bootstrap token from the device. Jamf does it for you automatically, but there are some edge cases where that doesn't happen. The app will tell you that those devices are not eligible. They are absolutely eligible in terms of the actual command itself. But in the spirit of me wanting to make this effortless and not require any documentation, you refresh it. If it doesn't have a bootstrap token, it doesn't show up. And that is not to say that it won't be like that in the future. But currently, it doesn't show up. However, you and I can have a conversation about fixing that. Thank you very much.
