Officedocs-skypeforbusiness: Location of install directory for users

[kfl64]

Hi.
In your documentation the install directory is referred to as %localappdata%\Microsoft\Teams\,
Under install I see the install directory as C:\ProgramData\kfl\Microsoft\Teams, install updated but not documentation?
When I check the user rights for C:\ProgramData\kfl\Microsoft\Teams I see that local users group has write access to the folder. Since domain users is a member of this group, it means that all users from the domain can overwrite update.exe in the Teams folder and replace it with a “bad” file, not good from a security perspective.
This would not be the case if the install was in %localappdata%\Microsoft\Teams.
In general I would like to handle Teams application like any other application in a enterprise environment, install to c:\program files (x86), and the patch it the way we patch all other applications.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 7b13006b-d1de-8bc7-e0c6-b7022af0e731
• Version Independent ID: d29dae65-bb28-8767-cfd7-07d2ed5fd460
• Content: Install Microsoft Teams using MSI
• Content Source: Teams/msi-deployment.md
• Service: msteams
• GitHub Login: @ninadara
• Microsoft Alias: ninadara

[koenvb]

Will this make it possible to install the teams application in a terminal server environment? Thanks for the clarification.

[AJ-Acevedo]

Two things:

1. The MSI has not been very reliable. It only successfully deployed on a small percentage of the Windows 7 computers.
2. The below document indicates that Teams is installed in the following two locations.
   %appdata%\local\Microsoft\Teams
   %appdata%\roaming\Microsoft\Teams

https://docs.microsoft.com/en-us/microsoftteams/get-clients

[bgiacaman]

Let's not forget about SquirrelTemp please. In our findings, the following locations need to be allowed for Teams to run properly:

%AppData%\Microsoft\Teams
%LocalAppData%\Microsoft\Teams
%LocalAppData%\Microsoft\TeamsMeetingAddin

C:\Users\%username%\AppData\Local\SquirrelTemp\
C:\ProgramData\%username%\SquirrelTemp\
C:\Users\%username%\AppData\Local\Microsoft\Teams\current\Squirrel.exe

SquirrelTemp is used to actually install Teams.

Microsoft: Get your act together please! Teams is all over the place. Please make it install and run from C:\Program Files and have user data go to the AppData folder for the user. No need to actually RUN Teams from the user's side of things! Think Enterprise-like! Please...

[tonysmit]

Hey everyone. I'm investigating this so please be patient. I'm looking for PM owners so they can respond to these queries. Thanks, Tony

[tonysmit]

No apologies necessary! I just wanted everyone to know that I’m reaching out to the owners of install and setup to get some answers for you!

