Ran into a challenge yesterday that found me chasing apparitions into the SCCM DB and in the process, discovering some interesting insights into the fatal, Failed to download policy (Code 0x80004005) Task Sequence (TS) error. Besides being interesting as Hell, we also found a “clean” resolution that was not available through countless Goog searches.  As if all that was not enough, there is a quick lesson on using a SQL Search tool that I was completely unfamiliar with until good friend, Adam Gross (follow this cat on the Twit: @AdamGrossTX), hipped me to what all the cool kids were doing!  Read On My Friends!

*Keep in mind that this is NOT the only cause for the “Failed to download policy (Code 0x80004005)“ error in a TS and certainly NOT  for “Requirements Not Met” ~ “Program Rejected (wrong platform)” in your ConfigMgr Deployment Status.  What this hopefully provides are insights and options on how you can dig down and discover what the root cause is in your unique case. 

THE CHALLENGE:

The challenges all began at a remote location, so we did not have the luxury of having physical access to the device.  We first recognized a challenge existed while reviewing the device progress in our PXE TS Deployment Status.  It was not located in the “In Progress” or “Error” tabs and ultimately found it in the “Requirements Not Met” tab.  The only real lead this would be providing was that we had a challenge, as “Program rejected (wrong platform)” had nothing to do with what was causing the TS to fail.

TROUBLESHOOTING:

We spoke w/ the user and learned that the device had actually PXE booted successfully.  It had reached the point of at least verifying the TS content’s availability before it suddenly rebooted, returning to the Win7 logon screen.  We worked with the user and obtained the smsts.log while in WinPE and this allowed us to see that the TS was failing to download a specific policy which caused the TS to fail and reboot: Failed to download policy {0EE5B482-390A-48DD-BB47-D5706BAB6459}/9 (Code 0x80004005).

I started researching and came upon several blog posts relating to the same or similar challenges, yet the resolutions failed to isolate the root cause and simply provided “workarounds” which included deleting the policy causing the TS failure . . . DIRECTLY FROM MULTIPLE SQL TABLES!!  Say Whhhaaatt? 😱 Although this may resolve the challenge, deleting records directly from a client’s production ConfigMgr DB was NOT an option.

I started querying SQL for the PolicyID causing the challenges and located the offending policy.  Some time was spent trying to find an intersection point that would reveal what this policy was related to, as it was not an application, package or software update.

I reached out to my good friend Adam Gross (@AdamGrossTX), who just happened to be returning from lunch and had some time to kill.  We chatted for a while, bounced ideas back and forth and then Adam found our “intersection”!!  Using APEX SQL’s Text and Object Search tool in his own lab, he narrowed it down to being a Client Setting. *For insight on this tool and usage, see How Did He Do That at the tail end of this blog post!!  With the culprit narrowed down to a client setting, we then queried against ClientSettingsAssignments using the PolicyID and Bam!!  Now we had the ClientSettingsID as 16777217.

A quick look in the ConfigMgr console revealed the offending Custom Client Device Setting as the Default Workstation Settings and the Date Modified further validated this, since the PXE TS had worked perfectly before July 4th break.

RESOLUTION:

There were several tests conducted to determine what the correct solution should be and, in the end, deleting then recreating the Default Workstation Settings deployment to the All Windows Workstation collection was the correct choice.  This ensured that whatever the corruption was within the client settings deployment, be it WMI or SQL DB, would be completely cleared and would not cause any additional challenges moving forward.

Confirming this truly was the resolution, a device was re-imaged successfully and without challenges: 🤙🤙

🤓GEEK BONUS!!

One additional piece of insight that we found extremely interesting and most likely, very useful in the future:

In the SCCM DB, Custom Client Settings are not only stored as a UniqueID or PolicyID.  The “slash number” after a Policy/ID is used to distinguish each separate Client Setting Node (not versioning as we previously assumed):

For Example:

PolicyID: {xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}/9

Is the Software Updates settings Node:

Pretty damn cool IMO! 🤙

 

How Did He Do That? …a foray into how AGross guy found SQL Salvation for a few!!!

When Marc pinged me I was hoping he was going to ask me to go catch some waves or bomb some hills on longboards, but no, he wanted help with client issues 😥.  He’s such a nice dood, plus we are both Louisiana natives, so I couldn’t pass up a chance to help with some sweet detective work with him.

As Marc mentioned, we used the totally free tool Apex SQL Search to find the offending policy. Microsoft MVP Steven Hosking (@OnPremCloudGuy) recommended it to me several months ago and I’ve used it several times to quickly find things in the SCCM DB. In a recent blog post, I mentioned using the View Dependencies function in SQL Server Management Studio (SSMS) to find the SQL objects that related to or depend on other SQL objects, but it only finds objects. Apex SQL Search lets you search for objects AND do full text searching of your entire DB and it does it rather quickly. It’s also worth noting that the View Dependencies option function didn’t return the correct table for us, so we may have been looking for a while.

In our case, we had already found the policy we were after, but we were having trouble finding the magic table that we needed. After blindly trying a few tables with “policy” in the name, I decided to use Apex SQL Search to search for all instances of the policy text in the db. Within a few minutes, I found the policy in several tables, one of them ended up being ClientSettingsAssignments. I sent the table over to Marc and he immediately confirmed that it contained the missing piece needed to solve the puzzle. Here’s an example of how we used it.

When you install Apex SQL Search, it will add a new menu item to SSMS.

The menu allows you to search for objects or text. For our issue, we used Text Search.

This will open a new SSMS tab where you can enter the search text and configure several options. If I know I’m searching for a numeric value, then I will only check the Numeric columns and Unique identifier columns for my first pass to help speed up the search. If I strike out, then I may check additional options and try again. In this case, I only selected Text and Unique columns.

As you can see in the search results, we got back 5 tables that have the search text. From here its just a bit of trial and error to find out which table/view is what we need. Fortunately, the first table was it, so we didn’t have to search very far.

In my lab, I was able to use these 3 tables to track down the name of the Client Settings policy that was deployed.

SELECT * FROM PolicyAssignment WHERE PolicyID Like ‘%{2B964D39-CA3B-4A72-9654-B5FCD0B3A5CE}%’
SELECT * FROM ClientSettingsAssignments WHERE UniqueID = ‘{2B964D39-CA3B-4A72-9654-B5FCD0B3A5CE}’
SELECT * FROM ClientSettings WHERE ID = 16777217

So that’s it! As you can see, the Apex SQL Search tool is super powerful and useful. I highly recommend adding it to any DB where you use SSMS. Also, this is a completely unpaid, unsolicited review of the Apex SQL Search tool – we just REALLY love it and REALLY think you should try it out. Apex apparently has other free and paid products that I haven’t even looked at yet. Go check them out!!

Thanks again for bringing me in on this one Marc and for asking me to co-blog with you! <== How cool is this guy?? 🤙