What advice do you have for others considering Automox?

This is a cloud-based version that updates by itself automatically. I'd recommend the solution to others. I would rate the solution seven out of ten overall. It's good for endpoints. However, it's not as good on the server end. There is overhead for you when you deploy on the server.

It is a flexible solution that does a majority of the tasks. The only thing it really doesn't do is Mac, which is something that Jamf Pro does, but it is not necessary. I would rate it a nine out of 10.

I would advise others to just try it. The demo is free. There is no risk. They don't ask for any information. You can just install the clients on some of your endpoints, and you'll be able to see very quickly that Automox works. Given the pricing, it is just a no-brainer to go with. The biggest lesson that I have learned from using Automox is that there is actually a patch manager that works. We had started to doubt that there was anything out there. I would rate Automox a 10 out of 10. It has been a very pleasant experience.

If I've installed the solution, I do not have complete visibility, but I definitely know the endpoint is there or if it's missing patches or any configurations that I custom make. The free trial of Automox was really important in our decision to go with it so that we could know how it really works. It's one thing to read a review or have them tell you how great their product is. It's another to see it working in real-time and especially working in one environment with all the different pieces they might have that could potentially make it harder to work. The trial is important for that consideration. My advice to anybody considering Automox would be to think about potentially investing in the API ahead of time because if I was to do it all over again, I think I would put source control around anything getting pushed into Automox, and I would probably set it up to where I would use the API to create policy. I'd use the API to push the code that sits in that policy. I think everything would be pushed through source control that way versus using the web console to log in and push all that. Every time you go in and make a change, there's really no history there. The only thing I would change about the implementation is to focus a little bit more on how to manage it over time and make some modifications to it. I would rate Automox a ten out of ten.

I recently asked my team about which areas of the product have room for improvement and for the moment we don't have any complaints, something I find anomalous. When I hear that from my techs and engineers, it’s always a great thing. We're not heavy into the Worklets yet, so those may have room for improvement, as they are something new for Automox and for us. But overall, when it comes to patch management, the dashboard, ease of use, and the ease with which data is digested, have been great for us. We're not trying to push what Automox is for. We use it for patch management as its key task and it's been fantastic for that. There have been no complaints by us so far. Our staff who access it include systems administrators and systems engineers. Across our organization, we have around ten people who access it at least once per month. There is not a lot that needs to go into this. I haven't really had to do much work with it altogether during the past year or two. We really only need one or two guys in here, depending on whether Microsoft or, perhaps, Ubuntu drops a large patch. The amount of manual labor required of an employee is very limited, which is nice. The biggest lesson that we have learned from using Automox is that as a managed service provider, it gives us a lot of insights into what our customers want. There are many customers who come in and state that they want everything patched up and up to date. Then, there are those who are the complete opposite. Most of our customers fall somewhere in the middle. Many of them do not have a proper understanding of why things need to be patched. But this has been very interesting because once we went live, we started getting feedback from our customers and this gave us insight into other areas that our customers consider to be important. The cloud-native aspect of the solution was not very important to us. We considered it to be a "take it or leave it" feature. Retrospectively, it is a great feature to have. It saves us from worrying about the servers or about updating Automox. So it does, in retrospect, make a lot of sense to go cloud native because we don't have to worry about it. We have had no issues, no downtime issues with Automox. There are no complaints in that regard. While being cloud native was not a key feature at the time, looking back it’s pretty nice not to have to worry about it. The solution provides us all the visibility we need, although we do not actually manage laptops. We only deal with what's inside data center walls. We actually use it for our employees’ desktops and then on the server side. It gives us complete visibility. While we don't have any macOS on here, the patch management definitely covers Windows, Linux, and even Unix. We love the overall patch management abilities. It's the main driver of why we adopted Automox, and it has definitely stood up to the test of time. It is absolutely important to us that it provides a cross-platform patch management across Windows and Linux endpoints. This was one of the driving factors and among the decision-making criteria for us. We already had two different patch management systems in the past, one of which could only handle Windows, the other only Linux. We were looking to try to unify that. It was such a pain since we were forced to bounce from one to the other. One of our older solutions capped out on how old an OS could be, since we have some customers who simply cannot move an application off an older OS. With Automox, the gamut is covered. That's what we want, that single pane of glass for patch management. For the moment, we do not use the product for automation of patching. While it is definitely in our R&D pipeline to adapt it, we do not yet have it automated. They have the playbooks and they seemed very interesting to me. I'm just waiting for some R&D time on our side so that it may be integrated. My people have been using Automox's Worklets for simpler tasks or those that are not overly complex. We're waiting to get these into our cloud portal. For the moment, we are making some use of them. We feel it is pretty important that Worklets enables us to enforce tasks across any managed endpoints. Especially in light of some of the vulnerabilities over the past two years, we want to enforce that our customers update. While we do not force updates, we want to make certain that the updates are covered and are applied in a reasonable amount of time. There are some delays with clients. Consequently, this capability of follow up and notification, should it still be waiting, is very important to us. We’re using some of the Worklets from the community, which is really nice. One of them involves getting Windows Update events, and that is great because it's part of troubleshooting. I've never had a complaint with Automox's speed. None of my people have had a complaint. We are satisfied with it. While my technical level is not that of an engineer, I can set up VMware, Windows, and Hyper-V environments. I can do the basics and follow instructions. This solution was super easy. We just installed it on a server during the original testing and then had it phone home and that was simple. We do not yet make use of it for API functionality, but this is something that we are looking into. It's part of our R&D plans to be able to push it from the cloud portal for customers. My people have already used it internally, but it's not yet for our clients.

