Carl Webster Accessibility Statement

Carl Webster is committed to facilitating the accessibility and usability of its website, carlwebster.com, for everyone. Carl Webster aims to comply with all applicable standards, including the World Wide Web Consortium’s Web Content Accessibility Guidelines 2.0 up to Level AA (WCAG 2.0 AA). Carl Webster is proud of the efforts that we have completed and that are in-progress to ensure that our website is accessible to everyone.

If you experience any difficulty in accessing any part of this website, please feel free to email us at info@carlwebster.com and we will work with you to provide the information or service you seek through an alternate communication method that is accessible for you consistent with applicable law (for example, through telephone support).

  • Error 9611 DNS_ERROR_INVALID_ZONE_TYPE When Attempting to Configure a Microsoft DNS Scavenging Server

    July 20, 2018

    Active Directory, DNS

    I have been working with Microsoft Active Directory (AD) since July 2001 and doing AD Health Checks since September 2003. One item I have done hundreds of times, failed on me yesterday during an AD remediation project. I duplicated the problem in my lab and want to document the solution for future reference.

    I have been speaking at conferences around the world on AD topics since Synergy 2012 in San Francisco. One of my “Top 10” things I look for when doing an AD Health Check is whether DNS Aging and Scavenging is configured correctly. I would estimate that 99% of the time, it is not configured correctly.

    The DNS Server service supports Aging and Scavenging features as a mechanism for performing cleanup and removal of stale resource records which can accumulate in zone data over time.

    With dynamic update, resource records are automatically added to zones when computers start on the network. However, in some cases, they are not automatically removed when computers leave the network. For example, if a computer registers its host (A) resource record at startup and is later improperly disconnected from the network, its host (A) resource record might not be deleted. If your network has mobile users and computers, this situation can occur frequently.

    If left unmanaged, the presence of stale resource records in zone data may cause some problems:

    • If many stale resource records remain in zones, they can eventually take up server disk space and cause unnecessarily long zone transfers.
    • DNS servers that load zones that contain stale resource records might use outdated information to answer client queries, potentially causing the clients to experience name resolution problems on the network.
    • The accumulation of stale resource records at the DNS Server can degrade its performance and responsiveness.
    • In some cases, the presence of a stale resource record in a zone can prevent a DNS domain name from being used by another computer or host device.

    The DNS Server service has the following features to solve the above problems:

    • Time stamping, based on the current date and time set at the server computer, for any resource records that are added dynamically to primary-type zones. Also, timestamps are recorded in standard primary zones where aging and scavenging is enabled.

    For resource records that you add manually, a time-stamp value of zero is used, indicating that these records are not affected by the aging process and that they can remain without limitation in zone data unless you otherwise change their time-stamp or delete them.

    • Aging of resource records in local data, based on specified refresh intervals, for any eligible zones.

    Only primary-type zones that are loaded by the DNS Server service are eligible to participate in this process.

    • Scavenging for any resource records that persist beyond the specified refresh periods.

    When a DNS Server performs a scavenging operation, it can determine that resource records have aged to the point of becoming stale and remove them from zone data. You can configure servers to perform recurring scavenging operations automatically, or you can initiate an immediate scavenging operation at the server.

    Microsoft recommends setting an advanced zone parameter that enables you to specify a restricted list of IP addresses for DNS servers that are enabled to perform scavenging of the zone.

    By default, if this parameter is not specified, all DNS servers that load a Directory-integrated zone (also enabled for scavenging) attempt to perform scavenging of the zone. In some cases, this parameter can be useful if it is preferable that scavenging is performed only at some servers loading the directory-integrated zone.

    To set this parameter, you must specify the list of IP addresses for the servers that are enabled to scavenge the zone in the ZoneResetScavengeServers parameter for the zone. Configuring the scavenging server can be done using the dnscmd command, a command line-based tool for administering Windows DNS servers.

    Microsoft recommends configuring at least one and no more than two DNS servers for scavenging a zone.

    Before beginning, first, verify no scavenging server is configured by running dnscmd /ZoneInfo domain.tld as shown in Figure 1.

    Figure 1
    Figure 1

    When trying to set a scavenging server, you receive “Command failed: DNS_ERROR_INVALID_ZONE_TYPE 9611 0x258B” as shown in Figure 2.

    Figure 2
    Figure 2

    To resolve this, enable aging for the zone by issuing the following command, as shown in Figure 3.

    dnscmd /Config domain.tld /Aging 1

    Figure 3
    Figure 3

    Reissue the command to set the scavenging server (which now works), as shown in Figure 4.

    dnscmd ServerName /ZoneResetScavengeServers domain.tld IPAddressOfServerName

    Figure 4
    Figure 4

    You can now check the zone information again, which now shows the scavenging server set, as shown in Figure 5.

    Figure 5
    Figure 5

    I hope this helps.

    Webster







    About Carl Webster

    Carl Webster is an independent consultant specializing in Citrix, Active Directory, and technical documentation. Carl (aka “Webster”) serves the broader Citrix community by writing articles (see CarlWebster.com) and by being the most active person in the Citrix Zone on Experts Exchange. Webster has a long history in the IT industry beginning with mainframes in 1977, PCs and application development in 1986, and network engineering in 2001. He has worked with Citrix products since 1990 with the premiere of their first product – the MULTIUSER OS/2.

    View all posts by Carl Webster

    Comments are closed.