Microsoft Teams has risen quite emphatically to prominence over the last six months or so. The reason for this is twofold – primarily, to do with the explosion of remote working that has occurred as a response to the COVID-19 pandemic, and also with the coincidence of the Skype for Business retirement date in August of 2020. This has resulted in many Citrix administrators having to deploy Teams into their Virtual Apps and Desktops environments – often quite rapidly.
Teams is Microsoft’s primary Office365 collaboration tool and is written in Electron, which makes it a bit of a pain to manage, like other Electron apps. An important point to make about Teams is that it cannot be run on-premises – it requires a cloud or hybrid model. This is because Teams hooks into Sharepoint Online, Exchange Online and Office365 Groups to drive the Teams experience. Exchange Online is the most important component to have so that your users can access the full features of the Teams product.
With Skype for Business running out of support and a huge percentage of the enterprise workforce now mandated to operate remotely, delivering Teams into Citrix environments suddenly became hugely important. But we didn’t just have to get it up and running – we had to get it up and running well. Video and audio (particularly video) were suddenly hugely important. For a lot of people, remote working is a huge cultural shift, and providing excellent collaboration facilities with the ability to interact directly with other humans is vitally important. The provision of realtime interaction is crucial – because drops in quality lead to disjointed contact, and for workers who are isolated from their colleagues, this can make a huge amount of difference. Indeed, the importance of top-quality video and audio isn’t just a business benefit to aid productivity any more, we’re actually potentially talking about people’s mental health and general happiness.
But what issues do we have putting Teams into a Citrix Virtual Apps and Desktops environment? I’ve had to divide this article into a very short series, unfortunately, so here’s the first instalment – dealing with installation.
Installation
Let’s start at the beginning, and arguably one of the trickiest parts of getting to grips with Teams – actually installing the damned thing.
Firstly, don’t use the Click To Run installer to install Teams, and make sure that you install the VDA prior to doing the Teams install. You can find the proper MSI installers at these links:-
You can use the “exe” rather than the “MSI” installer, but this only installs Teams for the current user only, which is why you’re best advised using the proper MSIs.
The installer needs to be run with certain switches, so it should be called from msiexec (whether this is manually, or through some form of software deployment mechanism, is entirely up to yourself). The two switches you need to be concerned with are ALLUSER and ALLUSERS.
ALLUSERS simply means that an entry will be written into Programs and Features for all users, allowing the program to be uninstalled directly.
ALLUSER means that the automatic updater will be turned off, and this is crucially important for non-persistent and RDSH environments. Without this you will receive updates into multi-user or non-persistent environments and you will see a lot of problems.
If you are fully persistent – so for instance, using Teams on one-to-one machines where the user’s profile is stored locally – then you can get by with simply using the ALLUSERS switch on the installer, as below
msiexec /i <path_to_msi> /l*v <install_logfile_name> ALLUSERS=1
If you are on any other form of environment other than fully persistent, then use both switches to ensure you don’t lose control of updates to your images
msiexec /i <path_to_msi> /l*v <install_logfile_name> ALLUSER=1 ALLUSERS=1
I’ve compiled a table here showing how the installers (both MSI and EXE) behave when run with the different sets of switches and on machines that may or may not have the Citrix VDA installed. (You will probably need to zoom in for the full details!) Key differences include the auto-launch methods (including various different Registry command switches), the location of the actual “application” files, the locations of the shortcuts, and whether users can see the uninstaller to initiate it.
* refers to features lagging behind the “official” release version of Teams. Examples of lagging features include multi-window (pop out meetings and chats), give and take control, background blurring, etc.
** needs a VDI environment installed or spoofed
Update – MultiWindow (pop-out) is now supported on VDI/RDSH – on Citrix, for instance, you need Workspace App 2112.1 or higher (Windows), Workspace App 2203 or higher (Mac/Linux), VDA 2112 or higher, and Teams version 1.5.00.11865 or higher. Feature lag still applies on an ongoing basis though.
If you need to “spoof” a VDI environment, then running either of the below commands will trick the installer into thinking you’ve got one
reg add HKLM\Software\Citrix\PortICA /f
reg add HKLM\SOFTWARE\Microsoft\Teams /v IsWVDEnvironment /t REG_DWORD /d 1 /fNow, onto the nitty-gritty. If you use both sets of switches, which I generally recommend, the Machine-Wide Installer drops a “stub” that is just the updater (and if you’ve installed using the right switches, this won’t run anyway). The executable and libraries go into c:\Program Files (x86)\Microsoft\Teams\current, but everything else is dumped into the user profile. So the executable is called from the Program Files folder – but the cache and all the other moving parts are thrown into the user’s profile and carried around with them.
Once this has completed, the next stage of “installation”, as it is, is triggered when the user logs onto a device that has the Machine-Wide Installer on it.
- User logs on
- Registry value in HKLM starts Teams.exe from the Program Files folder
- Approximately 10MB of files are created in %APPDATA%\Microsoft\Teams
- User is prompted for sign-in (or sign-in happens via pass-through)
- Teams UI launches and begins initial setup
- A further 5GB (approximately) of files are created within the user profile (most of which are deleted as part of this stage), session resource consumption spikes
Once initial setup and sync is completed (dependent on user setup), Teams is now fully “installed” into the user’s profile and this process will not need to be run again, as long as other devices the user accesses have the Teams Machine-Wide Installer and are using the same profile. Approximately 700-900MB of space in the profile is consumed by Teams data once this is completed (dependent on environment – this may be higher).
If you uninstall Teams, this simply removes the Machine-Wide Installer from the device – but what it also does is remove the executable that the users use to launch Teams (as well as the shortcut in %ALLUSERSPROFILE% that points to it). So despite having it still in their user profile, there’s no way for them to actually run the Teams client. However, it does mean that if they log onto a machine that does have the Machine-Wide Installer on it, they will not need to go through the first-run setup for a second time.
Teams does leave some remnants behind – mainly some device-specific filesystem entries
and a few logs and other folders in the profiles of users who may have launched Teams. As mentioned earlier, it is up to you whether to keep the profile-based entries (so that a user does not need to run the initial setup again), or to remove them entirely (usually would be done if you are trying to fix a Teams-related error that is tied to the user).
You can clear all this stuff up manually, or you can use some of the cleanup scripts that are out there (CTA Manuel Winkel has a good one here).
One final note to make about installation is that when you upgrade to a new Teams version, you must uninstall the old version fully before installing the new one. If you start every new build with a brand new image, then this isn’t an issue, but if you are simply making changes to an existing golden image (like you often would with MCS or PVS), then you need to be aware of it. Make sure in this situation you fully remove the old Machine-Wide Installer and do all necessary cleanup before installing the updated version.
Auto-setup and auto-launch
I’m going to refer to the automatic “first run” of Teams that triggers the initial setup as “auto-setup”. Auto-setup is a pain, for reasons you can probably guess. If you install the Machine-Wide Installer widely onto an estate, and then have thousands of users logging in the next day and launching Teams for the first time – that initial “burst” of resource utilization can cause a big problem.
Of course, as Citrix or RDSH admins, our first instinct is to disable the auto-setup from running so we can get a handle on it. If the users can launch Teams from the desktop or Start Menu shortcuts, then surely it is better to allow them to choose “when to launch Teams for the first time”?
If you go a-Googling, then there are immediately two methods of disabling the auto-setup that spring out:-
Use a switch with the command-line installer that blocks the auto-setup
msiexec /i Teams_windows_x64.msi OPTIONS="noAutoStart=true" ALLUSER=1 ALLUSERS=1
Or, edit the setup.json file that sits in the Program Files (x86) folder, so that it no longer has the auto-start flag set (the PowerShell below changes this setting)
(Get-Content ${ENV:ProgramFiles(x86)}’\Teams Installer\setup.json’).replace(‘false’,’true’) | Set-Content ${ENV:PROGRAMFILES(x86)}’\Teams Installer\setup.json’
There’s one small problem with both these methods, though – neither of them works. When you log into an instance that has been configured with either of the above methods, Teams still launches the auto-setup routine.
The auto-setup is driven by the entry pointing to Teams.exe which sits in HKLM. When this program runs, auto-setup is started (if the user hasn’t used Teams before), or the Teams client starts (if the user has already done the auto-setup step).
So can we just delete the HKLM entry and have done with it that way?
Well, yes, but with a significant caveat. The problem is that once auto-setup has been run, on subsequent logons, the auto-launch (so not the first-time setup, but the automatic launch of Teams for a user who has already done the auto-setup step, which we will refer to as auto-launch from hereon in) is also driven by the HKLM Registry value. So if you delete the HKLM Registry value so that users trigger the auto-setup step themselves, then the users will have to remember to manually launch Teams every time they log in. This isn’t ideal – apps like Teams are good to get auto-launched, because otherwise users may miss important conversations and messages. And don’t forget – there is no option in the user interface to auto-start Teams with the Machine-Wide Installer. The “user” version of Teams (the one that auto-updates, which we don’t want to use) has the option to auto-start in the GUI…
…but the Machine-Wide Installer has that option removed, as you can see below
Now, our requirements appear to be thus – we want to disable the auto-setup, so that new users don’t all launch Teams at once and hammer the system resources, but once they have launched Teams for the first time, we want the program to auto-launch so they don’t have to run it manually. There is a way to do this – but first, I’m going to go off on a bit of a tangent, because it ties together with what we are going to do, so bear with me.
Open minimized to notification area
Teams does, both in the user and Machine-Wide Installers, have the option to “open application in background”. This means that it will launch minimized to the notification area rather than opening up full-screen. I think this is an important feature. You don’t want users logging on to shared meeting-room devices, for instance, and a confidential or embarrassing Teams conversation flashes up on the screen for all to see.
Obviously, there is the option in the user interface to enable this functionality…
This setting correlates to an entry in a user-based configuration file, %APPDATA%\Microsoft\Teams\desktop-config.json. There is a property in this file called openAsHidden which will be set to true or false dependent on the option you have selected in the GUI.
Of course, like all things Teams, there’s a problem with this. In that, it literally just ignores the setting in the UI and just opens up full-screen anyway. Way to go, Microsoft! Arbitrarily ignoring user-selected settings that could have potential security risks attached – priceless.
So as well as getting rid of the auto-setup but keeping the auto-launch, we also want to force Teams to actually honour the setting for openAsHidden from the GUI.
GPOs?
“Isn’t there a GPO for handling this?” Well, there is. There is one solitary GPO for Teams, and it looks really promising – just read the description
In my testing, however, this GPO doesn’t do anything. I made sure I applied the GPO before Teams was installed (as per the description), but it still launches automatically at first logon. Talk about a disappointment!
Solving it
We need to do three things, as we’ve already laid out – disable auto-setup, enable auto-start once the setup is triggered manually by the user, and also make sure that the openAsHidden flag is actually respected. How can we do this?
You need to do a bit of conditional Registry editing, so I’d use Group Policy Preferences, Workspace Environment Management, Ivanti User Workspace Manager, or any one of the myriad tools out there that can manipulate the user Registry based on certain parameters. For this example we’ve used GPP as everyone has access to that – tweak as required for your own solution.
I set up a Group Policy Preference Registry item that writes an HKCU Run entry pointing to Teams rather than HKLM (make sure you do not use Wow6432Node in the path – HKCU does not execute the Wow6432Node Run entry, if it exists)
- Action – Replace
- Hive – HKEY_CURRENT_USER
- Key path – Software\Microsoft\Windows\CurrentVersion\Run
- Value name – Teams Auto Start
- Value type – REG_EXPAND_SZ
- Value data – (below so can be copied better)
"%ProgramFiles(x86)%\Microsoft\Teams\current\Teams.exe" --process-start-args "--system-initiated"Also, use “Run in logged-on user’s security context” in the Common tab, and an Item-Level Targeting scoped as below
Also, alongside this configure a second GPP Registry item, this time as below
- Action – Delete
- Hive – HKEY_CURRENT_USER
- Key path – Software\Microsoft\Windows\CurrentVersion\Run
- Value name – Teams Auto Start
Again, use “Run in logged-on user’s security context” in the Common tab, and an Item-Level Targeting scoped as below
Update – if you’re using the pre-staging technique from the second article in this series, you need to use a file other than desktop-config-json to indicate that Teams has already been run. I recommend changing the GPP Item-Level Targeting filters above to look for a folder, %APPDATA%\Microsoft\Teams\Cache, instead of the JSON file.
Update 2 – if you’re using FSLogix Office Containers with the Teams data captured into the container, the Teams auto-start won’t work properly, because the Office container may not be mounted when Group Policy processing is done at logon (and henceforth it will delete the HKCU entry because it thinks the Cache folder doesn’t exist). If you are using Office365 Container for Teams (this won’t affect Profile Container though), you need to remove the second GPP entry, the one that does the Delete if the Cache folder isn’t there. However, what this means is that when your users run Teams for the first time, they will need to stay logged in long enough for a Group Policy refresh to occur and write the auto-start entry. Most users generally stay logged in for at least a single refresh cycle to occur, but if you think they might not, then you can add a conditional Scheduled Task to simply run a gpupdate early on in their first logon session,
Hopefully you see what we are doing here. The HKCU entry is only created when the desktop-config.json file exists (which means auto-setup has been run manually by the user). If the json file does not exist, the HKCU entry is cleared. The additional arguments on the executable – –process-start-args “–system-initiated” – ensure that the openAsHidden property is properly respected. If you’re not bothered about it opening minimized, then just set the HKCU Run entry to simply “%ProgramFiles(x86)%\Microsoft\Teams\current\Teams.exe”
What a palaver! Let’s summarize this Teams installation and config process:-
- Always use the Machine-Wide Installer
- Always install with the ALLUSER and ALLUSERS switches
- Delete the HKLM Run entry that Teams drops into the Registry
- Apply the Registry entries mentioned above through GPP, WEM, UWM, etc.
Now, if all this seems like a great big pain in the proverbials my fellow CTP and Teams wrangler Rene Bigler pointed out something that may be of interest. Over at Master Packager (www.masterpackager.com) there is a custom installer file where they have modified it so it can be installed everywhere, it removes the desktop shortcut, disables auto-setup and removes the Modify option. You can find it at the following link – https://www.masterpackager.com/blog/mst-to-install-microsoft-teams-msi-vdi-to-regular-windows-10
Another point to mention is that the Teams Machine-Wide Installer is meant only to be used on “VDI” platforms (VDI being used in the loosest possible terms). This is why at the start I said that the VDA must be installed before installing Teams. The Machine-Wide Installer is supposed to run only on Citrix, VMware Horizon and Windows Virtual Desktop and performs some checks to make sure it is in one of these environments otherwise it will fail with the error below
Of course, this makes it problematic if you’re using one of the other virtualization technologies out there (Parallels maybe), or if you want to package or layer your Teams install using some kind of application installer technology (App-V, AppVolumes, App Layering, Cloudpaging, etc.) I can’t speak for VMware Horizon or WVD, but if you need to trick your Teams Machine-Wide Installer into running on a non-VDI platform, simply create the following Registry key prior to running the installer so that you make it think it is running on Citrix
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA
With this in place, you should be free to do what you want with the installer (or you could just avoid this and use the Master Packager version where they’ve already fooled it for you).
If you’re using the 1906 or 1909 version of the Citrix VDA, you may get issues with Teams crashing. Create a DWORD value in the following path – HKLM\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\SfrHook\Teams.exe – and set it to 204 to resolve.
Finally, make sure you update Teams as often as possible. New versions come, even to the Machine-Wide Installer, a couple of times a month. If you want to keep on top of new features for your users you will need to keep an eye out for new updates to the binaries, and remember what I said – unless you are starting with a fresh base image every time you update, fully uninstall the old Teams version before installing the new one.
Summary
So there you have it – what a finickety application to have to try and deliver!
Bear in mind that Teams changes regularly, so that anything in this article could become out-of-date at any time – certainly my previous Teams article is now redundant. At time of writing, though, this all tested and worked as described.
The next part of this, where we will talk about session performance and the mysteries of the json files that drive Teams, will probably drop in a couple of weeks as I have part #3 of my logons series to publish first (contain your excitement!) Stay tuned!
Hey James,
where did you get the link to your version? I always use https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi#deploy-the-teams-desktop-app-to-the-vm and there seems to be an older version.
I copied the links from the page you have mentioned.
Maybe use https://aka.ms/teams64bitmsi instead?
@Marco
that would be the standard link i guess, not the VDI one! Those are different packages.
Hi,
Both Files https://aka.ms/teams64bitmsi and from https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi#deploy-the-teams-desktop-app-to-the-vm are absolutely identical (19.11.2020 14:17 CET) checked with compare by content (binary). Link in the blog is an older build.
Ron.
I could have sworn that your link had a version like .22xxxx at the end when I first saw the article 😉
I just got a much newer version of the teams MSI from here: https://docs.microsoft.com/en-us/microsoftteams/msi-deployment
As of Oct 15, 2020 the MSI on the teams-for-vdi pages was distributing version .21759 while the MIS I downloaded from the msi-deployment link was distributing verison .26064
This is a really really good article Thank you very much! I’m especially glad, that I finally have proves for stuff I discovered weeks ago, but always thought I’m stupid.
Both the AutoStart Switch and the AutoStart JSON never worked for me, now I know they just don’t.
Checkbox “Auto-start” application was not available on Citrix, I was quite sure it’s not part of the MSI.
“Open application in background” also never worked for me, I will try –process-start-args “–system-initiated”
And finally the stupid none working GPO.
Thank you very much, for proving all my findings.
No problem Marco, don’t think that you’re being stupid, write it up and let everyone know! Nothing in Teams surprises me 🙂
Thanks for the excellent write-up. Has anyone actually been able to make the damn app start minimized by default?
I’d rather it start minimized for our users and let them have the ability to uncheck that option by default. I guess I could create default desktop-config.json that has that set, store it on a common share, and use a WEM file system operation to copy it down once…not ideal but might work.
Minimized is in the json file as well. But you can simply write the openAsHidden=true to the json file at the first launch and it should do the same?
I can’t get it to work either. Server 2019, 1912 LTSR CU1. Teams 1.3.0.21759
It just won’t start minimized, property in .json is set, HKLM keys deleted…
Even a “normal ” shortcut to doubleclick won’t work, it still opens in the foreground.
What about performance capping of Teams? on large environment with thousands of users, this is likely to consume a huge amount of resource and impact the total density. Have you looked at tailoring performance for Teams?
This will be addressed in the next part, but there’s only one word needed to deal with this – offloading.
Hi James, An excellent article for Dummies. In any of your upcoming article, can you also share pros and cons of x86 vs x64 version of Teams and on what circumstance should we choose one among them?
There are no pros and cons really, obviously the x64 version will perform better and right now I would always use 64-bit Office if possible. The only reason to still use 32-bit Office would be if you have incompatible plugins or add-ons, but if they haven’t been updated by now, they never will be, so I’d be thinking about ditching them.
Thank you for sharing James, excellent article !
Hi James,
Thanks for the article. Our xenapp sessions do not logoff because Teams setting On close, keep the application running is alway set to on. Xenapp cannot kill teams.exe for the session. This setting is not saved in the profile. Do you have solution for this?
kind regards,
Richard
Have you got Teams.exe in LogoffCheckSysModules?
I had the same issue. I found this script trough Twitter that sets the corresponding .json option to FALSE, so Teams always closes if you close the Teams Window (no more lingering in the sys tray, so no more teams.exe that blocks the logoff).
I start this script using Ivanti Environment Manager, but you could use any other tool e.g. GPO
Disclaimer: I am not the creator of this script.
Link:
https://github.com/Mohrpheus78/Microsoft/blob/main/Teams%20User%20Settings.ps1
I suspect that script was written by Dennis Mohrmann, who does some great Teams stuff
FYI to anyone who stumbles across this. We had to add WebSocketAgent.exe to LogoffCheckSysModules in addition to Teams.exe and we didn’t have to disable the “On close, keep the application running” setting. This looks to be newly relevant alongside the recent Shellbridge fix since the Run key is now processed in app sessions.
Hi James,
Thanks for the article. Just did the VDI install on a non-persistent Citrix farm. At least I suffer at some problems. Sometimes at Teams start users have to logon again and suddenly the password query appears while idle. Citrix login takes place with Windows account and for Teams we use a separate O365 account. There’s no specific error to find in the logs. Firewall is all open.
Do you have an idea for this?
kind regards,
Chris
Guys I fixed it. Make sure you put the following in the folder to mirror section in UPM management:
!ctx_localappdata!\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
Is there a way to re-trigger the auto-setup launch?
Maybe there’s a better question to ask, but what I want to test is if the changes I make to prevent the auto-setup actually work…. I tested with one account already and now the app just keeps launching on logon, but I don’t know if it opening as part of the auto-setup or part of the auto-launch.
Thanks!
Delete the user profile?
Duh! That was too easy, thanks!
Just an FYI for other users… I’m pushing this out to a non-persistent environment, and instead of opening up the ~10 images we have and installing this on the base image, I’m running the installation script on the read-only machines with the .msi stored in the network…. need to update? I don’t have to uninstall, I just have to replace the .msi in the network, and next time the computers reboot, they’ll instal the new version of Teams… no need to update the 10 vDisks again for this!
Thank you James, you are a true app installer artist!
Just one last thing to add… this was driving me crazy.
To try to re-create the auto-setup scenario, not only did I have to delete the user profile, which contains (at least for us) the %localappdata%\Microsoft\Teams, but I also had to delete the %appdata%\Microsoft\Teams folder, which for us, it doesn’t live with the user profile, it lives with the redirected documents. We send user profiles to one server and redirected documents to different servers depending on the user’s department.
The conditional registry jiu-jitsu is checking for the %APPDATA%\Microsoft\Teams\desktop-config.json file, so I kept deleting the user profile but the app kept launching… that’s because the desktop-config.json was not being deleted when I deleted the user profile.
Thanks again James!
You’re redirecting APPDATA? You have my condolences.
Thanks for this really useful post James.
Getting MS Teams working on our non-persistent Citrix PVS CVAD 1912 Win2016 server build (using Ivanti VHD management options to persist the Teams cache) has been much less of a nightmare, but still a nightmare! Here are some of the low/highlights of our journey that might prove useful to others…
1) VHD Teams cache management – we already used Ivanti User Workspace Manager so followed the guidance here to setup Environment Manager VHD Teams caching roaming + related personalisation:- https://marketplace.ivanticloud.com/packages/MicrosoftTeamsCacheRoamingTemplates/
N.B. The APSessionVHD variable defines where the VHD file should be persisted. I tried using the existing user home directory without success (Ivanti docs advise you don’t) and had to setup a new dedicated test share for the VHDs with the correct permissions. Looking ahead to a production – has anyone got an idea of how to size the VHD share from an IOPs per user perspective? I guess every Teams user is different but a rule of thumb would help.
MS IdentityCache folder roaming – not mentioned in the Ivanti VHD pdf guide but required. See details here:- https://forums.ivanti.com/s/article/Users-are-prompted-with-login-prompt-for-Microsoft-Teams?language=en_US
2) Teams 2nd launch failure – repeatedly prompts for credentials. Had this problem for ages. Tried lots of suggestions including Citrix hooking exclusions without success. Thanks to a comment on one of your Teams articles (and here https://superuser.com/questions/1440536/microsoft-teams-cant-connect-to-the-internet-request-timeout-after-second-s) I discovered deleting the settings.json file allowed a second launch, but this wasn’t really satisfactory. I ran it by our collaboration guys and it quickly became clear they had no idea of the inner workings of the Teams client. As a last resort I removed and re-installed the Teams client going from v1.3.0.9267 to v1.3.0.28779 and this alone appears to have fixed the problem. It may be coincidental but the VHD file size seems to have dropped with this new version too.
3) Conditional auto-launch – I tried your suggestions without success using Ivanti EM or GPO preference methods. With the GPO method the HKCU run key entry wasn’t being added at logon ( I suspect the VHD isn’t attached when the GPO conditions are evaluated) but if I checked the registry as a fully logged on user I could see the run key entry being added when I ran a gpupdate. We weren’t previously persisting the HKCU run key but adding this as a custom Ivanti Windows Personalisation setting has sort of made this work.
4) Tip – relaxing normal lockdown restrictions for your test users so they can edit the registry/view local server drives/access the command line will really help you see/troubleshoot how the VHD cache roaming solution works.
So in summary we have a solution working in our test environment but lots of work to gear up for production. Fortunately most of our Citrix users won’t need Teams access, as it really does seem like an awful lot of Heath Robinson-esque faff , effort and expense just to persist the Teams cache.
I’m looking forward to the Teams part #2 article!
Thanks again,
Nick
Thanks Nick, that’s really excellent information about getting it running on Ivanti, enough for a blog post 😉 I also agree with you on point #4, I’ve been lifting Registry restrictions for years to get at things like that. I think I wrote a blog post about removing them using AppSense once, and I think ControlUp has a feature that can do it also
Thanks for this, James!
I have both settings in GPP under User Config, not Computer Config with Loopback set to replace. Is that correct?
Also, what’s the proper order to run them in?
Follow up here…I’m utterly stumped. Even if I remove the HKCU Run setting, Teams still auto-runs and opens at startup. Is there something else I’m missing?
What else could force it to start?
We’re having the same issue… We have the GPOs in this article in place
Does anyone know if the single video feed in Teams meetings over Citrix is something we can change? seems to be a bit limited if we cant have more than a 1×1 meeting
If you’re on the very latest Workspace App and using the very latest VDA, you should be able to do 4×4 now, IIRC
Thanks this article.
Ive been tearing my hair out with Teams machine wide on wvd multi session windows 10 20h2. As it standards the only way to install machine wide successfully is with the citrix\port ica registry key, the problem which I am having is getting teams to be ‘WVD media optimized’ as currently the video does not work at all within teams only. I have all of the pre-reqs installed (webRTC) and the recommended registry keys provided by microsoft (IsWVDEnvironment) but no Dice, if anyone has any suggestions that would be great !
Hi James
Great article.
I’m having a problem with the MS Teams outtlook addin. It doesn’t seems to be installed anymore after installling the latest version of teams 1.4.0.4167.
If i check an oder installation i see a folder %programfiles%\microsoft\TeamsMeetingAddin, on the new setup with latest version, same installation parameters. The TeamsmeetingAddin folder isn’t created. Also the TeamsPresenceAddin in emtpy.
Have you seen this before?
If you know a reason for this, please share.
Kind Regards
Not that I have noticed – however every time I install Teams I make sure to fully install the older version first
You’re not alone. Have the same problem after upgrading from Teams v1.3.0.9267 to v1.3.0.28779 on a Win2016 RDSH CVAD 1912 CU2 PVS build. Did you find a fix in the end?
James, thanks for the great write up.
Cisco Webex for all of our meetings. I’ve been able to set that up nicely. But sometimes users will receive meeting requests with MS Teams links. So we need to support MS Teams as well. Is there an subset of instructions to install the teams components (server side and client side) for meeting participants in our scenario?
Can’t they just use the web client? If you need to install the full client, you can either let the users install the user version (provided you have a profile management solution), or install the Machine-Wide Installer
I was thinking of trying that.
Our users mostly use a Desktop session on our Citrix Farm. If they get a meeting request, just let them install the web client in their session. But I do want the camera and mic to be optimized and pushed out to their endpoint. Is the web client (installed in the user profile in Citrix) smart enough to push the optimized video and audio out to an endpoint?
Hmmm, if you want optimization in the web client, you will need to use Browser Content Redirection, which is not ideal. The web client isn’t “installed”, the “user” version of Teams is. You can use the “user” app to do optimization on a user-by-user basis, sure – just take care NEVER to let it co-exist with the machine installed version.
Hello James,
thanks for your informative article. I have installed teams on my terminal servers with this. Everything has worked so far, now I want to update Teams and that’s where my problems start….
I do as you described by uninstalling Teams and then manually delete the folder C:\Program Files (x86)\Microsoft. Additionally I delete the SquirrelLogFile and then try the installation as described. Unfortunately I always get the error “Access to the path ‘c:\program files (x86)\Microsoft\Teams’ is denied”.
I have already tried to install two different team versions, the error occurs with both.
Antivirus software is disabled during installation.
Do you have any suggestion for me?
Best regards
Never seen that happen before – what are the permissions like on the Teams directory?
Now would you like an exact listing of access rights?
I have compared the permissions with other folders, they are the same. Only the owner differs for some folders. Often the administrators are the owners, but for the Teams folder (and others) SYSTEM is the owner. Who is the owner on your Teams folder?
Hmmm, does it work if you change the owner to Administrators?
No unfortunately not.
I changed ownership to Administrators – same result. I also added authenticated users and gave them full rights, still the same error: System.UnauthorizedAccessException: Access to the path ‘C:\Program Files (x86)\Microsoft\Teams’ is denied.
Teams msi log gives a 1603….
Holger, I had the same issue. I think it might be due to the fact I installed my apps from a hidden network share, but could be wrong. Anyway, I was able to uninstall by the process below.
Locate the UninstallString key in the registry. You can copy and paste that into a cli and it works.
For teams, mine was: MsiExec.exe /I{731F6BAA-A986-45A4-8936-7C3AAAAA760B}
I found the path in one of these locations.
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\Wow64\Software\Microsoft\Windows\CurrentVersion\Uninstall
Topic: Teams password not saving. Using Citrix UPM with Fslogix Office 365 Container.
Brilliant article. I am hoping some of you have encountered this issue.
I am running Citrix Published Desktops, version 1912, with UPM and Fslogix for the Office 365 container. Thanks to many of you smart people, I have everything working smooth, except this issue. Teams username persists, but the password never saves.
I have tried every thing on the planet, all the UPM exclusions I can find.
Any help would be greatly appreciated.
Do you have the GPO configured to save the Office token? Also do you have FSLogix configured to save the Office licensing data?
James,
Thank you so much for responding. I do have the FSLogix configured to save the Office licensing data. However, this is the first time I have heard of the GPO setting to save the Office token.
I do see the GPO setting. Where do you normally save that to? Do you just drop into their Profile somewhere or in they home directory?
Thanks again.
Good morning, James. Sorry to bother you again.
I setup the GPO and set the path to %appdata%\Microsoft\Office\16.0\Licensing.
I verified the files are now created in that path. and the sclcacheoverride and sclcacheoveridedirectory regkeys are present and correct.
However, TEAMs is still not saving the password. Any thoughts?
I really appreciate your time. Thanks.
James,
Great Article, I wish I had seen it before I started testing for our Deploymen Package :(. I did have a question or 3 though lol, in regards to Microsoft’s latest instructions.
1. They say to target the SYSTEM with your SCCM Package, and take the defaults once it reads the MSI, but the defaults install for USER. Do you suggest that method for Desktop’s with roaming profiles (some roaming, Laptops are local)?
2. Are you seeing a long start up time for the App? Our testing is showing at LEAST 1 minute of start up time (We still have the App loading the default way, not in the background, for testing.
3. If we utilize the ALLUSER command llike is documented for VDI, to install to the Program File X86 directory, I know we lose auto-upgrades, but is there any additional performance hits we have to worry about? We are considering the overhead of deploying that way to PC’s and Laptops for this question, not for VDI. VDI I believe will definitely utilize this functionality.
Thanks!
1. I’d use the user-based install for desktops and laptops, unless you specifically want to align the version.
2. No, it seems pretty quick for us (as quick as Teams gets, anyway)
3. Nope, we haven’t noticed any performance hits – YMMV
James, before I found this blog I did a ton of testing myself, and one issue I found with the Install under the User Context is if it is a roaming user, and another user UNINSTALLs, it does not REALLY get it uninstalled from the System, because it was originally installed under the other user’s context I suspect. I even tried using my local admin account to uninstall, and it appears to work until you try to reinstall from your deployment tool, as it still recognizes the MSI GUID at the System Context. To test this I logged back in after uninstalling as Admin AND SYSTEM context using psexec.exe, and when the original installing user logged in, the Teams machine Wide Installer was in my Programs folder.
To fix this test box, I had to manually install the Application using SYSTEM context, and then uninstall it with the typical method, and at that point SCCM recognized it was no longer installed and would redeploy it.
Now this behavior MAY be because I did not use the ALLUSERS=1 switch, as we decided in our enterprise we did NOT want to let end users uninstall if at all possible, since the cleaning and reinstall is not seamless and we again see added difficulty because we wipe our local profile on every logoff, so users who had installs locally no longer have an appdata folder for us to target with uninstalls, BUT their are lingering registry entries we suspect. We decided our best course was to do all we could do to prevent an uninstall, and if one is required, let it be done by Help Desk who has admin rights and can use my Method of manual install and uninstall to truly clean the box and redeploy to it (from a Teams deployment perspective anyway, we cant reimage every box this happens to).
Note on the install switches, we are testing again today 5/28/2021 with version 1.4.00.8872 of the MSI. The Switch for OPTIONS=”noAutoStart=true” actually works exactly like Microsoft says it does, it just isn’t as we understood it to work at first. It DOES autoinstall for every user, but prevents the App from Autostarting on login until it is manually started the first time. I confirmed on 3 accounts this behavior, and then went back to their website and read it again and realized it behaves exactly like they describe at “https://docs.microsoft.com/en-us/microsoftteams/msi-deployment” under the “Disable auto launch for the MSI installer” topic.
“When a user logs in to Windows, Teams is installed with the MSI and a shortcut to start Teams is added to the user’s desktop. Teams won’t start until the user manually starts Teams. After the user manually starts Teams, Teams automatically starts whenever the user logs in.”
Our goal is to prevent the Auto Install from happening period, by using your method leveraging Ivanti and we are even going to block access to the EXE and hide it for users who are not in our beta/deployment access group yet, hopefully. That is our goal anyway. We also plan to use Ivanti to perform the install for users who are provisioned for access, so to them it is automated. We further plan to utilize your setting for starting in the background.
Thanks again for such a detailed break down of this confusing and problematic application. Even with all my testing, I learned more reading through your blog!
Hi
Thank you for this articles. Sorry for my english
I install et configure Teams on my Citrix environnement.
I have a problem with “planifiy a new visio”.
If teams not starting on Citrix (session user) when i want to planify a new visio teams the link of this visio teams is blank
Any idea?
I don’t want to start teams in a session citrix for all users.
James,
I’m testing the machine wide installed on a non persistent Windows 10 desktop. I use Liquidwares profile disk and the machine wide installer is pushed via flexapp. Our default profile disk size is 6 gb.
During testing Teams works fine for a time, then eventually stops or closes, when I try to reopen it says there isnt enough disk space. I see the note you made about the install cache 5gb of files in the user profile and assume this is the reason
How does someone with a profile disk work with that. Giving my Teams users 10gb profiles seems like a little much.
Thanks
Hi John
Either compact the VHD using one of the scripts out there (I recommend Jim Moyle’s), or simply give them bigger disks. I size my profiles up to 50GB.
Hi James,
I have followed your teams installation procedure, i tried to install via local admin but teama cannot be opened in all user(except local admin) only appears briefly in the task manager then teams dissapear, i tried to reinstall teams in the golden image through 1 regular user teams can be opened and work but still fail if opened using another user, i tried to check in the roaming profile it turned out that only 1 user got the folder in %AppData%Microsoft%Teams, then i try to copy the folder and move it to some users, after some users get the Teams folder, those teams can work. my question is why don’t all users get the folder after it is installed via golden image?
That folder should be created when the user runs Teams, not at install. I would check that you installed with the correct switches.
thanks james,
now i know my teams problem, it turns out that there is a former teams shortcut stuck in my roaming profile so that the teams folder cannot be created automatically when the user logs in.
I am installing teams into a Citrix 7.x FSLOGIX profiles hosted desktop environment. If we do just ALLUSERS then we get the meeting addin and 500mb of data in every profile. If we use BOTH ALLUSERS and ALLUSER we don’t get any data in the profile BUT the meeting-addin goes missing. My boss is not amused. Is there a solution I’m missing here or some switches? I think I’ve read every article on the internet so far. Noone addresses this.
Are you talking about the addin for Outlook? Are you installing Teams before or after Microsoft Office? We install both Teams and Office via Chocolatey, FSLogix too, and the add-in is always present using both the switches. I also don’t understand what you mean about “don’t get any data in the profile” – when you install the Machine Installer, you shouldn’t get any data in the profile until the user logs in and launches Teams.
Hi James,
I have an issue in non persistant environment where i installed teams as suggested with All user and All users key
However in Outlook recipient status of teams does not show up
Is there any fix you can suggest
Thank you
I know this is an older thread but the benefits of disabling auto-setup were discussed but not the caveats. Why would such a thing as auto-setup exist for a machine based install if its not really required?
I clearly misunderstood the article. You are disabling it from auto-starting not the auto-setup. For my implementation (still in progress) I will remove the startup from HKLM and use WEM for the adding to the user startup (based on existing json file). I’m not clear why I would ever delete the entry from startup for users (your second registry tweak)
Why would you remove the auto-start? To stop Teams using resources it doesn’t need to and impacting performance. IMO users should launch applications when they need them, not start them all at logon.