VMware Horizon Community
szilagyic
Hot Shot
Hot Shot
Jump to solution

Office 2016 (O365) and Writable Volumes, constant application crashing

We've had an issue trying to get Office 2016 working with our non-persistent desktop pools, it's never worked and we are putting many hours in trying to get it working.  Basically, it appears that when using a Writable Volume with Office 2016 click-to-run, the Office applications will work for a period of time then all of a sudden will crash and will no longer run at all.  We have Office installed directly on our golden master image, we are not deploying it within an AppStack.  The fix is to re-create the Writable Volume and it will work again but that is only temporary.  When it does work, it will be fine for anywhere from 2 hours, to 2 weeks, and suddenly one of the Office apps will crash and causes the rest of the apps to no longer launch.  When trying to launch any of them, we get the error "something went wrong".

Has anybody been able to get Office 365 working with Writable Volumes?  And how did you do it?  So far, we've done the following, which has not helped:

- Upgraded to App Volumes 2.12


- Installed Office 2016 with these options (must be done with floating desktop pools):

   <Display Level="None" AcceptEULA="TRUE" />

   <Property Name="SharedComputerLicensing" Value="1" />

- Checked Windows event logs, so far nothing helpful there at all indicating what the issue could be


- Updated the AppVol Writable Volume snapvol.cfg for Office 365, (per the VMware KB on this) :

################################################################
# Office 365 Virtual Registry exclusions
################################################################

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY


- Delete and re-create the Writable Volume


- Removed all AppStacks from the test VM, so the only thing that AppVol brings in is the Writable Volume and that's it

After doing all of the above, the issue still persists. 

We appreciate any and all feedback and help.  I currently have a ticket open with VMware on this as well, we are trying various steps but so far none of them are helping either.

0 Kudos
1 Solution

Accepted Solutions
szilagyic
Hot Shot
Hot Shot
Jump to solution

I believe we have a permanent solution to this issue.  We've found that if we revert snapvol.cfg back to the default provided with AppVol 2.12, and apply the two GPOs (part of the Office 2016 ADMX templates) below, it completely stops the ClickToRun functionality from trying to constantly autoupdate, and in return fixes the issues we were having with ClickToRun and the Writables. 

"Enable Automatic Updates" = Disabled

"Hide option to enable or disable updates" = Enabled

I was still a little nervous about the GPOs not applying or ClickToRun enabling itself again, so I have used the following custom lines in our snapvol.cfg as a precaution.  This has gotten everything to work here, including additional Office 2013 Appstacks.

exclude_path=\Program Files (x86)\Microsoft Office\PackageManifests

exclude_path=\Program Files (x86)\Microsoft Office\root

exclude_path=\Program Files (x86)\Microsoft Office\AppXManifest.xml

exclude_path=\Program Files (x86)\Microsoft Office\Updates

exclude_path=\Program Files\Common Files\Microsoft Shared\ClickToRun

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY

Hope this helps others in the same situation.

Our VMware ticket is in archive now, but there wasn't a permanent solution provided from that side, this was something we fixed on our own.

--

Chris

View solution in original post

0 Kudos
7 Replies
szilagyic
Hot Shot
Hot Shot
Jump to solution

We have made a little headway on this.  We noticed that on VMs that have a Writable Volume, some process is updating c:\program files (x86)\microsoft office\root\office16\c2r32.dll as it is stamped with the current date/time but the file is 0 bytes.  Then, on VMs without Writable Volumes, this same file is a symbolic link instead, pointing to : c:\program files\common files\microsoft shared\clicktorun\c2r32.dll.  This is very strange so I have tried to exclude the above directories from AppVolumes in snapvol.cfg.  I applied this change... so now after a while, when running an Office application, now we get a different error : "Microsoft Office can't find your license for this application...".   If the user logs out of their session, and logs back in, it will pick a different VM in the pool and the apps will work again, for a while.

