locked
OSD Task sequence started through PXE fails for known clients RRS feed

  • Question

  • Hello

    I have an issue with an OSD task sequence that applies a Windows 7 image to a computer. The task sequence is deployed as 'Available' to the 'All Systems' collection (which includes the xY Unknown Computer objects). If I boot the target computer using PXE, it asks for the password and lists the deployed task sequence. As long the computer that was booted is unknown to ConfigMgr, it runs as it should.

    Consider now a re-imaging scenario (OS totally crashed, malware infection, hard disk exchange, ...): The computer is now known in ConfigMgr with its MAC-Address and UUID. When the computer is booted via PXE, it still lists the task sequence. BUT: it fails to resolve the dependencies with 0x80004005.

    The MP_Policy.log on the server has the following entry per attempted try to run the task sequence:

    CHandlePolicyAssignmentRequest::PolicyAccessCheck(): A client (SMSID:b20c4f13-076d-4ec7-bef9-b73c23c0df5f)
    with an issued CD certificate has accessed another client's (SMSID:GUID:5b01ee77-efaf-4521-8401-5adbb23a336b) policy.

    Where b20... is the ID of the Distribution Point Certificate and 5b01... the computers SMS-GUID. So it seems that the PXE boot image is somehow not allowed to execute a task sequence for the computer (because it doesn't own the certificate of the client?).

    Any idea how to re-image a computer from PXE without deleting the computer object? (The site is currently configured for HTTPS only, but I could change that if necessary).

    Regards,
    Ingo

    Wednesday, June 27, 2012 3:40 PM

Answers

  • Found the issue:

    The client, once it was known, was automatically added to a collection. This collection received some client settings.

    The problem now apparently was some kind of hash mismatch. The client tried to download the client settings as a policy, and had an old hash of that policy. The server then replied with a 404 - there's no policy with that hash.

    Don't ask me how said hash got corrupt, but deleting the client settings deployment and creating a new one solved it.

    Regards,

    Ingo

    • Marked as answer by 'Ingo' Wednesday, July 11, 2012 8:56 PM
    Wednesday, July 11, 2012 8:56 PM

All replies

  • You need to take a look at the smsts.log file and look at the package that is failing the dependency check. You have to make sure that the package is distributed to a DP and that the client is in the boundary of that DP.
    Thursday, June 28, 2012 1:15 AM
  • Thanks for your answer.

    According to the smsts.log, the task sequence doesn't fail at resolving a package dependency, but cannot download a policy. I guess if it were a package distribution issue, it wouldn't run for an unknown computer either. Any further ideas?

    Downloading policy body {B5C67827-E07A-4D78-B97F-B0EA82BB733D}/9.	TSPxe	27.06.2012 08:56:08	1884 (0x075C)
    Preparing Policy Body Request.	TSPxe	27.06.2012 08:56:08	1884 (0x075C)
        Setting transport.	TSPxe	27.06.2012 08:56:08	1884 (0x075C)
        Setting policy location = http://<mp>/SMS_MP/.sms_pol?{B5C67827-E07A-4D78-B97F-B0EA82BB733D}/9.SHA256:CF71CBBB0DA1442A1F02DD41DE1DA9DBC24F247731B30B795271E66D1FAE24F9.	TSPxe	27.06.2012 08:56:08	1884 (0x075C)
    Executing Policy Body Request.	TSPxe	27.06.2012 08:56:08	1884 (0x075C)
    CLibSMSMessageWinHttpTransport::Send: URL: sccm1.mydomain.ch:443  GET /SMS_MP_AltAuth/.sms_pol?{B5C67827-E07A-4D78-B97F-B0EA82BB733D}/9.SHA256:CF71CBBB0DA1442A1F02DD41DE1DA9DBC24F247731B30B795271E66D1FAE24F9	TSPxe	27.06.2012 08:56:08	1884 (0x075C)
    In SSL, but with no client cert	TSPxe	27.06.2012 08:56:08	1884 (0x075C)
    Error. Status code 404 returned	TSPxe	27.06.2012 08:56:08	1884 (0x075C)
    BOM not found on policy reply	TSPxe	27.06.2012 08:56:08	1884 (0x075C)
    CLibSMSMessageWinHttpTransport::Send: URL: sccm1.mydomain.ch:443  GET /SMS_MP_AltAuth/.sms_pol?{B5C67827-E07A-4D78-B97F-B0EA82BB733D}/9.SHA256:CF71CBBB0DA1442A1F02DD41DE1DA9DBC24F247731B30B795271E66D1FAE24F9	TSPxe	27.06.2012 08:56:15	1884 (0x075C)
    In SSL, but with no client cert	TSPxe	27.06.2012 08:56:15	1884 (0x075C)
    Error. Status code 404 returned	TSPxe	27.06.2012 08:56:15	1884 (0x075C)
    BOM not found on policy reply	TSPxe	27.06.2012 08:56:15	1884 (0x075C)
    CLibSMSMessageWinHttpTransport::Send: URL: sccm1.mydomain.ch:443  GET /SMS_MP_AltAuth/.sms_pol?{B5C67827-E07A-4D78-B97F-B0EA82BB733D}/9.SHA256:CF71CBBB0DA1442A1F02DD41DE1DA9DBC24F247731B30B795271E66D1FAE24F9	TSPxe	27.06.2012 08:56:27	1884 (0x075C)
    In SSL, but with no client cert	TSPxe	27.06.2012 08:56:27	1884 (0x075C)
    Error. Status code 404 returned	TSPxe	27.06.2012 08:56:27	1884 (0x075C)
    BOM not found on policy reply	TSPxe	27.06.2012 08:56:27	1884 (0x075C)
    CLibSMSMessageWinHttpTransport::Send: URL: sccm1.mydomain.ch:443  GET /SMS_MP_AltAuth/.sms_pol?{B5C67827-E07A-4D78-B97F-B0EA82BB733D}/9.SHA256:CF71CBBB0DA1442A1F02DD41DE1DA9DBC24F247731B30B795271E66D1FAE24F9	TSPxe	27.06.2012 08:56:31	1884 (0x075C)
    In SSL, but with no client cert	TSPxe	27.06.2012 08:56:31	1884 (0x075C)
    Error. Status code 404 returned	TSPxe	27.06.2012 08:56:31	1884 (0x075C)
    BOM not found on policy reply	TSPxe	27.06.2012 08:56:31	1884 (0x075C)
    CLibSMSMessageWinHttpTransport::Send: URL: sccm1.mydomain.ch:443  GET /SMS_MP_AltAuth/.sms_pol?{B5C67827-E07A-4D78-B97F-B0EA82BB733D}/9.SHA256:CF71CBBB0DA1442A1F02DD41DE1DA9DBC24F247731B30B795271E66D1FAE24F9	TSPxe	27.06.2012 08:56:44	1884 (0x075C)
    In SSL, but with no client cert	TSPxe	27.06.2012 08:56:44	1884 (0x075C)
    Error. Status code 404 returned	TSPxe	27.06.2012 08:56:44	1884 (0x075C)
    BOM not found on policy reply	TSPxe	27.06.2012 08:56:44	1884 (0x075C)
    hr, HRESULT=80004005 (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,4741)	TSPxe	27.06.2012 08:56:55	1884 (0x075C)
    oPolicy.RequestPolicy((GetPolicyFlags() & POLICY_SECURE) != 0, (GetPolicyFlags() & POLICY_COMPRESS) != 0), HRESULT=80004005 (e:\nts_sccm_release\sms\framework\tscore\tspolicy.cpp,2019)	TSPxe	27.06.2012 08:56:55	1884 (0x075C)
    Failed to download policy {B5C67827-E07A-4D78-B97F-B0EA82BB733D}/9 (Code 0x80004005).	TSPxe	27.06.2012 08:56:55	1884 (0x075C)
    DownloadPolicyBody(), HRESULT=80004005 (e:\nts_sccm_release\sms\framework\tscore\tspolicy.cpp,2104)	TSPxe	27.06.2012 08:56:55	1884 (0x075C)
    m_pPolicyManager->GetPolicyXML(L"SoftUpdConfig", sPolicyXML ), HRESULT=80004005 (e:\nts_sccm_release\sms\client\tasksequence\tsmbootstrap\tsmediawizardcontrol.cpp,1835)	TSPxe	27.06.2012 08:56:55	1884 (0x075C)
    Command line for extension .exe is "%1" %*	TSPxe	27.06.2012 08:56:55	1884 (0x075C)
    Set command line: "X:\sms\bin\i386\TsProgressUI.exe" /Unregister	TSPxe	27.06.2012 08:56:55	1884 (0x075C)
    Executing command line: "X:\sms\bin\i386\TsProgressUI.exe" /Unregister	TSPxe	27.06.2012 08:56:55	1884 (0x075C)
    </mp>

    Ingo

    Thursday, June 28, 2012 8:00 AM
  • Check the certificates under the Administration\Security\Certificates node to see if any certificates are blocked or missing.

    Also check the BIOS Time/Date of the client.

    • Edited by dekac99 Thursday, June 28, 2012 2:01 PM
    • Proposed as answer by OmarBell Friday, October 19, 2012 3:12 PM
    Thursday, June 28, 2012 1:59 PM
  • I have 7 certificates listed there:

    • 5 are Blocked (Type: Distribution Point)
    • 2 are Unblocked (one for Distribution Point and one for Boot Media)

    I don't know what type of certificate should be missing there.

    The client I use for testing this is a Hyper-V VM, so Date/Time is definitely correct.

    Thursday, June 28, 2012 2:56 PM
  • Found the issue:

    The client, once it was known, was automatically added to a collection. This collection received some client settings.

    The problem now apparently was some kind of hash mismatch. The client tried to download the client settings as a policy, and had an old hash of that policy. The server then replied with a 404 - there's no policy with that hash.

    Don't ask me how said hash got corrupt, but deleting the client settings deployment and creating a new one solved it.

    Regards,

    Ingo

    • Marked as answer by 'Ingo' Wednesday, July 11, 2012 8:56 PM
    Wednesday, July 11, 2012 8:56 PM
  • For me the motherboard in a computer was changed and the BIOS date and time on the new board was wrong. Once this was adjusted the TS worked like a charm
    Friday, October 19, 2012 3:14 PM