Endpoint Protection

Hello community , I am about to propose a solution to a customer . Before doing that I would like to have your expert opinion and suggestions on the following.

Existing Scenario

CITY A (Primary Data Center)

Site 1 = 1 SEPM with Embedded DB ( supporting 500-600 clients)
Site 2= 1 SEPM with embedded DB (Supporting 600-700 clients)
Site 3 = 1 SEPM with embedded DB (Supporting 100-200 clients)
Current version of SEPM is 12.1.3 and clients have SEP 12.1 - 12.1.3

CITY B

Site 1 = 1 SEPM with Embedded DB ( supporting 500-600 clients)
Site 2= 1 SEPM with embedded DB (Supporting 200-300 clients)
All Sites are independent of each other, i.e 1 SEPM= each site (Admin on each site), there is no Replication or Failover between the Sites nor centralized policy enforcement on all SEPMs

Proposed Solution

1. Install 2 SEPMs 12.1.6 MP2 at primary site i.e Site 1 and configure them in Failover/Load balancing mode. Configure 1 GUP at each site ( on the same machine where SEPM was running previously . Uninstall SEPM and install SEP client and enable it as a GUP for that particular site . Each Site = 1 Group

2. Point every endpoint located in all sites on both Cites to the SEPMs located in Primary DC with MSL (Management Server list configured for load balancing)

3. We can use a Communication update package remote push from the new SEPMs to the endpoints connecting to the old SEPMs in their respective region or we can generate a new package from the new SEPMs and then remote push it to the endpoints from the new SEPM so that all the endpoints can be pointed/connected to the new SEPM and then can be upgraded as well.

What do you say is this a right approach in the regard as migrating from Old ( Strange and not optimized) setup to this new ( Centrally manage setup) . Do you have any suggestions in this regard. I can easily point clients to the new SEPMs from the old setup.

Thanks

Overall it looks ok. Consolidation is the key as well having them configured for failover/LB. It will take some work to get this accmplished though. Are you doing anything with existing polices or writing new ones from scratch?

Policies at this point is not a major concern we will do the the customization but at the momment the default poilicies are good enough with minimal changes . The only major point of concern at this point is how smooth the clients transition will be from old SEPMs to the new SEPMs.

The process must be automated , meaning we only have the option to use remote push from the SEPM server either  

1) Remote pushing a communication update package to the endpoints to point them to the new SEPMs

2) Generate a new package and then push it to the endpoints from the new SEPM so that they can pointed to the new SEPMs and also they can be upgraded to the latest version.  No manual interventation can be used to point the clients to new SEPMs nor they have any third party software management solutions so things can only be done from the SEPM

I am assuming that the transition/re-pointing of endpoints to the new SEPM should be smooth as they are already running SEP , but I am not very sure how the things will eventually turn out regarding pointing endpoints to new SEPMs

Thanks 

Hi,

Thank you for posting your query in Symantec community.

I would be glad to assist you here.

Your approach sounds very accurate to me. Are you planning to upgrade existing one of the SEPM from site 1 or doing parallel installation of SEP 12.1 RU6 till all the clients get migrated?

If yes, you will have to push out fresh new package or communication update package to get them redirected.

When you will push out new package just make sure to reset client -server communication settings to allow clients to migrate over the new SEPM without any issue.

Screenshot is attached to the reference.

The biggest issue you'll run into is either the remote registry service is not enabled or Windows firewall is blocking communication. Ensure these are not the issue and make sure you have proper credentials to authenticate to the clients and you'll be fine.

Thanks for your valuable reply and feedback guys

@ Brian on clients SEP firewall is managing eveyrthing as windows firewall is disabled by SEP.

@ Chetan I will be building news SEPMs . Once new SEPMs are built I will point the existing clients to the new SEPMs either by deploying communication update package from the new SEPM to the endpoints or in the worst case scenerio I will be pushing a new installation package from the new SEPMs to the endpoints so that they can be updated to the latest version and pointed to the new SEPMs in a single go . However the only issue of concern with this approach is the bandwith utilization from the SEPM to the endpoints for remote push.

For remote sites, it's strongly not recommended to push out package over the WAN link .But as a workaround can run the push deployment wizard locally.

Refer this guide: Push Deployment Wizard - Standalone deployment app for SEP install packages

