In this first part of this four part series on Microsoft Data Protection Manager (DPM) 2012 I cover the installation as well as the new Centralized Console.
Protecting your data and systems running Microsoft workloads is paramount and the best way to do that is with Microsoft Data Protection Manager (DPM). This is an enterprise class product that’s gone from strength to strength over the last few versions. In this review we’ll look at DPM 2012 Release Candidate.
In this four part article we’ll first look at installation of DPM 2012 RC and the new Centralized Management capability. In part 2 we’ll cover the scoped DPM console as well Role Based Access. Part three will cover other small and large improvements in DPM 2012 whilst the fourth part will look at Certificate Based Protection as well as some concluding remarks.
DPM 2012 installation
The overall installation experience has changed very little from previous versions. As before you can select to install a local instance of SQL Server (2008 R2 in this version) but larger environments are likely to use the option of a remote SQL Server. Multiple DPM servers can share a SQL server; each requires about 2.5 GB of memory so scale your servers accordingly. The underlying OS can be Windows Server 2008 / 2008 SP2 or 2008 R2 with or without SP1.
If you’ve been trying out DPM 2012 beta be aware that it can be upgraded to DPM 2012 RC which in turn will be upgradable to DPM 2012 RTM.
Whilst both DPM 2010 and 2012 servers can share a tape library (provided it’s recognized by device manager in Windows correctly) you can’t have DPM 2010 and 2012 servers talking to the same tape library, something to take into account for your upgrade planning.
The new DPM console has adopted the ribbon at the top as well as following suit with other System Center products with a wunderbar on the left a la Outlook.
Installing DPM 2012 is characteristically smooth and easy.
Centralized management of DPM 2012 and DPM 2010
To really enable DPM 2012 to reach enterprise scalability scenarios, in a manner that can be effectively managed, required a change in the management paradigm. If your company has two or three DPM servers, perhaps in separate locations, managing them independently isn’t a big deal. But if you have tens or even hundreds of DPM servers that approach quickly becomes expensive, notwithstanding the capabilities of PowerShell scripting.
DPM 2012 provides a centralized console for multiple DPM servers but rather than building a separate console it’s integrated with a console that many corporations are already using – Systems Center Operations Manager (SCOM). For businesses that rely on a third party ticketing system the SCOM integration will ensure that DPM alerts flow nicely into those systems as well. DPM 2012 beta supported SCOM 2007 R2 but the Release Candidate only supports SCOM 2012 RC. Both versions might be supported at RTM but we’ll have to wait and see.
To enable the Central Console is a three step process, first you’ll need to have SCOM 2012 RC installed and then run the main DPM installation screen and select to install the Central Console on the SCOM server. Finally the new Management Packs need to be imported into SCOM; if you’re thinking of trying out SCOM 2012 detailed instructions are available here.
Large businesses that have deployed DPM 2010 will be glad to know that the centralized console will manage DPM 2010 servers as well as DPM 2012. The centralized management extends further and lets you perform remote recovery, take corrective actions remotely and consolidate alerts across your entire backup environment. The Actions pane on the right is context sensitive and presents DPM actions appropriate to the object selected in the tree hierarchy. The tested scalability limit for the Central Console is 100 DPM servers or 50 000 protected data sources.
Using Operations Manager as the Central Console for DPM 2012 is an excellent move and it’s also very well implemented.
Raised Alerts are grouped by data source, disk, tape and tape drive, protection groups and replica volumes alerts, which makes it easy to focus on the area you need to troubleshoot. The central console on SCOM also filters alerts to match your SLA; say you have a guarantee to back up a data source every 4 hours but you actually run backups every hour, if these backups fail the DPM console will have an alert for each failure but SCOM will only raise an alert when the SLA is actually breached.
In part 2 we’ll cover the scoped DPM troubleshooting console as well as Role Based Access.