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

Virtual appliance and communication settings export problem

Created: 06 May 2013 | 5 comments

We have to ESXi hosts sharing the load of our virtual servers, and soon to be VDI clients.

We have TWO (2) SEPM servers, sharing the load of SEP running on our virtual servers and physical clients. The client computers exist in roughly 4 major groups in the SEPM structure, plus some groups for special purposes. We operate in computer mode, NO user mode.

We have had the virtual servers for several years and are planning a move to VDI for the clients very soon - about 350-370 clients will be converted.

Part of the install process for the SVA (Security Virtual Appliance) was to complete or edit the information in the XML install file, AND to export the communications setting from the group. That should have been a red flag right there "group" and not "groupS".
OK, so I chose our largest group of desktop computers since I HAD to have something to put into the folder where the install XML and other install files resided.
So I run the command line to install just like the documents state - JAVA this and that, and it used the XML install file and created the SVA for host1. I did this again with a newly edited XML install file and created SVA for the ESXi host number 2. So now we have the two VMware host EXSi "machines", each with a SVA running under them. Trouble from minute one - getting the vShield thing in place has broken some certain communications with host1, but the biggest question is this - so now what?

I came in this AM and saw in the logs that our senior network admin was having big trouble running an install on one of the servers. I checked and the server was found in the desktop computer group! Yikes! I can't figure how a server got into the desktop group, but I have a funny feeling I'm about to find out.

Since I was only able to export the communications setting from one single SEP group and not multiple groups to use for the SVA install, I assume that now any computer - server or otherwise that appears to the SVA will be transported by magic into this desktop group?

OR, will it refuse to communicate with the servers since the SVA has only the settings for the desktop group and not the server group in SEP?

What's the point of groups if the SVA can only understand one single group's communication settings? Do I have to create a SVA, and thus a shared insight cache for every single SEP group we have? One for servers, one for public computers, one for our employee desktop computers, another for management people and so on?

If so, then what's the point?
What is the purpose of the communication settings file export that is used for the SVA install?
What if when we move to VDI, we have 4 different groups of computers in SEP? What about servers? We have 2 different server groups - one for DCs, and another for other servers - file/print, etc.? How does the SVA communicate with them since it only has the settings for the desktop group?

What if I create a whole new group and split things - or combine groups? What will the SVA do?

Is this why the SVA virtual appliances appear to be doing nothing at all, and there's no communication - SEPM console shows "uinknown"??

Is sharing information about files scanned using an administrator defined scheduled scan, or a manual scan, all that these SVA virtual devices can do for the overhead they consume and install requirements in VMWare?

And finally - doing an exhaustive search on the SVA - shared insight cache - is there anyone who knows about these, how they work, and what about organizations with multiple computer groups in SEP?

 

Operating Systems:

Comments 5 CommentsJump to latest comment

Swapnil khare's picture

 purpose of the communication settings file export that is used for the SVA install

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

the pdf attached should give a good insight

AttachmentSize
SEP_12.1.2_Virtualization_Best_Practices[1].pdf 1.91 MB

 

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

 

ShadowsPapa's picture

You did not answer my questions about the SVA and being able to use only one group communication settings. 
No one I know of would use just one group in SEP. Part of the good thing about SEP is the ability to use multiple groups to customize protection and rights or lack of rights on different computers and how they are used, and by who. But I note in the SVA install you choose a single group and export the com settings for THAT group. What if you change down the road? Reinstall the SVA and start all over again?

I was asking since we can only use ONE SINGLE EXPORTED xml file for the install of an SVA  (communication settings file exported from 1 ONE single group) what happens with the OTHER groups we have clients in - or servers? Are they simply ignored? Is the SVA a single-minded, single-purpose product that does nothing else but handle scheduled or manual scans?

