This document from Symantec is what leads me to believe this is a know issue, and why I'm persuing this avenue, attempting to gather more info from OTHER users under the SAME conditions - it was indeed KNOWN in MR2 and they say fixed in MR3. I wonder.......... if it was a known issue in MR2 then why could it not be the same issue in MR3?

Symantec EndPoint Protection: Cannot save Word files to a file share

Question/Issue:
You have installed Symantec Endpoint Protection (SEP), and are now experiencing various errors when saving file changes from Microsoft Word to a file share.  (yes, this is us!)

Symptoms:
Errors:
"Word cannot complete the save due to a file permission error"  (yes, this is the error!)
"Check the drive to make sure the door is closed and contains the correct disk or CD"

If SEP file system auto-protection is disabled, these errors do not occur.  (correct!)

Cause:
This problem was fixed in Symantec Endpoint Protection 11.0 Maintenance Release 3.

Solution:
Upgrade to Symantec Endpoint Protection 11.0 Maintenance Release 3 or newer.

Checking "allow fast save" in save options of Word 2000 seems to work around this problem, although this option is unavailable in Word 2003 or newer.

Document ID: 2008101510003048
Last Modified: 10/15/2008
Date Created: 10/15/2008
Product(s): Endpoint Protection 11
Release(s): Endpoint Protection 11.0, Endpoint Protection 11.0.1, Endpoint Protection 11.0.2

ok, northernlight and DerekHo have in this forum confirmed that they, too, see this issue.

derek confirmed it was seen with MR3.

So that's a total of 3 of us.

Anyone else see this SAME issue with the SAME versions, please add to this thread..........

I have this same exact issue with MR3. Some things I discovered during my testing.

1) When you receive the error a .tmp file is left in the directory that contained the original doc you were trying to save. I believe it is hidden.

2) I've only been able to consistently recreate this issue by modifying an existing Word document and then closing it. During the close operation it attempts to save the document and errors. If I just attempt to save a Word document regularly (not during the close operation) I don’t get the same results.

3) This only affects Word 2003. Putting Word 2007 on the same XP machine resolves the issue. Uninstalling 2007 and going back to Word 2003 causes the issue to come back.

4) We have an Application and Device control policy defined (We log USB activity). If I disable that policy the issue seems to go away. This is not a good option since we need this.

5) There was a thread on here about this, and recommends disabling opportunistic locking. I've done that and it also seems to resolve the issue. I do not want to go this route though since I'm not sure what else it will affect, and this is a hack to fix an issue that is cause by SEP.

re: item 4

Same here. However, this is ONE reason we deployed this as we did. We were using SafeEnd to manage and log USB devices, but since SEP did this, we dropped our SafeEnd license!! In favor of the Symantec product.

It's a mandate that we log and can control such devices, but now it seems since we've move to SEP, this means we've lost this ability.

Since we have to do this, looks like we'll be calling the SafeEnd people again!

If I knew all that we would be able to use was the AV parts, I'd have left SAV 10 in place, it was working fine............

Bill D - I sent you a PM regarding your Word issue.  When you have a moment, perhaps we can discuss on the side.

russ

We have been having the same issue for awhile here.  Most of the time I can recover the user's file by opening the tmp file but this is getting old rather quickly.

We have tried the oportunistic locking method on both the clients and the servers.  For the most part it does clear up the problem, but we still have them from time to time. I have read that turning off network fileshare scanning could help as well as turning off the quick save feature in Word.

We have a mandate to monitor removable devices as well so we can't turn off the usb logging (until I get sanctuary up and running that is).

Does anyone or Symantec have any response or update to this?

Did you set your scan options for Outlook scanner to scan only selected extensions? Try configuring to scan all files. I think there was another post about this, try to find it, may help.

I meant Auto-protect, not outlook scanner. Sorry. You may just give it a try.

I've always set all Symantec products to scan all files.

Scanning by extension is a waste - and very dangerous - since extensions are totally meaningless in the last few years. You can give any file any extension, and even applications look at the header and ignore extensions in this day. Shoot, we have people giving files names like

lastname, firstname i. resume 2..doc

and you can't break 'em of it!  Tell me where the extension is in that file........

And word will open a .TMP file if you double-click on it as it looks at headers.

I've even excluded DOC files, and excluded winword.

No effect at all.

