Have you ever experienced slow installations when using the WUSA.exe together with *.MSU files? I did with a number of installations, such as:
- Microsoft Language Packs -> Multi-Language User Interface (MUI)
- Microsoft Internet Explorer 11
- Microsoft Internet Explorer components (Hyphenation, Spelling)
- Microsoft Internet Explorer 11 Language Packs
- Various Microsoft hotfixes
The Solution (short version)
In case you are in a hurry and are not waiting for any blabla, here is the quick version of the solution:
- Do not use the MSU file to install the software, but instead, extract the MSU file and use the included CAB file instead (not the one called WSUSSCAN.cab, the other one). Use the following command to extract the MSU file:
expand -f:* "C:\%InstallFile%.msu" %TEMP%
expand -f:* "C:\Temp\Windows6.1-KB2896256-x64.msu" C:\TEMP
- Then use the following command to install the software:
dism.exe /online /add-package /packagepath:"%InstallFile%.cab" /quiet /norestart /logpath:"%LogFile%"
dism.exe /online /add-package /packagepath:"C:\Temp\Windows6.1-KB2896256-x64.cab" /quiet /norestart /logpath:"C:\Logs\Install_hotfix_Windows6.1-KB2896256-x64.log"
For more information please continue reading.
First of all let's be clear under which circumstances my problem arose:
- Operating system: Windows Server 2008 R2
- System deployment tool: Microsoft SCCM 2012 R2
- Execution script: PowerShell (version 5.0)
- Execution command in script:
wusa.exe %InstallFile% /quiet /norestart /log:%LogFile%
The PowerShell wrapper was started by SCCM, which means that it runs under the local System account.
The installation of the individual installations took a REALLY long time. For example, an Internet Explorer language pack took up to 25 minutes to install, which under normal circumstances should only take 2 minutes or so. The same goes for the other components. Since I was creating a new golden image for my XenDesktop 7.x workers and I was installing 8 language packs this took about 2 hours! This was unacceptable of course.
In my installation packages I used the WUSA.exe to install the software. The WUSA.exe is the Windows Update Standalone Installer. As per Microsoft:
The wusa.exe file is located in the %windir%\System32 folder. The Windows Update Standalone Installer uses the Windows Update Agent API to install update packages. Update packages have an .msu file name extension. The .msu file name extension is associated with the Windows Update Standalone Installer.
I have to admit that I am still not 100% sure why the problem arose, but the main cause is for sure related to how the process WUSA.exe works. In the end, I suspect the problem has to do with two things:
- First of all, as written in the aforementioned Microsoft article, the WUSA.exe "uses the Windows Update metadata in the .msu file to search for applicable updates". This is the first step in the installation process. To me this means that the WUSA process tries to contact either the Windows Update server within our LAN or it tries to reach a Windows Update server on the Internet.
- Secondly, the SCCM installation runs under the local System account. This account has very limited permissions outside of the local server. It does have sufficient rights to contact the Windows Update server in the LAN, but not to contact Windows Update servers on the Internet.
As I said, I am not 100% sure what caused the delay in the process. Either the WUSA.exe tried to contact servers on the Internet (which it could not) or it tried to find some information on the local Windows Update servers which it could not find. I do not know.
In the end, the WUSA.exe process simply "got stuck" for whatever reason. After 25 minutes or so it (probably) ended in a time-out. Mind you, the installation itself worked fine, but it took a really long time to complete.
The Solution (long version)
In the Microsoft article mentioned in the previous paragraph a potential solution is presented. The solution is to install the MSU files by using the command DISM.exe /Add-Package. However, for some reason, this command did not work on all packages. It worked on the Windows Language packs, but not on IE 11 nor the hotfixes. In the cases where it did not work I received a strange error. But I wanted one method to rule them all.
So I decided to go a slightly different way. You see, DISM can be used to install CAB files as well. As per Microsoft:
Operating system package-servicing commands (DISM) can be used offline to install, remove, or update Windows® packages provided as cabinet (.cab) or Windows Update Stand-alone Installer (.msu) files.
So I decided to use the "dism.exe" command to install the CAB file included within the MSU file. These are the steps:
- Extract the MSU file using the following command:
expand -f:* "C:\Temp\%InstallFile%.msu" %TEMP%
expand -f:* "C:\Temp\Windows6.1-KB2896256-x64.msu" %TEMP%
- After extraction there will be four files present in your directory: two CAB files, one XML file and one TXT file. The MSU file used in this example included the following files:
Do NOT use the file called WSUSSCAN.cab. Use the other one. In our example this would be the file Windows6.1-KB2896256-x64.cab.
- Use the following command to install the CAB file:
dism.exe /online /add-package /packagepath:"%InstallFile%" /quiet /norestart /logpath:"%LogFile%"
dism.exe /online /add-package /packagepath:"C:\Temp\Windows6.1-KB2896256-x64.cab" /quiet /norestart /logpath:"C:\Logs\Install_hotfix_Windows6.1-KB2533623-x64.log"
And one last thing. In case you are wondering why I used the "dism.exe" executable within PowerShell instead of the native PowerShell command "Add-WindowsPackage", please remember I was working on Windows Server 2008 R2. Even though PowerShell version 5.0 was installed on the local system, the cmdlets for DISM are only available from Windows 8.1/Windows Server 2012 R2.