GL - Your advice is quite wise.

But I am not.

I thought I'd try a "lesser" repair by right-click-repairing C:\Program Files\Microsoft Office\root\Integration\C2RInt.16.msi , which is an installer (maybe the installer) for the Office 16 Click-to-Run Extensibility Component that is generating the warnings.

The repair ran very briefly and that created again the same 41 Warnings as an "Update Now" of Word.   Just now.  Back to square one.

I see in the Warnings in eventvwr that "Source" is "MsiInstaller", not "TrustedInstaller".

Hmmm.

Is there a way to add "MsiInstaller" to the Registry keys and then give it Full Control permission?  The Registry Keys already list TrustedInstaller and give it Full Control, but "MsiInstaller" is not mentioned in any of them.

Look, if I win the Nobel, we can share it.

No, MsiInstaller is a different thing, an EventLog source. It's not an "entity" in the security sense to give it permissions. So it's case #2, broken installer that breaks the registry.

In any case, I doubt you should run the installer from that location (Program Files), unless you are trying to uninstall it (which I strongly suggest you try, because I think nobody needs that).

I can't do quotes in this editor properly, so I'll just try to paste, if that works:

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_officeinsider-mso_other/what-is-office-16-click-to-run-extensibility/ebffe8d7-ac9c-4a88-bf1b-3d7cd402848d

Things like Windows Desktop Search integration, the OneNote Printer Driver, Primary Interop Assemblies (PIAs), and Visual Studio Tools for Office (VSTO) are things no normal user should ever need. They are bloat aimed to drag you into Microsoft dependency, which would be the case if they were slightly useful, which they are not.

It's another thing if Office doesn't work without them (as I read that version 15 breaks 32-bit Office if uninstalled), but there is some chance it won't break. You could (have) tested this if you tried to run your Office programs after uninstalling it, but before reinstalling it. But it's not too late to try again. Better way would be to use Add/remove programs and uninstall only the Extensibility Component, or use Nirsoft's MyUninstaller to find it among all possible entries.

Otherwise, the way to fix it is to make a bug report to Microsoft or edit the .msi with Orca or similar tool, both tedious tasks.

GL




 

Edited March 30, 20179 yr by GrofLuigi
typos (and a lots of them)

New update on April 16, 2017 -

Nothing has ever worked to stop the "cannot modify the protected key" warnings.  The new Update Now yesterday to this O365 Home generated the same 41 Warnings.

So, today, after first creating a restore point, I DELETED the 41 keys, then went to Control Panel -- Programs and Features -- right-clicked Microsoft Office 365-en us and did a Repair - Online.

No help.  In fact, it caused new problems, so I Restored from the restore point and went back to where I was.

What in tarnation is "protecting" those keys?

Ideas?

 
On July 4, 2018, over in the MS Answers Community, a good citizen suggested "MS Utility against Office https://diagnostics.outlook.com/#/" .

Well, I have now run that utility a number of times, and on the latest Update of my O365 (after running the utility), I have only 21 Warnings, and those are three Warnings for each of seven registry keys.  So the situation is improved.

Using the tools provided by dencorso and others in THIS thread, I have now gone into the Permissions of each of those seven registry keys and added Everyone - Full Control.

So let's see what happens the next time there's an Update to O365.  Stay tuned.

(And that suggested MS utility is clearly good for a LOT of situations.)

By the way, those seven registry keys are:

Software\Classes\CLSID\{3050F667-98B5-11CF-BB82-00AA00BDCE0B}\InprocServer32
Software\Classes\CLSID\{3050F819-98B5-11CF-BB82-00AA00BDCE0B}\InprocServer32
Software\Classes\CLSID\{AE24FDAE-03C6-11D1-8B76-0080C744F389}\InprocServer32
Software\Classes\CLSID\{25336920-03F9-11CF-8FD0-00AA00686F13}\InprocServer32
Software\Classes\CLSID\{3050F391-98B5-11CF-BB82-00AA00BDCE0B}\InprocServer32
Software\Classes\CLSID\{0BE35204-8F91-11CE-9DE3-00AA004BB851}\InprocServer32
Software\Classes\CLSID\{0BE35203-8F91-11CE-9DE3-00AA004BB851}\InprocServer32
 

 

UPDATE - NO LUCK - The same seven keys would not accept three modifications each.

Any ideas?

 

Added note on odd aspects of seven registry keys that are “protected” and throw Warnings when I update Office 365 Home

One of the seven is:

Software\Classes\CLSID\{3050F667-98B5-11CF-BB82-00AA00BDCE0B}\InprocServer32

Its “Advanced Security Settings” show the following (and this is after I gave Full Control to Everyone, Account Unknown and Users and made sure others had Full Control) – two screenshots:

< SEE SCREENSHOTS HERE>

OR TRY

< THIS LINK AND SCROLL UP IF TOO FAR >

NOTE HOW there are four DUPLICATE listings for SYSTEM, Administrators, Users and Account Unknown that say “Read”.  Two things:

I cannot Edit those “Reads”.  Any attempt to double-click on any of those last four does not work – I just bounce back into the upper list that already says “Full Control”. (All other attempts to check the Permissions of the upper part of the list indicate Full Control.)

I cannot check “Replace all child object permissions with inheritable permissions from this object”.  If I do and hit Apply, it unchecks itself.

I see these symptoms on at least four of the seven "protected" keys and a few of these symptoms on the other three.

So, might this be connected to the reason I get warnings that these keys are protected and cannot be modified each time I update O365?

glnzglnz <br/> ► In the office, Dell Optiplex 7010 with 4GB RAM, Win 7 Pro 32-bit and Office 2010. <br/> ► At home, Dell Optiplex 7010 with 16GB RAM dual-booting Win 7 Pro 64-bit (now with Office 365 Home) and Win 10 Pro 64-bit. <br/> ► Also still have Dell Optiplex 755 with 4GB RAM with Win XP Pro SP3 (which still gets updates with the POS hack) and Office 2003.

 

Edited July 28, 20188 yr by glnz

I believe that the duplicates are normal, at least we can think that there is a limitation in the UI. As long as each have different inheritances, when a Security Context appears an additional time in the permissions list, with one inheritance and one "not inherited" it means that the "not inherited" permissions are in addition to the inherited.

You can try, adding SYSTEM security context additionally to read, so that it too would have a "not inherited" listing. Then uncheck "include inheritable permissions from this object's parent" box. That should invalidate the already present inherited items.

Account Unknown is likely an account that no longer exists on the system. Previous user account, or a temporary account created by a program during installation. When the account is removed from the system, it still can exist in permissions for objects, as seen here. Search the registry for that SID to see if you can determine what that account originally was or what created it.

It is normal for the checkbox to uncheck after replacing. Another unusual UI design choice, it should have been a button rather than a checkbox I think.

Trip - thanks.

I' not sure what you mean by "You can try, adding SYSTEM security context additionally to read, so that it too would have a "not inherited" listing."  SYSTEM already appears twice - explicitly (not inherited) with Full Control, and inherited as Read.  Should I add it again?  If yes, with what setting?

Also, is it relevant that all seven stubborn registry keys end with "InprocServer32"?

When I started this philosophical-life struggle two years ago, an MS telephone tech person wrongly had me install the 32-bit version of O365 when I had always wanted the 64-bit version.  We UNinstalled the 32-bit and re-installed the 64-bit.  So, is "InprocServer32" a holdover from the initial installation that should no longer be there?  (And keep in mind I have tried to do some VERY thorough UNinstalls and re-installs since then.)

Ok let's preface this with MAKE A BACKUP FIRST... which hopefully wouldn't be a required thing to say.

First of all, when you are dealing with permissions, you can see an account name there, but it isn't a user account. The groups or other things (such as TrustedInstaller or System) are not user accounts nor groups. The groups solely exist elsewhere in the system. These references are Security Contexts.

You have duplicates in your list because there are some that have an inheritance, and others that you (or whatever) have added manually. If you want to remove the inherited context rights, you have a few ways of doing it:

1. Remove them using the UI (may not stick)

2. Remove the permission propagation of child objects from the parent object itself. The Inherited From column is telling you which object that is.

3. You can uncheck the "Include Inheritable Permissions" box, which should remove all of the Security Contexts that have inherited permissions.

However, before any of this is done, you need to make sure that SYSTEM still has the correct permissions, otherwise it can cause problems. Removing it using #2 or #3 could remove it from the list entirely, which is not advisable.

If you know which account is trying to do this action that is being recorded into Event Viewer, verify it on the Effective Permissions tab.

Trip - I'd like to post a follow-up question to you and some more detail here but I'm getting error message from MSFN that I don't have permission to post on this server.

Try the info I posted here:  < PCLOUD LINK TO DOCX >

Thanks.

Edited July 30, 20188 yr by glnz

Grant SYSTEM modify permissions on those keys.

Trip - SYSTEM is listed the first time with "Full Control" as an explicit permission ("not inherited"). 
SYSTEM is listed a second time with "Read" as an inherited permission, which I have not yet tried to change with one of the strong techniques you list.

I understand that the double-listing means that SYSTEM has all the permissions granted in either listing, so effectively it should be Full Control, yes?

Let's see what happens with the next update for O365, which seems to happen about every three weeks.

Thanks.

Edited July 31, 20188 yr by glnz

@glnz: OK. Do it this way: (i) Get joakim's great RunAsTI. (ii) Run it as Admin. It'll open a CMD box as the infamous TrustedInstaller. (iii) At the prompt of that CMD box, type regedit and hit enter. (iv) regedit will open at TrustedInstaller level. (v) Go to the problematic entries, delete the duplicates and correct the rights of what remains. It should just work! Consider, however, that I've given you a loaded .50 so make very sure you don't mistake the business end for the butt, please.

Den - thanks again.  I think I actually did much of that per your advice a year+ ago on this very thread.

Anyway, just the past two+ weeks, impersonating TI per the tools you recommended earlier, I added EVERYONE to the seven stubborn registry keys and made sure that all explicitly listed accounts have Full Control.

If you go to   < THIS LINK AGAIN >   and scroll up a bit, my two screenshots show this but also show four duplicate "inherited" entries with only "Read" permission that I cannot change, even impersonating TI.  I have not tried to delete them, but I am guessing I cannot delete them UNLESS I uncheck "Include inheritable permissions from this object's parent."

I think I'll wait through one more O365 update to see if most recent steps work.  If not, I'll try the uncheck and deletions.

PS - it's also very helpful to run RegScanner 64 when I'm in TI mode.  It finds things very fast, and then one can right-click directly into regedit.

So, thanks to you, I can impersonate both TI and IT.

Edited August 1, 20188 yr by glnz

22 hours ago, glnz said:

I understand that the double-listing means that SYSTEM has all the permissions granted in either listing, so effectively it should be Full Control, yes?

You'd have to look at the Effective Permissions tab to see exactly what rights it has.