Software Deployment

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"

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.

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

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.

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

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.

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

wscript.quit

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)