Today was supposed to be easy. Things were just supposed to work. We had been testing our ConfigMgr Task Sequence for a few weeks and today was cutover day. We had made some backend changes to our Windows 7 Task Sequence to help get ready for our upcoming Windows 10 migration (I know, haven’t upgraded yet! Get off my case!). Earlier in the week, we found one last item that needed to be added. We created a child task sequence to install a certain set of applications based on which site the device was being built for. The TS uses the Install Applications step and we just added 1-6 apps to the step. No biggie. We added the TS as a child TS into our main Windows 7 TS and tested Bare Metal builds PE on several machines without issue. However, we failed to test from Windows 7 as a Refresh from the ConfigMgr client.

Go Time

It was ‘Go Time’. I had cutover our boot image and built all new deployments and such. I kicked off a few Bare Metal builds that went fine. I kicked off a Refresh and it failed right away. I tried again. Failed. Several more computers, Failed. All were failing with the rarely helpful ‘The software could not be found on any servers at this time’ message in Software Center. If you Google it, you will mostly see responses telling you to check your Boundary Groups. It’s never Boundary Groups for us. I dug into the CAS.log and found the entry at the end of the log.

<RelatedContentIDs><RelatedContentID ID="Content_dd6f23c3-efeb-4d80-b50f-432aa15135e9.1"/></RelatedContentIDs>. Length = 110. ContentAccess 4/18/2018 10:00:06 AM 9836 (0x266C) The number of discovered DPs(including Branch DP and Multicast) is 0 ContentAccess 4/18/2018 10:00:06 AM 9836 (0x266C)

Above there was an entry with a Referenced ContentID. Based on what I was reading on various posts, the last ContentID listed was likely the culprit. I found a SQL query to look up the ContentID

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

SELECT
    CI_LocalizedProperties.DisplayName,
    CIContentPackage.CI_ID,
    CI_ContentPackages.PkgID,
    CI_ContentPackages.ContentSubFolder
FROM 
    CI_ContentPackages INNER JOIN 
    CIContentPackage ON CI_ContentPackages.PkgID = CIContentPackage.PkgID LEFT OUTER JOIN 
    CI_LocalizedProperties ON CIContentPackage.CI_ID = CI_LocalizedProperties.CI_ID
WHERE 
    contentsubfolder like '%YOURCONTENTID%'

I put in my ContentID and the query didn’t return anything. I tried a similar WMI query with no result. I thought maybe the Task Sequence was corrupt so I made a copy of it and the child Task Sequences and it still failed. I made new empty Task Sequences and copied the tasks in instead of copying the whole Task Sequence. Still failed. Eventually, we narrowed the source down to the new site application Task Sequence. From there, we began looking through the ~20 apps for missing content on the app its dependencies. Then our Application lead figured it out. She remembered an issue similar to this where applications that superseded another application that has been retired will cause the Task Sequence to fail. Sure enough, we found about 4 applications that superseded retired applications.

The Fix

I found a few sample queries related to supersedence and put them together. Just add in the Task Sequence ID and it should give you a list of any applications that supersede Retired applications.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

Declare @TaskSequenceID char(8); 
set @TaskSequenceID = 'YOURTSID'

SELECT
    CI.CI_ID,
    CI.CI_UniqueID,
    CI.Manufacturer,
    CI.DisplayName,
    CI.SoftwareVersion,
    ARF.ToApplication as RetiredSupersededApp
FROM
    v_TaskSequenceAppReferencesInfo INNER JOIN
    fn_ListLatestApplicationCIs(1033) CI ON CI.CI_ID = v_TaskSequenceAppReferencesInfo.RefAppCI_ID INNER JOIN
    (
        select 
            locpropFromapp.CI_ID as FromAppCI,
            locpropFromapp.DisplayName as FromApp,
            locpropFromDT.DisplayName as FromDeploymentType,
            locpropToapp.DisplayName as ToApplication, 
            locpropToDT.DisplayName as ToDeploymentType 
        from  
            vSMS_AppRelation_Flat as appflat
            JOIN v_LocalizedCIProperties as locpropFromapp ON locpropFromapp.CI_ID = appflat.FromApplicationCIID
            JOIN v_LocalizedCIProperties as locpropFromDT ON locpropFromDT.CI_ID = appflat.FromDeploymentTypeCIID
            JOIN v_LocalizedCIProperties as locpropToapp ON locpropToapp.CI_ID = appflat.ToApplicationCIID
            JOIN v_LocalizedCIProperties as locpropToDT ON locpropToDT.CI_ID = appflat.ToDeploymentTypeCIID
            JOIN v_ConfigurationItems as ciFrom ON locpropFromapp.CI_ID = ciFrom.CI_ID
            JOIN v_ConfigurationItems as ciTo ON locpropToapp.CI_ID = ciTo.CI_ID
        where 
        appflat.RelationType=15
        --AND ciFrom.IsTombstoned = 0
        AND ciFrom.IsLatest = 1
        AND ciFrom.IsExpired = 0
        --AND 
        --ciTo.IsTombstoned = 1
        --AND ciTo.IsLatest = 1
        AND 
        ciTo.IsExpired = 1
        ) ARF ON ARF.FromAppCI = CI.CI_ID
WHERE 
    v_TaskSequenceAppReferencesInfo.PackageID = @TaskSequenceID AND
    CI.ISSuperseding = 1

Once we removed supersedence from the retired applications and the The Task Sequence started working again.

References:
https://www.reddit.com/r/SCCM/comments/5ronkm/content_issue_with_previously_working_task/ http://www.configmgrdistrict.com/2016/04/18/configuration-manager-application-supersedence/