通过

SMSTS.log showing "Failed to download policy {GUIDHERE} (Code 0x80004005)"

  • 项目

Issue:

If you delivery Software Updates with ConfigMgr 2012, you may just run into this error, this error is caused when a Software Update is removed from the ConfigMgr system but a little something got left behind in the Site Database, this little something is problematic references to the policy in the DepPolicyAssignment and PolicyAssignment tables of the site database.

The tell tale signs are booting up during PXE or with Boot Media and just when you think you will get the screen with your task sequences, you receive the error 0x80004005 instead. So you open the trusty CMTrace and look at the smsts.log and find an entry that looks like this:

BOM not found on policy reply TSPxe 2/4/2015 11:09:48 AM 1312 (0x0520)
Failed to download policy {12345678-28EB-40E3-9959-1EFEB0453286} (Code 0x80004005). TSPxe 2/4/2015 11:09:50 AM 1312 (0x0520)
m_pPolicyManager->GetPolicyXML(L"SoftwareUpdateDeployment", sPolicyXML ), HRESULT=80004005 (e:\qfe\nts\sms\client\tasksequence\tsmbootstrap\tsmediawizardcontrol.cpp,1945) TSPxe 2/4/2015 11:09:50 AM 1312

(0x0520)

(Please note the GUID in this error example has been changed to protect its identity, no GUIDs where harmed during the making of this blog)

Resolution:

So what do you do, to get around this issue? Well there are a couple of options, I like to call them option A and option B:

A. Remove Software Updates from the Task Sequence and perform them outside of the image process
B. Remove the offending entry from the SQL DB for the ConfigMgr environment

Option A.
1. Open the Task Sequence in question with the issue
2. Disable the Software Updates Step
3. Apply the change and test the image process

Option B.
1. Open the SQL Server Manager Tool
2. Navigate to the ConfigMgr DB under Databases and select the DB
3. Click New Query and enter the following into the New Query:

select * from PolicyAssignment where PolicyID like '%12345678-28EB-40E3-9959-1EFEB0453286%'

4. Execute the Query (This will return the PADBID Number, example 123456789)
5. Open a New Query and enter the following into the New Query:

Delete from PolicyAssignment where PADBID = 'PADBIDNUMBERHERE'
(Example: Delete from PolicyAssignment where PADBID = '123456789')

6. Execute the Query (This will delete the offending PADBID from the SQL DB)

Possible responses from Query:
A. If no errors, close the SQL Server Manager Tool and test a OSD deployment
B. If you get the following error:

Msg 547, Level 16, State 0, Line 1
The DELETE statement conflicted with the REFERENCE constraint "DepPolicyAssignment_1_FK". The conflict occurred in database "CM_XYZ", table "dbo.DepPolicyAssignment", column 'PADBID'.  
The statement has been terminated

You will need to run the following queries to check for the same policy and PADBID in the table DepPolicy Assignment

1. Open a New Query and enter the following:

select * from DepPolicyAssignment where PolicyID like '%12345678-28EB-40E3-9959-1EFEB0453286%'

2. Execute the Query (This will return the PADBID Number for the DepPolicyAssignment table)
3. Open a New Query and enter the following into the New Query:

select * from DepPolicyAssignment where PADBID = 'PADBIDNUMBERHERE'

4. Execute the Query (This will return the entry for the DepPolicyAssignment Table)
5. Open a New Query and enter the following into the New Query:

delete from DepPolicyAssignment where PADBID = 'PADBIDNUMBERHERE'
delete from PolicyAssignment where PADBID = 'PADBIDNUMBERHERE'

6. Execute the Query (This will delete the offending PADBID from the SQL DB for both tables)

Once you have completed these steps, its time to re-fire up the ConfigMgr OSD deployment process and give it a whirl, you should be ready to image again.

Comments

  • Anonymous
    June 17, 2015
    Great!!!!!!
  • Anonymous
    June 29, 2015
    You just saved me a lot of trouble down the road. I literally tried everything to fix my issue with that error and this article did it for me!
  • Anonymous
    September 28, 2015
    Thank you. Worked perfectly for me.
  • Anonymous
    October 21, 2015
    We just had this occur in our CM2012R2 environment, and this article pointed us straight to the issue. Raised a Premier case to confirm our situation was the same, confirmed, deleted the offending PADBID row and happy once more. Thanks Charles :D
  • Anonymous
    December 16, 2015
    Thanks.. A real life saver.
  • Anonymous
    August 19, 2016
    Thanks very much for posting this. This problem came up for us and your instructions on what to query and delete were exactly what I needed.