szilagyic
Hot Shot
Hot Shot

Office Pro Plus installs/configures on every launch of Outlook

Jump to solution

Hello:

We just upgraded from AppVol 2.12 to 2.14.2 (latest).  After the upgrade, users are calling in with an issue where Outlook 2016 Pro Plus tries to run an install or configure every time it is launched. In our case we have Office installed directly on the master image which has not changed, it is not an AppStack.  We use Writable Volumes and I have verified that the issue is not related to any changes in the snapvol.cfg file with the update as I've tried the old version of snapvol.cfg as well and get the same behavior, so it's definitely an issue with the 2.14.2 upgrade somehow.

pastedImage_0.png

Has anybody else experienced this and know of a workaround?  I've been looking and so far no solution that I can find.

Thanks in advance!

Chris

1 Solution

Accepted Solutions
szilagyic
Hot Shot
Hot Shot

Thank you for all of the feedback.  I ended up opening a ticket with VMware.  They had me test with an empty AppStack , with a user that already had a Writable Volume, and that did not cause the issue to happen.  Since we have Office installed on our master image, we were able to test it with the new empty AppStack and as soon as I assigned any older AppStack (it didn't matter which one) to the same VM/user, the issue came back.  Knowing this I did another test which was to update an older AppStack but not make any changes, but simply update and and re-save it.  That also fixed the issue.  No idea why and VMware wasn't sure either, but I've gone through our popular AppStacks and updated and re-saved them.  This also seems to have fixed some slowness issues we have been seeing, too.

I thought the issue was related to a Writable Volume but it appears it was something with our AppStacks and re-saving them with the newer 2.14 agent seems to be doing something to them to fix the problem.

Thank you again, hope this helps anybody else that sees this same issue.

View solution in original post

5 Replies
sjesse
Leadership
Leadership

Have you tested disabling the writable volume? I'm not on this version and I'm planning on going here soon .

0 Kudos
szilagyic
Hot Shot
Hot Shot

Have you tested disabling the writable volume? I'm not on this version and I'm planning on going here soon .

Yes it works fine without a Writable Volume attached.

0 Kudos
gpenunuri
Enthusiast
Enthusiast

I'm running the same versions and do not have that problem.  I did however have a similar issue with Visio and Project doing the configuring every time it was launched.  I corrected it on the master image but I also had to delete the users writable profiles for the issue to go away. 

0 Kudos
solgaeDK
Hot Shot
Hot Shot

There is, in fact, a Microsoft KB article about this:

https://support.microsoft.com/en-us/help/2643974/please-wait-while-windows-configures-microsoft-offi...

The article lists Outlook 2013, but I've seen it happening on 2016 as well. The same solution works on both versions. Basically, you need to either enable Windows Search (which is doable since you have writable volumes in place), or place a registry key to make Windows Search stop indexing Outlook items.

0 Kudos
szilagyic
Hot Shot
Hot Shot

Thank you for all of the feedback.  I ended up opening a ticket with VMware.  They had me test with an empty AppStack , with a user that already had a Writable Volume, and that did not cause the issue to happen.  Since we have Office installed on our master image, we were able to test it with the new empty AppStack and as soon as I assigned any older AppStack (it didn't matter which one) to the same VM/user, the issue came back.  Knowing this I did another test which was to update an older AppStack but not make any changes, but simply update and and re-save it.  That also fixed the issue.  No idea why and VMware wasn't sure either, but I've gone through our popular AppStacks and updated and re-saved them.  This also seems to have fixed some slowness issues we have been seeing, too.

I thought the issue was related to a Writable Volume but it appears it was something with our AppStacks and re-saving them with the newer 2.14 agent seems to be doing something to them to fix the problem.

Thank you again, hope this helps anybody else that sees this same issue.

View solution in original post