Reading through the MP_GetPolicy.log and seeing errors about policy IDs not found.  Unfortunately the GUID isn't really all that helpful, contrary to what the developers think.  I've looked in some of the more obvious places in the database to try and translate it to something useful, but so far no luck.  The Policy table has an entry, but the part I need looks to be a blob.

The message is

MP IP:Policy ID={GUID} Version=26.00 not found.

It's hard to troubleshoot the problem when you don't know what the problem is. It wouldn't kill them to give us a reference to what it was trying to do would it?

Try using PolicySpy from the ConfigMgr Toolkit:

http://www.microsoft.com/en-us/download/details.aspx?id=36213

 

It makes troubleshooting policy issues much more simple.

 

I hope that helps,

 

Nash

Yeah, that was the first thing I tried.  Problem is finding the GUIDs isn't practical.  The log doesn't tell which computer is requesting it, and Policy Spy doesn't really have a way to search for a Policy ID.

Is there actually a symptom beyond the errors in that log?

Nope, just the can't find the policy, I'd like to figure out which policy so I can see if there's something wrong.  But right now I don't even know where to look.  I'll probably turn up the verbosity on the logs and see if it says anything more, but I have my doubts it will.

It could be that the client does a policy request for an older version of the policy (which is no longer available), but then downloads the current version successfully.

That's an interesting idea, and you very well may be right.  I just wish I could figure out what the policies are, there's errors spread over all the policy logs, and they are even more useless than this one for figuring out what the problem is. 

With verbose logging on it gets a bit more interesting.  Now the question is this an issue with annonoymous user or or is it something with the policy.  Looking at the logs it isn't just one computer, but I do see a lot of requests for this particular policy with the failure.  So again the question becomes what is this policy request. 

Policy body request from xxx.xxx.xxx.xxx using Anonymous auth as Anonymous user MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
Encountered validation failure 87D00239 for Unknown client for policy body download. MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
MP GP: Query String Before Decode : %7Bb663ba07-f3ff-4d96-b019-6e2712aa23f0%7D.116_00 MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
MP GP: Query String  After Decode : {b663ba07-f3ff-4d96-b019-6e2712aa23f0}.116_00 MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
MP GP: ID       : {b663ba07-f3ff-4d96-b019-6e2712aa23f0} MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
MP GP: Version  : 116.00 MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
MP GP: Compression : <none> MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
MP GP: Initializing anonymous request. MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
MP GP: GetPolicySendResponseHeaders: Sending response 200 OK MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
MP GP: GetPolicyDoneWithSession: ServerSupportFunction() returned 0x0 MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)
MP GP: HttpExtensionProc:GetPolicyProcessRequest() returned 1 MP_GetPolicy_ISAPI 5/30/2013 8:26:19 AM 7752 (0x1E48)

did you ever get anywhere with this?

I found the cause of the problem here at a customer which resulted in no Task Sequences being unable to run (800040005) on content location. 

I sifted through the database tables looking for and I found the related PolicyID in the dbo.DepPolicyAssignment table, which gave me a lastmodified date/time (this morning) and I then referenced this against the Audit logs to discover that a Software Update Group deploymemt was created but then deleted seconds later by the same user.

The speed at which the create/delete was done seems to have upset the SCCM policy processing mechanism and has resulted in some sort of inconsistency in the database for that policy and it's stuck.

I have been able to remove the row (after copying the data) for this 'stuck' PolicyID from the dbo.Policy, dbo.DepPolicyAssignment and dbo.PolicyAssignment tables and this has resulted in being able to resume our Task Sequence Activities, however the MP_GetPolicy.log is still churning over stating it cannot find the policy.  I'm wondering if there is an inbox file somewhere that needs to go.

Would appreciate any MVP or MSFT techie advice?

There are many moving parts involved here and it's impossible to tell details without sitting in front of the system.

I understand completely, I find myself in the very same situation when customers ask me questions like this - however I find myself in front of the very system but it isn't particularly intuitive as to which cog in the clockwork is causing this.

For all intents and purposes, whatever was created in the console and deleted is no longer in the console - so I have no visibility of 'what' exactly it was - and disappointingly the Audit Status Messages give no friendly names, only PolicyID.  On a related note, the Audit logs really should be more in-depth as to what user modified exactly which object and name - not just 'user modified a collection' - that's not helpful - we'd like to know the collectionid at the very least!

The database tables that I have found so far which contained the offending PolicyID have had that row removed and this has allowed the Task Sequence Engine to continue normally - but I'd really like to ease the load on the management point not being able to locate whatever once was.  I have re-installed the MP and it just continues where it left off.

I guess ultimately a call may be needed to Microsoft, it's nothing the customer has done 'wrong' aside from maybe create/delete an object too quickly (if that's even a wrongdoing!) and SCCM has thrown it's toy out of the pram.

We finally gave up trying to find the source of the events.  We just instituted a policy of do a quick scan of the errors and if it's something that looks like it has enough information to troubleshoot, then do so.  Otherwise ignore it.  As a result the status views in the console always have red and yellow levels.

Troubleshooting SMS/SCCM has always been painful, with 2012 it's reached new levels of difficulty because it seems all the application stuff references one of several GUIDs.  I've been sitting down with my customers and having a heart to heart talk about applications vs. packages.  The short of it is, packages work a lot more reliably but have less features.  Applications have more features, are a lot more work to setup, and have a lot more problems.  Now which one do you want to use? 

same situation here

Clients having task sequence installation issues, this is all the logs spit out

MP IP: Document ID=ScopeId_2067D847-40C7-4547-949A-75B7A0A0B9CE/RequiredApplication_96abdbd1-57d5-4482-b344-b6815c7f3dc0/15/MANIFEST, Version=B02E107EF35E87C42DE7E93DE50D02B8ED4A8B804D47CF55D7B61C7411F165FC not found
Failed to retrieve package body(0x80070057).
Failed to process request
Failed to process request(0x80004005).

not helpful at all, no idea how to troubleshoot. Frustration with this product grows with each release, service pack, and CU.