Automox Reviews

We use Automox as part of one of our product offerings, our server management, where we use it for patch management.

As concerns the Atlantic.Net side, when we're selling to the marketplace, we sell mostly public cloud with dedicated hosts, or cloud VMs. We also sell hybrid cloud and private cloud, as well as co-location when that unique need arises.

Obviously, with so many servers out there, our clients are very big into compliance, examples being HIPAA, PCI, NIST, ISO certifications and the like. We need to be able to provide patch management and that's how we utilize Automox. That's what got us started looking for this back in 2017. We needed something as our in-house solution was not working very well in terms of what we wanted: visibility and up-to-date patching. At that point, we decided to explore new open source options versus what is out there for purchase. 

This is how we stumbled across Automox and started using it with our clients. We never truly made this kind of functionality into a formal offering before settling on Automox. It was more on an urgent-need basis. But, once we adopted Automox, we made it a formalized offering.

The biggest improvement to our organization is the man-hours it saves us. One of the reasons we shied away from selling these kinds of things in a formal product, prior to Automox, is simply that it would have taken two or three dedicated people just to do updates — and that was before we really started it. We had some formal things for Windows in place, but because we've had so many different product offerings for operating systems, not just Windows, it was really tough to have everything covered under one solution, especially an open-source solution.

The savings in man-hours alone, in switching from that to Automox, means Automox has paid for itself. While I do not have exact figures, since then we've been patch managing five to seven times the number of servers. There's no way we would've been able to do that and still keep it cost-effective. How much time do we save? It depends on the load, since there is always that spike, given that Microsoft comes out with a new patch on Tuesdays. Not taking that into account, we probably spend about an hour a day, per person, meaning roughly five hours a week. That comes out to about 20 hours a month doing patch management through Automox, where in the past it was a full-time job for about two people.

Since we have scaled—and all the more so because in security compliance you have to test the updates, and do other things as well—we've probably saved hundreds of hours a month, at least. This amounts to significant savings.

The most valuable feature is probably the interface. Obviously, the work they do behind the scenes is important, such as: making sure that all the patches are there and making sure that everything is explained, such as what requires a reboot and what does not. It saves us on much legwork by removing all that manual processing from our side. From our point of view, the interface is clearly super simple to use, super simple to get up and running. It also makes it very easy to digest the data.

When I look at the dashboard, I can see how many are scheduled for updates, how many are already fully up to date, and how many need attention. I can see if there are any exceptions that my people put in for the customer. It's one of those things where it's really easy for everyone to be on the same page.

I can go to the Control Panel and I can create different organizations. This way, not everything has to be under one single interface and account. We can split it out as we see fit. That was something that we wanted. While it was not a big deal, it is nice that I can now go in and see a customer who has 400 VMs with us in a single pane of glass. I can click and see where they stand, as opposed to having to go through thousands all mixed together.

We would like to see additional detailed reporting for Service providers like us. We had to build our own reports via their APIs to meet our needs.

I have been using the product since June 2017.

Other than when maintenance is being performed, we have had no issues with the stability of the product, no downtime.

The scalability has been great, especially now that we can segment out large customers. 

We have significant plans for integrating it into our cloud portal. We can start with just the patching, which is what we are undertaking at present, and progress to offer it as a self-service model in our cloud portal.

We have had no complaints about the technical support. We've used it twice in almost four years now and have had no issues, and no complaints from our side. It's been great.

Prior to using Automox, we utilized open source and a Microsoft solution together. We would not consider the Microsoft solution to be a direct competitor of Automox. It was used solely for patching Windows systems, and the open source was used only for patching Linux-based systems.

There were a host of reasons that we decided to switch from this approach to utilizing Automox. The old systems were cumbersome, very hard to understand and to train on. They involved a long learning curve. Also, you were very limited in what you could and could not manage. You were very limited in terms of scheduling or the updates that you wanted to apply. For certain OS’s, even with the open source solution, you could not patch Windows and you could not patch certain Linux flavors with it. Just that issue alone left us asking ourselves how we could offer a full-fledged product without even being able to do all the OS’s that we offer.

That is when we started looking at a real system to replace it. We were not set on going with a cloud-native solution, but this being in the cloud reduced, by two VMs, what we would have had to manage, update, monitor and the like. That made life that much easier for my people.

We did make use of Automox's free trial prior to using it, which we considered extremely important. You may get promised the world concerning tech solutions, just to discover that they often do not properly work. A sales representative may promise you the world and then not carry through. We actually got an extension on the trial because we were not yet ready. We then ended up paying for just one endpoint on a server. We were getting a little delayed. Once everyone received the approval from everyone buying in, we proceeded to push it live. If they still make available a free trial, definitely use it, because it makes life a lot easier.

