AppV 5.1 and MS Word 2016 RRS feed

  • Question

  • Hello all,

    I have a problem that I thought would be much more common however I have only been able to find one other thread on this and his solution did not work for me ( winword.exe /appvve:IDGUID_VERGUID ). I have a VDI environment with Office 2016 installed locally into the VDisk. Office works fine but there so many addons these days... I can get them to work by creating an "Application" in my addon package which is just a shortcut to the relevant office executable. These all work just fine except for Word. No matter how I approach this I always get an error when launching word into the virtual environment: "We're sorry but this feature appears to be broken and needs to be raipaired..etc etc.."  Word then goes on to launch and function with no other errors. I am hoping this is so simple that no one even bothers to mention it ;) Any idea?

    Wednesday, October 12, 2016 4:52 AM

All replies

  • Why don't you use App-V packaged Office 2016?

    If I get right you already have packaged office addons to app-v. Just create app-v connection group between office and your addons.


    Wednesday, October 12, 2016 7:12 AM
  • Thanks, but that's not really an option. If I were going to take the easy way out I'd just deploy the addon into the VDI image. And that is what I'll do If there isn't a way to fix this error.


    Wednesday, October 12, 2016 10:43 PM
  • Yeah. I was just wondering why use local install of Office when virtual version is fully supported.

    Well then it's troubleshooting what you have to do. Basically try to find working environment and compare it with your VDI.

    Things I would test (first you looked things like events etc:))

    1. Try to start word inside another App-V package. Does this error come with every package or just with some packages? Try with package what have nothing to do with Office or create empty App-V package and test with it. After that you know is there something wrong with your addon packages or in virtual environment.

    2. Check are you using newest App-V client (hotfix etc.)? 5.1 RTM has bugs like unable open multiple tabs in IE:)

    3. Install same app-v client and office to normal workstation. Just install normal workstation, less modification is always better. Test addon package there. If it works you know App-V is able to do it but there is something in your VDI causing the problem.


    Thursday, October 13, 2016 5:47 AM
  • I have to correct you there, Office 2016 VL with latest ODT is no longer supported (there is still support for 2013 and older ODTs though). Only the O365 C2R client is still supported as AppV package.

    How are your word addins loaded? Did you place them in the startup folder under programfiles (in your appvpackage)? Or did you use the appdata folder?
    How are your regkeys inside the package set? They should be set to merge. Make sure to at least start all office components once on your sequencer before creating your package.

    Roy Essers

    Thursday, October 13, 2016 9:01 PM
  • I agree that its not ideal having a local install of office and then adding a bunch of virtual addons. I came late to this project so didn't have a say in the design from an apps packaging perspective.

    1. I have created an empty package on a vanilla Win 10 VM and added a shortcut to Word. I then tested it on a vanilla Win 10 client, same error so the addons are not causing the issue. 

    2. This is also happening with a different addon, Word and Excel for HP ALM, runs fine with Excel but Word gives the same error. (see point 1)

    3. The addon is loaded using the reg key: LoadBehaviour:3 which = loaded on startup as well as connected. However given the results from point 1 I'd say this is irrelevant.

    4. I did have the reg keys set to merge and cleaned out all other keys.

    5. AppV Client version is, I have just upodated to 5.1.106 and got the same result with my empty package on vanilla Win 10 clients.

    Thanks for the ideas so far guys. I am ready to admit defeat on this one I think.
    Thursday, October 13, 2016 11:38 PM
  • Roy, thanks for info about App-V support. Could you give some link or something else where that support thing is announced?


    Friday, October 14, 2016 6:40 AM
  • I think it's great, we do the same Office 2013 locally installed and started by RunVirtual. All our addons are in a single connection group and we just load them by group with the loadbehavior key. I've tried to run Office 2013 full virtual but it was really buggy and we got lots of issues.

    As for this issue, I've noticed it's important with addons that you clean-up the package thoroughly after sequencing. Delete any files/reg entries not required.

    Like in our environment we have the HKCU/Software/Microsoft/Office key added to virtualregkeypassthroughpath so we always have to delete that key from our sequences and manually add the add-in/loadbehavior key later on when the user starts the application.

    So do that first, clean your package to the bare minimum and test again.

    And btw also try to create an empty/dummy package and then launch winword.exe /appvve.... with the dummy package see if you get the same problem. Then you know if it's your package or a bug in Word 2016.

    Monday, October 17, 2016 9:11 AM
  • That you all for the replies. I was on my way to resolving this when that project was put on hold. When the bosses finish working out a contract I dare say I'll be back.

    I discovered that I needed to sequence the addons as Middleware (they are COM addons). This along with the "Run Virtual" reg keys solved the problem to a point. It all worked but HKLM run virtual needs to be published globally which is not an option for this app as the license count is only 5 and there are over 1000 VDI users.

    When/if I get back to it or come across this issue again I'll look into the HKCU run virtual option. I did give it a quick crack but it didn't work 1st try and I didn't get a chance to look into it.


    Tuesday, November 1, 2016 4:26 AM
  • All the other options besides standard package do is change some of the default app-v monitoring settings, exclusions etc. I never use them and I don't think anyone needs them.

    There is no such thing as runvirtual HKCU btw, its HKLM only. The idea is that you run winword.exe virtual and only load the addin for the required users by injecting the loadbehavior key for the plugin into HKCU/Software/Microsoft/Office/Word/Addins. You can do this with a preference GPO if you have no appsense or RES or other workspace management.

    Usually companies have multiple addins so I add all addins to one App-V connection group and load them for the user when required or not just by adding the loadbehavior registry key for that particular user. Of course this means that users that don't have the addin could still load it manually if they really wanted to. You can further lock this down with applocker if this really causes licensing issue but in most cases you should be fine. Either way it makes no sense to load an add-in required by 5 users only for 1000 users.

    Like I said before if you sequence for connection groups or runvirtual it's a whole different ballgame. You really need to cleanup the package and get rid of all the office related registry keys and files. You only need the files that are truly from the add-in onl and delete anything else. Then at a later stage inject the add-in key tot the user's registry and load it that way.

    I've sequenced a lot of add-ins for Office 2013/2016 and left some keys that seemed meaningless to me yet it caused winword to display an error during startup.

    If you don't want this then don't use runvirtual. Just use winword with the /appvve switch pointing to the addin package and instruct the user to launch that shortcut if he wants to use the add-in. I don't think that's really neat though.

    Good luck

    Tuesday, November 1, 2016 9:08 AM
  • There is no such thing as runvirtual HKCU btw, its HKLM only.

    Just an FYI you can do run virtual for per user published apps in HKCU since SP3:

    We've used it a bunch as a proof of concept using only HKCU.

    Thursday, November 3, 2016 1:22 AM
  • Yes but then you need to publish the app to the user and not globally, I don't think that's a great solution I would always publish globally (especially on VDI environments) for performance reasons. Other than that I don't think it's a good solution to run an app virtual for one user and not for the other.

    But yeah if you look at it like that it's possible.

    Thursday, November 3, 2016 8:08 AM
  • Hello,

    Here is the Technet article where I first read about the discontinued support for Office 2016 Volume License with ODT: https://technet.microsoft.com/en-us/library/jj219426.aspx

    You can use the ODT to create App-V packages for Office 365 ProPlus. Creating packages for the volume-licensed versions of Office Professional Plus or Office Standard is not supported.

    It was announced by Steven Thomas on Twitter (@madvirtualizer).

    Steven Thomas (@madvirtualizer) tweeted at 9:13 p.m. on Fri, Sep 23, 2016: Creating #AppV packages 4 VL versions of #Office ProPlus 2016 no longer supported with ODT - https://t.co/hehohXjQQb

    Thursday, November 3, 2016 9:51 AM