Data Protection Manager 代理网络疑难解答
大家好，我是 Shane Brasher。我想向大家介绍几个有关如何排查与 DPM 代理有关的网络问题的技巧。本文的目标不是让您成为网络专家，也不是提供深入的网络培训，而是向您提供一些基本技能和特定工具的知识，以帮助您评估 Data Protection Manager (DPM) 流量的通信问题。
产品支持团队收到的关于 System Center Data Protection Manager 代理的一个最常见的问题就是连接问题和端口阻断。本文档将大致介绍几个用于解决诸如以下问题的主要疑难解答方法：
a.) 您无法通过 DPM 管理控制台将 DPM 代理推送到服务器。
b.) 您手动安装了代理，但仍然无法与 DPM 服务器通信。
当然，如果诊断出连接或端口阻断问题，在某些情况下，DPM 管理员可能必须与网络管理员或目录服务管理员合作。例如，如果由于 tracert 结果失败，您怀疑路由器上的路由表缺少某个路由，则需要与网络管理员协作来检查路由器。再例如，如果域中服务器的上 Windows 集成防火墙是通过 GPO 配置的，并且没有对 DPMRA 端口设置规则例外，则需要与 Active Directory 管理员协作来更改 GPO。
DPM 代理 - 该代理是干什么的？它有哪些用途？
DPM 代理是我们打算使用 Data Protection Manager 备份的服务器上安装的一个组件。它负责跟踪选定进行备份的数据发生更改的数据块，还负责将备份的数据传输到 Data Protection Manager 服务器。
DPM 代理服务 (DPMRA) 的启动类型为“手动”并作为本地系统帐户在每个受保护的计算机上运行。仅当某个作业要按计划运行，并且 DPM 服务器联系 DPM 代理时，DPM 代理才会启动。计划作业完成后，DPMRA 服务将继续运行五分钟，然后才停止。
保护代理软件由两个组件组成：保护代理本身和代理协调器。代理协调器是在安装、更新或卸载保护代理期间暂时安装在受保护计算机上的软件。
DPM 连接
在我们开始了解用于疑难解答的一些工具之前，我们首先需要知道 DPM 使用哪些端口运行。下面的文章列出了 DPM 2007、DPM 2010 和 DPM 2012 使用的端口。
注意 DPM 2012 证书使用一个额外的端口，这将在另一篇文章中介绍。
DPM 端口
https://technet.microsoft.com/zh-cn/library/ff399341.aspx
协议 |
端口 |
详细信息 |
DCOM |
135/TCP 动态 |
DPM 控制协议使用 DCOM。DPM 通过对代理调用 DCOM 向保护代理发布命令。保护代理通过对 DPM 服务器调用 DCOM 进行响应。 TCP 端口 135 是 DCOM 使用的 DCE 端点解析点。 默认情况下，DCOM 动态分配 TCP 端口范围从 1024 至 65535 之间的端口。 |
TCP |
5718/TCP 5719/TCP |
DPM 数据通道基于 TCP。DPM 和受保护的计算机都发起连接以启用 DPM 操作，例如同步和恢复。 DPM 在端口 5718 上与代理协调器通信，在端口 5719 上与保护代理通信。 |
DNS |
53/UDP |
在 DPM 和域控制器之间，以及受保护的计算机和域控制器之间使用，以进行主机名称解析。 |
Kerberos |
88/UDP 88/TCP |
在 DPM 和域控制器之间，以及受保护的计算机和域控制器之间使用，以进行连接端点的身份验证。 |
LDAP |
389/TCP 389/UDP |
在 DPM 和域控制器之间使用，以进行查询。 |
NetBIOS |
137/UDP 138/UDP 139/TCP 445/TCP |
在 DPM 和受保护的计算机之间、DPM 和域控制器之间，以及受保护的计算机和域控制器之间使用，以进行其他操作。直接用于 TCP/IP 上承载的 SMB，以执行 DPM 功能。 |
现在我们已经知道需要哪些端口，那么我们如何确定在两点之间端口是否被阻止呢？我们有许多内置工具或可以随意下载的工具可以使用。
让我们先从几个可以快速、轻松地完成的简单命令行测试入手。还有一些其他网络可变因素需要考虑，例如 DNS、arp 缓存、IPsec 等等... 但在本文中，我们要尽量简单一些，只介绍一些只需稍加练习任何人都可以完成的基本测试。
用于排查 DPM 连接问题的工具包括：
a.) “Ping”以测试名称解析并确定其流量能否正确路由到目的地。
b.) “tracert”测试路由
c.) “Net view”检查服务器本身的可访问性。
d.) “Sc”命令行测试 RPC 连接
e.) “WBEMTEST”测试 DCOM 连接。
e.) “Wmic”测试 DCOM 连接。
f.) Netstat 列出使用的端口
g.) Tasklist 列出当前正在运行的进程
h.) Tcpview GUI 用于列出端口
i.) 集成防火墙日志记录
j.) Netmon
k.) 切换烟囱和 RSS
Ping 命令 - “我可以从这里到达那里吗？”
Ping 可能是用于测试整体连接性的使用最广泛的内置工具之一。我不打算介绍可以使用的所有开关，而只是简单地介绍 ping 的基本用法和少数几个开关。
Ping 测试 #1 测试整体通信
最简单的 ping 测试是 ping 服务器的主机名，就是这么简单。从命令提示符处，键入：ping <ServerName>
示例：
C:\Users\administrator>ping MemberServer
Pinging MemberServer.contoso.com [10.10.10.10] with 32 bytes of data:
Reply from 10.10.10.10: bytes=32 time=6ms TTL=128
Reply from 10.10.10.10: bytes=32 time<1ms TTL=128
Reply from 10.10.10.10: bytes=32 time=1ms TTL=128
Reply from 10.10.10.10: bytes=32 time=1ms TTL=128
Ping statistics for 10.10.10.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 6ms, Average = 2ms
成功的答复告诉我们，我们不仅可以将名称解析为 IP 地址，而且还知道如何到达那里，因此路由工作正常。稍后我们将通过 tracert 命令再次测试路由。
Ping 测试 #2 测试 MTU 大小
有时，如果发送的数据包大于路由器或防火墙允许接收较小数据包的网段接收的大小，那么在从 DPM 服务器路由到受保护的服务器时，通信可能会失败。路由器可能被配置为向发送数据包的主机发回 ICMP“destination unreachable”消息，否则，数据包将被丢弃。如果数据包被丢弃，即表明这是一个黑洞路由器，下面的文章中讨论了这种情况：
如果排查黑洞路由器问题 https://support.microsoft.com/kb/314825
尽管由于 2008 年推出的新 TCP 网络功能实现了黑洞路由器检测，这种情形不再像过去那么常见，但仍然值得检查，因为它有时还是会突然出现。
可以使用两个特定开关，通过特定数据包大小 ping 目标位置，来诊断此问题。
-l <size> 发送缓冲区大小。
-f 在数据包中设置“不分段”标记（仅限于 IPv4）。
成功示例：C:\Users\administrator>ping MemberServer -l 1472 -f
注意“-l”和“-f “开关。
-l <size> 发送缓冲区大小。
-f 在数据包中设置“不分段”标记（仅限于 IPv4）。
我们使用这两个开关测试两台服务器之间的 MTU 大小 1472。
注意：有关最大传输单元 (MTU) 的信息将在本节末尾提供。
Pinging MemberServer.contoso.com [10.10.10.10] with 1472 bytes of data:
Reply from 10.10.10.10: bytes=1472 time=1ms TTL=128
Reply from 10.10.10.10: bytes=1472 time=1ms TTL=128
Reply from 10.10.10.10: bytes=1472 time=1ms TTL=128
Reply from 10.10.10.10: bytes=1472 time=1ms TTL=128
Ping statistics for 10.10.10.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
在这里，我们看到 MTU 大小 1472 获得成功。我们指定了 –l 将缓冲区设置为 1472，并使用 –f 指定不分段。值 1472 是默认以太网 MTU 1500 减去表示 IP 和 ICMP 标头的 28 得出的。
参考：https://technet.microsoft.com/zh-cn/library/cc958871.aspx “ICMP 回显请求标头是 8 个字节，IP 标头通常是 20 个字节。在此处显示的以太网示例中，链路层 MTU 包含最大大小的 Ping 缓冲区加上 28，总共 1500 个字节”
失败示例：在这里，我们看到指定的 MTU 大小失败的示例。
C:\Users\administrator>ping MemberServer -l 1472 -f
Pinging MemberServer.com [10.10.10.10] with 1472 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 10.10.10.10:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
让我们将 MTU 值减小到一个更小的数字。我们选择 1272 来代替 1472：
C:\Users\administrator>ping MemberServer -l 1272 -f
Pinging MemberServer.com [10.10.10.10] with 1472 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 10.10.10.10:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
我们可以继续减小数据包大小，直到找到能够成功的可接受的大小。此外，如果成功的数据包大小小于预期（例如，您有一个千兆位链路，MTU 却只有 500），则不会获得预期吞吐量，并且可能遭遇数据包丢失，在带宽需求较高时尤其如此。
注意上面两件事。
1.) 我们收到消息，指出数据包需要分段。
2.) 我们遇到 100% 丢失率。
既然我们已经知道了这种情况，现在该怎么办？如何解决此问题？
有几种方法可以解决此问题，例如：
a.) 重新配置路由器或交换机以允许更大的数据包大小。
b.) 可能需要对路由器或交换机进行固件更新。
c.) 在服务器上启用黑洞检测。
目前我们的目的是诊断故障可能出现在何处。当然，如果您遇到这种称为黑洞路由器的情况，建议您与网络管理员协作。请参见下面的文章，了解更多信息。
Ping：https://technet.microsoft.com/zh-cn/library/cc952252.aspx
169790 如何排查基本 TCP/IP 问题：https://support.microsoft.com/default.aspx?scid=kb;ZH-CN;169790
314825 如何排查黑洞路由器问题：https://support.microsoft.com/default.aspx?scid=kb;ZH-CN;314825
不同网络拓扑的默认 MTU 大小：https://support.microsoft.com/kb/314496
Windows Server 2008 和 Windows Vista 中的新网络功能：https://technet.microsoft.com/zh-cn/library/bb726965.aspx
Tracert - “从这里到那里我要采用哪种路由（路径）？”
Tracert 是一个简单易用的实用工具，使用 ICMP 测试两台服务器之间的路由。采用的路由如下面的示例所示：
成功示例：
C:\Users\administrator>tracert MemberServer
Tracing route to MemberServer.Contoso.com [10.10.10.10]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.10.10.1
2 41 ms 27 ms 29 ms router [10.10.10.2]
Trace complete.
失败示例：
C:\Users\administrator>tracert 10.10.10.55
Tracing route to 10.10.10.55 over a maximum of 30 hops
1 1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
etc……
结果表明我们不知道如何到达那里。此时，您可能想检查您的默认网关是否有效，以及服务器和网络内的中间设备上的路由表是否正确。
有关 tracert 的详细信息，请参见下面的文章：
Tracert： https://technet.microsoft.com/zh-cn/library/ff961507(WS.10).aspx
如何使用 TRACERT 排查 Windows 中的 TCP/IP 问题： https://support.microsoft.com/kb/314868
路由表： https://technet.microsoft.com/zh-cn/library/cc957845.aspx
了解 IP 路由表： https://technet.microsoft.com/zh-cn/library/cc787509(WS.10).aspx
Net View - “该服务器上的哪些共享可供我通过网络访问？”
net view 命令用于查看远程计算机上可访问的共享。受保护计算机上的 ADMIN$ 共享必须能够使用计划用于安装代理的帐户从 DPM 服务器进行访问。net view 命令是执行此测试的快速方法。
成功示例：
C:\Users\administrator>net view \\MemberServer /all
Shared resources at \\MemberServer
Share name Type Used as Comment
-------------------------------------------
ADMIN$ Disk Remote Admin
C$ Disk Default share
D$ Disk Default share
IPC$ IPC Remote IPC
print$ Disk Printer Drivers
Users Disk
The command completed successfully.
失败示例：
C:\Users\Administrator >net view \\BogusServer
System error 53 has occurred.
The network path was not found.
如何使用 NET VIEW 命令查看共享资源：https://support.microsoft.com/kb/141229
SC 测试 RPC 连接 - “我可以通过 RPC 通信到达此服务器吗？”
现在我们使用服务控制器或 SC 命令来测试 RPC 和服务控制管理器 (SCM) 连接。如果成功，它将显示远程服务器上的服务列表：
Sc \\<protected server name> query
成功的输出告诉我们，与服务器上服务控制管理器的 RPC 连接可以访问。
成功示例：
C:\Users\administrator> sc \\MemberServer query
SERVICE_NAME: AeLookupSvc
DISPLAY_NAME: Application Experience
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
etc….
该列表可能相当长，因此本文档没有必要列出完整输出内容。要记住的关键点是它是否成功。下面给出了失败的输出：
失败示例：
C:\Users\administrator>sc \\Server1 query
[SC] OpenSCManager FAILED 1722:
The RPC server is unavailable.
如果我们确实知道“Server1”是有效的服务器名称，并且收到“RPC server is unavailable”结果，假定 ping 和 tracert 成功，表明我们知道如何到达服务器，那么我们可以得出结论，即可能的原因是 RPC 端口阻断。
有关更多信息，请参阅：
SC 查询
https://technet.microsoft.com/zh-cn/library/dd228922(WS.10).aspx
https://technet.microsoft.com/zh-cn/library/bb490995.aspx
WBEMTEST - DCOM 是否可以访问？
对于此项测试，我们可以使用 WBEMTEST 来测试 DCOM 连接。这是另一个可用于执行此测试的内置工具。以下链接中提供了一个出色的演练，介绍了如何执行此操作：
在 Data Protection Manager 2007 中排查代理部署问题 – 网络
https://blogs.technet.com/b/askcore/archive/2008/05/01/troubleshooting-agent-deployment-in-data-protection-manager-2007-networking.aspx
如果 WBEMTEST 测试失败，则根据下文所述验证 DCOM 设置：
在 Data Protection Manager 2007 中排查代理部署问题 - DCOM
https://blogs.technet.com/b/askcore/archive/2008/05/09/troubleshooting-agent-deployment-in-data-protection-manager-2007-dcom.aspx
WMIC
测试 WMI/DCOM。如果成功，此命令将列出有关远程服务器的一些基本信息。
语法：
Wmic /node:"<protected server name>" OS list brief
“list”---WMIC 动词
“brief”—WMIC 形容词
“/node”—指定计算机名称
“OS”—列出有关操作系统的信息
成功示例：
C:\Users\administrator>wmic /node:MemberServer OS list brief
BuildNumber Organization RegisteredUser SerialNumber SystemDirectory Version
7600 Microsoft Admin 12345-678-1234567-12345 C:\Windows\system32 6.1.7600
失败示例：
C:\Users\administrator>wmic /node:BogusServer OS list brief
Node – BogusServer
ERROR:
Description = The RPC server is unavailable.
尽管确实可能存在错误配置的 DCOM 设置导致无法访问，但本文不对此进行介绍，因为我们只是从网络的角度探讨这一问题。有关此内容的详细信息，请参考下面的文章：
在 Data Protection Manager 2007 中排查代理部署问题 - DCOM
https://blogs.technet.com/b/askcore/archive/2008/05/09/troubleshooting-agent-deployment-in-data-protection-manager-2007-dcom.aspx
其他信息
WMIC 动词：https://technet.microsoft.com/zh-cn/library/cc784966(WS.10).aspx
WMIC 开关：https://technet.microsoft.com/zh-cn/library/cc787035(WS.10).aspx
运行 Windows Management Instrumentation 命令行：https://technet.microsoft.com/zh-cn/library/cc782919(WS.10).aspx
Netstat - 哪些端口正在侦听或者正在使用哪些端口？
Netstat 是另一个方便的内置工具，用于确定活动的 TCP 连接并列出端口。netstat 还有其他开关，但我们只重点介绍少数几个。
我们将 netstat 与 tasklist（在下面列出）结合使用来确定以下事项：
a.) 是否可通过 DPM 端口 5718 建立 DPM 连接？
b.) 我们可以确信 DPMRA 服务正在使用该端口而不是其他端口吗？
语法：Netstat –ano
“-ano”开关用于：
-a 显示所有连接和侦听端口。
-n 以数字形式显示地址和端口号。
-o 显示与每个连接相关的所属进程 ID。
示例：
C:\Users\administrator>netstat –ano
Active Connections
Proto Local Address Foreign Address State PID
TCP 10.10.10.10:58891 157.54.62.44:56281 ESTABLISHED 3608
TCP 10.10.10.10:59628 10.251.16.114:443 ESTABLISHED 1904
TCP 10.10.10.10:60075 157.54.41.53:7575 ESTABLISHED 3608
TCP 10.10.10.10:61763 10.37.38.16:5061 ESTABLISHED 3708
TCP 10.10.10.10:64475 65.53.103.24:1745 ESTABLISHED 1112
TCP 10.10.10.10:65292 157.54.41.53:7576 ESTABLISHED 3608
TCP 10.10.10.10:3143 65.53.65.78:5718 ESTABLISHED 5512
注意列出的端口 5718 和 PID。我们知道这是一个 DPM 端口，那么我们如何确信其他服务没有侦听该端口？我们还可以使用“netstat –anob”来列出可执行程序，或者也可以按如下所示使用 tasklist。
Tasklist
Tasklist 可用于列出当前正在运行的进程和相关的 PID。我个人更喜欢 Tasklist 而不是使用 netstat 与“b”开关，因为 tasklist 还可以方便地查看哪些服务与 svchost.exe 相关。
语法：tasklist /svc
C:\Users\administrator>tasklist /svc
Image Name PID Services
========================= ========
OUTLOOK.EXE 3608 N/A
IncidentManagement.Client 1904 N/A
communicator.exe 3708 N/A
DPMRA.exe 5512 DPMRA
svchost.exe 252 CryptSvc, Dnscache, LanmanWorkstation,
napagent, NlaSvc, TermService
注意，我们可以看到 PID 5512 属于 DPMRA 服务。因此 netstat 和 tasklist 的输出都证实了当前服务（即此服务器上的 DPMRA）正在使用 5718 端口。下面的文章介绍了如何使用 Netstat 输出和 Tasklist 输出来评估其他进程是否在侦听 DPMRA 端口 5718 或 5719。
947682 DPM 保护代理服务无法在 System Center Data Protection Manager 2007 中启动：https://support.microsoft.com/default.aspx?scid=kb;ZH-CN;947682
TCPView
TCPview 是一个免费的实用工具，可用于完成与 netstat 和 tasklist 相同的任务，但它具有 GUI 界面。
TCPView： https://technet.microsoft.com/zh-cn/sysinternals/bb897437
TCPView 可以显示正在使用的端口、协议、IP 地址以及进程。可以将输出保存到一个文本文件中以供日后参考。
集成防火墙日志记录 - “是 Windows 集成防火墙导致出现问题的吗？”
集成防火墙的端口阻断绝对不是不可能的，并且绝对是一个通常被忽略的 DPM 代理通信问题的原因。我已将这句话加粗显示以再次强调它经常被忽略。当我们通过手动安装来安装代理时，“应该”正确创建 DPMRA 规则以允许通信。即使正确执行此步骤，仍有可能有人手动或通过应用 GPO 更改防火墙规则，甚至可能创建新的限制性更强的规则。关闭防火墙是排除该可变因素的一个不错的步骤。
可以通过以下三种方式之一关闭集成防火墙：
a.) 从命令提示符处
b.) 从 mmc 或计算机管理中
c.) 从 netsh
由于公司政策和/或更改请求，选择关闭集成防火墙通常是一个相当敏感的决策。因此，首先启用并分析防火墙日志记录对您可能大有帮助。
通过命令提示符关闭集成防火墙
要通过命令提示符关闭防火墙，您可以键入： “net stop bfe”
系统将提示您进行确认。这是最简单的方法，但会停止其他服务，例如 IKE、Ipsec、TMG（如果已安装） 。既然如此，如果不知道此服务器目前需要哪些其他服务，您可能不想使用此方法。您可能希望选择下面的其他方法之一。
通过 Netsh 命令关闭集成防火墙
要禁用 Windows 防火墙，请打开管理命令提示符并键入以下命令，在每行后面按 Enter。
netsh
firewall
advfirewall
set allprofiles state off
示例：
要重新启用 Windows 防火墙，请将最后一行更改为以下内容：set allprofiles state on
通过 MMC 关闭集成防火墙
通过 MMC 管理单元关闭它：为本地计算机添加“高级安全 Windows 防火墙”，或者通过“计算机管理”访问它。在树的顶部右键单击，然后选择“属性”。
您会看到以下屏幕：
请注意三件事：
a.) 有三个配置文件 - 专用配置文件、公用配置文件和域配置文件。
b.) 您“可能会”但并非总是能看到覆盖该选项以禁用防火墙的域 GPO。
c.) 您确实有了需要时可以参考的日志记录。
要点
如果 GPO 覆盖该功能以通过图形用户界面 (GUI) 关闭防火墙，则您可能必须通过命令提示符执行此操作 (net stop bfe)。这将暂时将其关闭以进行测试，但在 GOP 刷新时它可能会重新打开（默认 GPO 刷新间隔为 15 分钟）。但请记住，正如前面提到的，通过 net stop bfe 关闭防火墙还会关闭其他服务。
如果根本不允许您关闭防火墙，则应依赖防火墙日志记录来判断发生的情况。您可以选择启用丢弃的数据包和成功的数据包。建议您同时记录这两项。
参考日志时要注意的最重要的事情是：
a.) 操作（丢弃或允许）
b.) 协议
c.) 源和目标 IP。
防火墙日志记录基于每个配置文件执行。
默认路径： C:\Windows\System32\LogFiles\Firewall\pfirewall.log
下面的示例日志显示了源 IP 地址 10.10.10.100 和目标 IP 地址 10.10.10.50 之间被丢弃的 ICMP、TCP 445、TCP 135 和 UDP 137 数据包。
其他信息：
System Center Data Protection Manager 2012 代理安装失败并出现错误 319：https://support.microsoft.com/kb/2621989
安装 TMG 以进行 DPM 通信：https://blogs.technet.com/b/dpm/archive/2010/12/06/new-video-tmg-setup-for-dpm-communication.aspx
DPM 流量与烟囱和 RSS - “是 TCP 烟囱或 RSS 导致出现问题的吗？”
为了回答这个问题，我们首先需要了解什么是 TCP 烟囱和 RSS。TCP 烟囱和 RSS 是用于提高网络流量的吞吐量和数据包处理能力的增强功能。
RSS 技术允许属于相同 TCP 连接的网络数据包处理在系统中的多个处理器之间分布（如果您的服务器有多个处理器）。
TCP 烟囱卸载是一项网络技术，可帮助在网络数据传输过程中将工作负载从服务器 CPU 转移到网络适配器。当然，这假定适配器支持该功能。
“如果它是一项增强功能，为什么我需要将它关闭？”
但有时，“网络适配器不够强大，在高吞吐量时无法处理卸载功能。例如，由于硬件资源有限，启用分段卸载可以减少某些网络适配器上的最大可持续吞吐量。” ---引自以下位置中的一篇性能文章：https://msdn.microsoft.com/zh-cn/windows/hardware/gg463394
还有一个列表列出了当 TCP 卸载无法正常工作时可能会出现的常见症状。请参见下面的文章：
948496 提供了适用于基于 Windows Server 2003 和 Small Business Server 2003 计算机的用于禁用默认 SNP 功能的更新程序https://support.microsoft.com/default.aspx?scid=kb;ZH-CN;948496
最终结果是如果 TCP 烟囱和/或 RSS 没有正确或按预期方式运行，就可能会出现不理想的行为，例如 DPM 通信极其缓慢和/或在某些情况下甚至会失败。这不仅包括 DPM 复制问题，还包括失败的 DPM 代理推送实例。网上有各种 SNP 和 TCP 卸载修补程序，有些情况下可以应用这些修补程序来改善 DPM 通信。最好由网络管理员决定是否实施这些修补程序。
很多时候，如果 TCP 烟囱无法正常运行，NIC 驱动程序的一个更新将会纠正问题。必须记往，更新 NIC 驱动程序是一个经常被忽略的潜在解决方案。请注意，NIC 的优劣取决于为它编写的驱动程序，更新的驱动程序或许可以纠正许多潜在问题。
如果您怀疑 TCP 烟囱或 RSS 没有按预期方式运行，则尝试将它们关闭以进行测试。这非常简单，关闭 TCP 烟囱或 RSS 不需要重新启动服务器。测试完成后，可以很容易地重新打开它们。要关闭 TCP 烟囱或 RSS，可以使用下面的 netsh 语法：
烟囱
确定 TCP 烟囱卸载的当前状态：netsh int tcp show global
禁用烟囱：netsh int tcp set global chimney=disabled
启用烟囱：netsh int tcp set global chimney=enabled
RSS
要确定 RSS 的当前状态，请执行以下步骤：netsh int tcp show global
禁用 RSS：netsh int tcp set global rss=disabled
启用 RSS：netsh int tcp set global rss=enabled
示例：
注意上面输出中的以下内容：
a.) 同时使用了烟囱和 RSS。
b.) 我们事实上已将它们都关闭并收到更改已生效的确认消息。
951037 有关 Windows Server 2008 中的 TCP 烟囱卸载、接收方缩放和网络直接内存访问功能的信息：
https://support.microsoft.com/default.aspx?scid=kb;ZH-CN;951037
Netmon
对于网络管理员而言，netmon 是一个极其有用的工具，可帮助确定网络上正在发生的情况。然而，我经常听到一种说法。“阅读 netmon 跟踪更像是一门艺术，而不是一门科学。”本文档不讨论所有类型的通信的详细信息，以及基准行为与失败或异常通信之间的差异。对协议分析的讨论仅仅是基础层面就可能非常深入。尽管我们不会深入介绍 Netmon 用法，但仍然值得一提的是它是一个出色的工具，可由精通协议分析的人使用。
如果您想获取或提升此技能，则下面的链接可以助您一臂之力。
Netmon：https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f
OneClick - 这将允许您执行一次网络捕获。有时它可能比 Netmon 更容易使用：https://www.microsoft.com/download/en/details.aspx?id=6537
阅读跟踪的基础知识：https://support.microsoft.com/kb/169292
SETSPN 命令 – 我的 SPN 是否已正确注册？
下面是一个如何检查以确保 SPN 注册正确无误的示例。运行 setspn，检查无法将代理推送到的服务器的服务主体名称。
完成以下步骤：
1.从以下位置下载并安装 Windows 支持工具：
2.打开命令提示符，以域管理员身份登录后，运行以下命令：
setspn -l <Servername>
其中，<Servername> 是无法成功部署 DPM 代理的生产服务器。
输出应类似如下内容：
Registered ServicePrincipalNames for CN=EXCHANGESERVER,OU=Member
Servers,DC=joesgarage,DC=com:
SMTPSVC/exchangeserver.joesgarage.com
NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/exchangeserver.joesgarage.com
HOST/exchangeserver.www.joes.com/JOES.COM
HOST/exchangeserver.www.joes.com
exchangeMDB/exchangeserver.www.joes.com
SMTPSVC/exchangeserver.www.joes.com
HOST/exchangeserver.www.joes.com/www.joes.com
exchangeRFR/exchangeserver.www.joes.com
exchangeRFR/exchangeserver.joesgarage.com
exchangeMDB/exchangeserver.joesgarage.com
exchangeRFR/EXCHANGESERVER
exchangeMDB/EXCHANGESERVER
SMTPSVC/EXCHANGESERVER
HOST/EXCHANGESERVER
注意：上面的所有“HOST/”SPN 均显示 JOES.COM；这表示主 DNS 设置为 joes.com，而不是 joesgarage.com。在部署代理时，DPM 服务器将解析名称 EXCHANGESERVER.JOESGARAGE.COM，这是用于构建在部署代理时所请求的 SPN 的名称。但是，由于为 exchangeserver 注册的 SPN 是 www.joes.com，Kerberos 连接尝试将因为 SPN 不匹配而失败；发生这种情况时，我们会尝试进行匿名连接 - 这就是为什么有些情况下 Exchange 服务器上会记录事件 ID 6033 的原因。
3.运行以下命令以确保 HOST SPN 正确注册：
setspn -a HOST/exchangeserver.joesgarage.com exchangeserver
setspn -a HOST/exchangeserver exchangeserver
4.在整个 AD 内复制更改，并再次测试 DPM 代理部署
综合考虑以上内容 - 这么多内容，我从哪儿开始呢？我首先使用哪个工具？何时使用？
没有必须遵循的“绝对”顺序，但我们要从简单处着手。
如果您在尝试将 DPM 代理推送到服务器时失败，建议您测试以下项。
从 DPM 服务器到受保护服务器
ping <protected server name>
net view \\<protected server name>
Sc \\<protected server name> query
Wmic /node:"<protected server name>" OS list brief
Wbemtest
Ping
如果 ping 失败，则使用 tracert 查看通信止于何处。
如果 ping 失败，则检查目标服务器上的集成防火墙。
如果使用名称时 ping 失败，则通过 ping 目标服务器的 IP 地址进行测试。
如果使用名称时 ping 失败但使用 IP 地址时成功，则检查 DNS 注册。
如果 ping 成功，则使用 netview 测试。
Netview
如果 net view 失败并出现错误 53，则确保计算机名称正确并且启用了文件和打印机共享。
如果 net view 失败并出现“System error 5 has occurred.Access is denied.”，确保您用于登录的帐户有权
查看远程计算机上的共享。
如果使用名称时 net view 失败，则使用 net view \\ipaddress 测试，如果成功，则说明名称解析可能存在问题。
a.) 转到目标服务器，从命令提示符处键入：“ipconfig /flushdns”并按 Enter。然后键入
“ipconfig /registerdns”，并按 Enter。这会刷新本地服务器上的 DNS 解析程序缓存并向
DNS 重新注册名称。
b.) 从 DPM 服务器上的命令提示符处，键入：“ipconfig /flushdns”并按 Enter。然后键入
“ipconfig /registerdns”。
net view 现在可正常工作吗？如果 net view 成功，则确保列出了 ADMIN$。
SC
SC \\<ServerName> 查询会失败吗？如果失败：
a.) 检查目标服务器上的集成防火墙，以查看 RPC 通信是否被锁定和拒绝。
关闭防火墙和/或依赖防火墙日志记录，如前面所述。
b.) 如果 DPM 服务器和目标服务器之间存在任何防火墙，则确保 RPC 端口范围已打开。
记住，端口范围是从 TCP 端口范围 1024
至 65535 动态分配的。
可以对该端口范围进行配置使其成为受限端口，但需要仔细考虑并且需要与网络管理员协作，因为它会影响其他类型的通信。
如何配置 RPC 动态端口分配以使用防火墙：https://support.microsoft.com/kb/154596
WMIC 和 WBEMTEST
如果“wmic /node:"<protected server name>" OS list brief”失败，并且/或者 WBEMTEST 失败，则按照以下文章中的说明操作：
在 Data Protection Manager 2007 中排查代理部署问题 – DCOM：https://blogs.technet.com/b/askcore/archive/2008/05/09/troubleshooting-agent-deployment-in-data-protection-manager-2007-dcom.aspx
端口与 TCP 烟囱和 RSS
如果已执行上述步骤，确定所有内容都没有问题，接下来就应该检查目标服务器上的端口，当然要尝试关闭 TCP 烟囱和 RSS 以进行测试。使用 Netstat 或 Tcpview 并再次检查防火墙日志记录，以确定是否存在任何被拒绝的通信。
总结
可能很难追踪 Data Protection Manager 代理的通信。有许多内置工具、可免费公开下载的工具或需要付费购买的工具可以使用，每个人都有自己最喜欢的工具。我只介绍了 Data Protection Manager 支持部门最常用的一些工具。它们相对快速而且简单，可以帮助我们迅速找出问题根源。如果从网络的角度来看，一切似乎都表示能够成功通信，那么请按照下面“其他资源”部分的三篇文章中的说明操作，并参考位于以下位置中的 DPM 事件日志和 DPM 错误日志：
客户端活动--%Program Files%\Microsoft Data Protection Manager\DPM\Temp
DPM 服务器活动--%Program Files%\Microsoft DPM\DPM\Temp
可以使用记事本打开这些日志，查看发生的哪些情况可能导致失败。
其他资源
在 Data Protection Manager 2007 中排查代理部署问题：https://blogs.technet.com/b/askcore/archive/2008/04/23/troubleshooting-agent-deployment-in-data-protection-manager-2007.aspx
在 Data Protection Manager 2007 中排查代理部署问题 – DCOM：https://blogs.technet.com/b/askcore/archive/2008/05/09/troubleshooting-agent-deployment-in-data-protection-manager-2007-dcom.aspx
在 Data Protection Manager 2007 中排查代理部署问题 – 网络
https://blogs.technet.com/b/askcore/archive/2008/05/01/troubleshooting-agent-deployment-in-data-protection-manager-2007-networking.aspx
Shane Brasher | 高级支持呈报工程师
在 Facebook 和 Twitter 上获得最新的 System Center 新闻：
App-V 团队博客：https://blogs.technet.com/appv/
AVIcode 团队博客：https://blogs.technet.com/b/avicode
ConfigMgr 支持团队博客：https://blogs.technet.com/configurationmgr/
DPM 团队博客：https://blogs.technet.com/dpm/
MED-V 团队博客：https://blogs.technet.com/medv/
OOB 支持团队博客：https://blogs.technet.com/oob/
Opalis 团队博客：https://blogs.technet.com/opalis
Orchestrator 支持团队博客：https://blogs.technet.com/b/orchestrator/
OpsMgr 支持团队博客：https://blogs.technet.com/operationsmgr/
SCMDM 支持团队博客：https://blogs.technet.com/mdm/
SCVMM 团队博客：https://blogs.technet.com/scvmm
Server App-V 团队博客：https://blogs.technet.com/b/serverappv
Service Manager 团队博客：https://blogs.technet.com/b/servicemanager
System Center Essentials 团队博客：https://blogs.technet.com/b/systemcenteressentials
WSUS 支持团队博客：https://blogs.technet.com/sus/
Forefront Server Protection 博客：https://blogs.technet.com/b/fss/
Forefront Identity Manager 博客：https://blogs.msdn.com/b/ms-identity-support/
Forefront TMG 博客：https://blogs.technet.com/b/isablog/
Forefront UAG 博客：https://blogs.technet.com/b/edgeaccessblog/
dpm 2007 dpm 2010 dpm 2012 system center 2012 data protection manager