How do I tell Internet Explorer to trust a security certificate?

Certificates are supposed to prove that you're connecting to the site you think you're connecting to, something that's particularly important if you're about to share sensitive data with the site or download a program or system patch. I won't even talk about phishing and how that ups the ante of site verification (though you can read about it here: Paypal and eBay alerts: legit or phishing?)

Since having a site certify itself doesn't make sense -- because the site could just as easily have a forged security certificate -- there are third party Certification Authorities that act as what security folk call 'trusted third parties'. It used to be that there were just two or three of these authorities, but now there are more, and what's happened in your situation is that you've somehow ended up indicating to your Web browser, Internet Explorer, that you don't trust the third party certification authority that a particular site is using.

But don't panic. This can be fixed and pretty easily at that. Go into Internet Explorer then choose Tools -> Internet Options, then click on the Content tab. The middle of that window will show you different options regarding Certificates. Click on the middle button, labeled "Certificates..."

Now you'll see something that's an interesting user interface gaffe on Microsoft's

part because the tabs on this window don't fit in the window, so you need to click on the tiny right arrow by the rightmost tab. Once you can see it, click on "Untrusted Publishers". You'll end up with a window that looks like this:

You should see the publisher listed that's causing you such problems. On my screen, I have two certificates from Microsoft, published by VeriSign, as you can see. Just delete the entries here by clicking on each one to select it, then clicking "Remove".

Quit the browser, restart, and everything should be good to go!

Creating a Self-Signed Certificate using OpenSSL for use with Microsoft Internet Information Services (IIS) 5

---

Overview

This document describes how to sign your own SSL certificate requests using the OpenSSL toolkit and use these self-signed certificates to allow HTTPS connections to Microsoft's IIS 5 web server (as supplied with Windows 2000).

If you know what a self-signed certificate is and understand the concept of a certificate authority, great. If not, this should still work but you'll have no idea what you've acheived when it does :)

Command transcripts are shown in monospaced type, with the bits you type shown in bold. Bits in italics are comments to explain what's going on and what you should be doing.

---

Disclaimer

I'm by no means a security expert, and I'm not an OpenSSL guru. If you find these notes helpful, great - if you don't, there's plenty of more detailed resources out there which will answer your questions if you take the time to read them properly. Contributions and testimonials are welcome; questions will be read and possibly answered but I'm making no guarantees, and please don't rely on this information for anything important. I don't know whether it's the most secure or most effective way of doing this, but it works and that's good enough for me. If it's not good enough for you, don't use it :)

These instructions were tested using OpenSSL 0.9.6g (v1.0 Final) on Windows 2000 Server running Service Pack 3.

---

Ingredients

• Windows 2000 running Internet Information Services (IIS)
• The OpenSSL tools for Windows from Shining Light Productions. This is a Windows port of the popular OpenSSL toolkit.

Walkthrough

Install and configure the OpenSSL toolkit

1. Get OpenSSL from the address above, and run the installer, accepting the defaults. These instructions assume OpenSSL is installed in C:\OpenSSL.
2. Add C:\OpenSSL\bin to your system path (Control Panel, System, Advanced, Environment Variables, System Variables) - this isn't strictly necessary but it makes things a lot easier.
3. Create a working directory - here, we'll use c:\ssl as our working folder.
4. Download this copy of openssl.conf to your working folder. (Note: I have no idea what most of the options in this file mean. I just hacked it around until it worked...)
5. Set up the directory structure and files required by OpenSSL:

   C:\ssl>md keys
   
   C:\ssl>md requests
   
   C:\ssl>md certs
   