We required four staff in total for the deployment, involving two engineers who did the actual work, and two decision-makers. I found the initial setup of Automax very straightforward, very easy. My tech level is that I know what I'm talking about. I can kind of navigate pretty well, definitely not day-in and day-out, as I'm not in systems anymore due to my position. But, even if you told me to set it up today for a smaller-medium sized business that has 50 VMs, I could probably knock it out and do so without having too many headaches. That includes setting up policies, the VMs, and the hosts, and having everything set up and reporting back and making certain that we are hitting the criteria we set out to achieve. That is all pretty easy thanks to the interface. 

Regarding the length of time of the initial deployment, we did not rush with the testing. We had a trial and then we asked for another trial because we got pulled away due to what was going on with our customers and other systems. Once we decided to move forward with it, it took less than a week. This did not involve pushing very hard to get it done. It was more the case that my people had the time.

For our implementation strategy, we matched it up. The hardest part involved defining how we wished to put customers in at the time. That was before we had the ability to split them out into different segments. We had to figure out how to match what our other systems do, such as: customer number, customer name, and the relevant service policy. This is because some customers only want critical updates and some want all updates. Other customers want no updates to ever be applied. They just want to be notified of them and then they can update the patches themselves. We went in there, took our customer feedback and made it fit our needs.

We did not work with any third-party integrator or a consultant to help out with the deployment. I had experience because I'm actually the person in charge of our Salesforce and its development. With Salesforce, you definitely need the help of a consultant no matter what. You can get away with a simple deployment of Salesforce. Once you start getting deeper into CPQ and the like, that this is where the devs come in. With this, there's no need for them. It's very simple to deploy. We have two people maintaining it.

While I cannot supply you with specific numbers, the savings in man-hours alone has been a great ROI on the use of Automox. On the flip side, as we are heavily involved in the security compliance sector, we have to take into account HIPAA, PCI, SOC and the like. We need an offering for auto-patching. Whether or not the customer actually opts for it, the ability to provide him with the option at least gets us in the arena to bid on the deal. If we didn't have that as an offering, then we would have lost a lot more deals over the years.

The pricing and licensing costs have been great for us. We got in early and then they had a little price rise. Overall for the price that they charge now, you get your money's worth on it.

For us, they had no additional costs beyond their standard licensing price. I don't know if they do setup now but we did all our own setting up and deployment. It solely involved licensing costs for each endpoint.

My advice to others who are evaluating or thinking of implementing Automox is to give it a shot. If a free trial is still available, definitely use it, because it makes life a lot easier.

We did evaluate other options although I do not recall which ones off the top of my head. Most of them were not just patching solutions. They were a lot of other things too, and we did not need those extra pieces.

There are other differences between the other solutions and Automox, in terms of pros and cons. When it comes to solutions, we want to try to do open source first. We are very big on open source, our entire cloud platform having been built from the ground up by our development team. When comparing Automox to the open source solutions, we were finding many gaps where, perhaps, the open source could not support all the OS’s that we wanted to support, or which involved much more manual labor, or involved delays in the patches being made available in the appropriate amount of time. There were a number of reasons that, once we started examining everything, it made much more sense to go with Automox.

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.

My primary use cases for Automox are for patching, configuration management, and support. Our help desk receives tickets and we use Automox to create solutions that the help desk can use in an automated fashion rather than having to manually do the work. We have created ways to help them work faster.

A big benefit is Automox's ability to automate repetitive tasks for our help desk. If the VPN breaks, we can just click a button and fix the VPN for that person. If the software is having a hard time, we can run solutions to remove and reinstall that software rapidly so that they can get back to supporting the next person in line. Especially as our company is growing exponentially, Automox helps us scale rapidly because we can't just hire a bunch of help desk people and have them up and running quickly. Automox allows that particular effort to be a little bit more seamless. Almost every person that has the tool absolutely loves it.

It is very important to us that it is a cloud-native platform. Software as a Service means that I'm not maintaining internal architecture, servers, licensing, and the likes to keep it online or High Availability if I need it. I don't have to think about any of that because it's just there.

The most valuable feature is its ability to establish patching policies that continuously work with minimal effort. That's important to me because I am a long-time configuration management person and have dealt with other tools that require me to build the schedule up manually each time to create the list of patches. The value-add is that I'm not doing those two steps. The former step of building out lists of patches is the most important to have to deploy. The third-party patches require a lot more effort and Automox has taken that work off of my plate. That is a lot of work that a practitioner would have to do every single month. I am able to be more focused on patching compliance rather than building up patching, which has more value.

