When you deploy and install Microsoft Office 365 to a VDI environment, especially with non-persistent VDI (such as VMware Horizon Instant clones), special considerations must be followed.
In this guide I will teach you how to deploy Office 365 in a VDI environment, both with persistent and non-persistent (Instant Clones) VDI Virtual Machines. This guide was built using VMware Horizon, however applies to all VDI deployments including Citrix XenServer and WVD (Windows Virtual Desktops). Additionally this works on both Windows 10, and Windows 11.
By the time you’re done reading this guide, you’ll be able to fully deploy Office 365 to your VDI environment.
I highly recommend reading Microsoft’s Overview of shared computer activation for Microsoft 365 apps.
Guide Index
- Requirements
- Licensing
- What is Shared Computer Activation (SCA)
- Deploying and Installing Office 365 to the VDI Environment
- Configuring Microsoft Office 365 for the VDI Environment
- Deploying the Base Image
What’s required
To deploy Office 365 in a VDI Environment, you’ll need:
- VMware Horizon deployment (or equivalent other product)
- Microsoft Office 365 ProPlus licensing (See below for specifics on licensing)
- Microsoft Azure SSO (via PRT or Seamless SSO) for Microsoft 365 and Office 365 Single sign-on
- Microsoft Office Deployment Tool (Available here)
- Microsoft Office Customization Tool (Available here)
- Microsoft Office 365 GPO ADMX Templates (Available here)
- Roaming Profiles or Profile Management software (like FSLogix)
Licensing
In order to properly use Shared Computer Activation with Office 365 in your VDI environment you’ll need one of the following products:
- Microsoft 365 Apps for Enterprise (formerly known as Office 365 ProPlus)
- Office 365 E3
- Office 365 E5
- Microsoft 365 Business Premium
All 4 of these products include and support “Shared Computer Activation“.
Microsoft 365 Standard, Office 365 Business, Office 365 Business Premium, and Office 365 Business Essentials cannot be used as they do not include or support Shared Computer Activation.
An exception is made for Microsoft 365 Business Premium which actually includes Microsoft 365 Apps for Business, but doesn’t support enabling “Shared Computer Activation” via Group Policy Object and SCA must be enabled using the XML configuration file method.
What is Shared Computer Activation (SCA)
Shared computer activation is an optional activation method built inside of Office 365 and Microsoft 365, designed to control and manage activations on shared computers. Originally this technology was used for Office 365 on RDS (Remote Desktop Servers) to handle multiple users since Office 365 is activated and licensed per user.
Later, this technology was modified to handle Office 365 activations in non-persistent VDI environments. When utilizing SCA (Shared Computer Activation), when a user runs and activates Office 365, an activation token is generated and saved. These activation tokens are saved to a network location that the users has access to which allows the user to roam.
Due to the nature of non-persistent VDI, a user will always be logging in to a system they have never logged in to before. When Office 365 is deployed properly, it will call out to and look for the roaming activation token to automatically activate Office 365 without calling out to Microsoft’s servers.
This is also handy with persistent VDI, where you can have a roaming activation token be used on multiple desktop pools as it follows the users.
These activation tokens once generated are valid for 30 days and remove the need to activate Office during that timeframe. As expiration nears, Office will automatically reach out to Microsoft’s servers and attempt to renew the licensing activation token.
You’ll want to make sure that you have implemented Azure AD Connect and SSO (Single Sign-On) properly along with the correct GPOs (covered later in this post) for auto-activation to function without prompting users to sign-in to activate. For more information, check out my post on Understanding Microsoft Azure AD SSO with VDI.
If you have not using SCA, you’ll need to follow additional special steps to have roaming profiles include the licensing directory, however I do not recommend using that method. The licensing information (and activation) without SCA is stored in the following directory:
%localappdata%\Microsoft\Office\16.0\LicensingYou can configure Shared Computer Activation and the location of the roaming activation token using Group Policy, the local registry, or the configuration.xml file for the Office Deployment Tool.
Shared Computer Activation is ONLY required for non-persistent VDI. If you are using persistent VDI where users are assigned a desktop they are frequently using, shared computer activation is not necessary and does not need to be used.
Even though Shared Computer Activation is not required for persistent desktops, I might still recommend using it if you have users using multiple desktop pools, or you’re regularly changing your persistent desktop golden image and refreshing the environment.
Later in the document, we’ll cover configuring Share Computer Activation.
Deploying and Installing Office 365 to the VDI Environment
The steps to deploy and install Office 365 to VDI vary depending if you’re using persistent or non-persistent VDI. In both types of deployments you’ll want to make sure that you use the Office Deployment Tool which uses an XML file for configuration to deploy the application suite.
You can either modify and edit the Office 365 configuration.xml file manually or you can use the “Office Customization Tool” available at: https://config.office.com/
Office Deployment Tool and Office Customization Tool
Using the Office Deployment Tool and the Office Customization Tool, you can customize your Office 365 installation to your specific needs and requirements.
Using the tool, you can create a configuration.xml and control settings like the following:
- Architecture (32-bit or 64-bit)
- Products to install (Office Suites, Visio, Project, and additional products)
- Products to exclude
- Update Channel
- Language Settings and Language Packs
- Installation Options (Installation Source and configurable items)
- Upgrade Options
- Licensing and Activation (EULA acceptance, KMS/MAK, User based vs Shared Computer Activation vs Device Activation)
- Application Preferences
Once you have a configuration.xml file from the Office Customization Tool, you can use the Office Deployment Tool to deploy and install Office 365 using those customizations and configuration.
The configurations you use will vary depending on your VDI deployment type which I will get in to below.
Installing Office 365 with Persistent VDI
To deploy Office 365 with persistent VDI, Shared Computer Activation is not required.
You will however, want to use the Office Deployment Tool to prepare the base image for automated pools, or manually install Office 365 in to the VDI Virtual Machine.
See below for the instructions on Installing Office 365 on Persistent VDI:
- First you’ll need to download the Office Deployment Tool from this link: https://go.microsoft.com/fwlink/p/?LinkID=626065. You save this wherever.
- Create a directory that you can work in and store the Office 365 installation files.
- Open the file you downloaded from the Microsoft Download site, extract the files in to the working directory you created in step 2.
- Open a Command Prompt, and change in to that working directory.
- You can either use the included XML files as is (for default settings), modify them manually, or use the Office ustomization Tool.
- If you want to use SCA (Shared Computer Activation) make sure the following lines are added to the file right above the final line (right above):
<Display Level="None" AcceptEULA="True" />
These variables enable Shared Computer Activation and disable automatic activation. Save the XML file.
<Property Name="SharedComputerLicensing" Value="1" /> - We’re now going to run the tool and download the Office installation files using the xml from above by running the following command (if you modified the XML file and/or changed the filename, use the filename you saved it as):
setup.exe /download configuration.xml
- There will be no output and it will take a while so be patient.
- We can now install Office 365 using your XML configuration by running the following command (if you modified the XML file and/or changed the filename, use the filename you saved it as):
setup.exe /configure configuration.xml
Office 365 should now install silently, and then afterwards you should be good to go!
If you did not use SCA, the product will need to be activated manually or automatically via GPO.
If you did use SCA, you’ll want to use the GPOs to configure first-run activation, as well as the location of the roaming activation tokens.
In both scenarios above, after installation is successful you’ll want to configure Office 365 for VDI.
Please note: With persistent VDI, you’ll want to make sure that you leave the Office 365 updating mechanism enabled as these VMs will not be destroyed on logoff. The behavior will match that of a typical workstation as far as software updates are concerned.
Even if you are using persistent VDI, I highly recommend you read the notes below on installing Office 365 on non-persistent VDI as you may want to incorporate that configuration in to your deployment.
Installing Office 365 with Non-Persistent (Instant Clones) VDI
To deploy Office 365 with non-persistent VDI, things are a little different than with persistent. Shared Computer Activation is recommended and required if you’re not using profile capture software like FSLogix. You can however still use SCA with FSLogix.
We’ll use the Office Deployment Tool to prepare the base image. Using the tool, we’ll want to make sure we exclude the following applications from the XML file:
- Microsoft Teams
- OneDrive
Using the Office 365 installer for the above products will cause issues as the software gets installed in the user profile instead of the operating system itself.
These applications have their own separate special “All User” installation MSI files that we need to use to install to the base image.
We’ll use the Office Customization Tool (OCT) at https://config.office.com/ to create a configuration XML file for our Non-Persistent Office 365 deployment.
Below is an example of the XML file generated from the Office Customization Tool for Instant Clones (Non-Persistent VDI) Virtual Machines:
<Configuration ID="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX">
<Add OfficeClientEdition="64" Channel="Current">
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="Lync" />
<ExcludeApp ID="OneDrive" />
<ExcludeApp ID="Publisher" />
<ExcludeApp ID="Teams" />
<ExcludeApp ID="Bing" />
</Product>
</Add>
<Property Name="SharedComputerLicensing" Value="1" />
<Property Name="SCLCacheOverride" Value="0" />
<Property Name="FORCEAPPSHUTDOWN" Value="FALSE" />
<Property Name="DeviceBasedLicensing" Value="0" />
<Updates Enabled="FALSE" />
<Display Level="None" AcceptEULA="TRUE" />
</Configuration>You’ll notice I chose not to include Groove, Lync, Publisher, and Bing Search. This is because these are not used in my environment. I’d recommend excluding applications you don’t require in your base image.
You’ll also notice that I chose to disable Office 365 updates as these get managed and handled inside of the base image and we don’t want the instant clones attempting to update Office as the VMs are deleted on logoff. We also choose to accept the EULA for users so they are not prompted.
After we have our configuration XML file, we’ll proceed to installing Office 365 on the non-persistent base image:
- Create a directory that you can work in and store the Office 365 installation files.
- Open the file you downloaded from the Office Deployment Tool on the Microsoft Download site, extract the files in to the working directory you created in step 2.
- Copy the XML file created above from the Office Customization Tool in to this directory.
- Open a Command Prompt, and change in to that working directory.
- Confirm that SCA (Shared Computer Activation) is enabled by viewing the XML configuration file. You should see the following text:
<Display Level="None" AcceptEULA="True" />
<Property Name="SharedComputerLicensing" Value="1" /> - We’re now going to run the tool and download the Office installation files using the xml from above by running the following command:
setup.exe /download non-persistentVDI.xml
- There will be no output and it will take a while so be patient.
- We can now install Office 365 using your XML configuration by running the following command:
setup.exe /configure non-persistentVDI.xml
Office 365 should now install silently.
For the skipped applications (Teams, OneDrive) we’ll install these applications separately. Go ahead and download the MSI installers from below and follow the instructions below:
Installers:
- Microsoft Classic Teams – MSI Download: 64-Bit, 32-Bit
- Microsoft New Teams – Bootstrapper Download
- OneDrive – EXE Download: x86/64
Installing Microsoft Teams on VDI
At present there is the old Classic teams client, and the new Microsoft Teams client, which both support VDI installation.
Classic Teams is going End of Support June 30th 2024. I highly recommend deploying New teams for New VDI deployments and/or desktop pools.
See below for a summary, and further down links to more details blog posts which I have created.
Installing Microsoft Classic Teams for VDI
To Install the Classic Microsoft Teams on non-persistent VDI using the MSI file above, run the following command on the base image:
msiexec /i C:\Location\Teams_windows_x64.msi ALLUSER=1 ALLUSERS=1Using this method will install for all users in per-machine mode, and will also disable auto-updates for non-persistent environments.
Installing New Microsoft Teams for VDI
To install the new Microsoft Teams client on non-persistent VDI using the New Teams Bootstrapper, run the following command on the base image:
teamsbootstrapper.exe -pAdditionally, navigate to the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TeamsAnd create a new DWORD called “disableAutoUpdate” and set to a value of “1”, which will disable auto-updates for non persistent VDI images.
For more information and detailed guides, please see the following:
Installing OneDrive on VDI
Microsoft has a guide on how to install the OneDrive Sync app per machine (for use with non-persistent VDI).
To install Microsoft OneDrive on non-persistent VDI using the EXE file above, run the following command on the base image:
OneDriveSetup.exe /allusersAfter installing, open the Windows Task Scheduler and disable the following OneDrive update task:
OneDrive Per-Machine Standalone Update TaskAdditionally, open the Windows services and disable the OneDrive update service:
OneDrive Updater ServiceUpdating Office 365 in a VDI Environment
In persistent VDI environments, the auto-update mechanism will be enabled and activated (unless you chose to disable it), and Office will update as it does with normal windows instances. You can modify and/or control this behavior using the Microsoft Office ADMX Templates and Group Policy.
In non-persistent VDI environments the updating mechanism will be disabled (as per the XML configuration example above). To update the base image you’ll need to run the “setup.exe” again with the “download” and “configure” switch, so make sure you keep your configuration XML file.
Here is an example of the Office 365 Update process on a non-persistent VDI base image. We run the following commands on the base image to update Office 365:
setup.exe /download non-persistentVDI.xml
setup.exe /configure non-persistentVDI.xml
The commands above will download and install the most up to date version of Office 365 using the channel specified in the XML file. You then deploy the updated base image.
Configuring Microsoft Office 365 for the VDI Environment
Once Office 365 is installed in the base image (or VM), we can begin configuring Office 365 for the VDI environment.
To configure and centrally manage your O365 deployment, we’ll want to use GPOs (Group Policy Objects). This will allow us to configure everything including “first run configuration” and roll out a standardized configuration to users using both persistent and non-persistent VDI.
In order to modify GPOs, you’ll need to either launch the Group Policy Management MMC from a domain controller, or Install RSAT (Remote Server Administration Tools) on Windows 10 to use the MMC from your local computer or workstation.
You’ll probably want to create an OU (Organizational Unit) if you haven’t already for your VDI VMs (separate for persistent and non-persistent VDI) inside of Active Directory, and then create a new Group Policy Object and apply it to that OU. In that new GPO, we’ll be configuring the following:
We’ll be configuring the following “Computer Configuration” items:
- Microsoft Office – Licensing Configuration
- Microsoft Office – Update Configuration
- Microsoft OneDrive – Known Folders, Use OneDrive Files On-Demand
- Windows – Group Policy Loopback Processing Mode
We’ll also be configuring the following “User Configuration” items:
- Microsoft Office – First Run Configuration
- Microsoft Office – Block Personal Microsoft Account Sign-in
- Microsoft Office – Subscription/Licensing Activation
- Microsoft Outlook – Disable E-Mail Account Configuration
- Microsoft Outlook – Exchange account profile configuration
- Microsoft Outlook – Disable Cached Exchange Mode
Below we’ll cover the configuration
We’ll start with the Computer Configuration Items.
Microsoft Office – Licensing Configuration
If you’re using SCA (Shared Computer Activation) for licensing, we need to specify where to store the users activation tokens. You may have configured a special location for these, or may just store them with your user profiles.
First we need to enable Shared Computer Activation. Navigate to:
Computer Configuration -> Policies -> Administrative Templates -> Microsoft Office 2016 (Machine) -> Licensing SettingsAnd set “Use shared computer activation” to Enabled.
If you’re using FSLogix and redirecting the profile to a VHD file, you don’t need to perform the steps below. If you’re not using FSLogix and are not using a profile redirection mechanism, we’ll need to set “Specify the location to save the licensing token used by shared computer activation”. We’ll set this to the location where you’d like to store the roaming activation tokens. As an example, to store to the roaming User Profile share, I’d set it to the following:
\\PROFILE-SERVER\UserProfiles$\%USERNAME%Microsoft Office – Update Configuration
If you’re usBecause this is a VDI environment, we want automatic updating disabled since IT will manage the updates.
We’ll want to disable updated by navigating to:
Computer Configuration -> Policies -> Administrative Templates -> Microsoft Office 2016 (Machine) -> UpdatesAnd set “Enable Automatic Updates” to Disabled.
We’ll also set “Hide option to enable or disable updates” to Enabled to hide it from the users.
Microsoft OneDrive – Known Folders, Use OneDrive Files On-Demand
There’s some basic configuration for OneDrive that we’ll want to configure as we don’t want our users profile folders being copied or redirected to OneDrive. We also want OneDrive to be used with Files On-Demand so that users OneDrive contents aren’t cached/copied to the VDI user profiles.
This configuration is ONLY if you are using OneDrive and/or have it installed.
We’ll navigate over to:
Computer Configuration -> Policies -> Administrative Templates -> OneDriveAnd set the following GPO objects:
- “Prevent users from moving their Windows known folders to OneDrive” to Enabled
- “Prevent users from redirecting their Windows known folders to their PC” to Enabled
- “Prompt users to move Windows known folders to OneDrive” to Disabled
- “Silently move Windows known folders to OneDrive” to “Disabled”
- “Silently sign in users to the OneDrive sync app with their Windows credentials” to “Enabled”
- “Use OneDrive Files On-Demand” to Enabled
We’ve new configured OneDrive for VDI Users.
Windows – Group Policy Loopback Processing Mode
Since we’ll be applying the above “Computer Configuration” GPO settings to users when they log on to the non-persistent Instant Clone VDI VMs, we’ll need to activate Loopback Processing of Group Policy (click the link for more information). This will allow use to have the “Computer Configuration” applied during User Logon and have higher precedence over their existing User Settings.
We’ll navigate to the following:
Computer Configuration -> Policies -> Administrative Templates -> System -> Group PolicyAnd set “Configure user Group Policy loopback processing mode” to Enabled, and “Mode” to Merge.
We’ve fully configured the Computer Configuration in the GPO. We will now configure the User Configuration items.
Microsoft Office – First Run Configuration
As most of you know, when running Microsoft Office 365 for the first time, there are numerous windows, movies, and wizards for the first time run. We want to disable all of this so it appears that Office is pre-configured to the user, this will allow them to just log on and start working.
We’ll head over to:
User Configuration -> Policies -> Administrative Templates -> Microsoft Office 2016 -> First RunAnd set the following items:
- “Disable First Run Movie” to Enabled
- “Disable Office First Run on application boot” to Enabled
Microsoft Office – Block Personal Microsoft Account Sign-in
Since we’re paying for and want the user to use their Microsoft 365 account and not their personal M365/O365 accounts, we’ll stop them from being able to add personal Microsoft Accounts to Office 365.
Head over to:
User Configuration -> Policies -> Administrative Templates -> Microsoft Office 2016 -> MiscellaneousAnd set “Block signing into Office” to Enabled, and then set the additional option to “Organization ID only”
Microsoft Office – Subscription/Licensing Activation
We don’t want the activation window being shown to the user, nor the requirement for it to be configured, so we’ll configure Office 365 to automatically activate using SSO (Single Sign On).
Navigate to:
User Configuration -> Policies -> Administrative Templates -> Microsoft Office 2016 -> Subscription ActivationAnd then set “Automatically activate Office with federated organization credentials” to Enabled.
This will automatically activate Office 365 for the VDI user.
Microsoft Outlook – Disable E-Mail Account Configuration
We’ll be configuring the e-mail profiles for the users so that no initial configuration will be needed. Again, just another step to let them log in and get to work right away.
Inside of:
User Configuration -> Policies -> Administrative Templates -> Microsoft Outlook 2016 -> Account Settings -> E-mailAnd we’ll set the following:
- “Prevent Office 365 E-mail accounts from being configured within a simplified Interface” to Disabled
- “Prevent Outlook from interacting with the account settings detection service” to Enabled
Microsoft Outlook – Exchange account profile configuration
When using Exchange, we’ll want your users Outlook Profile to be auto-configured for their Exchange account so we’ll need to configure the following setting.
Navigate to:
User Configuration -> Policies -> Administrative Templates -> Microsoft Outlook 2016 -> Account Settings -> ExchangeAnd set “Automatically configure profile based on Active Directory Primary SMTP address” to Enabled.
After setting this, it will automatically add the Exchange Account when they open Outlook and they’ll be ready to go! Note, that there is an additional setting with a similar name appended with “One time Only”. Using the One time Only will not try to apply the configuration on all subsequent Outlook runs.
Microsoft Outlook – Disable Cached Exchange Mode
If you’re using persistent VDI, hosted exchange, or FSLogix, you won’t want to configure this item.
When using on-premise Exchange with VDI, we don’t want users cached Outlook mailboxes (OST files) stored on the roaming profile, or the Instant Clone. We can stop this by disabling Exchange caching.
Navigate to:
User Configuration -> Policies -> Administrative Templates -> Microsoft Outlook 2016 -> Account Settings -> Exchange -> Cached Exchange ModeAnd we’ll set the two following settings:
- “Cached Exchange Mode (File | Cached Exchange Mode)” to Disabled
- “Use Cached Exchange Mode for new and existing Outlook profiles” to Disabled
This will configure Exchange to run in “Online Mode”.
Microsoft Office Common Identity Registry – For Roaming Profiles
If you’re using Roaming profiles and folder redirection with non-persistent VDI and instant clones, the user may be prompted repeatedly on new logins to log in to their Office 365 account (with a login prompt) even though SCA is configured and working. This setting is not required when using FSLogix.
When troubleshooting this, one may think that the issue is related to SCA, when it is actually not. This prompt is occurring because of authentication issues with Office 365.
To correct this issue, we’ll need to add a registry configuration to the GPO that will delete a key on login.
User Configuration -> Preferences -> Windows Settings -> RegistryWe’ll create a new registry GPO item, that will “delete” the key path below inside of “HKEY_CURRENT_USER”:
SOFTWARE\Microsoft\Office\16.0\Common\IdentityThis will delete the Identity key on login, and allow Office 365 to function. This may not be needed if using FSLogix or other profile management suites.
Deploying the Base Image
At this point you can push and deploy the base image and have users log in to the VDI environment and Office 365 should be fully functioning.
Please keep in mind there are different methods for deploying and configuring Office 365 depending on what application delivery and profile management software you may be using. This is just a guide to get you started!
[…] This information is applies to when you want to install Office 365 / Microsoft 365 to a shared virtual machine, or a golden image for VDI (for VDI you can read my full guide “Deploy, Install, and Configure Microsoft Office 365 in a VDI Environment“). […]
Great post! Have you figured out first-run SSO for Teams machine wide installations? New users will have their username filled in when Teams opens but they still need to hit Connect and enter their password (and MFA code if enabled) one time for Teams to stay signed in. 365 apps for enterprise work 100% following this guide
Hey Mike,
Glad to hear the post worked for you!
For the SSO first run for Teams, I can’t recall if it prompted or not. I think with roaming profiles it only occurred once, and then worked normally after that.
I need to update my homelab environment, so I’ll check it out soon and if it requires extra work, I’ll update the post.
Cheers,
Stephen
[…] Deploy, Install, and Configure Microsoft Office 365 in a VDI Environment […]
365 apps are not reporting device ID or Join type to azure. They’re using rich client browser and failing our CA policy that requires hybrid azure devices.
Tried to delete identity from regedit ,but no good. Cleared cached credentials no good.
SSO works for onedrive(which reports internet explorer as browser) and when using traditional desktop browsers Chrome/Edge.
Any idea what it might be ?
This guide was amazing for our transition to Microsoft 365 in our VDI environment. Put this into production and our users didn’t notice anything. In fact, it’s actually a better experience than what they had before. Amazing guides, keep it up!
Awesome! I’m glad it helped TJ!
Great article, good info.
What are your thoughts on stacking Visio into O365 with App Volumes?
I find I have to “re-install” all of O365 and Add Visio (Same config xml, just add the visio section) in the App Volumes App stack.
Any other way blows up licensing.
Thanks Aaron!
How do you have the existing O365 suite installed? Do you have it baked in the image, or are you using App Volumes? I could be wrong (I haven’t had to deploy Visio yet), but you should deploy Visio using the method you deployed O365 with, unless Microsoft supplies an additional installer for Visio (like they do for Microsoft Teams on VDI).
Cheers,
Stephen
I just want to compliment you for this super guide. It helped us a lot to implement Office 365 in our VDI environment. Many thanks from Heerenveen, Holland!
This is really good information and very helpful. The only thing I miss is SSO. Does SSO work in this setup for all Office apps, also Onedrive and Teams and do I need the non-persistent machine to be Hybrid joint to Azure AD.
Hi Vincent,
In my environment SSO is functioning 100% and working correctly. Make sure that you have AD configured properly in your environment with AD Connect.
Also, check the GPOs I’ve provided https://www.stephenwagner.com/2021/08/06/microsoft-office-365-vdi/#h-configuring-office365-VDI
Finally, Hybrid domain joining is not required, and I actually have it disabled for my instant clones (covered here: https://www.stephenwagner.com/2021/04/25/hybrid-azure-ad-non-persistent-vdi-instant-clones/)
Cheers,
Stephen
Hi Stephen,
Great guide…my setup is very close but for some reason my Office 365 isn’t activating. When you open an Office app it comes to the “sign in to setup office” prompt. If I choose to sign in, it says that’s disabled by administrator. If I cancel, of course it says it’s unlicensed and that shared license can’t be found. Any immediate thoughts?
Thanks,
Ramzi
Hey Ramzi,
Did you configure the GPOs as per what’s specified inside of this guide?
Also, do you have AD/AD Connect SSO all configured and working?
And finally, are you suing Office 365 apps for business/enterprise?
Cheers,
Stephen
I’ve upgraded my gold images from 1803 to 20H2 and office (word and excel) are going through the configuration on startup . I have disabled it in the GPO.
Any chance you have seen this before?
thanks!
Ellen
Hi Ellen,
Is there a chance that the new image you’re deploying isn’t part of the right OUs for the GPOs? Also, are your ADMX templates the latest version?
Cheers,
Stephen
my ADMX templates are NOT the latest version. any gotchas on updating them? Thanks!
Hi ellen,
It should be a fairly straightforward process to update these. Simply make sure you update both the ADMX files as well as the applicable language files.
Cheers,
Stephen
i haven’t downloaded the new ADMX templates for 20H2, any gotchas here? we do have the latest horizon ADMX templates.
thanks!
Hi ellen,
As for the Windows Client/Workstation ADMX files, I don’t think I’ve ever had any issues updating these. 🙂
Hi Stephen,
Thanks for this article, it is exactly what we are looking for.
2 questions, first on updates, you say “In non-persistent VDI environments the updating mechanism will be disabled (as per the XML configuration example above). To update the base image you’ll need to run the “setup.exe” again with the “download” and “configure” switch, so make sure you keep your configuration XML file.”
So the same config we used initially with the above switches would update the version of office to latest?
Secondly,
Do you use CDN for your installation deployment?
Regards,
K
Hi Kingsy,
Thanks for reaching out! To answer your questions:
1) Yes, hold on to that XML you created. You’ll keep this and keep using it with the “/download” and “/configure” switches to update your Office installation.
2) I do use the CDN. This allows me to download the latest version of Office in the release channel I’m using whenever I run those switches above to download and install the updates.
Cheers,
Stephen
Thanks for above reply 🙂
Another question, we will be running non persistent machines and your article reference to ‘users activation tokens’
We will be using shared activation, does the above simply login user and save some info in the profile/shared location? – does this info change every so often?
We use a profile management, so just wondering how it works
Thanks,
Regards,
K
Hi Kingsy,
In my example, I chose to store the roaming activation token in the user profile directory. You can store it here or you can create a share for the roaming activation tokens.
Also in the example above, I have used GPOs to automatically sign in to and activate the users Office 365 license. So yes, the user logs in and then it creates and stores the roaming activation token.
And yes, the token get’s updated on an interval (I don’t know what it is off the top of my head, it could be 30-90 days).
Using an profile/management software application would be very similar, SCA must be used.
Cheers,
Stephen
Good article with great insights. Still running into a few questionmarks though.
I’m running non-peristent Citrix Virtual Desktops, while trying to use Citrix ProfileManagement for the Non-O365-Parts and FsLogix for the Office365-Container part. Any known issues when using FsLogix on your experience?
After initial log-in, the users are prompted with Microsoft login prompts whenever they start an Office365-application, OneDrive or Teams. Outlook is even asking twice, apparently for authentication towards the Exchange and towards Office-Licensing. All GPOs are set up as described in your article and are processed by the cloned VMs! Any idea on why those prompts still show up?
On the FsLogix-GPO I enabled ‘Include Office activation data in container’, as mentioned in your Licensing-Configuration. Should I still configure a separate path for the roaming activation token?
Hi Stephen
I had the problem that the login window from the Office Apps did not appear. I was able to fix this with a logon script, but now people with MFA can no longer log in. Do you have any idea what this could be?
Kind regards,
Cédric
Hi Cédric,
That is proper behaviour, when configured properly, the users will not be required to log in (as it’s handled by GPOs, SSO, and SCA). No fix is required as this is the proper and best behaviour.
I’m not familiar with what you mean by “fix” or what you put in a login script as these aren’t required if configured properly. I don’t know why you’re running in to these issues without knowing more about the environment, what you put in your script, and other information.
Cheers,
Stephen
Hi Stephen
Thank you for the answer, I use this script to make the login work. When I do not use the script, the Office apps freezes in Horizon after requesting the mail address. I used this script from Microsoft for this:
https://docs.microsoft.com/en-us/office365/troubleshoot/authentication/automatic-authentication-fails
However, I have the problem with the script as it automatically tries to log me in that I don’t get an MFA prompt.
Kind regards,
Cédric
Hi Cédric,
I still don’t understand why you’re using that script as it’s not needed and is probably causing your issues.
Stephen
Hi
Thanks for this article. I have followed it step by step and have been very impressed with the results
We have also gone with the non managed route(jnot azure/hyrbrid joined) and had to make a slight change where we had to add a key
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin, “BlockAADWorkplaceJoin”=dword:00000001
The above was when opening Outlook, we were getting a prompt to have device managed by organisation
We have one issue, which is becoming a pain point. When a user logs in for first time, they are being prompted to login to activate. There are a few blogs saying this is the norm but according to the above we should be able to skip that
Can you advice what the delete of the identity reg key and make sure its not roaming with profile bit does, that is only thing we havent applied yet and think may sort our problem. The thing is that key appears when you start office app, so when you delete on login, dont know how that will help
Thanks,
King
Hi King,
Glad the post helped, and thanks for adding the bit about the “BlockAADWorkplaceJoin” as I forgot to add that! 🙂
For activation, as long as you configure the GPOs to auto-sign in using the users credentials, they should not be prompted. Also keep in mind that you need Azure AD SSO enabled for it to work.
The key is required for profile management so that it can sign-in and activate (instead of preparing a warning). The identity key has computer identity specific information in it, and when logging in with different computers it needs to generate new values. This key needs to be deleted on logon so that when Office is opened, it won’t try to use the old incorrect identity from a previous session.
Cheers,
Stephen
Hi Stephen,
Thanks for the above.
On your Non persistent VDI’s – have you added https://autologon.microsoftazuread-sso.com to the intranet zones?
Regards,
King
Hi King,
Adding that URL to the intranet sites in IE, is part of enabling Azure AD Seamless SSO. If your non-persistent is not hybrid Azure AD joined, then you’ll need Azure AD Seamless SSO in order for SSO to function.
Hi Stephen,
That is excellent, sorted our issues and we good to go! – That maybe a good link to add to article as had us banging our heads against the wall! 🙂
Thanks for the article – we have one final question. When opening Edge, going to office.com , it only asks for email and then logs user in for rest of session, is there anything in edge policies or anything we can take through which allow users to auto login to office without needing the email address?
Thanks
King
Glad to hear! 🙂
If the users UPN matches their e-mail, it should automatically sign in without prompting for an e-mail address.
If there’s two accounts (personal and business) associated with the same e-mail address, it may prompt asking which one you’d like to sign in to.
Thanks,
Do you have any other websites added to your trusted sites or intranet zone out of curiosity?
[…] you implement and use Microsoft 365 and Office 365 in a VDI environment, you should have your environment configured to handle Azure AD SSO for a seamless user experience, […]
Hi Stephen,
A bit off-topic, but here goes.
I’m currrently pushing this value:
Disable OneDrive as the default save location:
Name: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\General
Value Name: PreferCloudSaveLocations
Type: REG_DWORD
Data:
Directly to registry with a PowerShell script, which is added to Devices -> Scripts in the Microsoft Endpoint Manager admin center.
But will I be able to set the same value in the XML file, which I create with the Office Customization Tool?
It is okay, if I have to add the value manually to the XML fil before it is uploaded to Intune.
Hi Jesper,
I’m not quite sure of the answer to your question. Most of the configuration I do is via GPOs. You might have to reference the Microsoft documentation.
Cheers,
Stephen
Well done on this article; looking forward to leveraging it in our upcoming updates.
Hello,
Is O365 the only option to have Office apps in a non persistent VDI environment? I only need Word, PowerPoint, and Excel in my environment, no email. Thank you for this guide, it is the most complete one I can find for VDI.
Thanks,
Timothy
Hi Timothy,
Office 2021 LTSC was just recently released, which I believe should support licensing for a VDI environment, however you’ll need to confirm this.
And thanks for the feedback, I’m glad the guide helped!
Cheers,
Stephen
Great article! I have managed to get everything BUT Outlook to work. When I open Outlook I get a prompt to enter the password, username is populated already. I enter the password but it never takes it, just re-prompts. I tried to enter it manually and I just get errors. OWA works fine and SSO just opens.
Any thoughts?
Thanks Karl
[…] also have a guide on how to Deploy, Install, and Configure Microsoft Office 365 in a VDI Environment, so make sure you check it […]
Thanks for this article !
Excellent article, very helpful. Will be back for more as time goes on.
We moved to ms365 about a year ago. I used your article as the base of our configuration. We’ve had the lingering issue of being prompted to login to Teams each morning. We are using vmware vdi non-persistent desktops. We are moving to FSLogix and one of the particulars is to ensure that AppData\Local\Microsoft\IdentityCache is included. Upon further research I found that it is never created. I see online forums where others have the same issue, but no resolution. Thoughts?
Hi Craig,
If using FSLogix, no special configuration is required if all the integrations in your environment are functioning properly (Azure AD Connect, SSO, etc) and FSLogix is successfully implemented.
Thanks Stephen! Helped me figure out why Teams kept only installing for 1 user in my VDI environments
Just an FYI. I have done all of this and spent several hours now wated due to a code change on the latest version fo FSLogix.
https://learn.microsoft.com/en-us/fslogix/troubleshooting-known-issues
They basically removed token roaming from FSLogix. Reverting to the previous version resolved the issue.
Hi Daniel,
Inside of the “known issues” document, there’s nothing pertaining to activation tokens. However, there is a section on PRTs, which are SSO tokens. PRT tokens cannot be used with Instant Clones for Azure AD SSO unless you’re using ADFS. If you’re not using ADFS PRT’s on non-persistent VDI is not supported, and you must use something like seamless SSO.
Cheers,
Stephen
Hello Daniel,
we just ran across the same issue and thus would like to know which Version of FSLogix you did you to make it work.
Thank would be a great help as we would rather NOT use ADFS
I had an issue where O365 SSO logins worked fine but the OneDrive sync tool did not. Every time I logged out and in again, the app displayed a red “X” and I had to re-authenticate. When I installed 2.9.8228.50276, everything started working again.
Hello Stephen,
Thanks for the comprehensive instructions!
I’m wondering if anyone managed to install the O365 as published apps? Via RDSH Windows Server 2022? We constantly have a problem with activation, whenever we need to enter the password screen disappears and the application freezes.
We’ve been fighting this for days.
Thanx
Hi Stephen- Thanks so much for all of the work you’ve done on this! I have been fighting with a 365 activation issue for a long time and now and I have exhausted everything out there in terms of KB articles, blogs, forums and things to try. Registry, group policy, etc. I’ve done everything and none of it works.
Basically, every time the user logs out and back into their Citrix session, their Office apps show a triangle and error saying “Your account many not work until you sign in again.” The applications are mostly functional, though there some things that don’t quite work the way they are supposed to.
If you click Continue and sign in, it signs in just fine and works perfectly. However, when you log out and back in again for a new session, the same thing reappears. As previously stated, I’ve tried everything. Why is this happening and how can I fix it?
It sounds like the identity data is persisting over the VDI session. What profile management software are you using and have you configured it to omit the identity registry key? Also, are you using Azure AD SSO?
Great article. I haven’t followed every bit, but it helped me on the way to make M365 work in non-persistent Horizon VDI.
Something has changed since last two years. License token is actually stored in %localappdata%\Microsoft\Office\Licenses\ (it goes deeper, but i used this root folder and added to our UEM/DEM config for Office common.ini and it works, it preserves the SCA token and don’t have to use additional network location. We only redirect Desktop and Documents, not the full profile, so had to use UEM for that).
Another useful thing for me was to check whether SCA setting from GPO actually applied to VM. Because i first had to use separate test GPO and didn’t see inheritance was blocked, so it was not applying. To make sure need to check registry on VM for HKLM\Software\Policies\Microsoft\Office\16.0\Commom\Licensing – sharedcomputerlicensing (set to 1). Another way to see that SCA is enabled is to go to Office app and Account page. Instead of saying M365 subscription for user X it just says Microsoft.
So, my activation info is saved now and doesn’t prompt user to activate on new login to VDI. The only problem is warning icon showing near user avatar and there asking to fix account. It doesn’t show any prompts though. I see you have suggestion to delete registry for Identity. Not sure if that will work and make user to sign in correctly on login. Or maybe i just need to remove that registry from UEM config. Will experiment more.
Corretion. Looks like it was using %localappdata%\Microsoft\Office\Licenses\ before SCA was active on VM and now it stores tokens in %localappdata%\Microsoft\Office\16.0\Licensing folder.
Oleg – we have exactly the same issue – have you managed to resolve please?
Hi Oleg,
You need to make sure that the identity key is deleted as it’s machine specific.
So we are receiving 1004 error from office while having a similar setup. Any ideas, non-persistent, horizon, adfs, with Duo but it’s only a certain user and not the entire pool? Any help would be greatly appreciated!
When does the 1004 code appear?
Stephen it appears when they launch Outlook from within their session when first logging in. Their account is shown in work and school and within the credential manager. We were having helpdesk clear out the account in work and school, then they would clear out everything from credential manager. Then log out of VDI. When they log back in they’re prompted for SSO. Outlook prompts them for credentials, they enter in their credentials and that allows SSO for all the MS apps. Teams will open next with no password. Then Bluebeam with no password. THe user is typically good for that session. Then they go to disconnect and log out. When the users logs back in they won’t be prompted for a password but will receive a 1004 error upon launching Outlook. Any recommendations would be greatly appreciated. We are not clearing the identity upon log on because we want the profile following the end user.
DisableADALaptopWAMOverride set to 1
EnableADAL set to 1
SignedOutOneAUthMigrationComplete set to 1
Hi Mark,
Identity needs to be cleared, as it contains information specific to the identity of the machine which changes on log off/on.
As for those other settings you mentioned you are setting, can you let me know why you have those set?
And finally, do you have Azure SSO configured (Seamless or PRT), and also do users UPNs match their e-mail addresses?
Cheers,
Stephen
Stephen, I just was your youtube video on this and you stated that there is a registry entry that you can create on your instant clone golden image that will stop the machine from performing a hybrid AD join.
What is that registry setting?
Great article, thank you!
Awesome article thank you! For the SCA setting, we currently use FSLogix for the users profiles but not office containers and the majority of the users are on non-persistent instant clones. However, the machines do not refresh after every log off (currently every 7 days) and we use dedicated assignment so there is typically only one user that logs into that specific machine.
The reason I ask is because users are getting the “Something went Wrong error 1001” when trying to sign back into office products after signing out or an image refresh. We have found a temporary work around of deleting some temp files/cache in the users profile appdata/Microsoft/Teams folder.
Hi Jay,
Is it teams giving that error, or all Office apps? Also, are you roaming identity with FSLogix? Do you have Azure AD SSO configured, and if so, which method are you using?
Also, have you deployed Teams using the proper method for VDI base image installation? And finally, if you’re using the new Teams client, do you have a high enough version of FSLogix installed?
Cheers,
Stephen
It doesn’t matter the 365 app, they all do it when it happens. We are currently using FSlogix version 2.9.8612.60056 but getting ready to push 2.9.8716.30241. I’m guessing based on the version number we are not roaming the identity.
Yes we just deployed the new teams via bootstrapper.exe, however, it was happening with the per machine installer as well.
I see that we need the 2.9.8716 version for the new teams so we’ll do that now.
Oh forgot sorry, we are using number matching for MFA with microsoft products. It goes all the way thru that then bombs out after you authenticate with the something went wrong error 1001.
If that’s the case then identity isn’t properly configured with Azure AD SSO.
When you specify this value in a non-persistent VDI, installation
Do we still need the following computer activation via group policy too in the below manner?
“Computer Configuration -> Policies -> Administrative Templates -> Microsoft Office 2016 (Machine) -> Licensing Settings
And set “Use shared computer activation” to Enabled.”
thanks
Hi Ara,
Yes it’s required. That switch turns on SCA (Shared Computer Activation), which is a requirement for non-persistent VDI deployments.
Cheers,
Stephen
Hi Stephen
I may have worded it in a way so that I confused you.
When you already specify this value in a non-persistent VDI, installation in this manner
Again Do we still need the following computer activation via group policy too in the below manner?
“Computer Configuration -> Policies -> Administrative Templates -> Microsoft Office 2016 (Machine) -> Licensing Settings
And set “Use shared computer activation” to Enabled.”
Basically, do we have to do it 2 times (1) one while installing (2) and again via group policy
Because in the ms article, it says the following which indicates we have to do the group policy only if we miss the parameter (“SharedComputerLicensing” Value=”1″) while installing office
“If Microsoft 365 Apps is already installed and you want to enable shared computer activation, there are three options to choose from. A reinstallation isn’t required. The device must be rebooted in order to apply the change.”
Option 1: Use Group Policy to enable shared computer activation
Option 2: Use Registry Editor to enable shared computer activation
Option 3: Use the Microsoft Support and Recovery Assistant to enable shared computer activation
https://learn.microsoft.com/en-us/deployoffice/overview-shared-computer-activation
Hi Ara,
I understand now. If you configured it with the installer, you may not need to configure it in the GPO, however I still do just for good practice.
Cheers,
Stephen
Thanks Stephen for the replies. When you say “identity isn’t properly configured with Azure AD SSO” is there anything specific I should be looking at?
Our Microsoft logins are @domain.com but we also have @domain0.onmicrosoft.com that was set up when we launched 365. Everybody’s identity in Azure/Entra ID show the domain0.onmicrosoft.com.
After we clear some cache/temp folders in their profile (FSLogix), sign them out and then back in, it works fine. Something is carrying over with their profile and mucking things up.
It sounds like your UPNs on Azure AD don’t match your UPNs on your local domain. I’d recommend reviewing your deployment and correct those items and re-test. The users AD UPN should match the UPN on Azure AD. If your AD domain doesn’t match your public domain, you can use an alternative UPN suffix (I have a blog post for that).
Bummer, the UPN’s match up. The UPN in AD matches exactly to the UPN in Azure. Thanks again for the help and if I get it, I’ll post back.
Hi Stephen, I have joined a company that uses non-persistent VDI’s on win10. SCA is enabled but users are having issues with the Office licence activation – We are having to disconnect their account from Access work or school and then reauthenticate them again, it is the only way we can get their licence to activate. We do use FSLogix for profiles. Any suggestions..
Many thanks,
Hi Jon,
This issue is common and is caused by one, or multiple of the following:
-UPN Mismatch
-SSO Issues (Depending if you’re using SSO with PRT, or Seamless SSO)
-Hybrid Domain Joining (If misconfigured, or configured when it shouldn’t be)
You’ll need to identify if one or more of the following is having issues, and then correct it.
Cheers,
Stephen
Hi, Congratulations! this webpage is very interesting. For my part, all softwares works fine until Conditinnal Access with MFA on Azure are enabled by IT Group…
I use VDI on W10 or Remote desktop on server 2019, fslogix profile and ODFC, O365, teams, onedrive, edge with AD account.
Like I said before, configuration is OK in SSO, profile roaming is OK.
When i enabled conditionnal with MFA, all softwares ask the MFA Code at ech logon! We must enter MFA at start of Edge, Onedrive, Teams, Office, etc…
I’m very desappointing because I can not have access to Conditionnal Access Rules… It’s managed by IT Group.
Can you help me about it? Maybe, Conditionnal Access is not compatible with Citrix/Fslogix?
I don’t know where I must search to debug it…
Thanks!
Hello,
In order to use conditional access inside of the VM, you are required to enable Azure SSO with PRT and hybrid join your VM guests.
Cheers,
Stephen
Hi Stephen. Do you know if OneDrive SSO is supposed to work with Seamless SSO?
Briefly tried with your settings and others, but it doesn’t seem to work.
Microsoft seems to state that HAAD join is a requirement for this: https://learn.microsoft.com/en-us/sharepoint/use-silent-account-configuration#prerequisites
Hi There,
This may have changed, but previously I don’t actually Hybrid Domain joining was required.
I’d recommend testing to see if it will work with Seamless SSO instead of Azure SSO with PRT from HAAD.
Hello again. Sorted it. It seems having any kind of MFA (Azure MFA/legacy/security defaults) breaks Seamless SSO especially for Teams and OneDrive. With MFA it prefills username, then asks for password.
Disabling MFA and Seamless SSO works instantly, OneDrive included.
(This is a non-persistent Horizon VDI environment where we don’t want ADFS for PTR SSO.)
In our environment (non persistent vdi – win10) we are getting intermittent http 404 error messages saying “We can’t connect you.” “Looks like we can’t connect to one of our services right now. Please try again later, or contact your helpdesk if the issue persists.” HTTP 404 login.microsoftonline.com.
This corresponds with 1098 Event ID errors in the event viewer related to the token broker plugin.
Like I said, intermittent…vm could load 10 times ok with activation working just fine and Outlook configured for the user just fine, then on the 11th time, 404 error. We have been up and down the firewall logs and see nothing at the time of the error. We were thinking it’s just a random activation server that errors out from time to time. Could it be SCA token related and timeout of a particular user token on the network or anything related to that?
There seems to be no rhyme, reason or pattern to it and we can’t make it happen on demand to test it or invoke it to generate a test.
Same same here.
Since MS Feb cumulative patch KB5034763, Office activation generates HTTP 404 login.microsoftonline.com.
We found a workaround by restarting the machines after creation. We’re doing this with a postsync script. Don’t understand why this is necessary as all settings, regkeys, policies are already applied before the restart but it won’t work without it.
That’s ok for now but a real fix would be appriciated.
Thanks for the info Will. We will try this. Was this happening every single time a user logged in to the vm desktop or was it intermittent?
Brent
Hello,
I’m also experiencing the same issue and it’s intermittent for users. We’ve had to delete the User’s DEM profile to get Outlook to work and some times this works. I hope someone finds a fix for this soon.
For my testing accounts it felt like permanent issue. No matter if I used the roaming profile or a fresh one. Maybe it worked from time to time but I can’t say if I didn’t make a restart of the vm before. Because of that we never deployed that snapshot to public until we worked around it.
No issues so far with the workaround still in place after two weeks in production.
I have been having issues connecting to office as well. I found that if I disconnect and reconnect the network adapter through vsphere, then I can sign in no problem. Idk how to fix this…
Hi John,
Is the image fully optimized using OSOT?
Cheers,
Stephen
Update: After following Reddit and VMWARE community threads I do believe the “trace” workaround is working for us. 60 plus login tests with no 404 on office activation so far. The command we use is this:
netsh trace start scenario=InternetClient_dbg provider=Microsoft-Windows-TCPIP level=5 capture=yes packettruncatebytes=120 tracefile=c:\Temp\net.etl report=disabled maxSize=1 fileMode=single perf=yes correlation=disabled
The below threads have plenty of discussion and I used DANVM99’s example listed here on page 3: https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Anyone-having-issues-with-Outlook-or-Teams-after-latest-Windows/td-p/3009088/page/3
https://www.reddit.com/r/VMwareHorizon/comments/1avofn9/authentication_issues_with_latest_version_of_365/
https://kb.vmware.com/s/article/97111
Brent
After installing new teams in our vmware environment we no longer have the addin for meetings in outlook, any ideas ?
Hi Nigel,
It sounds like you may have to re-deploy the New Teams add-on: https://learn.microsoft.com/en-us/microsoftteams/new-teams-vdi-requirements-deploy
Cheers,
Stephen
Hi Stephen,
Our SSO has been enabled and created the recommended GPO’s. I just wanted to ask few questions:
1. We created a customize configuration office O365 xml to exclude some of the apps that we don’t need. Here’s the sample xml’s:
2. We did test the guidelines that you’ve provided, And in our Horizon non-persistent environment, The end-users still need to enter their credentials to authenticate neither One Drive or Teams.
3. Also, Why the O365 apps when launching and opening the programs, It keeps asking to ‘Sign in to the Office’ to activate? If we login into any O365 apps, It should be automatically pulled the valid license across to all O365 platforms.
Hi Brian,
Unfortunately I can’t see your XML as it can’t be shared on comments.
For your second point, if it’s prompting you to authenticate, then it sounds like you don’t have SSO, or the ability to save the credentials to the profile.
For the third point, this could be caused either by lack of SSO or saved credentials, and then also if SCA (shared computer activation) isn’t working.
Are you saving your SCA tokens to the profile or network share?
Cheers
Stephen
Hi Stephen,
dsregcmd /status on horizon non-persistent vdi, It shows that the value for ‘AZAD PRT: NO’. Any O365 apps doesn’t do passthrough. End-users need to re-enter the username and password to activate the products.
Yes, We’re saving the SCA Tokens using theFSLogix (2.9.8884.27471). Saving the cache information using the fslogix didn’t help.
Bryan
Hi Brian,
Since you’re mentioning the PRT I’m assuming you’re expecting that to be yes, and you’re not using Seamless SSO?
Hi Stephen,
We’re using the Seamless SSO. And it works on physical devices. It’s just O365 apps on non-persistent VDI doesn’t passthrough the PRT.
Thanks,
Bryan
Hi Brian,
You mentioned Seamless SSO, but then later mentioned PRT.
Seamless SSO does not use PRTs, only HAADJ uses PRT for SSO.
Brent Marceaux,
Did you have do this workaround for every user’s session or are you doing this on the parent image?
Hi Stephen,
Have you encountered any issues with Office 365 throwing the “Something went wrong 1001” error when dealing with instant clones and roaming profiles (FSLogix)? Every couple of weeks our instant clones are refreshed and the users profiles are storing tokens or credentials and office bombs out after they try to log in. Typically, if we clear the credential manager and reboot, the user can log into office just fine.
Thanks,
Hi Jay,
I think I saw something similar with App Volumes, but I just had to re-deploy Office. Additionally, I’ve seen this at a client site, and recreating the image resolved it.
Note that there’s a possibility this could be because of the “Identity” key not being deleted, or your SSO configuration.
Cheers,
Stephen
Thanks Stephen,
We’ve gone down the road of new images and re-deploying office and no luck. I’m almost positive it’s something to do with the identity key like you mentioned or possibly the SSO configuration (which we haven’t looked at yet but not sure where to start). When the user logs in on the new image that identity is created which is probably tied to the machine ID somehow, then when the machine gets rebuilt from the instant clone refresh it doesn’t match up and throws the error.
We’ll start researching some of the SSO stuff. Thanks again.
Jay
Did you configure the GPO to delete that key as specified in my post?
Also, what are you doing for SSO, using Seamless SSO, or Hybrid Domain Joined IC’s with PRTs?
I am having difficulty with non-persistent VDI desktops where I have Shared Computer Licensing setup for Office 365. Our organization also uses OKTA for MFA and with some of the test users Office applications will not complete the activation process and the user gets a “Something went wrong [7q6ch]” error. In one specific example the user is able to launch and activate Word, Excel and Powerpoint and the Office Account – About for these applications all show the shared computer licensing is active. Outlook still produces the error for this user and will not allow for a profile to be created. I checked that group policy is set correctly and is being applied to the desktops and that the Office install is configured correctly. The strange thing in my opinion is how some of the test users do not get this error and others do. Also, if the writable volume (in which the licensing text files are stored within APPDATA) gets deleted, the user might start to having this problem.
Furthermore,I tried an experiment where I copied the two licensing text files to an external location, deleted the writable volume associated with the user and then had the user log back in and launch Office however before it actually attempted to activate again I copied the text files back into the appropriate location in APPDATA and then had the user open Office applications and they opened with the activation completed however Outlook would still not work.
I’m perplexed as to what is going on here in that it still seems to be a problem with license activation but I cannot determine what needs to be done next.
When updating the OneDrive App, shall I uninstall and reinstall or can I just update by using the /allusers switch?
With the latest version I have the wierd symtom that the OneDrive Context Menue disappeared, everthing else works fine.
Hi Stephen
We’ve recently installed a new server infrastructure with FSlogix (installed by a service provider), and for the past few weeks users have been getting a 7q6ch error when trying to use the Office suite. It started with problems with outlook (we were able to resolve this error in the same way as error 1001 at the beginning), then it became impossible to connect via the rest of the Office suite. We thought it might be a problem with the antivirus and/or firewall rules, but it doesn’t seem to be that. We’re wondering about a GPO or FSlogix problem.
Do you have any ideas?
Thanks in advance
Hi Stephen, great article, its been super helpful.
Non-persistent Citrix desktop environment.
Non hybrid sso. (we use another tool to sync users and use DUO SSO).
We like others had issues when MSFT released updates and fslogix versions that broke caching creds, where users had to sign in often during their session, between office apps, teams, etc.
Then they released FSLogix 2210 hotfix 1 (2.9.8440.42104) and we were able to apply roam identity gpo to help cache credentials. This worked fine it seemed and fixed that issue.
We recently have seen this caching of credentials issue is back and its not working again.
Then i saw your article here regarding deleting IDENTITY key for HKCU for users. We tried this on a subset of users and got great results where 100% of those users no longer had multiple prompts during the day.
Then just last week we upgraded our citrix servers to go from FSLogix 2210 hotfix 2 to hotfix 4.
I guess hotifx 4 breaks this again regardless of if the IDENTITY key gets deleted on login.
Any thoughts?
Hi Frederic, apologies for the delay.
These symptoms you’re reporting could be caused by a number of issues. Was your base image deployed using the best practices guide? Also, do you have Azure SSO configured (either seamless or with Azure PRT)?
Are you roaming the identity with FSLogix?
Hi Josh,
Happy the post has helped! 🙂
Can you confirm after upgrading FSLogix, that you’ve enabled “RoamIdentity” and you are deleting that user registry key before they initialize any office apps?
Stephen, thanks for the reply, you bet!
Roam identity is enabled on their GPO.
also, i am deleting that HKCU registry key via Group policy preferences.
Josh, just to confirm, you don’t have hybrid domain joining enabled, do you?
that’s correct, no hybrid domain joining.
Stephen, is this logical? Perhaps the total fix is doing what you mentioned, deleting the key entirely, and then add back “NoDomainUser” (set to 1 per the article) next in the order so that the credentials are cached correctly?
It mentions if you use federation or 3rd party federation (which we do), then this must be put in place.
https://learn.microsoft.com/en-us/microsoft-365/troubleshoot/access-management/office-prompt-for-credentials
Looks like that didn’t solve the issue, but apparently, what does fix the issue with having to sign in multiple times to different office apps, etc during the same 8 hour session is going into entra identity admin and clicking on the user and revoking all sign-ins. have them re-auth, and then they are good. So it is the profile?/
Would the equivalent fix (automated fix) letting the user somehow click a link to do this, or to have the user click a script to clear out something that IS in the fslogix profile that’s cached? im not sure what would need to be cleared out locally or if that’s even possible to do on the AD side.
Hi Josh,
Do you have Seamless SSO configured? You shouldn’t have to sign in to any apps.
You shouldn’t require any script to modify anything inside of Entra ID. There’s something wrong going on in your environment that needs to be corrected. Focus should be on resoling the issue, not working around it.
Cheers,
Stephen
Hello,
we use non persinstand XenDesktop VDI with Citrix UPM and Office 365 – SSO with Edge and Teams works but
we get very often “Office 365 – Account Error: Sorry, we can’t get to your account right now”
we have set Appdata\local\microsoft\identitycache synchronization but still the problem
https://support.citrix.com/s/article/CTX489573-office-365-account-error-sorry-we-cant-get-to-your-account-right-now?language=en_US
Any ideas whats the problem?
Robert
Hello,
Do you have Azure SSO configured (either Seamless or Azure PRT)? Also, are you deleting the Identity key?
Cheers,
Stephen