There's no pattern, and I've tried every exclusion or setting I can think of. The only way it won't interfere is if you stop the SEP service.  But then, some can have the problem with a file, then the next person work with the same file just fine! Or that person might work a day with all files fine, then lose 4 in a row.

I'd like to throw this into the mix.

Are you all ready for this?

We decided to check our file server....... not for updates, settings, etc. but for free space on the volume that holds ALL of our shares. The server's D: drive. ALL of our shares reside on our file server's D: drive.

Plenty of room, in fact, several GIG FREE.  However, when we ran the math, that was only 3% of the total drive's space. That means 3% was free. Now that's a SMALL number, but as I was reminded, we've seen "issues" when Windows Server runs below 10 to 15% of TOTAL space. On a 100 gig volume, that means if it got below 10 to 15 gig free, strange things happened.

I deleted 40 gig of Ghost images from an archive, then we created another volume and moved the Ghost share to that new volume.

We got our file server up to 16% free this AM.

That was at about 8 am today.

As of 2:30 today, there have been NO new reports of Word file save issues, and none of the prior users, now numbering about 40 users, reported any file save issues today.

So of the 40 with problems, they are saying "so far, so good".

And we've not added to that 40 user number.

Seems to me that if your server gets below 15% or so of free space, then you toss in SEP, bad things happen. But if you free up more space on your shared volume, things straighten out.

Now granted, that's only 6 hours of testing, but it's making me wonder. Perhaps it's the SEP interaction with a volume or SERVER with low drive space and not really SEP in itself????

Folks - check your free space and get it above 15% of total volume size. Forget the number of free K, M or G, work in PERCENT and see what happens.

Maybe it's a fluke?

That’s interesting. We’re using Windows DFS for our shares. The shares exist on a two different volumes. One currently has 20% free, while the other has 18% free. We’ve had the issue with both.

How frequently? How many users impacted?

Is the file deleted, but the ~xxxx.TMP file still there?

Attempting to gather information...... and I can't find a THING consistant!!

This seemed to be the only common thread, and increasing free space means we've gone pretty much all day with no issues now.

I know, one day does not a solid test OR solution make!

Actually now that I think about it you may be on to something. When we had this issue last we were under 15% free on one of the volumes on our fileserver. When we started having the issue I disabled the application and device control policy, and haven't had the issue since. Last week a co-worker reclaimed a lot of space on the file server. I'm going to turn the application and device control policy back on for a limited number of users. Originally 4 or 5 users reported the issue, but I was able to recreate it on another 4 systems. For us the problem only occurred when closing word and saving the document at the same time. I imagine anyone with endpoint would have had problem if saving documents in this method. I’ll let you know how my testing goes.

We’re still able recreate this issue even after cleaning up some data. The volume that the share lives on has 95GB free which equals 15.84% free at this moment. Cleaning up some data has not resolved the issue for us.

We're just deploying SEP 11 MR3 (up tp 150 client so far) and we ran into this problem right away (the original post... about "vanishing" word files from a memory stick...) I think I found a solution/workaround... I am still in the middle of testing but it seems that this is a problem with File system autoprotect's file cache feature. We disabled the file cache and it seems to be working now... try it...

VERY interesting! The way word works, this may make some sense......

Keep us posted.

I'm also having word 2003 issues after I installed SEP with MR3. I see most problems with memory/USB sticks. User are saving there work to them and when they go back it is missing correupt or a temp file is there in place of the orginal file. It is intimitant. Not sure what to do or where to look. Has anyone had any luck with this problem.

Also don't know if this is related but we started having problems mapping our Home directories though AD after we put SEP MR3 in place. Sometime there home directories and if it doesn't then they keep rebooting untill it does show up.

Thanks

We are having the same problems with Word 2007 and USB sticks.  If I back up the data on the USB stick and format the drive, the users are then able to save again.  I just started having this problem this week.  I have noticed many temp files on the drive before I format it.

Same problem here.

The only difference  is that we are using unix file server connecting to samba shares.

Furthermore the bad thing in my case is that, after the "crash" , while the client can ping the gateway and dns server (which is also the file server) it cannot reconect to the share at all.

I tried "smc -stop/start"  whith no luck.

The tmp file was created on the share without the last changes.

I havent opened a case yet since the sup is not the best out there.

I also have the extended debug  "on" with no logs related to that specific problems.

