Event ID 5788 and event ID 5789 occur when the DNS domain name and the Active Directory domain name differ on a Windows-based computer

You have a Window-based computer that is running one of the following operating systems:

• Microsoft Windows 2000
• Windows Vista
• Windows XP
• Windows Server 2003
• Windows Server 2008

On computers that are running one of these operating systems, the following event messages are logged in the System log:

Event message 1

Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 5788
Computer: ComputerName
Description:
Attempt to update Service Principal Name (SPN) of the computer object in Active Directory failed. The following error occurred: Detailed error message. Varies depending on the root cause

Event message 2

Event Type: Error
Event Source: NETLOGON
Event Category: None
Event ID: 5789
Computer: Computer
Description:
Attempt to update DNS Host Name of the computer object in Active Directory failed. The following error occurred: Detailed error message. Varies depending on the root cause

Note The detailed error messages for the events are listed in the "Cause" section.

This behavior occurs when a computer tries but fails to write to the dNSHostName and servicePrincipalName attributes for its computer account in an Active Directory Domain Services (AD DS) domain. A computer attempts to update these attributes under the following conditions:

• Directly after a Windows 2008-based, Windows Vista-based, Windows Server 2003-based, or Windows XP-based computer has joined a domain, the computer tries to set the dNSHostName and servicePrincipalName attributes for its computer account in the new domain.
• When the security channel is established on a Windows-based computer that is already a member of an AD DS domain, the computer tries to update the dNSHostName and servicePrincipalName attributes for its computer account in the domain.
• On a Windows-based domain controller, the Net Logon service tries to update the servicePrincipalName attribute every 22 minutes.

There are two possible causes for the update failures:

• The computer does not have sufficient permission to complete an "LDAP modify" request of the dNSHostName or servicePrincipalName attributes for its computer account.
  
  In this case, the error messages that correspond to the events that are described in the "Symptoms" section are as follows:
  • Event 5788
    Access is denied.
  • Event 5789
    The system cannot find the file specified.
• The Primary DNS suffix of the computer does not match the DNS name of the AD DS domain of which the computer is a member. This configuration is known as a “Disjoint namespace." The update is blocked in this configuration as the pre-requisite write validation of the attribute values fails. The write validation fails because the Security Accounts Manager (SAM) requires, by default, that a computer’s Primary DNS Suffix matches the DNS name of the AD DS domain of which computer is a member.
  
  In this case, the error messages that correspond to the events that are described in the "Symptoms" section are as follows:
  • Event 5788
    The attribute syntax specified to the directory service is invalid.
  • Event 5789
    The parameter is incorrect.

To resolve this problem, find the most likely cause as described in the "Cause" section. Then, use the resolution that is appropriate for the cause.

Resolution for Cause 1

To resolve this issue, you must make sure that the computer account has sufficient permissions to update its own computer object.

In the ACL Editor, make sure that there is an access control entry (ACE) for the trustee account “SELF” and that it has “Allow” access for the following extended rights:

• Validated write to DNS host name
• Validated write to service principal name

Then, verify any Deny permissions that may apply. Excluding the group memberships of the computer, the following trustees also apply to the computer:

• Everyone
• Authenticated Users
• SELF

The ACEs that are applicable to these trustees may also deny access to write to attributes, or they may deny the “Validated write to DNS host name” or “Validated write to service principal name” extended rights.

Resolution for Cause 2

To resolve this issue, use one of the following methods, as appropriate:

