In a long overdue and welcome move, Symantec released this summer a Backup Exec 2010 management pack for Microsoft System Center Operations Manager 2007 (SCOM). The last time Symantec released a management pack for Backup Exec, it was for the Backup Exec 12.5 release in 2008. That older management pack was actually written for Operations Manager 2007’s predecessor Microsoft Operations Manager 2005 (MOM). While a community-converted and manually modified version of the old management pack could run poorly in SCOM 2007, most organizations have had to forego integration of Backup Exec into their SCOM 2007 monitoring infrastructure until now.

Symantec is a major player in the backup software space, holding an estimated 60% market share. Many shops trust the Disaster Recovery (DR) readiness of their whole business — SQL, Exchange, Active Directory, SharePoint, Shared File data, and more — to Backup Exec. For small operations with just one Backup Exec server, it’s not too difficult to configure the software to email or otherwise alert administrators to backup failures. However once you scale out with some or many other Backup Exec servers to monitor, the enterprise backup picture can get progressively more difficult to manage.

Symantec has a software option for a Central Administration Server that consolidates backup job management across Backup Exec servers. If you need to copy lots of backup job details between servers, or enforce complex backup policies across backup media server farms, this can be a great option. However it’s costly, adding over a thousand dollars license cost per backup server. If you have deployed SCOM, and you are primarily needing a simple up-down check on your Backup Exec jobs and central collection of alerts relating to backup, the new Backup Exec management pack fills this key role very well and at a great price-free!

What the management pack looks like

The Backup Exec management pack increases the value of Backup Exec for customers that use Microsoft System Center products for systems management. It’s a fundamentally sound idea to present server backup status in the same “pane of glass” context as other server health metrics. Importing the Backup Exec management pack creates a new folder in the SCOM console: Symantec Backup Exec. Figure A shows the Alert view of the management pack. Context-sensitive tasks appear in the Alert view to restart Backup Exec services on server and agent computers.

Figure A

SCOM as a central collection facility for all Backup Exec agent and server alerts (click to enlarge)

In the background, two discovery processes will automatically check all Windows Computers for the presence of the Backup Exec server or remote agent software, and discovered instances are added to one of four SCOM groups: one group for each of the three releases of the latest Backup Exec 2010 version, and one group for all versions of Backup Exec prior to Backup Exec 2010. The Backup Exec server and agent discovery fires every fifteen (15) minutes by default. In larger SCOM environments (to minimize “config churn”) consider an override to reduce the frequency of these two discoveries to just once a day.

Using the management pack for backup management

The management pack supports all versions of Backup Exec server and agent, versions 11.0 and later. This is important for large environments that may have many different Backup Exec software versions in use. The Backup Agent State view has handy columns that list the version and build number of every agent, making it easier for the distributed enterprise to keep Backup Exec agent builds in sync.

The SCOM health model is put to good use in the Backup Exec management pack. The health explorer for the Backup Exec server component rolls-up the status of 21 monitors for each backup server, making it easy to spot critical events like backup failures, and operator-assistance issues like “waiting on tape to be inserted” events. Figure B shows the Backup Exec server state view on the left that makes it easy to spot which backup servers are in trouble. On the right of Figure B, the detail text in the state change event spells out the exact trouble, in this case, the “backup to disk device is offline.”

Figure B

Tracking down the cause for backup failures in the SCOM health explorer (click to enlarge)