針對 Data Protection Manager 控制台當機進行疑難解答

本指南可協助您診斷及解決 System Center 2016 Data Protection Manager （DPM 2016） 和更新版本中管理控制台的當機相關問題。 常見的當機錯誤標識碼包括 917、999、948 和 1069。

原始產品版本： System Center 2016 Data Protection Manager 和更新版本
原始 KB 編號： 10057

開始進行疑難解答之前，請確定您已安裝 System Center Data Protection Manager 的最新更新匯總套件。 如需最新版本，請參閱 System Center - Data Protection Manager 組建版本。

錯誤 917：DPM 服務的連線已遺失

處理主控台當機時，請務必瞭解 DPM 伺服器上的控制台依賴數個可用的服務。 如果上述任何服務停止執行或失敗，您可能會收到錯誤 917：

DPM 服務的連線已遺失。
如需可能的服務關機相關信息，請檢閱應用程式事件記錄檔。

以下是此錯誤的螢幕快照：

如果啟動主控台時發生當機，請確認所有 DPM 服務都在執行中。 必須執行的服務會列在錯誤訊息中：

• DPM
• DPMRA
• SQL Server Agent （適用於 DPM 實例）
• SQL Server （適用於 DPM 實例）
• 虛擬磁碟服務
• 磁碟區陰影複製服務

注意

在 Windows Server 2016 或更新版本中安裝 DPM 時，Hyper-V 虛擬機管理服務必須執行。

如果其中一個服務未執行，請嘗試啟動它，然後重新開啟 DPM 控制台。

如果服務已啟動，但仍遇到問題， 請檢查資料庫是否處於復原模式。

如果啟動服務時發生問題，錯誤訊息應該會提供失敗原因的線索。

錯誤 1069︰由於登入失敗，此服務未啟動

如果您在啟動其中一個 DPM 相關服務時遇到問題，可能是因為服務執行身分帳戶所造成。 服務無法以下欄錯誤啟動：

錯誤 1069：服務因為登入失敗而未啟動。

以下是錯誤的範例螢幕快照：

唯一可能以 SYSTEM 以外的帳戶執行的服務是 SQL Server 帳戶。 使用下表來確認帳戶正確無誤，而且它們具有有效的密碼。

注意

變更 SQL Server 用戶帳戶的最佳方式是使用 SQL Server 組態管理員 介面。

服務名稱	執行身分帳戶	啟動類型	調查是否未執行？
MSDPM	系統	手動	是
DPMRA	系統	自動	否
*SQL Server Agent （適用於 DPM 實例）	系統	自動	是
*SQL Server （適用於 DPM 實例）	系統	自動	是
虛擬磁碟服務	系統	手動	是
磁碟區陰影複製服務	系統	手動	是
DPM Access Manager	系統	自動	是
DPM 代理程式協調器	系統	手動	否
DPM CPWrapper	系統	手動	否
DPM 編寫器	系統	自動	是
DPMLA	系統	手動	否
DPM VMM 協助程序服務	系統	手動	否

* 如果啟用連結庫共用，SQL Server 服務會使用網域帳戶（必須是本機系統管理員）。

檢查資料庫是否處於復原模式

如果資料庫處於復原模式，當服務嘗試連線到資料庫時，可能會造成問題。 資料庫會因為 DPMSync -Sync 失敗或當機而進入恢復模式。 若要檢查此情況是否為這種情況，請對 DPMDB 執行下列 SQL 查詢：

select * from tbl_DLS_GlobalSetting
where PropertyName like 'DbRecovery'

如果傳回的 PropertyValue 為 1，資料庫會處於復原模式。

執行下列 SQL 查詢，讓資料庫脫離復原模式：

update tbl_DLS_GlobalSetting
set PropertyValue = '0'
where PropertyName like 'DbRecovery'

完成後，請重新啟動 DPM 服務，然後再試一次控制台。

服務逾時

如果已正確設定服務執行身分帳戶，您可能會遇到服務逾時的問題。 如果服務在嘗試啟動時逾時，您可以套用下列登錄專案：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

DWORD： ServicesPipeTimeout
值： 300000

如果專案不存在，您可以建立它。 此值是以毫秒為單位的逾時（毫秒），例如 60000 等於 1 分鐘（60 秒）。 您必須重新啟動服務以實作變更。 視需要調整值。

服務會啟動，但隨後損毀

如果服務啟動，然後當機，請檢查應用程式事件記錄檔是否有錯誤，指出哪個服務已損毀。 檢查當機時發生錯誤為層級的任何專案，以及 MSDPM（或任何其他 DPM 服務）作為來源。 事件的 [ 一般 ] 索引標籤應該包含已當機之服務的相關信息，以及有關當機的一些詳細數據。

