locked
SCCM Software Distribution on Linux RRS feed

  • Question

  • In my lab SCCM environment I've got 2 RHEL 6.5 servers which have the SCCM client  installed; they're quite happily sending HINV back to SCCM, and appear to be retrieving policies straight after installation and approval.

    I've set up a number of different deployments to these systems, non of which arrive. 


    When running '-rs policy' scxcm.log shows lot's of:

    2016-06-22T12:45:37,134Z Trace      [scx.core.client.agent.policy.PolicyEvaluation:149:1532:140039531245312] Skipping this policy because it has already been applied, or is disabled
    LinuxUNIXClient 22/06/2016 13:45:37
    2122549608 (0x7E838968)
    2016-06-22T12:45:37,135Z Info       [scx.client.agents.policy.EvaluatePoliciesTask:278:1532:140039531245312] ----Policy Evaluation:  Policy for entry  has evaluated to FALSE
    LinuxUNIXClient 22/06/2016 13:45:37
    2122551832 (0x7E839218)
    2016-06-22T12:45:37,135Z Trace      [scx.core.client.agent.policy.PolicyEvaluation:101:1532:140039531245312] Looking for policy in datastore /opt/microsoft/configmgr/root/ccm/policy/machine/requestedconfig/49e6f221-b0d0-4b5b-a0b7-715667d4062e
    LinuxUNIXClient 22/06/2016 13:45:37
    2122549608 (0x7E838968)
    2016-06-22T12:45:37,136Z Trace      [scx.client.utilities.SCXDataStore.SCXDataStore:1345:1532:140039531245312] Repository location changed to: /opt/microsoft/configmgr/root/ccm/policy/machine/requestedconfig/49e6f221-b0d0-4b5b-a0b7-715667d4062e
    LinuxUNIXClient 22/06/2016 13:45:37
    2122548040 (0x7E838348)
    2016-06-22T12:45:37,137Z Trace      [scx.client.utilities.SCXDataStore.SCXDataStore:1454:1532:140039531245312] ----->> Inhale opening file /opt/microsoft/configmgr/root/ccm/policy/machine/requestedconfig/49e6f221-b0d0-4b5b-a0b7-715667d4062e/policystate.xml
    LinuxUNIXClient 22/06/2016 13:45:37
    2122542520 (0x7E836DB8)
    2016-06-22T12:45:37,141Z Trace      [scx.core.client.agent.policy.PolicyEvaluation:149:1532:140039531245312] Skipping this policy because it has already been applied, or is disabled
    LinuxUNIXClient 22/06/2016 13:45:37
    2122549608 (0x7E838968)
    2016-06-22T12:45:37,142Z Info       [scx.client.agents.policy.EvaluatePoliciesTask:278:1532:140039531245312] ----Policy Evaluation:  Policy for entry  has evaluated to FALSE
    LinuxUNIXClient 22/06/2016 13:45:37
    2122551832 (0x7E839218)

    It seems that policies in /opt/microsoft/configmgr/root/ccm/policy/machine/requestedconfig are being evaluated with no issues, but no new policies are being downloaded. ('Skipping this policy because it has already been applied'). At the end of the policy evaluation it shows:  ----------------------------- No policies evaluated to true ---------------------------

    If this is indeed the case, then what could be going wrong here?

    Package deployments to Windows systems are working fine.

    Thanks



    • Edited by taunton_tom Wednesday, June 22, 2016 5:25 PM
    Wednesday, June 22, 2016 5:23 PM

Answers

  • Just an update on this issue; it turns out that I had other issues with my ConfigMgr site.

    Before I started testing ConfigMgr on Linux I had an issue with my Hyper-V host which caused the time/date to forward to 2020 on all of my guests.

    I re-installed a fresh ConfigMgr site last night and I've now successfully deployed software to my Linux servers.

    The incorrect date must have been present in the database somewhere which was causing policy issues.

    Tuesday, June 28, 2016 1:45 PM

All replies

  • What does the monitoring node tell for that deployment?

    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, June 23, 2016 7:09 AM
  • Unknown for both RHEL systems
    Thursday, June 23, 2016 8:45 AM
  • Hi,

        If you search for the deployment ID in your logs will you find something related?

    Best regards,

    Jimmy


    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.

    Thursday, June 23, 2016 10:16 AM
  • Hello, nope no reference to the deployment ID at all.

    Thursday, June 23, 2016 11:26 AM
  • Just an update on this issue; it turns out that I had other issues with my ConfigMgr site.

    Before I started testing ConfigMgr on Linux I had an issue with my Hyper-V host which caused the time/date to forward to 2020 on all of my guests.

    I re-installed a fresh ConfigMgr site last night and I've now successfully deployed software to my Linux servers.

    The incorrect date must have been present in the database somewhere which was causing policy issues.

    Tuesday, June 28, 2016 1:45 PM