Hey all,

My issue is the following, I'm trying to create an installation package for BMC Remedy User 7.1 which installs the files AR (contains server config) and AR.ini (personal app config) onto the users My Documents, which is redirected to a network share \\server\users\username.
The snapshot I created for this app is working fine except for these 2 files, which I can't get to install on the users home drive (My Documents).
I tried several things like the ROOTDRIVE property, using environment variables,... but I can't get this to work properly.

The difficult part in this problem is the fact that the MSI will be installed by using the SYSTEM account. The shortcuts are advertised so the moment the user (with limited rights) starts the application, the currentuser items are done (self healing). This works fine for all our applications which only need to install files locally on the C:-drive, but for this one I want to have the self healing put the AR and AR.ini file onto the users home drive.

Now of course my question, is there a proper way to accomplish this in an MSI?
Tips, hints and of course solutions are welcome as I'm running out of these at the moment.

Thanks,
Ben
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Community Chosen Answer

2
Never mind my question, I just had an epiphany how to solve my own problem [:D]

In the MSI package I used the ROOTDRIVE property to point to the redirected home folder (F:\-drive), this I tried before as well but then the installation with SYSTEM account failed as there was no F:-drive at that time. This I now solved by using SUBST in the batch file where I started the MSI installation to also have an F:-drive when installing with SYSTEM account, SUBST is now creating an F:-drive which points to %TEMP%.

When I now start the application via the advertised shortcut the SelfHealing kicks in and creates the 2 files on the user's personal F:-drive.
Problem solved, but if you have better ways of solving this issue, please feel free to post, I'm more than interested how to fix this issue completely inside the MSI file.

Ben
Answered 01/02/2009 by: BenLimerkens
Senior Yellow Belt

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
One would normally construct this by having a separate user feature (called, say, CurrentUser) as the parent feature of those features which contain the advertised shortcuts. Is that how your MSI is built? It sounds like it is.

Trying to do the copying at install-time will never work, because the System account has no concept of networking. I suppose you could lash up a Custom Action but that's pretty ugly (and a maintenance nightmare)

Are the profile folders actually redirected by the OS (using Folder Redirection)? If so, I can't see why that doesn't work: the OS takes care of "moving" the files to the network.
Answered 01/02/2009 by: VBScab
Red Belt

Please log in to comment
0
I did not create a seperate feature for this, I only have Complete with all items in there, Files and Advertised Shortcuts. What I did change is the component CurrentUser. After creating the snapshot this component only contains the HKCU registry keys. Then I moved the AR and AR.ini file into this component and then having the component point to My Documents\ARSystem\home (the folder the files need to go), but having only this did not solve the issue. Having this setup and clicking the advertised shortcut resulted in having the files installed to C:\Documents and Settings\%username%\My Documents\ARSystem\home. So it looked like the redirected My Documents to F:-drive is not really picked up by the MSI installation.
We only redirect the My Documents folder to the network share, nothing else. The rest of the profile stays on the C:-drive and is copied to another network share as a roaming profile.
Answered 01/02/2009 by: BenLimerkens
Senior Yellow Belt

Please log in to comment
0
How is the 'My Documents\ARSystem\home' path built, though? Is it using [PersonalFolder] as its "root"?
Answered 01/02/2009 by: VBScab
Red Belt

Please log in to comment
0
Initially it was using TARGETDIR as its "root", then the files were installed to C:\, which is logical as ROOTDRIVE was not set and it defaults to C:\. Then I changed it to have [PersonalFolder] as its root, then it was installing to that C:\Documents and Set... as explained above.

It's possible I changed too much as I was trying to get it to work and in the end break something instead of fixing.
Answered 01/02/2009 by: BenLimerkens
Senior Yellow Belt

Please log in to comment
0
Windows Installer won't install to network drives. You'll have to do some fancy CA footwork (and that'll be problematic if you deploy with SMS coz the acct. won't know about your users' "my documents")
Answered 01/02/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
Why do you say "Windows Installer does not install to network drives"? How I did it now, with setting ROOTDRIVE the value of the network drive, it installs fine. Every user who logs on to the pc and clicks the advertised shortcut, gets the required files and folders nicely on his F:-drive (network mapping to \\server\users\username).

I understand that the initial install done with SysAcc cannot copy the files to the network drive of the user. The SysAcc is not aware of that logged on user, but the moment the user clicks the shortcut the MSI selfhealing is triggered and this is in the context of the user, not SysAcc.
Answered 01/02/2009 by: BenLimerkens
Senior Yellow Belt

Please log in to comment
0
Well I tested when I got in and by ghosh it worked when I set ROOTDRIVE to x:\ and installed a file to x:\test
By default, ROOTDRIVE is set to the local drive with the largest amount of free space, but it can be overridden.
So, you CAN install to network drives - provided of course you have appropriate access. Not sure quite why one would want to do this unless it's a redirected personal drive like you mention. It looks like you resolved the problem, which is good! That's kind of a cool solution -
1) you faked out the SYSTEM user with the subst command for the f:\ drive and
2) used self healing to write to the f:\ drive after user logon.
Very nice! [:D]
Answered 01/02/2009 by: aogilmor
Ninth Degree Black Belt

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