Tech & Work

How do I use Regedit to ease the pain of an enterprise-wide software install?

A TechRepublic member offers his tip for making the installation of software across many workstations easier with a Windows Registry edit.
By John Scancella - in answer to a bounty

If you are a system administrator, you know the frustrations that can occur with configuring all the settings for a particular program or application. This is especially true when you must install the application on hundreds of computers and cannot afford the time to manually input the settings for each instance. This tip is one that I often use at work during these situations, when I cannot find the key in the Windows Registry file that stores the settings for the software.

Editor's note: Back up your Windows Registry before you edit the file. A corrupted Registry file could render the operating system inoperable.

This blog post is also available in PDF format in a free TechRepublic download.

So let's get to it. First you are going to need to export the registry before you make any changes. This way you can compare it to the Windows Registry that contains the configuration settings later. Regedit allows you to graphically edit the registry (Figure A). You can run regedit by going to Start | Run and typing regedit in the dialog box.

Figure A

Edit the registry.

As you can see, there are various subkeys, but we will worry about only two of them right now:


These two keys most often hold the registry values for the settings and configurations of installed software.

Next, we simply right-click on one of the two registry keys (in this case HKEY_CURRENT_USER) and click Export (Figure B).

Figure B

Export the keys.
Save the file as a text (.txt) file as it will make comparison easier later (Figure C). (Note: if you want to use the command-line tool, you should save it as a .reg.)

Figure C

Save the export.

Repeat these steps for the HKEY_LOCAL_MACHINE key.


Now that we have the registry saved, go ahead and change the settings for the software. Once you have changed the settings and verified that the software is running correctly, repeat the previous steps for exporting the registry (Figure D).

Figure D

Export again.

This second export is neeeded because we must compare the first registry that we exported before any changes were made to the exported registry after we changed the settings. The differences will show us what needs to be changed, so that when we install the software on many computers, they are already configured with the correct settings for the user.

OK, now that we have the registry keys before and after the software settings were changed, we need to compare them. At my job, we use a program called Workshare to compare Word documents for changes, but it also works for just plain text. Input the before and after text files we saved and click OK; this will start comparing the two documents for any changes (Figure E).

Figure E

Compare text file exports.
Because the registry is very large, it can take some time to compare the documents. If you are still in the process of documenting the install or have other work, now is a good time to get it done (Figure F).

Figure F

Slow and steady progress is made.

After it is done comparing, if no changes were found, you need to repeat the process for the other registry key (HKEY_LOCAL_MACHINE).

Now that we have the registry key(s) and the values of that key(s), we will modify the install of the software to match the change(s). This allows us to push out the software to any number of computers with the settings already configured during installation.

At my company we push out our applications through SCCM using VBScript. This is especially convenient not only because VBScript has built-in functions for modifying and writing to the registry, but also because it can run the .MSI or .EXE installer of the software. This allows the one script to both install and configure all the settings for the software, not only making debugging faster and easier but also ensuring the user has the correct configuration (Figure G).

Figure G

Look at an example comparison - Red is the previous value, blue the current value.
For those of you comfortable with the command line, there is a tool that you can use called FC (stands for File Compare). It is also a lot faster than Workshare, but it is not as easy to read the results (Figure H).

Figure H

File Compare displays these results.
After running the command, you get a text file that looks like Figure I.

Figure I

This is a text comparison from the command line.

On March 31, 2010, I republished an article from several years ago in the TechRepublic Microsoft Windows Blog, "10 Cool Registry Edits and Tweaks for Windows XP." Almost immediately, I received a snarky remark suggesting that I should publish only new tips regarding Windows XP. These comments irked me. So, I issued a challenge. I offered to pay a $300 bounty to anyone who could conceive of and then write, in a coherent publishable manner, a Windows XP tip that has never been published on TechRepublic before. So far, only one person has been able to meet the requirements. Have you got a new Windows XP tip for the Windows Blog in you? The bounty is still on, but have you got what it takes to collect?

Stay on top of the latest XP tips and tricks with TechRepublic's Windows XP newsletter, delivered every Thursday. Automatically sign up today!


Good and old idea. But a lot of work should be done after fc - you should find real differences and the real place of that differences in origin file. There is an nice utility RegShot, designed to easily compare two registry shots. Look here:


How do you edit another user's HKEY_CURRENT_USER, without doing the password/login/permissions dance to use their account (change pw, change permissions, log in, make change with REGEDIT, log out, change permissions, change pw, inform employee of new PW so they can change password to their choice) The only tip I've found for it hasn't worked.

Mark W. Kaelin
Mark W. Kaelin

Do you have a trick, tip or technique to help you make the installation of software across the network a little less frustrating?


If you're in a Domain environment you can accomplish this with KIX login scripts. Since the script runs when your user logs in, it's pretty easy to modify values in that user's Registry environment. We do this all the time on our network. You could probably do this with VBS scripts or even with DOS "bat" scripts, however we find KIX works well for us. Check it out at


Hi, Installrite ( is a free piece of software that watches your system while you install software. It will wait until you say the install is finished, enabling you to not only install the software, but also make tweaks to the setup before saving the results. You can then save an "install kit" for reuse later. Well worth a look... Gary


Use something like RegMon, so you can watch in real time. Just filter out everything unassociated with your applications processes, and watch the reg calls made. It's a lot faster than comparing two bulk exports of registry hives. I know Mark Russinovich stated he's no longer updating or supporting it, in favor of Process Monitor, but you can still download it.

Gis Bun
Gis Bun

There are other ways as well. Create a group policy that makes changes to the registry. [Not always easy or perfect.] You can also add the changes needed in a login script. If you need to make a one time change [i.e. you configured a deployed app one way but forgot one setting but 20,000 copies of the app was deployed], there are various registry tools that can modify a remote registry.


I would suggest researching and implimenting enterprise software distirbution via SCCM, LANDesk, ZENWork, Altirs, etc. With MSI packaging and/or additonal scripting all of this become a moot point. Even if you choose to do the work without one of those tools, you can use a VBScript from a login script to handle the configuration changes. If you have the tools to create/adjust an MSI you can run those via login script. In short there are several ways to solve this problem without going machine by machine.


Looks useful for other ways to correct MicroSoft.


You still need a package to push out through SCCM. Yes you can push out the install with a MSI through SCCM, but how do you notify users that do not look at their emails to know when software is going to be installed that takes 15 minutes? As you said there is more then one way to accomplish this, and sometimes it has been the only way. For example, we needed to change a setting for Microsoft Outlook. This program is installed and configured from our install image. It was actually less work to search the registry (especially if you us FC, which takes a few seconds) then to open a ticket with Microsoft and have them create a MSI to configure the settings. Finally, this tip is only to get the settings that have changed in the registry(if they are changed somewhere else then this will be of no help),what you do with the settings after you find them is a whole other article.

Editor's Picks