I know this has been asked and answered in January, but I'd like to verify the information still holds true... In our environment we use the Client Deployment Failure Report to regularly check on our automated GPO rollout of the ConfigMgr client as systems are built and joined to the domain. Unfortunately, we have a fair number of machines that get built up for testing (typically VMs) and then are permanently destroyed. I get a lot of client installation failures due to the fact the system was shut down or restarted during the ConfigMgr client install. The GPO deploying ccmsetup.msi does not run again (I assume because it technically succeeded installing the bootstrap), and the test machine lands on this report.Typically these dev VMs are built and destroyed before the failure can be addressed, so they become a permanent fixture on this report. In the following thread Wally confirms what we've seen, that a successful install clears this machine from the report. But if there's never a success, these machines are permanently stuck on this report. Our report is littered with these machines all the way back to our original site installation, which really detracts from the value of the report.http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2740782&SiteID=17Is there a mechanism yet for cleaning this report up? If not, can someone point me toward documentation on how I might request this functionality in a future SP? Or if it makes more sense to funnel this through our TAM, I can do that too.Appreciate your feedback. Thanks.

Won't the built in maintenance tasks clear that?

I don't know of any maintenance task to remove them. They are not associated with a client, so can't delete the client. And I'm not aware of any other automated procedure to remove them. They aren't technically status messages, so don't think our status message deletion tasks affect state messages. If the resource was in the database, and has been removed since these were reported, I'd expect them to be removed with the resource itself (such as Delete Aged Discovery Data). Are you still seeing them in the reports after the resource has been removed? If so, that kind of agrees with what dev said initially, no way to remove them (at least no supported way).

Yes, the report records remain long after the resource has been deleted. It sounds as if the original advice holds true. Thanks for walking through the issue again. I'll just learn to ignore them and ask the audience of that report to do the same.

I'll check again, but I'm sure I filed a DCR back in the TAP for Configuration Manager when we ran into this to have a way to clean them. Last I heard that got postponed :-(

I presume all we need to do is clear out the stale records within the Client Deployment Status Table, can someone confirm?Kevin Evans

Editing the database manually is not supported unless PSS/CSS tells you to do so. It might work but it could also result in database inconsistencies.

Can I request a built in maintenance task to address this issue? Wally you last heard that this was postponed, have you heard anything else on this?If MS don't support direct editing of the database, then it would be useful if the maintenance tasks addressed this automatically for us.Kevin Evans

You can provide feedback using connect.microsoft.com

Submitted feedback as advised, I will keep you guys informed.Kevin Evans

Is there any update on this issue? I assume that this was not included in SP2 since I see no new maintenance tasks that would cover this, but are there any plans to incorporate it in R3?

Hi, i did get a response back from MS via connect.microsoft.com, unfortunately I can't find the post, but basically the jist of this was that the stale records are left there by design. They did post a possible alternative where you create a custom report showing clients that had failures by month, so you could have a report for the last 30 days client deployment failures.I thing I argued that if I wanted the database to store records for x number of days, then this is what it should do. Unfortunately Microsoft didn't it see it this way. I guess it is down to the customers to raise this with Microsoft until they do change their mind.Kevin Evans

Before you start following the procedure, Please make sure that you understand that this is a WORKAROUND and is not supported by the support group. I had the same issue and here’s what I tested in my LAB While I was reproducing the issue; I found that we pull up this information from various views which are already there. Deleting the data from the view is not advisable way of removing the records. Because you might end up deleting the data which you didn’t want to. Being said that I tried reproducing the issue to see, If there are any shortcomings. I have tried looking at various tables and it should not cause any issue. Where this data comes from: When we have the FSP (Fall Back Status)installed. If at that time, if a client is unable to communicate to the Management Point; It’ll send an alert using the FSP which will get recorded in the Database. So, after you troubleshoot the client and it starts communicating to the Management Point; You might observer the data still exist in the report given the fact that client is working properly. Here is what I see in my reports: Computer Name (FQDN) Computer Name (NetBIOS) Client Version Deployment Start Time (UTC) Failure Description Description Parameter CS1SQL CS1SQL 4/28/2011 19:01 Invalid ccmsetup command line: "C:\Windows\ccmsetup\ccmsetup.exe" /runservice FSP=cs1srv So let’s assume that we have decommissioned this box and it doesn’t exist. To remove this server you need to run the following query against your ConfigMgr Database. Before I’ll delete this record using the DELETE statement, I wanted to use the select statement instead to look how many rows I’ll be affecting. Select * FROM [dbo].[ClientDeploymentState] WHERE FQDN='CS1SQL ' and NetBiosName ='CS1SQL' Once you’ll execute this, You’ll get an idea about how many row we are affecting. Then change the select statement to DELETE statement: delete FROM [dbo].[ClientDeploymentState] WHERE FQDN='CS1SQL' and NetBiosName ='CS1SQL' That should delete the entry from the report and try refreshing the report. If we have too many clients, we can then probably use the Last Update Time. However we should not use that. That SQL statement should look like: Delete FROM [dbo].[ClientDeploymentState] WHERE LastIDUpdateTime < '2010-12-31' Hope that helps. Anurag Microsoft Certified Professional| Microsoft Certified Technology Specialist (ConfigMgr) This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.