I "solve" the problem by installing just the AV and AntiSpy modules but this not an acceptable  solution neither for me as IT admin or the management (who will soon ask for explanation why we dont have logs for usb devices for the specific clients).

Regards

Yes, it's a state mandate that we control, log, etc. USB devices - any removable media - period. It must be protected, logged, controlled, whatever.

For now we use SafeEnd, but we're letting that go supposedly to have SEP take over for that since we own it anyway.

Agreed on another point, too. Rebuilding our entire structure wasn't the answer........... ended up having nothing to do with the issues. And apparently, the word isn't spread among the support staff as our tech said "never heard of this issue" and "you are the only one seeing it".

I sure lost confidence in support with that single phone call!

SEP MR4 beta solved it for those I installed it on, freeing up from 40 GIG free to 80GIG free helped the rest.

So it's an interaction issue.................. SEP has the power to make or break it in the end, though. We were ok until the SEP install, but I can't blame it ALL on SEP in our case since freeing up space did help, too.

We've not found out yet if it impacts USB devices.......... and we can't run the USB management bits yet, I've not been able to make it work consistantly. (but this MAY be a training issue!  LOL )

Has anyone else confirmed that disabling the file system auto protect cache feature fixed this problem with saving to memory sticks?

I am really sorry but disabling "file cache" was not the answer... it seemed to work at first, but after a bit of testing the errors were back. It only seemed to "postpone" errors so now I get the errors approx after 10th save cycle (but not every time)... I am about to give up... can't find any logic here... confused truly :-)

I think i found the problem.... When i disable all checkboxs in Applicaton & Devices policy - all errors dissappear... Enabling this options again causes errors come again... For best performance i compleately disable this polisy(disable and remove). 2nd day - no errors... For device control i using DEVICE LOCK.    Sorry for my RUSSIAN English ))

LOL - your Russian English is better than some of the native English speakers!

No worries. You did just fine.

hi ShadowsPapa,

Does Symantec work with you on this issue now? any workaround they provided to you? I am going to evaluate their Network Access Control solution at end of this month...hope this will not become another "BOMB" for me...

For the last 2 weeks, we've had NO issues saving Word documents. Their telephone tech support blamed it on corruption in our setup, I spent over a week rebuilding our entire structure, but found that the BETA of MR4 actually seemed to take care of the issue - as well as freeing up more space on the server.

It was complex. With MR3, if we stopped the SEP service on the workstation, they could save files fine. I got in contact with a person here who had the beta as well as another Symantec tech, and got the beta for MR4 client, and installed that on 4 workstations. Those 4 were fixed by the beta - they had NO more Word file save issues, however, the others who I did not install the beta for continued to have the Word file save issue. We had 40 GIG of free space on our server, but calculated that was only 3%. Recalling our Microsoft training from the past, another network admin here and I freed up more space and got the server free space up to 16% free. The issue disappeared for the remaining people. So in our case, the beta of MR4 fixed it, and the freeing up of server space, getting OVER 15% free space also fixed it. Apparently it was an interaction - SEP trigged the problem on a server with under 15% free space, so clearing up space OR using MR4 fixed it.

On the Network access control - I'd hope Symantec would be better than Cisco's solution! I'll be blunt, we lost our butts on the Cisco crap. Their hardware is being yanked out, the Cisco NAC project is being SCRAPPED. We spent WEEKS, sometimes 10 hours a day, working with Cisco engineers and our Cisco vendor. IT started in March - putting Cisco's NAC solution in place REALLY messed up this network and Cisco engineers were clueless. That and the fact their ACS solution is also trash, and their engineers didn't realize that some versions wouldn't run on the most current Windows Server 2003 - what a joke!

We are looking at Juniper where we can and MAY look at Symantec's NAC system. We'll not be going Cisco.

We had to take the issues with NAC and ACS clean up to the very highest top level of support and STILL didn't get good solutions. ACS is working for us, but fragile in that we're afraid to update either the server or the Cisco ACS. Cisco engineers made such a mess of our network it's going to take weeks to straighten some of it out.

I'm happy to see Symantec's NAC solutions are much much more flexible and don't require a total restructuring of the network and subnets to make it fly.

We are experiencing this also with saving to USB drives. Sometime the data can just not be recovered at all. Seems to be primarily in Word documents with tables.

They have confirmed it to be an issue.

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008041108225248

I have a case open buy they just say no solution and it appears MR4 is not coming until Jan. 6th.