This is what I put in the snapvol.cfg file so far (in addition to the registry fix above from the VMware KB article:

################################################################

# Office 365 Filesystem exclusions

################################################################

exclude_path=\Program Files (x86)\Microsoft Office

exclude_path=\Program Files\Common Files\Microsoft Shared\ClickToRun

There has to be a way to get Office and App Volumes to work together.  Any help would be greatly appreciated.

0 Kudos
jrp1
Contributor
Contributor
Jump to solution

Our setup is very similar to yours and so far I haven't had any issues although it's a relatively new environment.  Horizon View 7.0.3 with App Volumes 2.12.  VMs are non-persistent with Writable Volumes attached.  Office 2016 is in shared activation mode installed on the gold image.  I did run into issues with activation until I downloaded the current release version of 2016 (add the line Channel="Current" to the xml file before downloading using the OCT).  I followed instructions here: Reference: Configuration options for the Office Deployment Tool.


To persist activation between sessions, I used a combination of Writable Volumes and UEM to roam the folder and file locations used by Office for activation.  The file locations are at the end of this article: Reset Office 365 ProPlus 2013 and/or 2016 activation state – Office Deployment Support Team Blog‌.

0 Kudos
TDJB3
Enthusiast
Enthusiast
Jump to solution

Windows 7 SP1 App Volumes 2.12  View 7

We had a similar problem and resolved it with VMware's help.  We went from placing O365 on the template to creating an AppStack.

For Office 2013, We had to use a registry line to two places.  One line was added to the snapvol.cfg on the AppStack and the other to the snapvol.cfg writeable disk.  This was necessary for O365 2013.

The line that we used is

################################################################

# Office 365 Virtual Registry exclusions

################################################################

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Office\15.0\ClickToRun\REGISTRY.


I just added it to the bottom of the config file. C:\snapvolumestemp\MountPoints\GUID\snapvol.cfg for the AppStack. 

I have not changed the template for a writeable disk, but I changed my own to prove this out.  I added the same line.  To make the change, I had to go into Disk Management to assign a drive letter to the writeable disk.


We did decide to move to O365 2016 and it was not necessary for us to change the writeable disk template.  We put this line in for O365 2016

################################################################

# Office 365 Virtual Registry exclusions

################################################################

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Office\15.0\ClickToRun\REGISTRY.


We also used the recipe that was provided in this discussion.


I hope that this helps.


0 Kudos
szilagyic
Hot Shot
Hot Shot
Jump to solution

Thanks for the replies.  Good news is our fixes have been working for over a month in regards to Writable Volumes and Office 2016 clicktorun.  However now we are not able to deploy any Office 2013 Standard Visio or Project Appstacks.  I have a VMware ticket open right now and when blocking the path "c:\program files (x86)\microsoft office" in snapvol.cfg for Writable Volumes, it also prevents the AppStack from deploying properly as well.  So we are continuing to try and find out exactly what we need on snapvol.cfg to get the Writable Volumes working as well as Appstacks for Project and Visio.  I will post back what we end up finding to work, problem is it's taking a very long time and VMware does not have a definite answer at this point on a working snapvol.cfg.

0 Kudos
Raymond_W
VMware Employee
VMware Employee
Jump to solution

Can you please let me know the ticket number ?

Thanks Raymond

Kind regards, Raymond Twitter: @raymond_himself
0 Kudos
szilagyic
Hot Shot
Hot Shot
Jump to solution

Sure, it is 16322884712.

0 Kudos
szilagyic
Hot Shot
Hot Shot
Jump to solution

I believe we have a permanent solution to this issue.  We've found that if we revert snapvol.cfg back to the default provided with AppVol 2.12, and apply the two GPOs (part of the Office 2016 ADMX templates) below, it completely stops the ClickToRun functionality from trying to constantly autoupdate, and in return fixes the issues we were having with ClickToRun and the Writables. 

"Enable Automatic Updates" = Disabled

"Hide option to enable or disable updates" = Enabled

I was still a little nervous about the GPOs not applying or ClickToRun enabling itself again, so I have used the following custom lines in our snapvol.cfg as a precaution.  This has gotten everything to work here, including additional Office 2013 Appstacks.

exclude_path=\Program Files (x86)\Microsoft Office\PackageManifests

exclude_path=\Program Files (x86)\Microsoft Office\root

exclude_path=\Program Files (x86)\Microsoft Office\AppXManifest.xml

exclude_path=\Program Files (x86)\Microsoft Office\Updates

exclude_path=\Program Files\Common Files\Microsoft Shared\ClickToRun

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY

Hope this helps others in the same situation.

Our VMware ticket is in archive now, but there wasn't a permanent solution provided from that side, this was something we fixed on our own.

--

Chris

0 Kudos