I patch across Windows, Mac iOS, and Linux. If I split it, it would be 90% Windows, 8% Mac, and 2% Linux.

Coming from prior solutions that were a lot more effort, Automox's patch management abilities are transformational. When I took over patching at my company, they were using on-premise architecture to patch. As the workforce shifted from being in the office into home offices, I was able to lift and shift with no effort other than deploying the new agent out into the environment.

Automox's console for patch management is very successful. There are some challenges in regards to third parties that change how they deploy software. Examples would include how Adobe or Oracle approach some of their third-party tools. From an Operating System standpoint, they're well on their way. In the time that I've been with them, they have overcome the challenges of feature updates in Windows and I think they'll also overcome the challenges of major updates across Mac and Linux in due time. 

In terms of how much time Automox saves us, I've had a few examples in my environment where I can explicitly point out how much time savings there is. One example was replacing Office 32-bit with 64-bit. We wrote a worklist to do it and that saved each interaction roughly an hour. There were about 300 people that wanted to do it. We were able to multiply that effort, remove 30 minutes and turn it into two minutes of effort. Over time, we're saving at least 40 to 80 hours a month due to all the different features that Automox is helping us automate.

I use their Worklets to create and automate customized tasks across endpoints. I heavily rely on Worklets across many aspects of the company. I have created Worklets to manage drivers, security configurations, and software management. It's way faster than expected, coming from traditional tools that take forever for policy to download. Manually deploying a payload to it running on an endpoint is almost instantaneous. It's so fast.

In terms of Automox's ease of use, I have multiple help desk individuals operating within the tool and building Worklets who have less experience in the field. From being able to take people with fewer capabilities and helping them be highly successful, the tool is much easier than it was with prior configuration management tools that I've used in the past.

We use their API to review clients to check how to pull back some of the Worklets that we've used that are doing inventory-type or compliance-type checks to build out custom reports. The API is almost an extension to every script that we can run.

It is still a challenge but not impossible to patch solutions like Adobe via Automox. It just requires me to go back to some of my older techniques and older tool belt items. I still have to reach back out to some of my old ways of doing work and accomplish it that way, but it's not impossible. Where there are gaps in their automation, there are ways for me to fill those gaps. They haven't left me high and dry. They've still left me with a way to work around it. It might be a little effort, but I can get there.

There should be better inventory capabilities. Right now, they only allow you to have insight into software out-of-the-box. It would be nice to also extend that into custom inventory that can be modified and managed by the practitioner. 

It would also be really great if every device that's in Automox is limited to a single group and you can only apply policy to that one group. It would be nice to put a computer in multiple groups and apply different policies to different systems. I might only have seven or eight systems that I want to do a very specific config on, and in order to be able to do that, I have to use the API to make that a reality in another automation. Automox is short. I'm able to use the API or manual effort to get past it. They should improve the experience so that less technically skilled people can also be just as successful as a higher skilled person.

I have been using Automox for 11 to 13 months.

In terms of stability, Automox is equal to other tools I've used. I tend to run into problems with systems on every network. It's to be expected. It's always difficult to be 100%. Automox is very comparative to keeping the stability across the board as far as clients staying healthy and online and continue working without intervention. It's very similar to other tools in the industry. From an entire solution perspective, it's almost always online. When there is an incident, they give me updates every 20 minutes as to what the status is. They have really good incident responses when it does go down. Overall, my impression has been very positive. It hasn't caused me any significant constraints on my company's ability to perform.

It scales with my environment quite well. I don't have to think about it. I started out with 1,000 devices and quickly went above that. I found a surprise bill and then was able to come up with a solution and put a guardrail up so that I wouldn't go over my licensing. Today I'm using it for 1,500 points. Within the next year, I'll probably be using it for 2,500 endpoints.

Four to five people work on Automox on a regular basis. We have security, systems engineering, and help desk workers. 

Support is very quick to respond. The support personnel are knowledgeable and they tend to be very positive in their interactions. They have a genuine "I want to help you solve the problem" feel. I've used them multiple times and they've taught me a thing or two, and hopefully, I've taught them a thing or two along the way. It's more of a partnership to me.

Prior to Automox, I've used WSS, SCCM, PsExec, and PDQ Deploy to manage the infrastructures for these particular outcomes.

I switched to Automox because we can go from zero to hero with all of our complex needs really fast. We don't have to have the infrastructure. We don't have to have highly skilled individuals. We simply just need to turn it on and start doing what we need to do and the rest takes care of itself. 

