/build/static/layout/Breadcrumb_cap_w.png

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

0 Comments   [ + ] Show comments

Answers (2)

Posted by: vkleiner 12 years ago
Orange Senior Belt
0
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

Comments:
  • I miss a preview function for this board ... - vkleiner 12 years ago
Posted by: dunnpy 12 years ago
Red Belt
0
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

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

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