VMware Horizon Community
jmatz135
Hot Shot
Hot Shot

Office 365 Slow when ANY appstack attached

So we've been looking into some performance issues we have with Microsoft Office and it turns out it is App Volumes causing it.  First I'll explain the issue.  If you are using a Microsoft Office product the first thing you will notice is launching an Office app i.e. Microsoft Word it will take 2-3 times longer if you have ANY appstacks attached to the VM.  If this was the only problem I could get over it, as a 6 second launch time as opposed to a 2 second launch time isn't killer, rather just a bit annoying, but the real kicker is even once the application has launched certain things are very slow within the application and users can't stand it.  An example of this, when you have Microsoft Word open, open a blank word document and go to insert and select Object.  It will bring up this window:
pastedImage_0.png

If you have no appstacks attached this will happen in 1-2 seconds.  If you attach ANY appstacks at all this will take 10-15 seconds.  This isn't the only thing that happens slowly within Office, but it is the easiest to reproduce so I put it on here. 

The real issue here is that this isn't just if you have Microsoft Office in an appstack, this happens anytime you attach any appstack to your vm.  You can literally have a machine with Microsoft Office installed and everything will work fine, and while you are sitting there go to the app volumes manager and deploy an appstack with just notepad++ for instance immediately to your vm.  Now if you try to launch Word/Excel whatever it is significantly slower and doing certain things (as in the example above) is ridiculously slow.  Basically using app volumes at all makes Microsoft Office painfully slow at points. 

This happens if you are using Windows 7 or Windows 10, and App Volumes agents 2.13.0 to 2.14.0 at the minimum as I've tested all of those. Anyone have any ideas as to a way to fix this or help with this?

Reply
0 Kudos
31 Replies
Ray_handels
Virtuoso
Virtuoso

We have seen this with version 2.13 and 2.14 and is heavily related to Windows 10 and Office 2016 (as it seems)...

To be honest i haven't tried 2.12 because we started with 2.13 on W10.

