Transcript
It's a new year and I hope that the first few days have been kind to you. So last year was my first year getting to do this. The automate it podcast or the automate it podcast. But it was also my first year being a solutions consultant at automox and I really learned a lot in this new role. But one of the things that I've been able to learn more closely is the value that it brings to others. So normally I like to use this podcast to talk about things that are important to me that are not centered around it. We're not specifically centered on automox and patch management, but more so like my experience around it. The topic I want to talk about today is much more closely related to the topics of it and patch management. But the theme that I'm trying to bring on is I want to just kind of talk about why I think automark can help you reduce really burnout. That's really what I'm trying to prevent. That's one of my resolutions for the new year is to try to focus on what I can do for myself and my time at work, my professional time. What I can do to really limit like just cognitive burnout. And this way when I'm away from work, I don't have to spend too much time just constantly thinking and dwelling my thoughts on patching patch management. I'm really centered around what I've noticed, some things others can do to kind of really just put their best foot forward and make sure that they're not spending too much time on things that they can automate around automox. The question that I wanted to pose is what if the biggest time-saving changes that we can make do not come from big strategic projects, but instead they just come from eliminating small repetitive tasks that often consume hours if you're having to repeat them monthly or weekly sometimes. So a lot of the times when I get to speak to automox users or other IT admins, there's a lot of things that we have to keep track of when it comes to patching. This comes to release cycles. This can also include spontaneous ad hoc issues that require unexpected updates, approving new patches or having to prepare devices for rollout, maintenance windows. And then of course there's the verification process of validating, did your desired changes come to fruition? I get to meet with a lot of admins and engineers who have to do certain processes manually. And even to their own admittance, they would prefer to automate everything that they possibly can. Normally sticking to manual procedures might just happen because there's like an extremely tight patch window or just highly critical devices that only require like a selective group of updates. I still want to see if I can make suggestions for ways that I've seen automox save teams time and a lot of that extra manual burden. So just one thing to consider whenever a new device joins the fleet, there's usually a scramble to make sure that it's ready to patch. It's ready to configure and it's ready for the user to actually begin working. So most teams spend a surprising amount of time getting that one device into a healthy state, checking for required software, loading configurations, making sure it complies with like internal standards. And normally these changes have to be done before IT is ready to provide that machine to their teammate. And if you're supporting remote workers that just, that work doubles because you're prepping a device that's probably not going to come back to the hands of the desktop admin or the IT admin for a matter of months. What if you didn't have to preload everything manually? What if the moment the device comes online, it tells you exactly what it is, exactly what it's missing, and you can automatically close the gap. And I know that you can make the argument that automox worklets are the same as any remote script executor, but that does not make them any less powerful. Automox has policy types that are known as worklets and required software policies. And both of those can push out MSI or EXE installers as well as for macOS like PKG installers, for example. And these can add software that the user needs right away. And with required software, you would set parameters so you could issue like a product key immediately upon installation. Or if something requires more verbose configurations, you have worklets at your disposal that you can deploy your own custom script. Once the device is online and scanned with automox, you can enforce configurations. You could remove outdated software with worklets, or you can just set up your baseline just by assigning these automations outright to certain groups. The point is that enrollment doesn't have to be a big production anymore. You don't have to build a perfect image for every possible use case, or for example, rush through a checklist to get a device out the door. Automation can handle the routine setup, and then you just get your time back. That's fewer repetitive steps. That's fewer late nights of prepping machines and far less pressure on the team when hiring ramps up for hardware refreshes to roll in. Another thing I spend a lot of time on talking with automox admins is for those that are still getting started with their patching policies and establishing patching procedures, they might not be aware that we have best practice templates that we can recommend. If you're noticing, did he stop? Yes, I did. It's because I don't like the way my hair looks right now. I'm going to get this taken care of. I also, this digital background, courtesy of Mac OS, I do not live in a cream colored or peach colored room, I kind of do. But this is just a fake background because I'm going to try to change the angle of this a little bit more. Maybe I can showcase more of my personal belongings in the background, make this a little bit more personal. But with that being said, back to the main topic, a lot of might not be aware of some of the best practice policy templates that we have for those that are still getting started with automox and still wanting to, maybe you haven't established a plan or a schedule in mind for enrolling patches or sorry, getting patching policies enrolled in your devices. But we have best practice policy templates and a lot of these can be used out of the gate. They already have preset package targets that include Mac or windows as the, as the vendor for the policy. So as it stands, you can immediately ensure your devices are up to date with Mac OS or windows updates. And one benefit as well is that all of our policy templates use the advanced policy type. And this is normally what I would recommend. But one of the biggest benefits is that there's a list of attributes you can set for the patches you want to push to your devices. So one comment I've received very much last year was that some teams will have a pilot group of devices that install certain patches on day one of release. And some teams were not aware that with automox, you can actually have the pilot group and the remaining devices target the same patches, but you would just use a different filter for how old the patches we refer to this as the patch age. But this way your it team can still test the latest window releases. And then without making any policy changes, they can wait a certain number of days for the remainder of those windows devices to receive said patches. Another topic I like to bring up is that you can now schedule your patches specifically around patch Tuesday. So yes, you can set the requirement to have the patch age filter. But if you were more so concerned that you wanted everything to be patched two days after patch Tuesday or three days after patch Tuesday, that is an option to you. Because I have seen some environments where they were manually adjust their policy, look at the calendar, and then pick a day that they're comfortable with based on when patch Tuesday falls in that month. Ideally, once you have an established patch schedule workflow, what I want to suggest is that you can take advantage of some of the filters when setting up a policy that your team or your automox admins are not having to go in and adjust policies this regularly. In my own opinion, I would think that if you have a, for example, a windows patch policy that's going to try to include everything that is at least seven days old, or maybe 10 days old, you can set the attributes to whatever you'd like. But ideally, you're not going to go in and touch this policy again unless absolutely necessary or some testing gets done and you realize you need to exclude certain things. But really, I would advise that once you have a policy schedule that you are content with, like for example, you want to run first party updates once per week, I think that's a little bit more reasonable and a little bit more expected. Automated patching removes a lot of pressure that leads to burnout. When you're not manually pushing policies every month or watching devices closely on patching release day, you get time back. One of the worst things to hear for me is that somebody has to babysit their devices on patch day. Yes, I do agree that uptime matters, but most admins agree that their time is better spent improving the environment and not waiting around on a progress bar. On the topic of, you know, trying to stop Automox admins from feeling that they need to babysit some of their devices on policy day or anything like that, I also like to advise two sections that you can kind of keep an eye on that makes things a little bit easier for yourself. So I think that some Automox admins feel the need to babysit their devices because they're not certain the best way to track down patching failures. I have two suggestions. So I want to start with the policy results report. If you were in your Automox console, you can click on insights and then reports and it would be there. If you were to click on this report, it immediately opens up to display a bunch of bars and line bars specifically. And each bar represents a date and a time for a policy running. And the bar is color coordinated, separated to device, whether they successfully patched or not, not applicable, et cetera. But if you click on a certain part of that bar, so for example, for devices where that policy failed, if you click the red portion of the bar, it takes you to an already filtered and itemized list of devices where that patch failed. For each item, you can click on the far right to see the full logs of standard error and standard output of why that patch failed on that device. The unfortunate truth is even if you were babysitting a patch run, those devices unfortunately would have failed either way. So one benefit about using this report too, is if you have a selection of devices that failed, you can also run the policy again using the little task button, selecting the actions, and then there's a task item to run the policy again. After you've gone in and remediated any potential issues, this just makes it easy to try to push those patches out again. Another item that I wanted to mention is if you also click on the insights and go to analytics, you can go to the live board for patch impact and performance. And once you're there, there's an additional tab for patching performance. And on that tab, the first widget is for patch policy success. You can hover your mouse over where it says fail, and then right click, and you get the option to drill down. You can then select the policy name as a filter here, and then it will show you a list of the, not a list, but it will change the graph to show all of the policy failures in the last 90 days, and it will show you which policy has the highest volume of failures. So this report doesn't actually show like standard output and standard error of why the policy failed, but at least you can track down what is the biggest policy failure or biggest point of failure, I should say. And then you could take that policy name back to the policy results report. And from there, you can apply a filter on the left-hand side to look at that policy specifically and see from there which devices is a failing the most on and get more information for troubleshooting. So as always, I feel like this session here is mostly just me rambling, but I think that there are so many ways you can use AutoMock to save your time and cognitive burden, either for yourself or for your team. Like I said, one of my New Year's resolutions is to do what I can to avoid burnout at work and then giving myself more energy to use my time away from work, to focus on things that I really love, like being with my family, reading books and playing guitar. So please don't get me wrong. I love my job, but I don't want to spend every waking moment thinking about patching. And I'm sure a lot of people can agree with me on that. So I'm going to go ahead and wrap this up. But as my consistent reminder, please be kind to yourself at work and at home, have a happy New Year, and I will speak to you again soon. Take care.