We disabled the Application and device control policy and this did not seem to make a difference, however none of the options were selected anyway as it was just left at default after install.

How did you obtain MR4 beta?

Bunch of data loss over here due to this so just seems unacceptable and a fix should have already been released.

Hi, i know that this is an older post but has anyone tryed to add winword.exe and *.doc extention to centralized exceptions? It seems to be working for me until now. Charis.

Yes, that's the first things I tried. Made no differences at all.

I excluded winword.exe and excluded *.doc files from any any all testing for anything.

Didn't make a difference here.

MR4 relased yesterday Dec. 16th, on fileconnect.

Have not tried it yet to verify, still downloading.

So far, so good with MR4........

Is MR4 the accepted resolution for this issue? Do you know if it's the client or server version that matters?

Thanks,

MR4 (on the client side) IS an improvment, HOWEVER, NOW, since MR4 we don't LOSE files, but SEP interferes so bad that it's taking anywhere from 30 seconds to FOUR BLOODY MINUTES to save a file!

Open a document in Word takes from 15 to 30 seconds.

Close takes about the same.

Change and SAVE and your time skyrockets.

ONLY impacted on network, EXACTLY like the issue I posted about here with LOST files.

They are no longer lost but SEP interferes so badly it takes a very very long time.

Copy them local and they and word work great. Put file on network, sucks.

REMOVE SEP and the Word open, close and save times are cut by more than half, so SEP is still involved.

Fixed? No. Better? Yes.

Have you looked into SMB signing?

We had that issue a few years a go.

DC had different settings than clients and caused word and excel issues.

No - this is the first I've heard that term.

I guess I'll google...... unless you can explain here.

Another test - placed the files on a workstation at the remote office, accessed them from a computere here - saw the huge delays.

Removed SEP, delays GONE.

IF I access them from the servers in teh same building, NO problem.

If THEY access the files (they are in different city, LAN-TO-LAN networked back to here) from the server here, VERY slow. REMOVE SEP, speeds up.

So it's only going across the distance, with SEP enabled. Remove the distance, it's better, remove SEP it's better.

So even going workstation-to-workstation across the L-to-L connection was SLOW so it's NOT the file server itself.

We have 3 DCs and 45 offices outside of Des Moines -  and all of them are reporting the issue, but NOT the folks IN Des Moines.

Are all the clocks synced externally?

That can cause slowness too.

All computers synch time from the DCs. They synch time from a time-server functioning on a switch, and I'd have to recall how that's set......

Basically, everything points to the same place to get their time.

http://msmvps.com/blogs/kwsupport/archive/2005/04/02/40653.aspx

smb signing info

Dear All,

I upgraded the manager and clients to MR4, howeven, the WORD file still corrupted during SAVE....I am going to die soon.:smileysad:..anyone can help?

try to uninstall SEP client both on workstation and on server (with shared folder),

then run CleanWipe utility to remove everything about SEP

then install SEP MR3/MR4 again

hope it will help

I'm having the same problems as everyone else, with files being removed from USB Media etc.

I have the cd 1 and cd 2 of MR4.  Currently, I'm backing up the sep database, and I'd like to know if people have fixed this issue by just performing an upgrade and then rolling out the clients to the workstations?

For workstations that I know are affected, I can manually add them via the sep client deployment, but does upgrading the client fix the problem?

We had the same problem, and apparently when Symantec Endpoint is detecting autorun.inf files on a FAT Pen drive it causes that problem. It doesn't matter if autorun.inf file is launching something or not.

Error message is: Word cannot complete the save due to a file permission error.

If you format the USB stick as NTFS, MS Word file can be saved but that's not a solution for a big Network, so our temporary solution was to add autorun.inf as an Exception (to be ignored)...and it's working.

Their Official Solution is: http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008041108225248

"Solution:
This issue is resolved in SEP Maintenance Release 4"

...which apparently it didn't work quite properly.

Further Solutions will be apreciated.

* Do you have people who cannot save Word documents to a server share?

Save to a share actually works.  Saving to a partition on the local hard drive is our problem.

* Are your people running SEP version 11.0.3001.2224  (MR3)?

Sep Versoin 11.0.4000.2295 (MR4)

* Are your people using Word 2003?

Word 2007

* Do they attempt to SAVE a word document, and get an error that Word cannot save due to a permissions error?

Error 1

