Client to SEPM communication issues after upgrade TO SEP 12.1

[Migration User]

About 7-8% of my SEP 12.1 clients in a nationwide corporate WAN are not able to communicate with the SEPM after upgrading from SEP 11.xx.  The common element among the problem clients is they are running Windows XP SP3. Be aware that many Windows XP SP3 clients that were upgraded have no problem communicating with the SEPM. No Windows 7 clients have been seen to exhibit this problem.  

Best practices for the upgrade were all followed as per the published support article TECH163602. The error on the client is seen as a 'Winint error -9'. Settings at the group level are the default of "Group-Push" for Location-specific settings/communication settings.  There is no firewall interference, there are no proxy servers.   Using Sylink drop and Sylink replacer makes no difference.  Wireshark captures show when policy update is requested from the client, the client does not attempt to communicate with the SEPM. Running clean wipe and reinstalling SEP 12.1 on the client does not resolve the issue.  Testing with an exported installation file with managed settings embedded in the file - or installing the client as unmanaged, then attempting to convert it to managed with a sylink.xml file - or pushing out the install over the WAN with a new install package ---- all yield the same failures in communication between the client and SEPM.

However if I install SEP 11.xx on the same problem client, it has no problem communicating with the SEPM.  Has anyone experienced this kind of issue?  And if so, what was done to resolve it? 

[Migration User]

By any chance, are any of these machines clones or ghosted machines?

* * * *

If you can remote into one of the problem machines, look for the service - Symantec Management Client - it is usually set to manual.

Try starting it manually or try setting it to automatic.

[Migration User]

Yes, that is a basic thing to check, and I did not mention that in my post.  The Symantec Management Client service is always in the started state for these problem clients. All Symantec services are functioning normally for these problem clients. My issue that I posted has been a problem for the last two months or longer, and I have exhaused all basic troubleshooting and every Symantec support article I could find.  But, feel free to bring up anything. It's always good to have another set of eyes.

[pete]

just in case if you have not gone through this article

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

[Migration User]

Try to export new communication settings and do manual sylink replace. 

[Migration User]

 

 

Try doing these steps:

- From the Endpoint Protection Manager, right click the group which includes the problematic client, then choose export communication settings.

- Rename the exported file as Sylink.xml

- Go to the installation path of the problematic client and replace the sylink there.

- Run update policy to the client.

- Reboot the client.

[Migration User]

Actually I have gone through that article.  Thanks, though.

[Migration User]

I have already tried that and it did not solve the problem

[Migration User]

I have done that also, and it did not solve the problem

[Migration User]

1. On the client computer, open a Web browser, such as Internet Explorer.
2. In the browser command line, type the following command:
   http://management_server_address:8014/secars/secars.dll?hello,secars
   where management_server_address is the management server's DNS name, NetBios name, or IP address. When the Web page appears, look for one of the following results: If the word OK appears, the client computer should be able to connect to the management server--check the client for a problem. If the word OK does not appear, the client computer cannot connect to the management server--the problem is likely at the server's end

Also try the following Article

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

check the section and try the steps.

Enabling and viewing the Access log to check whether the client connects to the management server

Also try running sylink monitor tool on the client which  ha steh issue.

Download it from
http://www.symantec.com/business/support/index?page=content&id=TECH103369

You can use the Windows registry to turn on debugging in the client:
HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\smc_debuglog_on
 

then stop and start smc service.Then start sylink monitor tool and save the log after 10-15 minutes.

upload the logs.

[Migration User]

Thank you for the response. I have already followed all you point out above as part of my ongoing troubleshooting and investigation.  The client can connect in a browser using this format: http://management_server_address:8014/secars/secars.dll?hello,secars . As an earlier response from another person on this forum, I have already followed all steps in the tech article TECH160964.  I have setup Sylink logging on more than one problem client, and submitted sylink logs more than once to Symantec support.  I do have an open case.  They are unable to find a solution as to this date.  It has been about two months since the case was opened with Symantec support. 

I have posted my issue here hoping the Symantec community may have seen this issue and may offer a resolution. 

Considering that all proper procedures were followed when I upgraded my SEPM and clients from SEP11.0.6 to SEP 12.1; and there are no server issues; that the only clients affected are Windows XP Service Pack 3 ( at this time about 15% of all my XP SP 3 clients); and the clients that cannot communicate with the SEPM have no other issues of any kind; I am starting to come to the conclusion the problem here is most likely one that can only be prevented in the future by Symantec developers making some changes in SEP 12.1 as to how it handles files needed for the upgrade that should exist on the client computers, as to file state and version, and how remediation is handled concerning those files when necessary paramaters are not present.  I know this is a broad generalization, but I speak at this point on a conceptual basis, not a precise techincality of the subject. 

Please realise that my problem clients have problems communicating with the SEPM, ONLY, and I repeat "ONLY",  if they have SEP 12.1 installed that was installed as an upgrade. "Fresh" installs of SEP 12.1 on "fresh" installs of Win XP SP3, have not been a problem at all.  If SEP 12.1 is uninstalled from these problem clients and replaced with SEP 11.0.6.x, communication works just fine between these clients and the SEPM. This last statement in the context of what I have related here, should speak volumes to developers..... or so it appears to me.

If this case can remain on this forum long enough, others may well come forward with this same problem with communication issues after an upgrade from SEP 11.xx  Only an attentive Symantec admin can even notice this client to SEPM communication issue as it is not an obvious one. It is not observed on the client end by users. It is not obvious in my environment in the SEPM or via SEPM reporting.  In my enviroment I have about 75% laptop users who travel, so seeing an "offline" status in the SEPM is not unusual. Receiving a report that the SEPM has not communicated with a particular client for "X" number of days or weeks in not unusual in my environment.   So, the communication issue I have reported here was only discovered by an exhaustive audit of my environment in August of this year.

Please keep the feedback coming.

Thanks again for your response.

[Migration User]

Hello IT Monkey Boy,

there is another similar case recently arose in the company I work for. The only difference here, is that clients  reports status "File System Auto-protect is mail functioning"  and can't update content form SEPM server. Pushing content updates from server's console goes fine, but after few days story repeats.  Repair of SEP as well as clean wiping and re installation solves the problem till reboot. So I would like to ask You if any solution was found and implemented in Your company or probably Symantec Support offered some solution for the problem?  Many thanks for Your reply in advance....