Endpoint Protection

We currently have two different SEP servers (12.1.6 MP3, 2008R2) in their own sites and with their own (SEP) domains.  Replication is not set up between the two sites.  We are wanting to set up the server in Site A in a "Managed Service Provider" fashion, hosting the domains for both Site A and Site B, migrate the clients pointing to Site B to Site A for their management server (though still in their own domain), then retire the server for Site B.  Obviously, I can import the Site B domain into the server for Site A, and the domain will show up.  The next step(s) are what have me puzzled.

I had thought I would be able to set up site replication to get the database content over from Site B to Site A - the admin manual _implies_ this would work:

"You can also reconfigure a management server to replicate the data with a currently
existing site in your network. Or, if you have two non-replicating sites, you can
convert one of the sites into a site that replicates with the second site."

Apparently this is "poor wording", since in practice it will overwrite the existing database of the server you reconfigure and there is no way to "merge" the records in order to keep / preserve current client data and have replication to the other site.

But if I just have domain B imported on site A and set up Server A in the Management List for site B, will the clients even be able to check in to Server A properly?  If so, wouldn't the client data be "out of sync" between the two servers?

If you want Server A to provide management for all SEP clients, then you're going to have to change the commnucations files on all SEP client still managed by Server B.

These links should be of some help:

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

https://www.symantec.com/connect/forums/sep-1107-sepm-1212-communication-update-package-fails

https://www.symantec.com/connect/forums/how-change-sylink-client-using-snac-1215

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

The reason for this is that, even if you do create a new SEP Domain on Server A that has the same Domain ID, Server A still won't recognise the certificate used by Server B's clients.  This is why you need to replace their comms files.

I'd recommend:

1. Create new SEP Domain on Server A (doesn't matter if it's Domain ID matches that of Server B or not)
2. Populate and configure new SEP Domain as you see fit
3. Export new sylink file (comms file) from new SEP Domain on Server A
4. Import comms file into exist Server B clients

A few notes:

• You will lose the logs and all historical data from Server B
• You can export policies from Server B and import them into the new SEP Domain on Server A
• Server A has no records of Server B's clients, so you will need to assign them to the appropriate groups again
• After everything is moved across, only then can you reinstall Server B anew and make it a Replication partner of Server A (doing so beforehand will orphan some clients)

"Server A still won't recognise the certificate used by Server B's clients"

We aren't using encrypted communication for the clients, just 443 for connections.  However, the Domain IDs don't match when doing an export (from Site B) / import (to Site A), so it amounts to the same thing.

Thanks for taking the time to make such a clear and concise post.

Even without HTTPS encrypted comms, certain portions of SEP traffic is still encrypted.  This is managed by the "Enable secure communications between the management server and clients by using digital certificates for authentication" option in the Security Settings for every group, and is enabled by default.  This is why the comms file contains a cert.

Oh, and happy to help! 

Right, what I was saying is we have "Enable secure communications between the management server and clients by using digital certificates for authentication" _disabled_ and are using 443 communication only to "secure" the client communications.

When I was "labbing" it, I managed to import the domain and preserve the domain ID somehow, but couldn't replicate it in a "production" environment without the high likelihood of breaking something.  And even if the domain ID did match, the client information would be out of sync, and the policies would become out of sync on any changes to them.  So, not an option, and your marked solution is the only feasible route.

Thanks again.