none
Package Download failed during OSD RRS feed

  • Question

  • Hello,

    I have a weird problem during OSD Task Sequence.

    When a task sequence step need to download a package, it will fail 3 times then success.

    Example with a package (text in bold) :

    Trying https://DP-FQDN/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    Content source is a DP token auth capable, but DP auth token is not available OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    GetDirectoryListing() entered OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    Initializing HTTP transport. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    Setting URL = https://DP-FQDN/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
       Address=https://DP-FQDN, Scheme=https, Object=/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002, Port=443. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    Content source is DP token auth capable, but DP auth token is not available OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    Setting Media Certificate. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    WinHttp credentials set OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    CLibSMSMessageWinHttpTransport::Send: WinHttpOpenRequest - URL: DP-FQDN:443  PROPFIND /CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002 OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    In SSSL - but not using DP auth token or authenticator OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    In SSL, but with no client cert OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    401 - Unsuccessful with anonymous access. Retrying with context credentials. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    Using thread token for request OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    401 - Unsuccessful with context credentials. Retrying with supplied credentials. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    401 - Unsuccessful with supplied credentials. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    401 - Unsuccessful on all retries. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    SendResourceRequest() failed. 80190191 OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    SendResourceRequest(pCertContext), HRESULT=80190191 (..\downloadcontent.cpp,612) OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    oDavRequest.GetDirectoryListing (setDirs, setFiles, pCertContext), HRESULT=80190191 (..\resolvesource.cpp,3301) OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    Download() failed. 80190191. OSDSetupHook 03/01/2019 13:51:06 1840 (0x0730)
    Trying https://DP-FQDN/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002. OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    Content source is a DP token auth capable, but DP auth token is not available OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    GetDirectoryListing() entered OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    Initializing HTTP transport. OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    Setting URL = https://DP-FQDN/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002. OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
       Address=https://DP-FQDN, Scheme=https, Object=/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002, Port=443. OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    Content source is DP token auth capable, but DP auth token is not available OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    Setting Media Certificate. OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    WinHttp credentials set OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    CLibSMSMessageWinHttpTransport::Send: WinHttpOpenRequest - URL: DP-FQDN:443  PROPFIND /CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002 OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    In SSSL - but not using DP auth token or authenticator OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    In SSL, but with no client cert OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    401 - Unsuccessful with anonymous access. Retrying with context credentials. OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    Using thread token for request OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    401 - Unsuccessful with context credentials. Retrying with supplied credentials. OSDSetupHook 03/01/2019 13:51:21 1840 (0x0730)
    401 - Unsuccessful with supplied credentials. OSDSetupHook 03/01/2019 13:51:24 1840 (0x0730)
    401 - Unsuccessful on all retries. OSDSetupHook 03/01/2019 13:51:24 1840 (0x0730)
    SendResourceRequest() failed. 80190191 OSDSetupHook 03/01/2019 13:51:24 1840 (0x0730)
    SendResourceRequest(pCertContext), HRESULT=80190191 (..\downloadcontent.cpp,612) OSDSetupHook 03/01/2019 13:51:24 1840 (0x0730)
    oDavRequest.GetDirectoryListing (setDirs, setFiles, pCertContext), HRESULT=80190191 (..\resolvesource.cpp,3301) OSDSetupHook 03/01/2019 13:51:24 1840 (0x0730)
    Download() failed. 80190191. OSDSetupHook 03/01/2019 13:51:24 1840 (0x0730)
    Trying https://DP-FQDN/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Content source is a DP token auth capable, but DP auth token is not available OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    GetDirectoryListing() entered OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Initializing HTTP transport. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Setting URL = https://DP-FQDN/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
       Address=https://DP-FQDN, Scheme=https, Object=/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002, Port=443. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Content source is DP token auth capable, but DP auth token is not available OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Setting Media Certificate. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    WinHttp credentials set OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    CLibSMSMessageWinHttpTransport::Send: WinHttpOpenRequest - URL: DP-FQDN:443  PROPFIND /CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002 OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    In SSSL - but not using DP auth token or authenticator OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    In SSL, but with no client cert OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    401 - Unsuccessful with anonymous access. Retrying with context credentials. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Using thread token for request OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    401 - Unsuccessful with context credentials. Retrying with supplied credentials. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    401 - Unsuccessful with supplied credentials. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    401 - Unsuccessful on all retries. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    SendResourceRequest() failed. 80190191 OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    SendResourceRequest(pCertContext), HRESULT=80190191 (..\downloadcontent.cpp,612) OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    oDavRequest.GetDirectoryListing (setDirs, setFiles, pCertContext), HRESULT=80190191 (..\resolvesource.cpp,3301) OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Download() failed. 80190191. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Trying https://DP-FQDN/NOCERT_SMS_DP_SMSPKG$/PRI00002. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    GetDirectoryListing() entered OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Initializing HTTP transport. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Setting URL = https://DP-FQDN/NOCERT_SMS_DP_SMSPKG$/PRI00002. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
       Address=https://DP-FQDN, Scheme=https, Object=/NOCERT_SMS_DP_SMSPKG$/PRI00002, Port=443. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Setting Media Certificate. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    WinHttp credentials set OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    CLibSMSMessageWinHttpTransport::Send: WinHttpOpenRequest - URL: DP-FQDN:443  PROPFIND /NOCERT_SMS_DP_SMSPKG$/PRI00002 OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    In SSSL - but not using DP auth token or authenticator OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    In SSL, but with no client cert OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    401 - Unsuccessful with anonymous access. Retrying with context credentials. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Using thread token for request OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    401 - Unsuccessful with context credentials. Retrying with supplied credentials. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)
    Request was successful. OSDSetupHook 03/01/2019 13:51:39 1840 (0x0730)

    I've verified the Network Access Account and IIS Windows Authentication.

    IIS logs show error 401 2 5 1630 0 then 401 1 2148074252 1630 0.

    Does somebody have an idea?

    Happy New Year !

    Pierre

    Thursday, January 3, 2019 1:42 PM

