OU dnsHostname Report

Last updated: January 30, 2023
Audience: IT Staff / Technical

This document provides advice and background for delegated OU administrators who have received an email reporting dnsHostname issues within their delegated OU.

MI Policy prohibits the use of netid.washington.edu as the primary DNS suffix on computers in the NETID domain.

What You Need To Do

What you need to do depends on what operating system the computer on the report is running. But at the simplest level, to get a computer off the report, you need to change the dnsHostname attribute value so that it doesn’t have a value of X.netid.washington.edu. You can change the value to X.clients.uw.edu. Or you can use a DNS zone that you either already have, or that you request. What is required to get the dnsHostname value changes is different based on what operating system that computer is running.

Non-Windows computers flagged in the report?

We haven’t found a non-Windows platform that correctly sets the dnsHostname value or uses it in any way (but we’d love to hear otherwise). To fix these, you can simply edit the dsnHostname attribute value on the computer object in Active Directory. So you can deal with these one of two ways:

  • Modify the dnsHostname attribute to an acceptable value at domain join for each of these computers. You can use a variety of tools to do that, including:
    • Active Directory Users and Computers (View->Advanced Features=on, open computer object, Attribute Editor tab, edit dnsHostname)
    • ADSIEdit (right click, connect to=default naming context, browse to computer object, right-click properties, edit dnsHostname)
    • Ldp.exe
    • Powershell script (see below for an example)
  • Have a recurring scheduled task that calls a powershell script daily to fix up any non-Windows computer that needs a fix. For your convenience, we’ve written a PowerShell script which you can use that will change the value for every Mac in a delegated OU to have X.clients.uw.edu. You can adapt this script for your purposes. You’ll need to replace “pottery” with your delegated OU name, and if you have a different DNS suffix, you’ll need to replace “clients.uw.edu” with your preferred DNS suffix. You can modify that script further to meet your needs.
import-module activedirectory


$macs = get-adcomputer -server netid.washington.edu -ldapfilter "(&(dnshostname=*.netid.washington.edu)(operatingSystem=Mac OS X))" -SearchBase "OU=pottery,OU=Delegated,DC=netid,DC=washington,DC=edu"


foreach ($mac in $macs) {

                   $netBiosName = $mac.Name
                   $dnsHostname = "$netBiosName.clients.uw.edu"
                   set-adcomputer -identity $mac -DNSHostName $dnsHostname


                   write-host $dnsHostname

}

 

NOTE: This PowerShell script requires administrator privileges and should be run with an account that has delegated OU administrator privileges.

Windows

For a single computer fix, please reference /tools-services-support/it-systems-infrastructure/msinf/other-help/faq/ou-guidance/#dnsSuffixConfig.

For bulk fixes, we recommend using group policy. NOTE: you may want to deal with servers individually because they tend to be more sensitive to change. For an alternative bulk fix, you could write a script that leverages either the SetComputerNameEx Win32 API function or the netdom.exe binary. If you do write a script, you’ll need to run it from an account that has delegated OU administrator privileges.

To implement a group policy fix, you can create your own group policy object with the same bare-bones settings as those documented at /tools-services-support/it-systems-infrastructure/msinf/design/policy/group-policy/sample-dns-suffix-gpo/ substituting your own DNS suffix for the “Primary DNS Suffix” setting as needed.

If you are planning on using the clients.uw.edu DNS suffix, we recommend that you also include the group policy settings noted at http://www.netid.washington.edu/documentation/ddns.aspx#gpSettings.

Problems?

There are a rich set of problems you can encounter while changing the DNS suffix. Here are the ones we know about:

  • Windows 7 and Windows Server 2008 R2 have a known bug related to setting the DNS suffix. See http://support.microsoft.com/kb/2659158 for a fix that may be helpful.
  • If you have SQL installed on the computer, we’ve found that because SQL manages its own SPNs (servicePrincipalName values) and because SQL seems to have a bug related to the DNS suffix changing and because the SPN values and the dnsHostname value are tightly linked, SQL can cause a DNS suffix change to go awry in a variety of ways. To avoid these problems, you can stop SQL, make the change, reboot, and allow SQL to start on boot. If you don’t follow this, it is possible to end up in the state where the computer reports “The security database on the server does not have a computer account for this workstation trust relationship.” See below for how to resolve that.
  • Seeing the error “The security database on the server does not have a computer account for this workstation trust relationship.”? See /tools-services-support/it-systems-infrastructure/msinf/other-help/faq/ou-guidance/#fixDnsErrorViaPS for how to fix that yourself. Or ask UW-IT for help.
  • http://support.microsoft.com/kb/2018583 discusses some known causes of the error “changing the primary domain dns name of this computer … The specified server cannot perform the requested operation”. If that doesn’t help, sometimes a reboot helps.
  • Don’t change the DNS suffix (or the computer name) at the same time as you join the domain. You always need a reboot between those two actions.

If You Don’t Address This

On August 1, 2014, at its discretion, UWWI will begin enforcing this policy where reporting indicates it is needed. UWWI will notify the contacts for each OU prior to taking action. Enforcement will involve adding a group policy link with settings as documented here:  /tools-services-support/it-systems-infrastructure/msinf/design/policy/group-policy/sample-dns-suffix-gpo/.

This GPO has a WMI filter that limits which computers apply the GPO such that it only applies to computers where the OS is of Windows workstation variations. This GPO applies a DNS suffix of clients.uw.edu.

If your OU has the DNS suffix GPO applied to it and you’d later like that GPO removed, we’d be happy to entertain a request to have it removed. We’ll give you an grace policy period after removing the GPO during which we won’t re-implement the GPO to give you a chance to implement some alternative solution.

Background

It’s worth noting that changing how you join computers to your delegated OU can prevent computers from getting on this report. We strongly encourage everyone to uncheck the “Change primary DNS suffix when domain membership changes’ check box prior to joining the NETID domain.