Word cannot open the file ~WRL0001.tmp. If the file is stored on your computer, there may be a problem with your hardware. If the  file is stored on the network, there may be a problem with the network connection. If you can copy the file, try saving the file in another location and opening it there.

 

Error 2

Word failed reading from the file (~WRL0001.tmp). Please restore the network connection or replace the floppy disk and retry.

 

Error 3

Word has lost data due to a bad network connection or missing floppy. Documents relying on this data are going to be saved and then closed.

* Further, is the FILE DELETED or MISSING when they TRY to save the Word file??

The file is not deleted completely.  It is reduced to 1kb and not accessible.  The TMP file is also not accessible.

I can stop this from happening by adding .TMP files to the Centralized Exceptions on the Client. But I would rather not exclude TMP files.

• The client is using Word 2007 in Compatibility Mode ( opening .doc rather than .docx).
• This problem does not happen when opening files from the network.  The only difference I have noticed is the temp file on the network is ~filename.doc and the temp file on the local drive is ~WRL0001.TMP
• Word 2007 locks up after the third error.
• The document is reduced to 1KB in size.

Has there been any progress with this issue?

For the record we are on a fresh install of MR4. Clients were running SAV10 before pushing out the MR4 client.

Hi JayW,

we are facing the exact same issues with Word 2000. I deployed 11.0.4000.2295 two weeks ago as an update for SAV10.

It is also happening with Visual Studio 2008, the tmp which are the edited cpp/h files, stay in the directory. It isn't possible to delete them until the pc gets rebooted.

It's very annoying, I'm glad our subscription is running out in about 2 months. 

we still have the issue with mr4. we had a case open in november 2008 for this problem and were told mr4 would correct this issue. we are using both word 2003 and word 2007.

any ideas? any symantec engineers assistance?

i had the same

but i kill keeping temp files by formatting the drive, where VS projects were stored

it helped

SEP still does not play well with Word. Although we don't lose documents and have TMP files all over like with MR3, now Word just takes FOREVER to open files, and 10 times forever to save files to the network.

I've proven it was SEP, see my other thread here, removing SEP solves it, or installing ONLY the av and firewall solves it, but put PTP with application and device control into play, Word slows terribly and at times, tells users that the file is locked and in use.

we only have antivirus and spyware installed and it is still causing a problem.

i am going to try the file cache fix and report back my results.

Count me in ...

SEP MR4 on Windows Server 2008

File Server on W2k3R2sp2

Client: Windows XP SP3, Word 2003, SEP11 with Antivirus and Antispyware only

I'm the one who will implement and deploy SEP11 to hundreds of SAV 9.xx/10.xx clients.  I'm testing it on a mix of w2k3 servers and xp machines, including my production XP laptop.  I already lost a number of Word docs or the changes I was doing was not saved.  I never realised it has something to do with SEP until I started looking at this forum.  I got Errors 2 and 3 mentioned by JayW.

Now, this project to upgrade SAV will surely be delayed until all issues are ironed out.

the file cache fix does not correct the issue. the problem still exists with word.

This issue has just returned to our network after disappearing in December last.

During our pilot of Endpoint these issues started on some machines in one office and it was thought that it may have happened as a result of a new switch that was installed at that time.

After doing some troubleshooting with duplex settings and the like, here are my findings.

While a computer has Endpoint installed with Network threat Protection option, the error appears.
While a computer has Endpoint installed with Network threat Protection option but is running on a 1gig link the error does not appear.

The issue just stopped occurring on our network but has now come back over this last week.

My feeling is that it has nothing to do with network config but is more to do with the definitions for Network threat Protection. We are currently showing v 28 January 2009 r3.

This is around the date that the issues started again for us.

The documents that are being used are all with Word 2002 SP3 and they contain some formatting but are not crazy. Some have allot of images but none are bigger than 2Mb in size.

Please, will someone from Symantec respond with some ideas or potential troubleshooting issues we could try?

Has anyone got any further with their calls logged with Symantec?
I will log my own shortly if there is no response.

