Microsoft System Center Management Pack for DNS 2016

  • Article

 

 

image

 

 

image

 

What’s in the Management Pack?

The System Center Management Pack for Windows Server 2016 DNS monitors DNS health, availability, configuration, security, and zone-transfer issues on DNS servers running the Windows Server 2016 operating system.

clip_image001Note

This Management Pack contains functionality for Windows Server 2016 DNS only. The management packs of different versions can live side-by-side, so you can use the previous MP versions if/when you want to monitor previous versions of Windows Server DNS.

Changes in Version 10.0.6.0

· Fixed bug: DNS server discovery was causing repeated log events (EventID: 10000) on non-2016 Windows Server computers.

· Fixed bug: DNS servers were excessively discovered for the virtual cluster servers.

· Fixed bug: incorrect error handling for script-based monitors and discoveries was leading to discovery failures and incorrect operation of the monitors.

Supported Configurations

This System Center Management Pack supports the following operating systems:

· Windows Server 2016 with DNS role installed

· Windows PowerShell feature enabled

· DNS Server Tools enabled (RSAT -> Role Administration Tools -> DNS Server Tools)

· Nano Server with Microsoft-NanoServer-DNS-Package and with DNS role installed

All the management packs are supported on System Center 2012 SP1, System Center 2012 R2 and System Center 2016 Operations Manager.

Please note that Nano Server monitoring is supported by SCOM 2016 only.

 

Before you import the Management Pack, note the following limitations:

· Agentless monitoring is not supported.

 

Security Considerations

This section provides information about using a low-privilege account with the System Center Management Pack for Windows Server 2016 DNS.

Low-Privilege Environments

The System Center Management Pack for Windows Server 2016 DNS uses the agent action account to perform discovery and run rules, tasks, and monitors. The agent action account can run as Local System or as a named account. When running as Local System, the agent action account should have all the rights needed to perform discovery and run rules, tasks, and monitors. The action account should have DNS administrator rights for all monitored DNS servers.

 

Known Issues and Troubleshooting

Error in the event log “The PowerShell script failed with below exception…”

Issue: This event in the event log may occur when the real object is removed, but not deleted from SCOM.

Resolution: Wait until next discovery is completed.

Global Test Configured Root Hints Health task may work incorrectly

Issue: On some configurations, Global Test Configured Root Hints Health task may work incorrectly due to corresponding hidden task failure.

Resolution: No resolution available.

Some Global tasks may fail with timeout

Issue: The following Global tasks may fail with timeout while working on environments with large amounts of DNS servers and zones:

· Global Test Zone Health Across All DNS Servers

· Global Test Root Domain Health Across All DNS Servers

· Global Test Configured Forwarder Health

Resolution: No resolution available.

Global tasks may work incorrectly if the zones of DNS servers are configured differently, or the lists of the zones are different.

Issue: By design, Global tasks uses the list of zones discovered by the agents installed on the DNS servers, but perform the check only at the first DNS Server in the list. Therefore, Global tasks may fail if DNS zones are not synchronized between all DNS servers monitored by SCOM.

Resolution: No resolution available.

On Nano Server, PowerShell script and monitoring host operation may fail with an error

Issue: On Nano Server,PowerShell script and monitoring host operation may fail with “System.OutOfMemoryException” error. This issue may be connected with memory leak in WMI processes.

Resolution: No resolution available.

Error with WMI and COM objects inside the Monitoring Agent workflows may occur.

Issue: Error with WMI and COM objects inside the Monitoring Agent workflows may occur. The PowerShell script fails with the following exception:

Illegal operation attempted on a registry key that has been marked for deletion.

Root cause: During the process of monitoring, the user logs on to the machine locally under the same account used for the monitoring performed on this machine. When the user logs off, registry keys in the monitoring user profile are no longer available due to User Profile Service functionality of forced unload of the user profile upon user logoff.

Resolution: In order to prevent this issue, do not use the same user account for the monitoring and local logon. If the issue still occurs, in the group policy editor, change “Do not forcefully unload the user registry at user logoff” policy setting to “Enabled”. After that, restart the Monitoring agent.