AEA - need help with REMOTE and LOCAL clients

Avast Business Avast Endpoint Protection
1

First off, moving from the old ADNM (Sept-2009) to the new AEA (June-2012) has been painful. I’ve had issues or hit road blocks at every turn. Here’s to hoping my battles are soon over… ::slight_smile:

Under Computer Catalog, I have created two sub-groups. One is for my local clients and the other is for my remote clients. If you go into the properties of each of those sub-groups, you can change the EAS address on the Communication menu. For my local group, I’ve left it alone 'cause it the default - the local FQDN - was what I needed anyway. For the remote group, I’ve changed it to a public FQDN that we have set up with a NAT so that my remote employees can report back to AEA while they’re abroad.

Under Installation packages, I’ve created two packages: one for each of the groups. If you go into the properties of the package, you can click on Edit to get into another set up properties. In here you can select the EAS Server. For the package to be installed on the local machines, I clicked on Detect and chose the local FQDN that dropped down. For the package to be installed on the remote machines, I typed in the public FQDN.

Under Deployment tasks, I’ve set up two tasks: one for each of the groups. In the settings for each of those tasks, I selected the appropriate package to be installed. The task that handles the package for my remote employees, only generates the install package (.exe) whereas the task that handles the local package actually can be deployed by right clicking one of the computers on the domain and pushing out the job with the explorer context menu.

Here’s the issue: The deployment task for the local clients will “fail” after I run the task for the remote package generation. I use the term “fail” loosely. When I deploy the package to the local clients, the task will complete and the client will have avast installed on it. However, it will NOT have the local FQDN listed in “%programdata%\AVAST Software\Avast\avast5.ini;” it’ll have the public FQDN!

From what I can tell, whatever touches “%programfiles%\AVAST Software\Enterprise Administration\InstPkgs\admin.ini” last on the AEA server is the cause of this quirk. If I change the deployment task for the local package to just generate an exe and NOT actually install anything, it will be the last thing to touch admin.ini. Then, I can change it back and deploy as usual - until I rerun the task to generate the exe for my remote employees.

Maybe I’m doing something wrong. Maybe it’s a bug. Either way, I need my remote clients to be able to communicate back to AEA and I was told that tweaking the communication setting in the groups’ properties is the way of going about it.

2

are you planning to send the installer file to your outside-the-office-users? i recommend doing the first install on the machine while hooked up on the LAN.
you can then have standard deployment packages without having editted anything manually. The group membership will then define which server to use.

i personally dont have the need to deploy my clients like you plan to do since all my outsiders do actually build up a VPN connection or come to the office often enough to hook up the laptop to that LAN.

it seems that for all packages thre is only one admin.ini and as u say the last setting that is made in it will count for all packages, the way you are solving that issue is the only i can think of too (besides making a copy of the ini file with settings A and keep the normal with settings B)
on the other side: you have to make your deployment package for your outside clients only 1 time and sent it and have the file itself on your software repository on the LAN.

3

I plan on sending the installer out to my employees 'cause for one, they’re not coming into the office any time soon. Secondly, they already have the old 4.8 installed and the new version will need to be installed over the old. For any new laptops we load, we’ll obviously load it up here before we send it out.

Yeah, my work around will have to do for now but others will run into this issue if they have groups using different AEA servers/addresses. The only way the client can pick up the correct AEA address (set in the group’s settings) is if you do the install locally and it has time to pull the settings from the AEA server prior to shipping the laptop out. If it isn’t able to pull those settings, there’s a chance the client would never connect to the AEA and would leave the client in the wild with a trial version or some other issue(s).