Updates taking a long time to install in Windows Server 2008 R2

Today I would like to discuss one of the issues that you face while installing updates in Windows Server 2008 R2.  When you install an update, it may hang for a very long period of time without any progress showing.  If you open Event Viewer and look in the Setup Event log, you will get the entries as shown below (in the below example hotfix KB2545850 is facing the issue):

2/2/2016 10:29:17 AM Information server.contoso.com 1 Microsoft-Windows-Servicing N/A NT AUTHORITY\SYSTEM Initiating changes for package KB2545850. Current state is Absent. Target state is Installed. Client id: WindowsUpdateAgent.

2/2/2016 1:51:06 PM Error server.contoso.com 3 Microsoft-Windows-WUSA N/A Contoso\User Windows update ‘Hotfix for Windows (KB2545850)’ could not be installed because of error 2149842953 ” (Command line: ”C:\Windows\system32\wusa.exe’ ‘D:\temp\Windows6.1-KB2545850-x64.msu’ ‘)

2/2/2016 2:02:08 PM Information server.contoso.com 1 Microsoft-Windows-Servicing N/A NT AUTHORITY\SYSTEM Initiating changes for package KB2545850. Current state is Staged. Target state is Installed. Client id: WindowsUpdateAgent.

In these situations, checking the CBS.log (located in c:\windows\logs\cbs) can be really helpful as it captures all the details regarding update installation failures.

If you look in the CBS log you will see the entries as follows:

2016-02-02 10:29:19, Info                  CBS    WatchList: Add package Package_57_for_KB2868725~31bf3856ad364e35~amd64~~6.1.1.1.2868725-165_neutral_LDR to re-evaluation(install) due to the change on Component Family: amd64_microsoft-windows-lsa_31bf3856ad364e35_0.0.0.0_none_26431bf35d52e5a2, Version: 6.1.7601.21728, change: (Owner: Package_5_for_KB2545850~31bf3856ad364e35~amd64~~6.1.1.0.2545850-5_neutral_LDR, Flag: 5, Action: 3)

2016-02-02 10:29:19, Info                  CBS    WatchList: Add package Package_33_for_KB2871997~31bf3856ad364e35~amd64~~6.1.2.5.Trigger_1 to re-evaluation(Always) due to the change on Component Family: amd64_microsoft-windows-lsa_31bf3856ad364e35_0.0.0.0_none_26431bf35d52e5a2, Version: 6.1.7601.21728, change: (Owner: Package_5_for_KB2545850~31bf3856ad364e35~amd64~~6.1.1.0.2545850-5_neutral_LDR, Flag: 5, Action: 3)

2016-02-02 10:29:19, Info                  CBS    WatchList: Add package Package_120_for_KB3121212~31bf3856ad364e35~amd64~~6.1.1.2.Trigger_1 to re-evaluation(Always) due to the change on Component Family: wow64_microsoft-windows-lsa_31bf3856ad364e35_0.0.0.0_none_3097c64591b3a79d, Version: 6.1.7601.21728, change: (Owner: Package_5_for_KB2545850~31bf3856ad364e35~amd64~~6.1.1.0.2545850-5_neutral_LDR, Flag: 5, Action: 3)

2016-02-02 10:29:19, Info                  CBS    WatchList: Add package Package_121_for_KB3121212~31bf3856ad364e35~amd64~~6.1.1.2.Trigger_1 to re-evaluation(Always) due to the change on Component Family: wow64_microsoft-windows-lsa_31bf3856ad364e35_0.0.0.0_none_3097c64591b3a79d, Version: 6.1.7601.21728, change: (Owner: Package_5_for_KB2545850~31bf3856ad364e35~amd64~~6.1.1.0.2545850-5_neutral_LDR, Flag: 5, Action: 3)

Why does this happen?

When you check the file version on the machine, it is currently using the GDR (General Distribution Release) branch and the date stamp is marked as 12/30/2015. (latest date)

clip_image002

When you check the file version in KB2545850, it is an LDR (Limited Distribution Release) branch hot-fix that has the date stamp of 03/14/2011 (older date).

image

