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.
