Has anyone installed Teams MSI or EXE on a non-persistent environment?
As I see it there are 4 potential options,
1. Install on Master image
2. Install as app stack
3. User install on Writable UIA Vol
4. Thin App
I have tried the first three and every time i log off and log back in Teams is gone and I haven't had success yet on an App stack or on the Master image. I wanted to start up a discussion on this so we could get this as stable as possible. I also am running windows 7 and need to install Workplace Joined to get the VM's in Azure AD as Hybrid Azure AD joined.
Sorry, I forget this: you need to create this shortcut configuration on UEM or DEM server:
Shortcut name: Microsoft Teams
Arguments: C:\Users\%username%\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe"
Start in: C:\Users\%username%\AppData\Local\Microsoft\Teams
Icon Path: C:\Users\%username%\AppData\Local\Microsoft\Teams\app.ico
Icon index: 0
Check run asynchronously
The shortcut you are creating is for a user-installed teams setup, not a machine-wide teams setup. If you install teams correctly using both ALLUSER=1 ALLUSERS=1 switches, there will be no teams.exe in the userprofile, but only in c:\program files (x86)\microsoft\teams\
If you have teams.exe in both userprofile and program files folder, you'll start getting teams crashes because the teams in userprofile will update itself and won't be the same version of the teams installed in program files anymore. Trust me, I've been there, it's a lot of work to get that right afterwards. Certainly on non-persistent VDI, you should not let users install Teams in their userprofile!
RachelW Concerning the DEM config, I can't help you, because we don't use it. We use FSLogix to store our profiles and that works very smooth.
I obtained that command from this article from Microsoft (Teams for Virtualized Desktop Infrastructure - Microsoft Teams | Microsoft Docs). The install command I posted regarding the install was from this article - per-machine, non-persistent desktop. I am a little confused as to your comment about it being per-user instead of per-machine. Can you help me understand what you mean?
When a user logs into your virtual desktop the first time, are they prompted to enter credentials? Currently, we are being prompted the first time and then after that it does not. Do you know how to not have it prompt the user and just use their credentials of the machine they are logged into?
Don't worry, I was confused too when I found out I installed it wrong...
Using the MSI switch ALLUSERS=1 the MSI package will install a teams.exe in c:\program files (x86)\microsoft\teams and create a registry RUN key in HKLM so that everytime a user logs on, that teams.exe is started. In fact, that teams.exe is not the Teams executable, but a teams setup, that will install the Teams package in the userprofile (%appdata%\microsoft\teams\...).
Problem with this setup, is that there will be a full teams setup in each userprofile that logs on to the server/vdi!
Another problem with this setup, is that every user will be able to update the teams installation in their userprofile and this will lead to teams crashes when the teams setup in c:\program files (x86)\... is a different version than the one installed in the userprofile. (we found out the hard way. All was fine for about 3 weeks, and then suddenly users started complaining their teams crashed when they started a video call)
However, if you setup the MSI with ALLUSER=1 ALLUSERS=1 Teams will effectively be installed in c:\program files (x86)\microsoft\teams and run from there. Only user data will be stored in the userprofile and the users will also NOT be able to update the teams installation (to update it, you have to uninstall and reinstall the latest version with the same switches on the master image).
This is also the preferred way to go when using non-persistent desktops. Users will not be able to update their teams installation and when they try to download teams and install it, it will just start the already installed teams from c:\program files (x86)\... but not actually install anything because it sees it's already there.
Hopefully this clears out some confusion 🙂
Thank you for the clarification. That is EXACTLY how ran the MSI on my image with ALLUSER=1 ALLUSERS=1. Both of those parameters were used when I installed Teams on my image. 🙂
Another question I have is this....like I said we are using UEM and I noticed the Microsoft Teams Archive file is rather large - 40 MB compressed. What can be done to reduce the size of that file? I just spent weeks getting the Chrome profiles reduced to a decent size and now the Teams profiles are large.
Any suggestions are appreciated.
Here's a link to the Teams guide + DEM attached is a Teams.zip which i havent full tested yet, but it looks promising. I think it's in this post here somewhere.
p.s If you have a link to a promising guide on how to reduce the chrome settings please message me. ^^
**Disclaimer, we don't use the latest version currently in production but I have tested this on a newer version but definitely not the latest version.
This is what I've determined needs to be captured under the Teams folder. These are the bare minimum from what I can tell that need to be captured, but this causes the index and cache to be rebuilt every time the user logs in. If you have low-performance VMs then you may want to consider capturing those folders as well but experiment with it.
This creates about a 200-300 kb zip file. The biggest contributor is the dictionaries file.
I've also spoken with Microsoft support and they also recommend capturing these settings as these are the location in which the AAD credentials are stored:
And making the following reg edits:
A big factor in capturing Teams seems to really be how your Office 365 environment is set up.
We use ADConnect to sync AD to AAD.
We do not do SSO, so the user auths in Office 365 directly.
We do use password sync both to and from Azure AD.
I've got it working great when installed in the master image. Try this below..
msiexec /i <path_to_msi> /l*v <install_logfile_name> ALLUSER=1 ALLUSERS=1
This process installs Teams to the Program Files (x86) folder on a 64-bit operating system and to the Program Files folder on a 32-bit operating system. At this point, the golden image setup is complete. Installing Teams per-machine is required for non-persistent setups.
The next interactive logon session starts Teams and asks for credentials.
Here's the page explaining it..Teams for Virtualized Desktop Infrastructure - Microsoft Teams | Microsoft Docs
Then just use DEM to capture the settings you want.
I have it working pretty well now as well using the steps outlined in M_W_'s post. One thing we seem to be seeing consistently is this:
1) At the first login to the virtual desktop, Teams launches successfully - no prompts for credentials, errors, etc.
2) Logging out of that desktop and grabbing a new one, the user is prompted to enter their password for Teams. Once they put that in, Teams launches successfully
3) Logging out again and grabbing a new desktop, Teams launches successfully - no prompts, errors, etc.
Question is: why does the user get prompted to enter their password the 2nd time they login to a virtual desktop?
Thank you for this. I am looking at it now and it appears to be quite the workout to get this setup. We currently do not have SSO setup for Azure AD.
I've gone through the steps and gotten to the point where I "update your Microsoft Teams application manifest". Where in the JSON (manifest) do we add the text they outline in the document?
Obviously we would need to put the correct ID and resource in but does it matter WHERE in the JSON file it is placed?
Lastly, step 3 "Get authentication token from your client-side code." What do we do with this step?
We deployed Teams as an App Stack using the instructions found in this article.
Basically, you need to fake Teams into thinking you are installing it on a Citrix machine (which is supported) by creating the following reg key.
And then run the installer from the command line as follows.
msiexec /i <path_to_msi> /l*v <install_logfile_name> ALLUSER=1
I install Teams in my golden image with the following command:
msiexec /i Teams_Windows_x64.msi /lv C:\Windows\Temp\Teams_install.log ALLUSER=1 ALLUSERS=1 OPTIONS="noAutoStart=true" /qb /norestart
DEM CONFIGURATION - import/export config:
However I found that using FSLogix in stead of DEM works better and faster.
The only thing which is needed is to enable the policy "Include Teams data in container" in "Computer Configuration - Policies - Administrative Templates - FSLogix - Office 365 Containers"
Hello - Thank you for the information. We did install Teams on our Golden Image as well with a similar command with the exception of the OPTIONS. What does the "noAutoStart" do?
I definitely want Teams to auto login and start for the user however I have just learned that for some of our users, Teams is launching FULL screen instead of minimized. For me and several other users it launches minimized. How do we control that? We would like to launch it minimized for all users.
That is a setting the user can set in their settings by clicking their profile icon and then under general.
It is set in the desktop-config.json file and the property is "openAsHidden": true | false
Interestingly enough, when I login to a VDI desktop Teams launches minimized and I do NOT have that option selected under General.
Looking in my desktop-config.json file in my Microsoft Teams Archive in UEM, I have this:
And as I mentioned, Teams loads minimized for me.
A co-worker says his Teams launches full screen and his desktop-config.json file looks like this: