I have a strange issue that I've been unable to solve for weeks now and hoping someone on here can help. The short version is I have Office 365 installed with Shared Computer Licensing enabled in the XML file on my gold image which is deployed to several pools. I also have persistent VDI's only in Vcenter direct connecting, not going through horizon. The horizon non persistent machines cannot activate office and get a token, but the persistents can no problem. I've done a lot of troubleshooting and research including a ticket with Microsoft and have narrowed it down to this. Microsoft is saying that on my horizon VDI's Office only gets as far as our on prem AD and not out to the internet to continue activation. Both non-persistent and persistent machines are on the same segments. What difference (firewall maybe?) is there when it comes to activating office while going through Horizon and Vcentre? Obviously more jumps are made when going through horizon then just direct connecting. I'm also pointing the tokens to a network share. Any ideas? Will supply anymore details you need.
Hi MarceTek
Are you saying your horizon VDIs are unable to reach to internet? If machine is able to reach internet, thats all horizon non persistent or persistent VM need to contact MS server and get a licensing token. Do you have specific error/screenshot when activation fails?
Yes Horizon VDI's can reach the internet, I've also confirmed with Microsoft and our Firewall team the correct URL's required for activation are allowed through. No errors, simply says "unlicensed" at the top of the office apps. The difference I noticed between a horizon VDI and just a Vcenter one is that when I open Office in Horizon VDI, I get prompted for my e-mail only, then nothing happens. On the Vcenter one I get prompted for my e-mail, then my password, and a third window saying "Use this account everywhere on your device" once I see those 2 extra windows I know Office will activate.
Make sure the follow the guidance in this document Best Practices for Delivering Microsoft Office 365 in VMware Horizon 7 | VMware
for the non-persistent Horizon desktops.
Hi MarceTek
Please check the horizon guide shared in previous post and other than that looking at the symptoms, it seems like your base image contains the licensing token somewhere. Please note once you install office365 on base image, you should never open Or try to activate it on base image. If by any chance you open it on base image, it may try to contact MS server and store licensing token locally which is not recommended in non-persistent environment.
Login to base image and go to the following folder:
%localappdata%\Microsoft\Office\16.0\Licensing
If you see some text files in the folder, it means your base image contains licensing token which might be the cause of the problem. In this case, you need to either reinstall O365 (making sure you never try open it after installation on base image) Or clean all local licensing tokens before creating VDIs out of it (Follow Reset Microsoft 365 Apps for enterprise activation state - Office | Microsoft Docs on base image).
I can confirm the licensing folder does not exist and Office was never opened on the gold image. In addition, I also excluded "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\" from the snapvol.cfg file for writable volumes. I just opened a ticket with VMware to see if they can assist. Microsoft wasn't able to figure it out either.
Hello,
What profile solution are we using here? [ DEM Or app volume profile wrtiable disk] ? Steps vary based on profile solutions.
Ideally, for a successful O365 deployment on non persistent VDI we need to have following pre-requisites:
=======================
On parent VM:
=======================
* On reg path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration add below reg keys:
REG_SZ: AutoActivate
Value: 1
REG_SZ: SharedComputerLicensing
Value: 1
* SCL[ Shared Computer Licensing ] by default places the token files on licensing folder under user local appdata will contain these two files. It is important to carry these files on to your next non persistent desktop.
* You can redirect redirect the SCL Token Cache to custom directory as well by using the following reg keys: [ Optional ] if you are already using roaming profiles and if this licensing folder is part of roaming then you ignore this step.
REG_SZ: sclcacheoverride
Value: 1
REG_SZ: sclcacheoverridedirectory
Value: <path of where you want to store the token license> example: %userprofile%\appdata\
=======================
On GPO:
=======================
* Create a batch file with below contents and use this batch file on logon scripts, [ This is to disable Modern Auth ]
cmd.exe /c reg add "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity" /v "DisableADALatopWAMOverride" /d "1" /f /t REG_DWORD
If you are using DEM then you may use the below config file:
[IncludeRegistryTrees]
HKCU\Software\Microsoft\Office\16.0\Common
HKCU\Software\Microsoft\Office\16.0\FirstRun
HKCU\Software\Microsoft\Office\16.0\Registration
HKCU\Software\Microsoft\Office\16.0\User Settings
HKCU\Software\Microsoft\Office\Common
HKCU\Software\Microsoft\Shared Tools\Proofing Tools
HKCU\Software\Microsoft\VBA
HKCU\Software\Microsoft\Internet Explorer\IntelliForms
[ExcludeRegistryTrees]
HKCU\Software\Microsoft\Office\Common\ClientTelemetry
HKCU\Software\Microsoft\Office\16.0\Common\Identity\DocToIdMapping
HKCU\Software\Microsoft\Office\16.0\Common\Identity\Identities
HKCU\Software\Microsoft\Office\16.0\Common\Identity\IdToAuthorityUrlMapping
HKCU\Software\Microsoft\Office\16.0\Common\Identity\Profiles
[IncludeFolderTrees]
<AppData>\Microsoft\AddIns
<AppData>\Microsoft\Bibliography
<AppData>\Microsoft\Office
<AppData>\Microsoft\Proof
<AppData>\Microsoft\Spelling
<AppData>\Microsoft\UProof
<AppData>\Microsoft\Templates
<AppData>\Microsoft\Credentials
<LocalAppData>\Microsoft\Credentials
<LocalAppData>Microsoft\Office\16.0\Licensing
Hello,
I am using writable volumes at the moment as DEM is not setup yet in our environment. I am excluding the HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity key in the snapvol.cfg file. The XML file for the Office install is using the following,
REG_SZ: AutoActivate
Value: 1
REG_SZ: SharedComputerLicensing
Value: 1
REG_SZ: sclcacheoverride
Value: 1
REG_SZ: sclcacheoverridedirectory
Value: <network folder location>
The only thing I haven't tried from your suggestion setting the below key. Since I'm excluding the identity string anyway that shouldn't matter correct?
DisableADALatopWAMOverride
When I log onto persistent VDI's the tokens generate as expected to the shared network location. The critical step that's failing is after I get prompted for my e-mail address nothing happens on the non persistents so whatever that step should be is not happening.
I have a question about your DEM config file. Is that different than the ones that are built into DEM? Because DEM has a pre-made config for each Office app individually, but not Office as a whole. Does your config cover all of Office 365?
I'm not using DEM at the moment, we are only using writable volumes. Which I'm starting to believe is the root of the issue. Writable volumes are the main difference between the non-persistents and persistents. I also tried making an appstack for Office vs having it in the gold image. Is there a recommendation for that? Should O365 be in the gold image? Or Appstack along with writable volume. Having O365 as an appstack is not working either, I even tried activating it while provisioning but that didn't work. I feel I'm close to getting this resolved, but I'm missing something. Any other ideas?
Hello,
This solution also would work in RDS Sessions-Hosts based architecture?
Thanks