Software Deployment

i think the switch I've used is /fpu
also don't forget you need this in both hklm and hkcu hives

Thank you for the response!

I have tried the /fpu switch as well and it did not work.

If I understand activesetup correctly should this reg key only go into HKLM and then HKCU compares the two locations and implements the repair if it is not found? I would have thought if I put it in both hives then the system would compare the versions and see they are the same and do nothing? I can get this to work for non-admin users just not from an admin to admin account. Am I off base in this assumption?

sorry not sure why that'd be the case. usually when it's not working I found I'm overlooking something

Thank you for the ideas!

Just a thought... is your transform maybe copying the active setup registry keys to .DEFAULT in HKEY_USERS when installed to the system account via SCCM? If it is, the active setup command won't run on users that have not yet logged into the machine, since it will get the key imported via .default.

I just pushed it to my test vm to check on the hive and it is installing to HKLM\Software\Microsoft\Active Setup\Installed Components, I logged off and logged back on and I get the Active Setup box show up but it is not copying the xml file to C:\Documents and Settings\userid\Local Settings\Application Data\Cognos\Office Connection when I log on as myself (an admin) but if I log off and on as a non-admin user it works fine (xml file is installed and our production server settings show up and the user can logon). I am not sure why an admin account makes a difference.

Sounds to me like you should try a verbose log from the stubpath command line, and see what it tells you. Might be something really obvious that you just can't see because it's run silently on login.

OK I added logging to the ActivSetup and installed the application with the local system account (to mimic a SCCM push) and here is what I see when I log on and it repairs (as admin):


00000304 MSI (s) (B4:F0) [09:51:15:398]: PROPERTY CHANGE: Adding INSTALLDIR property. Its value is 'C:\Program Files\Cognos\Cognos 8 for Microsoft Office\'.
00000305 MSI (s) (B4:F0) [09:51:15:398]: PROPERTY CHANGE: Adding COGNOS1 property. Its value is 'C:\Documents and Settings\myid\Local Settings\Application Data\Cognos\'.
00000306 MSI (s) (B4:F0) [09:51:15:398]: PROPERTY CHANGE: Modifying OFFICE_CONNECTION property. Its current value is 'C:\WINDOWS\system32\config\systemprofile\Local Settings\Application Data\Cognos\Office Connection'. Its new value: 'C:\WINDOWS\system32\config\systemprofile\Local Settings\Application Data\Cognos\Office Connection\'.
00000307 MSI (s) (B4:F0) [09:51:15:398]: PROPERTY CHANGE: Adding COGNOS property. Its value is 'C:\Documents and Settings\myid\Application Data\Cognos\'.

As a normal user I see this:

00000310 MSI (s) (B0:B8) [09:58:05:699]: PROPERTY CHANGE: Adding INSTALLDIR property. Its value is 'C:\Program Files\Cognos\Cognos 8 for Microsoft Office\'.
00000311 MSI (s) (B0:B8) [09:58:05:699]: PROPERTY CHANGE: Adding COGNOS1 property. Its value is 'C:\Documents and Settings\test\Local Settings\Application Data\Cognos\'.
00000312 MSI (s) (B0:B8) [09:58:05:699]: PROPERTY CHANGE: Adding OFFICE_CONNECTION property. Its value is 'C:\Documents and Settings\test\Local Settings\Application Data\Cognos\Office Connection\'.
00000313 MSI (s) (B0:B8) [09:58:05:699]: PROPERTY CHANGE: Adding COGNOS property. Its value is 'C:\Documents and Settings\test\Application Data\Cognos\'.

The path 'C:\Documents and Settings\xxxx\Local Settings\Application Data\Cognos\Office Connection\ is where the xml file needs to go and it works for a regular user, I am having a hard time figuring out why if it installs with the local system account the pathing does not go to the same place when an administrator logs on, it goes to here instead: 'C:\WINDOWS\system32\config\systemprofile\Local Settings\Application Data\Cognos\Office Connection\

Thank you for all your help.

Looks like you'll need to find out how the property OFFICE_CONNECTION is defined. Have you tried doing a search through the MSI tables to see what its source is?

I decided to start over with a new transform, I have the same issue with an Admin user account. I install the application with the local system account and it will install my frameworksettings.xml file into the following location: C:\Documents and Settings\NetworkService\Local Settings\Application Data\Cognos

