Software Deployment

Hey Brett,

We use a script to copy the file to the required location in AS, under the userprofile environment variable copy the file either locally or from a dfs share.
A bit of a sledge hammer approach, but it works everytime when dealing with userprofile specific stuff.

Also a extensive log file will tell you what is happening on your startup of word. Check out John's Blog on Feature repair too:
http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!123.entry

Cheers
Wayne

looks like you don't run validation do you fella !

you will have a validation rule stating that you need to put an HKCU entry into the component which contains the %userprofile% files.

that HKCU entry can be a dummy key containing whatever you like it does have to be the keypath though.

I would suggest something along the lines of HKCU\Software\Packages\[ProductCode]\ValidationFix_Componentname = whatever.

this way all packages will have dummy entries in the same location.

You're correct that I don't run validation because the errors have always meant nothing to me .. I dream that some day my boss will send me on training (being the lead packager in a 20k PC environment). I just ran it and it's come up with more errors than I care to count, and that's one from a vendor.

But, I don't think it is going to be the answer as I've worked out at least partly what's going on. Endnote has it's own process to install the necessary files, but only after one of the Office products has been run so it knows what version of the files to install. It's this process that's putting the files in the correct location, not my transform.

I put the folders into the LocalAppDataFolder, not the AppDataFolder. If I go looking there, sure enough, the files have been installed. Which brings me to the next problem. How do I put them in the AppDataFolder? I've been trying to get some help with this here, but I haven't had any success so far and now have several packages I need to do this on.

When I look in the Directory table, I can see a reference to the areas that I need, in this case AppDataFolder. If I change my newly added top level folder (Microsoft) from having a Parent Directory of LocalAppDataFolder to AppDataFolder, I can no longer see it in InstallShields Files and Folders area. I could live with having to make that kind of change in the directory table if it worked, but it doesn't.

Any help in getting these 'special' variable based folders to work would be brilliant.
Thanks
Brett

EDIT : Thanks Wayne for your suggestion also. It would probably work in this case, but wouldn't clean itself nicely up on uninstall.

OK, further investigation into this shows me that the directory table is working, in that it is putting the files and folders in, but ONLY if the the logging in user is a User, not an Admin. If I log in with an Admin, the files are installed in the last users account. For instance, I logged in with my test account dh123456 which is a user, and the repair works correctly. I then log on with my Admin account and logging shows me the following.

Property(S): STARTUP = C:\Documents and Settings\dh123456\Application Data\Microsoft\Word\Startup\
Property(S): WORD = C:\Documents and Settings\dh123456\Application Data\Microsoft\Word\
Property(S): MICROSOFT = C:\Documents and Settings\dh123456\Application Data\Microsoft\

I can log in with multiple User accounts and it will perform the correct function, but when I log on with an Admin account, it will always use the last logged on User. I can then run a different User, then rerun the repair for the Admin and it will have changed the user name it's using, but it's still wrong.

Verbose logging gets the following (cmp006 is my admin test account).

MSI (s) (2C:84) [08:02:41:532]: PROPERTY CHANGE: Adding STARTUP property. Its value is 'C:\Documents and Settings\dh123456\Application Data\Microsoft\Word\Startup'.
MSI (s) (2C:84) [08:02:41:532]: PROPERTY CHANGE: Modifying LocalAppDataFolder property. Its current value is 'C:\Documents and Settings\cmp006\Local Settings\Application Data\'. Its new value: 'C:\Documents and Settings\dh123456\Local Settings\Application Data'.
MSI (s) (2C:84) [08:02:41:532]: PROPERTY CHANGE: Adding WORD property. Its value is 'C:\Documents and Settings\dh123456\Application Data\Microsoft\Word'.
MSI (s) (2C:84) [08:02:41:532]: PROPERTY CHANGE: Adding MICROSOFT property. Its value is 'C:\Documents and Settings\dh123456\Application Data\Microsoft'.

I've also attempted to take jmcfadyen's advice about the dummy HKCU registry entry, but either I've done something wrong, or it hasn't helped.

Can someone please explain this behaviour and what's going wrong here.

the dummy key needs to be in the same component and marked as the keypath

people always miss that bit about the keypath.

re the validation if your using wise dont run the separate tool, go into the table view, then run the validation tool from there. it makes fixing validation issues much easier as it takes you directly to the offending row in a specific table

Thanks again, but still no go. Let me know if I have done something wrong here.

Each of the three folders (Microsoft, Word, Startup) have been placed in their own components automatically by InstallShield (AllOtherFiles1 - 3). The Files are also part of AllOtherFiles3. Within this component, I've created the suggested registry entry and set it as the Key Path.

Is this correct, or should there be one registry entry for each of the folders? Is it necessary to have each folder within it's own Component?

Your help is very much appreciated, thankyou.
Brett

Well, I gave up on that idea and came up with a new one. This time, rather than putting the files I wanted into the MST and trying to do a repair which obviously didn't want to work for me, I created a new MSI which did what I wanted it to do and used that instead. The MSI is set to not require Admin rights, is copied to the PC using the MST from the rest of the program and is installed with an ALLUSERS="" within Active Setup. This seems to have gotten around the problem and has the advantage that the install time is much less than the full repair I was attempting before.

Thanks for all the help, I'll keep it in mind for the next time something bizaar is going on. Hopefully this will help someone else though when they are having problems.