It occurred to me that it might help if I explain why I think this is an important issue.
1. We cannot tolerate routine exceptions or errors. We run BE for many small business client sites. These sites do not have on-site IT staff, and my staff or I may not visit a given site for a month or more at a time. It is important that any anomalies be noticed and dealt with. Therefore, we cannot tolerate routinely having messages that an experienced tech would ignore. Not only because non-technical people don't have the expertise, but because technical people can easily miss important issues when they are buried amid trivialities.
2. Custom exclusion configuration is prone to errors; it needs to be minimized, justified, standardized and documented. In the past, I've set up the sites without exclusions, watched to see what got skipped, and set exclusions accordingly on a site-by-site basis. This is becoming less and less practical, as updates, service packs, etc., change the status quo. It tends to be time-consuming, and it's difficult to bill clients for such baby-sitting. And I have had the experience of being unable to restore important data that was accidentally excluded.
3. The files creating the exceptions are, for the most part, normal parts of the server OS/environment, or software Symantec itself sells. Many of them simply don't need to be backed up, as they are temporary/work files that will be automatically recreated. Some of them are tricky to skip correctly, due to naming conventions. Some of them may require special measures, or special open file settings. Symantec/Veritas is in a much better position than we are to know how to deal with these files.
/kenw
