locked
Domain GUID DNS registration conflict RRS feed

  • Question

  • My company has a mixed 2003/2008 AD environment whose FSMO roles are currently hosted on a 2003 DC.  The 2008 DC's are reporting issues where entries for the domain GUID not resgistered in DNS.  In actuality, they are registered in DNS, but it's registered under a different domain GUID.  My concern is that I may have problems when I move the FSMO roles to one of the 2008 DC's and/or demote the 2003 DC's.

    The dcdiag and BPA on the 2008 DC's are looking for this record:
    _ldap._tcp.88ce7205-xxxx-xxxx-xxxx-8bf4bea37768.domains._msdcs.domain.com

    In DNS, the following records are being registered by each DC (2008 and 2003):
    _ldap._tcp.4702b1c2-xxxx-xxxx-xxxx-2cc62ce567d1.domains._msdcs.domain.com


    Best Practices Analyzer error:

    Issue:
     The "DcByGuid" DNS service (SRV) resource record that advertises this server as an available domain controller in the domain and ensures correct replication is not registered. All domain controllers (but not RODCs) in the domain must register this record.
     
    Impact:
     Other member computers and domain controllers in the domain or forest will not be able to locate this domain controller. This domain controller will not be able to provide a full suite of services.
     
    Resolution:
     Ensure that "DcByGuid" is not configured in the "DnsAvoidRegisteredRecords" list, either through Group Policy or through the registry. Restart the Netlogon service. Verify that the DNS service (SRV) resource record "_ldap._tcp.88ce7205-xxxx-xxxx-xxxx-8bf4bea37768.domains._msdcs.domain.com", pointing to the local domain controller "2K8-DC1.domain.com", is registered in DNS.

    [note: DcByGuid" is NOT configured in our "DnsAvoidRegisteredRecords" list]

     

    dcdiag /test:dns result:

                   TEST: Records registration (RReg)
                      Network Adapter [00000012] vmxnet3 Ethernet Adapter:
                         Error:
                         Missing SRV record at DNS server <IP of 2k8-DC1>:
                         _ldap._tcp.88ce7205-xxxx-xxxx-xxxx-8bf4bea37768.domains._msdcs.domain.com

                         Error:
                         Missing SRV record at DNS server <IP of 2k8-DC2>:
                         _ldap._tcp.88ce7205-xxxx-xxxx-xxxx-8bf4bea37768.domains._msdcs.domain.com

    The 2003 servers don't report this error.

    Also, when you go into ADSI Edit on any of the DC's and look at the attribute for objectGUID on the domain, the value shows up as the GUID that's missing from DNS.

    Here are two others who have similar issues that are unsolved, and possibly need the same fix:

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/9d38617d-63a2-405e-b60e-f0c10e6123c6

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/b0e3ea61-cfa4-406a-9cc3-3eb9ee61252e

     

    Monday, September 24, 2012 6:46 PM

Answers

  • I finally got this one figured out.  I did a binary search on all the files in the windows directory for the invalid domain GUID (the first 8 bytes, and have to make sure to swap byte order) and finally found where it's stored.  It's in the following registry entry:

    HKEY_LOCAL_MACHINE\SECURITY\Policy\PolDnDmG

    After I updated this registry entry to the correct GUID and restarted the machine, Netlogon and in turn WMI (I also found out WMI seems to read the domain GUID from Netlogon) now report the correct domain GUID that is equal to the domain NC head.  Also, the domain GUID SRV record was created properly in DNS after the reboot.  I went ahead and also deleted the old SRV record since Netlogon won't delete it automatically.

    If anyone else wants to make this same change, you must be careful to enter the new domain GUID into the registry in the proper format as described on this page:

    http://www.jigsawboys.com/2008/04/17/sbs-migration-fails-with-error-this-server-has-a-trust-relationship-with-domain_namelocal/

    Here are the complete list of steps copied from the above link:

    Change the GUID on the replica domain controllers
    1. Change the permissions for the SECURITY hive. To do this, follow these steps:
    a. Start Registry Editor, and then expand HKEY_LOCAL_MACHINE.
    b. Under HKEY_LOCAL_MACHINE, right-click SECURITY, and then click Permissions.
    c. Under Group or User Names, click Administrators. Under Permissions for Administrators, click to select the Allow check box in the Full Control row, and then click OK.
    d. Quit Registry Editor.

    2. Find the Active Directory domain GUID. To do this, follow these steps:
    a. On a domain controller on which the Windows Support Tools component is installed, open a command prompt.
    b. Change to the following directory: Drive_letter \Program Files\Support Tools
    c. At the command prompt, type nltest /domain_trusts /all_trusts /v , and then press ENTER.
    d. From the output, record the domain GUID string. You can locate the domain GUID string in the line of output that starts with “Dom Guid.” For example, the domain GUID string may appear as follows:
    Dom Guid: 12345678-ABCD-EFGH-IJKL-MNOPQRSTUVWX
    e. In this example, record the registry entry as follows:
    78 56 34 12 CD AB GH EF IJ KL MN OP QR ST UV WX
    f. Close the Command Prompt window.

    3. On each domain controller, change the value of the following registry entry to the value that you recorded in step 2e:
    HKEY_LOCAL_MACHINE\SECURITY\Policy\PolDnDmG

    Important You must change this registry entry on all domain controllers. Make a system state backup of all computers on which you will make this registry change. Verify that you have working backups. You must also restart all domain controllers, member servers, and workstations after you make this registry change. Additionally, you must restart the member servers and the workstations to receive the LSA GUID.

    4. In Registry Editor, change the permissions on the SECURITY hive back to their original settings.


    • Proposed as answer by daveiver Thursday, October 18, 2012 5:56 AM
    • Edited by daveiver Thursday, October 18, 2012 6:10 AM typo
    • Marked as answer by Brandon Beachy Friday, January 18, 2013 11:33 PM
    Thursday, October 18, 2012 5:55 AM

All replies

  • Hello,

    what about the questions in other articles? Please post an unedited ipconfig /all from each DC so we can verify some basic settings.

    Are the DCs created from an image that is not prepared with sysprep?

    Any of the DCs running as VM, it seems yes according to "vmxnet3 Ethernet "?

    Are the DCs multihomed, more then one NIC or ip address used on them?


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Tuesday, September 25, 2012 7:07 AM
  • I don't know if they were prepared with sysprep.  Possibly one of them -- I doubt that both were.

    They are both running as VMs

    Neither are multihomed.  Here is the ipconfig output.  I modified the domain name to domain.com

    Windows IP Configuration

       Host Name . . . . . . . . . . . . : 2K8-DC2
       Primary Dns Suffix  . . . . . . . : domain.com
       Node Type . . . . . . . . . . . . : Broadcast
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : domain.com

    Ethernet adapter Traffic:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter
       Physical Address. . . . . . . . . : 00-50-56-85-00-11
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 172.31.10.22(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 172.31.10.1
       DNS Servers . . . . . . . . . . . : 172.31.10.22
                                           172.31.10.21
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter isatap.{F8B09052-5148-4DFC-83CA-523F7C62FBCE}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter Local Area Connection* 11:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

     

    Windows IP Configuration

       Host Name . . . . . . . . . . . . : 2K8-DC1
       Primary Dns Suffix  . . . . . . . : domain.com
       Node Type . . . . . . . . . . . . : Broadcast
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : domain.com

    Ethernet adapter Local Area Connection:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Conn
       Physical Address. . . . . . . . . : 00-50-56-85-42-00
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 172.31.10.21(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 172.31.10.1
       DNS Servers . . . . . . . . . . . : 172.31.10.22
                                           172.31.10.21
                                           192.168.1.210
                                           127.0.0.1
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter isatap.{15D83629-7C56-4F9B-8484-0756BFE30EDF}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter Teredo Tunneling Pseudo-Interface:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tuesday, September 25, 2012 4:05 PM
  • I have discovered more information on the issue.  It seems that the domain GUID that is registered in DNS (not what is in ADSIedit) is in the output of List Domain Information Using WMI on all Domain Controllers (2k3 and 2k8).  So, all domain controllers show 88ce7205-xxxx-xxxx-xxxx-8bf4bea37768 as the domain GUID according to ADSIedit;  whereas they all show 4702b1c2-xxxx-xxxx-xxxx-2cc62ce567d1 as the domain GUID according to the WMI output.

    So it seems the issue isn't specific to the 2k8 vs 2k3 dc's -- more that it's the 2k8 dc's that are noticing the problem.

    I think the question now is which one is correct?  Where is the WMI output getting the information?  And can we safely change either one so that they match?

    Tuesday, September 25, 2012 4:31 PM
  • I think the GUID in ADSIedit shoud be correct

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by Cicely Feng Friday, October 5, 2012 5:05 AM
    • Unmarked as answer by Brandon Beachy Friday, January 18, 2013 11:32 PM
    Monday, October 1, 2012 12:47 PM
  • If the GUID in ADSI edit is correct, why does DCDiag say there is a problem?
    Friday, October 5, 2012 7:09 AM
  • DCdiag says DNS is the problem

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, October 8, 2012 9:05 AM
  • So...how about a real answer?  If the domain GUIDs in ADSIEdit and DNS are different, that obviously indicates a problem.  How can it be fixed?

    Thursday, October 11, 2012 9:06 PM
  • The 2003 servers don't report this error.

    Also, when you go into ADSI Edit on any of the DC's and look at the attribute for objectGUID on the domain, the value shows up as the GUID that's missing from DNS.

    Here are two others who have similar issues that are unsolved, and possibly need the same fix:

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/9d38617d-63a2-405e-b60e-f0c10e6123c6

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/b0e3ea61-cfa4-406a-9cc3-3eb9ee61252e

    Actually, there are a couple of other threads regarding this.

    And if you're looking at the ObjectGUID of the domain, that's not the ObjectGUID alias of the DC. However, just to point out, do these values line up as they show below in the screenshot?

    .

    What I noticed in ADSI Edit, is the values are "close," but do not line up exactly. I don't know how the NTDS enumerates the DC's CNAME GUID from this value, which gets registered into the _msdcs.domain.local zone. And note: this DNS record is the DC's identifier used for replication and other DC to DC communications. For example, here's what I found at a customer's system:

    DC-01:
    Configuration
     CN=Sites
      CN=Site-Name
       CN=Servers
        CN=DC-01
         CN=NTDS Settings
          Properties
           ObjectGUID       
    Value (Hex) = A5 4A EE 49 8D F7 FB 49 86 67 6A B2 3D 3F E9 EB

    As the Attribute Editor list shows it:
    0xa5 0x4a 0xee 0x49 0x8d 0xf7 0xfb 0x49 0x86 0x67 0x6a 0xb2 0x3d 0x3f 0xe9 0xeb

    As DNS shows it under _msdcs.domain.local:
    49ee4aa5-f78d-49fb-8667-6ab23d3fe9eb._msdcs.domain.local

    .

    The above is not the same as what a dsquery found, because this query string finds the DC's actual GUID, where we need the DC's NTDS object GUID for the NTDS GUID that gets registered into _msdcs/domain.local:
    C:\>dsquery * "cn=dc-01,ou=domain controllers,dc=domain,dc=local" -scope base -attr objectguid
      objectguid
      {9F642F26-1798-48A9-A677-6C26B516E950}

    .

    .

    However, I think the better tool to find the DC's GUID, is using LDP or Replication Monitor:

    Determining the Server GUID of a Domain Controller
    http://support.microsoft.com/kb/224544

    .

    .

    .

    Double check your findings with the above info on your system. If it's correct, I think at this time to ignore the BPA errors.


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Friday, October 12, 2012 5:32 AM
  • I don't think the GUIDs of the DCs are relevant to this particular issue.  The BPA error refers to a record in DNS whose FQDN contains the GUID of the domain itself (_ldap._tcp.<domainGUID>.domains._msdcs.domain.com), not the GUID of a DC.  I can confirm that in a properly configured domain, the domain GUID as shown in ADSIEdit matches the GUID registered in DNS under domains._msdcs.domain.com, as shown below.

    Matching GUIDs

    In a domain that reports the BPA error, those GUIDs do not match, and I'd love to know which one is correct, as would a customer of mine who's experiencing this same issue at the moment.  If the GUID in ADSIEdit is correct (which I tend to believe, as it makes the most sense), how can DNS be convinced to register that GUID instead of the other one?

    Friday, October 12, 2012 10:31 PM
  • My bad for assuming the DCGuid. If that's the case, change the DomainGUID in ADSI Edit, but first copy/paste the current value into notepad or something, then change it and re-run the BPA.

    Before you do that, you may want to re-register everything cleanly to see if it automatically cleans up. Do that by the following:

    • In system32\config folder, rename the netlogon.dns and netlogon.dnb files respectively to .dns.old and .dnb.old.
    • Run an ipconfig /registerdns
    • Restart the netlogon service

    .

    Netlogon uses this file to register all SRV records into DNS. The above steps will force netlogon to re-create a new netlogon.dns file. Then double check the values. If it's clean, you're done. If not, try what I suggested to change it.

    .


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Friday, October 12, 2012 11:48 PM
  • Ace,

    I've ran into the same exact problem in this thread and would really like to know where Netlogon reads the domain GUID from when generating the netlogon.dns and netlogon.dnb files.  I've tried removing these files exactly as described above, but they get regenerated with the same incorrect domain GUID again.

    In my case, I'm seeing two different GUIDs returned by the following commands (nltest is returning an incorrect GUID) and need them to both be returning the same one:

    nltest /dsgetdc:domainname.local /FORCE
    dsquery * -d domainname.local -attr objectGUID -scope base

    I've checked adsiedit, ldp and dsquery and cannot find the domain GUID that is in my _ldap._tcp.<domainGUID>.domains._msdcs.domain.com DNS entry (and also returned by nltest).  Where is Netlogon getting it from?  If I could fix the source of this GUID it should resolve the problem.

    Thanks!

    Monday, October 15, 2012 6:14 PM
  • Ace,

    I've ran into the same exact problem in this thread and would really like to know where Netlogon reads the domain GUID from when generating the netlogon.dns and netlogon.dnb files.  I've tried removing these files exactly as described above, but they get regenerated with the same incorrect domain GUID again.

    In my case, I'm seeing two different GUIDs returned by the following commands (nltest is returning an incorrect GUID) and need them to both be returning the same one:

    nltest /dsgetdc:domainname.local /FORCE
    dsquery * -d domainname.local -attr objectGUID -scope base

    I've checked adsiedit, ldp and dsquery and cannot find the domain GUID that is in my _ldap._tcp.<domainGUID>.domains._msdcs.domain.com DNS entry (and also returned by nltest).  Where is Netlogon getting it from?  If I could fix the source of this GUID it should resolve the problem.

    Thanks!

    This is unusual. Was the domain ever renamed?

    It may be a blob in the AD database, as I've noticed the DCGuid is. That may be why you are not finding it, too.

    Are you having problems with your AD infrastructure due to this?


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Monday, October 15, 2012 6:44 PM
  • Ace,

    This domain was setup by a customer on a machine with a pre-installed sbs 2003 image.  They also have other domains that were setup on machines from the same batch and they are all reporting the same duplicate GUID from Netlogon (but unique GUIDs from dsquery).  I imagine these pre-installed images are the cause.  They were assigned a new object GUID on the domain when they were first setup, but the location that Netlogon reads it from must have not been updated.  I don't think this is necessarily affecting their core AD infrastructure, but it is breaking the custom software that we develop.  We read the domain GUID using the same technique as nltest and use this to track which domain a computer belongs to.  Since multiple domains are reporting the same domain GUID we can't correlate a computer to the proper domain.  And to make things worse, another part of our system tries to correlate the domain GUID read using the dsquery technique back to the one read from Netlogon, which of course will fail on this customers systems.  This is the first we have seen this issue; the Netlogon and dsquery domain GUID has always matched up before.

    Monday, October 15, 2012 7:28 PM
  • An Image? SBS? Interesting. I've never heard of such a thing with SBS. And I assume it can't be a sysprepped image, especially the fact that SBS is a DC.

    I don't know how to help you with that, since imaging DCs (or SBS) is not supported by Microsoft. Our take on any operating system installation is to either use a base, Sysprepped image, if not installed from scratch (preferred). However, with SBS, that's a different animal, and frankly from my years of experience, I would never image such a thing since you can't sysprep it.

    Perhaps you can give Microsoft PSS a call to help you further with this?
    http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Monday, October 15, 2012 7:37 PM
  • I apologize, I misspoke when I said "image".  The machines came with SBS 2003 pre-installed from HP.  I am not sure how HP does the pre-install.  I'm trying to avoid having the customer reinstall since this issue is affecting almost a dozen of their DCs.  Any suggestions on how I can find out where Netlogon is getting the domain GUID would be greatly appreciated.

    Monday, October 15, 2012 9:00 PM
  • I apologize, I misspoke when I said "image".  The machines came with SBS 2003 pre-installed from HP.  I am not sure how HP does the pre-install.  I'm trying to avoid having the customer reinstall since this issue is affecting almost a dozen of their DCs.  Any suggestions on how I can find out where Netlogon is getting the domain GUID would be greatly appreciated.

    DrDave pointed out where he found it.

    On one of your 2003 DCs, run:
    netdiag /v > c:\netdiag.txt

    Then search for the string "domain guid" (with a space). Do they match what you found?


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Monday, October 15, 2012 10:39 PM
  • Also, has anyone here used this script?

    List Domain Information Using WMI
    http://www.activexperts.com/activmonitor/windowsmanagement/scripts/activedirectory/domains/

    .

    And FYI, IIRC, with 2000 & 2003, I believe we can get that corrected using a netdiag /v /fix. However, netdiag is no longer supported in 2008 and newer.


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Monday, October 15, 2012 10:44 PM
  • Scratch that script. It's the same thing you used originally.

    Pinging this off fellow DS MVPs, what was discussed is possibly the best way to handle this is to find the object the GUID is representing by using one of the following: 

    Tony Murray's script:
    Powershell script to find objects using objectGUID value
    http://www.open-a-socket.com/index.php/2011/09/23/powershell-script-to-find-objects-using-objectguid-value/

    or

    Joe Richard's ADFind:
    http://www.joeware.net/freetools/index.htm

    .

    Once you get the object value, that should tell you which one is the real GUID. If they both point to the same thing, then I would assume there's a corruption in the database. If that's the case, you can fix it with NTDSUTIL, but honestly, I think you would be better off opening a case with PSS to assist to clean it up. Or even if this suggestion doesn't work, definitely a call to PSS to further help you and straighten this whole thing out.
    http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS

    .


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, October 16, 2012 2:44 AM
  • And if you call and they do find the issue, please post back updating us with what they found and tools used. This way we can also update those other two threads you posted.

    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, October 16, 2012 2:45 AM
  • Scratch that script. It's the same thing you used originally.

    Pinging this off fellow DS MVPs, what was discussed is possibly the best way to handle this is to find the object the GUID is representing by using one of the following: 

    Tony Murray's script:
    Powershell script to find objects using objectGUID value
    http://www.open-a-socket.com/index.php/2011/09/23/powershell-script-to-find-objects-using-objectguid-value/

    or

    Joe Richard's ADFind:
    http://www.joeware.net/freetools/index.htm

    .

    Once you get the object value, that should tell you which one is the real GUID. If they both point to the same thing, then I would assume there's a corruption in the database. If that's the case, you can fix it with NTDSUTIL, but honestly, I think you would be better off opening a case with PSS to assist to clean it up. Or even if this suggestion doesn't work, definitely a call to PSS to further help you and straighten this whole thing out.
    http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS

    .


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBookTwitterLinkedIn

    I've attempted to locate the object with the GUID returned by nltest (WMI also returns same GUID as nltest) and it is nowhere to be found in AD.  I used ldp, dsquery and also the powershell script in the link above to search by GUID.  All three methods find the object using the domain GUID found in adsiedit and dsquery just fine.  At this point I think it's obvious that Netlogon and WMI are getting an incorrect domain GUID, but I have no idea where they are getting it from.  I will make sure to update this thread if I get this figured out.
    Tuesday, October 16, 2012 7:08 PM
  • The guid shown in the CNAME record of a DC is derived from the objectGuid of the NTDS Settings object
     
    a7850556-73ad-49cc-a262-0e1fa3b7d345._msdcs.ADCORP.LAB
    r1fsrwdc1.adcorp.lab.
     
    16-Oct-2012  7:59:26.28
    [R1FSRWDC1] C:\>ADFIND -config -rb "CN=NTDS Settings,CN=R1FSRWDC1,CN=Servers,CN=DTCNTR01,CN=Sites" -s base objectguid
    AdFind V01.46.00cpp Joe Richards (joe@joeware.net) March 2012
    Using server: R1FSRWDC1.ADCORP.LAB:389
    Directory: Windows Server 8
    Base DN: CN=NTDS Settings,CN=R1FSRWDC1,CN=Servers,CN=DTCNTR01,CN=Sites,CN=Configuration,DC=ADCORP,DC=LAB
    dn:CN=NTDS Settings,CN=R1FSRWDC1,CN=Servers,CN=DTCNTR01,CN=Sites,CN=Configuration,DC=ADCORP,DC=LAB
    >objectGUID: {A7850556-73AD-49CC-A262-0E1FA3B7D345}
    1 Objects returned
    16-Oct-2012  8:00:39.66
    [R1FSRWDC1] C:\>
     
     
    The guid shown on the container under the domains container is derived from the objectGuid of the domain NC head
     
    fa18e54a-744b-4911-95da-af50382936e2.domains._msdcs.ADCORP.LAB
    r1fsrwdc1.adcorp.lab.
    16-Oct-2012  7:59:09.77
    [R1FSRWDC1] C:\>ADFIND -default -s base objectguid
    AdFind V01.46.00cpp Joe Richards (joe@joeware.net) March 2012
    Using server: R1FSRWDC1.ADCORP.LAB:389
    Directory: Windows Server 8
    Base DN: DC=ADCORP,DC=LAB
    dn:DC=ADCORP,DC=LAB
    >objectGUID: {FA18E54A-744B-4911-95DA-AF50382936E2}
    1 Objects returned
    16-Oct-2012  7:59:26.28
    [R1FSRWDC1] C:\>


    also see: http://jorgequestforknowledge.wordpress.com/2006/12/09/dsa-guids-and-invocation-ids/


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    Tuesday, October 16, 2012 8:17 PM
  • The guid shown in the CNAME record of a DC is derived from the objectGuid of the NTDS Settings object
     
    a7850556-73ad-49cc-a262-0e1fa3b7d345._msdcs.ADCORP.LAB
    r1fsrwdc1.adcorp.lab.
     
    16-Oct-2012  7:59:26.28
    [R1FSRWDC1] C:\>ADFIND -config -rb "CN=NTDS Settings,CN=R1FSRWDC1,CN=Servers,CN=DTCNTR01,CN=Sites" -s base objectguid
    AdFind V01.46.00cpp Joe Richards (joe@joeware.net) March 2012
    Using server: R1FSRWDC1.ADCORP.LAB:389
    Directory: Windows Server 8
    Base DN: CN=NTDS Settings,CN=R1FSRWDC1,CN=Servers,CN=DTCNTR01,CN=Sites,CN=Configuration,DC=ADCORP,DC=LAB
    dn:CN=NTDS Settings,CN=R1FSRWDC1,CN=Servers,CN=DTCNTR01,CN=Sites,CN=Configuration,DC=ADCORP,DC=LAB
    >objectGUID: {A7850556-73AD-49CC-A262-0E1FA3B7D345}
    1 Objects returned
    16-Oct-2012  8:00:39.66
    [R1FSRWDC1] C:\>
     
     
    The guid shown on the container under the domains container is derived from the objectGuid of the domain NC head
     
    fa18e54a-744b-4911-95da-af50382936e2.domains._msdcs.ADCORP.LAB
    r1fsrwdc1.adcorp.lab.
    16-Oct-2012  7:59:09.77
    [R1FSRWDC1] C:\>ADFIND -default -s base objectguid
    AdFind V01.46.00cpp Joe Richards (joe@joeware.net) March 2012
    Using server: R1FSRWDC1.ADCORP.LAB:389
    Directory: Windows Server 8
    Base DN: DC=ADCORP,DC=LAB
    dn:DC=ADCORP,DC=LAB
    >objectGUID: {FA18E54A-744B-4911-95DA-AF50382936E2}
    1 Objects returned
    16-Oct-2012  7:59:26.28
    [R1FSRWDC1] C:\>


    also see: http://jorgequestforknowledge.wordpress.com/2006/12/09/dsa-guids-and-invocation-ids/


    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    Yes, this is what I am expecting to see, but on the domains I'm having this issue, the GUID shown on the container under the domains container is not equal to the objectGuid of the domain NC head.  In the second example above, they do not match (and I've followed all procedures to regenerate the DNS records).
    Tuesday, October 16, 2012 9:01 PM
  • The Obj GUID gets registered when the instance is first created and it never changes ( though you change the DN , the GUID remains same ) - As its the system attribute i dont think AD will allow some apps or user to modify

    Tuesday, October 16, 2012 10:55 PM
  • The Obj GUID gets registered when the instance is first created and it never changes ( though you change the DN , the GUID remains same ) - As its the system attribute i dont think AD will allow some apps or user to modify

    Sainath, good point, and I understanding what you're saying, it's probably being protected by AdminSdHolder.

    Maybe it's in the way HP images their SBS OEM installations.

    And Daveiver, do you still have a warranty on this with HP? If so, I would give them a shout. You said there are a dozen DCs being affected, and curious, do you mean that there are a dozen replica DCs in this SBS environment? If so, this is the first I've heard of having that many replicas in an SBS environment, considering its max user count is 75.


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, October 16, 2012 11:02 PM
  • I finally got this one figured out.  I did a binary search on all the files in the windows directory for the invalid domain GUID (the first 8 bytes, and have to make sure to swap byte order) and finally found where it's stored.  It's in the following registry entry:

    HKEY_LOCAL_MACHINE\SECURITY\Policy\PolDnDmG

    After I updated this registry entry to the correct GUID and restarted the machine, Netlogon and in turn WMI (I also found out WMI seems to read the domain GUID from Netlogon) now report the correct domain GUID that is equal to the domain NC head.  Also, the domain GUID SRV record was created properly in DNS after the reboot.  I went ahead and also deleted the old SRV record since Netlogon won't delete it automatically.

    If anyone else wants to make this same change, you must be careful to enter the new domain GUID into the registry in the proper format as described on this page:

    http://www.jigsawboys.com/2008/04/17/sbs-migration-fails-with-error-this-server-has-a-trust-relationship-with-domain_namelocal/

    Here are the complete list of steps copied from the above link:

    Change the GUID on the replica domain controllers
    1. Change the permissions for the SECURITY hive. To do this, follow these steps:
    a. Start Registry Editor, and then expand HKEY_LOCAL_MACHINE.
    b. Under HKEY_LOCAL_MACHINE, right-click SECURITY, and then click Permissions.
    c. Under Group or User Names, click Administrators. Under Permissions for Administrators, click to select the Allow check box in the Full Control row, and then click OK.
    d. Quit Registry Editor.

    2. Find the Active Directory domain GUID. To do this, follow these steps:
    a. On a domain controller on which the Windows Support Tools component is installed, open a command prompt.
    b. Change to the following directory: Drive_letter \Program Files\Support Tools
    c. At the command prompt, type nltest /domain_trusts /all_trusts /v , and then press ENTER.
    d. From the output, record the domain GUID string. You can locate the domain GUID string in the line of output that starts with “Dom Guid.” For example, the domain GUID string may appear as follows:
    Dom Guid: 12345678-ABCD-EFGH-IJKL-MNOPQRSTUVWX
    e. In this example, record the registry entry as follows:
    78 56 34 12 CD AB GH EF IJ KL MN OP QR ST UV WX
    f. Close the Command Prompt window.

    3. On each domain controller, change the value of the following registry entry to the value that you recorded in step 2e:
    HKEY_LOCAL_MACHINE\SECURITY\Policy\PolDnDmG

    Important You must change this registry entry on all domain controllers. Make a system state backup of all computers on which you will make this registry change. Verify that you have working backups. You must also restart all domain controllers, member servers, and workstations after you make this registry change. Additionally, you must restart the member servers and the workstations to receive the LSA GUID.

    4. In Registry Editor, change the permissions on the SECURITY hive back to their original settings.


    • Proposed as answer by daveiver Thursday, October 18, 2012 5:56 AM
    • Edited by daveiver Thursday, October 18, 2012 6:10 AM typo
    • Marked as answer by Brandon Beachy Friday, January 18, 2013 11:33 PM
    Thursday, October 18, 2012 5:55 AM
  • Ahh, so it was an SBS OEM thing - the way the OEMs install SBS for their customers! Glad you figured it out.

    For SBS, we usually recommend and refer SBS questions to the SBS forum, due to SBS' differences and uniqueness. Matter of fact, the SBS gurus may have been able to figure this out quicker than we could, since that's all they deal with.

    For future SBS questions, I recommend posting them to the SBS forum:
    http://social.technet.microsoft.com/Forums/en-US/smallbusinessserver/threads

    .

    And I hope this part helps with the original poster and owner of this thread.


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Thursday, October 18, 2012 8:50 PM
  • Ahh, so it was an SBS OEM thing - the way the OEMs install SBS for their customers! Glad you figured it out.

    For SBS, we usually recommend and refer SBS questions to the SBS forum, due to SBS' differences and uniqueness. Matter of fact, the SBS gurus may have been able to figure this out quicker than we could, since that's all they deal with.

    For future SBS questions, I recommend posting them to the SBS forum:
    http://social.technet.microsoft.com/Forums/en-US/smallbusinessserver/threads

    .

    And I hope this part helps with the original poster and owner of this thread.


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBookTwitterLinkedIn

    I'm confident that this is the same issue that is affecting the owner of this thread and should also resolve the other threads.  I was able to reproduce this on a Server 2008 R2 DC by modifying the same registry key.

    Thanks for your help!

    Thursday, October 18, 2012 9:29 PM
  • I certainly hope it does!

    And you are welcome!


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Friday, October 19, 2012 5:27 AM
  • Daveiver, that is very, very cool.  I'm bookmarking the thread for the next time I run into this.  Thank you very much!

    Thursday, October 25, 2012 4:03 PM