Last night I was facing an annoing issue which prevents me from installing Update Rollup 2 for System Center 2012 R2 Service Manager systems. I’d no clue because the logging wasn’t telling me anything usefull information!
Luckely I came across a thread by Thomas Bianco which was facing the same issue with Update Release 4 of Service manager 2012 SP1.
I was able to trace this down to a sharing violation on the QFEList.xml file that lists the Windows Installer patches to apply as part of the update. Essentially, the PatchWizard executable opens this file and reads it before displaying the EULA, but for whatever reason doesn’t release this handle when it’s done. Once you click the Install button, PatchWizard tries to open and read that file again, only the original file handle is still open, so this creates a sharing violation.
The fix I used involved manually closing that file handle using Process Explorer before accepting the EULA. You’ll want to start the patch, wait for the EULA acceptance screen to pop up, open process explorer, find the PatchWizard process, look at it’s open handles list (usually in the bottom pane), find the QFEList.XML handle, right click and close handle. Accepting the EULA will then process without error, and the patch will install correctly.
This behaviour seems not limited to a specific OS version (Windows Server 2008 R2, 2012 or 2012 R2) neither Update Rollup. The same issue occured by installing Update Rollup 1 for Service Manager 2012 SP1 which was blocking from upgrading to R2. This seams particilulair related to the Patchwizard.exe wrapper as we encounter no issue’s by upgrading to R2. The last one is using SetupWizard.exe as wrapper instead of Patchwizard.exe
Another option to bypass this behaviour is to install the MSP directly. This is a fully supported scenario as mentioned by the Service Manager product team.
The *Patchwizard.exe file is just a wrapper, so if you have a tool like Configuration Manager you can use the .MSP file directly for deployment and skip deploying the executable. And this applies to past and future rollups that are constructed in the same way as well. This is a fully supported scenario so if that better suites your needs then feel free to deploy the update using this method instead.
Read Thomas blog on how to bypass and install your Update Release(s).
Both options – kill QFEList.xml thread or install UR directly using MSP – are not a solution but a workaround getting the software installed.