Thanks
:-(

we are not using network threat protection and we still have the issue.

 maybe a patch for Word/XP triggered the bug again ?

I turned off oplock on the 2003 file server here last December and the issue straightened out for the most part, documents were saved, not lost, and there were no more permissions errors.

Microsoft found out on Tuesday this week and said "NO NO NO, that's what is slowing your network down, turn that back on!"

So I did.

In a few hours, dozens and dozens of calls, many dozen LOST documents - many many errors regarding permissions, full disk, etc.

I then had to turn opplock back off and do an emergency reboot to make it take effect.

No more locked documents, no more LOST documents, no more permissions errors, etc.

Now if you remove SEP, you don't have this issue, opplock on or off.

I had to turn lock off last year after we applied SEP MR3.

But then we had issues with VERY VERY slow word access over distances.

Microsoft said turning off opplock would reduce network speed by 10% and I needed it back on.

Yeah, right!

There's a terrible interaction between SEP and oplocks on 2003 server/XP client/Office2003.

We didn't have any of these issues before SEP, but then, look at all the MS patches that have come out too, so who knows!!!!

Fantastic explanation!

Only problem now is who do we blame? Is this an Endpoint issue or something with CIFS protocols?

Personally i see it as Endpoint not working correctly with what is pretty much an industry standard (CIFS and oplock).

Why did you need to turn off oplock when you originally installed SEP MR3? Was it related to dropped client connection under load by any chance?

SEP MR3 was rolled out week of Dec 19th or so. Within a day or so, we started getting reports of Word documents being lost. They'd open a document, make a change, go to save it and it either would exit without error and the DOC file was gone, or it would tell them they didn't have permissions or the disk was full, try another disk. At times, they'd get an error stating that the file was already in use by another process.

We tried everything! The only big change was that security patch for IE7 and our rollout of MR3 (from MR2)

So I did some digging after days and days of attempting tofigure it out and found folks stating that the locks caused similar issues, and several suggested turning it off in the registry (lanmanserver parameters)

So I did, rebooted, and guess what - no more file save errors, no more disappearing files!

However, the day before, I also rolled out MR4! I found out that EITHER would fix it - the opp lock OR MR4.

Those who had pre-release MR4 said no more problems. the next day I disabled the locking and the rest of the folks reported no more errors. So it was a 2-way fix. Either install MR4 or turn off locking.

I did both.

The weird part is that now we have MR4 on everything, and turning the locking back on kills Word again!

We've been working with MS for WEEKS on an issue with Word being very slow to open files, VERY VERY slow to save files in most locations (not ALL, but MOST)

So it seems to be some od and weird interaction between SEP and MS. And the suffering application in ANY case is Word.

OK, thanks a million Bill for taking the time to explain this one.

So far, the issue has only appeared on one of our sites, we will continue with our MR3 rollout as this is the version we have standardised on.

Atleast now we having somethin to try if and when this problem occures for our full deployment.

I can see us moving to MR4 sooner than anyone was expecting :-)

hi Bill,

Do you got any drawback after disable opportunistic locking? Will it cause any problem when a users editing a file, at  the same time other one want to  open it?

BR,

Derek

We have MR3 installed and see this issue randomly with the file disappearing because of permission errors (creates a temp file we can reopen).  XP workstation, SEP MR3 (AV, FW, App/Dev Control... all features enabled except for SNAC).  File-and-print servers are Windows Server 2003 SP2.  Permissions on shares are correct, etc.

Without disabling App/Dev control policies or turning off the locks, we added WINWORD.EXE as an entry into each of the Application control rules as an exclusion  "Do not apply this rule to the following processes --> winword.exe".   And BINGO - it worked.  No more errors.

This is a work around that has fixed the issue in our environment until we can fully test the new MR4 MP1a version.  Anyone else try this?  If you can't turn off the locks or deploy MR4, give it a try if you have App/Dev Control enabled...  it may help?

HI All,

we are using 11.0.4014.26

I am also facing the same issue with word files,

but it is strange that this will happen in my other local drives when I save in C drive without any problem  its save,

When we disable autoprotect  it is working fine,

I tried removing NTP and check but luck,

Timebeing we exclude .doc extension from centralize execptions.

Please find the attach image of the error.

Symantec: The product is becoming worse day by day. two of our big customer are replace our product with mcafee they were using symantec for last six years.

Regards
Mansoor Rashid

Hi Mansoor,

Pls do not exclude *.doc from centralised exception as there could be a threat to systems.

Pls raise a ticket for your issue at symantec.

Rgrds,
SAM

Symantec:- Is this a known issue in SEP 11.0 MR3 / MR4...???

Pls comment.

Rgrds,
SAM

Any reason why Symantec will not respond to this issue?

