We have the main office where we purchased the avast and have adnm running with all clients.
I also have a remote site that is connected to the main site with a vpn tunnel so some communication is allowed. The remote site is on a different domain however so when users went there their avast was marked as offline in the console. I have installed avast there now as well for the clients that are based there but when clients based at the main site traveled there their computers “jumped” to use that avast server. Now they are back at the main site and they are still communicating with the avast server at the remote site over the vpn tunnel and I want them back with the main avast server.
How do i get them back here? their computers here are marked as offline but pingable.
What happens if we travel to another company altogether that is running avast, will our computers start talking to their ADNM?
You need to set the address of the correct AMS in the computer’s group properties (I think it’s the first page). However, here’s the tricky part: this needs to be done on the server they’re currently communicating with, that is, the remote server that is being accessed via the VPN tunnel.
I hope it makes sense, and that it will work (it should).
yea the ams address is correct for the group they are in.
I think there is a problem here that needs to be corrected on the avast side. Any managed computer that is in a group on my main network and talks to AMS 10.1.19.10 will show up in the remote network ADNM when their computers are there. They don’t jump in a group except they show up in the dynamic group of computers with agent.
Now I had messed up a bit since they were showing up in dynamic and I needed them to configure some settings I added them to a certain group there. Which is probably why they weren’t switching back to the 10.1.19.10 AMS once back on that network. So I removed them from those groups and deleted the computers and I’ll see what happens Monday.
What concerns me is what happens if this was a seperate company? That company could have had complete control over managing avast on the clients? That isn’t a good thing, is there a way to tell a client that if it has an AMS server of 10.1.19.10 it will not talk to or respond in any fashion to any other AMS server?
This is really a problem. I can’ t keep the clients under control of one ADNM? If they boot up on a network with another ADNM that one will see them and all their group settings from the other ADNM will not be in effect. Then sometimes I can’t even get them back to the initial ADNM. I have some group settings for people so they can right click and control avast a little more than others. But when they come up on the other network they can’t control crap and my only workaround is to create a group there for them… and then when they come back to main network they should be on their computer stays black in the ADNM.
I’m still try to figure out a solution to the problem.
Basically, the situation should NOT happen if your AMS is 24x7 up. That is, the clients start a search for a new AMS only if their primary AMS is not available
The AMS is up 24x7 but when clients go to another site then obviously that AMS is not available to them. This doesn’t mean I want them jumping on that sites AMS though. Esp cause there is not guarantee that it is an AMS that I am managing. There needs to be functionality put in place where an admin can hit a check box that says the clients in this group can ONLY communicate with AMS at this IP address… or something like that. I see no benefit in having clients communicate with any AMS they can find if the original one isn’t available unless I explicitly have told them to do that if I have multiple AMS’s.
Ok, I updated the ADNM and my server groups. Can’t do the clients over the weekend, but anything special I need to do now to make sure the clients will only communicate with ONE ADNM and not any they might just find?
Yes, in the computer group’s properties, set the AMS address correctly (typically by an IP address if it’s fixed) and uncheck the “Try to find” box next to it.
Of course, for this to work, you need to update the netclients as well.
than ks… I unchecked the check box.
but I just noticed I have an old version already. I just upgraded to 4.6.438 and now 4.6.440 is out? What did that fix?