What is our primary use case?
I work for B/Net Systems. We are a managed services provider, which is outsourced IT. We have a lot of clients, mostly in the Washington, D.C., Metropolitan area. We do as much or as little of their tech work as needed. A lot of the work that we do, really the bread and butter, is what we call monthly maintenance. That is making sure that all the computers are healthy each month. This involves a lot of software patching, making sure there is free disk space, ensuring there isn't anything in the error logs, etc. Automox helps us manage the software update part. It is really great because it manages software updates for every piece of software on the computer.
How has it helped my organization?
It has been a huge time saver and efficiency improvement tool. It goes down on a very deep level. It is checking stuff that we weren't even checking. While we were just checking the top line application software, we weren't really getting into the subsystem level. The tool does all that. It is all logged, and it is a big help.
We use their automation for patching. We let them do it. We have discovered all sorts of things, and a lot of it has to do with user behavior. For any type of software, you sometimes can update it in place and sometimes it requires a restart. That is because the application needs to shut down so you can install the patch, then it has to restart. Sometimes you can shut down the application, whereas other times it requires a machine to restart. We found that Automox would pop up, and say, "Hey, I am going to restart your machine. Is that okay?" and people would say, "No, I am busy. I am working on something right now." They would consistently defer it, and it never happened. Then, guess what? A month later, they are still not up to date.
The biggest reason for doing software updates these days is the security aspect. Some developers found some sort of hole and put out a patch, so it's a security thing and you just want to make sure that you are as secure as possible. If you are in my position where we are taking the responsibility for our clients' technology, we absolutely have a responsibility to make sure that it is as secure as possible. Therefore, this is a real problem. We had to talk to our clients, and say, "You need a human policy where we all agree, for example, Friday at six o'clock that your machine will be restarted. You will get one opportunity to defer it. However, the next time it turns on, it will ask you again, and if you don't do it, then the next time it tells you, it will restart." We can customize all that. Some clients will give us two times and others give us three times to defer it, or make it on a Saturday. It is little things like that which make the tool great.
It is important to us that this solution is a cloud-native platform. That is kind of how our business is set up. The whole world has been moving to the cloud over the past few years, but we have always tried to be cloud-centric. We don't have a physical office because no one comes to visit us, so we try to push as much as we can to the cloud for all the usual reasons: It is more scalable and robust as well as the security will generally be better. Features can get added on the back-end, and we will wake up one day, and say, "Oh cool. You can now do this in AutoMax and we couldn't do this last week." So, it is great.
What is most valuable?
For our Windows clients, it has been a huge help because we can now just go to the Automox dashboard and look at literally every single piece of software on that computer, even subsystems stuff that isn't an application that you would recognize, e.g., driver updates. It is great because we can see on the dashboard when something is up to date, and when it is not.
The interface is great. It is easy to use. It is really easy to see and drill down into systems that are compliant and also see where they are not compliant. You can push out updates. So, if for some reason that the Chrome update didn't take, then you can push out the updates from Automox, and say, "Hey, try it again." If it doesn't work after a couple of tries, then we can always remote into the user's computer and do it manually. This has been a huge time saver and convenience for our clients and us because we do almost everything remotely. We have been set up like that from the beginning.
It was a different ball game when I started this back in the 90s, because everyone had a desktop computer. If you had to remote in, assuming they left it on, you could just get into it after hours because no one was taking their desktop computer home. Right now, everybody is on laptops and taking the laptops with them everywhere. As soon as they close the lid, it is in sleep mode and we can't get in. Having a tool like Automox means we do not have to chase around our clients, and say, "We need to install this thing. It didn't work. Can we pick a time on Friday afternoon?" They reply, "Friday afternoon at three o'clock is okay." and we set a calendar appointment. Then, we try to get in and can't. When we talk to the person. "Oh, something came up at work. I'm sorry, but can we do this next week?" We wind up chasing them around for days before we get a time to do it. Automox cuts through all of that. We just go to Automox, and say, "Push out a new update and apply it." We can tell if it took or not from the dashboard. It has made our workflow very efficient. Instead of chasing around people, trying to line up remote sessions and schedule them, we can actually work on other stuff. It has been a great tool for this.
What needs improvement?
A challenging thing, which isn't really Automox's fault, is updating hardware drivers. The software part is great, but a driver is a piece of software that lets the hardware interface with the operating system. For example, you will see that Dell EMC will put out drivers for their network adapters and it fixes some problems. For some reason, the hardware manufacturers keep very close to themselves. You need to go to the Dell EMC if you want to use Dell EMC tools to upgrade Dell EMC drivers. This could be any hardware manufacturer, not just Dell EMC. It would be great if Automox could do this too. However, it could be that it is not their fault that the hardware manufacturers don't want to give that up. This is only kind of a minor quibble that I have with it.
I know they are going to fix this because I have talked to them multiple times and complained about it. Our company B/Net Systems has an account with Automox. Under our parent company, we have these different child organizations who are essentially our clients, like XYZ corporation and ABC lobbying group. They are all listed with all their computers under each one. This seems like a minor thing, but it is a real headache. You would think that we could put all our technicians on the parent level and set permissions on who can do what, so we have billing people, technical people, managers, etc., then we set it up. You would hope you could set it up at the parent level and have it be inherited by the child organizations. However, when we bring on a new client, we need to go into that client and manually set up my account, my chief engineer's account, three technicians' accounts, and a billing person's account all over again, which is annoying. We have probably up to 15 or 16 of our clients on Automox now. For every single one of those, we have had to go in and set this up. Then, if anything changes, we have to remember to go to Automox and change it 15 or 16 times. So, we just want inheritable permissions, and that is it. We have talked to them about this, and they are like, "Yeah, we hear a lot of complaints about it." I am thinking, "Guys, I have been complaining about this for a year and a half. When are you going to do it?" It must be some tricky thing or not an easy fix, because I can only assume if it were easy, then they would have done it by now.
I wish we could create an inheritable policy too. That would be awesome because every time when something declines we have to set up a brand new policy all over again exactly like the other 16 that we already have. This is growing pains stuff, and they are going to figure this out at some point. Hopefully, in the near future, they will have inheritability.
Automox doesn't do Macs, so it doesn't help us there.
For how long have I used the solution?
We have been using Automox for a little under two years.
What do I think about the stability of the solution?
We have had zero problems. As far as I know, I have not had any indication that the agent is unstable. It seems to be pretty solid.
What do I think about the scalability of the solution?
It seems scalable. We operate in this space where we are working with small- and medium-sized enterprises, nothing like thousands and thousands of machines. However, we have hundreds and hundreds of machines on it, and it has scaled just fine with the exception of the inheritability, which is kind of a pain from a scalability standpoint.
How are customer service and technical support?
The technical support is good. I have no idea of the size of their tech team, but they always resolve our questions, and it is always timely.
We have a joke. We call it tech support roulette because you don't know how good of a technician you will get when you call the help desk. Sometimes, you get a good one. On the other hand, I have even called Microsoft and gotten a tech who didn't know what he was talking about, which is kind of shocking. However, we have not had an experience like that with Automox. Every time that we have called, the man/woman on the phone who answers, or we were transferred to, can fix the issue. It is also not more than one hop to a person who can fix it for us.
Which solution did I use previously and why did I switch?
Before Automox, we had a very manual process. We would set up Microsoft Windows to automatically download updates and install them, but that did nothing for Adobe, Firefox plugins, Chrome, etc. Those programs have their own auto update features. However, if you work in tech for a while, it becomes pretty obvious that you have to follow the trust, but verify model. It is great that an automated tool says that it will update its own software on a regular basis, but how do you know it actually happened unless you go and check? So, we had these long processes where we would manually go in and just check, "Is Adobe up to date? Is this up to date? Is that up to date?" It was a real pain in the neck.
We would have to go check all these different things, run reports, and compare version numbers. It was a time-consuming pain. It was a little easier on the Macintosh platform, because Macintosh mostly runs all software updates of its operating system through the app store. There are some that somehow escape that. Though it was a little easier, it was still trust, but verify. We had to go in and take a look at the report to make sure.
How was the initial setup?
The initial setup was pretty straightforward. We trialed it with one of our medium-sized clients, so we had to run around and install the Automox agent on all their computers then figure out how to tweak it, customize it, and set up the reporting and alerts. You can set up policies, where you can tell this group of computers to update just this software at this time. We played around with that, but it was all very well-designed.
The permissions/inheritance thing was the only real major annoyance, which we didn't discover until we went to add our second client. Then, we are like, Whoa, where are all our accounts?" We called them up, and they were like, "Oh, you have to set them up again." I was like, "Are you kidding me?"
Setting up policies is not difficult because our methodology is to be as consistent as possible. Unless a client asks us, we will not set up 10 different policies for them. We want a one size fits all that would update every single piece of software on this computer at least once a week. That is all we care about. We are not going to subdivide and say, "These are developer computers." We haven't had that need, but if we needed to, we would. Our policy needs are very simple, so we haven't had a need to get complicated with it, so setting it up has been easy. It works.
We learned some things, like you don't want it to update too frequently. It sounds counterintuitive, but the sweet spot seems to be about once a week. If you do it more than that, it will start alerting the user. Then, they will get confused and be like, "Wait a minute. I thought we just did an update yesterday. What is this?" Then we get a support call, a ticket is generated, and we need to talk to them. It just created too much confusion. We finally settled on doing it once a week, Friday at six o'clock, unless the client wants something else. We give them one chance to defer, and that's it. That is our base policy that we replicate across.
What about the implementation team?
There are some growing pains to Automox. For example, when you set up a new client, you would think you go to the console, set up a new client, and it will show up there as a child organization under your MSP organization. Then, you think, "I'm done," but you are not done. You then need to email or call the tech support people at Automox, send them the URL for the child organization that you just created, and make sure they link it to your account. I think that is for billing reasons. Even though it shows up under my dashboard as a client that is a child under my MSP parent, it is not on their system. They are very nice about it. They add it within an hour or two, then it is done. However, it is just one of those things where you are scratching your head going, "Why did you design it this way?" We have talked to them about it, and they're like, "It is on the list. We will get to that."
What was our ROI?
We have seen ROI. The cost isn't really an issue because our clients bear the cost of that. They pay for it. We have seen the benefit in process improvement, streamlining our operations, and peace of mind, e.g., being able to pull up a console and see how many systems are not compliant.
Previously, we would run a report, scan it, and compare it. We were spending 15 to 30 minutes a month on each machine on this stuff because you would find stuff that wasn't up to date, then you had to fix it. This solution takes that time down to minutes. Automox saves us easily many hours a month.
What's my experience with pricing, setup cost, and licensing?
The pricing is great. It is inexpensive and on the lower cost side of some of the tools that we use. Our tools range from $2 a month per machine up to $7 or $8 a month per machine. Automox is closer to the $2 a month side. Of course, we are resellers, and you have to be a reseller to use it. I don't know that they sell the solution directly, so we could mark it up to whatever we want but we don't do that. We just pass through the cost and make our money off of labor. There are companies where that is their business model, and they pick up dollars wherever they can. Good for them, but that is not how we do it.
For all these software tools, it is usually a subscription model. There is a monthly charge that we need to pass along to our clients because we are doing all this for their benefit. It is only a couple of bucks a month per computer, and that is a low enough price point where our clients, without exception, have accepted it, and said, "This is great. We will pay that. It sounds like a worthwhile thing."
Two years ago, we used the free period for a little bid with a trial client after we got their permission to give it a shot. The free trial was important in our decision to go with Automox. I like the "try before you buy" model. Because if it doesn't work out for whatever reason, the interface isn't easy to use, the tech support people are no good, or the product is unstable, then you can walk away from it, if you want. There is no big commitment, and having a trial is perfect for that.
Which other solutions did I evaluate?
We didn't have other options because we couldn't find anything that was exactly like this solution. It was also recommended to us by one of our clients who was using it. That is how we found out about it. Therefore, it came highly recommended, and we thought, "Let's take a look at this and see if we like it." We did, we loved it, and we haven't looked back. It has been a process of just getting as many clients as possible on it. I would love to have all our clients on it. It simplifies our life.
What other advice do I have?
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.