MSI package for reg deployment

What is the best way to create MSI package to deploy a registry key over a network, rather than using GPO.

There are many tools for building MSIs. I prefer Advanced Installer, which is available as a freeware version. Advanced Installer allows you to manually input registry keys/values, or import them from a file or live registry. It is quite simple to use.

Alternatively, if you don't need an MSI, you can easily manipulate the registry from the command line using the Windows utility reg.exe. This can be done remotely using tools such as psexec.

I wouldn't use an MSI to deploy registry settings. An MSI pointed at system settings is a "loose cannon". The MSI thinks it "owns" the key and will be trigger happy removing or reverting it. Here are some details:

• Unintentional Uninstall: If you author the MSI badly the component writing the settings will not be marked permanent, and if the MSI is ever uninstalled it will rip the whole registry key/value out. Note that if you upgrade the MSI a major upgrade may or may not perform a full uninstall before the new version is installed (depends on how the update is configured). If the reinstall then fails your registry key is missing.
• Group Policy: Certain registry keys on workstations are overwritten regularly (every 90 minutes or so) by domain controller commands - hence they may be reverted after your MSI is installed. Some further details here.
• Add / Remove Programs (ARP): Furthermore you get these MSI files showing up in the Add/Remove applet on the system where users can see them and potentially uninstall them. You can hide your MSI from this view by setting the ARPSYSTEMCOMPONENT property to 1. This will only prevent the display in add/remove though. The MSI can still be uninstalled from the command line or via script automation or a remote administration tool.
• Cleanup Mania: Even if your MSI is hidden in ARP, if you are using a deployment tool such as SCCM, Altiris, Unicenter, Tivoli or similar, a dilligent admin with cleanup-mania could decide to uninstall these "hack packages" and wreck havoc if the MSI wipes required settings. Remember that MSI files generally run elevated (temporary admin rights) as well, so they are definitely armed and dangerous if up to no good in the first place.
• System Restore: Installing an MSI will trigger the creation of a restore point on the PC (unless system restore is disabled). This could be time consuming and seems excessive if you are just writing a couple of values.
  • There are ways to speed up MSI installs (recommended read, but use with caution - disabling file costing could be ok, disabling system restore is dangerous).
  • System Restore is a troublesome feature. It seems to sometimes wipe out cached MSI files, delete some files unexpectedly and recover deleted files - among other things.

• Cyclical Self-Repair: If another MSI package references the same registry key, you might run into cyclical self-repair cycles under certain circumstances. Most admins have seen this at least a few times. Hard to fix if you don't know where to look. I have written a long answer for this on stackoverflow: how to debug cyclical self-repair (recommended read as well for system administrators). More on self-repair or "self-healing":

  • Self-repair - explained
  • Self-repair - finding real-world solutions
  • Self-repair - how to avoid it in your own package

• Package Interference: If you are really unlucky and author an MSI that may repair - which is invoked - or even just self-repair - which happens automagically - at some time, you could overwrite/revert settings that have been changed by subsequent changes. This kind of scenario is often hard to debug. You can find the package that caused the problem in the Event Log though. It even specifies what component caused the problem, but going from there requires MSI expertise. Good article on the subject from Stefan Kruger (MSI MVP).

• No Guarantee: Similarly to above, the fact that you see an MSI installed on the system is often seen as evidence that a system is "patched". What the presence of the MSI tells you is that the installer ran at one point, but you know nothing about the present registry state.
• HKCU: As others have mentioned, if the registry keys you are writing are under HKCU, they will only be written if the user in question happens to be logged on at the time the MSI is installed. Any other users will NOT have their registry updated. ActiveSetup can help here. ActiveSetup has been largely deprecated, you could use logon scripts, but don't use MSIs.

Those were just a few problems off the top of my head, I have certainly forgotten a few.

Other answers with core MSI information for system administrators:

• How to debug cyclical self-repair (important topic)
• The corporate benefits of MSI (may be useful for managers)
• How to extract files from setup.exe (worth a read for any admin, probably old news)
• Purpose of Administrative Installs (core MSI operation for system administrators)
• Common errors in MSI packages (more for developers, but also for system administrators)
• How to speed up MSI installations (just a couple of options)
• How to update every user profile using ActiveSetup (somewhat dangerous, but useful)