none
SCCM 1610 Hotfix KB4010155 has a serious bug... RRS feed

  • Question

  • Hello,

    After upgrading to the latest SCCM 1610 Hotfix (KB4010155) I noticed the following issue.

    Software Center is broke for systems that have upgraded to the latest client (5.00.8458.1520).  If a user opens the Software Center it will show "No items found." under each category.

    I am able to remedy issue with a reinstall of a previous SCCM Client.  Is Microsoft aware of this bug in this hotfix?  If so when can we expect a remedy?  I've searched around on some blogs and apparently I'm not the only one that has seen this issue.


    Wednesday, March 8, 2017 6:15 PM

All replies

  • You should open a case with Microsoft support on these issues. They may or may not be known to the product group and given that the rollup was just released at the end of last week, you may be one of the first folks deploying it.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Wednesday, March 8, 2017 7:24 PM
  • Thanks Jason, will do!
    Wednesday, March 8, 2017 8:22 PM
  • We just finished our upgrade to 1610 and were discussing the KB you mentioned here. Very interested in what you find with MS support on this. Please keep me updated.
    Friday, March 10, 2017 1:17 AM
  • I noticed something similar as issue #1.

    After upgrading the SCCM CB 1610 site with this new update, the clients were automatically upgraded from .1007 to .1520 version. This works fine however starting Software Center does not work anymore.

    I had to reinstall SCCM client on machine to fix this.

    Lucky I was that i tested this first on my test environment. Now waiting for sulution before updating my production environment.

    Friday, March 10, 2017 12:42 PM
  • is it "old" Software Center, or "new" Software Center that is impacted by this hotfix ?

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, March 14, 2017 7:47 AM
  • The new one.
    Tuesday, March 14, 2017 8:02 AM
  • Our organisation also installed KB4010155 (client version 5.00.8458.1007 > 5.00.8458.1520) and we have the same problem. When updating the Software Center is empty. Applications (attached to users) are visible, packages are hidden.

    Is there a fix to solve this?

    Tuesday, March 14, 2017 8:27 AM
  • Is there a fix to solve this?


    Not yet as far as I know, but feel free to contact Microsoft support in order to add pressure to the product group.

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

    Tuesday, March 14, 2017 9:21 AM
  • I only see, that some computers where I re-enroll the cm client, cannot installed because of the 4010155 update. Existing computers are working.

    Please remember to mark my post as an answer, if I really helped you out, or vote if usefull. Thank you!

    Tuesday, March 14, 2017 10:12 AM
  • this bug is logged on Connect, you can upvote it

    https://connect.microsoft.com/ConfigurationManagervnext/Feedback/Details/3127484


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, March 14, 2017 11:11 AM
  • I checked my registry on my failty .1520 client and the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\CcmExec]ProvisioningMode is set to TRUE

    When modified to FALSE Software Center does start again.
    So why does the upgrade from .1007 to .1520 ends in provisionmode=true ?
    Tuesday, March 14, 2017 12:11 PM
  • Did create a case at Microsoft for this and they just confirmed to me that the will not solve it now.

    This issue is currently named "a bug" and will be solved in SCCM 1702 version.

    • Proposed as answer by pollewops Wednesday, March 15, 2017 4:27 PM
    Wednesday, March 15, 2017 2:22 PM
  • Are you able to share case ID? I Will open a case and refer to yours. We are not able to upgrade to 1702 due to 2008r2 site and component servers. (Yeah I know Need to upgrade, big company, new hardware required ect so not that easy.) There should Come a fix for the 1610 Issue.
    Wednesday, March 15, 2017 8:32 PM
  • Please check if the registry key "SOFTWARE\\Microsoft\\Ccm\\CcmExec\\ProvisioningMode" exists. If so, then you should delete this key.

    • Proposed as answer by NPherson Thursday, March 16, 2017 1:07 AM
    Wednesday, March 15, 2017 9:51 PM
  • we have installed the latest hotfix KB4010155 on CMCB1610 ,so far no issues seen. clients are upgraded to latest version ,can see updates ,applications etc in software center (new) .all looks good for us. 

    Eswar Koneti | Configmgr Blog: http://www.eskonr.com | Linkedin: eskonr | Twitter: @eskonr

    Thursday, March 16, 2017 1:51 AM
  • The provisioning mode is meant to "pause" the current client and prevent it from doing anything while it is being upgraded.

    The bug of course is that the provisioning mode does not get cleaned-up.

    I'm simplifying the explanation, but the details are long.

    Anyhow, the fix is on its way.

    • Proposed as answer by TorstenMMVP Thursday, March 16, 2017 7:08 AM
    Thursday, March 16, 2017 1:54 AM
  • Yes. We have installed the latest hotfix KB4010155 on CMCB1610, no issues.

    RME

    Thursday, March 16, 2017 5:52 AM
  • Did that, didn't change the behavior for my systems.
    Thursday, March 16, 2017 6:14 PM
  • Did that, didn't change the behavior for my systems.
    did you restart the client agent after zapping the regkey?

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, March 16, 2017 8:11 PM
  • Please check if the registry key "SOFTWARE\\Microsoft\\Ccm\\CcmExec\\ProvisioningMode" exists. If so, then you should delete this key.


    That worked! Thanks. It is a good work-around, now we have to wait for the 1702 version.
    Thursday, March 16, 2017 8:20 PM
  • Did that, didn't change the behavior for my systems.

    did you restart the client agent after zapping the regkey?

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Yes.  Basically, I've had to delete the registry key, force a repair on the client, then delete the registry key again, which seems to put the client back into an active state.
    Monday, March 20, 2017 2:06 PM
  • We also had a plan to upgrade. Tested on LAB first and i didn't face any issues. We dropped our plan to install the roll up on PROD after checking this thread. 

    > Clients upgraded to 1520 and Software center is working as normal.

    Regards,

    Santhosh B S 


    Tuesday, March 21, 2017 10:17 AM
  • Did that, didn't change the behavior for my systems.

    did you restart the client agent after zapping the regkey?

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Yes.  Basically, I've had to delete the registry key, force a repair on the client, then delete the registry key again, which seems to put the client back into an active state.

    Hmm. Can you confirm how (what method) you are using to apply the hotfix?
    I wonder if some people are having troubles (and others not having troubles), due to differences in the deployment method for the hotfix?

    like, are you applying the hotfix at client install during OSD TS?
    Or you packaged the hotfix in some way?
    I may be way off target, but there used to be good (and not so good) ways of deploying client hotfixes, back in the old times...


    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Tuesday, March 21, 2017 8:38 PM
  • Thanks for the Information. Any release date when the fix will be available?


    _surfer13

    Wednesday, March 22, 2017 1:23 PM
  • We have found that when deploying new DPs, setting up the boundary groups creates a runtime error.  The only solution is to download the Hotfix 4015074. 
    Wednesday, March 22, 2017 3:11 PM
  • Looks like a fix might be out:

    Fix 4016483

    Wednesday, March 22, 2017 4:10 PM
  • That's the fix, but the fun part will be figuring out which clients are in provisioning mode and getting ahold of them to run this.  We have workstations that will go offline for weeks on end or be in remote locations that we cannot get ahold of.  Such a mess.

    Best, Jacob I'm a PC.

    Thursday, March 23, 2017 2:29 PM
  • I have also tested the Fix 4016483 on an affected machine and it solves the poblem. But as jheinikel already said, how to figure out which clients are in provisioning mode.


    _surfer13

    Thursday, March 23, 2017 2:34 PM
  • I am not 100% sure, but you could test it (even by manually setting provisioning mode): does DCM (baselines / CI evaluation) still work in that case? This might sound strange but I think that I discovered that once, but it's been a while.

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

    Thursday, March 23, 2017 2:42 PM
  • Hi Torsten,

    I have discovered 1 system by utilising a DCM looking for the registry entry, which is as expected ;-)

    Thursday, March 23, 2017 2:59 PM
  • I am testing for this issue by using Windows Updates.  I have found that machines with this issue will report non-compliance, but will not change from that state.  Using reporting, I am able to find out which machines are still in a state of non-compliant by using the "Computers in a specific state for a deployment (secondary)" report.

    I am taking those machines and adding them to a machines.txt file and using the following script to see if the machine is online, remove the reg key, and repair the client remotely.  This script seems to be working really well with removing any clients with this issue.  The main problem is that I have to catch the clients when they are online which is hit or miss.  I am hopeful that the 1702 client upgrade will work on machines in this state.

    I plan on installing the hotfix so that any future clients are not affected by this issue, but I am annoying that this happened along with the issue with Office 365 updates.  You have to set Office 365 updates in a deployment that does not allow a fallback to Microsoft in order for the clients to download properly.

    function repairclient([String] $strComputer)
    {
    $SMSCli = [wmiclass] "\\$strComputer\root\ccm:sms_client"
    $SMSCli.RepairClient()
    }
    
    $clients = get-content "Machines.txt"
    
    ForEach ($SCCMClient in $clients) 
    {
        if(Test-Connection -ComputerName $SCCMClient -BufferSize 16 -Count 1 -Quiet)
        {
            $reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $SCCMClient)
            $key = $reg.OpenSubKey('SOFTWARE\Microsoft\CCM\CCMEXEC')
            if ($key.GetValue('ProvisioningMode') -ne $null)
            {
                write-host 'Repairing' $SCCMClient
                reg DELETE "\\$SCCMClient\HKLM\Software\Microsoft\CCM\CCMEXEC" /v ProvisioningMode /f
                get-service -ComputerName $SCCMClient CCMEXEC | Stop-Service -Force -ErrorAction Continue
                Start-Sleep 5
                repairclient "$SCCMClient"
            }
        }
        Else
        {
            Write-host $SCCMClient 'not online'
        }
    }

    I hope this can at least help someone with the same issue find some help.

    Thursday, March 23, 2017 6:54 PM
  • There is Fix available and release by Microsoft for us :

    https://support.microsoft.com/en-us/help/4016483/fix-new-deployments-are-unavailable-in-software-center-on-configuratio


    Please click answer If it works Thanks KMI

    Monday, March 27, 2017 4:34 PM