Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

share|improve this question

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer
    
when i import the reg key, does it require enduser interaction –  Eddy Apr 14 '11 at 12:25
    
@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

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:

  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • If you are really unlucky and author an MSI that may self-repair 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).
  • 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.
  • 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.

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:

share|improve this answer
    
this is really good info thanks, ok then what is your suggestion for such case ? –  Eddy Jun 3 '11 at 9: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 3 '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: stackoverflow.com/questions/1423687/… –  Stein Åsmul Jun 3 '11 at 17:27

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?

share|improve this answer
    
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 3 '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. –  Alexander Miles Jun 3 '11 at 18:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.