none
Microsoft Teams folder redirecting to ProgramData and SRP query RRS feed

  • Question

  • Hi,

    I am testing FSLogix, as well as SRP (Software Restriction Policy).

    I have some queries;

    1.When logging into my test RDSH server using FSLogix policy, our Microsoft Teams machine-wide installer installs Teams into my profile, but it seems to place it in "C:\ProgramData\username\Microsoft\Teams

    When I go to %localappdata%, I do not see Teams here. Equally, the rest of my LocalAppData folder does not appear under ProgramData\username

    If I disable the FSLogix policy, and revert to using UPDs, the install path for Teams is correct; "C:\Users\username\AppData\Local\Microsoft\Teams"

    Can anyone think why FSLogix puts the Teams installation (and seemingly ONLY the Teams installation), into ProgramData?

    2. Has anyone used FSLogix profile containers with group policy Software Restriction Policies? If so, does it still work as expected, allowing you to set your SRP to block anything in either;

    %AppData%\*\*.exe

    %LocalAppData%\*\*.exe

    And have those executables be correctly blocked?

    Thanks

    James

    Monday, October 28, 2019 3:43 PM

All replies

  • Can anyone assist?

    Thanks

    James

    Tuesday, November 19, 2019 4:53 PM
  • Although I'm not familiar with SRP or why you're seeing the Teams application installed to ProgramData, I would recommend reinstalling teams with a proper machine-wide setup-- the way you're doing it is the "old" machine-wide way, where it would drop the per-user installer for Teams into Program Files and then run it for each user that logs in. The new way actually installs the full application to Program Files, which I'm guessing would allow you to more easily block it with SRP if needed (since it's an identical path for all users) and would no longer reside in either ProgramData or LocalAppData.

    For some reason MSDN forums still aren't letting me post links in my replies, but Microsoft has documentation on installing Teams machine-wide for VDIs. Essentially, you add the switch "ALLUSER=1" to msiexec when you install it on the server.


    Tuesday, November 19, 2019 7:16 PM
  • Hi,

    I am testing FSLogix, as well as SRP (Software Restriction Policy).

    I have some queries;

    1.When logging into my test RDSH server using FSLogix policy, our Microsoft Teams machine-wide installer installs Teams into my profile, but it seems to place it in "C:\ProgramData\username\Microsoft\Teams

    When I go to %localappdata%, I do not see Teams here. Equally, the rest of my LocalAppData folder does not appear under ProgramData\username

    If I disable the FSLogix policy, and revert to using UPDs, the install path for Teams is correct; "C:\Users\username\AppData\Local\Microsoft\Teams"

    Can anyone think why FSLogix puts the Teams installation (and seemingly ONLY the Teams installation), into ProgramData?

    2. Has anyone used FSLogix profile containers with group policy Software Restriction Policies? If so, does it still work as expected, allowing you to set your SRP to block anything in either;

    %AppData%\*\*.exe

    %LocalAppData%\*\*.exe

    And have those executables be correctly blocked?

    Thanks

    James

    I am currently investigating.  To my knowledge there is nothing in FSLogix that would explain why teams would be going to the ProgramData directory.  I will report back shortly.
    Tuesday, November 19, 2019 8:37 PM
  • Hi,

    I am testing FSLogix, as well as SRP (Software Restriction Policy).

    I have some queries;

    1.When logging into my test RDSH server using FSLogix policy, our Microsoft Teams machine-wide installer installs Teams into my profile, but it seems to place it in "C:\ProgramData\username\Microsoft\Teams

    When I go to %localappdata%, I do not see Teams here. Equally, the rest of my LocalAppData folder does not appear under ProgramData\username

    If I disable the FSLogix policy, and revert to using UPDs, the install path for Teams is correct; "C:\Users\username\AppData\Local\Microsoft\Teams"

    Can anyone think why FSLogix puts the Teams installation (and seemingly ONLY the Teams installation), into ProgramData?

    2. Has anyone used FSLogix profile containers with group policy Software Restriction Policies? If so, does it still work as expected, allowing you to set your SRP to block anything in either;

    %AppData%\*\*.exe

    %LocalAppData%\*\*.exe

    And have those executables be correctly blocked?

    Thanks

    James

    I am currently investigating.  To my knowledge there is nothing in FSLogix that would explain why teams would be going to the ProgramData directory.  I will report back shortly.

    I will definitely need more information.  FSLogix should not be causing this.  A few thoughts.  Is it possible that you have used FSLogix redirect rules in rules files to do this redirection on your own?  I know that some users had used a workaround like this before teams provided a per machine install as a way to share a single install with multiple users.

    I would like to get more information about this,  Would it be possible to collect a procmon of this install, or to send up the logs from profiles or ODFC (whichever container(s)) you are using?  These will contain names of file shares, and usernames and sids, so it would be best if you opened a support ticked, and uploaded those to us using their tools.  It would also be useful to see the output from frx.exe list-redirects, and frx.exe list-rules this would show you what is being redirected from where and to where by fslogix.

    I am not familiar with SRP or how it determines paths of executables.  In theory the output from the frx.exe list-redirects would be virtualized in a way that it would be near impossible for calling components to know that it was virtualized.  The output from frx.exe list-rules will issue reparse statuses, and callers could know that they have been redirected.





    • Edited by Brian Mann1 Tuesday, November 19, 2019 8:58 PM
    Tuesday, November 19, 2019 8:55 PM
  • Although I'm not familiar with SRP or why you're seeing the Teams application installed to ProgramData, I would recommend reinstalling teams with a proper machine-wide setup-- the way you're doing it is the "old" machine-wide way, where it would drop the per-user installer for Teams into Program Files and then run it for each user that logs in. The new way actually installs the full application to Program Files, which I'm guessing would allow you to more easily block it with SRP if needed (since it's an identical path for all users) and would no longer reside in either ProgramData or LocalAppData.

    For some reason MSDN forums still aren't letting me post links in my replies, but Microsoft has documentation on installing Teams machine-wide for VDIs. Essentially, you add the switch "ALLUSER=1" to msiexec when you install it on the server.


    I wasn't aware they had issues a new version of the machine-wide installer!

    I have been asking for this for a while, so will investigate and transition over if available.

    Thanks.

    Wednesday, November 20, 2019 10:23 AM
  • Hi Brian,

    SRP just prevents apps from running based on rules, it doesn't change location of data/installs.

    I am going to investigate the new version of the machine-wide teams installer first, to see if that helps.

    I can tell you though, that we do not make use of the redirections file.

    Whilst it may not be FSLogix causing the issue as such, it seems like it might be a compatibility thing between how FSLogix is handling the profile, and how some apps are trying to install into localappdata.

    Our live servers use UPDs as part of RDSH deployment, and don't see the same behaviour.

    I will feedback after checking machine wide install, and then try and provide more info if still ongoing.

    Many thanks.

    James

    Wednesday, November 20, 2019 10:31 AM
  • Although I'm not familiar with SRP or why you're seeing the Teams application installed to ProgramData, I would recommend reinstalling teams with a proper machine-wide setup-- the way you're doing it is the "old" machine-wide way, where it would drop the per-user installer for Teams into Program Files and then run it for each user that logs in. The new way actually installs the full application to Program Files, which I'm guessing would allow you to more easily block it with SRP if needed (since it's an identical path for all users) and would no longer reside in either ProgramData or LocalAppData.

    For some reason MSDN forums still aren't letting me post links in my replies, but Microsoft has documentation on installing Teams machine-wide for VDIs. Essentially, you add the switch "ALLUSER=1" to msiexec when you install it on the server.


    Sadly, I think the article you are probably referring to, does not have RDSH in scope of that deployment model:

    Shared session host type deployments

    I think that the same process would still occurr, even if using VDI, in that the installer is machine wide, but it would create a single installation for each user of that VM (if it were persistent).

    Wednesday, November 20, 2019 4:05 PM
  • I am currently investigating.  To my knowledge there is nothing in FSLogix that would explain why teams would be going to the ProgramData directory.  I will report back shortly.

    I will definitely need more information.  FSLogix should not be causing this.  A few thoughts.  Is it possible that you have used FSLogix redirect rules in rules files to do this redirection on your own?  I know that some users had used a workaround like this before teams provided a per machine install as a way to share a single install with multiple users.

    I would like to get more information about this,  Would it be possible to collect a procmon of this install, or to send up the logs from profiles or ODFC (whichever container(s)) you are using?  These will contain names of file shares, and usernames and sids, so it would be best if you opened a support ticked, and uploaded those to us using their tools.  It would also be useful to see the output from frx.exe list-redirects, and frx.exe list-rules this would show you what is being redirected from where and to where by fslogix.

    I am not familiar with SRP or how it determines paths of executables.  In theory the output from the frx.exe list-redirects would be virtualized in a way that it would be near impossible for calling components to know that it was virtualized.  The output from frx.exe list-rules will issue reparse statuses, and callers could know that they have been redirected.

    I will start by running the frx commands you asked for, and will post the results soon.

    Many thanks

    James

    Wednesday, November 20, 2019 4:08 PM
  • After doing tests on another issue on our live servers, I ended up recreating my live profile.

    Upon logging in with my new blank profile, I found Teams had been installed into ProgramData\%username% on that live server.

    Therefore, it looks like the behaviour is indeed down to the Teams installer somehow. I will raise a ticket with Microsoft to try and determine why this happens.

    Thanks

    James

    Thursday, November 21, 2019 10:43 AM