Endpoint Protection

SEPM version 11.06300.803

I have two servers that I wanted to migrate from one server to another. After speaking to support over multiple days, it was recommended that I do a replication instead of backup/restore of the database to the new server, then setup the management server list with different priorities to migrate the clients. Every step was done with them on the phone and over webex (they asked to) so there should be nothing weird that was done.

Now after 4 days after we setup the management server list with the new server being priority 1, some clients are not migrating. After digging around with support they are recommending that I manually stop SMC, and replace sylink, serdef, and serstate from a working client to all the ones that did not migrate. Since I have hundreds that have not migrated over and many are servers that I can't touch I asked for another way from the SEPM server. They are now recommending that I create a new install package and push it out. The problem is the clients are all different versions and the server can not be rebooted anytime I want. Some are 11.04 which is not even a direct upgrade.

I dug around some more and it seems that even though the client groups replicated, the SEPM-A (original) server has an older policy on the groups than SEPM-B (new). I manually replicated a couple of time, even including the logs, and the SEPM-A server still has an older different policy in the groups than the SEPM-B server. I'm not sure how that happened but both servers have the correct MSL setup and assigned to all the groups for the migration. It would seem to me that the SEPM-A server isn't getting or matching the policy that is somehow newer on SEPM-B. Is there a way to fix this issue?

SEPM-A Original server, older policy after replication

SEPM-B New server, different newer dated policy on groups

Some clients will not grab an updated policy and thus staying on SEPM-A even though MSL priority list is setup.

There is also an error message that comes up every 30 secs on the SEPM console that says an unexpected exception has occurred. I sent support some logs but I haven't heard if they are related.

Hey Mate,

Do I clearly understand that you have created a new site and changed the communication settings for existing client groups to use a new site (new server?).

If so:

1. When you are creating a new site, a new certificates are being generated for a new site. Clients have to update that certifica te to be able to start communicating with a new SEPM and a new Site.

The question is: what kind of the database do you use? Embedded or MSSQL?

If you use Embedded - I understand the reason behind creating a new site. If MSSQL - I don't :) If you use MSSQL, I would add new server to the same site (with no need for replication, new certificates and so on). Once all clients established communication with a new server, I would remove the first one (old one).

As far as the client-server communication is concerned, you may use the SylinkReplacer tool, to replace the sylink file of the new server on the clients which are still reporting to the old SEPM. Nothing can be done about the policies. They have to be re-created.

Or Retry the replication.

Hi,

How many clients are affected ? how many total clients do you have in your network ? So that we can come to know success ratio.

Could you please share support case number ?

Some ideas to check/try

On one or two clients that do not appear to be communicating with SEPM-B, have a look at their C:\Program Files\Symantec Antivirus\Sylink.xml file.  If the client has picked up the new Management Server List you should see two lines

<Server Address=SEPM-A.....>

<Server Address=SEPM-B.....>

Hopefully both servers are listed in that file. If not there is some kind of problem with those clients pulling new policy from SEPM-A and I would recommend using the SylinkMonitor tool to dig into client->server communication issues.

If both servers *are* listed in that file then you might consider powering down SEPM-A for a period of time.  I have seen clients "latch" on to a server and the only way to force them to failover was to shutdown the server.  Depending on how often you have your clients configured to heartbeat should guide you in how long you need to leave SEPM-A turned off.

Embedded DB

2400 clients, 100 or so not moving.

Just looked at one and Sylink does have the correct priority list. Since the original post, I've found the client cleanup command and ran it yesterday. It seems to have cleared up most of my issues. I now only see maybe 5 clients that are still pointing to the old server. I'm not sure if it was the fix.

http://127.0.0.1:9090/servlet/ConsoleServlet?ActionType=ConfigServer&action=CleanClients

Hi,

It's good to hear that issue is almost resolved.