locked
Windows XP/Server 2003 Cross-Forest Clients are not receiving Machine policy. Help? RRS feed

  • Question

  • Heres the scenario. We have all of our SCCM servers in Forest 1. One CAS, one Primary and one Secondary. Forest 1 and Forest 2 have a two way trust. I have Configuration Manager 2012 publshing the site information in the Systems Management container in both Forest 1 and Forest 2. I have a mixture of Windows XP and Windows 7 clients in Forest 1 reproting into the environment properly, they receieve policy, I can push software... everything is great!

    I also have Windows 7 and Server 2008 clients in Forest 2, I have those clients reporting up to the secondary site server and they work properly as well. Heres where the madness happens, when I try to get an XP or Server 2003 client in Forest 2 to report into my heirachy they don't seem to register fully. I can go to my console and see that they are showing their client as "Yes" and Client Activity is "Active", they are even sending state messages back to their MP and I can see that their client check is evaluating and passing successfully. However, the machines never seem to receieve their Machine policy.

    Here is what I have looked at so far on the client side logs

    ClientLocation.log

    Comes up clean, the problem machines are discovering that they are in defined boundaires and are being assigned the proper management point.

    LocationServices.log

    Also looks good, I can see that I am being assigned a local management point.

    ClientIDManagerStartup.log

    I have tried to re-install the client numerous different times and the client does get past this step, here is a snippit.

    [RegTask] - Client is not registered. Sending registration request for GUID:A8EFB09D-5667-498A-A284-A2BC1B1E66B1 ... ClientIDManagerStartup 10/19/2012 7:45:34 PM 668 (0x029C)
    [RegTask] - Client registration is pending. Server assigned ClientID is GUID:A8EFB09D-5667-498A-A284-A2BC1B1E66B1 ClientIDManagerStartup 10/19/2012 7:45:35 PM 668 (0x029C)
    [RegTask] - Sleeping for 60 seconds ... ClientIDManagerStartup 10/19/2012 7:45:35 PM 668 (0x029C)
    [RegTask] - Client registration is pending. Sending confirmation request for GUID:A8EFB09D-5667-498A-A284-A2BC1B1E66B1 ... ClientIDManagerStartup 10/19/2012 7:46:35 PM 668 (0x029C)
    [RegTask] - Client is registered. Server assigned ClientID is GUID:A8EFB09D-5667-498A-A284-A2BC1B1E66B1. Approval status 0 ClientIDManagerStartup 10/19/2012 7:46:36 PM 668 (0x029C)

    PolicyAgent.log

    This is the only spot where I have found in the logs where something strange is happening, when I initiate a Machine Policy Retreival and Evaluation Cycle the machines always come back with this

    Requesting Machine policy assignments PolicyAgent_RequestAssignments 10/19/2012 8:52:51 PM 5848 (0x16D8)
    Requesting Machine policy from authority 'SMS:SITECODE' PolicyAgent_RequestAssignments 10/19/2012 8:52:51 PM 5848 (0x16D8)

    Processing Machine assignments from 'SMS:SITECODE'. The new cookie is ''. PolicyAgent_ReplyAssignments 10/19/2012 8:52:51 PM 4248 (0x1098)

    Already processed Machine assignments from 'SMS:SITECODE' with the cookie ''. PolicyAgent_ReplyAssignments 10/19/2012 8:52:51 PM 4248 (0x1098)

    Note how that the cookie is blank on a proper system I have found that this is always populated with a date/time stamp, such as this line.

    Processing Machine assignments from 'SMS:SITECODE'. The new cookie is '2012-10-20 02:26:37.793'. <-- this is from a healthy client

    When logging into one of the affected clients and launch the Configuration Manager app from the Control Panel the only options available to run are the Machine and User Policy Retrieval and Evaluation cycles.

    I'm stumped here.



    • Edited by dletsinger Saturday, October 20, 2012 4:48 PM
    Saturday, October 20, 2012 4:01 AM

Answers

  • I figured this one out, and I believe it may be a bug.

    The clients were not automatically being approved by the Configuration Manager heirachy. After hours of digging in all the wrong holes the idea to check this setting came to me. Simple fix for the interm is to create a search that will grab all of your affected machines, do a select all, right click and approve. I verified that my heirachy is set for automatic approval, and systems in all other scenarios are being approved automatically (which is why it didn't occur to me to check this setting right away).

    • Marked as answer by dletsinger Saturday, October 20, 2012 8:56 PM
    Saturday, October 20, 2012 8:56 PM

All replies

  • I figured this one out, and I believe it may be a bug.

    The clients were not automatically being approved by the Configuration Manager heirachy. After hours of digging in all the wrong holes the idea to check this setting came to me. Simple fix for the interm is to create a search that will grab all of your affected machines, do a select all, right click and approve. I verified that my heirachy is set for automatic approval, and systems in all other scenarios are being approved automatically (which is why it didn't occur to me to check this setting right away).

    • Marked as answer by dletsinger Saturday, October 20, 2012 8:56 PM
    Saturday, October 20, 2012 8:56 PM
  • Have you approved those clients in the other forest? By default, clients in alternate forests are not automatically approved.

    Incidentally (not that you can change it now) having a CAS if you only have a single primary site is a complete waste and superfluous.


    Jason | http://blog.configmgrftw.com

    Saturday, October 20, 2012 9:31 PM
  • I have the "Automatically approve clients in trusted domains (recommended)" option checked in my heirachy configuration, this seems to work for any clients in Forest 2 that are Windows 7 or Server 2008, just not anything that is still on Windows XP or Windows Server 2003. Since the two domains are trusted this option should automatically approve the clients.

    And yes, the CAS is a waste, we did the design and implementation for our Configuration Manager 2012 deployment before the ability to add a CAS if needed information was announced as part of SP1, so I'm stuck with it for now. We wanted the flexibility that the CAS added; specifically the ability to add additional primaries if needed.

    Sunday, October 21, 2012 12:19 AM
  • Can't say I've tested this explicitly. Are you verifying approval status in the console of the various clients?

    And, this is a moot argument at this point, so it's more for others who made read this thread, but the "just in case" argument for having a CAS is like buying two cars just because you may need a second one (not a perfect analogy, but close).


    Jason | http://blog.configmgrftw.com

    Sunday, October 21, 2012 12:36 AM