6. Create the file database.txt - an empty (zero-byte) text file. This can be done using the 'touch' command if you have it (it's a Unix tool not available on Windows by default, but you might have one lying around), or by creating an empty file manually:

   c:\ssl>copy con database.txt
   ^Z
   
   C:\ssl>
   

   MS-DOS veterans will recognise this particular invocation. We're copying from CON (the console) to a file called database.txt, and that's a Control-Z end-of-file character on the first line. This should produce a zero-byte file called c:\ssl\database.txt
7. Create the serial number file serial.txt. This is a plain ASCII file containing the string "01" on the first line, followed by a newline. Again, we can use a little bit of ancient DOS magic:

   C:\ssl>copy con serial.txt
   01
   ^Z
   
   C:\ssl>
   

   to achieve the desired effect. (That's keystrokes zero, one, return, control-Z, return)

Set up a Certificate Authority (CA)

1. First, we create a 1024-bit private key to use when creating our CA.:

   C:\ssl>openssl genrsa -des3 -out keys/ca.key 1024
   Loading 'screen' into random state - done
   warning, not much extra random data, consider using the -rand option
   Generating RSA private key, 1024 bit long modulus
   ...........++++++
   ..................++++++
   e is 65537 (0x10001)
   Enter PEM pass phrase:  - choose a memorable pass phrase to use for this key
   Verifying password - Enter PEM pass phrase:  - type your pass phrase again for verification
   

   The pass phrase will be requested whenever you use this certificate for anything, so make sure you remember it. This will create a file called c:\ssl\keys\ca.key, containing our certificate authority private key.
2. Next, we create a master certificate based on this key, to use when signing other certificates:

   C:\ssl>openssl req -config openssl.conf -new -x509 -days 1001 -key keys/ca.key -out certs/ca.cer
   Using configuration from openssl.conf
   Enter PEM pass phrase:  - type your passphrase here.
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) []:GB
   State or Province Name (full name) []:Hampshire
   Locality Name (eg, city) []:Southampton
   Organization Name (eg, company) []:dylanbeattie.net
   Organizational Unit Name (eg, section) []:
   Common Name (eg, your websites domain name) []:ssl.dylanbeattie.net
   Email Address []:ssl@dylanbeattie.net
   
   C:\ssl>
   

   This will create our CA certificate and store it as c:\ssl\certs\ca.cer
3. (optional) Finally, we export our CA certificate in PKCS12 format - this will allow Windows users to import the PKCS12 certificate into their Trusted Root Store, so they don't get warning messages every time they use one of our certificates. From the OpenSSL FAQ:

   12. How do I install a CA certificate into a browser?

   The usual way is to send the DER encoded certificate to the browser as MIME type application/x-x509-ca-cert, for example by clicking on an appropriate link. On MSIE certain extensions such as .der or .cacert may also work, or you can import the certificate using the certificate import wizard.

   You can convert a certificate to DER form using the command:

   openssl x509 -in ca.pem -outform DER -out ca.der

   Occasionally someone^* suggests using a command such as:

   openssl pkcs12 -export -out cacert.p12 -in cacert.pem -inkey cakey.pem

   DO NOT DO THIS! This command will give away your CAs private key and reduces its security to zero: allowing anyone to forge certificates in whatever name they choose.

   * Guilty as charged - sorry! This guide originally recommended the insecure method warned about above. Thanks to Baahl for pointing out the error and Marco Fagiolini for the correct method.

Create an IIS Certificate Request

This is described in detail elsewhere on the web - see Microsoft Knowledge Base Article Q228821. You should end up with a file called certreq.txt.

Sign the Certificate Request

1. Copy the certreq.txt file into c:\ssl\requests
2. Sign the request

   C:\ssl>openssl ca -policy policy_anything -config openssl.conf -cert certs/ca.cer -in requests/certreq.txt -keyfile keys/ca.key -days 360 -out certs/iis.cer
   Using configuration from openssl.conf
   Loading 'screen' into random state - done
   Enter PEM pass phrase:
   Check that the request matches the signature
   Signature ok
   The Subjects Distinguished Name is as follows
   commonName            :PRINTABLE:'myCommonName'
   organizationalUnitName:PRINTABLE:'myOrganisationalUnit'
   organizationName      :PRINTABLE:'myOrganisation'
   localityName          :PRINTABLE:'myLocality'
   stateOrProvinceName   :PRINTABLE:'myProvince'
   countryName           :PRINTABLE:'GB'
   Certificate is to be certified until Feb  2 01:13:14 2004 GMT (360 days)
   Sign the certificate? [y/n]:y
   
   
   1 out of 1 certificate requests certified, commit? [y/n]y
   Write out database with 1 new entries
   Data Base Updated
   
   C:\ssl>
   

   Let's just take a look at those command-line options in a bit more detail:
   • -policy policy_anything - specifies that we're using the 'policy_anything' policy from our openssl.conf file. This is a relaxed policy in which the name, country, etc. in the certificate don't need to match those used by the certification authority. Use -policy policy_match for a more restrictive CA.
   • -config openssl.conf - specifies we're reading our configuration from openssl.conf in the current directory.
   • -cert certs/ca.cer - specifies we're using our CA master certificate to sign the request.
   • -in requests/certreq.txt - the certificate request we're signing.
   • -keyfile keys/ca.key - the private key for our CA master certificate, which proves we're allowed to use it.
   • -days 360 - the time until the certficate will expire
   • -out certs/iis.cer - the file in which to place our newly-signed certificate
3. Convert the signed certificate into x509 format for use with IIS:

   C:\ssl>openssl x509 -in certs/iis.cer -out certs/iisx509.cer
   
   C:\ssl>
   

   This will leave the new certificate in c:\ssl\certs\iisx509.cer - signed, sealed and ready to install

Install the new certificate under IIS

Again, this is described elsewhere on the web - remember that the iisx509.cer file is our certificate response file, and the instructions in Knowledge Base article 228836 should make everything clear.

---

Links & Acknowledgements

OpenSSL for Windows: http://www.shininglightpro.com/

Creating a Self-Signed Certificate using OpenSSL for use with Microsoft Internet Information Services (IIS) 5

---

Overview

This document describes how to sign your own SSL certificate requests using the OpenSSL toolkit and use these self-signed certificates to allow HTTPS connections to Microsoft's IIS 5 web server (as supplied with Windows 2000).

If you know what a self-signed certificate is and understand the concept of a certificate authority, great. If not, this should still work but you'll have no idea what you've acheived when it does :)

