braddock83 Tracker

Re: RDSH Seamless Office Apps + OneDrive Files On Demand - Sign-In Issues & OneDrive auto-launch

braddock83 — Fri, 14 Jul 2023 13:18:27 GMT

Thanks for reaching out to the internal team. I've requested an update from the regional account team, but haven't heard back. Have you heard anything on that end?

RDSH Seamless Office Apps + OneDrive Files On Demand - Sign-In Issues & OneDrive auto-launch Failure

braddock83 — Tue, 13 Jun 2023 17:01:15 GMT

Has anyone been successful in publishing Office apps on Server 2019 and having the Office sign-ins work as expected? This is using Shared Computer Activation. The issue is when a user signs in to the Office app, another window pops up that is not visible (or falls behind the app) when the app is in seamless mode. To the end user, the app appears frozen. If you have a RDSH desktop or manually launch explorer.exe, the process works as expected and Office is able to license successfully.

This is a known issue that VMware and Microsoft developers have been working on this for some time, but the status seems to always be 'in progress'. Server 2019 is not a new OS and it's hard to believe there isn't a working solution when both Microsoft on their AVD platform and Citrix have both developed a working solution (or workaround). VMware's current attempt at a solution has a defect where it breaks at scale and therefore was never released. Has anyone found any viable options aside from 1) remaining on Server 2016 for seamless Office published apps or 2) launching full explorer shells or RDSH desktops?

Now for OneDrive. I understand Server 2016 and OneDrive files on demand (or perhaps as a whole) do not jive. So, that was one reason to push forward with Server 2019. We can get OneDrive to work as expected...wait for it...as long as a full explorer shell is running. Any seamless app launches will not result in the OneDrive system tray process starting up and therefore files are not available and cannot be retrieved from the OneDrive areas in File Explorer. If we manually launch explorer.exe, OneDrive auto-launches and signs in as expected. RDSH desktops also have no problems.

With all this said, how does VMware even have a play at published apps on RDSH Servers 2019 and higher? It has rendered the product effectively unusable and forces us back to desktops for everything. Has anyone else found any viable workarounds or solutions for either of these issues?

Re: DEM + FSLogix Containers Not Jiving

braddock83 — Tue, 24 May 2022 11:35:50 GMT

Thanks @Mickeybyte for looking more closely at this one and for the input that DirectFlex is a workaround. That makes total sense--settings would be applying mid-session and the FSLogix Office container would merge those in to what it's storing. For common settings (like Office Shared Settings), that we want to be present before a user launches any Office application, this is where DirectFlex gets a little tricky. I wonder if we could key those common settings off something core to the Windows user session (e.g., explorer.exe or dllhost.exe) instead. I tried opening a case with VMware support early on and they weren't able to provide any real input because FSLogix is not a VMware product. Even though there were some TechZone articles showing Horizon, DEM, and AppVolumes all used in one solution. It really makes me think it should be working. Thanks again for your efforts and I hope we come up with an explanation soon.

DEM + FSLogix Containers Not Jiving

braddock83 — Mon, 16 May 2022 15:49:04 GMT

We have an environment where we're using DEM to apply some predefined settings (files/registry) and just started using FSLogix Office containers. If changes are made to those predefined settings (partially/fully enforced) or to any registry settings (under User Environment), I can confirm in the DEM logs they are applied to the user (under HKCU/AppData), but it appears the FSLogix Office Container applies after those settings. When looking at the registry, none of the new settings from DEM are there and the applied content from from the FSLogix container is all that remains. If this were a new user with no profile or FSLogix containers, everything applies as expected, but subsequent logins will not receive any changes from DEM.

How are others dealing with changes that need to be made (that were traditionally done via DEM)? Based on what I'm seeing, we need to move these application level settings out of DEM back over into GPO (which does work). If we expand FSLogix to also enable full profile containers, I imagine this would continue to be a problem for other applications and settings in other registry trees and folder paths. We might be able to do some asynchronous applications of settings, but I think it might be cleaner to just go back to the drawing board. Thanks for any input here.