When we try to update a binary that is using the GDR branch of the hot-fix with the LDR version of the hot-fix, we cannot compare the version numbers to see if the file needs to be updated.  At this point we have to compare the dates of the files.  In this situation, the date of the file in the hot-fix we are trying to install from KB2545850 is older than the binary that is already on the machine.  This triggers a re-evaluation during the applicability checks and takes more time.  When we have to compare the dates on a lot of binaries like the example above, it causes the process of installing to take longer.

This behavior can be expected in Windows Server 2008 R2.

We will have to wait for hours or days for the installation to complete.  So, how do we speed up the servicing mechanism?

The following workaround can help in speeding up the operation. The below steps may vary for each KB. These steps are proposed based on the behavior noticed in each scenario.

Workaround steps

  • Cancel the update when it is stuck and reinitiate it right away and check. At times reevaluation might be cached which would complete the installation of the updates.
  • Check if the update/hotfix is superseded by checking in the Microsoft Update Catalog site: http://catalog.update.microsoft.com . Since the superseded update will have all the binaries with latest date stamp, it is least likely to trigger re-evaluation.
  • To speed up the installation we can also install the hotfix/update manually using DISM and check if that helps:

1. Download problematic update from Microsoft Download Center and place it to any folder i.e. C:\Temp
2. Run cmd.exe with elevated privileges (right click on cmd.exe and choose “run as administrator”)
3. Unpack the update by using an administrative command prompt and running the following commands:

  • expand -f:*{update name}.msu {destination folder}
    • Example: To unpack update Windows6.1-kb2545850-v2.msu which is stored in C:\Temp folder the command will be following:
    • expand -f:* C:\TEMP\Windows6.1-kb254580-v2.msu  C:\TEMP
    • This should result in a .cab file in the C:\Temp directory

4. Now from the elevated command prompt, run the following command:

Dism.exe /Online /Add-Package /PackagePath:c:\temp\Windows6.1- kb2545850-v2.cab

More Information on Re-evaluation:

Re-evaluation of the applicability rules vary from machine after machine and this cannot be predicted as the applicability and installation phases are working properly.

Below are some of the Applicability Evaluation Scenarios.

1. Package being installed by CBS:
Updates could be installed, possibly triggering other updates to change state, or they could be staged, waiting for their applicability to be satisfied, or they could be absent with no presence on the system.

2. Package being uninstalled by CBS:
Components being removed can cause applicability rules targeting them to change state, triggering additional servicing operations. Child packages could be triggered to be removed when their applicable parent package is uninstalled.

3. Update being installed by CBS, or selectable feature selected on:
Other updates may be triggered for installation

4. Update being uninstalled by CBS, or selectable feature selected off:
Other updates may be triggered for uninstallation.

5. Normal component being upgraded (on existing branch):
Reevaluation based on the component version change may uninstall an older version.

6. New component being installed:
Other updates may be triggered for installation.

7. Branch-forcing component being installed:
Reevaluation based on component version change may trigger patches for elevated branch.

8. Normal component being removed:
Reevaluation based on component version removal may install an older version.

9. Branch forcing component being removed (determined by mapping back to update):
If another component forcing the same branch, reevaluation is based on current branch.
If branch is released, the new active branch needs to be determined, which then triggers reevaluation.

More Information on LDR and GDR:

How does Windows choose which version of a file to install?
https://blogs.technet.microsoft.com/joscon/2011/11/30/how-does-windows-choose-which-version-of-a-file-to-install

What is the difference between general distribution and limited distribution releases?
https://blogs.msdn.microsoft.com/windowsvistanow/2008/03/11/what-is-the-difference-between-general-distribution-and-limited-distribution-releases

QFE vs GDR/LDR hotfixes
https://blogs.technet.microsoft.com/instan/2009/03/04/qfe-vs-gdrldr-hotfixes

GDR, QFE, LDR… WTH?
http://blogs.technet.com/b/mrsnrub/archive/2009/05/14/gdr-qfe-ldr-wth.aspx

Branching Out
http://blogs.technet.com/b/mrsnrub/archive/2009/05/18/branching-out.aspx

Hope this information was helpful

Poornima Venkataraman
Support Engineer
Windows Core Team, Microsoft Enterprise Platforms

Suganya Natarajan
Technical Advisor
Windows Core Team, Microsoft Enterprise Platforms