Blog Post

SCCM – Software Failing with no explanations or misleading error messages

D Walsham • Jan 29, 2020

Issue

When trying to install software with SCCM you might find some very interesting error messages which might not make a lot of sense and also experience applications which fail almost immediately whether they are deployed as available or required deployments.

One error message in which you may come across is one which says “ A Prerequisite for an install could not be satisfied”

The error message for this code shows as 0x80073CFD (-2147009283)

These can be found either in your Monitoring – Deployment and deployment summary

Also looking through your client logs specifically the AppEnforce.log you will also see the same error code referenced for the problematic app.

Reason

As the error message describes it appears like it has an issue with trying to resolve the dependency within an application, although the bigger at hand is that you may find the dependency is actually already installed, evidence of this can be seen within the client log called AppDiscovery.log

You may find this error perhaps more common with APPX packages. Just as an example we can see the details for a deployment type dependency

But just to exhaust all avenues there are also the requirements which are set for a deployment type which the error message could also be in reference to but this is also satisfied as well.

Solution

The way to fix this is to examine the current Windows 10 build version which you are using. If you are running a build from Windows 10 1607 or lower, you may find these errors amongst multiple other applications which may fail due to this.

Windows 10 1709 is more stable from most of these errors but going forward it will be down to ensuring your Windows 10 builds are on the latest version to avoid any errors such as these.

Additional Information - SQL Query for Windows 10 Versions

Though you have a view within the SCCM console to see the amount of devices you have which are Windows 10 and which build versions they are, here is a SQL query which can be used as well as placed into a custom report via Report Builder or using PowerBI which gets all Windows 10 devices and build versions and also contains an additional condition to which you can specify the collection name if you have a specific deployment going to a specific collection

select vSMS_R_System.Name0 AS MachineName,

vsms_r_system.AD_site_Name0 As ADSite,

v_CH_ClientSummary.LastPolicyRequest,

v_CH_ClientSummary.LastHW,

v_CH_ClientSummary.LastSW,

v_CH_ClientSummary.LastActiveTime,

v_CH_ClientSummary.ClientStateDescription,

v_GS_OPERATING_SYSTEM.Caption0 As OperatingSystem,

REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(v_GS_OPERATING_SYSTEM.BuildNumber0,'17134','1803'),'15063','1703'),'16299','1709'),'17763','1809'),'10240','1507'),'18362','1903'),'14393','1607'),'10586','1511') as BuildNumber,

vsms_r_system.Client_Version0 As ClientVersion,

v_GS_COMPUTER_SYSTEM.Manufacturer0 As Manufacturer,

v_GS_COMPUTER_SYSTEM.Model0 As Model,

vSMS_R_System.User_Name0 As UserName,

v_r_user.Full_User_Name0 As FullName,

v_r_user.User_Principal_Name0 As Email,

collections.CollectionName

from vSMS_R_System

LEFT OUTER join CollectionMembers

ON vSMS_R_System.Name0 = CollectionMembers.Name

LEFT OUTER join collections

ON CollectionMembers.SiteID = Collections.SiteID

LEFT OUTER JOIN v_GS_OPERATING_SYSTEM

ON vsms_r_system.ItemKey = v_GS_OPERATING_SYSTEM.ResourceID

LEFT OUTER JOIN v_GS_COMPUTER_SYSTEM

ON vSMS_R_System.ItemKey = v_GS_COMPUTER_SYSTEM.ResourceID

LEFT OUTER JOIN v_CH_ClientSummary

ON vSMS_R_System.ItemKey = v_CH_ClientSummary.ResourceID

LEFT OUTER JOIN v_R_User

ON vSMS_R_System.User_Name0 = v_R_User.User_Name0

Where Client0 = '1' and v_gs_Operating_system.Caption0 LIKE 'Microsoft Windows 10%' AND Collections.CollectionName = '<Enter Collection Name>'


by D Walsham 13 Dec, 2021
Looking through the current SQL Server topology and how it affects our decision
by D Walsham 07 Oct, 2021
Introduction
by D Walsham 06 Oct, 2021
Introduction
by D Walsham 12 Aug, 2021
All the parts of the series we went into great detail about how we analyse an end to end solution and how we would design a solution in which would allow us to build endpoints without SCCM being a dependency. Whilst we did this, there is another scenario which we have not touched on yet, which is the hybrid scenarios. In a perfect world ideally you would have your Azure Active Directory within the cloud, every machine meets the recommended requirements for Windows 10, everything is imported into Intune/Autopilot and everyone is happy. But we know this isn't realistic in all cases. Many organisations cannot just simply up and go from on-premise into the cloud therefore the checkpoint here is of course getting into hybrid solutions such as; Co-Management Between Intune and SCCM Hybrid AD with Azure AD and On-Premise AD syncing together These things can play a very interesting part in how you would tackle this if you envisage the next step in the blueprint is to be in a position in which you can build and manage endpoints soley within Intune. With this final part of the series we will go in-depth in how the common hybrid setups look like and how we go about moving into the next step of being able to manage and build devices without SCCM.
by D Walsham 29 Jul, 2021
In continuation from the previous part where we had discussed how we create the "on site" piece of the solution, this was the part which would allow us to get our endpoints into a state in which they would essentially be ready to go through the Autopilot process. Which leaves our next piece of the puzzle, to begin the configuration of the actual backend side that resides within our Endpoint Management console. And you will see how everything ties up together to satisfy the full end to end process of getting an unknown (or known) device to proceed thorough the whole workflow to be finally managed by Intune without the aid of SCCM taking part in any of the prerequisites or preparation at hand.
by D Walsham 15 Jul, 2021
In this part we are now going to look into the technical step by step points on how we put everything together. In the previous part we spoke about the structure of how we would asses whether a machine was actually ready to be built with Autopilot or not with a build checklist process which would step through all areas which would cover an endpoints eligibility. Now with everything planned out we finally want to step into making things reality by putting everything together.
by D Walsham 02 Jul, 2021
When it comes to managing your endpoints in endpoint manager, one of the things you may be looking to do is to get all of your Intune registered machines to also be enrolled as Autopilot devices. Now we can of course just have the deployment profile deployed to all machines and then hit the "Convert targeted machines to autopilot" but this might not necessarily be feasible for every client. We may want to perform some due diligence first so we can at least understand what devices in Intune are not in Autopilot.
Show More
Share by: