Jan 14 2020 02:40 PM
Jan 14 2020 02:40 PM
Here is our semi-horrifying situation.
We have a business-critical application that I've dubbed "the worst-written Windows application ever". It is truly awful. But it's a key part of our business.
The application is configured via a .ini file. If our users want to change a setting, they do it by editing the .ini file and relaunching the application. (Did I mention this is the worst-written application ever?)
We want to deploy this application using WVD. Because the only way to change a setting is to edit the .ini file, we have to deploy it as a Desktop Application Group. So users launch a desktop, then launch the app.
However, if a user changes the .ini file, then the next person who launches the application on that host uses that same .ini file. And if you have ten or fifteen people on the same host - well, you can imagine the flurry of .ini file changes that go on and how they impact each of the users.
Of course we could set the Host Pool to "Personal" rather than "Pooled", which means I'd need to deploy forty hosts rather than one, which sort of defeats the purpose of setting up WVD in the first place.
Does anyone have any other suggestions for how to handle an application on a multi-session host that uses a singular configuration file that can be edited by multiple people?
I'm looking at maybe having the .ini file be a symbolic link to an .ini file on the user's home share. Then I can have a startup script that checks for the existence of the .ini file, and if it doesn't find it, copies a default .ini file into the user's home share. It seems a complicated mess but it's the best solution I can think of.
Anyone else have experience with a scenario like the one I described above? Any suggestions on how to deal with that?
Jan 15 2020 12:44 AM
Jan 16 2020 01:31 PM
Jan 16 2020 01:40 PM
Jan 16 2020 05:23 PM
While application masking is generally intended to handle full applications, you can generate a rule file by hand that will do what you want.
Create a redirect for the ini file that redirects into the users profile somewhere. There is even a checkbox that will copy the original file if one does not exist at the target.
Start by creating a new, empty ruleset. Add a file redirection rule. Something like:
C:\badapp\badapp.ini -> __USER_PROFILE_PATH__\AppData\Roaming\badapp\badapp.ini
(Variables that can be used are described here: https://docs.microsoft.com/en-us/fslogix/application-masking-rules-ht#create-a-new-rule)
Next you will need to describe which users should get it. Maybe Everyone? See this for directions: https://docs.microsoft.com/en-us/fslogix/implement-application-masking-tutorial#make-assignments-for...
Jan 16 2020 06:10 PM
Please try out the above steps that @racook mentioned and reach out to AppAssure team in case of any further queries.
Submit Request for Assistance (RFA) in FastTrack portal using the below mentioned steps which will help us in working with you.
Jan 16 2020 10:55 PM
Jan 17 2020 02:41 PMSolution
@knowlite the original ini file will be in the place where the app expects it to be. It's just that based on which user is accessing the file, FSLogix will redirect the file open to the user's copy in their profile. It's like a fancy symlink, except that it will redirect to a different place based on which user is accessing the file. And if the target file doesn't exist, it can copy the original file to the target location before opening it.
Jan 31 2020 08:28 AM
Well, this may not be helpful to future people who search for solutions to this very peculiar problem, but here's the solution we came up with.
After discussion, we determined that there are only a couple of settings that actually need to be changed. So we created three host pools - MyApp Setting A, MyApp Setting B, and MyApp Setting C. So users launch the desktop of the host pools whose application settings match their needs.
Not elegant, and a bit wasteful, but unfortunately necessary because of the very peculiar way this application was written.
Thanks everyone for you very helpful comments and suggestions.