The active setup works for non-admin user and puts the file into the user profile LocalAppDataFolder but not if you logon as an administrator. I am having a hard time understanding why there would be this difference between an admin logging on and a user logging on. Most of our users are locked down and this would not be an issue but our developers are admins on their devices so this becomes an issue.

Thank you all for your help!

save yourself the trouble do the install from sccm with a named account.

1)Add your XML file as an File into Your MST to some location
2)Write a vb script to copy m\c location to Required location.
3)Run vbs in active set up.

Hope it will work.

Add XML file in the MST to the some machine location.
write a vb script to copy XML file from Machine location to required location.
trigger vb script in active set up.
aslo need to add vbs as file in MST.

Just a thought but have you checked to see if there is a redirection on the ADMIN account in group policy ?

I am having a very similar problem and I think the problem has nothing to do with ActiveSetup. I would love to get some help in figuring out what I am doing wrong and/or how to make it work.

Here's my scenario: I have a client that wants to push software (home grown, so we own the MSI file) to a bunch of machines at night while nobody is logged in (via SCCM and yet another home grown deployment app). These installs will take place under the LOCAL_SYSTEM or SYSTEM account. Obviously anything that belongs in a user's 'profile' won't get installed correctly (HKCU entries, files in %appdata%, etc.) They have asked me to wedge ActiveSetup into this package to solve the problem - everybody gets the local files and registry keys when they first log in via a repair install.

All sounds good, and in fact the HKCU registry keys work fine, but files installed into %appdata% don't get repaired.

In the interest of making things simple, I have created a tiny Notepad installer to flail about in, and I can duplicate the issue without using ActiveSetup. The installer puts a copy of Notepad.exe into a folder in %programfiles% and a .txt file into a folder in the user's %appdata% folder. The installer also creates two string registry values in the user's HKCU registry hive.

When I run my NotepadInstaller under the System account the text file gets installed into:
C:\WINDOWS\SysWOW64\config\systemprofile\Application Data\InstallerFactory\ActiveSetupNotepad

I guess this is what the %appdata% directory name resolves to when running a per-user installation under the System account.

I then run a repair install from a command line (logged in as local administrator) exactly the way I would run it in ActiveSetup upon login (with the addition of the log file for debugging):
msiexec /fua {product code} /qn /vl* repair.log

This should simulate the ActiveSetup part without all that logging out and back in, right?

The problem is that the text file never gets installed into the user's %appdata% path. It does get replaced in the original path if I delete it.

Here is the interesting snippet from the repair.log:
[blockquote]
[font="courier new"]MSI (s) (70:28) [18:04:03:982]: Executing op: FileCopy(SourceName=ACTIVE~1.TXT|ActiveSetupNotepadDataFile.txt,SourceCabKey=activesetupnotepaddatafile.t1,DestName=ActiveSetupNotepadDataFile.txt,Attributes=16384,FileSize=41,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=20971520,HashOptions=0,HashPart1=144051981,HashPart2=1985051018,HashPart3=-943810598,HashPart4=-1702673323,,)
[font="courier new"]MSI (s) (70:28) [18:04:03:982]: File: C:\WINDOWS\SysWOW64\config\systemprofile\Application Data\InstallerFactory\ActiveSetupNotepad\ActiveSetupNotepadDataFile.txt; Overwrite; Won't patch; REINSTALLMODE specifies all files to be overwritten
[font="courier new"]MSI (s) (70:28) [18:04:03:982]: Source for file 'activesetupnotepaddatafile.t1' is compressed
[font="courier new"]MSI (s) (70:28) [18:04:03:982]: Re-applying security from existing file.
[font="courier new"]MSI (s) (70:28) [18:04:04:044]: Verifying accessibility of file: ActiveSetupNotepadDataFile.txt
[font="courier new"]MSI (s) (70:28) [18:04:04:060]: Note: 1: 2318 2: C:\WINDOWS\SysWOW64\config\systemprofile\Application Data\InstallerFactory\ActiveSetupNotepad\ActiveSetupNotepadDataFile.txt[/blockquote]
It seems like the repair install is not reevaluating the target directory for the logged in user.

