Help - Search - Members
Full Version: Creating KAV Group
Kaspersky Lab Forum > English User Forum > Protection for Small and Medium Businesses
GaryCa
Hello, I am currently creating my folder structure for KAV on my network. We have 1 master site and an extra 5 sites. Would you recommend creating a site1 group on the master admin console and then 5 slave servers coming off that one group? Any suggestions or ideas would be great.
saladbowl
Hi

I cant speak for everyone but in our forest, it is simply the main (domain.com) OU i have with only our machines in it. For the other slave server sites, these are usually added under Administration Servers anyway and have their full expandable forest should you wish to manage. So for tidyness i Simply use the main OU for the Master Server and the Administration Servers group for the slaves. Keeps it less cluttered otherwise.

GaryCa
I was going to have the main site where most of the PC's are, the under that Administration server have all the slaves and put the other PC's from that site in the slave group. My query is where does the group know where to get the updates? for example PC's from site2 get updates from site2 and not site1.
phr3n1c
QUOTE(GaryCa @ 15.09.2009 17:49) *
I was going to have the main site where most of the PC's are, the under that Administration server have all the slaves and put the other PC's from that site in the slave group. My query is where does the group know where to get the updates? for example PC's from site2 get updates from site2 and not site1.

If the clients are connected to the 'slave'-Administration Kit, they'll get their updates from 'their' Administration Kit (slave) automatically. Please check with klnagchk-tool if the clients connect to the master or slave.
GaryCa
is there any documentation about this with screen shots. I'm really struggling with the concept.
Cheers All
Tybilly
Hello,

Citation (GaryCa @ 15.09.2009 15:29) *
Hello, I am currently creating my folder structure for KAV on my network. We have 1 master site and an extra 5 sites. Would you recommend creating a site1 group on the master admin console and then 5 slave servers coming off that one group? Any suggestions or ideas would be great.


It depends on the your network, what kind of connectivity (VPN, ADSL ...) & bandwidth there are between remote sites and the main site.
It also depends if remotes sites have a direct access to the Internet or if all network traffic go through the main site.

I usually advise to set up slave servers only if there are administrator on each remote site and if the main administrator want to delegate the installation and the administration of the Anti-Virus, keeping the possibility to gather statistics about the antivirus network and to push a global policy from the main site. Otherwise, it is better to use update agent.
GaryCa
QUOTE(Tybilly @ 25.09.2009 17:13) *
Hello,
It depends on the your network, what kind of connectivity (VPN, ADSL ...) & bandwidth there are between remote sites and the main site.
It also depends if remotes sites have a direct access to the Internet or if all network traffic go through the main site.

I usually advise to set up slave servers only if there are administrator on each remote site and if the main administrator want to delegate the installation and the administration of the Anti-Virus, keeping the possibility to gather statistics about the antivirus network and to push a global policy from the main site. Otherwise, it is better to use update agent.


I have one main site (where the admin console is), then 5 remote sites (by ADSL). If i don't use Slave admin consoles how do i create a location where each site grabs it's updates? I was only thinking that you can create this via a slave admin console.
Tybilly
Install your Administration Server on your main site. The most important thing is that your Administration Server should be reachable from outside your network through a DNS name or a static IP address.
Then in your Administration Console, create a logical group for each remote site and define a policy for each of them where the update source is what you want (e.g. KL Update servers or an update mirror)
GaryCa
QUOTE(Tybilly @ 25.09.2009 18:14) *
Install your Administration Server on your main site. The most important thing is that your Administration Server should be reachable from outside your network through a DNS name or a static IP address.
Then in your Administration Console, create a logical group for each remote site and define a policy for each of them where the update source is what you want (e.g. KL Update servers or an update mirror)


Thanks for your help Tybilly, apologies if i'm sounding a little silly.

I wish to create an update server on each site so that the network dosn't get hit too bad. Is this just going to be a case of creating an slave administation server at each site that only pulls down the updates?
GaryCa
QUOTE(GaryCa @ 28.09.2009 08:37) *
Thanks for your help Tybilly, apologies if i'm sounding a little silly.

I wish to create an update server on each site so that the network dosn't get hit too bad. Is this just going to be a case of creating an slave administation server at each site that only pulls down the updates?


Just to bump this up, any ideas anyone?
Tybilly
Citation (GaryCa @ 28.09.2009 09:37) *
Thanks for your help Tybilly, apologies if i'm sounding a little silly.

I wish to create an update server on each site so that the network dosn't get hit too bad. Is this just going to be a case of creating an slave administation server at each site that only pulls down the updates?


You can install an Administration Server on each site, but if there's no local administrator to use each console there's no point to do this. If you're just interested into local update mirror, then you'd better use the updater keeping the possibility to manage all your hosts from a central place (your main site) like I described before.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.