Common Application Configuration File in WVD


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?



8 Replies
Hi 40MB,

You mention that the application uses an ini file, does it need to be referenced when launching the application or is it static (can you change the path?)?
You could opt in placing the INI in the user profile (FSLogix) and moving together with the user.
If yes on previous question, why should a published application be a problem? You could even publish notepad if they need to change the INI file.

Changes to the (personal) INI file would only reflect in changes on the user and not the rest of the users.
You could create a script to replace all INI files (or simply with a GPO) if required for structural changes.

Looking forward to your reply!
I didn't think about Notepad as a separate published app for editing the ini file. That's brilliant.

The ini file *has* to be in a certain directory of the installed application (did I mention worse app ever?). I floated the idea of doing a hand-recompile of the app to allow for a registry-based ini file location, and was told that would violate all sorts of legal stuff.

Can FSLogix be used to take the contents of the configuration directory of the application and cache it for each individual user?
Hi 40MB,

FSLogix is a method to resolve the issues that come with roaming profiles (big Outlook OST files, OneDrive synced files, teams content etc) causing extensive login times. FSLogix also offers "application masking" which hides applications for certain security groups but this would only solve your issue if you want to hide other user's INI files from other users (maybe this is what you are looking for?) More information can be found on:

The explanation for the recompile sounds like "let's use the magical LEGAL term to get rid of irritating requests", just like "GDPR" but those are just my two cents ;)



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:


Next you will need to describe which users should get it. Maybe Everyone? See this for directions:


Then deploy.



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. 


  • Access this link:
  • Click the services tab.
  • Click Desktop App Assure from the services list
  • Fill the fields and mention "AppCompat issue on WVD" under assistance needed field. 
  • Submit the new request.
Hi Racook,
As far as I understood the initial poster, the ini should stay in the program folder so redirection cannot be done? Am I correct 40MB?
best response confirmed by FortyMegabytes (Contributor)

@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.

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.