Greetings Microsoft engineering team,
This document contains detailed information about issues that end users are experiencing with Convenience rollup update for Windows 7 SP1 and Windows Server 2008 R2 SP1.
These issues are not a result of a misunderstanding or misinterpretation; they're real issues that degrade the experience of the rollup.
Therefore we sincerely hope you take this seriously and urge you to fix these issues as soon as possible.
For simplicity's sake, convenience rollup KB3125574 will be referred to as "the rollup".
The rollup doesn't include the following optional feature packs, but it does contain their updated components (which were previously released as individual hotfixes or updates):
Platform Update KB2670838, Remote Desktop Protocol 8.0/8.1, Windows Management Framework 4.0, Work Folders, DirectAccess Connectivity Assistant 2.0, Active Directory Lightweight Directory Services, Remote Server Administration Tools, Virtual PC, Server Essentials Connector, Active Directory Federation Services, KB2483177 Desktop Experience Decoder Update for Windows Server 2008 R2.
This means that the user needs to install those feature packs first (before rollup) so that the updated components contained in the rollup get installed when it's installed afterwards.
This should eliminate all their individual updates released before the rollup.
The suggestion is:
Add a notice or recommendation to the rollup KB article explaining that those feature packs or platform updates should be installed first.
Important: If you install one of those features after you install the rollup, you must reinstall the rollup. Therefore, we recommend that you install any of those features needed before installing the rollup.
1: SOLVED by KB3181988
After installing the rollup, every SFC integrity scan reports and fixes an error regarding this file:
(en-US differs based on OS language).
The issue occurs because usbhub.sys.mui is referenced and linked in two winsxs components:
In the "Vanilla" Win7 image, both have the same file version: 6.1.7600.16385.
But the rollup only includes the usbport.inf.resources component, and usbhub.sys.mui is updated to version 6.1.7601.23403.
Now, when SFC is run...
First it checks component usb.inf.resources (version 6.1.7600.16385) and it finds the newer file (version 6.1.7601.23403) in \System32\drivers\en-US\, so it replaces it from the winsxs store with (version 6.1.7600.16385).
Second it checks usbport.inf.resources (version 6.1.7601.23403), but now it finds the older file (version 6.1.7600.16385) in \System32\drivers\en-US\, so it replaces it from the winsxs store, this time with version 6.1.7601.23403.
And so on...
With each scan, it performs the same replacement operations.
Here is a snippet of CBS.log:
Release a hotfix that includes the usb.inf.resources component with an updated usbhub.sys.mui file to match rollup version 6.1.7601.23403, or a hotfix that includes both components with a higher version.
Microsoft has solved this issue with KB3181988:
they released an update that includes both components with a higher version:
If the rollup is integrated into an offline image and update KB2603229 is installed on a live running system that was installed from the updated image, KB2603229 will have no effect and won't fix the registry value.
The rollup supersedes the component of KB2603229, which represents a generic command: UpdateWowRegisteredOwner.exe, which must be executed on live running systems.
However, since the rollup version of this component is higher (6.1.7601.23403), it prevents UpdateWowRegisteredOwner.exe from running when KB2603229 is installed because its versions are 6.1.7601.17671/6.1.7601.21795.
Release a refreshed KB2603229 or a new update with a higher component version than 6.1.7601.23403
If you don't, advise users to install KB2603229 first and not to integrate the rollup.
Or, if the rollup is integrated, advise users to execute this command manually through an admin command prompt:
As we have unfortunately found out, the command above does not work if you integrate the rollup into an installation DVD.
After the system is installed, the registry values of:
are no longer “Microsoft”.
For the command to work, you would
need to reset the tow values to “Microsoft” first.
But if the values are to be changed anyway, it makes more sense to use the correct values that can be found in these keys:
If you install the rollup on a live system, the values are correctly set and KB2603229 is not required. Windows Update will still want to install it regardless.
3: SOLVED by KB3185278
If the rollup is installed first on a live running system, two updates do not correctly fix their specified situation:
KB2919469: Canada country code
KB2970228: Russian ruble currency symbol
Only the users of each country are affected
The generic command that is needed to correct the values is defined in the same component manifest for three updates:
The third and newest update is KB3102429: Azerbaijani Manat and Georgian Lari currency symbols
As a result of this manifest replication, the rollup includes only the latest manifest for update KB3102429, leaving out the first two.
Since the rollup version is higher, it prevents the generic command from running when KB2919469 and/or KB2970228 are installed.
Release a new update with a unique component manifest for each country and with a higher component version than 6.1.7601.23403.
If you don't, advise users to install KB2919469 and/or KB2970228 first on live running system, before installing the rollup and not to integrate the rollup into installation image.
Or, if the rollup is installed, advise users to execute the following commands manually through an admin command prompt:
For Canada x64:
%windir%\winsxs\amd64_microsoft-windows-g..decacheclean-canada_31bf3856ad364e35_6.1.7601.23403_none_a77fed0e51881a5d\cleanupintlcache.exe /LocaleName en-CA /updateicountry 2 1 /LocaleName fr-CA /updateicountry 2 1 /LocaleName iu-Latn-CA /updateicountry 2 1 /LocaleName iu-Cans-CA /updateicountry 2 1 /LocaleName moh-CA /updateicountry 2 1
For Canada x86:
%windir%\winsxs\x86_microsoft-windows-g..decacheclean-canada_31bf3856ad364e35_6.1.7601.23403_none_4b61518a992aa927\cleanupintlcache.exe /LocaleName en-CA /updateicountry 2 1 /LocaleName fr-CA /updateicountry 2 1 /LocaleName iu-Latn-CA /updateicountry 2 1 /LocaleName iu-Cans-CA /updateicountry 2 1 /LocaleName moh-CA /updateicountry 2 1
For Russia x64:
%windir%\winsxs\amd64_microsoft-windows-g..decacheclean-canada_31bf3856ad364e35_6.1.7601.23403_none_a77fed0e51881a5d\cleanupintlcache.exe /LocaleName ru-RU /updatesCurrency \u0440. \u20BD /updateiCurrency 1 3 /updateiNegCurr 5 8 /LocaleName tt-RU /updatesCurrency \u0440. \u20BD /LocaleName ba-RU /updatesCurrency \u04bb. \u20BD /LocaleName sah-RU /updatesCurrency \u0441\u002e \u20BD
For Russia x86:
%windir%\winsxs\x86_microsoft-windows-g..decacheclean-canada_31bf3856ad364e35_6.1.7601.23403_none_4b61518a992aa927\cleanupintlcache.exe /LocaleName ru-RU /updatesCurrency \u0440. \u20BD /updateiCurrency 1 3 /updateiNegCurr 5 8 /LocaleName tt-RU /updatesCurrency \u0440. \u20BD /LocaleName ba-RU /updatesCurrency \u04bb. \u20BD /LocaleName sah-RU /updatesCurrency \u0441\u002e \u20BD
If you integrate the rollup into an installation DVD, then the installed system is not affected and KB2919469 and KB2970228 are not needed. Windows Update will still want to install it regardless.
As one additional ‘online‘ solution, all users registered on the system could temporarily change their “region and language”-format to a different value, apply the change, then choose the correct value again and apply it. This fixes the issue also, but all personal format adjustments will be set back to the default values.
Microsoft has solved this issue with KB3185278:
it contains an unique component manifest for each country:
Some updates get removed when running Disk Cleanup (Windows Update Cleanup), but Windows Update still requests these updates and installs them again.
However, running Disk Cleanup will remove them again, and so on...
The list of affected updates varies, but preliminarily, it includes:
KB2446710, KB2478662, KB2846960, KB2871997, KB2992611, KB3031432, KB3033929, KB3140410.
Since the rollup is on the LDR branch, Windows Update requests these updates to get the GDR branch of their components.
But for Disk Cleanup and the servicing stack, those updates are truly superseded by the rollup and other newer updates and thus, can be removed.
The definite fix would be to change updates metadata in Windows Update in order to recognize the installed rollup.
But, since the rollup is still optional and not deployed by WU, you can just advise users to hide these updates in Windows Update.
A workaround to reduce the list of affected updates to two (KB2446710, KB2478662) can be found here.
Even though the link is not directly related to issue 4 the specified solution also partially solves issue 4.
partially solved by KB3177467
Even though KB3020369 is a prerequisite of the rollup, the old servicing stack KB2533522 is still offered by Windows Update. And if a user does not look at the size, he'd be surprised that he has to reinstall Windows 7 SP1 (KB976932).
Maybe because KB2533522 is included as companion with SP1, and Windows Update recognize SP1, but fails to suppress the companion.
Windows Update metadata should be updated to not offer KB2533522 (disguised as SP1) if KB3020369 is installed.
KB3177467 supersedes KB3020369 and works as prerequisite of the rollup.
On x64 systems KB2533522 is no longer offered by Windows Update. Solved!
On x86 systems Windows Updates now offers KB2533522 two times, one entry shows “KB2533522” the other “Windows 7 SP1(KB976932)”, both install KB2533522.
This describes a discrepancy that seems unintended regarding Active Directory Lightweight Directory Services (AD LDS) for Windows 7 (KB975541).
As a side note, the page in the Microsoft Download Center wrongfully lists the package version as 6.1.7600.16494. The actual correct version is 6.1.7600.16521.
If AD LDS (KB975541) was installed after SP1, only ntdsai.dll will be updated by the rollup.
But just the opposite, if AD LDS (KB975541) was installed before SP1, the Service Pack will upgrade the AD LDS version to 6.1.7601.17514. Then all its components will be updated by the rollup, except ntdsai.dll.
And in that case, hotfix KB2922852 is needed to get the latest applicable version of ntdsai.dll.
The rollup's internal packages explicitly state that AD LDS ntdsai.dll component is applicable only for version 6.1.7600.16521, which prevents version 6.1.7601.17514 from getting used to update file.
The intended packages are:
Just the opposite, the rollup internal packages for all other AD LDS components explicitly state that they are applicable only for version 6.1.7601.17514
The best fix would be to release a refreshed AD LDS package separately for Windows 7 SP1, similar to what was done for RSAT.
If that's not possible due to Win7 being out of mainstream support, release a hotfix that includes the same AD LDS components in the rollup with a higher version and it should be applicable for both AD LDS versions 6.1.7600.16521 and 6.1.7601.17514
If not, add AD LDS updates to the list of excluded fixes in the rollup's KB article so that users can manually download and install them.
The current applicable hotfixes for AD LDS (KB975541) are:
KB2462137, KB2539513, KB2589154, KB2647644, KB2898997, KB3012660
The current applicable hotfixes for AD LDS (KB975541) are: (The ntdsai.dll KB-number is underlined)
KB2462137, KB2539513, KB2589154, KB2647644, KB2898997, KB3012660, KB3125574
KB2462137, KB2539513, KB2589154, KB2647644, KB2898997, KB3012660, KB3042816 (AD LDS components of KB3125574 do not apply)*
The current applicable hotfixes for AD LDS (7601) are:
KB2922852, KB3125574 (Windows-DirectoryServices-Core-files.Resources are taken from KB3125574)
KB2922852, KB3125574 (Windows-DirectoryServices-Core-files.Resources are taken from KB2922852 - the resources files of KB3125574 do not apply)*
AD LDS components of KB3125574 do not apply for AD LDS x64 clients.
For clients Microsoft-Windows-DirectoryServices-NTDSAI would be installed by:
This package is defined in package:
But for package_1109 sr-Latn-CS language is a prerequisite. So, as long as sr-Latn-CS is not installed,
package_1053 will not be called and Microsoft-Windows-DirectoryServices-NTDSAI will not be installed.
For clients Windows-DirectoryServices-Core-files.Resources is only defined in:
for servers (package 1567-1586) and x86 clients (package 385-402) there is one package for each language.
But package_384 is for sr-Latn-CS language only, also. So, as long as sr-Latn-CS is not installed,
Windows-DirectoryServices-Core-files.Resources will not apply. Note: if sr-Latn-CS is installed,
the language resource files will be added for en-US.
It looks like someone mistakenly changed “neutral” to “sr-Latn-CS”.
Release a cumulative update for AD LDS.
Build one small hotfix that includes the resolution for the first 3 issues and add it as companion with convenience rollup KB3125574.
Then instruct users specifically not to integrate this update, but to install it directly on live running systems after installing the rollup.
Waiting for an answer:
Abbodii, PointZero, Komm
Our report in the Microsoft block:
First and only reaction from Microsoft:
New Monthly Rollups: (screenshot 1, screenshot 2)