Video Screencast Help

Replication partner did not take over as priority 1 SEPM server

Created: 29 Apr 2013 • Updated: 10 May 2013 | 22 comments
This issue has been solved. See solution.

I am a little confused as to why this did not work as expected. I have two 12.1.2015.2015 SEPM servers running on Windows 2008 R2. All of my clients were reporting to one machine which is in our DR location. I wanted to move all clients to the SEPM Server running in our Production environment. The SEPM Server running in our DR site was built first then I created the second server in our Production environment and added it as an additional site and created replication between the two servers. To move all clients over to the second server (production environment) I made that server Priority 1 on my MSL. I then let about a week go by and a number of replication occurances. Then, this past Friday evening, I stopped the SEPM service and the Embedded Database service on the SEPM server than all clients were currently reporting to. When I checked on the status of the second server this morning I expected to see all clients now reporting there. This was not the case. All clients on the second machine were showing as Online on the Remote server. When I checked that server all clients were showing as offline. I started the SEPM and Embedded database services back up but still nothing is reporting to the orginial server. All clients are now in limbo. Shouldn't all of my clients started reporting to the second server? The I made Priority 1 in my MSL. I followed this procedure below but it didn't work and now I have all of my clients showing as offline. How do I get things back to the way they were before I tried to initiate the failover?

Thank you.

This is the article I followed to move all clients to the other machine: http://www.symantec.com/business/support/index?page=content&id=TECH104389&profileURL=https%3A%2F%2Fsymaccount-profile.symantec.com%2FSSO%2Findex.jsp%3FssoID%3D1360096189165o7332jvX5mD2iNAby0N749pY17qMJePAbk4NW

Operating Systems:

Comments 22 CommentsJump to latest comment

.Brian's picture

Did you verify the MSL is correctly applied to the group(s)?

Assigning a management server list to a group and location

Article:HOWTO80735  |  Created: 2012-10-24  |  Updated: 2013-01-30  |  Article URL http://www.symantec.com/docs/HOWTO80735

 

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Berino's picture

Hi,

Make sure that you assigned the MSL from the SEPM in which the clients were already reporting to caus thats where the clients would take the policy update from.

Inorder to confirm whether the same has been implemented on the client end open the "Sylink.xml" file in the client and check whether the Priority change is reflecting in the sylink file.

This would be a more authentic way of confirming the change rather than looking at the green dot in the clients tab in the SEPM.

Hope you have Priority 2 as your old server cause that would give the clients a fall back option if the priority 1 is not up.

If all doors are closed then run the sylink monitor log on a client which is in limbo and post it here for us to have a look.

Berino's picture

How to enable Sylink debugging for the Symantec Endpoint Protection 11.x and 12.1 client in the Windows Registry

 

Article:TECH104758  |  Created: 2008-01-18  |  Updated: 2013-02-26  |  Article URL http://www.symantec.com/docs/TECH104758

 

spasq's picture

Thanks all. I should have mentioned in my original post that I did assign the MSL to all of the groups and when I noticed this issue on Monday I checked the sylink.xml file on a number of clients and it looks like the original server is still listed as Priority 1. So, that would explain why my clients did not move over to the other server but I would think that once I restarted services on the original server all of the clients would start reporting to it again. I will enable sylink debugging on one of the clients and post the results.

.Brian's picture

Do post it here if you can. It should give all the info needed to troubleshoot.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

spasq's picture

sylink.log is attached. This is from my machine.

AttachmentSize
sylink.txt 121.21 KB
.Brian's picture

Thanks, will check it out. I forgot to ask but replication between the two has been working? No errors at all?

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

spasq's picture

Ok, so it looks like I got everything working now. I restored a backup of my database from earlier in the day I tried to move all the clients over and everything is reporting back to the original server now. I'm not really sure why that fixed this issue but I did read something about doing that so I gave it a try.

Now, why are the changes I made to my MSL not reflicting in client's sylink.xml files? 

A. Wesker's picture

Hi,

