Endpoint Protection

Hi All

We have SEPM on a central server with 15 remote sites, all running on an private WAN with different subnets at each site.  The goal is to have updates download tothe central server and feed out to the remote sites (no problems so far).  Reading the current forums, the best way to acheive this is using GUPs at each remote site (total users for all sites is under 500) and I can see the logic of that (I originally looked at replication, but that doesn't look to be the way to go).

From a configuration viewpoint, in what order do you complete the steps after the initial install on the central server?  I have a client package already created, although I can't seem to change the config of that to allow end users to manually update or (with the laptop users) allow external updates if outside the network (another question really, but please be kind and answer it too!).

I'd like to identify each site seperately, but really only need one install package and one set of policies for all of the sites.  There is a very good forum answer on creating and managing domains, so it is just a case of in what order to do things.  Remote sites will be managed by the same administrator.  Many of the computers have Endpoint Protection already installed, so really just need to be discovered and put in the right domain.

Thanks in Advance

Hi there, let's see if we can sort out a some basic configurations and step that would work for you.

If you're using GUP, I would recommend you use new SEP 11 RU5 release that just came out. This major GUP improvements.

Another option to explore is the LiveUpdate Administrator, or LUA. LUA comes on your CD 2. It basically acts as an internal Live Update server that you can point clients too.

With that in mind let me analyze your first question:
" I have a client package already created, although I can't seem to change the config..."
Most of the configuration options you are interested in will be in the Policies --> LiveUpdate --> LiveUpdate Settings area of the Manager. Here is where you can define most, if not all, your LiveUpdate and GUP settings. If you create a new policy under this section, or open the default policy, you can see under the policy's "Server Settings" tab there is an option called "Use a Group Update Provider", which is GUP. If you check this option the Group Update Provider button becomes enabled and you can set all your GUP related settings there. One important setting inside this GUP area is the "maximum times that clients try to download updates from GUP before trying the management server". If this is set to anything other than "Never", clients may download from the central server if there is a problem with your GUP clients.

If you are trying to configure this in a release before RU5, you may have to create a LiveUpdate policy for each site. The reason for this is the way you configure which clients become GUPs in previous releases was very limited. Using the new features of RU5 it is possible to make one LiveUpdate Policy that creates GUPs for many sites.

I'm sure that didn't answer the question completely, but hopefully you have more to work with now.

Now the next half of the question:
"...change the config of that to allow end users to manually update or (with the laptop users) allow external updates if outside the network "
The key words here are: allow manual/external updates if outside the network
There are two parts to this. Manual Updates, and Outside the network.
First, if you want to allow users to run Manual Updates, you have to enable 2 options inside the LiveUpdate Policy.
Inside the LiveUpdate Policy, under Server Settings, you have to turn on "Use a LiveUpdate server". Next, you move to the "Advanced Settings" tab, and check "Allow the user to manually launch LiveUpdate".

So now, how do you get this to work when a user is "outside" the network.
Any time you want a policy to change based on the users location, you have to add something called a policy location. To do this, go to the Manager and open the Clients Button on the left, then click the "Policies" tab in the top center.
Now if you look on the left side, there is a list of "Tasks". Click on Add Location.
This will launch a wizard that will guide you through setting up a location. You can also use the "Manage Locations" task to better manage the locations after as well.
When you make a location, you try to specify ways the computer can tell if it's in that location or not. A common condition people use is, "Client can connect to Management Server". If the client can connect, then you are "in the network", if the client cannot connect to the Manager, then you are on an "External" network. You can set many conditions including IP address range, Gateway address, DNS Servers, Network Connection type etc.
You simply need to explore until you find a set of criterias that works for you.

Now that you have two locations, and some conditions for them, you will notice that there are 2 sets of policies inside your group. This is because each location has their own set of policies. So if you want users to be able to manually run LiveUpdate when in the External network, but not the Internal network, you create 2 LiveUpdate Policies. One that allows manual updates, and one that does not.
Next, you assign the one that allows manual updates to the "External" location, and the one that does not to the "Internal" location.

So your next question,
"...need one install package and one set of policies for all of the sites"
If you are using RU5, it's possible to setup one policy that will work for most, if not all, of your sites. Before RU5, you would have to have seperate policies for each site.
If you are able to use RU5 and create one policy for all your sites, just export a client package using that policy and your good! But incase it gets a little more complicated here some other tips.
If a client is installed and able to communicate to the SEPM server, you can move the client into any group you want. When you move a client into a group it will use the policies specified for that group. This gives you the option of giving one client package to everyone with a 'generic' policy, and as the computers log in you can use the Manager to move them into the correct groups so they get the correct policies.
You also have the option of creating one client package per site that contains the correct policy for that site.

I'm sure you have lots and lots more questions, but I hope this post gives you a good step in the right direction. After you try out some of the steps I talked about you'll be able to ask more specific questions and get more specific answers.

Enjoy

Top 10 Symantec Best Practices - Deploying Symantec Endpoint Protection Architecture


http://service1.symantec.com/support/ent-security.nsf/docid/2009012721190648?Open&seg=ent


How to allow users to run LiveUpdate manually, as SEP clients' LiveUpdate button is grayed out on the SEP application

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008081811225948

Our setup is similar to that of G1m1k, a central site with 15-20 remote sites.  Our requirements are that the remote sites can't access the internet and the logs from the remote clients need to be sent back to the central site.

So, with those guidelines (especially the client logs) is there any alternative to using a SEPM at each site with replication of logs and LiveUpdate content?

The remote sites that you have can the connect to the main site ?
if yes you can install GUP at eacg site and the clienst will take update from the GUP and forward the logs to SEPM

Just to be clear, the GUP server will not proxy logs for the clients. It only proxies bandwidth-hungry contents. Logs are always sent directly from the SEP clients to the server.
For policy updates, you can use a channel other than SEPM server to SEP clients. There is a featured called "3rd-party" updates. Basically how this works is there is a folder on the client computers. You can take policy files that the SEPM server generates and drop them into the folder on the client using any method you like (SMS, Altiris, USB-flash drive, script file, etc).

But as far as I know, logs must always be sent from the client directly to the server -- but compared to AV Definitions, the logs are relatively small.