Profiles vs. Declarations: Managing Apple Devices the DDM Way

folks. Welcome. Alright. For everyone just getting in now and settling in, my name is Mauricio, and I’ll be the solutions architect conducting today’s webinar. And today, we’re gonna be talking about profiles versus declarations. So if you’ve been with Addigy for a while, you may have noticed one of the features have changed as far as its name from MDM profiles to device settings. And within those device settings, you may have seen a keyword there called declaration. And we’re here to talk about, you know, some of those device settings. What does the declaration actually mean? What do those profiles mean, and what do they do? Where are they located on your machine? We’ll go ahead and talk about that through here. Okay? Again, if at any time there’s any questions due to the amount of folks that are in this audience, which, again, I’m very happy and grateful for, if anything comes up, just feel free to, drop it in the chat. We will have a q and a at the end. If anything comes up as I’m going along, feel free to just drop your question in the chat. We’ll be more than happy to answer and and help you out with whatever it is that you need. But before we get started, we have to understand what are these device settings and what do they actually do. Are these keys that Addigy just pulls out from thin air and just calls it a day and we can manage them on the machine? No. These keys are Apple defined keys. Right? Apple is who decides which keys can be managed. Apple defines the settings, the payloads, the declarations, and which operating system version supports which of those. Our job here at Addigy is basically providing you with the UI and the deployment workflow around what Apple has already built. Right? So that goes with these profiles. If you log in to your Addigy instance, you click on your policies. I have my little test policy here in alpha networks. I have my device settings. New. Several columns worth of profiles that I can deploy to my machine. Within these profiles, there are certain keys. Right? So for example, let’s see. Software update profile. Software update has certain keys that you then point to on the machine and manage that key, keyword being managed. As an example, I’ll just do software update MDM profile. First question that typically comes up here is why are there two checkboxes? Because the first checkbox is what’s going to determine if it’s a managed setting, meaning you, the admin, manages it. The second icon here or or checkbox here rather is whether or not you are gonna enable or disable that setting. K? So if you do not want to automatically install app updates, you would disable that. If you do not want to automatically check for updates, you would disable that or enable, again, case by case basis. Right? This really depends on what both you and the customer you’re managing are looking for. You’ll notice that MDM profiles have an installation priority because it’s based on when the profile lands on the machine. Whereas with declarations, it’s a bit different, and we’ll see that in a moment. So let me just go ahead and create this profile real quick. I’m gonna deploy this profile to my machine via my policy. Right? And like anything in my policy hierarchy, it is inherited. So I have a whole policy hierarchy here for my Alpha Networks company, Alpha Networks, engineering, sales, support. If I add my device settings up here, it is inherited, meaning I would then apply it to engineering, sales, or support. I can wait for the profile to land on the machine, or I can expedite this by clicking deploy now, which deploys my policy here. Where can I review if this profile has landed on the machine? Well, status for one, your deployment status. Right? In this case, it’s green, meaning good. You’re looking for four separate color codes. Green, good. Yellow, pending. You’ve pushed out the profile, but maybe the machine’s offline. Red, error. Maybe you’re doing something redundantly, like file vaulting a machine that’s already file vaulted, or perhaps the profile’s just you know, you’re you know, there’s just an error of some kind. And then you have blue, which is for compatibility. You’ll notice some profiles are only compatible with iOS. Some are strictly for mac most are for macOS, but you’ll have some that are also for iOS, right, which we’ll talk about this in a moment. But the key takeaway here is that you have device settings. What do they do? They enforce a managed setting on the machine, meaning you manage it. The end user can’t do much about that. And this is gonna apply whether you’re deploying a MDM profile or a declaration. So another place I can review if this profile made it to the machine is via device settings, installed device settings. And at the very bottom here, there’s my software update MDM profile. I can also review this in live terminal using a command called pseudo profiles list, which we’ll look at again in a moment, pseudo profiles list. Also, I can look in library preferences. There’s my software update p list. The MDM profile that I deployed is making an adjustment to this p list, and only I, the admin, can do something about that. My end user can’t make any changes locally because it is guaranteeing the state of whatever it is that I’m enforcing. Oops. So where do these profiles actually live? They’re not all entirely in library preferences. Right? Library preferences might show you the results of a setting, but the actual management state lives inside of macOS’ own profile system, which is that second bullet there, private VAR DB configuration profiles. This is not a directory intended for you to go in there and use a native utility like defaults read to look through a file and adjust settings and keys. K? It’s for the Mac OS system itself. K? Don’t just assume a setting is missing because you didn’t find it in library preferences. All settings should be available within that private VAR DB configuration profiles directory. Right? And, again, you can use pseudo profiles list. We’re gonna use this again when I deploy a declaration. Because when we deploy a declaration, you’re gonna notice that it has a fairly unique identifier compared to just the standard MDM profile. Right? You can actually run another command, after this, which I’ll again, I’ll show you in a bit, which dives a little bit deeper into each of these individual profiles here. So the anatomy of an MDM profile. An MDM profile, this is sort of the internals of it, and what we and this is for Chrome extensions. Right? And, basically, the internals of a profile, you have keys and you have values assigned to these keys. And, again, these are Apple defined keys. This is not something that Addigy just creates out of thin air. Right? What we do here at Addigy is we create and we send the profile. MacOS registers the profile as an installed configuration. It’s the profile itself that enforces the setting. Right? This is the profile itself that enforces the setting. When you remove the profile, you essentially remove the instructions. Management, Addigy tells the Mac just install this profile. I see a question in the chat here. If we’re using DDM and policies updates, do we also need to set up the device manage no. So I’ll finish the question. Is talking about or do those devices profiles just an extra level of control if desired? Will DDM work without the device yes. It will. And what you’re referring to, Steven, great question, is our previous webinar, we spoke about DDM as an update mechanism. Right? And it’s, again, asynchronous. You set the instructions. It creates a file. You call it a day. You do not need any device settings profile associated with this. Right? All you need is just setting this up here. The analogy I used previously was it’s like an Amazon delivery. Right? You have two types of deliveries. With MDM, you have to be home at the time of the delivery, aka you have to be at the machine at the time of delivery. Whereas with DDM, it sends the instructions to the machine, and it expects the machine to maintain that state. So this is how we up this is DDM as an update mechanism. From device settings, it’s DDM as far as declaring settings. The the idea or the concept of setting declaration is is still managing and enforce excuse me, enforcing a managed setting. So to summarize everything I just said, the DDM update mechanism doesn’t have anything to do with this, number one. Number two, when you deploy these, regardless of if it’s a declare declaration or a pro or an MDM profile, it will enforce a managed setting. Okay? Now this is not needed to be treated as urgent. You don’t have to go in here and go, oh my god. I gotta go and start migrating to to recommended right now. It’s not necessarily urgent. It’s just something to be cognizant of. Right? So let’s see here. Brent Porter. Currently, if you are using version control in DDM and you want to control some of the update settings, you will need MDM profiles configured. And by MDM profiles, again, Brent meant it means device settings. If you use to keep to the latest, you can replace those settings. Right? And I’ll leave that there. I’ll copy and paste that for you guys in the chat. I think he’s in the chat. Alright. Cool. Okay. So a declaration is more of like a it’s first off, the main difference is that it’s exchanged as JSON. So instead of install this file, it’s more like, hey. Define the state that macOS should maintain. So with legacy profiles, it was install this profile. With a declaration, it’s maintain this state. But the work the idea is still the same of it enforcing a setting. Okay? What does that mean, or what profile might this actually apply to? Well, there’s actually a profile in Addigy right now that has both a legacy and a recommended version, and we’ll take a look at that aft I think after this slide here. But, again, the key distinction between the two is that an MDM profile is more server driven. Hey. Install this configuration profile now. If something does change, the MDM server generally has to send another command to replace or update the profile or potentially even remove it. DDM declaration, Addigy tells the Mac, hey. This is the state I want you to maintain. The Mac evaluates the declaration and applies it when it’s appropriate, maintains that state, and reports status back to MDM. And this is just sort of a summary because there are gonna be some profiles that you decide to deploy in device settings and go, well, which one am I gonna use? Recommended, legacy? Which one is which? What what happens? Well, what’s a profile for us to take a look at here? What are some profiles we can reconsider? The first one will be a passcode profile. You see, if I go back into my Addigy instance, I have some of my profiles here have the word new next to it, meaning that we have a declaration available for that setting. Passcode being one of them. Passcode legacy and passcode recommended. Now if you’re still pushing a legacy profile, that’s okay. It’s not like it’s gonna, you know, Thanos snap out of the machine and it just gets deleted. It’ll still be there. In fact, with password profiles, what should we consider? So I’m gonna call this here passcode legacy DDM webinar profile. And I’ll just select a few settings here. Minimum password length, and then I’ll create a profile. Notice under legacy, there’s still an installation priority involved because the installation priority is tied to the the profile being deployed to the machine and not a setting that we’re configuring. So if I click create profile, I’ll create that profile, and I’ll deploy it into my my policy. Now I can wait thirty minutes for my policy here to run, or if I’m feeling impatient, I’ll click deploy now, which should update my policy settings, right, or rather update the instructions I’m sending to the machine. If I go into again, I could look at the deployment status or I can go into devices, go live, and confirm via device settings that my passcode is here. You could confirm with pseudo profiles list, but it’s gonna be a bit of a generic sort of output. When we look at pseudo profiles list, I don’t think it highlights passcode nor does it highlight, that it’s DDM or declarative. Right? So what happens if I currently have a legacy profile and I want to use the recommended version? Well, best practice would essentially be, first, obviously, is always test. Right? We wanna isolate a machine, preferably in, an isolated test policy. Apply throw a VM in there just so we can observe the behavior. But in this machine here, we have a legacy password profile. Let me go into my policy again. So policies, alpha networks, device settings, new, passcode, recommended. Few things you’ll notice. First off, the banner. This is gonna be more for, current OS, which is twenty six, and any operating system moving forward, twenty seven, twenty eight, whatever the next ones coming up in the following couple years. You’ll also notice no installation priority, and that’s because we’re not necessarily deploying a like, dot mobile config. We’re deploying a declaration to the machine. K? DDM doesn’t use a priority order because you’re not telling the Mac, hey. Apply this first and then that. You’re telling the Mac you’re telling the machine or whether it could be the macOS or iOS machine, this is my desired end state, and the machine works towards that end state. Okay? However, for passcodes, I’m gonna call this here passcode recommended, you know, webinar profile. I’ll select a couple options here. Keep in mind, with passcodes, I’ll create a declaration. I’ll go ahead and add the declaration. I have two password profiles applied to the machine. Did I just break the machine? No. Two password profiles can exist on the machine. But the rule of thumb is, right, the, the DDM, the declaration should take priority. If you’re deploying a declaration versus legacy, declaration typically takes priority. However, when it comes to, conflicts, let’s say the legacy profile is slightly more restrictive than the recommended profile, guess what? The legacy profile is still the one that’s gonna be enforced. K? So just because you deployed a passcode declaration over a passcode legacy profile doesn’t guarantee that it’s gonna take the declaration first. It’s gonna take whichever of those passcode profiles are the most restrictive. And now notice, after deploying the declaration and I run pseudo profiles list, I have this attribute here with, it looks kind of different from what the other options that we see here. Right? We see some other options here, but none of them look similar to this profile identifier that I just deployed for a passcode migration or, excuse me, for a passcode declaration. So, again, best practice, you could deploy the the if if you plan on using it as a declaration as, again, that’s what we’ll be moving forward with new operating systems, then you can have both on the machine at the same time. Just go into the policy. Once you’ve confirmed that the the declarative passcode has has deployed, you can confirm on the machine as well. Once that’s been confirmed, you just go into your device settings and remove the legacy profile. Now there is a poll in the chat there. Feel free to answer that question. Again, this is not necessarily urgent. If you’re still deploying the legacy, passcode profile, again, your machine isn’t gonna blow up or anything like that. You’ll be fine. It’s just we’re gonna start being cognizant as some profiles are now gonna be recommended to move into declarations. So if you’re still in legacy, that’s okay. But, again, as the name implies, we recommend moving to the more recommended settings. Okay? And those identifiers that we saw in pseudo profiles list, that’s what makes those DDM declarations unique. K? It’s those particular identifiers. When were these passcode added? It’s been it’s been a while. I don’t have a specific time frame. I could check here in the back real quick to see with in the background here with real quick to see when we actually released the declaration. This has been around for a few months now. Not a I don’t think it’s been a year, but about a few months now that we’ve had recommend probably even a year, I don’t know, that we’ve had recommended. It’s been a minute. I I I’ll check I could check here on the back end if maybe Dan or he wants to let me know the specific date. I don’t remember the specific dates that this released, but it’s here. Okay? It’s here. And, again, I highlight this because with passcodes, it’s okay to have both profiles on that machine. VPN, however, not the same thing. Right? So if you look back on your policies, device settings, new, like I mentioned, you’ll see a lot of profiles here with, like, a new tab next to it. Passcode being one of them. VPN is another one as well. VPN settings legacy, and then you have some other options as well. But keep in mind, the main difference here, at least when it comes to VPN profiles. Right? The idea of stricter wins applies for passcode. VPN doesn’t really work the same way. You use one or the other. You’re not using both. Okay? You’re not using both when it comes to, the the VPN declaration. K? So when you’re migrating to a DDM, like, VPN declaration, why would you use it for? Always on VPN, and you have some additional options here as well. You’re only mainly, you use the legacy profiles as the name implies legacy for older OSs. Right? So older operating systems, perhaps, you know, fourteen, maybe fifteen, if they’re still using legacy VPN. Hell, even if the macOS twenty six is still receiving legacy, it’s still okay. But moving forward, start to be aware that you’re gonna need to use the recommended version. And VPN, unlike passcodes, you can’t have both. You could have both on the machine, but it will cause some kind of conflict. Right? Whereas with passcodes, it’s strictly gonna apply whichever is most strict. VPNs, there’s no need to deploy two separate profiles. You you deploy a profile, then you remove the other one that or excuse me. You remove the one you’re currently using. Once you’re ready, then you go ahead and apply the declaration. Okay? One second here. Okay. Alright. Sorry. Just looking at see the q and a here. Alright. Yep. So the thing about VPN profiles, again, just keep in mind, when you push different VPNs, that’s fine. Right? It’s when you have the same profile deployed in that same policy level where there may cause some issues. Apple doesn’t provide a clear conflict of what happens when you have both profiles on the machine. Okay? But there typically, there may be some kind of potential connectivity issues involved when it comes to at least VPN. Okay? Those are your two main profiles out of all of these that have a, recommended versus legacy. Some of these are just brand new entirely, and we’ll take a look at those in a moment. Before we do, Appleseed versus stable. So maybe there’s a profile you’re interested in. Perhaps you’re using platform SSO, the extensible SSO profile. You’ll notice that extensible SSO now has option and stable. Appleseed is primarily for beta testing. Okay? Appleseed is for beta testing. It’s not really for your production machines. Right? You need, Apple seed for IT enrollment. There’s, like, an agreement that you have to sign, and I believe you also do need Apple Business in order to use this. So not gonna be available for everyone and, again, not used for, like, your day to day management. This is just used for you testing on, you know, what’s to come, basically. Right? Appleseed is basically allowing you to test what’s potentially next. And what you can do, as we always recommend, create a separate, test policy. If I go into policies new and just have an isolated policy for testing. Testing. And in here is where you can, potentially have some Appleseed device settings deployed so that you ensure that you’re only touching a controlled set of machines versus your entire, you know, fleet of machines. K? Back to device settings. Again, there are some profiles that are entirely new. Safari settings for configuring things like Safari extensions. Notice at the top, the tab. Right? This is what’s gonna be needed moving forward. Experimental options, Appleseed, beta testing. Another profile that folks have asked questions about that sounds kinda similar is passkey attestation. Right? Passkey attestation is one of the newer profile options. And, basically, a passkey verifies the user. Passkey attestation verifies the device that it came from. It basically proves that a passkey was created on a trusted Apple device. You, the admin, specify in the profile what, parties are allowed to receive attestation. In other words, which URLs when the when the user accesses it, will both the user and their machine be verified and authenticated? That is passkey attestation. Sounds kind of similar to passcode, but it is different because a passcode is gonna control what the password looks like. Passkey attestation is proving where it came from, right, or rather what device it came from. So although it sounds kinda similar, the word passes in each, they do operate pretty differently. So just something to keep in mind with one of the newer profiles there. Yes. And as Iggy mentioned, Apple c test early and test often. With macOS GoldenGate on the horizon, we should be looking at some test groups with those Apple c keys. Exactly. So one way that you could test, again, a flex policy. Inside of your testing flex policy, add a filter for the macOS version that the only versions that you wanna test on. Maybe you already have some machines on GoldenGate. So or VMs rather on GoldenGate, right, for just, you know, testing purposes. You can go in here, set the macOS version to equals twenty seven point zero. And then in here, I don’t think we have any oops. I don’t think we have anything regarding Appleseed. Right? But in here, you could point specifically to your machines, and then from there, apply your testing. K? One thing I forgot to share, if I go into my devices page, I used Addigy Device AI to create a very simple script. This is not a scripting webinar. This is just to show you what you can do with scripts. But perhaps for folks that are potentially migrating from passwords to from legacy password profiles to recommended password profiles. There’s, again, just something you can you can potentially come up with, a passcode enforcement source, which it’ll essentially review that pseudo profiles list, and it’ll it’ll tell us if the machine is enforcing a declaration or a legacy profile. And, again, this is I can’t copy and paste this into the chat. I think it’s too big of a script. I used our AI settings here to do it. It’s nothing fancy schmancy. I’m sure there are better, more efficient things out there. This is just to show you what you can do knowing this information. Right? So if I hit passcode enforcement source, I hit send, run script script, history, and I can review it here. My enforcement source for my passcode is gonna be my DDM declaration. If it was my if it was my legacy profile, that is what the output would have been, legacy profile. So just another way of identifying which machines might need to migrate to these my to these, recommended profiles. Create a custom fact using a script that tells you, you know, is is that DDM profile on the machine? Is the legacy profile on the machine? Which profile’s on the machine? See, I’m actually getting two outputs here, so it’s not the best script to use. Again, the idea wasn’t to script. The idea is just to show you what you can do with the information that you know here. So you can, again, you can use a script to see if it’s a legacy profile versus a declaration, and then from there, determine if you wanna move into the declaration or not. Again, another new profile that we have appeared. Right? So policies, alpha networks, device settings, new. We have two types of profiles for intelligence. Right? Apple intelligence. We have external intelligence. We have intelligence settings. External intelligence is, again, a declaration. I’ll just type this external intelligence webinar declaration. And, again, why are there two? Just like the MDM profiles, one makes the first checkbox makes it managed. Second checkbox is if you want it disabled or enabled. In this case, I want it disabled. So I’ll create the declaration. And, again, external intelligence determines whether Apple intelligence can reach outside. Can Apple intelligence connect outside of Apple? Hence, the name external intelligence. Let me go ahead and deploy that, and we’ll see what it looks like here in a moment. Let me deploy external intelligence. New. Think of intelligence settings as, like, internal intelligence. Which Apple intelligence features can users actually use? Things like writing tools, Genmoji, image playground, visual intelligence. So this is, like, internally, what can the user access? So I’ll type intelligence settings, webinar declaration. And I’ll go ahead and select I’ll let the I’ll disable most of these items here. K? And, again, remember, no installation priority because we are telling the machine the state we want it in, not deploying a file, so to speak. Right? So if I deploy now, I have external intelligence and intelligence, which, again, are both intelligence related. One is tied to, can Apple intelligence connect outside of Apple? The other one is tied to internally. Right? What the users can actually make adjustments to. Not having done reading one of the chats here. Not having ever done any of this. All good. When would not when would not make a declaration manageable? So, again, the declaration is it’s you’re still managing the setting, and it’s not something that you necessarily have to get taken care of immediately. It’s just something to start preparing for as newer operating systems release, and you’re gonna start probably noticing new more of this new tab here on some of these profiles. Right? And, again, it starts with the passcode profile. We have a legacy and recommended. You may start to see this across other profiles as well. So the key to take away from that is start preparing to move into more recommended forms of management of these settings versus deploying an MDM profile. That’s the main takeaway there. K? So summarizing what we covered today. K? Device settings currently have two options available. MDM profiles, like security and privacy, software updates. Right? System extensions, Wi Fi. Those currently, if you’re if you’re using them, you’re fine. They’re not gonna get removed from your machine. They’re there, and they are enforcing a managed setting. K? The other type of profile now you have is called a declaration. New settings, like math notes, Safari. PPPC currently stays the same. Nothing has changed as far as with PPPC as of yet, potentially in the future. I’m only highlighting the ones that we currently have a new tab on. And when you click on that new the ones that have a new tab, you’re either gonna see recommended versus legacy or Appleseed and stable. And to be honest, I think that’s on Apple. I’m not sure when maybe my product team can answer this better when these settings are gonna be moved to DDM. I don’t have a dates on when settings are gonna be moved. It’s just be aware of it. Maybe whenever you tend to log in to your environment, you know, go into device settings and just confirm. Oh, look. Looks like Wi Fi has a new profile. Just prepare and start, just, again, just to to just to be aware of that this is what this is what you’ll see, next time you log in. Right? You might see a new security and privacy profile. I don’t have a date for when that’ll happen. This is based on, again, from the very first slide. Apple defines this. We don’t just come up with this from thin air. Apple has to define it first, and then we make a profile available for you. K? Again, in summary, you have new profiles that are available. Lean toward using the recommended version of the profile if possible. If you have legacy still, it’s okay. It’s not urgent. Just something to be aware of. Apple seed, be careful with Apple seed. Really good to have for testing, but that’s exactly what it should be for, testing and not for our actual day to day devices that we’re managing. Okay? These are all still enforcing managed settings on the machine. If I go back into live terminal I’m gonna clear this out, and I’m just gonna do pseudo profiles list one more time. And you’ll notice there’s some profiles that look different from the others. These are our declarations. The identifiers look slightly more different than the other ones. So this is one way of determining if a profile is potentially their declaration or not is through these identifiers here, which, again, look vastly different from the other profiles. K? So, again, why does this matter? The same settings are there. The same workflow is there. Just be aware that there’s a new method of delivering these device settings, and that’s gonna be through DDM. Should we start start to consider it? There is no hard deadline, and it’s okay if you missed a few if you missed the first couple minutes, this will be in the academy later, so no worries. There isn’t, like, a deadline. We’re not just gonna, you know, start removing profiles, you know, from you ***** nilly. Right? As Brent has put here, Apple has been warning some of these profiles being deprecated since the last WWDC if you run a report from the Mac evaluation till the unmanaged device. So Brett recommends running that app. It helps you find out what is being reported on everything you’re managing on systems. Thanks for sharing that, Brett. That’s what this is all about too. I’m just presenting. I’m nobody superior. Feel free to share anything that you like. Okay? But, again, they could exist. Legacy profiles and DDM as we saw with passwords. Just because you have two doesn’t mean that the machine broke or passwords broke. In the case of passwords, you the most restrictive setting wins. Right? So if it’s DDM, then DDM wins. If legacy happens to be more restrictive, it’ll continue to be enforced until you remove it from the machine. So keep in mind when these, migrations start to happen, when you start to notice new profiles, like a new Wi Fi, for example, or new, security and privacy or perhaps a new restrictions releases, the migration would not be automatic. You’ll have to go in there and actually deploy the profile yourself. Not every setting has a DDM equivalent. And, of course, most importantly, test on the OS before you actually deploy. So have a separate isolated test policy. Do whatever you want in there. Deploy all the declarations and all the profiles in there before you then move into, deploying it to your actual day to day prod machines. Key takeaway, move to DDM gradually and intentionally. Again, not urgent. Doesn’t have to be done immediately after this call. Just start to get you know, just start to look in that profile section and start to see, this pro I’m actually currently deploying passwords, and there’s a new version. Let me deploy the new one. Right? And then lastly, there’s one more poll question regarding Addigy Boost. So within Addigy Boost, if you decide to you know, if you enjoyed today’s training and the DDM webinar we did previously, if you sign up for Addigy Boost, basically, just clicking yes is gonna automate someone to contact you, and they’ll offer you the following. Basically, training credits. You get two training credits per year. You get proactive monitoring, health insights, guided remediation, and staying certified. So earlier in the call, I introduced both Dan and Iggy. If you sign up for Boost and you have, like like, let’s say, Boost onboarding or Boost meeting, chances are you’ll have a more, you know, one on one session with either, again, Daniel, Alan, or Ignacio. And if you’ve worked with them before, you know just how fantastic they are. They’re very helpful with whatever questions that you have. So if you are interested, please just select the yes option as that should kick off an automation. If not, no worries. I still hope that you walked away learning a thing or two. I hope that you walked away going, okay. Now I have an idea of what, you know, declarations are versus device settings. What we’ll do now is, I guess, this essentially ends the webinar, but I wanna have some time for q and a. So if you have any questions in the chat, feel free to let me know, and I’ll try my best to help. Otherwise, if you are good, I hope you enjoy the rest of your day. K? Remember, if you missed the first, like, couple minutes, this will be available for us in Addigy Academy so you can review it with your team later if you’re interested. Alright? Thank you so much, everyone. And if you already signed up, all good. It’s all love. Really appreciate everybody’s time. I’ll hang back, see if there’s any questions. Look forward to the next one as we’ll be start we’ll do this more continuously. So if you receive value, if you learned, let me know, and we’ll continue more. We’ll keep doing more. Yeah. If you like more, let’s do more. Thank you all so much. I’ll hang back here and answer any questions. Can I access this video with Academy, a free account? Yes. Yes. You can, Jacob. You should even free accounts should access it. Expect it sometime later today. I have to send it to send it to, like, my I think my marketing team. Gotta make it look nice. You know the drill. Today, we use Intune to automatically hand out computer and user search to Windows machines. Okay. It looks like Iggy answered that question. Yes. We do deploy deploy we do support deploying certificates and the certificate payloads. That is correct. I really appreciate y’all so much. You so much. Again, I’ll hang back. Give it another couple minutes. If you’re good, drop and enjoy the rest of your the rest of your Thursday. Again, expect another one. I really appreciate you guys. Thanks for giving me an opportunity to spend some time here and talk to you during your lunch. Any guidance or resources on creating Apple VMs for testing? Yeah. A matter of fact, if you’re on Apple Silicon right now, Justin Justin, which I love the double name there. My nephew’s name is Justin. I’m gonna start calling him that now, Justin Justin. One of the resources I use is free. It is, VirtualBuddy. If you’re on Apple Silicon, the the free resource I like to typically recommend folks is VirtualBuddy. I’ll paste this in the chat. I highly recommend, you know, if again, if you are on Apple Silicon, use VirtualBuddy. Create a separate test policy. Add your VirtualBuddy in there, excuse me, your VM in there and do whatever you like. Break it, blow it up, and then just remove it, and then create another one. But check feel free to check out VirtualBuddy. It’s entirely free. The caveat is you do need to be on Apple Silicon. See what else we got here. Yeah. Give it a shot, Justin. Give give that I pasted the, link in the chat for anyone interested in VirtualBuddy. It’s the tool we typically recommend in our training and it just in general. Primary reason is because it is free ninety nine, the best price imaginable. Is there an easy way to tell? I think if you go into device settings, the best easiest way to tell is if you deploy a device settings profile or any profile for that matter and and you go to its go live page, device settings, they will be, oh, actually, this is the name I gave it. So there isn’t really an easy way to tell. I think you could use, like, pseudo profiles list. There’s another command that you could also use alongside this that, like, dives a little bit deeper into pseudo profiles. And I think in there, it might give us a an idea of what’s declaration or not. I think it is, if I have it in my documents here, pseudo profiles show type configurations. Let me paste this in the chat. That command that I pasted in the chat should give you a little bit of a deeper look into each of those lines. And I think I don’t believe it shows that it’s specifically a declaration or not. So the one way to tell is just that that that ID here. So if I do pseudo profiles list, one way you could tell is through this. You could maybe use a script to identify this particular profile. And if it you know, if not on the machine, then deploy. I mean, there’s so much you can do. There’s so much you could do. The easiest way, I think again, I I would say just labeling them yourself on the profile and then maybe using some claw magic to see, you know, how to identify one from the other. Alright, folks. I’ll give it another minute or so for more questions. If there’s no other questions, guys, I really, really appreciate your time. But, again, I’ll be hanging back here and seeing if you have anything. Join us for our next one. We’ll be doing more of these. We’re gonna alright. Alright. I don’t see any questions popping up, folks. We’re gonna wrap up here. I really truly appreciate everybody’s time. Thank you so much. And, again, expect this in Academy and reach out to me at Mauricio at Addigy in case you have any questions or training at Addigy in case there are any other additional follow-up questions. I’m more than happy to help you. Thank you guys so much. Appreciate y’all so much. Thank you. And thanks to Eddie and Anna as well for hanging out here.