If you did follow carefully the procedure mentioned on the TechNote you talked about, you must create the new MSL only on the new SEPM, assign it to all your OUs and then perform replication loops and wait that all your clients contacted your main SEPM in order to retrieve these modifications.

That's why we recommend to let run the both SEPM for a period of time as you don't know if 100% of your clients will be online on daily basis as you may have some users of holidays, etc so the clients which are offline during this period will never know the existance of your second SEPM.

In the worst situation, if you still have a few quantity of clients that were offline during all that time, you can still deploy the sylink.xml file from your SEPM of Production to your clients with a MSL that will contain only one SEPM (your SEPM of Production).

Beware of not creating MSL on the both SEPM and reverse priority, otherwise it could provoke some unexpected behavior such as the client do not know where to go and swap to both Management Server all the time.

When your clients try to connect to your SEPM of Production, they're kicked out.

On your Sylink, return code HTTP Code 503 Service not available and even HTTP code 400 Bad Request. Make sure you dont have firewall activated on your second SEPM on Domain, Public, Private Network as it might result this type of result.

No migration done before using SEP 12.1 RU2 ? If you were on SEPM 11.X before, ensure you remove IIS cause known issue if it's still present, it could result HTTP return code 503

Perform a check of the SEPM certificate as well cause it can come from there as well.

Articles that may help.

=> http://www.symantec.com/business/support/index?page=content&id=TECH103158

=> http://www.symantec.com/business/support/index?page=content&id=TECH174761

=> http://www.symantec.com/business/support/index?page=content&id=TECH185333

 

Kind Regards,

A. Wesker

SOLUTION
spasq's picture

Thanks for this info. I can tell you that I did NOT create the MSL properly. I created it on both boxes. I am guessing that is why I ran into an issue. I created a new MSL on the second server, assigned it to all groups and deleted the old MSL. I will let replication do its thing for a few days then will check the sylink.xml file on some clients to see if they got the change in priorities. Thanks!

spasq's picture

I corrected the mistake I originally made with the MSL by removing it and recreating it on the new SEPM server..making that server priority 1 and then allowing several replication cycles to complete causing that MSL to be created on the original SEPM server. I have been checking clients over the past couple  of days and they still have not received the new MSL. I'm not really sure what I am doing wrong.

Berino's picture

Please follow this logic,

The clients are reporting to the Old SEPM

Create an MSL in the Old SEPM like this,

Priority 1: New SEPM

Priority 2: Old SEPM

This would mean that all your clients will be asked to report to the New SEPM and will still have a fall back option to reach the Old SEPM if need be

Check the Sylink file to confirm the same.

Create an MSL in the New SEPM like this,

Priority 1: New SEPM

This would mean all the clients that reach the New SEPM would follow the New MSL and will update their Sylink files with just the one Priority ie the New SEPM. This will mean the clients will eventually stop reporting to the Old Server.

Once you confirm the same then you can Turn Down your Old SEPM and let it RIP.

spasq's picture

I corrected the mistake I originally made with the MSL by removing it and recreating it on the new SEPM server..making that server priority 1 and then allowing several replication cycles to complete causing that MSL to be created on the original SEPM server. I have been checking clients over the past couple  of days and they still have not received the new MSL. I'm not really sure what I am doing wrong.

SebastianZ's picture

Can you confirm if the clients have indeed received the latest policy from SEPM according to policy serial number?

Berino's picture

Create an MSL in the Old SEPM like this,

Priority 1: New SEPM

Priority 2: Old SEPM

This would mean that all your clients will be asked to report to the New SEPM and will still have a fall back option to reach the Old SEPM if need be

Berino's picture

Step 2: Create an MSL in the New SEPM like this,

Priority 1: New SEPM

This would mean all the clients that reach the New SEPM would follow the New MSL and will update their Sylink files with just the one Priority ie the New SEPM. This will mean the clients will eventually stop reporting to the Old Server.

Once you confirm the same then you can Turn Down your Old SEPM and let it RIP.

spasq's picture

I see the new MSL on my clients now. This was after creating it on the new server and letting replication do its thing.