One thing to note though is to have a thorough look through your appstacks. Polluted appstacks do tend to add a few seconds to the wait time and trying to rebuild some of them by excluding which one is causing the most issues is worth the effort. And it seems to hit all office applications. I was triggered by the object thing from jmatz which led me to test this with power point (in which I thought the issue wasn't there or at least less visible) but we see the exact same issue there which implies all office applications will have some issues here and there..

Reply
0 Kudos
jmatz135
Hot Shot
Hot Shot

This happens in Windows 10 or Windows 7 and has nothing to do with what is in your appstacks.  You can have Office installed on your base image and apply a literally blank appstack and you will see the issue.  There are other things this happens to as well.  Event Viewer is one that I see a lot as I'm having to use it fairly often.  Basically Event Viewer will open fine but when you go to actually click on events if you have an appstack applied it will take like 20 seconds and totally hang your machine just to show the events in the viewer.  If you have no appstacks applied it will take 2-3 seconds (obviously these times depend on how many events there are but I clear my events on the snapshot before deploying so there are not very many).  This is very easy to test.  Just log into a machine with no appstacks and open event viewer and it works as expected then apply an appstack with anything in it immediately while you are still logged in.  Now open event viewer and feel the pain.

Reply
0 Kudos
alsmk2
Hot Shot
Hot Shot

... begs the question what testing do the AV team actually do before a release? I'm longing for the day when AV finally makes it out of beta.

Office is pretty much the number one app in 90% of organisations, so should be at the top of the list for compatibility testing.

Reply
0 Kudos
jmatz135
Hot Shot
Hot Shot

With all of the issues just getting the agent to actually connect consistently to the managers and all of the bugs that are introduced after each release my guess is they have zero actual testing of the application.

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

I've tried various things to fix this and so far unsuccessful.  Has anybody opened a ticket yet on this issue?

Reply
0 Kudos
jmatz135
Hot Shot
Hot Shot

I had a ticket open for about 4 months, but since VMware's stance is that the behavior is expected and appropriate it didn't go anywhere.  They eventually closed the ticket and I didn't bother arguing as they weren't going to to anything.

Reply
0 Kudos
Najtsob
Enthusiast
Enthusiast

Version 2.15 was released few days ago, I need to check if there is any improvement on o365 startup times.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

Please let us know but to be honest I guess it wont help us with the slowness in Office applications.

Still trying to find a solution, will keep you guys posted. And please najtsob, if you find something with the 2.15 agent let us know.

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

I too would be interested in whether 2.15 helps.  It looks like enough people are having this issue and Office 2016 has been out long enough that AppVol should be stable with it, in my opinion.  We only started having this issue after upgrading the Manager and Agent to 2.14.2 (from 2.12), and having these issues without changing anything else so it's definitely an AppVol issue.

I currently have a ticket open regarding Office 2016 running its setup repeatedly for Outlook.  I am thinking maybe it's related to the slowness issue but I will post back the findings to see if it might help.  I am able to reproduce the issue and they have collected logs from an affected VM.

Reply
0 Kudos
pawan11
Contributor
Contributor

We have a majim delivery for a customer on hold for just because of this issue. The main issue for us 0355 which is installed on base image and we have appstacks per users vary from 3 to 5. As the numbrn of appstacks increase the office launch time is also increased. We are having launch time feom 17sec to 40 sec. We are working with VMware team for last 3 months. Initially we tried with exclusion of office exe in snapvol config file which did not work in our case as we were using UIA + profile for app volumes. Just last week VMware team has told us to use a registry key to disable Telemetry for O365, which after testing for few rounds has not improved the performance. The VMware engineering team is working on it and they may be releasing some fix for in couple of months. The customer has challenged us where we know the VDi well or not. It is sad that we have sold a solution which customer is now not willing to move to production because of bad end user experience. To be honest, I would not take it myself. Hopefully VMware should brake it seriously and speed-up the release of fix ASAP.

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

We have a majim delivery for a customer on hold for just because of this issue. The main issue for us 0355 which is installed on base image and we have appstacks per users vary from 3 to 5. As the numbrn of appstacks increase the office launch time is also increased. We are having launch time feom 17sec to 40 sec. We are working with VMware team for last 3 months. Initially we tried with exclusion of office exe in snapvol config file which did not work in our case as we were using UIA + profile for app volumes. Just last week VMware team has told us to use a registry key to disable Telemetry for O365, which after testing for few rounds has not improved the performance. The VMware engineering team is working on it and they may be releasing some fix for in couple of months. The customer has challenged us where we know the VDi well or not. It is sad that we have sold a solution which customer is now not willing to move to production because of bad end user experience. To be honest, I would not take it myself. Hopefully VMware should brake it seriously and speed-up the release of fix ASAP.

Hello: We recently came across some issues with our Office applications, due to older AppStacks being used.  Our solution was to update and re-save each AppStack.  It apparently updates the AppStacks in some way that applies fixes since we created them.  We created in version 2.12 and I re-saved them in version 2.14.2. It might be worth trying to re-save yours and see if you notice a difference.  Try it on a test machine, and try attaching just one AppStack to it.  If it's slow, update and re-save the AppStack and try it again and see if you notice any difference.  I would also upgrade to AppVol 2.14 or higher as there are a lot of MSFT related bugs fixed.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

Even though it does help to recreate appstacks we also see this issue when we have empty appstacks and try to start up office applications. It's not with every applications and it is not with every action you take. The insert Objects one is a good testing base. And waiting for 40 seconds is something we did not see. We had a max wait time of about 15 seconds and this was due to a bad appstack. After recreating the "bad" appstacks we went to a max of 7 (but mostly 5) seconds wait time for those actions the first time they are executed. Still very frustrating for a user.

Reply
0 Kudos