Senior Project Manager at a government with 51-200 employees
Real User
2021-08-03T23:07:00Z
Aug 3, 2021
The only thing that we've ever truly wanted is an onsite repository. Currently, all updates are provided directly from the internet. So, if you have 1,000 devices, all 1,000 devices go directly out to the internet. We would love the option of being able to put the updates on local storage so that we're not consuming as much bandwidth. That is literally the only thing that we've ever wanted.
Security Engineer at a retailer with 501-1,000 employees
Real User
2021-04-28T20:12:00Z
Apr 28, 2021
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.
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.
Director Of Business Operations at Ihloom Cybersecurity
Real User
2021-03-24T19:33:00Z
Mar 24, 2021
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.
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.
Facing growing threats and a rapidly expanding attack surface, understaffed and alert-fatigued organizations need more efficient ways to eliminate their exposure to vulnerabilities. Automox is a modern cyber hygiene platform that closes the aperture of attack by more than 80% with just half the effort of traditional solutions.
Cloud-based and globally available, Automox enforces OS & third-party patch management, security configurations, and custom scripting across Windows, Mac, and...
They need to improve the automation features. It could be more stable.
It should have integrated workstation access. So, there should be a remote desktop feature.
The only thing that we've ever truly wanted is an onsite repository. Currently, all updates are provided directly from the internet. So, if you have 1,000 devices, all 1,000 devices go directly out to the internet. We would love the option of being able to put the updates on local storage so that we're not consuming as much bandwidth. That is literally the only thing that we've ever wanted.
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.
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.
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.
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.
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.