The initial setup was straightforward. I set up my environment in the course of three hours across about 600 endpoints.

I used my existing tools to push the product and then I used other tools to find the gaps and made an effort to close them manually very quickly. There was no plan. We just stumbled through the implementation. That's a testament to how easy the deployment is. You can come in without a plan and tackle it with no problem at all.

It was very easy to set up policies. They're rather straightforward. The user interface is very pointed. It keeps you aware of what you're doing. My only critique is that they should explicitly call out and make a policy event. Building the policies is rather intuitive. You can go in without any prior knowledge and build a policy without messing it up on the first try.

There has certainly been a return on the time spent accomplishing the tasks and accomplishing tasks that we didn't even think would save us time, but it ultimately did. We have also seen a return in our ability to patch everything and keep it compliant. Our vulnerability management program measures this and so far has been a success.

There are no additional costs in addition to the extended licensing fees with Automox. You get support and per endpoint license with what you purchased.

I looked at ConnectWise, BigFix, and considered Cisco Meraki System Manager. I considered going towards SCCM for that. Out of all of them, I couldn't see any other product besides Automox that would get me where I needed to go as fast as I needed to go.

It is much cheaper to go with the cloud-native solution than it was for on-prem. There's a trade-off there. There's a lot of functionality and features that you don't have with Automox that you would have with some of these on-prem solutions that just don't exist yet.

For example, the ability to push policy control, Bit-Locker control, remote access, or having a self-service software portal for any employee to log into a portal and say, "Hey, I need Adobe reader." They click a button and they now have Adobe reader. We still have to rely on our help desk to call in and ask for said software and then we can use Automox to push it. It would be really great to have that ability. 

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. 

We are a managed service provider and we use Automox to patch our clients' systems.

We have integrated Automox directly into our breach prevention platform, ThreatAware, which means that having an API is a massive win.

Automox provides us visibility of devices in our environment, in terms of patch status and applications, and it is important to us because you can't protect what you can't see.

This product provides patch management from a single console across Windows, macOS, and Linux endpoints. Overall, the patch management is very good. If it can't do something because I haven't integrated it, you can use the worklets and do it yourself, which is great.

The speed that Automox carries out its functions is really quick. When you install the agent, literally within 30 seconds, the machine will appear. This is really handy because if you are rolling out a load, you can just check them off as you go. You don't have to wait half an hour and come back. We've natively integrated it with their API to ThreatAware and if we say, "run a patch or reboot," literally instantly, those patches start installing within seconds. It's very quick.

One of the key features we use is the worklets, which are used to create and automate customized tasks across endpoints. My team uses worklets all the time. One example is that they use them to install all of the other underlying agents. We use them to connect to Freshservice and TeamViewer, where Automox installs the Freshservice agent and the TeamViewer agent, all within minutes.

We use the fully automated patching process and it's great. It literally just follows the schedule and does it when you want. Obviously, the machines need to be turned on but as long as it's on, Automox will patch it.

Patching automation saves us a lot of time. We try to utilize automation in everything we do. Then when we link it into ThreatAware and use the bulk operation feature, it just makes life easy. We're probably saving between 10 and 12 hours a month, which is pretty decent.

Automox gives us one less thing that we need to worry about. It used to be a real pain, where perhaps something wasn't installing or we didn't have something that was covering all the operating systems, or we had multiple products being used. We never felt fully confident that everything was being done but now, we can see exactly what's done, and what isn't. Literally, it's our go-to product for patching and we don't use anything else.

There are three features that I find quite valuable.

• It is completely cloud-based.
• It works on every operating system.
  
• It supports worklets, which means that it's really agile in what we can do with it.

Although we use it for patching, we also use it for pinging off other commands and scripts like uninstalls and just general fixes. We put Automox on first, then everything else follows using the policies and it's all automated. It works very well.

It is important to us that this is a cloud-native platform because we are a fully cloud-based business. We only use things that are in the cloud, pretty much. For us, the thought of having to maintain servers is foreign because it's something that we just don't want to do anymore. We used to, many years ago, but not anymore.

Automox's console has a clear interface, it's easy to use, and it looks good. In terms of importance, looking good doesn't really matter but the fact that it does look good means that it just makes it a lot more intuitive. What you need to do is clear.

It's super easy to use and we haven't found anything easier. You just specify what you want to patch, and what level. For example, you can choose to just do security, or you can do everything. You tick a few boxes and it's done. That's how easy it should be.

