Endpoint Protection

Hi, I made a post about this almost a year ago, with the same question really: https://www.symantec.com/connect/forums/moving-managed-clients-another-site We are consolidation multiple sepm instances to one site with two managers and multiple gup's. I did a few tests with the 'Communication Update Package Deployment' with remote push, this worked on a server, but didn't on a few clients. I found out this needs Remote Registry enabled. But looking on the client after a succesfull push ... it is still on the old management server. I also did a few tests with the 'Communication Update Package Deployment' with save package, this also didn't work on those clients. Even importing the sylink.xml through the GUI didn't work... Only a client without a password set seemed to work with the saved package. We are running on 12.1.6 MP5 and most clients are also on these versions. We have tamper protection disabled for the test. I would like some help with what is going wrong...

Disabling tamper protection shouldn't matter. What version are those older clients on?
 

Are all the SEPM's on the same version? 

If so set them all up as replication partners (Admin > Servers > add replication partner)

Once they are all communicating with each other simply update the Management server list to point them at the SEPM you want as the main (Policies > expand Policy Components > Management server list) 

Set the SEPM you want them all to check in as the Priority 1 machine and put the others as a lower priority just in case they have any communication issues with the main they can still check into the old SEPM. Then click ok and wait for all the machines to start checking in and picking up the new management policy. 

Variating quite much with 12.1.4013, 12.1.4112, 12.1.5337, 12.1.6168, 12.1.6608, 12.1.6860 and offcourse the latest 12.1.7004

But we also got a few 11.x clients which I don't have access to.

All lower versions then 12.1.6608 are less then 10 per version.

 

Disabling Tamper Protection was suggested a few times on the forums here, but I'll happily enable it again :)

All SEPM's are on the same version, didn't know you could replicate multiple sites with eachother without loosing there own site/clients. Does this work with the following? SEPM1 and SEPM2 are already replication partners SEPM3 and SEPM4 are already replication partners SEPM5 SEPM6 SEPM7 and SEPM8 share one DB and site (these are the new servers) If this would work, how should I work this out ... add on every SEPM server the SEPM7 and SEPM8 servers as replication partner? Wouldn't this break my new policies created on the new servers?

Yes you can have multiple SEPM replication and replicate the group structure from the SEPM;'s you no longer need to the main SEPM. See below article.

https://support.symantec.com/en_US/article.TECH184455.html

You can either do it 1 SEPM at a time if you want to do it in a crontrolled manor or you can add multiple SEPM's but harder to track if there's an issue if you do multiple SEPM approach. 

How Replication Works
https://support.symantec.com/en_US/article.HOWTO81035.html

When I run the Management Server Configuration Wizard...

Warning: Reconfiguring this management server overwrites the existing management server settings and database settings for this site. To avoid overwriting these settings, you can install a new site and management server on a different computer.

How I read this ... you lose everything! And startover with the config of the replicated server ... correct me if I'm wrong.

yes, first one will overwrite the other..It will be one DB for 2 SEPMs

But they all have different clients and configs ... we want to consolidate not make them unmanaged.

Then replication is totaly not an option ... like I thought already

It won't make them unmanaged it will consolidate everything into one database with group structure and settings copied over to the machine you are making the main central SEPM.

If you have a lab or test SEPM you can test it on there to make sure it works as expected before you carry out this on your live environment. But it won't delete any settings already setup it will just consolidate them to the single SEPM depending on the settings you check on replication. 

Well ... luckely I tested this ... cause I lost everything on my test server 2.

test server 1 and 2 where 2 different sites with both 2 clients, after I used the Configuration Wizard on test server 2 to replicate with server 1 ... I had only 2 clients in my site, with only the groups and policies from test server 1.

Please point out what I did wrong GeoGeo.

Do not perform replication, it's not an option in your case. As you stated earlier you will loose database and configuration of that SEPM.

Total how many SEPM's are there? Total how many clients are connected per SEPM? 

 

We got 5000 clients spread over 6 SEPM, which where previously all maintained by other people. The biggest one is 2800, another has 1100 and then a few smaller ones.

 

About replacing the sylink file, I could test that, but that is offcourse no option for all clients. [edit] replacing works! [/edit]

About the replication ... then why is it even suggested ... I wasted a morning testing it.

So to sum it all up:

• Running SylinkDrop.exe from the SepCommunicationUpdater.zip doesn't work
• Running SylinkDrop.exe -silent -p P@$$w0rd sylink.xml doesn't work either.
• Importing Communication Settings with the sylink.xml doesn't work either.
• Replacing sylink.xml manually after stopping SEP with smc -stop does work!

After unsetting the 'require a password for stopping the client service' within the policies:

• Running SylinkDrop.exe from the SepCommunicationUpdater.zip does work!

 

Hello,

You want to keep the biggest one which has 2800 & 1100 clients respectively? Or planning to move those clients on another SEPM?

When you will move other site clients to dedicated SEPM's on main site it may impact bandwidth utliziation at some extent. Just make sure bandwidth won't be any issue.

 

We want to move to two new SEPM servers, new database and with the usage of GUP's.

GUP's have already been tested and are working perfectly, just SylinkDrop isn't doing it's job.

We already got a script laying around that will check if the client is on the new server, if not ... running sylinkdrop.exe

Thanks for the update & If bandwidth is not a big concern can push out a fresh new package also.

Dunno, but I think you misunderstood ... SylinkDrop isn't working yet.

Just that we have everything sorted except that last step, moving all the clients to the new manager.

I think I fixed the issue my self ... it had something to do with the locations.

I compared everything between the clients and servers, the only thing I hadn't tested where the 'Managed locations'.

Making these the same fixed the issue it seems ... will update this topic when I find more exact information.