Known issues / limitations
This page documents some known issues and limitations with this solution. Please be aware of these before you implement it.
Language
Some parts of the report work best where the OS display language is English, ie pages that report on update status from the Windows event log. Where the OS display language differs from English, the names of some updates as well as the installation states can be localized. To handle these language differences properly, some minor code updates are needed.
I have included the ability to handle the German and Italian languages in the report, and other languages can be added by following the instructions here.
Azure service limits
Both Power BI and the Azure automation runbooks use the Log Analytics query API, and the runbooks and the client-side script also use the data collector API. Use of these Microsoft APIs is subject to their service limits, which are documented here.
For very large environments it may be possible to hit these service limits which could result in missing data in the report. As a reference though, an environment of ~9000 reporting devices with clients sending SU data at least twice a day, and a 4-hour summarization schedule, everything is well within these service limits.
New Windows releases
When new feature updates are released for Windows, the Windows Upgrade Readiness page in the report will need updating with the new release to provide compatibility data for that release. Check the change log for this solution for when an updated Power BI report template is available containing the new release.
Incorrect installation statuses
Some of the report pages (ie from Updates Installation Summary and on) make use of update installation data reported in the Windows event log. In some instances, updates may have been installed manually instead of using Windows Update, in which case the current installation status may not be reported to the event log. Some feature update installations may be wrongly reported as a failure because the last event logged for the update indicated a failure, but the feature update has since been successfully installed without this being reported to the event log. An example is the error code 0x80242016, which translates to The state of the update after its post-reboot operation has completed is unexpected. In many cases that I have observed, the feature update did install successfully in spite of this being the last reported status in the event log.
Data blips
I have observed occasional data 'blips', ie one or two time points here and there that didn't report the full amount of data. This will be visible in the trend charts - the screenshot below is a good example of this.
I have been unable to conclusively determine the cause of this, but since the Azure automation runbooks are reporting the full data set, it is likely an issue with the backend Microsoft service that ingests data posted to the data collector API.
The good news is that, if this happens, you can purge those timepoints from the log analytics tables following my instructions here.
The table you need to purge will depend on which trend chart the data blip occurs in:
Trend - Latest Security CU
SU_CUComplianceTrendLatest_CL
Trend - Recent CUs
SU_CUComplianceTrendExtended_CL
Trend - Feature Updates
SU_FUComplianceTrend_CL
Use the PostedTime_t column for the column parameter. Using the example above, I would provide these exact parameters to purge that single anomalous timepoint from the chart in the Trend - Recent CUs report page:
Last updated