From: mconwell [e-mail]
Sent: Tuesday, April 17, 2018 8:37 AM
To: MicrosoftDocs/OfficeDocs-SkypeForBusiness [e-mail]
Cc: Tony Smith [e-mail]; Assign [e-mail]
Subject: Re: [MicrosoftDocs/OfficeDocs-SkypeForBusiness] Location of install directory for users (#101)

Sorry - getting used to this new comment system

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2FOfficeDocs-SkypeForBusiness%2Fissues%2F101%23issuecomment-382037958&data=02%7C01%7CTony.Smith%40microsoft.com%7Cf5026e5f4a6b476e8cb608d5a4790322%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636595762006000219&sdata=mKfYryRU82xWWuBmDECDzD0ZZLVeRr00ZUcEUpCTaeA%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAdlCbmz9KK-mqq_wNxXh3JhrMdk3HNRjks5tpgwGgaJpZM4TJpzm&data=02%7C01%7CTony.Smith%40microsoft.com%7Cf5026e5f4a6b476e8cb608d5a4790322%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636595762006010228&sdata=VhVhgz61curciGozZFcPs2ofjTIvokjfwKj0gjQJHcA%3D&reserved=0.

[tonysmit]

Checking in - Still trying to locate an owner on the PG side.

[ericgryan]

Hi,

I'm currently trying to deploy this using a company PowerShell script to Software Center. Is there a commandline for installing to the user logged on without logging off or restarting? We seem to have issues deploying this application. Initially tested with the .EXE version of the install but that does not seem to properly install.

[bgiacaman]

@ericgryan We deployed it the same way. Put on the script that after install of the crappy MSI from Microsoft, to create and run a scheduled task to run the Teams Installer .exe from C:\Program Files (x86)\Teams Installer (it goes to this directory even though one might install the 64-bit version; c'mon Microsoft!). This scheduled task gets ran as the user, and mimics what happens upon logon of the user. Once the task finishes, then it gets deleted per the script. Hope that helps!

[ericgryan]

@bgiacaman Even if users reboot, or log off and come back in. It seems that the MSI still does not work in that situation. Do you perhaps have a code snip for that task scheduler sequence you can share?

[mconwell]

I have successfully used the Microsoft Teams MSI to install Teams to new Windows 10 images. No issues, but the MSI is definitely different than a standard MSI (read the docs) but it has worked for us.

Installation was straightforward:
msiexec.exe /i Teams_windows_x64.msi /qn reboot=reallysupress

I have not used the Teams removal/cleanup script, so I cannot comment on that. I also have not attempted to deploy teams to an existing computer.

We could not use the EXE because that is a per-user installation.

[ericgryan]

That's basically what I've been using to deploy but we are using current images and users have to go to Software Center and initialize the install through there. So i'm wondering if theres an argument for the MSI that will trigger it to install on the active user session. The EXE does not seem to work for us in that situation.

[mconwell]

From the documentation, it seems to indicated that the MSI will place the installer so that when a user logs into the machine it tries to determine if Teams is installed and if not it will run the installer. Then the app is installed for the user after the user logs out and then back into the computer.

There does seem to be a "gotcha" if the user had previously had Teams installed. Even after uninstalling it leaves traces that fools the MSI into thinking the program is still installed.

MS says:

1. Uninstall Teams App installed for every user profile
2. After uninstall, delete directory recursively under %localappdata%\Microsoft\Teams\
3. Redeploy the MSI package to that particular machine

MS has a script available to do steps 1 & 2

I have not tried this though. Good luck.

[tonysmit]

Hey everyone! Thanks for the feedback! I'm trying to locate a PM to answer your questions. I will report back to this thread. Appreciate your patience. Thanks, Tony

[tonysmit]

I've assigned two PMs from the product group to lend you a hand. We appreciate the feedback. If there are addition/corrections/suggestions to the docs, please edit the topic by clicking Edit (on the right side of the topic) or use VsCode/GtiHub desktop. Let me know how I can help further.

[ericgryan]

For me, the real issue here is just a matter of the software being coded so that:

1. It writes like a normal 64 or 32 bit application to Program Files Directory.
2. It installs all it's components and shortcuts even if it fails to connect to the internet for the first time.

The reasoning behind these two previous premises is that a great amount of IT infrastructures have certain restrictions to prevent writing to APPDATA folders. Also since we might need to adjust the firewall rules in order to allow the program to run, it is better to troubleshoot any exceptions while the program is fully installed.

[tonysmit]

@juturu and @voltarone for awareness.

[tonysmit]

@juturu and @voltarone Do you have any feedback on this issue? If you are assign an issue, you must help the customer find a resolution. If it's a bug for engineering create a bug for them, if not and a topic needs updated, you can fix the article and issue a PR. Lastly, if it's a no repo or can't be fixed, then let the customer know and close this out.

[bgiacaman]

Anything on this yet?? We've now realized that we are not able to open up Teams.exe from the User's AppData folder in the firewall because since the firewall is running as the system, it does not recognize user-specific system variables like %userprofile%, %localAppData%, etc. This MSI REALLY needs to change! Here's the solution we NEED, Microsoft:

• Install and RUN Teams.exe from %ProgramFiles%
• Put user data in %localAppData%; no need to copy the EXE there and run from there.

Once Teams.exe is put in the %ProgramFiles%, we will be able to open up the program in the firewall to run as intended. PLEASE HELP!!

[CDjgould]

Agree with everyone else. Please install to ProgramFiles and store user specific settings to AppData. That is how it SHOULD have been from the start. This MSI does little to nothing of solving the problem with Teams in a business/education environment. The way it is now makes it seem like the installation process was decided by some hipster coders who can't comprehend why it's a problem. There is a reason things are done the way they have been for decades. Your ripping holes in system security. Stop it already before someone takes advantage.

[AJ-Acevedo]

Microsoft Teams should have two installers. The same way Google Chrome has two installers. The basic installer should allow any user without admin credentials to install the app in AppData. But the MSI should behave similar to Google Chrome Browser for Enterprise. It allows an admin to deploy the app in ProgramFiles for any user that logs onto the computer.

[absentspace]

RTFM!

[Hicsy]

as @ericgryan pointed out on May 4... a key issue for many of you is that the x64 MSI still "chucks" the Teams.exe installer in
C:\Program Files (x86)\Teams Installer\
It may rightfully BE a 32-bit exe that runs the installer (haven't bothered to check) but then the reg RUN key points to an invalid directory:
HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\
TeamsMachineInstaller : C:\Program Files\Teams Installer\Teams.exe --checkInstall --source=default

[CIGAdmin]

Just got news about installing in Program Files. However, reading here, it looks like the installer just install the installation files in the Program Files and, once user logs in, execute to install in user's AppData folder. While storing data in AppData is fine, my Software Restriction Policy prohibits running executables from AppData. The main program must be installed in Program Files. That was the goal. Is this not made? Then it's still useless in Enterprise environment.

[nidelius]

Ugly workaround:
Whitelist install location for endusers %localappdata%\Microsoft\Teams\current and the two exe:s squirrel.exe and teams.exe AND
%localappdata%\Microsoft\Teams\update.exe

To enhance security, let AV know the current hashes and let %localappdata%\Microsoft\Teams\update.exe update squirrel.exe and teams.exe
Use a staging or preproduction environment to log in as a enduser, to check for in and outgoing traffic and allow it in firewall.
But there might be more connections added when plugins and other services are added to teams anyway.

Use fiddler 4 to check for connections https://www.telerik.com/fiddler

[bgiacaman]

They have closed the UserVoice request to change the install locations citing this article. Again, this method of install is NOT secure nor ideal. Microsoft: This MSI REALLY needs to change! Here's the solution we NEED, Microsoft, here's what we need the MSI to do:

• Install and RUN Teams.exe from %ProgramFiles%
• Put user data in %localAppData%; no need to copy the EXE there and run from there.

Once Teams.exe (not the installer but the actual end-user software) is put in the %ProgramFiles% directory, we will be able to open up the program in the firewall to run as intended. PLEASE HELP!!

[bgiacaman]

This is the UserVoice request they marked as closed :(

https://microsoftteams.uservoice.com/forums/555103-public/suggestions/17380159-improve-install-options-install-for-all-users-an?tracking_code=5ab634aa39ce2102495413ce97a86648#{toggle_previous_statuses}

[kenwith]

@bgiacaman - I am going to surface this to the Teams group.. it sounds like the User Voice that was closed wasn't satisfactory?

[CIGAdmin]

Definitely did not meet the basic criteria for Enterprise users, which is to install the main program in ProgramFile once, not in each user’s AppData. Program in ProgramFile, data in AppData.

[CDjgould]

Agreed with others. The requirements of installs for Enterprise (install the actual application to Program Files NOT AppData) has not been met and will continue to prevent adoption of these products. Unfortunately I think the teams over at Microsoft understand the issue but don't actually want to solve it. They have taken the approach, like a few other devs, that there is "no problem" with it being installed for every user in AppData. Which is just plan wrong. It's an issue logistically for anyone running VDI. And an issue security wise for anyone that needs to run a locked down domain.

[bgiacaman]

@kenwith exactly! It was totally not satisfactory and comments are closed for it. Please have it reopened. I also created another UserVoice request for the same thing but it did not have much votes to get noticed like the one they closed :/

[kenwith]

Just a quick update. I am following up with Warren who manages the User Voice.

[AJ-Acevedo]

I share the same sentiment as others have expressed. The current Microsoft Teams installer does not meet the needs of Enterprise customers with an Enterprise deployment strategy.

[WarrenMicrosoftTeams]

Thank you for the feedback and our Microsoft Teams feature team have seen your feedback. Allow me to provide a response from the feature team.

1. Why Teams App is NOT installed in Program Files (aka per Machine)?
   The goal was to ensure we provide our users with newest features and fixes as quickly as possible and ensure all users are getting the best experience possible from Microsoft Teams.

Therefore, we don’t limit the ability to update the software by requiring only IT Admin credentials. Unfortunately, if the product were installed under Program Files, that is exactly what would happen. Software under Program Files requires IT admin credentials and the updates would need to be managed per user which in turn would be a lot of overhead due to the frequency of updates to Microsoft Teams.

1. Why Not follow Office Installation Practice?
   All Office apps require admin credentials to install & update. Office products are updated at a much slower rate than Teams. We are actively creating updates and new features as quickly as possible and having an admin prompt pop due to updates either several times a week or sometimes daily when in Teams would be frustrating for users.

Also, most managed deployments of Office happen via SCCM (msi based) which is handled by IT admins. The process is a system service and an install would not prompt the user for admin credentials. Once the installation is complete all future updates are handled by SCCM. If IT admins were required to handle weekly SCCM for various updates, this too would be frustrating/annoying.

The overall goal is to try and make the installation as painless as possible while enabling our ability to keep Teams updated in a timely fashion without placing undo burden on IT admins within organizations.

[CIGAdmin]

The problem with your resolution is that it runs smack against Software Restriction Policies. Most, if not all, Enterprise setting have prohibited running software out of AppData and Temp folders. Worse, having 100s copies of Teams App on a single RDS server is ridiculous. Thus, Enterprise users will not be allowed to use Teams App until this is corrected. Microsoft needs to think like an Enterprise firm.

[CDjgould]

Fine, then know that Teams will NEVER be used by a large number of Corporate entities.

Installing to AppData conflicts with Security Policies. To make matters worse you can't even whitelists the applications through other means like Certificate or Hash. It also tries to VIOLATE the very security measures put in place to protect my end users. It also conflicts with any RDS or VDI environment which is a MAJOR ISSUE.

Your "solution" for Teams installation simply doesn't work in a multitude of environments. If the group at Teams doesn't see that as a problem then I guess I don't see their product having a place in my environments.

Perhaps you should rethink your "deliver updates and fixes as quickly as possible" strategy. Maybe align more with all the rest of Microsoft Office products. Staged and thoroughly tested updates that LIMIT bugs.

Also, I've been pushing against this practice for a few years now. There are threads in the Microsoft Forums about this very topic and how your "allowing end users to update apps without Admin rights" not only is a security issue, but that it also doesn't even work correctly. For instance there was a user that ran into registry issues/permission problems because of this "deployment strategy".

But at this point I'm moving on from Teams ever being a viable option, so feel free to just ignore this customer.

[kenwith]

@WarrenMicrosoftTeams - do you think it is possible to open a User Voice for a feature request to install in Program Files?

[voltarone]

I the specific of issue with Program Files is part of our deployment story; and as such, this falls already into the IT Admin support deployment with MSI Installer.

If we open a separate UV around that, we are breaking down the feedback around our deployment.

That said, I would recommend to open a separate UV for shared device (aka, VDI, RDS, etc.).

From: Ken Withee [e-mail]
Sent: Tuesday, July 31, 2018 12:09 PM
To: MicrosoftDocs/OfficeDocs-SkypeForBusiness [e-mail]
Cc: Ram Farhi [e-mail]; Mention [e-mail]
Subject: Re: [MicrosoftDocs/OfficeDocs-SkypeForBusiness] Location of install directory for users (#101)

@WarrenMicrosoftTeamshttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWarrenMicrosoftTeams&data=02%7C01%7CRam.Farhi%40microsoft.com%7Cb59e8f137c8f4a70acb908d5f7190d2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636686609327468492&sdata=8ZqlducwWeVYDANprQr9Oi%2FWa58sM982mbrjEOFI%2Fk4%3D&reserved=0 - do you think it is possible to open a User Voice for a feature request to install in Program Files?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2FOfficeDocs-SkypeForBusiness%2Fissues%2F101%23issuecomment-409333359&data=02%7C01%7CRam.Farhi%40microsoft.com%7Cb59e8f137c8f4a70acb908d5f7190d2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636686609327468492&sdata=nqnJd9IHyxPaHGzooJZg41IARNmkLBhYxMH2QcxHMwQ%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAk_x58KtvEYi75M58Ov6kH7VsxcrYhKaks5uMKtCgaJpZM4TJpzm&data=02%7C01%7CRam.Farhi%40microsoft.com%7Cb59e8f137c8f4a70acb908d5f7190d2e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636686609327468492&sdata=04ByRiEH%2FdIKSw%2FwvMxIqiglpbyN9I9UjgO6A%2BEpm%2Bc%3D&reserved=0.

[ChrisKubiak]

@WarrenMicrosoftTeams - Our organization also falls into the "Install to Program Files" camp. Between this thread and other topics on the UserVoice site there appears to be two primary concerns from Enterprise customers with regards to the current installer practice, Terminal Services and Application Whitelisting. What about having the Teams PG work with or solicit feedback from the PG responsible for Terminal Services and features like SRP\AppLocker . Perhaps working with them directly they might help expose how the intent of "make the installation as painless as possible" may be falling a bit short for at least some Enterprise customers. With any luck perhaps they may be able to make some suggestions that may offer a middle ground that still allows the Teams PG to "update in a timely fashion" while giving us the tools we need to perform our job.

[bgiacaman]

@voltarone : there was a user voice opened for this request but it was marked as complete and closed by @WarrenMicrosoftTeams.

Here's the link: https://microsoftteams.uservoice.com/forums/555103-public/suggestions/17380159-improve-install-options-install-for-all-users

[bgiacaman]

@WarrenMicrosoftTeams:
The response you provided from the feature team is inconceivable. It seems like no one there has ever worked in a true enterprise environment with SRPs/GPOs/Firewalls, etc. No one in an enterprise environment would ever think about running a software from the user's AppData; this idea even goes against Microsoft's own standards and practices. See OneDrive, Dropbox, and even Google had to provide the same change when they released their MSI package for enterprise environments. What we are asking for is not unreasonable and it is not impossible. What we need is for the MSI package for Teams to behave differently then the public's. We need the app to be redesigned to stop trying to load EXEs in the user's AppData path, and also stop defaulting the update process to go and run from there.

The MSI should:

1. Install the EXE in the Program Files directory (not a Teams Installer, but the actual Teams app EXE)
2. Store and reference user files (like settings, and other data) in the user's AppData path.
3. Redesign the behavior of the auto-update to put the downloaded update wherever the Teams app EXE is installed in (i.e. C:\Program Files\Microsoft Teams\DownloadedUpdate); as IT admins we can allow this path or specific EXEs running from this path to be allowed to function without administrator credentials.

Having the Teams' MSI standardized with the industry's practices will allow us as IT Admins to manage the app better across our domains. We would be able to create SRP rules for the software, as well as allow it through the firewall (something that we can't currently do, since we can't reference user variables as system variables in firewall rules because of a Microsoft limitation). Doing this will truly help us make the installation as painless as possible while enabling your ability to keep Teams updated in a timely fashion.

Thank you!

[AJ-Acevedo]

So essentially, Microsoft is saying screw you and your corporate policies, we're going to do it our way! Thanks Microsoft.

[kenwith]

Hi All, I just noticed there is an AMA for the Teams product team tomorrow (Thursday, Aug 9) and it might be a good opportunity to bring up regarding the install directory and how it works with corporate policies. Here is the link: https://techcommunity.microsoft.com/t5/Microsoft-Teams-AMA/Announcing-a-Microsoft-Teams-AMA/m-p/216192#M1957

I will keep this thread open too and if anyone knows of a User Voice that we can link let's link it in here so we can add the up votes.

[bernardw1]

As someone from a small company but we do use RDS/Terminal Services quite heavily, I really don't like the option of having Microsoft Teams installed 100 - 200 times so that people can use it in the RDS environment. That just feels like a waste of hard drive space and a nightmare to manage.

Additionally with Application White Listing turned on Teams will not run in it's normal way.

I guess we will not be using MS Teams in our Terminal Services environment which means it will not be utilized a good portion of the company.

[KyleSchroeder]

Left a comment here; I suspect many of you in this thread will understand:
https://github.com/MicrosoftDocs/msteams-docs/issues/238#issuecomment-422090416

[kenwith]

Hi All, I am going to close this thread since this repo is for the docs. Any comment here will re-open this thread though so anyone with updates or requests for action from the community is welcome (example - if there is a user voice we can all up-vote feel free to post).

On a note, I know this issue is high on the radar of the product team and I ask about it every chance I get.

[atiq-cs]

https://microsoftteams.uservoice.com/forums/555103-public/suggestions/34768153-improve-install-options-install-for-all-users-an

[SerdarSoysal]

Thank you for posting the uservoice. We'll continue to track this issue there.

[Ruud-Mens]

I have the same issue as @kfl64, Teams is installed the *c:\programdata\*Microsoft\Teams and not in the Local AppData as the documentation suggests. I searched everywhere, but can't find anything on why it install in the programdata\username folder.

The only thing I can think of is that our Software Restriction Policy. We block every .exe in the user profiles, so Teams can't install there after the users logs in. Can anyone confirm this or point me in the right direction why Teams isn't installed in the "correct" location.

[CIGAdmin]

Microsoft finally made it enterprise-friendly. I have the full Remote Desktop Server package (RDG, RDCB, RDSH), including User Profile Disk (UPD) and Software Restriction Policies (SRP) yet I got this to work today with the enterprise-friendly installation. You can read about it at https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi. There are a few items to tweak, though:

1. Installation will fail unless you create a registry key, if one doesn't already exists, for either:
   a. HKLM\SOFTWARE\VMware, Inc.\VMware VDM\Agent, or
   b. HKLM\Software\Citrix\PortICA

If you do not want to auto-start this for everyone (I had another group that doesn't use it at all and it annoys them every time they log in):

1. After installation, delete the registry value Teams from HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run. Do not delete the other two TeamsMachineUninstaller* values.

2. If the user wants it to auto-start (unfortunately, Teams didn't have its own auto-start option), do these:
   a. Right-click Start Menu (Windows logo key) and select "Run".
   b. Enter "shell:startup" and press Enter. This opens up you your Startup folder.
   c. Click Start Menu, scroll down to Microsoft Corporation, drag Teams to your Startup folder.

Enjoy!

[CDjgould]

@CIGAdmin I'm going to try this today! If this works you are a life saver.

I saw they released it for VDI/RDS environments so I had high hopes that shortly after they would release it for regular desktop users and finally resolve this issue. My initial attempts to install the VDI/RDS based installer on a regular desktop had failed.

They just recently as part of updates to Office365 they began pushing Teams to users without opt-in. The method they use is the "drop the installer in Program Files, run on user login, and install to AppData". Which was blocked by my SRP policies. No doubt this is a push to move everyone away from Skype with it being phased out soon.

I figured there had to be some "detection" method and way to trick the installer. Sounds like it's just this reg key.

Also, there are GPO methods (or reg keys) you can use now to prevent the auto installation of Teams or prevent it from running on first install. See https://docs.microsoft.com/en-us/DeployOffice/teams-install

[CDjgould]

Yep, that worked! Added HKLM\SOFTWARE\VMware, Inc.\VMware VDM\Agent and installer worked no problem!

[daBONDi]

2020 still same shit.

Workaround a fucking msi wrapper not fixing anything

[CIGAdmin]

@daBONDI are you trying to install it on RDSH? I have had mine working since Aug 2019. Did you follow all the steps I outlined? What kind of issue are you having?

[daBONDi]

@CIGAdmin i want to install it on User Desktop(Education Envrionment) Roaming Profiles/Shared Computer, and so on, found a workaround with preseeded registry keys to fake a RDSH environment with an mst transformfile to mitigate that shit until ms get his shit together and learn to write software again.

The steps you mention are workarounds, and not a solution!

if ms thinks this is a enterprise product they realy need to rethink there installer...

[CIGAdmin]

@daBONDi, yeah, @CDjgould wanted machine-specific installation of Teams on his desktops as well. The registry hack is what allowed us to use the machine-specific installation where there's no Citrix nor VMware. I had to also use this hack even though I have a native RDS setup; Microsoft didn't think about their own RDS!

[pcunite]

Please respect the security of the environment. Allow Teams to run from a locked down directory. Thank you.

[CIGAdmin]

Allow Teams to run from a locked down directory.

@pcunite, are you using the machine-specific installation of Teams? If so, it's normally run under "C:\Program Files (x86)\Microsoft\Teams\current". That folder is read-only to my users and they're using Teams on RDS with UPD and SRP. See earlier instructions on how to get machine-specific Teams installed on your RDS server.

If you are using the user-specific installation of Teams (by far, the default), then it runs under user's own AppData folder. Normally not locked down but my SRP prevents running programs from anywhere but the Program Files and Windows folders, unless their certificates have been whitelisted within SRP.

Good luck getting yours up and running, whatever platform you are using (PC or RDS).

[JaredSysAdmin]

@CIGAdmin

I have installed the teams in the program data files following your directions but the installer is still failing for users. I am running vmware virtual windows server 2019. I must be doing something wrong but for the life of me cant figure it out. It looks like it is only installing the teams installer in program files and not the actual application.

[Leiter1212]

You need to check your GPO, and see if you have an SRP. If you have an SRP enabled and it blocks the appdata folder locations, Teams will install into programdata instead of appdata.

[CIGAdmin]

@JaredSysAdmin, you need to use the machine-wide installer. Make sure you read this thoroughly:
https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi#deploy-the-teams-desktop-app-to-the-vm
Pay attention to the switches needed to install these properly. Also, make sure you already edited your registry settings as I had instructed earlier in this thread. If you are installing this in a remote session as opposed to console session, be sure to do the usual CMD "change user /install" before installing and "change user /execute" after installing. GL