All replies

  • Are you using https certificates? And are they validated and trusted and still within date and not expired?
    If you have validated your credentials for your network access account have you tried to browse to the IIS Virtual Application SMS_DP_SMSPKG$ and check to see if you can access this ok

    Thursday, January 3, 2019 2:04 PM
  • Hello,

    When I try to access to https://DP-FQDN/SMS_DP_SMSPKG$ IE prompt me for a certificate but I can't choose the Machine certificate from our PKI.

    SCCM servers are using HTTPS only and certificates are valid.

    When I try to access to https://DP-FQDN/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002 IE prompt me for Windows authentication. If I provide the Network Access Account or an SCCM Admin account, it prompt me again 3 times then display me a blank page.

    Thursday, January 3, 2019 2:59 PM
  • are you experiencing this issue with anything you try to push?
    if so sounds like an authentication issue. Where the credentials are concerned try to go into IIS Authentication and go to Windows and change the providers make sure NTLM is up top.

    The machine with the client certificate issues can you confirm the sccm agent is connecting with HTTPS and is showing as PKI connected?

    Thursday, January 3, 2019 3:16 PM
  • Hello,
      
    In the first 3 times, clients tried to contact this address:
     
    https://DP-FQDN/CCMTOKENAUTH_SMS_DP_SMSPKG$/PRI00002
     
    After 3 failures, it started contacting this address and succeeded. 
     
    https://DP-FQDN/NOCERT_SMS_DP_SMSPKG$/PRI00002
     
    Note that contacting this NOCERT folder does not mean that no cert is used. It just means that cert that the client presents to the server does not need a subject name that matches the client's machine name. This is because during OSD WinPE clients don't have real machine names. Certs are still used. 
     
    Hope my answer could help you and look forward to your feedback.
     
    Best Regards,
    Ray

    Please remembers to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, January 4, 2019 10:30 AM
  • Hello,

    Thanks for your reply. I read the log multiples times but haven't noticed the difference between CCMTOKENAUTH and NOCERT... Sorry...

    It's weird that in WinPE, Tasksequence try to download packages with certs with subjectname matching...

    OSD is much longer with that when there is a lot of packages.

    I will try to find a way.

    Have a good day.

    Monday, January 7, 2019 2:03 PM
  • Hello,
     
    Is your CM version 1810?
     
    Best Regards,
    Ray

    Please remembers to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, January 9, 2019 12:02 PM
  • I'm having the same problem and it just started after upgrading to CM 1810
    Thursday, January 10, 2019 8:45 AM
  • We are seeing the same issue as yours @pierre Nichelle. Have you resolved it? 

    Apparently after the SCCM upgrade from 1806 to 1810 (Running the site in PKI) we've seen these two new Virtual Directories in IIS (CCMTOKENAUTH_SMS_DP_SMSPKG$) & (CCMTOKENAUTH_SMS_DP_SMSSIG$). 

    During OSD via PXE when downloading the content from DP, the Client machines tries to download the content from "CCMTOKENAUTH_SMS_DP_SMSPKG$"  Then fails retires for 3 times then get's the content from Vdir "NOCERT_SMS_DP_SMSPKG$". 

    During this retrieval and lookup process SMSTS log shows many 80190191 Errors, Is there any way we can explicitly let our clients to not to look into this VDir "CCMTOKENAUTH_SMS_DP_SMSPKG$", (Hoping to cut down the files lookup time & 80190191 error codes in SMSTS.log)


    • Edited by Harish CCM Wednesday, January 16, 2019 9:15 PM
    Wednesday, January 16, 2019 9:13 PM
  • I opened a premiere ticket with MS. right now its been 5 days and they are no closer to resolving our problem.
    Thursday, January 17, 2019 6:12 AM
  • I have just upgraded to SCCM 1810 yesterday, and am seeing this happen on some machines. I am able to build VMs hosted on the same server that hosts the DP, but when I try to build physical machines on another subnet, I am getting the 80190191 errors, but it then fails the Task Sequence with a timeout error (000005B4)

    Please do let us know how you get on with this

    Friday, February 1, 2019 11:51 AM
  • Reports we have seen on this have traced back to older versions of the ConfigMgr client in boot images, or operating system images.

    When functionality is introduced in upgraded sites, older clients can have issues with interoperability. For more information related to this, please see: https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/interoperability-between-different-versions#bkmk_mixed. 

    When using ConfigMgr to build and capture an operating system image for deployment, the Prepare ConfigMgr Client for Capture task now removes the ConfigMgr client completely: https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-steps#BKMK_PrepareConfigMgrClientforCapture. If using an old image or alternate method for creating images, verify that the ConfigMgr client has been removed from it to avoid interop issues.

    It is recommended to update boot images with the new ConfigMgr client post site upgrade - for more information on this, please see: https://docs.microsoft.com/en-us/sccm/core/servers/manage/checklist-for-installing-update-1810#update-custom-boot-images-and-media

    Also, confirm that the Setup Windows and ConfigMgr task is not referencing an older version of the ConfigMgr client, especially if a custom client package is being used. 

    If client piloting is enabled for the site and the new ConfigMgr client has not been promoted to production, configure the task sequence option to Use pre-production client package when available. Make sure the system(s) being imaged are members of the Client Piloting collection. For more information see: https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-steps#use-pre-production-client-package-when-available


    Jerry Abouelnasr [MSFT]


    Friday, February 1, 2019 9:45 PM
  • Thanks for your response. I am not using client piloting, and client is not included in the windows image, as we do not use ConfigMgr to build and capture the image. All my boot images have been updated as well.
    Monday, February 4, 2019 8:19 AM
  • I noticed that the timeout for the package that was failing was 1 minute (simple file copy). I increased this and the timeout now no longer happens. However, I am still seeing every package failing three times with 80190191, and then succeeding (as explained by others above).

    I have confirmed that permissions are fine on the folders used, and when browsing to (for example)  https://server.name/CCMTOKENAUTH_SMS_DP_SMSPKG$/OXF002A2, it prompts me to login 3 times and then fails saying "HTTP Error 401.1 - Unauthorized"

    Monday, February 4, 2019 11:23 AM
  • here is how we resolved this issue, your issue maybe different.

    CAUSE

    ======

    OSD Client was failing to decrypt the DP Auth Token. Missing DP Auth token caused the client to get 401 errors against the CCMTOKENAUTH virtual directory on the DP introducing delays in the OSD process. We submitted a change request to the product group, to not attempt accessing CCMTOKENAUTH virtual directory on the DP if the token retrieval failed.

     

    RESOLUTION

    ===========

    - When OSD Client attempted to retrieve the DP Auth Token, the token retrieval was successful but decryption of the token was failing with the below error:

     

    02-01-2019 11:32:47.792    TSMBootstrap    984 (0x3d8)    Retrieving DP Auth token from MP.

    02-01-2019 11:32:48.157    TSMBootstrap    984 (0x3d8)    CryptDecryptMessage ( &DecryptParams, pbEncrypted, nEncryptedSize, pbPlain, &nPlainSize, 0 ), HRESULT=80090003 (..\windes.cpp,466)

    02-01-2019 11:32:48.157    TSMBootstrap    984 (0x3d8)    SMS::Crypto::DES::DecryptBuffer (hCertStore, (BYTE*) pbEncryptedToken, dwEncryptedTokenSize, pDecryptedToken, dwDecryptedSize), HRESULT=80090003 (..\resolvesource.cpp,2094)

    02-01-2019 11:32:48.157    TSMBootstrap    984 (0x3d8)    DecryptBuffer() failed.

    02-01-2019 11:32:48.157    TSMBootstrap    984 (0x3d8)    ParseTokenFromResponse() failed. 0x80090003

    02-01-2019 11:32:48.157    TSMBootstrap    984 (0x3d8)    ParseTokenFromResponse (sReply.c_str(), sToken), HRESULT=80090003 (..\resolvesource.cpp,2151)

     

    - Even though we didn’t have the DP Auth token, we attempt to access the CCMTOKENAUTH virtual directory on the DP which requires the DP Auth token for authentication and fail with HTTP 401 error. This is then retried 5 times before switching over to the NOCERT virtual directory and downloading the content successfully, but these failures introduce a lot of delays in the imaging process.

    The resolution was found in the way the pxe cert was created. 

    - The only difference is the "X509v3 Key Usage", which shows 80 for the customer, vs. 10 for my certificate.

    - Researching further on this, I found that the flags are determined when making a Certificate Request, based on the "Private Key" tab which has the following options under "Key Type" section:

    Exchange - this is the default

    /* X.509 v3 Key Usage Extension flags */

    #define KU_DIGITAL_SIGNATURE            (0x80)  /* bit 0 */

    #define KU_NON_REPUDIATION              (0x40)  /* bit 1 */

    #define KU_KEY_ENCIPHERMENT             (0x20)  /* bit 2 */

    #define KU_DATA_ENCIPHERMENT            (0x10)  /* bit 3 */

    #define KU_KEY_AGREEMENT                (0x08)  /* bit 4 */

    #define KU_KEY_CERT_SIGN                (0x04)  /* bit 5 */

    #define KU_CRL_SIGN                     (0x02)  /* bit 6 */

    The final answer to all this was that we were using a Signing cert which resulted in the key usage set to 80, and that was not expected, once we created a new cert with the key usage set to exchange (10). things worked again. Also, feedback was submitted to the ConfigMgr team regarding token auth failing but then still trying the token auth url. hopefully they fix that in the next release of ConfigMgr

    Wednesday, February 13, 2019 8:27 PM
  • Thanks for the great explanation. If I want to try your resolution in my environment, do I need to assign this new certificate to ALL my DPs, or do I just need to update the boot media ?
    Wednesday, February 13, 2019 8:41 PM
  • The final answer to all this was that we were using a Signing cert which resulted in the key usage set to 80, and that was not expected, once we created a new cert with the key usage set to exchange (10). things worked again. Also, feedback was submitted to the ConfigMgr team regarding token auth failing but then still trying the token auth url. hopefully they fix that in the next release of ConfigMgr

    I checked the certificates I am using for DPs as well as boot media, and they show both Digital Signature and Key Encipherment. Als, when requesting new cert, Exchange is already selected as default.

    I have a test environment which very closely matches our live environment, and I am not having these issues in the test environment. Everything looks the same in the certificates between the 2 environments, except for when I request a new certificate in the (working) test environment, under Properties / Private Key Tab, Microsoft RSA SChannel is selected under CSP, whereas in the live environment, when I request a cert, Microsoft RSA SChannel  is NOT selected. Would this cause this strange behaviour (SCCM was working fine in both environments until I upgraded to 1810, and now in live environment, this issue is happening)

    Friday, February 15, 2019 10:02 AM