Software Deployment

What is your active setup command?

it just updates the current user files and registry entires using msiexec. But Like I said that is not the issue. I need to be able to create a directory under the install directory using the ntid

I need to create the following dir structure
P:\factset
P:\factset\config
P:\factset\config\{username or ntid}

I have treid using [LogonUser]
[%LogonUser]
%LogonUser
%LogonUser% for the folder name but it does not substitute the Property for the property value.

So my question is what is the best way to do this?

Wise script or vb script custom action is probably what I'd go for.. Pickup the username from the environment variables.

Cheers,
Rob.

ORIGINAL: SeaWall
it just updates the current user files and registry entires using msiexec. But Like I said that is not the issue. I need to be able to create a directory under the install directory using the ntid
I need to create the following dir structure
P:\factset
P:\factset\config
P:\factset\config\{username or ntid}


Please tell me you're only doing config files and not installing the program on every users's P: drive. that would be Very Bad Design. My understanding from previously packaging this app is that the app takes care of the users' "P: drive" user data just by virtue of the user logging in. But if you need to pre-populate user settings I see no reason this wouldn't work as long as every user is in fact a valid factset user (it has its own user database) and has access write access to to the config directory. .

ORIGINAL: SeaWall
I have treid using [LogonUser]
[%LogonUser]
%LogonUser
%LogonUser% for the folder name but it does not substitute the Property for the property value.
So my question is what is the best way to do this?


[LogonUser] is a standard Windows installer property no need for the %

If the task is only to create a file structure and copy some files then I would perform this action in a logon script instead.
Too much fuzz with an installer for this simple task.

MSI is not designed to install files to a network drive and it shouldnt be used to do so. The correct, imo, way to do this would be to use a custom action vbscript to create the directories and copy files. This script would have to cater for install and uninstall as well as repair.

The easiest way to achieve a file copy is to drop the payload on the local machine and then have the script copy the files under, for example, the run key for local users, with appropriate error checking!

P

Another way to crack this (assuming there is a shortcut for this application) would be to author a wise / vb script to check for the existance of / create the folder structure before running the main application .exe - then include the script in your package and set the shortcut to execute that...

Just depends on what you prefer but I don't like the logon script solution as it keeps the solution outside of the package. Unless it's well documented someone is probably going to forget why it's there and it's also something else to remember when the app is evetually decommissioned.

Hope it helps,
Rob.

it's also something else to remember when the app is evetually decommissioned.Yee ha! Someone works for a client who decommissions apps! This IS a Red Letter Day!

Haha - there is no decomissioning here... it was more of a theory really [:D]

It would be possible to install files on a network however; it would have to be done during a repair (REINSTALL AND NOT PATCH) and using set directory/property custom action to change the component(s) directory (path). There should also be some considerations during uninstall. A custom action during repair would also be a possible solution that would check if the network is accessible before doing its work.