Need to install the package without any shortcuts with user component. Using an active install. Works fine for the regular user. However a user with admin rights on the log in active setup installs user components to the system profile.

Here is mine StubPath:
msiexec /fuo {DAB3B7C4-91AF-4796-B31F-A644F7438525} /q

Does anyone one has any idea what could be the problem? Or its just active install functionality?

Thank you.
0 Comments   [ - ] Hide 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.
Answer this question or Comment on this question for clarity


Seems that there is some bad reference where the user component(s) should be installed.
Run the command manuall as the admin with a verbose logging to see why this happens.
"msiexec /fuo {DAB3B7C4-91AF-4796-B31F-A644F7438525} /q /l*v C:\Temp\ActiveSetup.log"
Answered 05/16/2007 by: AngelD
Red Belt

Please log in to comment
Thanks for reply. I changed switch to /qb and created a log. and i can see active setup launching and finishing without any issues. But from the log i was able to see that its going to system profile.
The package is adding new word templates.
Admin Log:
Adding OutOfDiskSpace property. Its value is '0'.
PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'.
PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'.
PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'.
PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'.
PROPERTY CHANGE: Adding TEMPLATES property. Its value is 'C:\Documents and Settings\LocalService\Application

User log:
PROPERTY CHANGE: Adding TEMPLATES property. Its value is 'C:\Documents and Settings\***\Application
PROPERTY CHANGE: Adding ISIWRITER property. Its value is 'C:\Documents and Settings\***\Application
PROPERTY CHANGE: Adding VANCOUVER property. Its value is 'C:\Documents and Settings\***\Application

The main difference that i can see is a Adding MICROSOFT property
IN the user profile it is created before application related properties and i am guessing that why everything after is pointing to correct profile. However in the admid log the MICROSOFT property is created after all application related properties.

Could this be controlled? Or am i doing anything wrong?

Thank you.
Answered 05/16/2007 by: ogeccut
Black Belt

Please log in to comment
hmm sorry, missed your msiexec command line options abit [;)]

As you only want the Active Setup to install the user part try this for the StubPath instead:
msiexec /fauvs {DAB3B7C4-91AF-4796-B31F-A644F7438525} /qb
Answered 05/17/2007 by: AngelD
Red Belt

Please log in to comment
Thank you for reply.
Issue resolved by recapturing the application and adding same registry key. Don’t know why!!!!
Used same StubPath as in the first post.
I have tried /fauvs switched before with no changes.
Answered 05/17/2007 by: ogeccut
Black Belt

Please log in to comment
* B U M P *

I have almost the same problem.. Have an active setup, runs fine as a standard user, when an administrator logs on, AS doesn't place files in c:\d&s\user$\app data\microsoft\word\startup.. When a standard user logs on, it DOES work. Event logs says configuration completed successfully. Have had this before, and usually solved this with active setup starting off a vb script which copies the files to the user dir.. But i'm getting fed up with AS not working as intended for users who have admin rights.. So here goes..

I'm using the duplicate file table to deploy the files to program files\_user\appname. AS runs commandline when logging on (from stubpath key):

msiexec /fup {C46CA301-1AA2-4854-AEA0-CCB80802913E} REINSTALL=CURRENTUSER /qn

Files which should go to user dir, are placed in the CurrentUser feature, along with a registry key.. Reg key is being deployed fine, file isn't. Turned on logging when logged on as the local admin using:

msiexec /fup {C46CA301-1AA2-4854-AEA0-CCB80802913E} REINSTALL=CURRENTUSER /q /l*v C:\Temp\ActiveSetup.log

I HAVE the log, but what should i be looking for..? Please help.. Thanks..!
Answered 01/11/2008 by: neo2000
Purple Belt

Please log in to comment
As you can see from my log I was able to see that files were copied to a system profile "LocalService" in the log.
I still have about %10 failure on this application, and have to copy files manually. Since the error is not consistent I am not able to find a better solution.
Maybe using a vbscript CA to just copy files to a needed path by reading %USERPROFILE% system variable?

Please post if you find a solutions.
Answered 01/11/2008 by: ogeccut
Black Belt

Please log in to comment
Well, i haven't found a solution, and i'm starting to think this could have something to do with our standard workstation installation, or even a "bug" with Active Setup it self. It's actually the second time i've encountered this "problem" which only seems to occur if users have local administrative rights on their workstations.

I know, in most organisations one wouldn't probably encounter users with these rights, but in my situation however, where not all software is being repackaged but only the software in use by 10+ users, it really isn't that unthinkable. In fact, we have some notorious banking software (a manual install unfortunately) that's won't run without these priviledges..

Anyways, there are always ways around problems that can't be fixed in a jiffy, so here's my "solution" to this problem.

I already had a MSI package which placed some files in: C:\program files\_user\packagename\Startup\
The "program files\_user\packagename$" folder is a folder where i store files needed for packages that utilize the duplicate file table repair functionality.
I needed active setup to:
* write a registry key to the CU hive;
* copy/heal the files (some word templates) to the folder APPDATA\microsoft\word\startup

So, if the folder doesn't exist already (e.g. Word hasn't started for the first time), it needs to be created, the registry key needs to be written and the files need to be copied after user logon.

So, what i've done is create a vb script that does this for me, store the VB scriptlocally on the machine (So, adding the script to the MSI as a file) and running it using Active setup the first time a user logs on to the target machine.

I guess some organisations could have strict rules whether or not scripts can be stored or even run locally. So if it suits you better you might want to create a custom action in a certain feature or something with some VB script code in the MSI and do a repair on that feature when the user logs on.. I chose the quickest way as mentioned before, storing the vb script locally (as a hidden file) and running it using AS.

My script, should you decide to try it:

On Error Resume Next
Dim Whsshell, FSO, TempPath, strpath
Set Shell = CreateObject("WScript.Shell")
Set WshShell = WScript.CreateObject("WScript.Shell")
Set FSO = CreateObject("Scripting.FileSystemObject")
Set objFSO = CreateObject("Scripting.FileSystemObject")

strpath = Shell.SpecialFolders("Appdata") + "\Microsoft\Word\Startup"
TempPath = ("C:\program files\_user\packagename\Startup\")

' Create the folder if it doesn´t exist yet, in 2 steps cause VBS can´t create the entire directory at once
if fso.FolderExists(strpath) = false then
strpath = Shell.SpecialFolders("Appdata") + "\Microsoft\Word\"
Set objFolder = objFSO.CreateFolder(strbestandpath)
set strpath = nothing
strpath = Shell.SpecialFolders("Appdata") + "\Microsoft\Word\Startup"
Set objFolder = objFSO.CreateFolder(strpath)
end if

' write the regkey so Word knows where to look for the templates
Shell.RegWrite "HKCU\Software\Microsoft\Office\11.0\Common\General\SharedTemplates", "c:\program files\templatefolder\", "REG_SZ"

' Start the copy
FSO.CopyFolder "C:\program files\_user\packagename\Startup", strpath, true

' Release strpath to clear memory
set strpath = nothing


Hope you find it usefull in any way. Could have done a better job with the vbs, but it seems to work and well, the organisation seemed like kind of in a hurry for me to get the MSI done/working.. :P (plus the fact that i'm no vb guru.. :P)
Answered 01/21/2008 by: neo2000
Purple Belt

Please log in to comment