Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Several SEP 12.1 GUPs getting "no connection to SMC service error"

Created: 20 Sep 2012 • Updated: 27 Dec 2012 | 16 comments
This issue has been solved. See solution.

Over the last several weeks I have had an increasing number of site complaining that their endpoints are out of date at their site.  We use AD structure to assign policy to all locations.  Some 144 GUPs of which 10 confirmed are having the issue, but the SEP Monitor tool says 40 GUPs are out of date.

I have been working with support and the current suggestion of disabling the sysplant driver does not appear to be working as I am still seeing the issue on a few of the GUPs I have been working with directly. 

I am currently testing the replacement of the serdef.dat file on one of the servers, but that has only been since last night, but so far it has remained online.

I know in searching the forums assistance has been limited, but the issue does not seem new.  I guess what I am not understanding is why do some systems function without issue, but these several keep experiencing the SMC crash.  I then begin to wonder if it is only my GUPs or could be more wide spread to normal endpoints.  So far I have not been able to easily investigate other systems, so the GUPs remain the obvious because of what happens when they are not running and endpoints go out of date.

Any thoughts or assistance would be greatly appreciated since I have support scratiching their heads.  I will continue to work things from that angle as well, but thought it may also help to take the issue to the community for more ideas.

Thanks

Comments 16 CommentsJump to latest comment

.Brian's picture

What components do you have installed on the machines having the issue?

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.

.Brian's picture

I'd be curious to see what would happen if you removed everything except AV.

I had the same issue (12.1 RU1) and once I removed everything except AV, it went away and I haven't seen it since.

My guess would be it has something to do with NTP, most likely as support already seems to think the sysplant driver. The application and device control component has also caused us some grief and since removing that, issues stopped.

I assume these are servers?

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.

smakovits's picture

yes they are.

With 11, we only ran AV on servers.  No FW and PTP was not supported on server OS.  However, with the move to 12.1 there was initiative to lock things down, therefore, this meant PTP and FW will be installed across the board on all systems.

My biggest issue is that this is not all GUPs or systems for that matter.  Instead, it is something that just recently crept up.  My opinion of removing the components is that it is a band-aid not a fix.  There is no reason in my eyes that it should work on majority, but not some.  Obviously it is a a matter of opinion and often people will say you dont want those components installed on servers anyway, but it was a recent initiative to secure systems across the board, even servers.

.Brian's picture

Couldn't agree more. However we had to many headaches and complaints from admins with the FW and PTP component, so we had to remove.

PTP and NTP can certainly be installed on servers but more time and care is needed to perfect it. Time we just didn't have...

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.

smakovits's picture

Seems to be the issue everywhere you look, time...

I guess another option is to remove them one at a time to determine the actual cause of the current issue.  The horrible part of trying to disbale sysplant is the need to unlock the tamper protection in the policy, wait for it to push down.  Then uncheck tamper protection, edit the registry and tell admin to reboot.

I guess it would be similar with the need to remove components as far as a reboot being needed.

.Brian's picture

As soon as you make the policy change in the SEPM (and it actually changes) you can right click the SEP client icon and "Update Policy" to force it to check in and update.

I would start with PTP to remove app and device control if you do decide to go that route.

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.

smakovits's picture

I may actually explore the beta as well since Symantec says the thought issue is resolved there.  Might just be worth testing before going crazy

.Brian's picture

Do they know what the issue actually is?

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.

.Brian's picture

Any success removing components?

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.

smakovits's picture

removing the components were not a solution.  Had 2 locations where removing components still resulted in the issue.

However, all is not lost, after collecting some process dumps on systems with the issue, Symantec was able to verify the issue.  It turns out this is a known coding bug that affects GUPs.  Why it is not every GUP if it is a code issue is not known, but I have been assured that the issue is fixed in the next release due later this month.

I have the beta installed in a few places and it does seem to be working so far.

.Brian's picture

Hopefully fixed in 12.2 than

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.

smakovits's picture

Beta continues to work, so I feel this is indeed fixed in the next release as it is much needed.  As the GUPs become unavailable, there is another bug in the RU1MP1 code that has the endpoint ignore the policy to never bypass the GUP for updates and instead it does.  This resulted in failed WAN links as a few computers pulling full updates were saturating the connections.  They say that this too is fixed in 12.1.2 (Jaguar) do any day, most likely next week.

jellsworth's picture

Thanks for this thread.  This has helped solve some issues on my end