Here is another interesting issue that I come across recently with the Configuration Manager build version 2002.
I was reviewing the client health dashboard in the monitoring workspace and saw the following status..
As you can see above, the bar chart for the client's overall health, the client policy request is at a very low percentage compared to other scenarios such as client health, software inventory, hardware inventory, etc..
The client policy is something that you can configure in device the client settings (default 60 min) and help the client to download the policies from the Management point.
By clicking on the policy request bar chart, I can see that, there are a large number of client devices with time stamp very old (almost 2 months old).
From the above screenshot, many clients are online and active but the policy request timestamp is OLD.
By looking at the old timestamp, the first thing that came in mind is, clients might be having issues with downloading the policies which will cause the deployment issues.
I picked one of the online clients with an old timestamp and looked at the client logs such as policyagent.log and other deployment logs such as appenforce.log,wuahandler.log, updatesdeployment.log, etc.
These logs can help us to identify if the client is able to download the policies and install the deployments if any.
On the client that I picked, it has installed applications very recently and also monthly software update patches which is a good thing.
So now, there are no issues with deployments and also the client policy download but why is policy request timestamp not getting updated?
A couple of things verified before applying the NASTY workaround.
1. Verified the MP logs such as MP_Getpolicy.log, MP_policy on the MP server, IIS logs. All looks good.
2. Verified that, inbox folder polreq.box has huge backlogs that are failed to process (E:\Program Files\Microsoft Configuration Manager\inboxes\polreq.box). This inbox folder keeps increasing. I could not able to find anything in the logs that refers to this action.
3. Verified the antivirus exclusions for configuration manager are configured correctly.
4. Restarted the SMS executive services for a fix but could not get through.
The solution (NOT RECOMENDED IN PRODUCTION ENVIRONMENT UNLESS YOU KNOW WHAT YOU ARE DOING)
When there are a large number of clients that are having old timestamp, i started digging into the database as well and found a SQL table called v_CH_PendingPolicyRequests.
This SQL Table list the information about policy request including the GUID of the request.
Run the following syntax on your SQL management studio:
select * from v_CH_PendingPolicyRequests
As you can see above, a large number of clients with an old timestamp, GUID, and also its Management point.
DISCLAIMER: Please take a back up of your ConfigMgr SQL database before performing this step. Once the changes are made, they cannot be UNDO.
we will remove all the pending records from this table v_CH_PendingPolicyRequests and monitor the client policy request again.
On your SQL management studio, perform the following syntax.
TRUNCATE TABLE v_CH_PendingPolicyRequests
Now run the SQL Query to verify if there are any more results or not?
select * from v_CH_PendingPolicyRequests
Confirm that, there are no records in it.
Now delete the backlog files inside the inbox folder polreq.box
Now we will monitor the client policy requests from the clients and this time, all the clients have updated their timestamp correctly in the console and also in the client health dashboard.
Is there any other fix without truncating the records in the SQL table? No, i don’t have at this point.
I hope you find this useful!