Please?

Even a simple... We dont know?

Without wasting any more time its better to log a case with Symantec Techinical Support Team. Let them analyze the same.

Tell them to take Webex of your sytem and troubleshoot the issue. If its a known issue, better it get fixed in upcoming MR4MP2. And if it doesn't get fix, then there would be lot of poeple posting the issue and finally symantec will need to release MR4MP2a as an unschedule release.

Rgrds,
SAM

We've been having the same issue at work. It's only affecting some users running Word 2003, and only some files on our network. Everying using Word 2007 is fine.

I figured out what was causing our issue; finding a solution apart from disabling proactive protection is something esle. Here's what's causing our issue, and it might be what's causing some of yours too.

The problem only occurs with Word 2003 file that have images in them - but we also have some Word 2003 files with images in them that save fine. The ones that are causing the problem are -

Words 2003 files which had images in them, but have been opened at some stage in Word 2007, then saved in a Word 2003 format. I had a quick look at that issue and it appears there is a separate issue with images embedded in Word 2003 being opend in Word 2007. Word 2007 inflates the image size, or does something weird with the formatting. You can save it as a 2003 documents, and the image and document look fine. But at soon as i try and edit and save the documenet, the error occurs. Doing a "save as" works fine. But the problem still occurs trying to edit the "saved as" file too.

Opening the word document and removing all the pictures, then trying to save it caused the problem to occur again. Opening the document, removing the image, and doing a "save as" worked (as we know it would because "save as" works fine. But this time, when I opened Word 2003 document without the image file in it, I was able to save the document without the error occuring.

I then opened up the Word 2003 document which contained the image (but wouldn't let me save), pasted the image into mspaint (i didn't save the file) pasted it back into the Word 2003 document which no longer contained the image and saved the file. I was then able to open and modify the document, and save the changes afterwards, without needed to do a "save as"

The original document size was around 4.5 mb's. After i removed the image and did a "save as" the file size was around 1.7 mb's. The size of the document after pasting the image back into it (which changing the format of the picture) was 1.95 mb's.

This leads me to believe that it might be both a microsoft and symantec issue. Microsoft needs to fix the problem with imaged from a 2003 document being inflated once they're opened in 2007 (they may already) and symantec need to let their product know that it's not a virus, it's just an inflated microsoft image, let it do what it needs to do.

Check with the users who are having this issue, find out if you have people in your organisation running 2007 who are editing the files. Check the size of the files to see if they appear larger than what they should be. I'm hoping there is a fix out there somewhere because the only work around would be to have every document that is affected fixed by removing the image(s) then re-inserting it while using Word 2007, then saving it as a 2003 file. I'm not sure how this will affect future work though, is the user then saves it in 2003, will it change the formatting of the picture, so when it is opened again in 2007, the problem re-occurs...??

I had other problems to look into so I couldn't spend any more time finding out anymore info. But i'm hoping someone knows of one, or can confirm that this is what's causing their problem too.

Thanks andrewm1978@hotmail.com for the great description.

You may want to get hold of MR4MP2.

I've been doing some testing with this version over since its release and so far it seems to be ok

I have found a resolution for this issue. I uninstalled the Network Threat Protection part of SEP. So I am assuming that you can either uninstall or disable Network Threat Protection to achieve the desired result. Hopefully this helps.

Hi Kakarot1980,

Thanks for the efforts but that has already been suggested in previous posts and although it does work... its not really a solution. You removing the SEP component that is needed :-(

The solution according to Symantec is to upgrade to version MR4 MP2.

This is what we have started to do for anyone who complains of this issue.

We will then deploy a later and more stable version of SEP to all our clients.

I had the same issue too... some advised me to exlude the winword.exe. but i think there something should be done in the policy side of the SEPM...

CodeJACK,
  sorry, I didn't read the entire thread. I installed MR4 MP2 without Network Threat Portection and am still having this issue. Unfortunately, it is not fixed with this release. Dang this is frustrating!

Yeah, we have this issue, with MR4...

Specifically, 11.0.4204.75

Just had a user lose her document.

We had these symptoms here. Clients are Vista SP2/Word 2007/SEP MR4 MP2.

We have not seen it since the server was recently upgraded from WS2003 SP2 to WS2008 SP2. Still crossing my fingers. Perhaps it's a problem with SEP & SMB that doesn't happen with SEP & SMB2?