Endpoint Protection

Currently we are running SAV 10.1.5.5000 with a primary server and secondary servers in our remote offices where local remote office clients connect to the secondary servers for their updates and such.

I want to upgrade to SEP, I have a SEP server in place in our main office installed on a separate machine. I want to use the GUP option in the remote offices so the remote office clients can get their updates. I don't want to upgrade all the clients in a remote office at once. If I upgrade to SEP on the current secondary server, is it still going to provide definition updates to the existing SAV clients?

What alternative do I have?

Thank You

Read this KB for migration from SAV.

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

I've read that, but I don't think it addresses my specific question?
My question is if I upgrade SAV to SEP on a secondary server and made it a GUP, will it still provide definition updates to SAV clients?

it won't upgrade SAV clients, consider using LiveUpdate Administrator

 for migration SAV to SEP,
go through this link.....
http://www.exitcertified.com/symantec-training/migration-symantec-endpoint-protection-11-x-EP-MIGRATION.html
hope its help you..

If you're going to remove the SAV server when installing SEP. I suggest to set all the clients to get their updates from the Internet first. Then set-up the servers before going to the clients.

You might have problems in installing to unmanaged clients.

If you upgrade the Secondary server to SEP, then you would have effectively lose management of all the clients that the Secondary server was managing\distributing definitions to. If you decide to go that route, you might want to point the clients back to the central server prior to the upgrade just to maintain manageability and easing your migration down the line. The hierarchy and server placement in SEP have changed greatly, and I would suggest revisiting your migration plan to see what roles are necessary. LUA is definitey a good alternative. GUP can be assigned to a standard client without a server install, so if you upgrade one of the clients to SEP (assuming you have all the groups/locations/policies already set up), then you can service the rest of the SEP clients at that location with that GUP once you upgrade them. One thing to keep in mind is that the policies always come from the management server regardless of the LUA or GUP at the location. The default "PUSH" communication setting with SEP should only be used on local campuses or it could potentially saturate your WAN link.

Thanks for your reply CKT,

I wouldn't mind making a local client a GUP, but these clients are all XP machines. I have posted on this forum before and never got a good response that says how an XP machine would be able to handle about 250 clients. I think I'll move these remote clients to the primary server and let the clients get the definitions from the primary server temporarily. Once the Secondary server (F&P server) gets upgraded to SEP, I'll make a liveupdate policy change.


Another related question:

Why is that the liveupdate policy that I create pointing to a GUP has to be applied to the GUP server also?
Ideally I would like all my F&P servers (GUP's) Grouped into one group in SEPM.
but it looks like to I have to create a separate group for each server for it function as a GUP.

If you want to group your GUPs in one group then do that and in the LU policy for them as a GUP type in 'localhost'.
This way all of them will act as a GUP and you may assign the policy pointing to any of them to toher groups.

Well, keep in mind that the SEP client is able to belong to only one group. The policy has to apply to the GUP as well because the GUP has to be part of that group in order to serve the clients in that group. So, it won't be possible to add all the GUP's to one group as there can be only one GUP per group. Actually, let me correct myself, one GUP per group per location. So, if you really want to, you would have to break that one group down to their locations with a distinct LiveUpdate policy for each location. Then, you would be able to include all the GUP's in one group. The caveat is, the rest of the client base would also have to belong to that group as well. In this design, you would lose the flexibility of having different groups. Might or might not work for you. That's a design decision. Typically, I filter the groups into server and workstations and then below that the individual apps or other collections that require group settings. Then I would filter using location-based policies with the groups. I find that to have more flexibility than a traditional flat group design. Again, more of a design issue.

As far as GUP on XP, I don't see too much of an issue, except that you have to keep in mind that XP can only support 10 client connections at a time. To handle 250 clients, you'll have to adjust the randomization to a pretty high number. My experience with the randomization in previous versions of SAV were not pleasant, though I haven't had any issues yet with SEP. Can't say I recommend it though. For 250 clients, I would definitely look into the LiveUpdate Administrator. For SEP, you don't really need secondary servers. So, I would remove all SAV/SCS related installations on the Secondary server, install a regular SEP client on it, and then install the LiveUpdate Administrator. Then, instead of using GUP in the LU policy, you would specify the LUA server for that group/location. The thing I don't like about the LUA approach is that there is no centralized configuration for them. Each LUA server you spin up have to be managed and configured individually. LUA also have a tendency of corrupting itself. In my period of 6 month testing, I had to repair/remove the software 3 times. There's also no monitoring for that, so you'll have to custom build scripts to make sure that the service is healthy.

That's an interesting configuration you have. Does it work?

Thanks CKT.

pbogu,

Interesting concept. I'm going to try it.

So basically I will have 1 liveupdate policy for my F&P servers/ GUP's.

Then for the each of the district office locations/groups, I will have individual liveupdate policies that list the particular F&P server hostname.

Sounds abour rite?

@CKT yes it works
@bjohn exactly

The thing is that the machine will check what should be GUP and lkocalhost will always resolv to the same machine so it will start serving as GUP.
After starting to act as GUP machine is not checking who is contacting it just serves the content for whoever contacts it.
You can easily test it if you want, just change the policy and check client logs on the machine - it should say starting working as GUP (or something along those lines).

Btw. If you consider using GUPs in large environment then be aware that GUP settings are not inherited even if you have inheritance on and LU policy for main group is set to use GUP. you will need to turn off inheritance and assign the same policy to subgroups.

Hi All,

This solution worked fine for me on MR4 MP2 but since upgrading to RU5 my clients that use GUP's no longer get virus def updates.

Can anyone help with this and suggest ways on how GUP's should be configured now?

Mine still works this way after upgrading to RU5. I only upgraded SEPM and not the clients, but don't think that should make any difference.

Hi bjohn,

I have upgraded both the clients and the SEPM server, on the liveupdate policy for the client PC's it would not let me use the FQDN, it threw up an error about too many characters, no commas etc. (e.g. CONTOSO.MICROSOFT.COM) so I have entered the IP address of the GUP for each group.