Overall, we have been very happy with it. Like any new product, there are things that need to be fixed. When they fix them, the tool just gets better. So, I am very optimistic that it will only get better, and it has already been a huge help. We have been converting over as many of our clients to using it as possible. At some point, because we have to restart, we need the collaboration of the user. This is not really a problem with Automox. It is more of a human being thing. However, it exposed something that we needed to talk to our clients about. We use six or eight different tools on most machines. This is one of my favorites because we don't have to bother the client. The joke that a colleague of mine used to say was, "We are the plumbers of the 21st century." I thought about it and that really makes sense. Like plumbing, your average user doesn't understand how all this stuff works. They don't want to understand how it works. They don't care. They just want it to work. Also, like plumbing, when there is a problem, it needs to be fixed right now, not tomorrow or next week, because it is a mission-critical thing. Having Automox allows us to bother people less, fix things faster, and generally be a better managed services provider providing better service. There is a lot more transparency as well as be more under the radar than it used to be when we had to schedule everything manually. Definitely do the trial. Pick some meaningful use cases, test them as thoroughly as you can, and also be very aware of the human policy side of things. When you get into technology like this, it is really easy just to focus on what the tech can do, but there is always a human side of it. The human side in this case was the forced reboots once a week. That was something we had to get our clients to approve because we were restarting their machines. Therefore, make sure you look at it not just from a technology impact, but how it impacts the users and what you will need to change as well as any kind of policy you will need to set up on the human side. We are looking into how we can leverage more of the solution’s API functionality, but we are not using it at this time. I would give Automox a nine out of 10. The only reason that I am not giving it 10 is because of the inheritability thing and having to call every time that we set up a new client, when we need to have them link it to our account.

The present size of the environment that we are managing with Automox is around 1,500 agents and we have four IT consultants who work with the product. My advice to others who have not already purchased the product or are in the process of considering its implementation or use would be to take advantage of the free trial. Automox facilitates an understanding of how to set up one's groups, the manner in which the notifications are employed, and how there are reboots referrals and patching deferrals. It enables the person to properly understand the product's capabilities and affords him the opportunity to match this up with the tolerance for patching in the organization. I think that, by default, Automox is really aggressive, especially in terms of forcing patching reboots. This will result in unhappy users if one is not careful and immediately proceeds with its deployment. As such, it is really important to properly understand what those defaults are and the default user experience.

My advice for anybody who is considering Automox is to utilize the free trial. It really doesn't take long to do it. What you can do is just install the agents on a handful of machines, then you can just put it in discovery mode. From there, it would tell you exactly what patches are missing, and you'll see the difference between what Automox is finding and how many things are missed already. Generally, whenever we do that, you see that the previous patching method is not as good. Then you can start testing out the policies a bit more and actually getting them installed. It really doesn't take long. In a week, I think you'll be able to see how effective it is. It's a neat little system. It's good. The biggest lesson that I have learned is an obvious one, but watch out for the auto-reboot option in the policies so that it doesn't just go and reboot all of the machines. The notification feature is okay, although it's a little bit hit and miss. It will give you the notifications, but then if you ignore them enough times then it won't tell you that it's just going to go ahead and install immediately. When this happens, it may just reboot the machine. It will have given you a lot of warning but it's not right at that moment. It is something that you should be mindful of. The best thing to do is choose to reboot at one of the times it is asking. Overall, this is a really good solution and we are really impressed with it. However, I would still like to see further integrations. I know that they are pushing people to use the worklets but I still think it creates more effort for the client. I would also like to see the ability to handle customers within one larger group and fix the access control between multiple customers. I would rate this solution an eight out of ten.