i already read a lot of community- and knowledgebase-articles here but I have still questions. I know about the recommended exclusions when using Backup Exec (2010) as a media server or as a remote agent, but I have a sympton, I would like to discuss here...
Up to now I have no exclusions for processes of Symantec Backup Exec, e.g. the beremote.exe but I have complete exclusions (including subdirectories) on Exchange 2010 database directories. Let's say I have a seperate partition with a root-directory DATABASE containing Exchange databases and a seperate partition with a root-directory LOGFILES containing the Exchange logfiles since the last full backup. Both root-directories (DATABASE and LOGFILES) are excluded for read and write (including further sub-directories) from VirusScan.
I then checked those exclusions by copying several files inside of these 2 directories. In the 'On-Access Scan Statistics' window, those directories were not mentioned. When I decided to copy several files from one of these directories to e.g. C:\TEMP, then only the C:\TEMP directory was mentioned several times in the 'On-Access Scan Statistics' window, because C:\TEMP is not excluded. So far so good!
Now, the question is...
Why are some Exchange logfiles (from within a LOGFILES sub-directory, which is completely excluded in VirusScan) scanned and mentioned in the OnAccessScanLog.txt as infected files during remote backup with beremote.exe (Process from Symantec Backup Exec 2010) ???
Is it because beremote.exe takes the data from the ShadowCopy, because we use AOFO and VSS and all exclusions inside VirusScan are no longer valid for VSS ??? To me, that's the only plausible answer to this behaviour.
Furthermore, using VirusScan 8.7.0 Patch 4 with the same upper mentioned exclusions and under Exchange 2003 reports no infected logfiles during backup with beremote.exe from Symantec Backup Exec 12.5 !!! Has anything changed with how beremote.exe behaves under Backup Exec 2010 or has anything changed with logfiles under Exchange 2010 ?
Now, I am really curious, what lets beremote.exe from Backup Exec 2010 decide to scan my Exchange 2010 logfiles, allthough those are completely excluded.
Best regards and many thanks in advance for your efforts to enlighten me,
Did you get anywhere with this? I'm seeing the same problem on our exchange server backups; they failed because they could not read from one of the log files; when I copy that file to a place outside of the excluded folders and try to open it, VSE detects a virus and deletes the file - which I think is what BE is experiencing - the file on the snapshot is being deleted when it attempts to read it (because the exclusions don't apply to the snapshot, only the real disk).
I've disabled VSE temporarily now and am running a backup to prove this is the problem.
Would be good to know what exclusions we'd need to use to get around this I guess.
the topic is still on my todo list! Unfortunately other tasks forced me to disable VirusScan on the Exchange 2010 server for the time being. I suppose it will at least be necessary to exclude the process BEREMOTE.EXE, which should also boost performance of backups from file server as well.
I will get to this later again and post any positive results, rest assured!
DiWiMessage was edited by: diwi on 7/24/12 7:15:10 PM CEST
Thanks for the swift response!
Yes I was thinking I'd have to do the same (exclude BEREMOTE.EXE) - the backup I'm running at the moment with VSE disabled is flying too.
Will let you know my results too.
I've confirmed my problem was definately VSE (8.7 in my case) deleting an Exchange 2010 log file within a VSS snapshot that was being backed up, causing the backup to fail.
For anyone else struggling with this problem, I got eventlog entries like:
Event ID 257, McLogEvent
The file \Device\HarddiskVolumeShadowCopy12\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0881358643\E0000059473.log\0000360d.js contains the JS/Exploit-Blacole Trojan. Will be deleted after the next reboot (Clean failed).
Event ID 489, ESE
eseutil (5952) JetDBUtilities - 7700: An attempt to open the file "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0881358643\E0000059473.log" for read only access failed with system error 5 (0x00000005): "Access is denied. ". The open file operation will fail with error -1032 (0xfffffbf8).
In the OnAccessScanLog:
\Symantec\Backup Exec\RAWS\beremote.exe \Device\HarddiskVolumeShadowCopy9\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0881358643\E0000059473.log\0000360d.js JS/Exploit-Blacole (Trojan)
24/07/2012 15:57:04 Will be deleted after the next reboot (Clean failed) NT AUTHORITY\SYSTEM C:\Program Files\Microsoft\Exchange Server\V14\bin\eseutil.exe \Device\HarddiskVolumeShadowCopy12\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0881358643\E0000059473.log\0000360d.js JS/Exploit-Blacole (Trojan)
Note that the first one is the BackupExec remote agent but the second is ESEUTIL.EXE - I assume this is the Backup Exec remote agent running the consistency check.
The actual location of the log file which was detected to contain 'JS/Exploit-Blacole' and subsequently deleted from the VSS Snapshot was this server's D:\ drive, where there are exclusions for VSE which are working, thus the exchange server is working fine, but the backups are/were failing.
Our Backup Exec 2010 R3 backups were failing for this Exchange database with:
Verify- \\XXXXXXXXXX\Microsoft Information Store\Mailbox Database 0881358643 XXXX
The false-positive matched logfile has been truncated now by the successful full backup I just ran with VSE disabled, so I can't test this further, but my plan is to add exclusions for the processes beremote.exe and eseutil.exe, unless I can wildcard the drive part of the exclusion.
Anyway, hope this helps someone - the point is that VSE does not appear match path-based exclusions starting with a drive letter to the VSS snapshots that BackupExec backs up from.
A keen observation.
This is why Support will advise to use **\path\folder\etc when defining "pattern" exclusions, because the product does not always see the file object as %driveLetter%\path\folder\etc but instead sees Device\Volume\path\folder\etc. Any exclusion based on drive letter would therefore fail to match.
** is interpreted as anything, including subfolders.
**\mypath\myfile.txt, as an exclusion, would exclude:
You could alternately enter the exclusion using both formats (drive letter, and device name).
Ultimately, the detection log tells you "What we saw" as the file object so it's easier to see what you're supposed to be excluding for an unwanted detection.
Very handy - thanks for the info, I wasn't aware of the use of ** in exclusions - I'll update them accordingly rather than exclude the whole of the BE processes.