Video Screencast Help

SEP 11.0.7 with SEPM 12.1.2 Communication Update Package fails

Created: 19 May 2013 | 9 comments
GarethNZ's picture

Hi, we have a server running SEPM 11.0.6100.645, we had about 1200 SEP 11.0.7000.975 managed by the server. We have recently setup a new server running SEPM 12.1.2015.2015, I have used the client deployment wizard to update communication settings to point some SEP clients to the new server but not update the client version. I used Remote Push, Search Network\Find Computers, imported a list of 90 PCs, moved them over from "Available Computers to "Update communication settings on", put in my domain admin account, all PCs passed the "testing connection" test, clicked Next, then Send.
I then get the "Deploying Client Remotely" box, only 26 out of 70 succeeded, but I'm not sure why. The columns "Deployment Status" and "Communication Update" box have crosses in them. What troubleshooting can I do to figure out why this is failing for so many PCs?
Or is there a better way to do this? This way sounded easy, but should I be just replacing the sylink file instead?

If a client fails the "testing connection" test, I get this link for troubleshooting, those clients don't make it to the next step though (mine failed cos they were off).
Server OS = Server 2008 R2, client OS = Windows 7 with some SP1 (I've checked, the successful ones are a mix of SP1)


Comments 9 CommentsJump to latest comment

pete_4u2002's picture

have you checked the install log on the failed clients? have you restared the clients?

Rafeeq's picture

the location of Sylink is different in 11.7 and 12. thats why the deploy communication settings failed.

use this tool to replace the communication setting for 11.0.7 clients

sandra.g's picture

The Communication Update Package is designed to install on both 11.0.x and 12.1.x systems.


Symantec, Senior Information Developer
Enterprise Security, Mobility, and Management - Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best helps you!

GarethNZ's picture

On a PC that failed, c:\windows\temp\SEP_INST.LOG was not touched, I understand there might also be a log file in %temp%? Would SEP_INST.LOG go into the %temp% of the logged on user? I doubt this, but can't see a log file in there anyway. Also no SEP_INST.LOG in C:\ProgramData\Symantec\Symantec Endpoint Protection\Logs. Thanks.

SMLatCST's picture

The SEP_INST.log will only appear (or be updated) if the Client Deployment Wizard manages to push across the package and initiate a run on it (in which case the CDW will also give you a green tick for that system).  As the CDW is giving you a red cross for the systems in question, it normally means it failed to push the package across.

Essentially, the SEP_INST.log file is not applicable for anything with the red cross in the CDW because it won't have progressed far enough to generate this particular log file.

SMLatCST's picture

The below article details what to look for to get a client ready to "receive" the  communications package push attempt (you can get to this by clicking through a couple of the links in the communications package udpate article)

Generally speaking, the most common issues are:

  • firewall is blocing the connection
  • remote registry service is not started on the recipient/target endpoints
  • permissions
  • Admin$ is unavailable

As an aside, I've always found using SylinkDrop mroe reliable, as it is initiated by the endpoint and I tend to distribute it via script.  Much like the one below (which I've posted a few variations of, all over the forums wink):

If not exist %temp%\<newsylinkfile> (
Xcopy \\<NetworkLocation>\*.* %temp%
 “%temp%\SylinkDrop.exe” –silent %temp%\<newsylinkfile>)
FYI, This article assumes you;ve put the sylinkdrop tool and the new sylink communciations file in a share that can be read by all the endpoints.  I normally end up pushing this out via GPO, but it can work with whatever you have for pushing .bat files
GarethNZ's picture

Thanks all. I went through the process again and chose "Save package" instead of "Remote push", I then created a task in SMP to run SylinkDrop.exe (didn't work with -silent, but was silent anyway), the clients all updated to point to the new server. Still not sure why the Remote Push didn't work, we have the remote registy service set to manual start on all PCs, and $Admin is available, not sure about Firewall, but all PCs are the same, so odd that some worked fine.

SMLatCST's picture

Glad the ol' SylinkDrop worked for you!

As always, it's appreciated if you could mark any posts you find useful with a "Thumbs Up" or as the Solution wink