Video Screencast Help

Error connecting to an SEPM server in a fail-over configuration

Created: 05 Dec 2007 • Updated: 23 May 2010 | 1 comment

I'm trying to set up a new SEPM server so I can de-comission the existing one.

I've installed an new SEPM server to the original site.  It is using the same remote SQL database as the first server.

I can log onto the console of the new server and verify that it has been added to the Default Managment Server list.

I've created a new Managment Server List policy and created two priorties.

Priorty 1
Priority 2

I assign this new policy to all my clients.

The idea is that the clients get the updated policy and connect to NewSEPM since it has the highest priority.  I can then remove OldSEPM.

The problem that for some reason the new clients cannot connect to NewSEPM.  They always fail over to OldSEPM. I cannot find any reason for this.

This is a system log snippet from one of the clients:

12/5/2007 4:01:31 PM    Information    Connected to Symantec Endpoint Protection Manager   
12/5/2007 4:01:20 PM    Information    Disconnected from Symantec Endpoint Protection Manager.   
12/5/2007 4:01:18 PM    Information    Connected to Symantec Endpoint Protection Manager   
12/5/2007 4:01:14 PM    Information    Host Integrity check is disabled.   
12/5/2007 4:01:06 PM    Information    Symantec Management Client has been started.   
12/5/2007 4:01:06 PM    Information    Network Threat Protection ---- Engine  version : 11.0.980   
12/5/2007 4:00:59 PM    Information    Location has been changed to Default.   
12/5/2007 4:00:59 PM    Information    Network Threat Protection has been activated   
12/5/2007 4:00:59 PM    Information    Location has been changed to Default.   
12/5/2007 4:00:59 PM    Information    Stop serving as the Group Update Provider (proxy server)   
12/5/2007 4:00:26 PM    Information    Symantec Management Client is stopped.   
12/5/2007 4:00:23 PM    Information    Stopping Symantec Management Client....  

You can see it's trying to connect to NewSEPM but can't so fails over to OldSEPM.

This is the symlink.xml for that policy:
<?xml version="1.0" encoding="UTF-8"?>
<ServerSettings DomainId="DA7D7D61C0A8026F01C425435E18A7FC" NameSpace="rpc">
    <AgentCommunicationSetting AlwaysConnect="1" CommunicationMode="PUSH" DisableDownloadProfile="0" Kcs="6F5254E11A382E6AFE97284C006F78D7" PushHeartbeatSeconds="300" UploadCmdStateHeartbeatSeconds="300" UploadLearnedApp="1" UploadLogHeartbeatSeconds="300" UploadOpStateHeartbeatSeconds="300"/>
    <ServerList Name="New Managment Server Policy">
      <ServerPriorityBlock Name="Priority1">
        <Server Address="SEP2" HttpsVerifyCA="0" VerifySignatures="1"/>
        <Server Address="" HttpsVerifyCA="0" VerifySignatures="1"/>
      <ServerPriorityBlock Name="Priority2">
        <Server Address="SEP" HttpsVerifyCA="0" VerifySignatures="1"/>
        <Server Address="" HttpsVerifyCA="0" VerifySignatures="1"/>
    <LogSetting MaxLogRecords="100" SendingLogAllowed="1" UploadProcessLog="1" UploadRawLog="1" UploadSecurityLog="1" UploadSystemLog="1" UploadTrafficLog="1"/>

Really stumped here.  Is there anywhere I can turn on more detailed debugging logging that might actually tell me why the clients are failing to connect to the new server?

Comments 1 CommentJump to latest comment

Jay Scovill's picture

Just thought I'd post an update regarding this.

I contacted Symantec regarding this issue and they never were able to provide me with any explanation as to why this was happening.  I eventually solved the problem on my own.

I noticed that for some reason none of the policy directories from the ../data/agent/outbox directory were being replicated from the original server to the new server.  I mentioned this a few times to the rep I was working with but noone ever directly acknowledged this was at the very least a symptom of what was wrong.

I hesitated simply copying the directories over to the new server as I wanted to give Symantec a chance to discover the root cause of the issue rather than just bandaid-ing things by copying the directories.

After four days of no progress by Symantec I decided to move forward on my own and just copy over the directories.  My clients were then able to connect to the new server.

So it would appear, at least in my environment (this occured in two completely independent environments, one virtual and one physical), that there is something wrong with the policy replication from a Priorty 1 server to a Priorty 2 server in a fault-tolerant setup or between load-balanced servers assigned the same priority.

Message Edited by Jay Scovill on 12-20-2007 07:46 AM