How to use Small Office Administration console with avast Endpoint Protection Suite Plus made easy!

I have written this document to make installations easier and save you time.  It is specific to avast! Endpoint Protection Suite Plus.  The following URL is a screen shot by screen shot complete walk through of the SOA installation. I highly recommend that you spend a few minutes to familiarize yourself with this process prior to SOA installation:

NOTE: The SOA console does NOT have to be installed on a server, and does not use conventional SQL (it uses an embedded SQL lite). Ours is running on a XP SP3 box (very light).  Verify that the target computer is not already running SQL. This situation requires creation of a new instance of SQL, and a custom installation to use the external SQL as your database. The Small Office Administration console is limited to 200 users using the embedded SQL, and can increase to 300 users if you use external SQL, such as SQL Express 2008 R2.

SOA console installer with mirror (clients update from console) –

SOA Quick Start Guide –

SOA User Manual –

Endpoint Protection Suite Plus Stand Alone Client –

SOA Administrator Guide –

Endpoint Protection FAQ –

Service Port Numbers

1. Please make sure the ports listed below are opened in the network on both the client and server side (you can use the GPO to dispatch on all machines, and make sure to reboot the machines for the changes to be applied).  avast! Small Office Administration uses the following ports:

Port for Console: 8731

Secure Port for Console: 8732

Port for Client: 25322

2. Install the Small Office Administration console (SOA) with mirror so that the clients will update their anti-virus from console:  Prerequisites include DotNet 4.0 and Microsoft Silverlight (these will be automatically installed during the SOA installation if needed).

3. Do a discovery task to find all the machines (this occurs automatically during the console install).  Create the necessary groups for each type of system (Workstation, Server, Sharepoint server, unmanaged, etc.) and move the discovered systems into their appropriate group. The unmanaged group is a place to move unmanaged systems and Active Directory ghosts out of the way.

4. Modify the components of the deployment package for the type of systems currently being deployed. Desktop, server, SharePoint or Exchange server. NOTE: There is only a single deployment package in SOA, so the components that are selected and “saved” is the current deployment package. 


For desktop installation, I recommend to remove all the server protection modules from the deployment components, so they are not installed on the client.

NOTE: When you are push deploying for a Domain, Enable the Admin Shares,  network discovery, and Microsoft File/Printer sharing must be ENABLED.  Below is our deployment package used for workstations:


File Servers

For servers, I will recommend to manually install all servers (custom install) so that you can be 100% in control of every step.  If there are too many servers to manually install, then you must modify the components of the deployment package and deploy.  In the console, under Admin, Settings, Components, create a light installation package for servers OS’s, which usually consists of the File System Shield only. This is usually the only real protection required for file servers and this is an industry standard best practice. This assumes that the File Server not being used as a workstation. NOTE: DO NOT use the Network Shield on servers.   SharePoint servers should add the SharePoint shield in addition to the File System Shield.  If servers are to be managed (see below), then each server type will require its own group, separate from the managed client group. If servers are NOT to be managed, then use the custom install feature to select the correct shield/shields for that server type. If the server will go online, then it is best to include the File System Shield, as well as the Web Shield, Behavioral Shield, and Script shield. Terminal Server protection is best tailored to the function of the clients. At one site, the users remotely access the SQL server, so here only File System Shield would be required. However, I have a site that uses thin clients.  All email and browsing are preformed through the Terminal Server. Proper protection will now include File System Shield, Mail Shield,  Web Shield, Behavioral Shield, and Script shield. You will also want to add the email server protection (exchange plug-in) to have avast! anti-virus protect the Exchange server Mail store.

Also, there are the avast! anti-spam plug-ins for Exchange and Outlook. I prefer the anti-spam at the Outlook level instead of the Exchange server level (both are included).  End users are truly the only ones that know what is solicited, and unsolicited email (spam).  This way users can look for themselves what they are not receiving, by the contents of their Junk Mail folder, and can adjust accordingly. Please see this article “How to properly use the avast! Anti-Spam Filter for Outlook”.    

Below is our File Server components:

5. Start to deploy by group of 10-20 machines at once, make sure to enable the “Reboot the machine” option in the deployment task settings (this is necessary to finalize the installation process). **Important** – Before sending out an installation please be sure the mirror is up to date which you can check by going to view tab in the console and check mirror status. Once it’s up to date then you can send out the installation. (NOTE: SOA can be installed with or without mirror). I have created a new Deployment job under JOBS, Scheduler.  NOTE: verify the correct domain is selected under “Domain” field drop down. Also, the “Username” field is really the domain/administrator: The screen below was from a workgroup, so the Domain field is not populated:

 6. After you send out an installation, all systems MUST be rebooted after deployment, so plan accordingly. If clients are not receiving the license file, look at the Group View to see if clients are attempting to contact the console, then “fix now”.   


You may push a deployment from the console for a domain. Workgroups will not deploy, so installs either occur from users or Administrators.


If using Active Directory you can easily create an installation package to push the client remotely through the network with Network Administrator password and in the Deploying Group. The Endpoint client will remove existing installation of avast! 4 only.  Any other avast! version or other anti-virus should be un-installed prior to Endpoint deployment.


If using a Workgroup you can only DEPLOY remotely (no push deployments from your console)  We recommend to create the installation package manually and send it via email to each client or install it separately via USB Flash disk to manually install it on each client. Once the client has been installed only then will it be detected in the Console.  The Endpoint client will remove existing installation of avast! 4 only.  Any other avast! version or other anti-virus should be un-installed prior to Endpoint deployment. The orange URL refers to the “managed.exe”.  This URL is used for Workgroup deployment, since you cannot push deploy:




J.R.  Guthrie                                      


Advantage Micro Corporation



“At this point in time, the Internet should be regarded as an Enemy Weapons System!”