Deploy, Install, and Configure Microsoft Office 365 in a VDI Environment
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.
- 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
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)
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:
You 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
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="AUTOACTIVATE" 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:
Installing Microsoft Teams on VDI
I have created a guide that covers how to install Microsoft Teams in a VDI environment and how to enable Microsoft Teams Optimization.
To Install 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=1
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:
Updating 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 Settings
And 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:
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) -> Updates
And 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 -> OneDrive
And 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 Policy
And 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 Run
And 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 -> Miscellaneous
And 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).
User Configuration -> Policies -> Administrative Templates -> Microsoft Office 2016 -> Subscription Activation
And 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.
User Configuration -> Policies -> Administrative Templates -> Microsoft Outlook 2016 -> Account Settings -> E-mail
And 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.
User Configuration -> Policies -> Administrative Templates -> Microsoft Outlook 2016 -> Account Settings -> Exchange
And 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.
User Configuration -> Policies -> Administrative Templates -> Microsoft Outlook 2016 -> Account Settings -> Exchange -> Cached Exchange Mode
And 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 -> Registry
We’ll create a new registry GPO item, that will “delete” the key path below inside of “HKEY_CURRENT_USER”:
This 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
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.
[…] 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.
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).
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.
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/)
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?
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?
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?
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?
my ADMX templates are NOT the latest version. any gotchas on updating them? Thanks!
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.
i haven’t downloaded the new ADMX templates for 20H2, any gotchas here? we do have the latest horizon ADMX templates.
As for the Windows Client/Workstation ADMX files, I don’t think I’ve ever had any issues updating these. 🙂
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?
Do you use CDN for your installation deployment?
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.
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
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.
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?
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?
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.
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:
However, I have the problem with the script as it automatically tries to log me in that I don’t get an MFA prompt.
I still don’t understand why you’re using that script as it’s not needed and is probably causing your issues.
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
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
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.
Thanks for the above.
On your Non persistent VDI’s – have you added https://autologon.microsoftazuread-sso.com to the intranet zones?
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.
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?
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.
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, […]
A bit off-topic, but here goes.
I’m currrently pushing this value:
Disable OneDrive as the default save location:
Value Name: PreferCloudSaveLocations
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.
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.
Well done on this article; looking forward to leveraging it in our upcoming updates.
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.
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!
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.
[…] 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?
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.
They basically removed token roaming from FSLogix. Reverting to the previous version resolved the issue.
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.
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.
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.