Hi - thanks for the input. I do have administration privileges on the local drive. I think you're on something though - the way the clipboard is managed (address pointers?). Who knows. Until then, enter key works OK - annoying though.
So I was too hasty in stating that was the fix. It made things less problematic, but the clipboard errors came back. The version that was having issues for us was:
Version 1712 (Build 8827.2179 click-to-Run) Educational ProPlus
I will state that we support over 350 separate clients in our Tri-State area, and this is the only client I have encountered this issue with. Additionally, it is only affecting 2 users. Both of which had their systems reimaged and Office installed from
the 365 portal.
In my company's portal, I'm an early adopter and work for an MSP, and the lastest version I have access to is:
Version 1708 (Build 8431.2153 Click-to-Run) ProPlus
So there is something weird going on when a non-early adopter is able to install a build version 4 (1712 vs. 1708) higher than an early adopter. The interface is quite different than 1708 or 1701. Most notably, there is an "auto-save" toggle switch in
excel near the "File" menu.
This version was installed fresh on a newly imaged system and downloaded from the 365 portal. I spoke with the tech that installed this and I found that this is not the normal way we install Office for this client.
We normally deploy Office through the Office Deployment Tool with a source directory and xml configuration file for this school. When installing Office through the Deployment Tool the source files we have are for the following version:
Version 1701 (Build 7766.2060 Click-to-Run) ProPlus
After Office is launched it has the user sign into it and licenses the software from their cloud licenses. It does not update further. This most likely is because we have WSUS enabled for the environment to prevent mid-day updates/restarts and to make
sure Microsoft can't blindside us with a patching failure.
The clipboard issue is not present in Version 1701 (Build 7766.2060 Click-to-Run). I feel like I just sidestepped this issue, but if you can get your Office version reverted, you won't need to deal with this headache anymore.
If you would like to try this, here are the steps to revert to a previous version. Be aware that this could cause you to be affected by a previous issue that was already patched, and have to throw in the disclaimer that you try this on your own accord.
That being said, if the world blows up and something goes very wrong you can always uninstall and reinstall from the 365 portal and be no worse off then you are now.
This assumes you have the 32bit version installed as Microsoft recommends not installing the 64bit version because most add-ins will not be compatible with the 64bit version.
- Open an administrative command prompt
2. Type or copy this to change your directory:
cd "%programfiles%\Common Files\Microsoft Shared\ClickToRun"
- Type this command to revert to a specific version:
officec2rclient.exe /update user updatetoversion=16.0.7766.2060
You should now see the same type of Window if you were doing a quick or online repair. After this completes, provided there are no errors, you should be on a version of Excel that actually works. Make sure you delay your Office updates after this or it
may randomly update to the broken version again. If it does update you can always repeat these steps to revert it back to the old version.
P.S, This is how to make sense of the updatetoversion number code:
[version 16.0.xxxx.yyyy = Office version 16 .0 <-- the zero means nothing. (build number) xxxx.yyyy (Ex. 16.0.7766.2060, this would be the 1701 (Build 7766.2060 Click-to-Run) version I describe above]
I hope this makes someone's life a little less stressful and extra "copy and pasty"! ;)
RW