You responded with "here is what you need to install", which I stated above I was well beyond - the file was exported and used for the SVA install already, twice.
Then you responded with a "best practices" - which admittedly is one I've not seen, it still says nothing about the SVA and interaction with groups (plural - multiple groups) 
(because Symantec is like Microsoft - you learn of the best practices AFTER the install! That document should be in the READ ME area, seen prior to install, included as part of the install package, not a "oh, by the way, this is pretty good reading" long after the frustration of the install and finding out it ain't working.)

This is why the connect forums are turning into a wasteland - all we get are simplistic boiler-plate responses with links.

I said in my original post that I had read the documentation - all of it, such as it it (it's pretty empty except for bare-bones basics how to install) I had already exported - manually - the communications settings, I included that file in the same folder all the install files were in - I put everything in a single local folder, and ran the install. The install started and completed, I found no errors in the install log that was created.

So I'll try once again - I've seen and read all the install documents that were included with the SVA part of SEP.
I have ALREADY DONE the export so I'm long long long way past that HOWTO81110 document - the horses have left the barn. It's too late to read about how to install it because I already did.
The best practices PDF is a very good file, but it says nothing at all about using MULTIPLE groups of clients with an SVA.

My question is - why just one group? What about all the other computer groups? Are we hosed - unable to use an SVA with MORE than one single group of computers in SEP?
Clients 1
Clients 2
Clients used by public
Servers
Using the above example groups, which group would one export the communication settings from and use to install an SVA?
Will an SVA communicate with and work with only ONE single group in SEP?
Does one have to have an SVA for each and every group of computers in SEP?
If so - why bother?

NO boilerplate links or copy 'n paste responses please - unless it answers these questions.
I don't need to keep jumping back in here all hopeful just to see the same links I've already seen. Please use experience and thought processes to determine the answers.
I do pretty well with searches, so I typically find documents that are easily found.

 

Paul Murgatroyd's picture

Hi Shadows, Long time no talk!  I hope you are well?

To answer your question, the SVA uses the XML file you export to configure its communication with the SEPM, the heartbeat, etc.  I generally recommend customers create an empty group for the SVA and configure heartbeat as they want it for the appliance, then export the XML from that group.

The XML you exported and used in the SVA installation should have NO BEARING on where clients appear - they should stay in their own groups, and you should then see the SVA name they are "managed" by appear on the right hand side of the client display window.

If your clients are moving groups, I think there is another reason for that, and we may need to troubleshoot further.  Is it all your clients that have moved to your SVA group, or just some?

thanks

p.

Paul Murgatroyd
Principal Product Manager, Symantec Endpoint Protection
Endpoint twitter feed: http://twitter.com/symc_endpoint

ShadowsPapa's picture

Now there's a great answer. Thanks.

It was one single server - and I've been watching things but haven't seen others "move". It happened just a couple of hours after the SVAs were brought up - a server that had been in our server group for over a year suddenly appears in the desktop group just a couple of hours after the SVAs are installed was totally weird. Coupled with the fact that the SVAs appear to be doing nothing at all...... and the fact that when we bring SVA1 up, we lose communication with ESXi host 1.  Remove SVA1 and the VMWare support folks can regain communications with ESXi1. Reinstall SVA1 and we lose communications with ESXi1 again. Coincidence? Maybe-  but if so, another weird one.

There's quite a level of frustration here as we're finding out it's a whole lot of work for no real gain. In our situation, I'm fast finding the facts are quite different from what we heard, read, or were told. The fact they now sit, everything is 0s, nothing is happening, and when we bring up one of the two, we lose communications with a host server. I can't even tell my lead what is happening as the console shows "unknown" for status.
So far we really have little understanding of how to make the SVAs work, what the purpose or point is, and have had a lot of hassles due to the loss of ESXi1, etc. If what I've learned or seen this week is correct, we may end up not using them since they are only good for manual scans or scheduled scans, and then only for a given set of defs.

The SEPM console shows "unknown" for status next to the servers where the vShield piece and the latest VMware tools are installed. The SEPM console says "not installed" next to the two servers that do not have the VMware vShield piece and latest VM tools installed - which is correct. But it's either "not installed" or "unknown" or "not applicaple" - for servers turned off.

We don't yet have VDI clients - we are in process of setting up the framework first - and assumed it would be best to put the vShield parts in place, and even the SVA devices up before actually creating any VDI clients to play with and test.

There seems to be a lot of confusion as to what the SVA is and does, and what it does NOT do. From where I sit now, had I known then what I know now, I'd have probably said "don't mess with it, we won't gain enough compared to the overhead of management of two new virtual devices.
The kicker for me after reading that is since we update defs every day - actually LU runs every 60 minutes, we could conceivably get new defs 3 times a day. This means that the SVA data given it when a computer runs a manual or scheduled scan is good for 1/3 of a day if defs came out every 8 hours, or 3 times a day. Example could be we run a scheduled scan ONE time a week - in the example with defs 123 rev b, that info goes to the SVA, and is good for a whopping 8 hours until the next defs, 123 rev c,  come out... but since things won't scan for another almost 7 days, the SVA does nothing at all for those 6 days, by then the defs that checked the files are not in effect, so the SVA tosses that infornmation,  as we don't run manual scans, and scheduled scans are once a week. So each time a weekly scheduled scan runs, we literally start over - is all that correct? And if they all scan at one time, then by the time the info get into the SVA, it might be used or touched by 1 or 2 servers of our 20 or 22 servers. Clients would be similar, I assume?

OR, should we run scheduled scans more often, and change to the "active scans" where it scans only common load points and at-risk files? I run things SO tight that we've not had a single incidence of malware or viruses in 25+ months now. So a scheduled scan isn't likely to find anything.

My problem is that I can't seem to find anyone uses these, or else no one knows the purpose, how they work, what they do.......No one but a high-level Symantec person could answer the part about the purpose of the com file export.
The instructions imply or lead us to believe it's to establish communications and settings for the group that the VDI clients will be in. We don't yet know - and if we did, it would be more than one.

If you read the actual published instructions that come with the product, it states clearly to export the communications settings to the XML file - "choose the groups that your VDI clients will be in".
Does anyone see the trouble with that set of instructions? Choose the group that your VDI clients will be in and export the settings...... what does that imply? We need to know what group that will be (group - singular), and that the VDI clients will be in.

So it appears that we've established then this only uses the communicatins settings - that's fine as the group I chose is sort of "indicitive" of our others - it's a good sample or example as far as the comm settings.
Then what about our current servers? They are ALL virtual - we have no physical servers except for the two that run the VMware host OS. All servers, be it print, file, SEPM, all - are virtual. Will this do anything for them? They scan one time a week, middle of the night on weekends. No manual scans, they are low risk as we control who has direct access.
I know my team lead is expecting these things to actually be "doing something" right now - we were told, and it was implied, that scanning, real-time and otherwise, used this, that once things scanned the files in any way shape or form, the info was kept in the SVA and any time any server or client did a scan on a file or files, even real-time, it simply checked the status via the SVA, and if it was safe, it ignored the file(s).
Apparently that is not the case. It's just for scheduled scans. (which are a dying thing)

 

ShadowsPapa's picture

One other thought directly related to this, might call it "part 2" is this:

I export the group settings for our "desktop" group - the main group of several. It's rather an ok example of settings for communications and servers.

HOWEVER, since the instlal of the SVA uses that exported xml file during the install process, what happens if for some reason the SEPM servers die - and I have to reconstruct?

What happens if once again, there's a major "boo-boo" in support (yes, unfortunately, and the next tech apologised profusely) and they say "delete the servers, kill the database, start over, restore the data to a new database" and now the servers are "different" - same IP, same short and DNS FQN names - but they are still different servers..
What happens then?

Do I have to uninstall both SVAs and reinstall?

What if there's a minor change or we make a major change in the communications settings in SEP/SEPM?
Is there any way at all to modify the SVA without killing and building again from scratch?

Can any settings be modified via script, or GUI or even command line? What if I must - absolutely must change the IP address of the SVA?  What is we give back the current IP range to the state's entity in control of such things and start using private addressing - what about the SVAs?

I guess in short, part 2 of this is  - is there a way to modify, change, tweak, the SVAs via any interface - GUI, command line from console, telnet, etc.??
OR - do any changes, no matter how minor or major, require a full uninstall/reinstall of the SVA?