Symantec Management Agent 7.5 Icon not displaying correctly

[Powershell_Guru]

Hello all,

 

Quick question.  We have stood up a 7.5 environment and things seem to be going very well, especially after SP1.  One thing i'm finding, however, is that although the AEXNSC service is a delayed start, most times when the pc is first booted, the icon still displays the "no smoking sign" although it is successfully connected to the SMP and registered with a site server.  If the service is restarted, the HTTPS padlock reappears and everyone is happy.  Normally, this wouldn't be a really big deal but we have instructed the support team to use this icon as a quick notify of connectivity.

 

Thanks,

Paul

[Alex Bizjajev]

Hi,

May you clarify a bit - this incorrect status happened after regular restart, or maybe you have noticed this issue after the SMA upgrade? Asking because I know we have a bug when sometimes icon status is incorrect after the first SMA startup right after the upgrade, but problem with incorrect status after the restart is something new to me.

If it would be possible to zip&share logs from the client with the problem it will be really helpful!

Thank you,

Alex.

[Ray OConnor]

Any update on this issue Guru?

[Powershell_Guru]

All,

I apologize for the untimely response.  The issue is still being observed and this is after a clean install and before/after the SP1 upgrade.  As I stated previously, there is no performance issue from the client perspective and the machines affected seem to be fully operational. 

Thanks,

 

PSG

[steve1977s]

Powershell,

We are seeing the same issue within our environment running 7.5 SP1.

Agent icons in the system tray are showing as not connected, however the agent is fully operationally and talking to the NS.

If I restart the management agent, then the status correct's itself.  Seem to be a refresh issue somewhere.

[Igor Perevozchikov]

If restart of SMA removes this incorrect icon status and problem disappears, then you can assign a client task to restart SMA on managed endpoints, where SMA is already upgraded to 7.5 SP1.
 

[Powershell_Guru]

Igor,

 

With all due respect (and I know you deserve it), this seems a little ridiculous to create a scheduled task on 10,000 endpoints because of a graphical bug.  90% of my workforce is mobil so most of these user are rebooting several times a day.  I would be stopping a delayed-start service only to restart it rightaway when I really have no indication of failure rate outside of what i've observed myself.

 

Thank you,

 

PSG

[Igor Perevozchikov]

PSG,

I didn't know about what amount of clients you have :) Now I will know this.

Of course it's unnecessary to force a restart task of SMA, for all of them due temporary cosmetic issue. Agree.

Also I thought about the way to disable/enable 'show SMA systray icon' only for Windows managed endpoints, via script task or via SMA settings policy, but I'm not familiar with this issue and not sure that this will 100% solve cosmetic issue to avoid unnecessary SMA restarts.

Thank you.

[Mistral]

Will this be fixed soon?

Customers really facepalm when the agent icon says "not connected", but in the settings you see everything is fine.

Is it so hard to show/update the correct status?

It's really annoying to see an "unconnected" agent all day.

[JoeVan]

We see the exact same issue.   Haven't had the chance to open a ticket it on it since I'm still working on higher priority issues (resulting from the 7.5 SP1 upgrade).  It would be nice if Symantec could acknowledge the bug and let us know they are working on it without the need to open a case.

As others have pointed out, the issue has no impact on functionality and appears to be a simple UI bug that probably has something to do with timing and boot up sequence.  It doesn't always happen but I've seen it often.  It does cause concern for users and calls to the help desk since it gives the appearance of something not working.  I've only seen it happen on a clean boot and restarting the agent does result in the correct icon being displayed.  Hoping for a quick turnaround on this fix since I don't want to train my users to ignore warning signs like this!

 

[Powershell_Guru]

All,

 

I agree, we are buried in post 7.5 trouble.  CEM has been a huge nightmare and we have had a LOT of "bugs" in almost every solution.  I'm curious if anyone else has had an issue with pages displaying in the console during a membership update or policy change commit where the page will display "Request Entity Too Large and can not be displayed"

 

Super frustrating! 

Symantec, are you listening?  This was supposed to be good for my environment!

 

Thanks,

PSG

[JoeVan]

CEM is our biggest issue as well right now.  It works partially for us.  Ticket has been open for 3 weeks and is escalted to backline.

I've not run into the "Request Entity Too Large" issue.  Try the console from another machine.  I did have an issue after upgrade where I could not update filters and policies though and it was specific to my machine.  I had one other admin complain of the same issue.  I ended up needing to delete the cache on my browser and delete the IE plugins then allow them to reinstall.  I think that's what ended up fixing it. 

[Powershell_Guru]

All,

 

The request entity too large issue has been resolved.  see (https://www-secure.symantec.com/connect/forums/metadata-import-task-error-page-was-not-displayed-because-request-entity-too-large#comment-10539911)

 

REQUEST ENTITY TOO LARGE

 

Also, the issue with the icon is supposedly fixed in SP1 HF3.

 

Thanks