none
Exit code 3010 suddenly considered as failure RRS feed

  • Question

  • Hello,

    SCCM CB 1906 in use. Suddenly packages that return exit code 3010 is now considered a failure, as they of course should be a "success but reboot required". Below some applicable information extracted from execmgr.exe . This happens in both full desktop and Task sequence environment. Tested with a few different packages that use Reboot=ReallySuppress switch, all fail.

    - - - -

    Running "C:\WINDOWS\system32\msiexec.exe" /i "PackageX.msi" /qn /L*V c:\Somewhere\install.log REBOOT=REALLYSUPPRESS with 32bitLauncher

    ...

    Program exit code 3010

    Looking for MIF file to get program status

    Script for Package:ABC00000, Program: install failed with exit code 3010

    ...

    Execution is complete for program install. The exit code is 3010, the execution status is FailureNonRetry

    - - - -

    Packages "After running" action is "no action required".

    Any suggestions what could have broken? Last time these same packages worked correctly was about 2 weeks ago.


    Friday, September 6, 2019 10:00 AM

Answers

  • Just to verify, has "someone" altered the site control file?

    To check, if you run the below query in SQL Management studio, expand the returned XML (by clicking on it) and then look for the Reboot Return Codes property, what codes are listed for the Value 2 attribute? 

    SELECT SiteControl 
    FROM vSMS_SC_SiteControlXML 
    WHERE SiteCode = '<SITECODE>'

    See the HOW TO VIEW THE SITE CONTROL ( SITECTRL ) FILE section at https://www.anoopcnair.com/how-to-edit-sccm-site-control-sitectrl-file/ for screenshots and a brief description on this.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by no_access Wednesday, September 11, 2019 10:15 AM
    Friday, September 6, 2019 12:28 PM

All replies

  • Just to verify, has "someone" altered the site control file?

    To check, if you run the below query in SQL Management studio, expand the returned XML (by clicking on it) and then look for the Reboot Return Codes property, what codes are listed for the Value 2 attribute? 

    SELECT SiteControl 
    FROM vSMS_SC_SiteControlXML 
    WHERE SiteCode = '<SITECODE>'

    See the HOW TO VIEW THE SITE CONTROL ( SITECTRL ) FILE section at https://www.anoopcnair.com/how-to-edit-sccm-site-control-sitectrl-file/ for screenshots and a brief description on this.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by no_access Wednesday, September 11, 2019 10:15 AM
    Friday, September 6, 2019 12:28 PM
  • Thanks Jason for your reply!

    Checked the values, listed codes are the proper ones: 1604,1641,3010,3011

    I managed to reproduce the problem with packages returning exit code 1641 too.

    Very strange... additional suggestions very welcome :)

    EDIT: We have identified that clients receive faulty policies, resulting incorrect values in "RebootReturnCodes" field. So this is a client side issue, we´re investigating what is causing this.

    FIX: temporarily disabled "Client Cache settings" from all distributed client policies except default policy, then enabled back -> exit codes now back in order.



    • Edited by no_access Tuesday, September 10, 2019 5:28 AM Added fix
    Friday, September 6, 2019 2:36 PM
  • Strange. You should report your findings and evidence to Microsoft using a frowny face in the console.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Wednesday, September 11, 2019 2:58 PM
  • We also had this occur in our environment. Still re-testing the Client Cache settings disable/enable fix.
    Tuesday, December 3, 2019 10:54 PM
  • We have this issue too. Just that when applying "the client cache settings"-fix that can give you an access denied when downloading the policy for an machine in WinPE. (If you have multiple client settings that defines the client cache).

    Smsts:

    <![LOG[BOM not found on policy reply]LOG]!><time="14:30:07.336-60" date="02-06-2020" component="TSMBootstrap" context="" type="2" thread="2152" file="libsmsmessaging.cpp:5634">

    <![LOG[hr, HRESULT=80004005 (..\libsmsmessaging.cpp,5656)]LOG]!><time="14:30:11.353-60" date="02-06-2020" component="TSMBootstrap" context="" type="0" thread="2152" file="libsmsmessaging.cpp:5656">

    <![LOG[oPolicy.RequestPolicy((GetPolicyFlags() & POLICY_SECURE) != 0, (GetPolicyFlags() & POLICY_COMPRESS) != 0), HRESULT=80004005 (..\tspolicy.cpp,2254)]LOG]!><time="14:30:11.353-60" date="02-06-2020" component="TSMBootstrap" context="" type="0" thread="2152" file="tspolicy.cpp:2254">

    <![LOG[Failed to download policy {375A1DB4-3881-4D27-A677-2D36C03F7F5B}/6 (Code 0x80004005).]LOG]!><time="14:30:11.353-60" date="02-06-2020" component="TSMBootstrap" context="" type="3" thread="2152" file="tspolicy.cpp:2254">

    <![LOG[DownloadPolicyBody(), HRESULT=80004005 (..\tspolicy.cpp,2339)]LOG]!><time="14:30:11.353-60" date="02-06-2020" component="TSMBootstrap" context="" type="0" thread="2152" file="tspolicy.cpp:2339">

    <![LOG[m_pPolicyManager->GetPolicyXML(L"SoftDistConfig", sPolicyXML ), HRESULT=80004005 (tsmediawizardcontrol.cpp,1967)]LOG]!><time="14:30:11.353-60" date="02-06-2020" component="TSMBootstrap" context="" type="0" thread="2152" file="tsmediawizardcontrol.cpp:1967">

    MP_GetPolicy:

    <![LOG[MP IP: Policy ID={375A1DB4-3881-4D27-A677-2D36C03F7F5B}/6 Version=1.00 not found or authorized for 019C96E1-CE4C-4721-83E8-22EE18DF63C8 client]LOG]!><time="14:30:07.309-60" date="02-06-2020" component="MP_GetPolicy_ISAPI" context="Policy" type="1" thread="7304" file="mpisapiproxy.cpp:1170">

    Seems like settings that's not even advertised to the client at hand is playing a part. 

    The only way we've found that takes care of both problems is to only define cache settings in the default policy. I'm not talking about switching "Configure client cache size" from 'yes' to 'no'. We can't even have the "Client Cache Settings" view visible in a custom setting.

    Have a case going with Microsoft. If I or MS finds a solution I'll post it here.
    If you must define different client cache sizes, Branch Cache and so on I've successfully tested a batch file that captures 3010 as a wrapper.

    Found it online, just can't remember where.

    Install.cmd

    "%~dp0ndp48-x86-x64-allos-enu.exe" /q /norestart
    if ERRORLEVEL 3010 goto success
    if ERRORLEVEL 0 goto success
    goto failure
    :success
    set %ERRORLEVEL% = 0
    goto end
    :failure echo Failed
    EXIT 1
    #goto
    end
    :end


    Thursday, February 6, 2020 7:01 PM
  • Where you able to find an answer to this issue? 
    Thursday, March 5, 2020 1:30 PM
  • Got a call from MS just some days ago. They've classified this as a known error and it will be addressed in a future patch. They couldn't say which SCCM build that would get the fix for sure, but they leaned towards 20xx...

    I've made a script to battle this until then.
    It pretty much deletes the rows containing the corrupted returncodes from the [ClientAgentProperty_Value] table.
    It's beeing triggered by a status filter rule on the messageID 40301.

    I've sent the script to MS but since my SQL knowledge is very limited and since our site is the only one I have available for tests I won't post it.
    Don't want to make things even worse. (But feel free to look for '{0}' in that table) :)
    Tuesday, March 24, 2020 12:29 AM