• Method 1: Correct an unintentional disjoint namespace

  If the disjoint configuration is unintentional and if you want to revert to contiguous namespace, use this method.
  
  For more information about how to revert to a contiguous namespace, visit the following Microsoft Web site:
  http://technet.microsoft.com/en-us/library/cc773025.aspx

  (http://technet.microsoft.com/en-us/library/cc773025.aspx)
  For Windows Server 2008 and for Windows Vista, follow these steps to configure the DNS suffix by using the Systems Properties dialog box:
  1. On the computer that recorded the events, click Start, right-click Computer, and then click Properties.
  2. In the System dialog box, click Advanced System Settings under Tasks.
  3. In the System Properties dialog box, click the Computer Name tab, click Change, and then click More.
  4. Click to select the Change primary DNS suffix when domain membership changes check box, and then click OK.
  5. If the Change primary DNS suffix when domain membership changes setting is applied by the DNS client Group Policy, remove the Group Policy setting, or unlink the policy that contains the setting from the organizational unit (OU) that contains the computer account.
  6. Restart the computer.

• Method 2: Verify that the disjoint namespace configuration is working correctly

  Use this method, if you want to keep the disjoint namespace. To do this, follow these steps to make some configuration changes to resolve the errors.
  
  For more information about how to verify that the disjoint namespace is working correctly in Windows Server 2003 and in Windows 2000 Server, visit the following Microsoft Web site:
  http://technet.microsoft.com/en-us/library/cc755926.aspx

  (http://technet.microsoft.com/en-us/library/cc755926.aspx)
  For Windows Server 2008 and for Windows Vista, for these steps to make sure that member computers stay in a disjoint namespace:
  1. On the computer that recorded the events, click Start, right-click Computer, and then click Properties.
  2. In the System dialog box, click Advanced System Settings under Tasks.
  3. In the System Properties dialog box, click the Computer Name tab, click Change, and then click More.
  4. Click to clear the Change primary DNS suffix when domain membership changes check box, and then click OK.
  5. Restart the computer.
  To make sure that the Windows Server 2008 domains are working correctly, follow these steps:
  1. In the Start Menu, point to All Programs, point to Administrative Tools, and then click ADSI Edit.
  2. Right-Click ADSI Edit, and then click Connect to.
  3. Select OK to choose the default options in the Connection Settings dialog box to work with the current domain of the server. Alternatively, specify the name of a domain controller or a domain that you want to manage in the Computer area.
  4. Double-click the domain directory partition for the domain that you want to modify.
  5. Right-click the domain object, and then click Properties.
  6. On the Attribute Editor tab, double-click the msDS-AllowedDNSSuffixes attribute in the Attributes list. If the attribute is not displayed, click Filter, make sure that Optional is selected under Show attributes and that the Show only attributes that have values option is disabled.
  7. In the Multi-valued String Editor dialog box, type a DNS suffix in the Value to add box, and then click Add.
  8. After you add all the DNS suffixes that you require for the domain, click OK.
  9. Click OK to close the properties dialog box for the domain.
  10. Right-click ADSI Edit, and then click Connect to to modify the msDS-AllowedDNSSuffixes Active Directory attribute on the domain object container in another domain.
  11. Under Computer, click Select or type a domain or server: (Server | Domain [:port]), type the name of the next domain that you want to modify, and then click OK.
  12. Repeat steps 5 through 9 to modify the domain.
  13. Repeat steps 10 through 12 to modify all the domains.

A network trace of the response to the LDAP modify request displays the following information: In this network trace, 200B hexadecimal is equal to 8203 decimal.

The net helpmsg 8203 command returns the following information:
The DNS domain name and the Active Directory domain name can differ if one or more of the following conditions are true:

• The TCP/IP DNS configuration contains a DNS domain that differs from the Active Directory domain of which the computer is a member and the Change primary DNS suffix when domain membership changes option is disabled. To view this option, right-click My Computer, click Properties, and then click the Network Identification tab.
• Windows Server 2003-based or Windows XP Professional-based computers may apply a Group Policy setting that sets the primary suffix to a value that differs from the Active Directory domain. The Group Policy setting is:
  Computer Configuration\Administrative Templates\Network\DNS Client : Primary DNS Suffix
• The domain controller resides in a domain that has been renamed by the Rendom.exe utility. However, the administrator has not yet modified the DNS suffix from the previous DNS domain name. The domain rename process does not update the primary DNS suffix to match the current DNS domain name following renames of DNS domain names.

Domains in an Active Directory forest that do not have the same hierarchical domain name are in a different domain tree. When different domain trees are in a forest, the root domains are not contiguous. However, this configuration does not constitute a disjoint DNS namespace. You have multiple DNS or even Active Directory DNS root domains. A disjoint namespace is characterized by a difference between the primary DNS suffix and the Active Directory domain name of which the computer is a member.

Disjoint namespace can be used with caution in some scenarios, but it is not supported in all scenarios.

For more information about disjoint namespace and support guidelines, visit the following Microsoft Web site:

Technical support for x64-based versions of Microsoft Windows

If your hardware came with a Microsoft Windows x64 edition already installed, your hardware manufacturer provides technical support and assistance for the Windows x64 edition. In this case, your hardware manufacturer provides support because a Windows x64 edition was included with your hardware. Your hardware manufacturer might have customized the Windows x64 edition installation by using unique components. Unique components might include specific device drivers or might include optional settings to maximize the performance of the hardware. Microsoft will provide reasonable-effort assistance if you must have technical help with a Windows x64 edition. However, you might have to contact your manufacturer directly. Your manufacturer is best qualified to support the software that your manufacturer installed on the hardware. If you purchased a Windows x64 edition such as a Windows Server 2003 x64 edition separately, contact Microsoft for technical support.

For product information about Windows XP Professional x64 Edition, visit the following Microsoft Web site: For product information about x64-based versions of Windows Server 2003, visit the following Microsoft Web site: