Well, the day has come and you are thinking about installing SP1 for DPM 2007 to your DPM environment. There are a few things you that you need to be aware of before you install this Service Pack to any DPM servers. Let’s take a moment to discuss these before unleashing SP1 into your environment haphazardly. In the event you do make the decision to back SP1 out of your DPM environment, we will cover the steps needed to make this happen. Of course, we will first discuss how to best prepare for the installation of the service pack.
To begin with, DPM 2007 SP1 includes a lot of new functionality as well as numerous fixes that will without a doubt stabilize your DPM environment. As with any churn to the binaries on a server, there is always an inherent amount of risk involved. In order to mitigate the risk involved and try to make this as positive an experience as possible, take some precautionary steps.
Do you know what DPM patch level you are running currently without looking at the DPM server?
If you know and are absolutely sure that you know, then kudos to you; since I am a precautionary doubter by nature, let’s confirm. Two ways to confirm this are covered. First, from within the DPM Administrator’s Console, look for the ‘I’ which looks like the informational icon seen in the Event Viewer in the upper right of the console. Double clicking on this will show you a screen that provides the build number of DPM which will appear near the bottom of the screen and may resemble “2.0.8107”. This can be used to determine the patch level of DPM as DPM 2007 without any patches will have a version number of “2.0.5820”.
Alternatively, you can open SQL Query Analyzer and connect to the DPMDB and run the following query “Select name, buildnumber from tbl_AM_AgentPatch”. This query will return the necessary information to determine what the patch level of the DPM Server is.
Now that we have that information, let’s take a look at protecting the data that is currently in production before we introduce SP1.
If you have applied any patches like the Feature Pack from KB949779 which modified the database schema, a backup of the database has already been taken for you. You will find this backup of the DPM database in a file called QFEdpmdb.bak in the C:Program FilesMicrosoft DPMSQLMSSQL.1MSSQLBackup folder on the DPM server if you have a local installation of SQL on the DPM Server. If your DPM server is utilizing a remote installation of SQL Server, then you will find the backup of the database on the SQL server, under the MSSQLBackup folder on the server.
Protect this file as this is an older backup that can be used as a last resort before reinstalling from scratch and having to start over with DPM. You may want to consider renaming this file to include the build number of the database that it contains. Next move this file into a safe location.
With that file protected, you will now need to open a command prompt and run the following command to take a backup of the DPM database. Navigate to C:Program FilesMicrosoft DPMDPMbin and run the command ‘dpmbackup –db’. Depending on the size of the DPMDB database, it may take some time to complete. Once this backup completes, it will create a file called DPMDB.BAK in the C:Program FilesMicrosoft DPMDPMVolumesShadowCopyDatabase Backups. This backup should be renamed to give you an idea of what the build number is and then the files should be copied into the same folder as the QFEdpmdb.bak file that was moved earlier. Now you have both of your backups labeled clearly so you know what they are and they are safe.
The reason for this is that if SP1 needs to be removed, a full uninstall of DPM will be required and we don’t want these copies put at risk when the server is cleaned up of DPM. Regardless of whether you intend to upgrade DPM to SP1 right away or not, it is strongly recommended that you have a scheduled task run the ‘dpmbackup –db’ command on at least a weekly basis and have that file copied to a location where DPM can back it up. Local Data Source protection was introduced with the Feature Pack from article number KB949779 so this is an option.
With DPM backups taken, and moved to a safe location, you are ready to upgrade your DPM server to SP1.
Returning DPM to a Pre-SP1 version
Invariably, there are some situations that necessitate that DPM 2007 SP1 be removed from the environment while additional testing is done. It will not happen in many cases, but given the odds, it will happen. Let’s now take a look at the steps necessary to return DPM to a working version prior to the SP1 upgrade.
Considering that the SP1 installation routine will take a backup of the DPMDB database during the installation of the service pack, we can utilize that copy of the database for our recovery.
Working under the premise that the QFEDPMDB.BAK file has been moved to a safe location out from under the DPM folder structure as stated above, we will need to uninstall DPM from the server. On a Windows Server 2008 system, this is done by navigating to Control Panel and selecting the Programs and Features option. This will generate a list of installed applications like AddRemove Programs does for Windows Server 2003.
On both Windows 2008 and Windows 2003 servers, look for the Microsoft System Center Data Protection Manager 2007 entry and remove it. On a Windows Server 2008 system, there is an Uninstall option at the top and in Windows Server 2003, click on the Change/Remove button to the right. This will start the wizard to remove DPM from the server. This is necessary in order to return the server back to a Pre-SP1 build of DPM as the modifications to the database schema cannot be reversed without uninstalling.
Follow the wizard to the Uninstallation Options screen where 2 radio buttons will be presented. The first is the Retain disk-based recovery points button. This is likely the option you will select as these recovery points can be used in recovery scenarios after the DPM server is back up and running with a pre-SP1 build. If you choose the Remove data option, you must understand that any recovery points created previously before and after SP1 was installed will be lost and cannot be recovered.
Click on Next and continue through the wizard until the uninstall of DPM has been completed. There is a notification screen at the end that tells of tasks that were not performed by the uninstall routine. One complete, you will need to reboot the DPM server.
After the server comes back up and you have logged in, you will need to navigate to the SQL Server Management Studio and delete the DPMDB database. This must be done in order for the reinstallation of DPM to be successful. The installation routine will detect if there is already a DPMDB in existence on the SQL server instance selected. Once the DPMDB database has been deleted, you can begin the install of DPM on the server.
Install DPM just as you did originally making the same settings changes during the installation. Once the installation completes and you are presented with the Installation Success screen, unselect the Open DPM 2007 Administrator Console when the wizard closes checkbox. This is not the right time to open the console as this is a plain installation with no data. Choose Close to terminate the wizard. Now the patches that were on the DPM server prior to SP1 will need to be reinstalled. If you have the patch from KB949779 or anything after it, you can start with it and then apply the last patch that was applied to the server. The reasoning here is that from the KB949779 patch forward, all patches were cumulative.
NOTE: If you are unsure what build of DPM you were running, you can restore the DPM database using the following commands and then run the query (“Select name, buildnumber from tbl_AM_AgentPatch”) to see what build number DPM was prior to applying SP1. At that point, you will know which patches to apply.
Once the DPM server has been patched, you will want to rename the new QFEDPMDB.BAK file that was created after applying the KB949779 patch so that you will have a working clean database to revert back to if needed.
Restore the DPM Data
Now that DPM has been reinstalled and patched, you will need to restore the database and get DPM back up and running. In our recovery example, the database (QFEDPMDB.BAK) backup file was moved to C:DPM_BACKUP folder prior to removing DPM. To restore the data, open a command prompt using StartRun’CMD’ and navigate to the C:Program FilesMicrosoft DPMDPMbin folder (understanding that this is the folder that DPM was installed to).
Type the following at the command line and press enter.
Dpmsync –restoredb –dbloc c:DPM_BACKUPqfedpmdb.bak
This will restore the contents from the backup file into the existing DPM database. Depending on how much data has to be restored, this may take some time.
From the same command prompt, now type and execute the following command.
This command can take a very long time (hours) for DPM database that are very large and have been protecting large numbers of data sources. As there is no progress bar, do not be alarmed if this process appears to be hung and non-responsive. If the process is still running after 8-12 hours, you may consider opening a support incident with Microsoft.
When it completes, you can then test the DPM installation by opening the DPM Admin Console. If any agents have been upgraded to the SP1 version, you will need to remove the agent and reinstall it which will result in the machine being restarted so this should be taken into account when backing out DPM SP1 from the environment.
The DPM Admin Console should reveal the agents and data sources that were being protected prior to the application of SP1. This completes the restoration but there is still the matter of stabilizing the data sources that DPM is protecting.
As with most application recoveries, a Consistency Check must be run. Since the entire DPM server was restored to a pre-SP1 state, all of the data sources will show inconsistent. A Consistency Check will be required on each data source in the environment and this may take considerable time and storage space to complete.
As the data sources show a Protection Status of ‘OK’, then DPM will continue protecting them based on their original schedules. If there are portions of this process that were not clear or missing, please send us your comments.
Support Escalation Engineer
Enterprise Platforms Support