C:\Windows\X.ini on Terminal Server with App-v, multiple user conflict
Hi,
I'm new to sequencing and am unsure about the following so would like some advice.
I have sequenced an application which installs a .ini file to C:\Windows. The file is installed there during the sequence and is therefore captured inside my AppV bubble.
When the user then runs the application the C:\Windows\X.ini file is referenced and the application behaves in a certains way after reading some settings from within the .ini file.
Am I right in assuming that this file, because it's installed to C:\Windows\ and is a system file rather than a user specific file, is stored in the Appv cache file in this location - C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\AppFS Storage\XXXXXXXX\XXXXX.pkg
Also, am I right in saying that any change made to the user specific part of the application gets stored in the file in the following location - \AppData\Local\SoftGrid Client\XXXXX\XXX.tmp?
If my assumptions are correct then I was wondering if there is any way to change this behaviour, the reason I ask is that I need to run this application on a Terminal Server and therefore, multiple users could be running this application at the same time and if one user changes the settings in the INI file to suit them, the following user may need to use different settings and so there is a conflict of interests with this file. Even though it's not installed directly onto the machine but because it's stored in C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\AppFS Storage and will therefore apply to all users.
I would like to know if there is a way around this happening so that the file cannot be edited for a start and also if anyone has had to deal with this situation in the past and how they got around it.
Unfortunately, the application looks for the INI file in C:\windows and so this location can't change.
Any advice would be greatly appreciated as a this moment in time I am looking at removing this file from the package entirely and installing it via a script outside of appv.
Rgds,
Mark
I'm new to sequencing and am unsure about the following so would like some advice.
I have sequenced an application which installs a .ini file to C:\Windows. The file is installed there during the sequence and is therefore captured inside my AppV bubble.
When the user then runs the application the C:\Windows\X.ini file is referenced and the application behaves in a certains way after reading some settings from within the .ini file.
Am I right in assuming that this file, because it's installed to C:\Windows\ and is a system file rather than a user specific file, is stored in the Appv cache file in this location - C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\AppFS Storage\XXXXXXXX\XXXXX.pkg
Also, am I right in saying that any change made to the user specific part of the application gets stored in the file in the following location - \AppData\Local\SoftGrid Client\XXXXX\XXX.tmp?
If my assumptions are correct then I was wondering if there is any way to change this behaviour, the reason I ask is that I need to run this application on a Terminal Server and therefore, multiple users could be running this application at the same time and if one user changes the settings in the INI file to suit them, the following user may need to use different settings and so there is a conflict of interests with this file. Even though it's not installed directly onto the machine but because it's stored in C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\AppFS Storage and will therefore apply to all users.
I would like to know if there is a way around this happening so that the file cannot be edited for a start and also if anyone has had to deal with this situation in the past and how they got around it.
Unfortunately, the application looks for the INI file in C:\windows and so this location can't change.
Any advice would be greatly appreciated as a this moment in time I am looking at removing this file from the package entirely and installing it via a script outside of appv.
Rgds,
Mark
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
vkleiner
12 years ago
Hi mark,
use a script to delete this file after application shutdown by using the POST tag.
Some hints:
http://blogs.technet.com/b/appv/archive/2007/10/11/scripting-within-an-osd-file.aspxhttp://blogs.technet.com/b/appv/archive/2007/10/11/scripting-within-an-osd-file.aspx
http://www.tmurgent.com/osd_illustrated.aspx
/vkleinerde
use a script to delete this file after application shutdown by using the POST tag.
Some hints:
http://blogs.technet.com/b/appv/archive/2007/10/11/scripting-within-an-osd-file.aspxhttp://blogs.technet.com/b/appv/archive/2007/10/11/scripting-within-an-osd-file.aspx
http://www.tmurgent.com/osd_illustrated.aspx
/vkleinerde
Comments:
-
I miss a preview function for this board ... - vkleiner 12 years ago
Posted by:
dunnpy
12 years ago
Take a look at the 'Files' tab on the Microsoft App-V Sequencer.
Bottom right is a 'Sequencer Attributes' option, where you can specifiy whether the 'Sequencer file Type' is 'User Data' or 'Application Data'.
If set to User Data, I believe that it will use the generic copy in the first instance and when modified with stay within the user profile and prevent the conflict issue you describe.
Hope that helps,
Dunnpy
Bottom right is a 'Sequencer Attributes' option, where you can specifiy whether the 'Sequencer file Type' is 'User Data' or 'Application Data'.
If set to User Data, I believe that it will use the generic copy in the first instance and when modified with stay within the user profile and prevent the conflict issue you describe.
Hope that helps,
Dunnpy
Comments:
-
Hi,
OK, I've carried out some more testing. It seems as though the file is being copied to the users home-path, in this instance H:\Windows\X.ini.
So, once this file is copied there the user then has full access to it, even after I have set it to be read only within the sequencer and I enforced security descriptors.
Also, it seems as though I was previously mistaken, in that, the X.ini file is not shared between users on the machine.
Therefore, my question now is how do I ensure that this file is removed from the users home path once the application is closed?
Thanks for your help,
Mark - mark_holland21 12 years ago
