Endpoint Protection

I'll try to stick to things I know and can point to, factual..........
So far, after only a couple of hours experience with RU5, I noted a HUGE difference, and IMO, a big improvement ->
When I assign a package to a group, and choose the "update schedule" via the package properties, normally, it's several hours, heck, even the next day before I see any servers have received the update. And in fact, I read in a Symantec paper that this was known, or maybe it was a forum thread. Anyway, within 15 minutes, I saw a server in our group had RU5! I mean, I updated the SEM servers, assigned packages to the server group, and in 15 minutes noted the first had been updated.  As of this AM, only 3 of 28 servers do NOT have the update, plus one of the SEM servers has received RU5 already. With prior releases, it would have been at least a day before I saw even 50%.
More to come as I discover it.
Maybe others would like to add SPECIFIC things they have seen, especially improvements.

Hi Bill,

It is one of the main benifits of RU5. The delta package for upgrading the groups is reduced hence improvising the performance of the upgrade process.

If a particular computer does not upgrade for a long time, please reboot that machine to kickstart the upgrade process for that client.

best,
Aniket

just small one... we added file location in single risk email notifications :-)

On the few machines I'm testing so far:

Full scan seems to be quicker - certainly wasn't as noticible whilst continuing to work.

One machine didn't update NTP definitions from server - had to force an update from Symantec servers - all was OK after that though.

File path added to email alert - WOOHOO! Such a small change, and soooo useful.

Works on Win 7 without issue so far.

Exported install files are about 15Mb larger (95Mb ish) and take even longer to generate.


Nick

OMG! I can't wait for our first infection! Cool!
Honestly, if the email alerting was as good or at least as COMPLETE as the Intel used with SAV CE, I'd call it near-perfect.

Now to get them to work on the monthly reports.......... scrap the pies and give me info.........  ;-)

This is cool - I've printed and have been studying the release notes and known issues papers.
So far, good stuff, however, I still don't see what I really need - a fix for SEP causing our servers to delete Word documents upon save attempts. Even tech support gave up and said "hope it's fixed in RU5" - so we'll see, there's no notes on it anywhere that I've found.
Anyway, back to the positives, esp those not in the notes, like that email bit! Thanks for that! Free coffee for everyone!

Nick - I noted the exported install packages - those I use to "push installs" to took a bit longer to generate - didn't check size, however. Will do that now.........

Yup - old was 155 meg, new is 167 meg for a 64bit, let's check a 32 bit: - hmmm, must be a problem with the export, the RU5 is half of  the MR4.

The stand alone client update files don't seem to work properly.  I've tested on 2 x86 machines, one Windows 7 and one XP SP3.  They run through the update process, but after the upgrade proess is complete, the service does not restart.  If you try to launch the client from the All Programs menu, it will prompt you to start the service and after that, LU does its thing and all is well.  Just something to keep an eye on as this could leave a machine unprotected until a reboot if you're not paying attention...

ShadowsPapa - Say it ain't so!!  This was a major issue on workstation\local storage in my network.  I was hoping this "blurb" in the release notes meant that this issue had been handled;

Microsoft Word files are deleted as soon as they are opened on a local partition

Fix ID 1536936

■

Symptom: Microsoft Word files are deleted as soon as they are opened on a local partition.■ Solution: Auto-Protect was modified to do non-buffered I/O on NTFS file system.

 

Our issue:
Windows 2003 32 bit server with shares or folders where our users "keep their stuff" as The Tick would say.
Clients are Windows XP SP3, etc. etc.
Office 2003 with all the latest and greatest patches and SPs.
user opens a document from the network/server share by double-clicking to it OR by navigating through their folders and launching with Word already open. Usually the former - click on the file or a shortcut to the file.
User makes changes, hits SAVE button and is greeted by "you can't do that - you don't have permissions" and the file is deleted.
REMOVE SEP from server, all is fine again.
OR, turn off opportunistic file locking on the server (which slows it down and disables server caching) and it works again.
Enable opplocking, issue returns. This happened with the SEP upgrade in mid-december 2008. Until then, all was fine. IT was only after I updated SEP in 12/08 that this started. Files disappeared left and right, users called complaining of many dozens of lost Word documents, and errors all over their screen about full drives or no permissions. Disabled opplock, things went back to normal, but opening and closing Word documents can take several minutes now.
Was HOPING MR5 or RU5 (looks like the Russian version of MR5!!) would help. Problem is, to test this, you have to enable opplock during production hours and risk the rath of 300 users............... and the loss of many files.
MAYBE MAYBE MAYBE that fix ID may have some impact? Does anyone know??

Anyway, back to having fun with 68 pages of release notes and "known issues" hoping to NOT shoot myself in the foot again like I did with the move to MR2 or whatever it was that broke Word documents on servers.........

Our issue was incredibly similar with the caveat that it affected word documents locally stored only.  How strange!! Behavior upon opening document and then saving changes was identical. But, it never touched or affected network stored documents.  I am firing up my test SEPM server for testing.  I have kept this guy available but "asleep" for just such a purpose.  I also have a few workstations with the issue in the local "neighborhood".  I will advise of results.  Hopefully, this particular fix is relevant to both of our iterations of the problem.  Thanx for your posts.

Are you using Application and Device Control?  I found this, though there isn't much information attached to it:

Title: 'Failed to save Word files onto network share folder in MR4 clients'
Document ID: 2009051916471148
> Web URL: http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2009051916471148

sandra

Some of our users complained of the Word document issue as well, but I was never able to reproduce it.  If this fixes it, then all the better.

Well what do you know - a document that acknowledges the problem, but not a clue as to the FIX............

Number 3 we did as a test, NO difference. We can't leave it that way, we'd be in big trouble........

Removing application control would open us up very wide since I've got stuff in there that blocks things that SEP misses - those rogue BHOs and other items that like to install in user profile areas, including Google's garbage, including their junk browser that breaks all the rules installing into a profile area instead of the program files area.
If I recall, I did try #2 many months ago - the issue is, I can't "experiment" because that means I have to disable our policies, re-enable opplocking, restart the server, see how many folks scream and lose documents, then if there are any that continue to have the problem, disable opplocking again and reboot the server for it to take effect.
Since we are effectively banned from OT, etc. - AND I can't reproduce this in a lab, it's very random and unpredictable - it's got to be done during production hours with real people and real documents.. We're in a big catch situation here. It's like we have to know there is a fix, and not test it, just apply it knowing it will work. Tests just don't work. I have never seen the issue myself with my computers or documents, and some folks don't see it every day. At least though there's proof that it's a known issue! Just no "fix" yet other than disabling security! And if that's the case, why not just uninstall SEP, put SAV back on and get all your performance back, and keep your documents from being deleted?  LOL - Naw - we'll live for now with the big performance hit for having opplock and thus server-side caching off but in a secure environment, hoping that someday, there will be a real fix. I have to have something really in hand before I can declare a "test day" again because this has become a really really big "political" here with reputations on the line.

-----------------------------------------------------------------------------------

Question/Issue:
When saving Word files onto network share folder after editing, the error "Word cannot complete the save due to a file permission error" appears, and the file fails to save.


Solution:
As workarounds, you can choose each one of the following ways to solve the issue:

1. Disable Application and Device Control policy, which has been applied onto clients.
2. Check the applied "Application and Device Control" policy and make sure all rules of "application control" have been disabled. Meanwhile, you can enable device control.
3. Change the permission of shared folders to "Full Control" for remote users.

Document ID: 2009051916471148
Last Modified: 09/22/2009
Date Created: 05/19/2009
Operating System(s): Windows XP Professional Edition, Windows Server 2003 Web/Standard/Enterprise/Datacenter Edition
Product(s): Endpoint Protection 11
Release(s): Endpoint Protection 11.0.4

 

ShadowsPapa, you're a brave man for installing this less than one day after release for production servers.  I'm really tempted to upgrade all of my SEPM's today (currently copying the installation files).  Please keep us informed of your experience with RU5.  Great job as usual!

I wish it would for me!  D/L install on SEPM were all sweet..  Created my packages and added to the "Install Packages" of the unknowing guinea pigs.  Noted 2 things..

1. The SEP shield alerts that is failing (why can't it just alert it is being upgraded?)

2. A number of machines came to a screeching halt and crashed with..

Symantec Endpoint Protection

Error: The resource file version does not match the version of file trying to load it - cannot load SfrMANRess.dll
Error: The resource file version does not match the version of file trying to load it - cannot load DevManRes.dll
Error: The resource file version does not match the version of file trying to load it - cannot load HPPProtectionproviderUIRes.dll

Then the machine hangs on the hour glass..  I even had to go get a laptop so I could even write this note.. :)  Am I alone..  I mean if there is a problem I will find it..  Brokenjeep

 

On some servers there was little choice but to give it a shot. I'm not doing clients yet save for a half dozen.
I had to get this onto our 2008 servers NOW.
First huge hiccup - two servers won't upgrade.

I remoted into one to take a look and anything I do I'm greeted with the MSI stuff stating it's working on something. It won't install, it won't uninstall and what's worse, it's got MR4 AND RU5 BOTH installed - well, sort of ! Neither will work, neigher will uninstall, neither will install. I can't get the MSI cycle to end. I kill all MSI processes and as soon as I do anything at all it's in my face again. Gonna put the kabosh on any further "upgrades" via the upgrade package assignments to groups. 28 servers and these two have to puke on it.
It seems it's just the install piece that is an issue. I've never seen where it left a prior version and tried to install the new version and BOTH are in add/remove programs, and neither can be installed or uninstalled now.
Worse yet, there are other Symantec products on it so clean-wipe is out of the question - it's running protection for sharepoint!

YES, these two have the "do not match" error, too!
Looks like we've found a hiccup - don't assign packages to groups...........

The manual upgrade process of the SEM servers went with NO issues - but then I backed up the SQL, took down server number 2, turned off the service, ran the setup.exe and chose to install the manager, followed all directions, then did the same for server number 2 - turned off server number1 and did the upgrade on #2. Managers went very well. It would seem the common item is an upgrade package assigned to a group?

Papa - For what it's worth, it sounds like there are definitely differences between our two issues, but in case it helps.  Completed upgrade of my Test SEP network - went smooth as silk.  Created new client install packages and sent to the SEPM server (32bit Server 2003), a new 64bit Windows Server 2008 and two XP workstations (both with the local Word.doc save issue).  Early returns - all good ------- including resolution of the Word.doc issue.

Talking abt the new things in RU5, I have created a couple of articles on GUP enhancements in RU5.

Plesae take a look:

Whats new in Group Update Providers in RU5 release of Symantec Endpoint Protection 11.0

Configuring Group Update Providers in Symantec Endpoint Protection 11.0 RU5

[ For the second one, Please ignore the horrible editing for the next 24 hours...as for some reason the editing changes are not being saved ]

Cheers,
Aniket

OK, after about 3 hours, I've concluded:
One server issue was user access control was still active blocking the upgrade in that group. It was a 2008 R2 64 bit and when I disabled user access control and rebooted, the upgrade went fine.
The other server, possibly a fluke. In talking to another admin, he says the server isn't really fully current in other areas, has had "issues" in the past. It appears that the SEP services wouldn't fully stop and files got copied and registry changes made, but not fully.
I was able to get it convinced to remove RU5, and it left MR4 in place, but with some RU5 files still in the folder. I'm manually copying the proper "old" files to the server so the versions all match. With luck, I'll be able to do a manual UNinstall and move on to RU5.

THe clients have upgraded just fine - both push and upgrade package assignment. That's only about 10 of 300, but so far, ok.
It seems to be a TAD faster on the console side. NOT a lot of change, still slower than the proverbial 10 year itch, but it's enough that I feel someone is paying attention. (I still say SCRAP JAVA!!!!! use a REAL language, one that is fast and stable.... and secure)
Anyway, once I get this one server under control, it will be time for more discovery.  Again, I'll call it a fluke, but DO be watchful!
If it's a VM environment - make snapshots, then roll out to your heart's content. You can always revert to snapshot.

Woo-hoo! SEPM popup windows work correctly when Java 1.6 u16 is the only Java installed on the SEPM server! (Think I read in the readme that u14 was "recommended".)

That said, I agree: scrap Java.

I"m being flooded with "Security Alert Notifications" on "ping of death". We used to get a lot of them - why I have no clue, but now, let's just say 400 of them today alone, and ONLY THE SERVERS even have RU5 on them. The clients have not been upgraded yet.
Also note a HUGE increase in the number of "Security Alert Notifications" that have bascially empty reports. Again, we used to get a lot, now take that times 10 at least.
The email reads as:


And when you click the attachment, it's basically EMPTY...

So the ping of death reports (false I might add) and these empty reports has skyrocketed since the servers went to RU5. We've always had to deal with them, and I delete a couple hundred such "so what" reports or emails every day. I get about 6-10 every few minutes now, mostly empty report attachments. Was BAD before, is worse now.

Symantec Endpoint Protection

Notification Events

September 23, 2009 1:51 PM to September 23, 2009 1:52 PM Print    Save    Close

 

Table of Contents     Network Threat Protection and Compliance Events     Traffic Events

 

  Top
 

 

Network Threat Protection and Compliance Events

 

Nothing to Report

 

  Top
 

 

Traffic Events

 

Nothing to Report

 

Active Filters for This Report
Date from:	09/23/2009 13:51:00
Date to:	09/23/2009 13:52:59

Do you still have any clients that have not been cleared of a "Still Infected" status via the Home Page of the SEPM?  The only time I ever ran across blank messages like this being apparently randomly generated resulted from a Still Infected status not being cleared.

sandra

Hearing all this is making me itch to install on prodcution. But our lab install is still on test. Sandra's point seems to be something I should add to my checklist before I start.