We haven't run into this yet, but our tsm server is only 6.3.4, and many of our clients are that vintage as well. Thanks for the heads-up, will keep our eyes open here.
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Robert Talda Sent: Friday, November 04, 2016 5:08 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Is anyone supporting Spectrum Protect clients running on systems using Microsoft's System Center Endpoint Protection ? Folks: Our university just began an major rollout of the Microsoft System Center Endpoint Protection (SCEP) product (replacing the Symantec equivalent) and we’ve noticed some new behavior from the Spectrum Protect client for Windows. In particular, when the client encounters an infected file, it ends the backup, writing the summary statistics to the log and exiting with an error code 12. We caught this behavior when a backup of a volume with 2.9 million files ended after only 260K files were processed. What we :think: might be happening: the Spectrum Protect client has detected the change to file, and attempts to read it to back it up. This triggers a scan by the SCEP that reveals the virus. The SCEP then blocks the Spectrum Protect client request, resulting in the following error message: ANS9999E ..\..\common\winnt\ntrc.cpp(771): Received Win32 RC 225 (0x000000e1) from FileOpen(): CreateFile. Error description: Operation did not complete successfully because the file contains a virus or potentially unwanted software. It appears that this stops the Spectrum Protect client producer “thread” from walking the filesystem; and then, when the “consumer” thread catches up, the client exits; such as in the backup that generated the error message above, the last lines written were: Normal File--> 444 \\<filepath>\<filename> ** Unsuccessful ** Total number of objects inspected: 267,699 Total number of objects backed up: 26 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 98 Total number of objects failed: 0 Total number of objects encrypted: 0 Total number of subfile objects: 0 Total number of objects grew: 0 Total number of retries: 0 Total number of bytes inspected: 168.77 GB Total number of bytes transferred: 40.08 MB Data transfer time: 0.10 sec Network data transfer rate: 375,325.92 KB/sec Aggregate data transfer rate: 5.19 KB/sec Objects compressed by: 0% Total data reduction ratio: 99.98% Subfile objects reduced by: 0% Elapsed processing time: 02:11:39 And the backup exits with a return code 12. It :feels: like the Spectrum Protect client is being “nicely” killed by the SCEP for accessing the infected file, but it may also be a bug in the Spectrum Protect code. I should note that guaranteeing and deleting the infected file allows the next backup to proceed - until it encounters an infected file. (a.k.a. Apply, lather, rinse, repeat) This output was generated by a Spectrum Protect client for Windows v7.1.4.0 running on a Windows 2012 Server R2 platform. The backup was initiated by a script, rather than by the TSM scheduler, but I believe the same behavior will happen for a scheduled backup. I also believe this will happen on Apple Macintosh OS X systems that are running SCEP as well. I’m working with our security office to set up test scenarios to verify this behavior. But I thought I’d reach out and see if others have noticed this. Thanks! Bob T. Robert Talda EZ-Backup Systems Engineer Cornell University +1 607-255-8280 r...@cornell.edu