Just a side note on the registry keys. The interesting bits from the original install log and the repair log are identical:
[blockquote]
[font="courier new"]MSI (s) (70:28) [18:04:04:060]: Executing op: ActionStart(Name=WriteRegistryValues,Description=Writing system registry values,Template=Key: [1], Name: [2], Value: [3])
[font="courier new"]MSI (s) (70:28) [18:04:04:060]: Executing op: ProgressTotal(Total=2,Type=1,ByteEquivalent=13200)
[font="courier new"]MSI (s) (70:28) [18:04:04:060]: Executing op: RegOpenKey(Root=-2147483647,Key=InstallerFactory\ActiveSetupNotepad,,BinaryType=0)
[font="courier new"]MSI (s) (70:28) [18:04:04:060]: Executing op: RegAddValue(Name=ProductVersion,Value=1.00.0000,)
[font="courier new"]MSI (s) (70:28) [18:04:04:060]: Executing op: RegAddValue(Name=Version,Value=1.00.0000,)[/blockquote]
Note that the root key is exactly the same in both the install and the repair: -2147483647. (I can only assume this is HKEY_CURRENT_USER, but the math doesn't work out correctly. HKEY_CURRENT_USER is defined as 0x80000001, which should be 2147483649, not ...647. Not sure what is going on here.) It seems like the repair install just asks for the HKCU root during install and gets the System root. When it asks for the HKCU root during the repair it gets the current user's root. Pretty simple. Pretty clever, really.

Things I have tried:

• 
  Fiddling with all possible values of ALLUSERS property in the original .msi file[/align]
• 
  Every permutation of flag on the repair install[/align]
• 
  Running msiexec /i {product code} REINSTALL=ALL REINSTALLMODE=vomous /qn (and all other reasonable reinstall modes)[/align]
• 
  Making sure the file in question is a key file in the component, etc.[/align]

So I guess my question is this: How do I get a repair install to reevaluate a destination path for a file? Or is there something in my ActiveSetup simulation that is throwing me off and has me chasing a red herring?

I have searched the AppDeploy web site to the best of my ability and I have not seen a thread closer than this one, so please - if you know where this issue is addressed then point me there.

Thanks in advance for any hints, pointers, suggestions, etc. I am stuck on this one.


Dave

But first, let me apologize for the formatting in my post. I don't know why my text is running off the right of the window while every other post seems to wrap correctly. Sorry about that.

Dave

Problem solved.

I found a clue in this thread: http://itninja.com/question/silent-uninstall-oracle-8-cilent0079

pjgeutjens suggested adding a KeyPath for the component to an HKCU registry key, so I changed the KeyPath from the file to the registry key and now it works.

The interesting section from the repair log file now looks like this:

MSI (s) (94:C8) [20:14:26:966]: Executing op: FileCopy(SourceName=ACTIVE~1.TXT|ActiveSetupNotepadDataFile.txt,SourceCabKey=activesetupnotepaddatafile.t1,DestName=ActiveSetupNotepadDataFile.txt,Attributes=16384,FileSize=41,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=20971520,HashOptions=0,HashPart1=144051981,HashPart2=1985051018,HashPart3=-943810598,HashPart4=-1702673323,,)
MSI (s) (94:C8) [20:14:26:966]: File: C:\Documents and Settings\Administrator\Application Data\InstallerFactory\ActiveSetupNotepad\ActiveSetupNotepadDataFile.txt; To be installed; Won't patch; No existing file
MSI (s) (94:C8) [20:14:26:966]: Source for file 'activesetupnotepaddatafile.t1' is compressed
MSI (s) (94:C8) [20:14:26:966]: Note: 1: 2318 2: C:\Documents and Settings\Administrator\Application Data\InstallerFactory\ActiveSetupNotepad\ActiveSetupNotepadDataFile.txt



... and the text file shows up in the user's %appdata% folder.

So thanks to everyone on AppDeploy, especially [color=#0066cb size=2][font="times new roman"]pjgeutjens. Now, anyone have any thoughts on how to get rid of the data that gets left behind in the file system and registry for all the non-logged in users (including the system profile) when a user uninstalls the application?

(And yes, I figured out why my text was wrapping - it was sizing the canvas to the longest line in the copy/pasted log file because I wasn't using the code tags.)

Thanks,

Dave