• http://www.symantec.com/docs/TECH195705

Second thing here since I will be replacing/Un-install the SEPMs that I have at the momment (exisitng setup ) in each site and then will configure those servers as a GUP Server so that they can server content to the endpoints.

Now If I enable the server to be a SEPM and GUP at the same time , I belive it won't be an issue or is it ? 

Becuase I can un-install the SEPM from a site ( present setup) once all the clients of that site are moved to the new SEPMs . Consider the below scenerio

Client 1 is reporting to Old SEPM in Site-1 ( I install a package exported from new SEPM install it on this SEPM machine it start reporting to the new SEPM server) . Now I also enable this SEP agent on the old SEP server to be a GUP server for the endpoints in Site-1 . Now the machine is running as both SEPM server ( as per the old setup ) and also as GUP ( as per the new setup) . So I believe the machine can exist in both role as a SEPM server and as a GUP machine . 

Once I get all the machines in site-1 pointed to the new SEPM , then I will Uninstall SEPM ( as per the old setup ) from this machine and it will work solely as GUP servers for all the endpoints in site-1

I will use this approach on all of the SEPM servers ( as per the old setup) till the clients are pointed to the new SEPM.

If you have any suggestions please do share. Thanks 

It's not recommended to use the SEPM as a GUP but if the GUP is pointing to the new SEPM you may be able to get away with it. Haven't tested it TBH.

Brian here is the thing , the server machine that is being used it will be a SEPM Server ( Old Setup) . The SEP client that I will be installation on the same server 2008 R2 machine will point it to the new SEPM server ( as per the new setup) so essentially the SEP client will be connected to the new SEPM so it will be a GUP ( as per the new setup) . so there shouldnt be an issue as far as I think.

I hope what I am trying to say here 

I also believe it should work as expected, SEP client should work as a GUP without any issue.
 

Yes, it should work without any problems.
 

your Plan looks solid to me and getting the clients migrated to the new SEPM will be your biggest challenge, if your prepared for it the rest should taken care of with out any issue.

Yes a SEPM and a GUP can co-exist to the GUP reports to your new SEPM there will not be any problem. the only concern here will be until the migration is completed on your old SEPM server it will have both the load of clients reporting to SEPM and the clients from new SEPM will be requesting for updates from the GUP. hope your server has enough juice to handle it

I would expect that it would be okay then.

Dear all . Can you please shed some light on the following

Push Deployment Wizard - Standalone deployment app for SEP install packages

http://www.symantec.com/docs/TECH195705

Does it mean in the remote site , from any one machine I can do the remote push from that machine and do the installation on the remaining machines part of the same site . By following this method I dont have to remote push packages located at the DC to endpoints in the remote site over the WAN . It can be done locally? Thanks 

I meant by Pushing from SEPM located at DC over the WAN to the endpoints in regions. It can be done locally within the site ?

That's correct. By this way you will be able to save unnecessary utilization of bandwidth.

yes, you copy the package to the remove site and the tool.

tool will just push the package, package will have all the info about your SEPM

thanks for your reply guys . Well that sounds a really good idea . Is there any pre-requisites for using this tool in terms of envoirement readiness or anything that I need to make sure is in place before using this tool

@ Chetan the link to document is no longer available . When I try to open it getting the following error

" There is no article that matches your request " can you please verify 

Hi,

You just need necessary rights to be able to push out packages on those machines.

However if faced any issue refer this guide: http://www.symantec.com/docs/HOWTO80805

I just re-checked previously shared article & is accessible, might be there was an issue. If still faced issue try from different browser.

http://www.symantec.com/docs/TECH195705

Thanks for your valuable replies everyone . 

Can you please confirm me one thing . Is it possible to export a communication update package from the new SEPM server when everything is configured i.e group hierarchy , MSL , GUP configuration and on the old Server we go to remote push and then select the option Update clients with the communication update package ( use the package exported from the new SEPM) and then deploy to the endpoints so that clients reporting to old SEPM starts reporting to the new SEPM gracefully.

Can it be done in this way? Thanks

There is no way to input the new sylink file. The old SEPM would simply use it's own sylink file.

It should just be simple enough to pushing from the new SEPM to clients, is that feasible.

You could manually replace the sylink file in the data >> outbox>>agent folder but this is all manual and not really recommended to mess with.