What is our primary use case?
As an IT company which is a managed security provider and managed services provider, we use Automox primarily for our own internal patching and policy management and, also, for reselling it to our client base. We are talking about the same product for the same solution set. We simply resell it.
How has it helped my organization?
Automox has improved our organization when it comes to the more traditional use we were making of RMM or remote monitoring and management solutions. Admittedly, some of the stories in the news over the last few years of managed service providers being hacked or compromised and of the hackers managing to obtain access to the RMM solution and to push out ransomware frightened us. While a person who was really intent on this could do the same with Automox, it would be more difficult as the solution has a lighter-touch.
This makes it more lightweight than some of the RMM solutions. As it's a bit more complicated, a person would need a good grasp of what he's doing with scripting. In contrast, with some of the traditional RMM solutions, all a person needs to do is state his desire to run a given file and he will receive the help he needs. As such, we think it's a bit more secure than a standard RMM solution. Owing to its lightweight nature, it doesn't consume many system resources. This allows users to have a better overall experience, as their computer's are not getting bogged down by another agent that is consuming its resources.
Furthermore, Automox provides complete visibility for any laptop, desktop or server in our environment, regardless of whether the person is on the train, in the cloud or on the move. This is a very important feature for us, the reason being that these capabilities traditionally only exist on machines when they're in the office or in a defined place. Yet, there has been a general trend over the past three to five years, and particularly during the last year with the Covid-19 pandemic, towards working remotely, with people commuting to the office only several days each week. As such, it is a valuable feature to be capable of insights and machines regardless of their location and to be sure of our abilities to patch and manage them.
Additionally, the solution's speed in carrying out its functions is quite good. There are a couple of different use cases for patching. We have, indeed, set patch schedules and we have found that if we state our desire to patch a group of machines at 10:00 AM, they will all be patched at this time. There's no delay or staggering when those machines get patched. Also, from the scripting side, we can send out commands and they're often received by the end point within 30 seconds. Things are so nice and responsive, whether we're just performing a scheduled task or going into the console and doing something manually. Things just happen, which is nice.
Also, we make use of Automox's API functionality, although just for monthly reporting and we do so to make sure that we're getting accurate agent counts. I can slice up the reporting however I wish via the API, but I know there's much functionality involved in running through it such things as commands and patching. While we don't use it for that, I do utilize the API functionality.
Overall, the solution has definitely saved us lots of time, although an exact figure would be difficult to calculate. I would put the conservative figure at 20 hours each month. In the past we utilized a person whose job it would be to go in and manage patching, review everything and reach out to make sure that things are getting patched. In the past we could not even be certain that what we were using was actually patching the machines. The savings in time is incalculable to me.
What is most valuable?
The most valuable feature is the patching. The fact that it's just one product that can patch multiple operating systems is really great. We've been utilizing a feature called Worklets, which basically allows one to script, simply to run code on the machines on which it's installed. This we've been using to manage certain endpoint policies for some of our smaller clients who lack an alternate solution for doing this.
Moreover, we value the patching capability of this solution and the fact that it's a single console across Windows, Mac OS, Linux and Points. Our impression of the solution's console for patch management, in particular, is that it's quite good. We have seen many improvement made since we started using the product over the last six months or so. A really big push has been made to consolidate numerous features within the console and to make it a little more accessible... Every month it seems like some updates to the console are being released which makes things easier. I trust that, over time, the product will be as efficient as it could possibly be.
We use solutions worklets to create and automate customized tasks across endpoints and we consider it very important that they enable us to enforce tasks across all managed endpoints.
Some of our clients in, say, just a five person office, do not have a traditional, single central server which can manage policies that are then pushed out to various end points. So, we can use Automox to enforce policies locally on each machine, in addition to running one-off tasks and performing some basic management functions. For some of these clients this a really big sell. If we could only offer patching capabilities, maybe these clients would be more on the fence about purchasing. Yet, since we can help manage their end points, in addition to doing the patching and getting some of the other visibility that we get, it helps us to make the sale.
When it comes to policies, it is relatively easy to do setup via Automox. It is true that there are some complex use cases, especially as a person starts getting into work, at which point things can get a little more confusing. However, the general process of setting up a policy is quite easy.
Furthermore, we felt it to be very important to make use of Automox's free trial before going with this solution. We also took into account its availability. We are talking about an investment. One should not buy a product if he can't first try it out. This is standard procedure in the IT world. We considered this to be huge. We felt it important to get in there, deploy and play around with it, to break it a couple times and figure out how we can use it.
What needs improvement?
Overall, the ease of use is very good. However, in respect of the patching concepts, there's a bit of a learning curve in terms of understanding how Automox wants you to work within the console, not only splitting up everything into groups, but then having the various policies assigned, which is the point at which they all kick off. I admit that if we were a single organization or simply managing one, it would work a little better. Since we have so many different clients as a reseller, it makes it really complicated. As I know this is something the company is striving to improve in development, I can say that the product is great for the management of only a single environment. Only because of the issue with our specific use case would I knock it down a mark.
Furthermore, as we are managing multiple customers within a single portal, there needs to be a procedure in place for adding a new organization for each new client. The problem concerning the patch policies and all the workloads is that what is set up in one organization is not transferable when creating a new organization. This means that we have fifteen or twenty policies defined within a given organization. As such , it is a pain to make a new organization. It takes a lot of time.
Moreover, we have to recreate everything. While I know this issue is actively being addressed in development, I am left without a solution for the moment. This is definitely a sore point. While access control for users does allow me to grant user-specific access to a particular group within an organization, I must provide access to the organization as a whole. This is a pain, as it sometimes requires us to set up new organizations.
So too, patches and policies, when applied to a parent group, do not trickle down to any of the groups that are nested under the parent group. Consequently, if we have a group of Windows machines, and beneath each one of that parent group there appears each possible client, then every time that I wish to create a new client and put it under Windows Workstations I must apply new patch policies, or the same existing policies to that new group. It would be a lot easier if policies were just inherited from a parent group. Then, we could simply manage them in one place. It is true that all these issues can be surmounted, yet, as we scale as an organization, we are certainly looking to hire more junior members of staff to manage these things.
This complicates things for someone who is coming in with no experience. Certain features are typically included in a system, policies that are inherited from a parent group, so it's strange that in this instance this is not the case. These are some of the big things that come to mind.
From the user's perspective, the product does allow notifications to be shown on his workstation when the patching is about to happen or when a machine needs to be rebooted. While updating the user about an impending patch to his machine is certainly useful, there is no status provided of the patching.
I am always giving thought to the significant updates to the Windows features. A user who requests that a patch be made at a given moment cannot truly know what's getting patched. Also, this process can take an inordinate amount of time. There are times when a user will simply put a machine to sleep in the middle of a patch or do something to cause it to fail. A user lacks visibility into what's happening. He is aware only that his machine is about to patch and is left with the question of the best way to manage it. A large Enterprise company with an IT team may have a systems administrator who's only managing patching, perhaps sending out notifications to their users at all times.
Moreover, the process of keeping the user in the loop should be made easier. A company such as ours, which has several small clients, or one which is a small client itself, will remain in the dark and have to satisfy itself with the knowledge that the machine is getting patched. Consequently, I wish there would be more insight on the front end. It is here that problems and complaints arise.
On a scale of one to ten, I would rate this product an eight. I say this only because of the issue that presents itself in our use case concerning the multi-tenancy set up. If more organizations were being contemplated, Automox would meet all of our criteria, be deemed by us to be a great product and would merit a 10 for sure. However, I feel Automox's present quirks in its ability to manage multiple clients to constitute its weakest point. This said, I know the company is actively working on this issue and am confident that it will be successful in addressing it.
For how long have I used the solution?
We have been using Automox for around 18 months.
What do I think about the stability of the solution?
Being cloud-based, the availability of this solution and stability of our agents is very good. We haven't had any outages that I recall, so we trust that the agents are reporting in.
We don't tend to lose agents. We have not encountered computers that simply stop reporting in for no reason. Moreover, we've always been able to get into the console to do work, so I've been very happy with the availability.
What do I think about the scalability of the solution?
The scalability of the solution is quite good. We have a couple of issues in terms of our multi-tenant environment, but in terms of scalability, as an individual organization, I see none. A minor point I would mention is that there are occasionally some load time issues in the console when trying to load a page in the realm of 500 devices.
How are customer service and technical support?
Automox's technical support for their product is very good. They're responsive, they're knowledgeable and they help out when needed. I have encountered no issues in which a support case has dragged on or where concerns have been brushed off. The technical support always answers things directly and quickly.
Which solution did I use previously and why did I switch?
Prior to using Automox we made use of the EMM solution Continuum RMM for patching and for numerous other tasks.
We switched to Automox because we wanted something that has a bit of a lighter touch. It is pretty incredible to think of the the number of agents that get put on people's machines nowadays. As a consequence, we were looking for something that would consume fewer system resources. We wanted something that wasn't so completely hooked into the system at every level. Automox really is a very lightweight agent. All it does is relay PowerShell or Bash commands. It's not really running processes that are hooked so deeply into the system that we would have another administrator account on the computer.
This is not its default function, although I suppose it can be utilized in this manner. What I mentioned was really appealing to us. So was the reliability and the ease with which we can simply go into the console and see what is going on. Our primary focus is to continue with patching and this was the big thing for us. Not only was it very difficult to see what was getting patched, but, while this was being undertaken, to trust that the reporting was accurate and that the machines were actually getting patched and reporting in. We switched because this was becoming cumbersome.
How was the initial setup?
The initial setup was straightforward and it's gotten more so. Improvements are being made to this.
The deployment may be accomplished in a couple of different ways. Broadly speaking, for the majority of our machines, which are Windows-based, we can customize an installer so that it can then be supplied to the client. All one would need do is double click and run the installer. That is all. This marks an improvement in the product from a year-and-a-half ago, which is when we first started utilizing the process. Yet, even at its most complex, we are really only talking about one installer that the client runs and then copies and pastes into a site token. Because we're managing the policies, it's all set up in the back end and all the user has to do is install an agent. There's no other configuration to be done on the user's computer, which is great. So, really, it can be easily deployed by anyone, as long as he knows how to run an installer. At this point, he will be good to go.
What was our ROI?
We have seen a return on our investment with Automox, although it is difficult for me to quantify. I do know that our consultants who utilize the product have had a good response. Also, I know that, simply from a management perspective, it makes things super easy to accomplish.
What's my experience with pricing, setup cost, and licensing?
I feel that Automox is reasonably priced. If a person only wishes to patch Windows machines, there are probably cheaper solutions available, but this would be applicable to no more than a small percentage of organizations. As most organizations have a mix of MACs and Windows, it is certainly of great value to have one product that can handle both operating systems and Linux, as well.
This definitely increases the product's value. To be honest, I think we're on a bit of a different pricing model, because we resell. While I know that we get volume discounts the more that we sell, I have no idea if this would apply to a single organization that bought directly from Automox. I don't know how that works. However, I do believe that a person should investigate volume pricing. It is likely this would be relevant, or, alternately, that it would be advisable to purchase from a reseller, such as Williams Cybersecurity.
Moreover, we can get you a good deal. The product is a great value. It can provide a bunch of different types of functionality all in one place, it's easy to manage and it scales well, whether a company has five people or 50,000.
Which other solutions did I evaluate?
Ivanti Patch management was another solution we evaluated. We didn't go with this solution because it was only for on-premise Windows machines. Straight off the bat, we considered this a no-go.
There was, yet, another solution we considered, but its primary use was only for the patching of Windows machines. As such, even though it patched Windows machines anywhere they were connected to the internet, it would do so for these only. The main deciding factors in favor of Automox was the fact that it could patch multiple operating systems, that it could do so from anywhere that they had an internet connection, and that the agent is lightweight.
So too, when evaluating other solutions, we took into account the cost difference between those that are on-premise and the cloud-based feature of Automox. I recall that Ivanti is really expensive and on-premise only. We took this into account, as well. Of course, if it was something that we had to host or which had to be deployed at a client site, we would have done so. It wouldn't have been a deal breaker for us, but it certainly makes it easier when you don't have this to manage.
A nice feature about Automox is that it allows us to tell a customer "we're rebooting the computer in 15 minutes. You have no choice." So, depending on the environment, that can either be a pro or a con. This requires an understanding of the workload and the fact that software can be fairly easily deployed through Automox. The advantage is that when a person is in the process of undertaking a series of manual installations or managements, he can have an understanding of what can be accomplished with Automox. This way, he may try to include this in his setup workflows as quickly as possible and to assess the potential benefit.
Of primary importance is acquiring an understanding of what the default experience is straight out of the box. The solution tries to patch by default. It does not satisfy itself with merely trying to reboot and sending out a slew of automatic notifications. Mostly, a person could simply set the default patch policy to "patch everything" and this wouldn't always work, especially on Windows machines. Therefore, it is important to learn how to stagger patches week by week or day by day, even if one needs a patch quickly, rather than simply accepting the defaults as being good. While the solution is easy to set up, there are still some configurations involved to ensure that everything happens cleanly. That can take some time to figure out.
What other advice do I have?
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.