背景：
我有一个两个不同AD域的环境，每个AD域都有自己的林，每个域都有两个充当DNS服务器的Windows Server 2008 R2域控制器。 域之间没有信任。
每个DNS服务器pipe理其AD域的主DNS区域，然后pipe理其他一些区域，包括其IP子网的反向查找区域; 所有区域都是AD集成的; 所有pipe理区域的DNS服务器都被正确列为该区域的权威名称服务器。
所以情况就是这样（使用假名和IP地址）：
域A：
DNS域名： domainA.dom
IP子网： 192.168.1
DCs / DNS服务器： serverA1.domainA.dom （ 192.168.1.1 ）， serverA2.domainA.dom （ 192.168.1.2 ）
权威区域： domainA.dom ， 1.168.192.in-addr.arpa ， somezone.local
域B：
DNS域名： domainB.dom
IP子网： 10.0.0
DCs / DNS服务器： serverB1.domainB.dom （ 10.0.0.1 ）， serverB2.domainB.dom （ 10.0.0.2 ）
权威区域： domainB.dom ， 0.0.10.in-addr.arpa ， someotherzone.local
域A中的DNS服务器为由域B中的DNS服务器pipe理的每个区域定义了有条件的转发器，转发给域B的DNS服务器; 域B中的DNS服务器具有相反的configuration。 所有转发器都存储在Active Directory中。
所有工作都完美无缺，每个域中的计算机都可以使用域的DNS服务器parsing两个域的正向和反向DNS查询。
问题：
我将SCOM 2012部署在域A中，并在两个DC上安装了SCOM代理; Active Directory和DNS服务器的pipe理包已安装并且是最新的。
我在这两个域控制器上都有一系列警报，如下面的警报： 为每个转发区域和每个转发的服务器生成每个警报：
Forwarder someotherzone.local (10.0.0.1) cannot resolve the host name 192.168.1.1,someotherzone.local for serverA1.domainA.dom Forwarder someotherzone.local (10.0.0.2) cannot resolve the host name 192.168.1.1,someotherzone.local for serverA1.domainA.dom Forwarder someotherzone.local (10.0.0.1) cannot resolve the host name 192.168.1.2,someotherzone.local for serverA2.domainA.dom Forwarder someotherzone.local (10.0.0.2) cannot resolve the host name 192.168.1.2,someotherzone.local for serverA2.domainA.dom Forwarder 0.0.10.in-addr.arpa (10.0.0.1) cannot resolve the host name 192.168.1.1,0.0.10.in-addr.arpa for serverA1.domainA.dom Forwarder 0.0.10.in-addr.arpa (10.0.0.2) cannot resolve the host name 192.168.1.1,0.0.10.in-addr.arpa for serverA1.domainA.dom Forwarder 0.0.10.in-addr.arpa (10.0.0.1) cannot resolve the host name 192.168.1.2,0.0.10.in-addr.arpa for serverA2.domainA.dom Forwarder 0.0.10.in-addr.arpa (10.0.0.2) cannot resolve the host name 192.168.1.2,0.0.10.in-addr.arpa for serverA2.domainA.dom
唯一的例外是域B的DNS服务器（“domainB.dom”）pipe理的主要AD DNS区域：对于该条件转发器，不生成警报，并且转发器可用性监视器为绿色。
好吧，这是什么意思？
那些监视器试图告诉我什么？
他们在检查什么？
什么是错的
为什么“domainB.dom”区域没有错误，这个区域的configuration方式和其他区域完全一样 ，既作为域B的DNS服务器中的区域，也作为域A的DNS服务器中的转发器？
回答发现，这有点不愉快（至less如果你期望人们创buildpipe理包，实际上知道他们在做什么）。
从显示器的描述中提取：
该监视器通过在目标转发器上执行NSLOOKUP来validation转发器的可用性。
该脚本执行
nslookup -timeout=<value> -querytype=<type> <name> <server>
<type>是A，NS，SOA。
<name>是要parsing的目标DNS名称。 如果是无条件转发器，则使用覆盖值，否则使用转发器域名。
<server>是发生NSLOOKUP查询的服务器的名称。
值是$Target/Property[Type="DNS!Microsoft.Windows.DNSServer.Library.Server"]/ListeningIP$，它提供当前DNS服务器正在侦听的所有IP地址的列表。由于超时秒数用于设置脚本可以运行的最长时间，因此
<value>是超时秒数/ 3。无条件转发器示例：
NSLOOKUP -timeout=30 -querytype=a www.microsoft.com 10.0.0.5将为NSLOOKUP -timeout=30 -querytype=a www.microsoft.com 10.0.0.5的DNS名称查询服务器10.0.0.5。 在这种情况下，您可以将实际的超时秒数设置为90监视器覆盖。条件转发器示例：
NSLOOKUP -timeout=30 -querytype=a www.msn.com 10.0.0.5将针对此监视器所针对的条件转发器的实际名称查询服务器10.0.0.5。
这意味着SCOM代理将尝试执行这些查询：
nslookup -timeout=30 -querytype=a domainB.dom <server> nslookup -timeout=30 -querytype=a someotherzone.local <server> nslookup -timeout=30 -querytype=a 0.0.10.in-addr.arpa <server>
这将适用于主要的AD域的DNS区域（因为DC自动注册为该区域的空Alogging），但会失败的“someotherzone.local”，它没有任何空的Alogging（我可以证实，手动创build一个后，警报消失，显示器返回绿色）。
第三个查询当然总是失败，因为在反向查找区域查找Alogging根本没有意义 。
解决scheme：重写DNS转发器可用性监视器，以执行对转发区域的NS查询，而不是查询。 这是从一开始就应该做的事情。