例如， 事件識別碼為999失敗的MSDPM 進程具有下列詳細數據：

找不到來源 MSDPM 的事件標識碼 999 的描述。 本機電腦可能並未安裝引發此事件的元件，或安裝已損毀。 您可以在本機電腦上安裝或修復該元件。

如果事件源自另一部計算機，則顯示信息必須與事件一起儲存。

事件包含下列資訊：

未預期的錯誤導致進程 『msdpm』 失敗。 重新啟動 DPM 進程 『msdpm』。

以下是此事件的螢幕快照：

在此範例中，[ 問題詳細 數據] 區段顯示失敗，錯誤碼0x80004015對應至：

類別設定為以不同於呼叫端的安全性標識碼執行

然後，我們可以開始將問題調查為用戶帳戶問題。 因為它是當機的 MSDPM 服務，下一個步驟是查看對應的 DPM 錯誤記錄檔。 這些 DPM 錯誤記錄的預設位置類似於 C:\Program Files\Microsoft System Center\DPM\DPM\Temp\。

錯誤記錄檔會針對其記錄的服務命名，而每個服務的目前記錄檔會命名為 <service>curr.errlog。

如果服務已當機，系統也會建立類似如下所示的 .crash 檔案：

當機事件會記錄在檔案的結尾處，並顯示更多詳細數據。

針對各種服務當機進行疑難解答時，其原因和解決方式已超出本指南的範圍。 事件記錄檔、錯誤記錄檔和 .crash 檔案應該提供足夠的資訊，以針對最常見的錯誤進行疑難解答。

錯誤 948：無法連線到 DPM 伺服器

如果服務無法連線到 DPM 資料庫，它可能會無法啟動。 在這裡情況下，您會看到類似下列的錯誤：

無法連線到 <DPM 伺服器>。 （標識元：948）
確認 DPM 服務正在這部電腦上執行。

事件記錄檔中的 [問題詳細數據] 區段應該提供有關失敗本質的其他資訊。 資料庫通常會離線或無法連絡（如果資料庫位於遠端伺服器上），或者您可能發生登入失敗。 在這種情況下，您可能會在事件記錄檔中看到類似下列其中一個範例的錯誤：

一些常見原因包括：

登入失敗

無法登入的帳戶應該會在錯誤訊息中清除。 否則，您可以在 DPM Temp 資料夾中檢查 msdpmcurr.errlog 。 如果這無法清楚說明，請嘗試 SQL Server 安裝位置中的 ERRORLOG 檔案（例如 C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Log）。 路徑可能會因已安裝的確切 SQL Server 版本或安裝到非預設位置而有所不同。

此錯誤記錄檔應該包含任何失敗的登入稽核專案。 將許可權指派給參考之資料庫所提及的帳戶，以解決這些錯誤。 這通常是 SQL Server 執行身分帳戶或 SYSTEM 帳戶：

• 針對 SYSTEM 帳戶，您可以移至 [安全性>登入]，然後在 [系統帳戶] 上按兩下滑鼠右鍵，在 SQL Server Management Studio 中新增相關許可權。 確定其已 選取系統管理員 角色，如下所示：

  

• 針對 SQL Server 執行身分帳戶，重設 SQL Server 組態管理員 中的帳戶。

資料庫/實例脫機

您應該已檢查 SQL Server 服務目前是否正在執行。 否則，請立即加以檢查。 執行 SQL Server 服務之後，請嘗試從 SQL Server Management Studio （SSMS） 連線到實例。 如果伺服器以與安裝帳戶不同的帳戶登入，則偶爾會失敗。 在此案例中，請嘗試以系統管理員身分執行 SSMS。 如果可以成功連線，DPMDB 已上線。 如果 DPMDB 離線，看起來會像下面這樣：

如果 DPMDB 離線，請以滑鼠右鍵按兩下 [DPMDB]，選取 [工作]，然後選取 [上線]。 在在線之後，請確認問題是否已解決。

網路相關問題

如果您看到有網路相關問題的錯誤，請完成下列步驟，測試從 DPM 伺服器連線到資料庫：

1. 建立 .udl 檔案。 最簡單的方式是將擴展名為 .udl 的空白.txt檔案重新命名。

2. 按兩下 UDL 檔案，然後從下拉式清單中選取要測試的實例和資料庫。

3. 按一下 [測試連接] 。

   

如果失敗，請檢查您是否可以從 DPM 伺服器偵測 SQL Server，並確認名稱解析是否正常運作。 也請確認傳回的IP位址正確無誤。 確認 SQL Server DPM 伺服器 > 中的位址也正確無誤。 檢查流量可能無法通過的任何其他明顯原因，例如防火牆。