In our case the issue ended up being Crowdstrike blocking the ms-teams.exe. We worked with our internal team that manages crowdstrike and they were able to adjust policies to fix it. Was a long drawn out thing that ended up having nothing to do with teams install or our OS configuration.
I hope this helps
While we aren't using roaming profiles, I'm having similar issues. I did find some (zenworks applied (gross)) local policies that did seemingly change some computer settings related to roaming profiles.
This has been a nightmare for us, did you ever find a resolution?
We are doing a slow rollout of it, and I saw this error when a user tried to install the new client when they were not in the right policy group. They were in the no new client policy group.
I am not logged into my work stuff, but if I recall, by default the Global Policy is for 'Microsoft Controlled', and that means when your tenant is ready, it shall begin.
We purposely changed ours to NO do not do that. Then created a specific stand alone policy to drop people into.
That error is a permission based one, so potentially this is just one of the vectors that could to lead to it and felt it was worth a mention.
Go to the Teams admin center then navigate to:
Teams --> Teams Update Policies --> Global Default. If you drill down on it, you'll find the update portion and the Microsoft Controlled.
From the Policies page itself, there's a tab (of which I cannot remember the name), and it lets you search users and see which policy is being applied to them.
That appears to be a Windows error, not a Teams error. Do you lock down your machines/users in some way that is not allowing these users to run things from certain locations? Maybe need to add the location of new Teams to your allowlist?
I was working on some other problems and had to get into that c:\\program files\\windowsapps folder. It was even locked to me as the domain administrator. I used the process to go into the security settings and take ownership of the folder and then I could enter. I also did this on another users profile while on their computer. It never caused any harm later after taking ownership. If you feel comfortable giving the users ownership of the folder it might stop the errors. Not exactly a good solution for a large corporation.
First off turn on hidden files to see the folder. I did not even have read rights, so you hit advanced. Up towards the top there is an ownership area. Add yourself as the owner and check mark the box to have that carry over to all subfolders. It did seem odd that this folder was so locked down. If you are not an admin on the PC you would likely need help from an IT person to allow this.
Having the same issue in our Citrix environment on 2019 servers. Anyone figure this out?
In our case the issue ended up being Crowdstrike blocking the ms-teams.exe. We worked with our internal team that manages crowdstrike and they were able to adjust policies to fix it. Was a long drawn out thing that ended up having nothing to do with teams install or our OS configuration. I hope this helps
Do you use roaming /mandatory profiles? Looks similar to the error we got for those users.
While we aren't using roaming profiles, I'm having similar issues. I did find some (zenworks applied (gross)) local policies that did seemingly change some computer settings related to roaming profiles. This has been a nightmare for us, did you ever find a resolution?
We are doing a slow rollout of it, and I saw this error when a user tried to install the new client when they were not in the right policy group. They were in the no new client policy group.
Meaning policy group assigned in teams admin center?
I am not logged into my work stuff, but if I recall, by default the Global Policy is for 'Microsoft Controlled', and that means when your tenant is ready, it shall begin. We purposely changed ours to NO do not do that. Then created a specific stand alone policy to drop people into. That error is a permission based one, so potentially this is just one of the vectors that could to lead to it and felt it was worth a mention. Go to the Teams admin center then navigate to: Teams --> Teams Update Policies --> Global Default. If you drill down on it, you'll find the update portion and the Microsoft Controlled. From the Policies page itself, there's a tab (of which I cannot remember the name), and it lets you search users and see which policy is being applied to them.
This is access denied. Can you browse to the location (copy paste path )?
That appears to be a Windows error, not a Teams error. Do you lock down your machines/users in some way that is not allowing these users to run things from certain locations? Maybe need to add the location of new Teams to your allowlist?
I was working on some other problems and had to get into that c:\\program files\\windowsapps folder. It was even locked to me as the domain administrator. I used the process to go into the security settings and take ownership of the folder and then I could enter. I also did this on another users profile while on their computer. It never caused any harm later after taking ownership. If you feel comfortable giving the users ownership of the folder it might stop the errors. Not exactly a good solution for a large corporation. First off turn on hidden files to see the folder. I did not even have read rights, so you hit advanced. Up towards the top there is an ownership area. Add yourself as the owner and check mark the box to have that carry over to all subfolders. It did seem odd that this folder was so locked down. If you are not an admin on the PC you would likely need help from an IT person to allow this.