This content has been marked as final. Show 6 replies
Update: After looking at the file version tables in MSWU-419 article, this appears to be a GDR/LDR issue.
Thank you for the details. Our data team is currently researching this issue.
We experience the same problem with the same patch and the same circumstances as listed in the first post.
It appears your patching system is not functioning correctly.
What does, "this appears to be a GDR/LDR issue.", mean?
When will vmWare (Shavlik) be providing corrective fixes to Protect Essentials Plus support subscribers???
Some of Microsoft's patches have 2 versions, GDR and LDR, as defined by:
"GDR service branches contain only those fixes that are widely released to address widespread, critical issues. LDR service branches contain hotfixes in addition to widely released fixes."
Most of the time you will have the GDR version installed. The LDR file version number is higher than the GDR file version number. Many times, the last set of numbers in the GDR file version will be something like 17xxx and the LDR file version will be something like 21xxx. As an example, say a patch sets the last part of the GDR file version to 17132 and the LDR file version to 21132. You install the patch on your machine which is on the GDR branch, so your machine now has a file version ending in 17132. Then, Microsoft releases and you install a newer patch that increases the last part of the GDR file version to 17488 and the LDR file version to 21488. If VMWare doesn't adjust their detection logic, the older patch detection will see that 17488 > 17132 and assume that your system is using the LDR branch. Then, it checks and sees that 17488 < 21132, so it flags the older patch is missing. I'm not sure why VMWare doesn't automatically use a check like "is the version > expected GDR and < expected LDR" for each patch to start with, but apparently they don't, because it seems like there is at least one patch every month or two that has this detection problem until they adust their logic. I've been complaining about this for over a year, and it still happens fairly regularly.
By the way, the newest XML, version 22.214.171.1240, has fixed this issue for MSWU-419 / Q982584.
I'm sorry, in my longer post (the first one today), instead of:
I'm not sure why VMWare doesn't automatically use a check like "is the version > expected GDR and < expected LDR" for each patch to start with...
I should have said:
I'm not sure why VMWare doesn't automatically use a check like "is the version > expected GDR and < LDR base number" (in my example that would be > 17132 and < 21000) for each patch to start with...