4

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

jscott
  • 24,204
  • 8
  • 77
  • 99
Eddy
  • 257
  • 3
  • 10
  • 22

3 Answers3

9

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.

  • 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":

  • 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:

Stein Åsmul
  • 2,566
  • 4
  • 25
  • 38
  • this is really good info thanks, ok then what is your suggestion for such case ? – Eddy Jun 03 '11 at 09:44
  • The obvious choice for most values are GPO, but given you don't want to use that and I have one foot in development I would probably roll my own tool written in C# or similar to check the state of a single system or all systems for specific registry values. Other than that jscotts advice to use reg.exe could work ok I suppose. If the registry settings are per user I would recommend the use of "ActiveSetup" to ensure all users get the update, not just the ones logged on whilst installation is running. – Stein Åsmul Jun 03 '11 at 17:19
  • If you do end up using an MSI file, always make sure that the components it installs are set permanent. But don't :-). If you want to update user profiles / HKCU, try activesetup as described here: http://stackoverflow.com/questions/1423687/updating-every-profiles-registry-on-windows-server-2003 – Stein Åsmul Jun 03 '11 at 17:27
2

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.

jscott
  • 24,204
  • 8
  • 77
  • 99
  • 1
    when i import the reg key, does it require enduser interaction – Eddy Apr 14 '11 at 12:25
  • 1
    @Eddy No, you import the reg key as part of the MSI build process. When deploying the MSI, use something like `msiexec /i your.msi /qn` and the MSI will install without user interaction. – jscott Apr 14 '11 at 12:26
  • @Eddy you don't specify which registry hive you're manipulating, but beware of the differences between deploying reg keys under Local Machine and those under Current User. Your deployment tool may or may not give you the choice to run under the System or User contexts, and your user may or may not have permission to make changes to the Local System hive. – GAThrawn Apr 15 '11 at 16:16
1

You could always add it via a logon script, or whip up a script that uses psexec to deploy it via the command line remotely?

codewario
  • 548
  • 3
  • 16
  • 33
  • They did state *"rather than using GPO"*, so I didn't know if local GP would be a consideration. Also, why your user icon isn't the cardboard box, I'll never know. – jscott Jun 03 '11 at 17:57
  • Actually, I was more thinking of inside the user logon scripts. It's dirty but it does work. And I also use psexec at times to silently perform tasks without other users having to be bothered from their work. – codewario Jun 03 '11 at 18:26