locked
Clients Not Receiving Policy after Install (Two-Way Trust Forest) RRS feed

  • Question

  • I have spent a couple days looking at this issue we have 2 two way trust domains and then our main domain.  Any Servers on main domain work fine, but if they are on the two way trust domains I can get a client on them but then that is it I only have machine or user policy actions.  I don't see anything drastically jumping out at me in the logs... But I am starting to wonder if this has something to do with certificates, boundaries, or AD Forest Discovery?  We are not using https... If I take a server on the two way trust domain and put on main domain client starts to work... What all logs do you think I need to look at on client and mp?  What all do you need from me to assist in a resolution?
    Wednesday, March 30, 2016 5:39 PM

All replies

  • how did you install the client on the other domain computer ?

    If you dont specify the MP how are they suppose to find the MP? have you publish in AD ? Are you using a DNS entry ?

    So i would start by looking at the log on the client like CcmMessaging.log.

    To make sure the client is assign properly to the SCCM site.

    If it is i would look to make sure that the client is approuved.



    Wednesday, March 30, 2016 6:14 PM
  • Client was installed via Push Install.  It knows what the MP is the client shows active in console but never gets polices.   CCMMessaging.log doesn't jump out at me but here is what is keeps saying every 15 minutes:

    Raising event:
    instance of CCM_CcmHttp_Status
    {
    ClientID = "GUID:09AB47E8-522B-478C-BDD0-4EB4129B309B";
    DateTime = "20160330181921.399000+000";
    HostName = "SCCMSERVER.domain.com";
    HRESULT = "0x00000000";
    ProcessID = 6300;
    StatusCode = 0;
    ThreadID = 11876;
    };

    Yes the Client is approved.


    Wednesday, March 30, 2016 6:24 PM
  • Did you look at the PolicyAgent and PolicyEvaluator log?
    Wednesday, March 30, 2016 6:38 PM
  • Yes I did check this and I did not see anything jumping out at me.  No red and looks to be okay on this log.
    Wednesday, March 30, 2016 6:41 PM
  • well would it be possible for you to upload those log so we can look at them.

    The error are not always in red.

    Wednesday, March 30, 2016 6:46 PM
  • 3 Logs requested attached.

    Logs.zip


    • Edited by cfreeman21 Wednesday, March 30, 2016 6:50 PM Made Active Hyperlink
    Wednesday, March 30, 2016 6:49 PM
  • Well looking at the log i see this: 

    [CCMHTTP] ERROR: URL=http://SCCMPSP01.mbci.corp/ccm_system_windowsauth/request, Port=80, Options=480, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE

    If you look into SCCM console and look at the last time this device communicated with SCCM.

    After you see this 

    Raising event:
    instance of CCM_CcmHttp_Status
    {
    ClientID = "GUID:09AB47E8-522B-478C-BDD0-4EB4129B309B";
    DateTime = "20160330164802.232000+000";
    HostName = "SCCMPSP01.mbci.corp";
    HRESULT = "0x87d0027e";
    ProcessID = 6300;
    StatusCode = 401;
    ThreadID = 13696;
    };

    This sound like a authentication issue. I would look at the IIS log also.

    Thursday, March 31, 2016 2:06 PM
  • Looking at IIS Log on MP is showing for this particular client and the is showing 

    2016-03-31 16:25:52 10.130.5.226 CCM_POST /ccm_system/request - 80 - 10.x.x.x ccmhttp - 200 0 0 6

    Thursday, March 31, 2016 5:29 PM
  • ccm_system_windowsauth/request and not ccm_system/request

    this is not the same virtual directory

    Thursday, March 31, 2016 5:32 PM
  • Agree but there is nothing in the log for this machine and cc_system_windowsauth/request

    I will say this issue appears to have started with the latest upgrade.

    Clients Running Version 5.00.8239.1301

    Thursday, March 31, 2016 5:51 PM