We've used a lot of other products, as well, and many of them are not easy to use. I think that SCCM is probably a prime example of the most complicated way of doing patching. With Automox, its usability is a sign that it's a very well put together, well thought out product. If it's there to do a task, you shouldn't need to be tweaking and adjusting.

The biggest area they need to fix, without a doubt, is the ability to copy and sync profiles and worklets between all of the organizations you manage, and the ability to have top-level user access control across all of the companies that you manage. This is important to us because we manage multiple companies and they're all in our profile, but all of the policies, the worklets, and the user access is all unique for every single company. It's a real pain and I wish they'd fix that.

As it is now, we have to create a worklet or policy for each client instead of replicating them. Also, for users, you have to invite one user to every single company. So, you create the user one, then invite them. If you haven't been invited to a company then you don't know what you haven't been invited to. It's a real pain and they really need to sort that out. 

I have been using Automox for a couple of years.

The stability is rock-solid and I've never had a problem accessing it. It's always online, and it's always fast.

It's scalable, but there's definitely that issue with the overall manageability of each client, and it is becoming annoying. In terms of adding in new machines, there is no issue there. However, adding in lots of different companies, because we're an MSP, does become a bit of a pain.

We've got approximately 15 people working on it and they're engineers ranging from second to third line.

This is a chargeable product, so we don't have all of our clients on it. At this point, we're probably protecting about 1,800 machines with it. We do plan on increasing the number of endpoints in the future.

The technical support team is really good. We have used them and they are fast. They're getting issues solved.

We were using SolarWinds N-able a long time ago and we were using Windows Update Services before that. Neither were fit for the purpose. N-able was unbelievably complicated to set up and not very effective. Windows Update was not fit because it can't do Macs, third-party tools, or Linux. Also, it was pretty hit and miss on how good it was during the patching, even on its own Windows machines.

Both of these solutions were pretty abysmal, to be honest, which prompted us, a few years back, to go looking for something better.

The initial setup is really easy and it involves only four steps. All you have to do is create your policies. In fact, we've written a guide on it in ThreatAware.

We've rolled out to each of our clients and we have a set way that we create our policies. It is a top-level template that we implement and we follow it each time we're setting up a new client. It takes about four hours to complete.

Setting up the policies is extremely easy. You create your groups and you do this by working out what type of machines you have and how you want those groups to be. You may choose to do it based on the operating system type, or on the severity of the criticalness. You might have a testing group, and you might also have one that's linked to schedules.

Then, you create the relevant policies that match that. So for example, you might decide that you're going to patch once a week, and you're going to start patching your test machines on Monday, then you're going to expand your group a little bit further on Tuesday. Eventually ramping that up to the critical systems on Friday.

After that, you link the policies so you know one's going to do X number of updates and it's going to do that once a week. Then you might have another policy, maybe once a month, where you are going to do feature updates. You may be doing security updates once a week, then your feature updates once a month. You just create those relevant groups and policies and tick the boxes you need. It really is that simple where you can specify something like "I want Windows and I want security, critical patches only, and I want that every Monday." Create that, then link it to the group. That's it, done. After that, all that remains is assigning the computers to the right groups.

We have definitely seen ROI from Automox, both in terms of time and money savings.

The pricing is fairly reasonable for what you get. We are on the premium licensing, which is the one that has the API capability that we use. There isn't any additional cost on top of that.

I wouldn't mind it being a bit cheaper but I wouldn't want it to be much more expensive. It's getting close to the point where we would need to look at other options if it were priced any higher.

We made use of the free trial before implementing it. This was very important because we don't implement any technology unless we try it.

We have used on-premise solutions to manage patching, configurations, and software, and it's going to be more expensive if you implement the on-premises route. It's not about the cost of that one server; rather, it's the cost of maintaining on-premises equipment, in general, and all of the limitations that come with it.

We looked at ManageEngine and several others. I know that there was none that actually supported all of the operating systems and worked solely on one agent being rolled out. They all needed to have some kind of infrastructure.

That landscape has changed now, as there are more competitors than they had then. However, they are leaders in this area, and we know this because we do evaluate quite regularly.

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.

We use it for patch management. It is used for patching servers and workstations.

We're using the web version.

Its flexibility is most valuable.

It should have integrated workstation access. So, there should be a remote desktop feature.

We dealt with it for a couple of months.

It has been pretty stable.

It should be easy. We're probably going the opposite way. We're not going to be doing much scaling up. If anything, we'll be scaling down.

There are three people who use this solution. They are from desktop support and server infrastructure.

I never had to contact them other than during the implementation.

It wasn't complex at all.

Its licensing for a year was nine grand. There was no additional fee.

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.