From time to time, SCCM just isn’t going to cooperate with you. When running published applications from the Software Center, you may notice the apps get stuck at Downloading or Installing (return code 0x80091007 (-2146889721). This happens because the machine rebooted before the SCCM agent can finish updating all the WMI classes (or something has happened to WMI or the content), but after the actual advertisement is completed. The Root/ccm/clientsdk:ccm_program class has not completely updated, resulting in your application falling into limbo. Not great. Do the following to resolve the issue and prevent it from happening again. Make sure you also review Notes at the bottom.
#1 – Return Published Applications – Note the ADV ID’s of apps having problems
gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution
* if you’d like to output to notepad for easier reading:
gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution | out-file readme.txt | notepad.exe readme.txt
#2 – Remove Apps that are having issues using their ADV ID’s
foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter “ADV_AdvertisementID=’ABC20183′“){$i.delete()}
foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter “ADV_AdvertisementID=’ABC20184‘”){$i.delete()}
foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter “ADV_AdvertisementID=’ABC20174‘”){$i.delete()}
foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter “ADV_AdvertisementID=’ABC20128‘”){$i.delete()}
#3 – Prevent it from happening again
$ccmProgram = Get-WmiObject -Namespace ROOT\CCM\ClientSDK -Class CCM_Program | Where-Object {$_.EvaluationState –eq 14}
If ($ccmProgram -ne $null)
{
$ccmExecutionRequestEx = Get-WmiObject -Namespace ROOT\CCM\SoftMgmtAgent –Class CCM_ExecutionRequestEx | Where-Object {$_.RunningState -eq “NotifyExecution” -and $_.AdvertID -gt “” -and $_.ContentID -eq $ccmProgram.PackageID}
If ($ccmExecutionRequestEx -ne $null)
{
$ccmExecutionRequestEx | Remove-WmiObject
Start-Process sc.exe -ArgumentList “config smstsmgr depend= winmgmt/ccmexec” -Wait
Restart-Service -Name CcmExec -Force
}
}
#4 – Reinitialize Application Deployments using the Control Panel CM Action Item
or run these from an admin prompt
sc stop CcmExec
sc start CcmExec
WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule “{00000000-0000-0000-0000-000000000121}” /NOINTERACTIVE
WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule “{00000000-0000-0000-0000-000000000021}” /NOINTERACTIVE
Notes
Four other things you can try if you’re still having issues:
#1 Check the local server anti-virus. I have found SCCM package content in the quarantine area. And, let me tell you, SCCM hates missing content, especially if it’s only partially missing. You must restore the content, and add an exception to the SCCMContentLib folder.
#2 Verify all content is sync’d up between sites (specifically the package you’re having issues with). Make sure this folder’s content is the same at other locations: SCCM_Drive:\SCCMContentLib
#3 Clear local ccmcache using the Control Panel CM Applet.
#4 Just re-add the content as a new package, distribute to DPs, test the Software Center.
Delete BITS Tasks
bitsadmin /reset /allusers
cmd /c sc create — binPath= “cmd /c start c:\windows\system32\bitsadmin.exe /reset /allusers” type= own & net start — & sc delete —
bitsadmin /reset /allusers
Rebuild WMI
net stop ccmexec /y
net stop VMAuthdService /y
net stop winmgmt /y
c:
cd %systemroot%\system32\wbem
rd /S /Q repository
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl
for /f %%s in (‘dir /b /s *.dll’) do regsvr32 /s %%s
for /f %%s in (‘dir /b *.mof’) do mofcomp %%s
for /f %%s in (‘dir /b *.mfl’) do mofcomp %%s
winmgmt /resetrepository
net start winmgmt
net start VMAuthdService
net start ccmexec
even more…
Problem 1
One scenario that was a little interesting was when we were trying to re-distribute the built in boot images to some distribution points. We had removed the package from the distribution points, as we didn’t think we would need them….turns out we did.
When we went to re-add them, the distribution status kept informing us that there were no distribution points targeted. We did this a few times, both the individual DP’s as well as DP groups, each time we re-open the content locations tab on the boot package properties, it showed no DP’s.
On investigating the logs we found something odd.
The logs were reporting that the content was being REMOVED from the DP, not added to, and then, that it was removing the DP from the date sources.
OK, that’s odd, but how do I fix it?
The Fix – Problem 1
This was the first ‘stuck’ package we had come across in ConfigMgr 2012. It appeared that the package was stuck in a cycle of trying to be removed from the DP’s, but was never finishing the task. The content was still in the SCCMContentLib on both DP’s.
After a bit of a search, we turned up a database query to find which servers the package was located on:
select * from PkgServers where PkgId = ‘ABC00004′ and SiteCode =’YourSiteCode’
This returned 2 entries for the package in question. The interesting bits fields were:
- Action = 3
- SiteName = NULL
- UpdateMask = 8192
- LastRefresh = 1970…
We deleted the two entries with this command:
delete from PkgServers where PkgId = ‘ABC00004’ and SiteCode = ‘YourSiteCode’
Now, when we went back to the console, we were able to successfully redistribute the package to the DP’s.
Problem 2
The next issue that we came across was after testing some DR processes (failing the Primary Server, and Re-Installing it), we found that the Configuration Manager Client Upgrade Package was not being distributed to one of the DP’s. It was in a failed state and wouldn’t budge.
The trouble with this package is, that it is a hidden package, and you cant refresh it from the console, or delete it, or validate it, etc.
Luckily, there is a PowerShell command that can refresh package. The PackageID for the hidden upgrade package is always the same ‘ABC00003’ where ABC is your SiteCode.
$AllDPs = Get-WmiObject -Namespace”Root\SMS\Site_YourSiteCode” -Query “select * from SMS_DistributionPoint where PackageID = ‘ABC00003′”
foreach ($DP in $AllDPs) {
$DP.RefreshNow = $true
$DP.Put()
}
Try as it might though, the primary server couldn’t refresh the package. The distmgr.log revealed the following error:
ExecStaticMethod failed (80041001) SMS_DistributionPoint, FinalizeContent
After a bit of searching, it appeared to be related to a permissions issue.
Looking at the DP’s SCCMContentLib\DateLib directory, I could see a folder for the package: ABC00003.6
When trying to open the folder though, I was greeted with an access denied, despite being an admin on the server.
The Fix – Problem 2
TAKE ownership of SCCContentLib\DataLib\ABC00003.6
takeown /F D:\SCCContentLib\DataLib\ABC00003.6 /A /R
ICacls D:\SCCMContentLib\DataLib\ABC00003.6 /reset
With a reboot, the permissions were restored.
After re-running the PowerShell commands from above, the package was successfully transferred back to the DP.
