While on a project to update the Sophos Enterprise Console from version 5.2 to the newest version 5.5 I ran into a nasty problem. The Sophos installer will update all components, including the database if its hosted on the same server, and all seemed to go well. There was however a snag when the installation procedure tried to install the management console MSI, and rolled back the installation:
The rollback resulted in the following message and got me absolutely nowhere. The logs quickly pointed me to the event viewer.
The event viewer showed a strange problem, found from the logfiles regarding the fact that some obscure part of the registry could not be accessed or located. When checking the concerning registry key, even in safe mode, it was unaccessible:
I tried everything with every user that had some form of rights on the specific 2008R2 server the console is installed on, but to no avail. After some googeling I found a brilliant idea, referring to the SYSTEM account on the server. Why not use psexec to start regedit.exe under the SYSTEM account?
After downloading the PStools from former Sysinternals (now Microsoft) I managed to start the registry editor and presto, I could access the concerning key. The concerning command line used: psexec -i -d -s c:\windows\regedit.exe
The strange this was, there were no rights applied to the concerning registry key, but it showed me as an owner:
I replaced the child object permissions from the inheriting key by selecting the Replace all child object permissions with inheritable permissions from this object and restarted the upgrade procedure:
Sadly, the registry key was not the only one. After many tries and searching the registry the following list of entries had the same problem and had to be amended:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components
\4863E4C7411439B4FA223EBAA59F497A\7CE13FD4909C9DB46A8AF04F4C131388 \C2CFBACF6DA6EA748B690CE151F44818\7CE13FD4909C9DB46A8AF04F4C131388 \F3FF4F3AC9D19A84491ED716FE35BDF1\7CE13FD4909C9DB46A8AF04F4C131388 \5F74E7C4D90360844990D872C400BE6C\7CE13FD4909C9DB46A8AF04F4C131388 \48BFC751BAA3B6042BDC3E21051FE7D5\7CE13FD4909C9DB46A8AF04F4C131388 \E96864278DB3BCF498F10F84BBFFE831\7CE13FD4909C9DB46A8AF04F4C131388 \DF4E05F72AA05A041847EC2D184ABD2E\7CE13FD4909C9DB46A8AF04F4C131388 \4674C07415324034CAE2263040A0AF17\7CE13FD4909C9DB46A8AF04F4C131388 \888100ECDA0FEFC4C8DB614BA8644AB6\7CE13FD4909C9DB46A8AF04F4C131388 \AC76EA9DA0133AA46B0C33FC8D7CF5B2\7CE13FD4909C9DB46A8AF04F4C131388 \80190E7BCD26B4540BDD50EE3C2278F8\7CE13FD4909C9DB46A8AF04F4C131388 \44E8737BE0944CA4D88013C93F5531D7\7CE13FD4909C9DB46A8AF04F4C131388 \4585CFB410AF1554BB6DDFB20C794E2B\7CE13FD4909C9DB46A8AF04F4C131388 \729F6741923D8D448BBFF3227EBECEB4\7CE13FD4909C9DB46A8AF04F4C131388 \FE19DC7E58AB9094DA927F3CD055449C\7CE13FD4909C9DB46A8AF04F4C131388 \44888DA3BA408BA41A11B6EB73E8AC32\7CE13FD4909C9DB46A8AF04F4C131388 \C4E0B6545F83582458DF400AA0FE419F\7CE13FD4909C9DB46A8AF04F4C131388 \D1C9A20BB42F96E4AB68BB4D201C0026\7CE13FD4909C9DB46A8AF04F4C131388 \7C077DCEB04E69640BFD4A84F5940F8D\7CE13FD4909C9DB46A8AF04F4C131388 \2987560411DFB084EA66CB6FBD7724CF\7CE13FD4909C9DB46A8AF04F4C131388 \7C7418BCEB7B4314E9A569ACF756738B\7CE13FD4909C9DB46A8AF04F4C131388 \73DAA4E671F41784FA9EDD26250B59FB\7CE13FD4909C9DB46A8AF04F4C131388
After reapplying the correct permissions to them, the upgrade went off without a hitch. I have not been able to determine a cause, but luckily found this workaround. Takeway from this is whenever you run into permission related issues with either registry or files, there's always the option to leverage the SYSTEM account, in this case through PSEXEC to start the concerning process.