Software Deployment

Er...why not simply write to HKEY_USERS\.Default?

HKEY_USERS\.Default is used by the System account, not new users.

So it is! I'd forgotten that. In recalling it, a distant memory came to me about a solution I came across at a client site, where an Active Setup script would determine a user's "new" status by comparing the date/time of the local profile with the current date/time....I'll see if I can find anyone I know who's still there.

Do I also recall that the command line utility REG.EXE can load profiles? Of course, the user needs to be logged off first.

EDIT:
http://blogs.technet.com/deploymentguys/archive/2008/06/06/useful-script-number-5-adjusting-the-default-user-registry-hive.aspx

Why don't you want to use active setup? You can run it with silent paramters so the users shouldn't notice it. If you need to change the Default Users HKCU key then it sounds like you need to address this with your image creation and not at the software level. I would fix it there by exporting the .dat, mount that hive and make the changes, then unload the hive and copy it back to your image. At the software level, this request seems unattainable if you don't want to use self-healing or active setup.

The vbscript above will do the loading of the hive like I am referring to. But even easier, if you are using a XP SP3 sysprep'd image just make the changes under the administrator account and add this, UpdateServerProfileDirectory=1 , under the section [Unattended] in sysprep.inf. That will copy the administrator profile over the Default User profile during sysprep.

Basically all my users are always 'new', so those dialog boxes would run on every login or program launch. I didn't know the active setup could be hidden, but you have to hope the user doesn't run the application before the active update is done. I don't think I should have to make a new image every time I upgrade IE or Itunes. I have ways to update the default user hive with Altiris Rapidinstall (which Altiris deprecates) or reg.exe, but I think it's a major shortcoming that Windows Installer can't do it.

Self-healing alone does this unless your users are clicking cancel, or the components are not set up properly within the package. The self-heal only occurs once per user if you let it complete. If it runs every time you click the shortcut the package is not set up properly. You mention IE. This uses Active Setup natively to accomplish this task (IEAK). You aren't repackging that application right? R.I.P. RIPs, those were old four years ago :)

Active Setup itself is not transparent, but you can make the stubpath silent. Additionally, Active setup is going to run for a new user anyways to configure the base OS stuff so you can just tag your app on the end if for some reason a self-heal (from a dekstop shortcut, etc..) doesn't work. I believe the solution below is more complex then you require, but I'll give the example regardless.

Active setup won't let the desktop load until it is done running. So in your package make an entry under:

HKLM\Software\Microsoft\Active Setup\Installed Components\{GUID of APP}

(Default) REG_SZ Name of Software
StubPath REG_SZ msiexec.exe /fu {GUID of APP} /qn
Version REG_SZ 1

This will silently kick off a self-heal if a HKCU entry needs created for a new user because the versions will not match (1 > null), thus triggering the Stubpath.

I usually script an install using msi silent install flags or autoit inside a rapidinstall package. If I need any hkey_current_user registry entries in the default user hive, Rapidinstall automatically puts them in.