Thanks for a great forum and it has helped me many times. But this time I can't seem to find a good answer.

I'm making a transform for a vendor MSI package. When using this application, some configuration files are stored in c:\Users\<username>\appdata\local\

These files I want to deliver with the MST, so the users don’t need to do the configuration themselves.

When in Files, I can't seem to find the appropriate folder to place the files in. I tried using profiles\local settings\application data, but it doesn’t work. This is probably because we need to run the installation with elevated rights and it messes with the username.

Any ideas how to handle this?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
If i am reading your post correctly...
There is a good chance that files and directory are created at runtime. Create the directory in your mst. Obtain the files after they are put down when app is launched as administrator. Ten make whatever config changes are needed and place them in your package. Then use active setup with the /fup switch to get them to replicate to users.
Answered 09/09/2010 by: oreillyr
Fifth Degree Brown Belt

Please log in to comment
0
I have the config files on the computer running Package Studio and tried too put them in the package with the add content button. Problem is, I can't put them too the c:\Users\<username>\appdata\local\ folder. This reference doesn't exist. The documentation says the windows\profiles\local settings\application data is the right place to put them. That should translate to c:\Users\<username>\appdata\local\ when the msi/mst are run. Since users don't have admin rights, we run it with elevated rights from SCCM. I tried to run the msi/mst manually and the files where placed in the c:\Users\<adminusername>\appdata\local\. That means that the windows\profiles\local settings\application data in WPS8 is the right place to put them, but the system doesn't handle the elevated rights as it should
Answered 09/09/2010 by: Gard
Yellow Belt

Please log in to comment
0
Yes it does. You have asked it to put files into the logged-in user's profile and, since SCCM executes as local System, that's exactly where they've gone. :-) You'll find them somewhere beneath '%SystemRoot%\system32\config\systemprofile'.

You can either re-jig the feature tree so that use of an advertised entry-point (such as a shortcut) triggers a repair once the actual user's logged in or, as advised, you could use Active Setup.
Answered 09/09/2010 by: VBScab
Red Belt

Please log in to comment
0
I meant the system should handle the elevated thing different. I'll have a look at Active Setup (never heard of it:-)
Answered 09/09/2010 by: Gard
Yellow Belt

Please log in to comment
0
I meant the system should handle the elevated thing differentlyHow?!? If you tell SCCM to install with admin rights (or, more correctly, NOT with user's rights), it'll use the System account.Active Setup (never heard of it:-) Scary...
Answered 09/09/2010 by: VBScab
Red Belt

Please log in to comment
0
Someone got a sollution for this problem.

I'm trying to install files in de application data folder of the user with a per-machine installation trough GPO.
My files are installed in the 'windows\system32\config\systemprofile' this triggers a repair everytime i run the application because the user can't acces that folder and the files aren't installed in de the correct folder.
Answered 10/07/2010 by: netloony
Senior Yellow Belt

Please log in to comment
0
Answered 10/07/2010 by: timmsie
Fourth Degree Brown Belt

Please log in to comment
0
the files aren't installed in de the correct folder.Because, just like SCCM, GP deploys using the System account. Refer to post # 4.
Answered 10/07/2010 by: VBScab
Red Belt

Please log in to comment
0
I also have this problem. Trying to create a folder under [AppData] but if different users share the same machine and application a self repair is triggered all the time at every startup of the application.

Why is Active Setup the only option?

We distribute programs through SCCM and I get that the AppData folder at installtime is created at windows\system32\config\systemprofile.
But the self repair should create the folder at the correct location under the user profile. But it seems as if the installer checks whether the folder exists the last users profile, or not. Atleast according to event viewer.

Can someone point me in the right direction?
Answered 01/05/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
David,

Verify that you have a HKCU registry entry as keypath for the component creating the directory or files under the user's appdata folder
Answered 01/05/2011 by: AngelD
Red Belt

Please log in to comment
0
Hi,

I actually changed in the package now so that there is a HKCU key that is keypath in the same component that created the folder. All that happens is that the registry key repairs itself but no folder gets created.
Answered 01/05/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
I'm guessing you have a CreateFolder entry for this?
What is the parent directory entry for the directory you're trying to create?
Answered 01/05/2011 by: AngelD
Red Belt

Please log in to comment
0
Yes InstallShield created a CreateFolder entry for it.
As far as I can see "AppDataFolder" is the parent directory if I check the Directory table in DirectEditor.
Answered 01/11/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
I really need help with this. Now I have another application (Netop) which has files under AppDataFolder. I read the following thread http://itninja.com/question/distribution-message21&mpage=1&key=𑛞 and tried the tips there but it leaves me with a msi+mst which I cant run at all now.
Answered 01/25/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
Trouble is...I can't quite see the actual error you get because my crystal ball is all fogged-up. Is there any chance you could actually tell us what it is?
Answered 01/25/2011 by: VBScab
Red Belt

Please log in to comment
0
Sorry VBScab I thought I explained it further up in this post but no, it wasn´t crystal clear :)

The issue is that if I package or create a mst for a vendor MSI, that creates a file or a folder under users AppDataFolder the self repair is really weird. It looks for the file or folder under the LAST users profile. The user who was logged in before the current user that is. And the current user doesn´t have access to the last users AppDataFolder. So if two users share a machine and a application the application will selfheal every time (or the first time for each user until another user logs on again and starts the application).

I have tried with having the files and folders and the HKCU reg value for self repair in the same component. As well as splitting them up but I get the same result. I can see in event viewer that the previous users AppDataFolder is being used.

I have also tried with having a parent feature with the HKCU regvalue and AppDataFolder folder and files and using DuplicateFiles table but I dont get it to work. The msi-installer fails. I use InstallShield2010 and the entries in DuplicateFiles table aren´t created automatically. But the error with "wrong user self heal" shouldn´t be related to the duplicatefiles table anyway, or?
Answered 01/25/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
I was thinking that maybe its an error with the way that I create the folder under AppDataFolder? I simply create a component in InstallShield2010. Go to the component and under "Destination" i write [AppDataFolder]Netop\Netop Remote Control\Guest. Entries about the folder are created under "directory"-table.
Should I have another approach to this?
Answered 01/25/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
Maybe I didn´t mention it but at installation time the AppDataFolder being used is the systems account and then somehow that path is saved when another user starts up the application. Instead of that users AppDataFolder.
Answered 01/27/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
If your feature tree is correctly set up, how the property is resolved at installation time is irrelevant.

Are you sure that there isn't a Custiom Action running which might be changing the property's value?
Answered 01/27/2011 by: VBScab
Red Belt

Please log in to comment
0
I don´t quite follow, what property are you referring to?

I see two CustomActions which are named DWSaveNDB_i and DWSaveNDB_d and the files under AppDataFolder have .ndb as filetypes. Those actions calls a .dll. Something to do with that?
Answered 01/27/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
Er...the AppDataFolder property.

I'd guess that those CAs are backing-up user data so, no, not connected.

Why not post your MSI to Windows Live/SendUit/whatever?
Answered 01/27/2011 by: VBScab
Red Belt

Please log in to comment
0
Well the MSI and MST (from vendor) contains licenses so it´s not something I want to spread around.
But somehow it seems as if I got it working now! The difference I see now in the event viewer is that the broken keypath is from the registry and not a file with a absolute path. This is strange because i have always in the previous attempts, used reg-keys as keypaths. Never ever a file!
I´m glad that it works and it seems as if the error was files as keypaths and not reg-keys, but it would be nice to know how a file became a keypath? Or maybe a folder, but a folder cant be a keypath or am I wrong?
Answered 01/27/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity