none
Child domain computers attempting to access parent domain for GPO processing

    Question

  • I have over 2000 XP embedded client computers in a child domain OU. Some of these systems fail to correctly acquire and process GP objects because they are not looking to their assigned child domain controllers which are also their assigned DNS servers. DNS resolution and connectivity to the child domain controllers function without issue but for some reason these machines generate 1030: “Windows cannot query for the list of Group Policy objects. A message that describes the reason for this was previously logged by the policy engine” and 1005: “Windows cannot connect to xxxxxxxx.com domain. (Server Down). Group Policy processing aborted” errors any time they attempt to update GPOs. The GPOs created for these clients are located in the child domain and there are no GPOs in the parent domain that are assigned to the child domain clients. I can't determine how to force the clients to pull GPOs from the appropriate DCs.



    Friday, April 10, 2015 8:48 PM

All replies

  • Hi,

    Were the domain controllers in child domain online? Here, I need to double confirm if we can successfully ping the FQDN of the domain controllers from the troubled clients.

    Regarding Event ID 1005, we can follow the suggestions provided in the following article for troubleshooting.

    Event ID 1005

    http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=1005&EvtSrc=Userenv&LCID=1033

    Best regards,

    Frank Shen 


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Monday, April 13, 2015 8:31 AM
    Moderator
  • Yes, all child domain controllers are on-line and reachable. Below is a quick connectivity test from a lab machine I set up to replicate the problem. Connectivity has never been as issue that's why this does not make sense to me at all.

    Microsoft Windows XP [Version 5.1.2600]
    (C) Copyright 1985-2001 Microsoft Corp.

    C:\Windows\system32>ipconfig /all

    Windows IP Configuration

            Host Name . . . . . . . . . . . . : sv00703-r101A
            Primary Dns Suffix  . . . . . . . : stores.xxxxxxxx.com
            Node Type . . . . . . . . . . . . : Unknown
            IP Routing Enabled. . . . . . . . : No
            WINS Proxy Enabled. . . . . . . . : No
            DNS Suffix Search List. . . . . . : stores.xxxxxxxx.com
                                                xxxxxxxx.com

    Ethernet adapter Local Area Connection:

            Connection-specific DNS Suffix  . :
            Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
            Physical Address. . . . . . . . . : 00-1A-64-43-EA-91
            Dhcp Enabled. . . . . . . . . . . : No
            IP Address. . . . . . . . . . . . : 10.13.203.101
            Subnet Mask . . . . . . . . . . . : 255.255.255.240
            Default Gateway . . . . . . . . . : 10.13.203.97
            DNS Servers . . . . . . . . . . . : 10.10.10.97
                                                10.10.10.94

    C:\Windows\system32>nslookup 10.10.10.97
    Server:  riv-strdc02.stores.xxxxxxxx.com
    Address:  10.10.10.97

    Name:    riv-strdc02.stores.xxxxxxxx.com
    Address:  10.10.10.97


    C:\Windows\system32>nslookup 10.10.10.94
    Server:  riv-strdc02.stores.xxxxxxxx.com
    Address:  10.10.10.97

    Name:    riv-strdc04.stores.xxxxxxxx.com
    Address:  10.10.10.94


    C:\Windows\system32>ping riv-strdc02.stores.xxxxxxxx.com

    Pinging riv-strdc02.stores.xxxxxxxx.com [10.10.10.97] with 32 bytes of data:

    Reply from 10.10.10.97: bytes=32 time=18ms TTL=121
    Reply from 10.10.10.97: bytes=32 time=20ms TTL=121
    Reply from 10.10.10.97: bytes=32 time=18ms TTL=121
    Reply from 10.10.10.97: bytes=32 time=16ms TTL=121

    Ping statistics for 10.10.10.97:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 16ms, Maximum = 20ms, Average = 18ms

    C:\Windows\system32>ping riv-strdc04.stores.xxxxxxxx.com

    Pinging RIV-STRDC04.stores.xxxxxxxx.com [10.10.10.94] with 32 bytes of data:

    Reply from 10.10.10.94: bytes=32 time=14ms TTL=121
    Reply from 10.10.10.94: bytes=32 time=15ms TTL=121
    Reply from 10.10.10.94: bytes=32 time=16ms TTL=121
    Reply from 10.10.10.94: bytes=32 time=19ms TTL=121

    Ping statistics for 10.10.10.94:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 14ms, Maximum = 19ms, Average = 16ms

    C:\Windows\system32>

    Monday, April 13, 2015 2:49 PM
  • I devised a test to determine if my GPO processing problem was machine image or network communication related. I had previously built a client machine from our current image that exhibited the GPO processing problems seen in our latest production store installs. This machine was installed in our testing lab so as not to have to constantly commandeer production systems for testing and analysis. I also had a working client in our lab that had been configured well before this problem developed and did not exhibit the GPO processing issues. That was my baseline.

    It occurred to me that I could copy this working image, install it on a different machine in the lab, change the machine name, un-join the domain and then rejoin to see if I had the same policy processing problems. It turns out I did. This was important because I was now not sure if this was a problem with the new client image as I had previously assumed it was. I then connected this client to the parent domain network and verified all policy processing worked as expected. This was not unexpected as the parent domain could be reached from this network and the 403 errors I received on the effected production clients referred to problems accessing parent DCs. I was just under the impression child domain clients did not need to access parent domain DCs if all of the GPOs were assigned in the child domain.

    I now suspect the problem is chain wide but not directly visible on legacy machines as they had incorporated all of the GPOs prior to the recent security changes. Our production GPOs do not change that often. Some of the security changes that have taken place over the last year or two have obviously had some unintended consequences in terms of access restrictions and GPO processing. I suspect this is a firewall port issue as most other protocols work without issue.

    I just wish I had been able to find some documentation detailing the relationship of parent and child domains with regard to group policy. I had known for some time that the client machines in the child domain could not directly communicate with parent domain DCs due to our firewall configuration. I just could not prove the case as to why they needed this access to process GPOs located in the child domain. I suspect this may be an LDAP or global catalog issue where clients need to traverse the forest from the top down but I have not been able to locate any references to verify this assumption. This verification will become necessary to justify the firewall changes required to allow child domain clients access to parent domain DCs. Any assistance in this effort would be greatly appreciated.


    • Edited by unimorpheus Wednesday, April 22, 2015 10:44 PM
    Wednesday, April 22, 2015 10:36 PM