Data Loss Prevention

Has anyone experience extremely slow scan times and low bytes scanned, e.g. over 23 hours to scan approximately 6MB of data?  I've gone through and look at all the usual suspects (NIC speeds, placement of the agent, permissions, policy...) and have had no success in speeding up the scan times.  I have even recycled the Discover servers multiple times to ensure there was nothing hung up.  The odd thing is when I perform file share scans I get the speed and data results that I'm expecting.

If anyone has expereinced this and found an answer or work around your guidance would be greatly appreciated!!

Thanks,

Lonnie

Does anyone have any informtion on what are the plans and tentative release dates for Vontu to support SharePoint 2010 Scanning.  I would assume based on company adoption of an updated platform that there are many who have migrated from 2007 to 2010.

Thanks again!

Lonnie

DLP 11.0 currently supports scanning of Sharepoint 2010 through the Sharepoint Web Solution.  I have used it and it works very nicely. 

Regarding your scanning speeds, yes, Sharepoint scanning is slow, but should not be that slow.  Are you using the old "scanner" or the new Web Solution?  In ideal conditions, I've been seeing scan rates of about 2 GB per hour with the Web Solution using one Discover server.  Not lightning fast, but not unmanageable either.  I'd think the culprit is your Sharepoint honestly, if it's that slow.  Think of this as a Sharepoint user who is just rapidly reading document after document...it's going to "pull" them as fast as it can process and read them (it does it one doc at a time).  Since you've already confirmed that the Discover Scanner itself can process quickly (via a regular file system scan), then it seems like it's a matter of how fast Sharepoint is able to serve those documents up.

~Keith

Thanks Keith!  We are using the new Web solution.  We've got the Enforce on one server and the Discover on another; both virtual.  We have employed the agent in the SharePoint solution.  I had the SharePoint Admins screen shot through the admin console where "symantec_dlp_solution.wsp" was installed (servers) and how it was deployed "Globally Deployed".  It's also showing on the "Front-end Web server" under the Deployment Server Type.  I ensured that they followed the same steps as when it was deployed for 2007 but to no avail.  Are there other settings on SharePoint 2010 that I should be aware of?

Thanks again,

Lonnie

Should be pretty much exactly the same install steps.  I rereviewed my notes from the install I did on Sharepoint 2010 and the steps were exactly as outlined in the help notes on the subject.  I'm unclear what your current issue is...is it that you can't scan Sharepoint 2010 at all, or that you're still having performance issues with the scan.  If it's the former, I would first verify the user privileges of the account you're scanning with.  In our case, we gave the user "Full Control".  If it's the latter, again, I'd suspect it's Sharepoint, not the scanner, that's having the issue in serving up content in an expedient manner.

~Keith

We can scan but it's extremely slow (e.g. 1 site took over 24 hours) and not able to scan as fast as it should have.  I did have a discussion with support and the issue was resolved.  I also validated with the SharePoint team that we have the "enumerate permissions" as part of the ID (the ID associated has farm level credentials).  Ultimately, it was all around the setting on the server "Discover.SharePoint.ACLFetch".  Once I put the setting to False then it worked as it should have.  The only bad thing now is that there is no ACL data but I have gotten them to escalate as I couldn't imaging we're the only one having issues with that.

I really appreciate your assistance!

Lonnie

wow....you're not kidding.  I just ran a test on this to assess the impact of fetching ACLs for SharePoint scans.  We went from 11 GB scanned in about 24 hours (less than 500 mB/hr) to up to 9 GB/hr.  Obviously there's something clearly amiss in that, as the discrepancy is just far too high.

Funny, with the old SharePoint scanner, I guess I had learned to accept that these scan types were just going to be slow regardless of what you did.  With ACL Fetches off, this is rivaling the speed of file share scans.  Yes, it would be better to have the ACLs, but at least you do still get the Created By and Modified By attributes.

Please post up here if they get a fix for you.  I've already spoken with one of my customers about this, and we've come to the conclusion that we could easily do a quicker "inventory" scan with ACLs turned off, and then, if needed, target specific sites with a subsequent scan with ACLs turned on to get the more detailed info.

~Keith