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

Shared Insight Cache 12.1.2 (VShield) - Security Virtual Appliance Status "Unknown"

Created: 26 Apr 2013 • Updated: 26 Apr 2013 | 15 comments

I have deployed a new Symantec Endpoint Manager Server 12.1.2 and have deployed "Security Virtual Appliances" to each VMWare host in our environment.  Prior to deploying the SVAs, I built a VShield server in our VMWare 5 environment.  I enabled SHARED INSIGHT CACHE USING VSHIELD in the policies on the SEP Manager for the appropriate servers.  I then deployed the SEP 12.1.2 client to 4 servers that have the VMWARE TOOLS client installed.   When I check the SECURITY VIRTUAL APPLIANCE column for those servers in the SEPM, the status shows as UNKNOWN.  I have rebooted the SVAs and the servers but nothing changes the status.  Has anyone else had this experience or have any insight into what's happening with this?

Thanks.

Operating Systems:

Comments 15 CommentsJump to latest comment

.Brian's picture

Have you went thru the troubleshooting guides?

 

What do I need to do to install a Security Virtual Appliance?

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

 

Installing a Symantec Endpoint Protection Security Virtual Appliance

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

 

Configuring the Symantec Endpoint Protection Security Virtual Appliance installation settings file

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

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.

SebastianZ's picture

Issue already reported to Symantec but not resolved yet  - please contact the Symantec Support to log a case and they will attach it to master internal ticket that is currently still under investigation for this problem.

ShadowsPapa's picture

Can I assume this is what folks are talking about?

We also have ESXi errors now as well -and have lost ability to SS into the ESXi1 host - communication failure error in the VM logs.

But this is a puzzler - and the N/A is a  bit baffling too.

So far, I can't really figure out the whole point of this VSA to begin with other than actually scheduled or manual scans. I thought it was supposed to do so much more - but for that, we could simply not schedule scans.

I was informed that it helped with REAL TIME scanning, and offloading, etc. - and so far am quite disappointed in that all it does is share information related to scheduled scans. We probably won't schedule scans in the future anyway since we can certify the images for VDI. It seems to do nothing at all for us........everything is 0's in the vShield manager as it relates to the SVAs

Can anyone explain the point - what it does besides sharing information about files touched during a scheduled scan? Does it just sit and do nothing at all if there are no scans running?

What does "not applicable" mean in this setting? What about unknown - not getting any info?

What sva-unknown.jpg

ShadowsPapa's picture

I can't speak for the original poster - the starter/owner of this thread, but I can for us - YES.

But you don't pick and choose the way we do it. We let VMWare install the tools - it's silent, without any fanfare, it just installs the whole shootin' match, then says "current, running" in the console when done.

Right click a server,

vmware-tools-install_1.jpg

nlnieme's picture

Both the VSHIELD DRIVERS and SHARED FOLDERS have been installed on all the clients.  I have also deleted and reinstalled the SVAs per Symantec'request.  Not luck yet.

jackOO7's picture

And what u see in vShield tab in vcenter on esx host?

Summary tab - SVM is visible?

sva.jpg

ShadowsPapa's picture

Same here -removed and reinstalled multiple times, both SVAs.

And the SVAs do show up in the vShield manager.

We are having an issue with vShield and one of the ESXi hosts - "communication lost" but that's not the same issue, or even related. It's the SVA not communicating with the SEPM  - the console shows properly Not Applicable  if the computer is off, Not Enables if it's not enabled on the client or server VM computer.
But if it is enabled and the computer is running, it shows unknown instead of the SVA name. (if that is what it's supposed to show, that is - don't know as I've never seen "normal")
 

nlnieme's picture

The VSHIELD manager listed the SVM servers and the Host as well as any servers with the SEP 12.1.2 client installed.  I have also called VMWare and had them verify the VSHIELD setup and they validated that it was correct.  I have a ticket open with Symantec Support now for 3 weeks but we haven't made any progress.  I'm not sure if the benefits of the SVA integration is worth the trouble of getting it working.

ShadowsPapa's picture

I say it's not unless you have a LOT of VM guests - a LOT, and run a lot of scans.

Reason I say that - it off-loads nothing at all. Real-time operates as normal. Manual scans of folders or drives won't use it, only manual scans of selected files will use it (how often is that, really?)

IT is only good for the scans using current defs. Once the defs are updated, which can be up to 3 times a day, then the cache isn't used and it's started over again. So only a couple dozen machines running scans, the first will not use it because there is no cached info. LAter ones will, but if other scans take place after a defs update, then it starts over again, not using what's cached in the SVA.

I was under the impression, told, actually, that is actually off-loaded scans - took some of the load off the host because the guests won't all be running scans. Since the files will still be looked or touched to find the hash or some value, then what is really saved?

David Poston's picture

I was having the same issue as above and found a VM article that states the EPSEC driver needs the guest image to be restarted. I restarted my guest, and they started working.

ShadowsPapa's picture

And after installing the new tools with the drivers, and trying to make things work for what is probably almost a month now - they think the guests haven't been restarted, some of them multiple times?

Not only does the SEPM console state "status unknown", but scans don't do a thing with the SVAs, they are just sitting there untouched. No clients, nothing connects to or uses them. Scans run as always, fully on the VM servers (no VDI clients yet, but all of our servers are virtual), it's like they are just there for looks.

I set up scheduled scans, I manually scanned files (interesting note Symantec states that scans of folders or drives won't use the shared cache! How worthwhile is that?)

It doesn't matter what we do, uninstall, reinstall, reboot, replace, do it all again, move guest servers from host 1 to host 2 and back, the SVAs sit there, and the VMWare guest servers run all scans, scheduled, manual and real-time as if the SVAs don't exist, and no numbers increment up at all. Still all zeros.

 

 

nlnieme's picture

Just a followup:

After weeks of working with Symantec Support and escalating the ticket, Symantec finally found an issue with the SVA_INSTALLSETTINGS.XML file.  Apparently the file has some of the relevant config settings commented out.  You need to make sure there aren't any <!-- or --> symbols around any of the config settings related to the ESX hosts or VCENTER communications.  I believe it was my SVA NETWORK CONFIGURATION that was commented out for some reason.  After reinstalling ALL the SVAs, the clients started displaying their SVA.

Now I'm fighting another issue though.  Some of my SEP clients have lost their SVA.  I'm troubleshooting this now.  I'm hoping a reboot might fix this.  Otherwise I may have to reinstall. 

ShadowsPapa's picture

STILL to this day fighting this issue. The SVA install XML is/was perfect. All settings fine. the network part is correct and right - the IP address, DNS, gateway, mask, etc. all fine.

IT's only the SEPM and clients that won't communicate with the SVAs, if it was a network issue, then we'd not be able to communicate with it at all.