Software Deployment

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.

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

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.

I meant the system should handle the elevated thing different. I'll have a look at Active Setup (never heard of it:-)

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

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.

Active setup is your best bet

http://www.etlengineering.com/installer/activesetup.txt

the files aren't installed in de the correct folder.Because, just like SCCM, GP deploys using the System account. Refer to post # 4.

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?

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

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.

I'm guessing you have a CreateFolder entry for this?
What is the parent directory entry for the directory you're trying to create?

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.

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.

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?

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?

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?

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.

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?

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?

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?

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?