Command transcripts are shown in monospaced type, with the bits you type shown in bold. Bits in italics are comments to explain what's going on and what you should be doing.

---

Disclaimer

I'm by no means a security expert, and I'm not an OpenSSL guru. If you find these notes helpful, great - if you don't, there's plenty of more detailed resources out there which will answer your questions if you take the time to read them properly. Contributions and testimonials are welcome; questions will be read and possibly answered but I'm making no guarantees, and please don't rely on this information for anything important. I don't know whether it's the most secure or most effective way of doing this, but it works and that's good enough for me. If it's not good enough for you, don't use it :)

These instructions were tested using OpenSSL 0.9.6g (v1.0 Final) on Windows 2000 Server running Service Pack 3.

---

Ingredients

• Windows 2000 running Internet Information Services (IIS)
• The OpenSSL tools for Windows from Shining Light Productions. This is a Windows port of the popular OpenSSL toolkit.

Walkthrough

Install and configure the OpenSSL toolkit

1. Get OpenSSL from the address above, and run the installer, accepting the defaults. These instructions assume OpenSSL is installed in C:\OpenSSL.
2. Add C:\OpenSSL\bin to your system path (Control Panel, System, Advanced, Environment Variables, System Variables) - this isn't strictly necessary but it makes things a lot easier.
3. Create a working directory - here, we'll use c:\ssl as our working folder.
4. Download this copy of openssl.conf to your working folder. (Note: I have no idea what most of the options in this file mean. I just hacked it around until it worked...)
5. Set up the directory structure and files required by OpenSSL:

   C:\ssl>md keys
   
   C:\ssl>md requests
   
   C:\ssl>md certs
   

6. Create the file database.txt - an empty (zero-byte) text file. This can be done using the 'touch' command if you have it (it's a Unix tool not available on Windows by default, but you might have one lying around), or by creating an empty file manually:

   c:\ssl>copy con database.txt
   ^Z
   
   C:\ssl>
   

   MS-DOS veterans will recognise this particular invocation. We're copying from CON (the console) to a file called database.txt, and that's a Control-Z end-of-file character on the first line. This should produce a zero-byte file called c:\ssl\database.txt
7. Create the serial number file serial.txt. This is a plain ASCII file containing the string "01" on the first line, followed by a newline. Again, we can use a little bit of ancient DOS magic:

   C:\ssl>copy con serial.txt
   01
   ^Z
   
   C:\ssl>
   

   to achieve the desired effect. (That's keystrokes zero, one, return, control-Z, return)

Set up a Certificate Authority (CA)

1. First, we create a 1024-bit private key to use when creating our CA.:

   C:\ssl>openssl genrsa -des3 -out keys/ca.key 1024
   Loading 'screen' into random state - done
   warning, not much extra random data, consider using the -rand option
   Generating RSA private key, 1024 bit long modulus
   ...........++++++
   ..................++++++
   e is 65537 (0x10001)
   Enter PEM pass phrase:  - choose a memorable pass phrase to use for this key
   Verifying password - Enter PEM pass phrase:  - type your pass phrase again for verification
   

   The pass phrase will be requested whenever you use this certificate for anything, so make sure you remember it. This will create a file called c:\ssl\keys\ca.key, containing our certificate authority private key.
2. Next, we create a master certificate based on this key, to use when signing other certificates:

   C:\ssl>openssl req -config openssl.conf -new -x509 -days 1001 -key keys/ca.key -out certs/ca.cer
   Using configuration from openssl.conf
   Enter PEM pass phrase:  - type your passphrase here.
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) []:GB
   State or Province Name (full name) []:Hampshire
   Locality Name (eg, city) []:Southampton
   Organization Name (eg, company) []:dylanbeattie.net
   Organizational Unit Name (eg, section) []:
   Common Name (eg, your websites domain name) []:ssl.dylanbeattie.net
   Email Address []:ssl@dylanbeattie.net
   
   C:\ssl>
   

   This will create our CA certificate and store it as c:\ssl\certs\ca.cer
3. (optional) Finally, we export our CA certificate in PKCS12 format - this will allow Windows users to import the PKCS12 certificate into their Trusted Root Store, so they don't get warning messages every time they use one of our certificates. From the OpenSSL FAQ:

   12. How do I install a CA certificate into a browser?

   The usual way is to send the DER encoded certificate to the browser as MIME type application/x-x509-ca-cert, for example by clicking on an appropriate link. On MSIE certain extensions such as .der or .cacert may also work, or you can import the certificate using the certificate import wizard.

   You can convert a certificate to DER form using the command:

   openssl x509 -in ca.pem -outform DER -out ca.der

   Occasionally someone^* suggests using a command such as:

   openssl pkcs12 -export -out cacert.p12 -in cacert.pem -inkey cakey.pem

   DO NOT DO THIS! This command will give away your CAs private key and reduces its security to zero: allowing anyone to forge certificates in whatever name they choose.

   * Guilty as charged - sorry! This guide originally recommended the insecure method warned about above. Thanks to Baahl for pointing out the error and Marco Fagiolini for the correct method.

Create an IIS Certificate Request

This is described in detail elsewhere on the web - see Microsoft Knowledge Base Article Q228821. You should end up with a file called certreq.txt.

Sign the Certificate Request

1. Copy the certreq.txt file into c:\ssl\requests
2. Sign the request

   C:\ssl>openssl ca -policy policy_anything -config openssl.conf -cert certs/ca.cer -in requests/certreq.txt -keyfile keys/ca.key -days 360 -out certs/iis.cer
   Using configuration from openssl.conf
   Loading 'screen' into random state - done
   Enter PEM pass phrase:
   Check that the request matches the signature
   Signature ok
   The Subjects Distinguished Name is as follows
   commonName            :PRINTABLE:'myCommonName'
   organizationalUnitName:PRINTABLE:'myOrganisationalUnit'
   organizationName      :PRINTABLE:'myOrganisation'
   localityName          :PRINTABLE:'myLocality'
   stateOrProvinceName   :PRINTABLE:'myProvince'
   countryName           :PRINTABLE:'GB'
   Certificate is to be certified until Feb  2 01:13:14 2004 GMT (360 days)
   Sign the certificate? [y/n]:y
   
   
   1 out of 1 certificate requests certified, commit? [y/n]y
   Write out database with 1 new entries
   Data Base Updated
   
   C:\ssl>
   

   Let's just take a look at those command-line options in a bit more detail:
   • -policy policy_anything - specifies that we're using the 'policy_anything' policy from our openssl.conf file. This is a relaxed policy in which the name, country, etc. in the certificate don't need to match those used by the certification authority. Use -policy policy_match for a more restrictive CA.
   • -config openssl.conf - specifies we're reading our configuration from openssl.conf in the current directory.
   • -cert certs/ca.cer - specifies we're using our CA master certificate to sign the request.
   • -in requests/certreq.txt - the certificate request we're signing.
   • -keyfile keys/ca.key - the private key for our CA master certificate, which proves we're allowed to use it.
   • -days 360 - the time until the certficate will expire
   • -out certs/iis.cer - the file in which to place our newly-signed certificate
3. Convert the signed certificate into x509 format for use with IIS:

   C:\ssl>openssl x509 -in certs/iis.cer -out certs/iisx509.cer
   
   C:\ssl>
   

   This will leave the new certificate in c:\ssl\certs\iisx509.cer - signed, sealed and ready to install

Install the new certificate under IIS

Again, this is described elsewhere on the web - remember that the iisx509.cer file is our certificate response file, and the instructions in Knowledge Base article 228836 should make everything clear.

---

Links & Acknowledgements

OpenSSL for Windows: http://www.shininglightpro.com/

How to restore default NTFS permissions on Windows 2000/XP

To restore Windows 2000/XP’s default system security you can execute following command:


secedit /configure /cfg "%systemroot%\security\templates\setup security.inf" /db waisaw.sdb /verbose


Note that file “%systemroot%\security\templates\setup security.inf” must exist.

XP's No-Reformat, Nondestructive Total-Rebuild Option

This Blog Entry shows you how to completely rebuild, repair, or refresh an existing XP installation without losing data, and without having to reinstall user software, reformat, or otherwise destructively alter the setup.

It's one of those software design decisions that makes you scratch your head and wonder, "What were they thinking?"

The "it" in this case is XP's most powerful rebuild/repair option, and yet Microsoft chose to hide it behind seeming dead ends, red herrings, and a recycled interface that makes it hard to find and (at first) somewhat confusing to use.

But it's worth exploring because this option lets you completely and nondestructively rebuild, repair, or refresh an existing XP installation while leaving already-installed software alone (no reinstallation needed!). It also leaves user accounts, names, and passwords untouched and takes only a fraction of the time a full, from-scratch reinstall does. And unlike a traditional full reinstall, this option doesn't leave you with two copies of XP on your hard drive. Instead, you end up with just the original installation, but repaired, refreshed, and ready to go.

We've saved this technique for last in our discussion of the various XP repair/rebuild options because the fixes we've previously discussed are like first aid--the things you try first. For instance, see this discussion on removing limitations on XP's Recovery Console, turning it into a more complete repair tool; or this discussion on the Recovery Console's little-known "Rebuild" command that can cure many boot-related problems. (There's also lots more on the Recovery Console here.

But when the Recovery Console techniques don't work, and you're facing the prospects of a total reformat/reinstall, stop! Try the no-reformat reinstall technique we're about to illustrate, and you just may get your XP setup running again in a fraction of the time and with a fraction of the hassle of a grand mal wipe-and-restore.

The First Fork In The Road
The no-reformat reinstall operation starts with a normal boot from an XP setup CD. Ideally, to save time, use a setup CD that's been "slipstreamed" to include the SP1 and SP2 patches and upgrades. (Need info on slipstreaming? See "How To Save An Hour (Or More) On XP Installs" and also this third-party site.

Start your PC with the setup CD in a drive, and hit a key when you see the following screen:

Screen One Boot from your XP setup CD to gain access to the no-reformat reinstall option. (click image for larger view)

If instead of booting to the CD your PC boots from the hard drive, you may need to modify your PC's "boot order." It's easy and only takes a minute to make the change so that the PC will check for a bootable CD before trying to boot from the hard drive. See this for more information.

Once your PC starts to boot from the CD, you'll see something like what's shown in Screen 2:

Screen Two Let the CD boot proceed normally and automatically through "Setup is inspecting your computer's hardware..." to the "Windows Setup" screen. (click image for larger view)

After a minute or two, you'll see the "Windows Setup/Setup is starting Windows" screen, shown in Screen Three. Don't be alarmed: It's still just the setup process running, and nothing's been changed on your PC yet.

(click image for larger view)

Screen Three The "Starting Windows" screen is a bit of an overstatement; it's just the setup process getting going. Windows, as we normally think of it, isn't running yet, and no changes have been made to your PC.

Soon after Screen Three, you'll be presented with the normal "Welcome to Setup" screen, as shown in Screen Four.

Screen Four The "Welcome to Setup" screen is poorly worded; the "Repair" option we want isn't the one explicitly offered here. In fact, the repair option we want isn't shown at all. See the text for full detail.

(click image for larger view)

The poorly worded options in Screen Four lead many users astray. The only mention of "Repair" here is "...repair a Windows XP installation using Recovery Console..." but that's not the no-reformat repair/reinstall we're seeking. (The Recovery Console Repair option is useful in its own right for fixing relatively minor problems with the operating system, and we fully explore it in the links listed above.)

The repair option we do want--a nondestructive, no-reformat reinstall--is actually hidden beneath the Setup option, "To set up Windows XP now, press ENTER."

So hit Enter, just as if you were setting up Windows afresh and from scratch.

The next screen, about licensing, gives no reassurances that you're on the right path for a nondestructive repair/reinstall--in fact, it's the same screen you see when you're setting XP up on a virgin hard drive. But this is only the first of many screens that the Repair option will borrow from a full-blown setup. Press F8 to accept the licensing terms and to go on.

(click image for larger view)

Screen Five The licensing screen gives no indication that this is a Repair and not a brand-new, from-scratch installation. But don't be alarmed. You're on the right track.

Next, the XP setup process will show another screen that you may recall from your initial setup of XP. It searches for "a previous version of Microsoft Windows." In our case, we're not replacing a previous version of Windows, but rather repairing the very same version that's on the setup CD--but that's OK; it's just another poorly worded screen.

Screen Six Our intent is to repair the same version of Windows as is on the setup CD, but another poorly worded screen makes it seem like you're upgrading a previous version of Windows or installing one anew. But don't let the bad wording alarm you; we're still on track for a nondestructive reinstall.

(click image for larger view)

Screen Seven finally shows verbiage that's not recycled from the generic XP setup, but is specific to our Repair task. Setup should find your damaged copy of XP and present it for repair, as shown:

(click image for larger view)

Screen Seven At long last, Setup begins to refer to a Repair option. Here, Setup should have found your damaged XP setup, which you can select and then press R to start the nondestructive repair.

If your damaged copy of XP isn't highlighted in the list box, highlight it now. When it's selected, press R to start the repair process.

The Repair process then selectively deletes system files in the \Windows folder and subfolders and copies undamaged replacement files from the setup CD to their proper locations.

Screen Eight The Repair operation replaces all potentially damaged system files with fresh copies from the CD. (click image for larger view)

The Repair process then works on the current setup's Registry, leaving much of it intact and rebuilding the rest.

(click image for larger view)

Screen Nine There's no fanfare, but this is one of the nicer parts of the Repair process: Setup retains what it can in the current Registry so that already-installed hardware and software will remain installed.

The system then needs to reboot and will do so automatically. If your setup CD is still in the drive, remove it so that the system won't try to boot from it.

Screen Ten With the system files freshly copied and the Registry ready for rebuilding, the system needs to reboot. Remove the CD from the drive so that the PC will boot to the hard drive instead of to the CD. (click image for larger view)

The first Repair reboot will take longer than normal. Don't be alarmed. Also, don't be alarmed when Setup resumes. Once again, it will appear that you're performing a full, from-scratch setup; there's nothing on-screen to indicate that you're repairing an existing version of XP. But although the setup screens are the same as what you'd see in a full install, it's still a repair process, as will become clearer in a moment.

The first two of the Repair setup screens ask for your language preferences and product key. Enter these normally.

	Screen Eleven (click image for larger view)		Screen Twelve (click image for larger view)
	When Setup resumes, it will appear that you're performing a full, from-scratch setup. But don't worry--you're still indeed repairing your existing version of XP.

Many of the next few Repair screens will also be familiar. The "installing devices" screen, for example, is identical to the one you normally see during a full, from-scratch setup. But Repair is actually retaining much of the current setup's configuration and so will move through these steps faster than in a full setup.

(click image for larger view)

Screen Thirteen The Repair version of the setup process skips or shortens many steps because it already has the information it needs from the existing setup. For example, Repair's "installing devices" and the network setup steps are both much faster and require less user input than a new setup does.

The setup screens don't reflect the fact that a Repair proceeds much faster than a normal, full setup. In fact, the time estimates in the setup progress bar will be way off. You'll be done in far less time than the progress bar predicts.

Screen Fourteen Just as with "installing devices," the network setup proceeds rapidly because Setup can reuse many of the configuration details from the current installation. In fact, a Repair setup takes far less time than the installation progress bar indicates.

(click image for larger view)

When this portion of the Repair is done, you'll see a "completing installation" screen:

Screen Fifteen The "completing installation" screen means most of the heavy lifting is done, and you're just minutes away from finishing the repair operation. (click image for larger view)

Setup then reboots your PC again, and this reboot will also take longer than usual. This is normal.

Screen Sixteen With the bulk of the repair work done, your PC needs to reboot once more and will do so automatically. The reboot will take a bit longer than a standard boot, but this is normal. (click image for larger view)

After the reboot, you'll be brought to an abbreviated version of the "Welcome To Windows" setup pages.

Screen Seventeen The Repair process ends with still more screens borrowed from the full setup. (click image for larger view)

You'll be asked if you want to register and--depending on how badly hosed the previous installation was--you may or may not be asked to reactivate the copy of Windows. Next, the setup software handles the final networking details and then offers a "thank you" screen.

Screen Eighteen The final steps in the Repair process pass very quickly, and you'll soon reach the last screen in the Repair operation, a "thank you." (click image for larger view)

In most cases, the system will now reboot for a final time. The Repair is done. It's a normal boot, bringing you to the normal choices for login.

Screen Nineteen With a final, fully normal reboot, you're done. Your copy of XP should be as good as new, but with all your previously installed hardware, software, and user configuration data undamaged! (click image for larger view)

If all has gone as planned, you'll find all the user accounts and passwords intact, all the hardware devices set up as before, and all the previously installed software still installed and configured. In fact, if all has gone as planned, the only significant change will be that whatever problem your copy of XP was previously experiencing will now be gone!

You now have a range of repair tools at your disposal, ranging from simple on-the-fly fixes such as Registry cleaning and safe Mode fixes to Recovery Console fixes (see links in the beginning of this article) and, now, a nondestructive, no-reformat repair/rebuild option.

With this information, you should almost never have to face a dreaded start-over-from-scratch reformat/reinstall of XP!