In this post I’ll be discussing the two most common errors associated with launching the System Center Data Protection Manager 2007 administrator console, the common causes of these errors and how you can easily address them and get back up and running quickly.
The first is the "ID: 917" error. The error shown below is typically the most common one observed and is easily identified by the “ID: 917” along with the message “Connection to the DPM service has been lost” in the body of the error:
For this type of error there are a few things that you will want to check first. The first and easiest will be to check to ensure that the services themselves listed in the error are all enabled.
Next, as the error alludes, the cause could be due to the database running in recovery mode. The preferred method to address this is to open a command prompt (Administrative on 2008+) and execute the DpmSync.exe tool with the “-sync” switch. Doing so in most cases will normally remove the dbRecovery flag from the DPM database and allow the service to start properly and the console to open. You can also manually check the database for this by taking the steps below, however we highly recommend that you use the Dpmbackup.exe tool to first take a backup of the DPM database before opening or making any changes within it:
1) Connect to the SQL server with SQL Management Studio and the DPM database (e.g. MS$DPM2007$) 2) Expand Databases -->DPMDB -->Tables -->dbo.tbl_DLS_GlobalSetting 3) Right Click and choose Open Table 4) If DbRecovery is set to 1 set to 0 5) Restart the DPM Service
In addition, here are some other common causes of the “ID: 917” error when launching the DPM Administrator console
1. Problems connecting to the remote SQL server hosting the DPM database. To test for connectivity issues I find it easiest to create a new text document and rename it with the “.UDL” extension. For example, if you’re text document is named “SQL.txt” rename it to “SQL.udl”. Once this has been done double click on the file and then type in the name of the remote SQL server along with the database name (default DPM database name = MS$DPM2007$). After this click on the “Test Connection” button to test connectivity to the SQL Server and database as demonstrated below. If you find that there are issues connecting then you will need to focus on the network, SQL Server, name resolution, etc. to determine why the DPM server is unable to connect to the remote SQL Server or the database itself.
2. Disk Quotas have been enabled on the DPM installation drive and/or for the "MICROSOFT$DPM$2007" account. If you find this is the case please disable the quota or alternatively set the "MICROSOFT$DPM$2007" account to no limit. Please see the link included below for more information on disk quotas and how to manage them.
3. DPM database corruption as caused by disk issues, file system corruption etc. For this you will need to restore the DPM database from a recent backup. Please review the links below for additional information on how to backup and restore the DPM database.
4. The absence of the DPM TEMP directory in the following path "C:\Program Files\Microsoft DPM\DPM\Temp\MTA" or the share itself. Recreate the path "C:\Program Files\Microsoft DPM\DPM\Temp\MTA" directory or re-share the MTA folder as “MTATemptStore$”.
5. If tape library sharing has been established verify that the library server can be contacted (ping, UNC, etc.) and if you are no longer using tape library sharing then you will need to disable this.
Moving on, let’s look at the other common error seen when you’re unable to launch the DPM Administrator console as well as the common causes for it. This is the "ID: 948" error:
The “ID: 948” error does share some things in common with the first error we looked at above, however we’ll recap on those and also look at the potential areas unique to why this error may be occurring.
1. First verify that the DPM service itself is not disabled but rather is set to a manual startup type. You can also attempt to manually start the service if it’s not already running.
2. Next you will want to check the DPM database using the steps shown previously to verify whether or not it’s in recovery mode. If it is then either manually change this in the database or from a command prompt (Administrative on 2008+) execute the “Dpmsync.exe -Sync" command to remove it from being in the dbRecovery mode.
3. For this type of error we need to also verify that the “SQL Server” service has not been disabled on the DPM server. If it has not been disabled then it’s recommended to verify the log on account information for the SQL Server service. It by default will use the “MICROSOFT$DPM$Acct” local user account which is created when DPM is installed.
4. Next check for any unresolved machine accounts in the local groups “MSDPMTrustedMachines” and “DPMRADmTrustedMachines”) on the DPM server and either correct the issue so that the accounts can be resolved or simply delete them from the groups. The unresolved accounts are easily identified by the appearance which will be in the form of a security identifier as shown below:
5. Like the previous error, the “ID: 948” error can also be due to corruption in the DPM database. For this you will need to restore the DPM database from a recent backup. Please review the links below for additional information on how to backup and restore the DPM database.
If none of the items proposed above provide a resolution to the issue then at that point you may need to open a support case with Microsoft to help you address this. With this in mind there are a few tasks you can do ahead of time to help expedite the case and a resolution when working with Microsoft Support.
1. Download and run the DPM MPS Reports tool on the DPM server to collect data. This tool can be downloaded at the link provided at the end of this post.
2. Please look for and gather any *.dmp files found in the following location: “%WINDIR%\PCHealth\ERRORREP\QSIGNOFF”
3. If the DPM Server is operating on Windows Server 2003 then please run the following command from command prompt of from the Start menu to enable DR Watson as the default application debugger: “DRWTSN32 -i". Once this has been done check the “%WINDIR%\PCHealth\ERRORREP\QSIGNOFF” for any *.dmp files and gather any that are found.
4. Download and install the Debugging Tools for Windows on the DPM server. Once this has been done you will then use ADPLUS to capture a dump of the MSDPM.exe process while reproducing the issue. To do so you will need to issue the command: “cscript Adplus.vbs –crash –pn msdpm.exe –fullonfirst –o c:\adplus” where the output folder of “c:\adplus” in my example can be any location/folder that you’ve pre-created.
Using DpmBackup to Create Backup Shadow Copies http://technet.microsoft.com/en-us/library/cc161258.aspx
How to Recover DPM Databases http://technet.microsoft.com/en-us/library/bb808944.aspx
Setting Disk Quotas http://technet.microsoft.com/en-us/library/dd163561.aspx
Downloads for System Center Data Protection Manager 2007 http://www.microsoft.com/downloads/en/results.aspx?freetext=%22data+protection+manager+2007%22&displaylang=en&stype=s_basic
DPM MPS Reports http://www.microsoft.com/downloads/details.aspx?familyid=14392186-6707-45a5-8987-29665abbd6f5&displaylang=en&tm
Debugging tools for Windows http://www.microsoft.com/whdc/devtools/debugging/default.mspx
286350 How to use ADPlus to troubleshoot "hangs" and "crashes" http://support.microsoft.com/default.aspx?scid=kb;EN-US;286350
Tyler Franke | Senior DPM Support Escalation Engineer
Hi folks - in case you are interested to recover your data from DPM fast (in seconds) regardless of your data set size, please give DPMExplorer (www.instavia.com) a try. It is free. Thanks!
My issue was caused by insufficient access permissions to the \\Server\MTATempStore$ on the primary DPM Server. This was resolved by adding DPMRADCOMTrustedMachines to both Share and NTFS permissions and giving the group full control permissions.