Last updated on December 29th, 2023 at 12:53 pm
The other day I was asked how does ConfigMgr product lifecycle details get updated? You know the details from the Product Lifecycle dashboard in the console. I have to admit that I don’t know that off the top of my head. But I knew that I saw it within the logs. I agreed to track it down as it was not something that I could find it 5 minutes. Plus, we had other things to address during our call. So, this will show you how to confirm that your Configuration Manager (ConfigMgr) Product Lifecycle are being downloaded from Microsoft.
ConfigMgr Product Lifecycle
BTW, ConfigMgr Product Lifecycle set is one of my favorite report sets within ConfigMgr.
One of the custom dashboards sets that I leverage uses the ConfigMgr SQL views to give a different layout that the console dashboard. So, they are seeing different results from the query then I’m seeing. To help them I agreed to track down how the data is imported in ConfigMgr database. Now it turns out that I’m mostly right. The report set that I’m thing about does not in fact use the ConfigMgr Product Lifecycle XML, but instead it used the WindowsServicingStates.xml, which is part of the exact same process. So let find it within the logs.
Working backward I can see within hman.log that the WindowsServicingStates.xml is extracted from ConfigMgr.AdminUIContent.AUC. As shown by the pink highlighted line. Then ~20 lines later we can see the SQL stored procedure for Lifecycle getting to execute and importing the XML into ConfigMgr database. I can only assume it is round this point that it is importing the XML to ConfigMgr as I didn’t find any useful log lines. Look at the date and time, it was within the last 24 hours that this process happened. Looking higher in the logs, I’m not seeing the download process happening at all for ConfigMgr.AdminUIContent.AUC. Time to dig deeper.
It didn’t take that much longer to determine that Dmpdownloader.log was the log file that shows ConfigMgr.AdminUIContent.AUC being downloaded. Once the log was loaded into CMtrace, I search from the bottom of the file. We can see that the payload will be saved as ConfigMgr.AdminUIContent.AUC (orange line). All of this is to say this is downloaded by ConfigMgr during it normal tasks when it checks for updates.
Great we have track down what updates the ConfigMgr data for the v_WindowsServicingStates SQL view, which is used within the query for the custom dashboard. Now they can review their environment to determine why they are not seeing the same results are me.
I thought as I write this article, I should at least include a simple query leveraging this SQL view. So here is one that will Give you a list of your device and support statement.
R.Netbios_Name0 as 'Device',
OS.Caption0 as 'OS',
WHEN '1' THEN 'Release Ready'
WHEN '2' THEN 'Supported'
WHEN '3' THEN 'Expires Soon'
WHEN '4' THEN 'End of Support'
End as 'State',
isnull(WSLN.Value,'n/a') As 'Short Name'
dbo.v_R_System as R
join dbo.v_GS_OPERATING_SYSTEM as OS on R.ResourceID = OS.ResourceID
left outer join dbo.v_WindowsServicingStates WSS on R.OSBranch01 = WSS.Branch and R.Build01 = WSS.Build
left outer join dbo.fn_GetWindowsServicingLocalizedNames() WSLN on WSLN.Name = WSS.Name
How Does ConfigMgr Product Lifecycle get Updated? Video
Below it the associated video for this blog, it will show the step I took along with some extra details.