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 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.
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:
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.
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.
There are a rich set of problems you can encounter while changing the DNS suffix. Here are the ones we know about:
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.
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.