What on "God's" green earth was the logic behind removing from Backup Exec 2012 the ability to backup transaction logs (really SQL transaction logs) from/for Microsoft SharePoint (at least version 2010) thus allowing them to eventually grow to very large sizes?!? Once a Backup Exec Exec 2012 media server detects SharePoint resources on a SharePoint server(s) via the formerly called "SharePoint agent" installed/enabled, you lose ALL ability to select/de-select related SQL Server databases for backup (i.e., the SharePoint databases in the SQL Server selection list on the Backup Exec media server appear grayed out but checked). Your related article describing this condition but no justification for this boneheaded RE-design decision is here: http://www.symantec.com/business/support/index?pag... The article says that I should switch to the "Simple" method of recovery for the database in SQL Server. Really??? You actually want end-users to do that in an business/educational/enterprise environment?!?!? Even if so, how are people (like us) suppose to backup mirrored SharePoint databases where this SQL Server feature is only possible via fully enabled transaction logs??
Ya know, I'm slowly (VERY slowly!) beginning to warm to Backup Exec 2012 after 18+ years of experience with prior versions all the way back to Backup Exec 5 or 6 (mid-90's). However, you/Symantec/your designers really made some *stupid* (sorry - no other word for it) design decisions with this latest incarnation of the product. <scratches head/> Heads really ought to roll on this one, and I think you know that! When the SP2 beta service pack for Backup Exec 2012 sees the light of day, could you please ensure that this SharePoint transaction log backing up functionality is fully restored to the product as was the case with Backup Exec 2010? Thanks in advance. :-(
~Kent