ClickOnce and UEM - Redirect LocalAppdata ?

[sentania]

Howdy -

I'm building out an instant clone based VDI environment.  Early in the build we discovered that one of our business critical applications was built around the MS ClickOnce technology/framework.

After some frustrating conversations with the developers I was eventually able to capture the data with UEM and make it persist for the users.

Fast forward a month or so, and I'm having some folks on my team who are eating our dog food, ask about Github Desktop and Atom (python editor).  Low and,  behold I discover they are also ClickOnce apps.

I whip up a UEM profile that captures them, and to my dismay I now discover that my login time has jumped to just about 2 minutes due to UEM having to process and unpack nearly 700 MB of archives for just these two apps.

Needless to say, this isn't optimal.  After discussions with another teammate we pondered the idea of updating our gold image to point the LocalAppdata directory to the users profile share, which would allow us to not have to deal with creating UEM profiles for ClickOnce apps. How To Make APPDATA and LOCALAPPDATA Environment Variables Follow The Registry Keys – Liquidware Lab...

Thinapp also sounds like another option, but given that ClickOnce apps can be installed without admin privileges.  User conditioning to being able to install those sorts of apps, and my team already being overloaded with other onboarding activites and appstack creation, I'm worried that adding various Thinapp packaging to the flow, which we had hoped to avoid, isn't scalable for an unknown period of time.

I'd appreciate any and all feedback.

[fangoutbang]

Why not have a different Golden image for your AppDEv team? Does your General population need these apps?

How are you deploying the Clickonce apps now without UEM profiles?

[sentania]

What does a separate image buy me?

In our legacy VDI environment (manually provisioned full clones) and our physical environment the click once applications are installed as needed by the users.

ETA: None of these applications are general population apps.  The original ClickOnce is used by a relatively large number of business users (400-500).  Github Desktop, Atom, and other ClickOnce apps I have no insight into their population at this time.

[fangoutbang]

Apologies I miss read your question about the non presistant desktops.

[Al37x]

We have the same issues with Click to run/Clickonce apps.  ProU's compression might be faster LOU's vs. Zip files.  This allowed for acceptable login/log off timing.  2 or 3 minutes waiting for 600 or 700 MB's of sync time creates unsatisfied end users.  Let alone the other issues with capturing ClickOnce apps that do not have an exe when ran.  How the heck do you capture that?  If it's an easy thing please let em know.   

Sentania,  Have you found a solution for this?  Please share if you did.

[dolzhenkom]

I've accomplished something similar for per-user installed applications like Teams and Slack on our instant clones. Essentially, it boils down to a UEM logon script that creates junction paths from where the application would be installed to by default (local appdata), to the writable volume. The timing of the script took a bit to figure out, but we've been able to successfully deploy those kinds of applications in a persistent manner to our non-persistent VDIs, utilizing the writable volume like a persistent disk rather than to store UIAs (we disable virtualization in the snapvol.cfg file) or the user's profile (we use a UIA only template).

[jbacheldor]

We had a similar issue, but we went a different route. We created app stacks for these applications, installed the app, moved the folders/files from the local app data to a folder in program files,and created a shortcut on the desktop to the exe. This removes the element of saving the local app data folder and gives us some more flexibility with who can see the app too. This is the article we referenced when determining the best route

ClickOnce Applications in Enterprise Environments | Remko Weijnen's Blog (Remko's Blog)

[jmatz135]

If you can just move the software from appdata to a file share and launch it from there you could make the shortcuts point to that or use a symlink from within the appdata folder to point to wherever you put it.

[sjesse]

The problem with some of these is they require a login from a seperate app or webpage. I created a script a bit ago to export the appdata files and the registry keys assoicated with them and then import them on next login, it works for the most part just requiring the delete the saved infromation and having users recreate it.

[jmatz135]

That's why I think you should try a symlink.  As far as anything interacting with the program it would think that the program is right where it was supposed to be.