Saving autocomplete history in Outlook 2010 (and later)

Anyone who has had to transfer a user’s MS Outlook data from one computer or another has probably heard this question before:

“Where are all my addresses?”

The user then shows you that whenever they try to compose an e-mail, addresses do not “auto-fill” — hence “Where are all my addresses?”

Explanation: Outlook stores autocomplete addresses separate from contacts. Most users don’t even realize this (and nobody ever explains it to them) so they assume that autocomplete is their addressbook.

Luckily, most of the time you could just locate the autocomplete cache file in their old profile and copy it to their new profile to restore their history. This process has become slightly more complicated in Outlook 2010, but it’s still a simple thing to recover, provided you still have access to the original user profile.

Important: Outlook cannot be running while you are doing any of this.

Copying autocomplete history from Outlook 2007 and earlier, to Outlook 2010 and later

Retrieve the old autocomplete history from the old user profile. It will be in the following directory:


It will be named outlookprofile.nk2, where outlookprofile is the name of the Outlook profile that the autocomplete history file corresponds to. If you have multiple versions, you could merge them with NK2Edit.

Copy that file into the same folder in the new user profile:


Hold the “super” key (it usually has the Windows logo printed on it) and hit the “R” key, to bring up the run dialog. Type the following command:

outlook.exe /importnk2

Click “OK” and you’re done. Verify that your autocomplete history shows up when you compose a new e-mail.

Copying autocomplete history from Outlook 2010 to Outlook 2010 and later

Retrieve the old autocomplete history from the old computer and/or old Windows user profile. If all you’ve done is created a new Outlook profile on the same machine, in the same Windows user profile, then both old and new files will be in the same directory. Either way, that directory is:


And the autocomplete history file will have a name similar to:


If you’re moving from a new computer and/or Windows user profile, then you already know which file contains the data you need. But, if you’ve created a new Outlook profile on the same machine, in the same Windows user profile, you could have multiple autocomplete files in the RoamCache directory.

In the event of multiple autocomplete files, you could use NK2Edit to merge all of them. Sometimes all you need is the largest or most recently modified file. But you’ll have to decide how you want to handle this. The safest route is to merge all of them, however that may not be desirable.

Now locate the new autocomplete file. It will be in the same directory in the new user profile as the old file was, in the old user profile. If you do not see it then it might not exist just yet so start Outlook, compose and send an e-mail, and it should appear.

If this file also contains data that you’d like to keep, you can use NK2Edit to merge the old autocomplete file(s) into the new one, overwriting it in the process — be sure to keep the filename of the new autocomplete file intact.

If it doesn’t have any data that you’d like to keep, simply rename the old autocomplete file to be identical to the new one, then copy the old (but now renamed) file into the new RoamCache directory — overwriting the new autocomplete file.

Here's an example of what this might look like

Here’s an example of what this might look like

Start Outlook and compose a new message. Start typing in the To field. If any cached addresses appear, then you’re good. If none appear, then close Outlook and repeat the previous step. Sometimes Outlook overwrites the autocomplete file upon first being opened after restoring the old data. In my experience, it will only do this on the first attempt, so just repeat the previous step to get your data back.

More information:

DDoS via DNS Amplification and Windows Server 2003

A quick show of hands; who else is still running Windows Server 2003 somewhere on their network? Ok, how many of you depend on those servers for DNS? It’s 2012 for fuck’s sake… what the hell is wrong with you people?

… I kid, I kid.

Unfortunately for the time being, I’m included in that group. I’ve got more than a few clients who still rely on the Windows Server 2003 DNS — which is the reason I’m writing this post.

This morning I had a client complaining about their Internet connectivity being quite unreliable. It was easy to determine that this was a DNS-related problem: pinging (Google’s public DNS) was successful while resolving was not. This particular network only has a single DNS so naturally that is where I looked next. Running netstat -a revealed a ton of outbound traffic — all DNS queries — directed towards their upstream DNSs and the root servers. Their DNS was making these queries, but why? I’d disabled recursion on that server literally years ago, but for some reason it was still responding to recursive queries — look at the “Flags” section of the log snippet below (this particular snippet was generated by windows’ DNS debug log). Notice where it says RD 1. This means the query was recursive:

20121105 08:40:29 F94 PACKET  02612A00 UDP Rcv     ebe4   Q [0001   D   NOERROR] ALL   (4)ripe(3)net(0)
UDP question info
  Socket = 512, recvd on port (65535)
  Remote addr, port 53
  Time Query=12890, Queued=0, Expire=0
  Buf length = 0x0500 (1280)
  Msg length = 0x0025 (37)
    XID       0xebe4
    Flags     0x0100
      QR        0 (QUESTION)
      OPCODE    0 (QUERY)
      AA        0
      TC        0
      RD        1
      RA        0
      Z         0
      RCODE     0 (NOERROR)
    QCOUNT    1
    ACOUNT    0
    NSCOUNT   0
    ARCOUNT   1
    Offset = 0x000c, RR count = 0
    Name      "(4)ripe(3)net(0)"
      QTYPE   ALL (255)
      QCLASS  1
    Offset = 0x001a, RR count = 0
    Name      "(0)"
      TYPE   OPT  (41)
      CLASS  4096
      TTL    0
      DLEN   0
      DATA   (none)

Next I had a look at the firewall’s logs. The firewall has logging configured on all policies that allow requests from the public Internet, so when I saw this:

(For security purposes, we’ll pretend that the public IP address of the DNS targeted by the attack is

Traffic Log for Policy:

(Src = "Untrust/Any", Dst = "Global/MIP(", Service = "DNS")

Current system time is Mon, 5 Nov 2012 08:43:21

Time Stamp Action Source Destination Translated Source Translated Dest Duration Bytes Sent Bytes Received Application

2012-11-05 08:43:11 Permit 17 sec 13446 72 DNS 
2012-11-05 08:42:55 Permit 17 sec 13446 72 DNS 
2012-11-05 08:42:39 Permit 17 sec 13446 72 DNS 
2012-11-05 08:42:23 Permit 17 sec 13695 72 DNS 
2012-11-05 08:42:07 Permit 17 sec 13197 72 DNS 
2012-11-05 08:41:51 Permit 17 sec 13529 72 DNS 
2012-11-05 08:41:35 Permit 17 sec 13446 72 DNS 
2012-11-05 08:41:19 Permit 17 sec 13363 72 DNS 
2012-11-05 08:41:11 Permit 1 sec 75 208 DNS 
2012-11-05 08:41:09 Permit 2 sec 90 120 DNS 
2012-11-05 08:41:05 Permit 2 sec 86 219 DNS 
2012-11-05 08:41:03 Permit 17 sec 13446 72 DNS 
2012-11-05 08:40:47 Permit 17 sec 13446 72 DNS 
2012-11-05 08:40:31 Permit 17 sec 13446 72 DNS 
2012-11-05 08:40:15 Permit 17 sec 13446 72 DNS 
2012-11-05 08:39:59 Permit 17 sec 13446 72 DNS 
2012-11-05 08:39:55 Permit 3 sec 75 91 DNS 
2012-11-05 08:39:43 Permit 17 sec 13446 72 DNS 
2012-11-05 08:39:27 Permit 17 sec 13446 72 DNS 
2012-11-05 08:39:11 Permit 17 sec 13363 72 DNS 
2012-11-05 08:38:55 Permit 17 sec 13612 72 DNS 
2012-11-05 08:38:39 Permit 7 sec 9462 1112 DNS 
2012-11-05 08:38:33 Permit 17 sec 25730 72 DNS 
2012-11-05 08:38:33 Permit 1 sec 83 1251 DNS 
2012-11-05 08:38:27 Permit 4 sec 90 106 DNS 
2012-11-05 08:38:19 Permit 3 sec 90 130 DNS 
2012-11-05 08:38:17 Permit 17 sec 24817 72 DNS 
2012-11-05 08:38:01 Permit 1 sec 166 1271 DNS 
2012-11-05 08:37:19 Permit 4 sec 79 95 DNS 
2012-11-05 08:37:17 Permit 2 sec 79 95 DNS 
2012-11-05 08:37:15 Permit 1 sec 79 95 DNS 
2012-11-05 08:35:21 Permit 3 sec 84 100 DNS

…It was pretty obvious what was going on. There were a few other suspicious IP addresses in the logs other than including, but not limited to:

  1. Loads of traffic originating (i.e., “distributed”) from multiple source IPs? Check.
  2. Internet connectivity (i.e., “service”) pretty much dead (i.e., “denied”)? Check.

This has all the makings of a Distributed Denial of Service attack (DDoS). This particular type of DDoS is known as a DNS Amplification Attack, technically it’s a distributed reflected denial of service attack (DRDoS). It can occur when you are running an open DNS and somebody with malicious intent notices.

After blocking inbound requests from all of the suspicious IPs and verifying that service had been restored, I shifted my focus back to the DNS. There are two places in the DNS Management Console where you can disable recursive queries:

…But as far as I can tell, the DNS built into Windows Server 2003 will allow you to change these settings and then it disregards your configuration and does whatever it damn well pleases. You’d think that between the two of these configuration options, the server wouldn’t respond to any recursive queries. Sadly this is not the case as you can see in the test results from DNSStuff:

DNSStuff also provides a link in the test output that describes which steps you should take in order to close an open DNS. Unfortunately…

NOTE: These instructions show you how to completely disable recursion. This is the best practice. However, if you need to run a DNS server that is both authoritative and recursive/caching, you will need to check the DNS server documentation to find out how to enable recursive lookups only for your local network. It seems that there is no way to do this with Microsoft DNS; if so, you will need to use other DNS server software or use a hosted DNS service. If anyone is aware of a way to get Microsoft DNS to allow recursion only to specific IP ranges, please let us know -- lots of people would like to do that.

This is the default behavior of the Windows Server 2003 (and 2008, 2012 from what I’ve read) DNS. In other words, it is insecure out of the box — this is analogous to allowing unauthenticated, unrestricted relaying on a mail server by default. Thanks Microsoft!

Anyway… since the company-in-question has it’s website hosted on the local network and their only DNS also serves as the authoritative DNS for their domain name, my next course of action will be to configure a separate non-windows DNS and use that to host their zones. Let this serve as a cautionary tale to any of you out there who might be using a Windows server as an authoritative NS for domains and a resolver for queries originating on the local network.

Opening Terminal Server registry propogation window. (aka: Installing software in windows takes forever)

That’s not a typo. For the past few months, I’ve noticed that installing software or running updates on one particular terminal server that I manage (Windows Server 2003, std.), the updates/installation take hours — in some cases, days. So I enabled windows installer logging and here’s what I found:

MSI (s) (2C:30) [01:58:16:558]: Opening Terminal Server registry propogation window.
MSI (s) (2C:E8) [02:35:44:188]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [03:13:14:358]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [03:50:44:453]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [04:28:14:529]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [05:05:44:619]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [05:43:14:897]: RunEngine wait timed out
Installer is no longer responding.
Action ended 5:52:07: InstallInitialize. Return value 1.
MSI (s) (2C:30) [05:52:07:859]: Doing action: SxsInstallCA
Action start 5:52:07: SxsInstallCA.

So as you can see by the snippet above, this routine installation took an enormous amount of time. This exact scenario played out anytime I tried running updates or installing software. As it turns out, this was the problem. Simply removing the driver and deleting the following registry keys, and then installing the latest version of the driver (… I was on ~3 something; at the time of this writing, the latest version is 6.1) fixed the problem. Here are the registry keys that should be removed after the driver has been uninstalled (and before the latest version has been installed):


This was an extremely frustrating issue — other symptoms included server crashes with an error message about the registry being too large; logging in a brand new user for the first time takes ~15 minutes or so, and a whole host of other performance related weirdness. At first I thought that installing UPHClean would help solve this (the symptoms being registry-related and all) but it may have actually made the problem worse. If you scroll all the way down to the bottom of the page of the previous link to HP’s website, you’ll see the following post:

JulianBlue Oct 6, 2010 07:37:53 GMT
It is very likely that HP UPD problem replicating tons of registry keys to global default registry hive (.DEFAULT) being related to Terminal Server on which the Microsoft UPHClean Tool is installed. I would recommend to look at the readme.txt with UPHClean and setup an exclusion for svchost.exe/rpcss.dll.

“UPHClean assists the operating system to unload user profile hive by remapping the handles to the user profile hive to the default user hive. For example if a process has a handle to HKEY_USERS\S-1-5-21-X-Y-Z\Software\Microsoft after remapping it would have a handle to HKEY_USERS\.DEFAULT\Software\Microsoft.”

I haven’t had the chance to test this yet, but it does sound plausible enough. There’s also some other posts related to this on HP’s website that are worth having a look at. Here’s the readme.txt that comes with UPHClean. Setting up an exclusion list is fairly straightforward; for convenience, I’ve pasted the pertinent section of the UPHClean readme here:


Because UPHClean assists in unloading the users registry
hive some services may behave incorrectly. Administrators
are encouraged to test and watch for unexpected behavior.
If unwanted behavior is identified contact the developers of
software that UPHClean identified as preventing profile from

UPHClean assists the operating system to unload user profile
hive by remapping the handles to the user profile hive to the
default user hive. For example if a process has a handle to
HKEY_USERS\S-1-5-21-X-Y-Z\Software\Microsoft after remapping
it would have a handle to HKEY_USERS\.DEFAULT\Software\Microsoft.
This allows the profile hive to unload. This may not work if the
application expects data that would only be available under the
specific user profile hive it was accessing since the data will not be copied.

If you find that removing UPHClean stops a particular problem from
occurring then you may be interested in restricting UPHClean from
processing certain handles. UPHClean ignores handles that are
held opened to profile hives for the users specified on the user
exclusion list or by processes specified on the process exclusion list.
These lists are specified using the following registry values:



Note that since these values are specified as REG_MULTI_SZ strings
you should use regedt32 on Windows NT and Windows 2000 to edit them.

The process exclusion list is a list of process names that UPHClean
should ignore when determining which handles to user profile hives
to act on. Each process name is specified on its own line when
input in registry editor. The process name should be specified the
same way as it shows in Task Manager. Usually this is the file
name of the program (e.g. notepad.exe).

A few process show multiple times in Task Manager. It is possible to
specify that a certain DLL be loaded in the process to allow a selection
of a specific process. This is useful with the svchost process to identify
a specific instance. For example to specify the svchost process that
the Remote Procedure Call (RPC) service is running in on Windows 2000,
Windows XP and Windows Server 2003 you would specify
svchost.exe/rpcss.dll in the process exclusion list

The user exclusion list is a list of user security identifier (SID) or user that
UPHClean should ignore when determining which handle to user profile
hives to act on. Each user SID or name is specified on its own line when
input in registry editor. If specifying a user name you must enter the user
domain name followed by a backslash followed by the user name. For
example RCARONDOM\RCARON to specify the user RCARON from
domain RCARONDOM. SIDs should be specified in the usual string
format (e.g. S-1-5-21-2127521184-1604012920-1887927527-68486).
This is the same string you see under HKEY_USERS in registry editor.

Note that the user exclusion list always includes the following
SIDs: S-1-5-18, S-1-5-19, S-1-5-20. Unloading these profiles can cause
problems so UPHClean will not attempt to process handles to these profiles.

Which processes UPHClean performs handle remapping can specified
using the following registry value:


The list by default contains ‘*’ which specifies that handle remapping should
be performed for all non-excluded processes. This list can be changed to
only include specified processes in the same manner as the process
exclusion list. Processes specified on this list can be preceeded by a ‘-‘
character to specify that they should be excluded from handle remapping.
Any handle for a process that is not excluded but has handle remapping
turned off will be closed.

I hope this helps!

Configuring “Per User” licensing in Terminal Services, remotely *without* Remote Desktop access

So the other day I was trying to connect to one of the terminal servers that I manage (for the purpose of this post, we’ll call the server ‘TERMSVR01’) and I got the following error message and was promptly disconnected:

The remote session was disconnected because there are no Terminal Server client access licenses available for this computer

At first glance, this seems as though the server ran out of TS CALS (Terminal Server Client Access Licenses). I was pretty sure that the server was configured to use the “Per User” licensing mode. However, a Windows Server 2003 Terminal Server operating in the “Per User” licensing mode can’t run out of licenses to the extent that it prevents the user from connecting (and instead, giving them the aforementioned error message). To the best of my knowledge, it can only do this when it is operating in “Per Device” mode. So this was the assumption that I ran with — that somehow, this server was never configured for “Per User” -or- it was, but the setting was either changed, reset, or corrupted somehow.

So, even though I wasn’t able to connect to TERMSVR01 via Remote Desktop, I was able to “Manage” it remotely by doing the following:

  1. Open “Active Directory Users and Computers” on any Domain Controller
  2. Expand the “Computers” node
  3. Right-click TERMSVR01 and select ‘Manage’

Now we can do a few things (not many) on the server. One thing I wanted was to have a look at the Event Viewer. There were a few error messages like the following:

Event Type: Information
Event Source: TermService
Event Category: None
Event ID: 1004
Date: 1/5/2010
Time: 6:18:23 PM
User: N/A
Computer: TERMSVR01
The terminal server cannot issue a client license. It was unable to issue the license due to a changed (mismatched) client license, insufficient memory, or an internal error. Further details for this problem may have been reported at the client’s computer.

For more information, see Help and Support Center at

The more of these I saw, the more confident I was that my assumption was correct — the server was operating in “Per Device” mode and it had finally run out of licenses. I had the following options:

  1. Wait for someone to go onsite and reconfigure the licensing mode (easy, but it would have to wait until tomorrow) or…
  2. Attempt to reconfigure this setting and restart the service remotely (so that the setting takes takes effect) … all without having “Remote Desktop” access to the server.

Care to guess which option I chose? :-)

Step #1: Override the licensing mode setting using group policy

  1. Click ‘Start’
  2. Click ‘Run’
  3. Type the following command:
    gpedit.msc /gpcomputer:TERMSVR01
  4. Click ‘OK’

Those four steps open the group policy (remotely) for TERMSVR01. Next we need to actually change the setting:

  1. In the left-hand panel, expand “Administrative Templates”
  2. Expand “Windows Components”
  3. Click on “Terminal Services”
  4. Locate the following setting in the right-hand panel:
    Set the Terminal Server licensing mode
  5. Double-click the aforementioned setting
  6. Change the option (directly below the heading) to “Enabled”
  7. Select “Per User” from the drop-down box (below the heading: “Specify the licensing mode for the terminal server”.)
  8. Click ‘OK’
  9. Close the “Group Policy Object Editor” window

Great. The licensing mode has been changed but the setting won’t take effect until the service is restarted. We could open ‘services.msc’ and connect to ‘TERMSVR01’ by using the ‘Connect to another computer …’ option in the ‘Action’ menu. This will allow us to administer almost all running services on TERMSVR01 … almost all. You’ll notice immediately that you cannot start/stop the ‘Terminal Services’ service from this management console, so we need to find another way to do it.

The easiest way I know to accomplish this task is to use the WMIC command from the command prompt.

Step #2: Restart a remote service using WMIC

  1. Open a command prompt
  2. Type the following command (then hit enter) to stop the service:
    wmic /node:TERMSVR01 service where “caption=’Terminal Services'” call StopService
  3. Then, type the following command to start the service:
    wmic /node:TERMSVR01 service where “caption=’Terminal Services'” call StartService
  4. Close the command prompt

If everything was successful (and my assumption about the nature of the problem was correct), then I should be able to connect to the server using the Remote Desktop client. I fired up the client and voilà! It worked perfectly.

Adding “Trusted Sites” to Internet Explorer, via the registry

Update! 5 February 2014 This can also be accomplished via GPO.

  • Open the group policy editor.
  • Create a new policy (or edit an existing policy.)
  • Navigate to:
    Computer Configuration/Administrative Templates/Windows Components/Internet Explorer/Internet Control Panel/Security Page/
  • The setting to add sites to the “Trusted Sites” zone is called “Site to Zone Assignment List”. Read the explanation in the “Help” box before configuring anything!
  • Then, to set configuration options for the “Trusted Sites” zone, you’ll want to navigate to the subdirectory/subkey titled “Trusted Sites Zone”. There you will find every setting that governs the behavior for that zone.

Original Article Follows

A while ago I needed to add a list of websites to the Internet Explorer’s “Trusted Sites” zone for multiple users, scattered across multiple terminal servers. IE’s “Enhanced Security Configuration” (ESC) is configured by default on windows terminal services and it’s normally a good idea to leave it intact.

However, this can have unintended consequences for users who require the use of websites that employ ActiveX, javascript, etc. because, by default, ESC does not allow those items to run. Sometimes, this means that the site in question will only be partially non-functioning. Other times, the entire site will be completely unusable. Furthermore, most users on terminal services have only a limited ability to actually modify the settings for an entire zone. Normally the best thing they can do is add the site to their trusted sites zone, if in fact the site is legitimate (i.e., “trusted”).

Originally, I explained to the users the steps involved in adding a site to their trusted sites, however many of the users used many of the same websites that other users were using. Also, new users needed to be trained on how to do this as well. Needless to say, it got very repetitive, very fast; so I came up with a “global” list of sites that can be trusted, and imported them to the registry on each terminal server. The list consisted of about 40+ sites, and I was able to generate the list mostly by exporting the following registry key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains

…from a few user accounts who had already added most of the sites to their trusted sites zone. After grepping out the duplicates (among other things), I had my list.

Now, I’m going to cover two ways of making this list of domains “globally trusted”—both of them involve writing to the following registry key:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains

Pay attention! This is not the same key as previously mentioned. This key resides in the ‘HKEY_LOCAL_MACHINE’ hive, whereas the previous key resides in the ‘HKEY_CURRENT_USER’ hive.

The first way is via the following visual basic script:

Option Explicit
Dim DomainArray(5), strComputer, strHTTP, strHTTPS
Dim dwordZone, regPath, objReg, counter, subkeyPath
Dim subkeyValue
Const HKEY_LOCAL_MACHINE = &H80000002
DomainArray(0) = ""
DomainArray(1) = ""
DomainArray(2) = ""
DomainArray(3) = ""
DomainArray(4) = ""
strComputer = "."
strHTTP = "http"
strHTTPS = "https"
dwordZone = "2"
regPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" &_
Set objReg = GetObject("winmgmts:{impersonationLevel = impersonate}!\\" & _
        strComputer & "\root\default:StdRegProv")
For counter = 0 to 4
        subkeyPath = regPath & DomainArray(counter)
        objReg.CreateKey HKEY_LOCAL_MACHINE,subkeyPath
        objReg.SetDWORDValue HKEY_LOCAL_MACHINE,subkeyPath,strHTTP,dwordZone
        objReg.SetDWORDValue HKEY_LOCAL_MACHINE,subkeyPath,strHTTPS,dwordZone

This script will insert ‘’, ‘’, […] into IE’s trusted sites zone when run on any machine. It must be run by an Administrator (or another user who has access to write to the HKEY_LOCAL_MACHINE registry hive), and the changes are global (to the machine).

The next way involves creating a “registry entries” (.reg) file:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\]

Just like the previous script, this must also be run by a user with Administrator privileges and any changes will be global to all users on the machine.

(Of course, you would want to customize these snippets of code to suit your needs.)

For more information, please visit the following sites:

Internet Explorer Enhanced Security Configuration changes the browsing experience
Enhanced Security Configuration for Internet Explorer
Internet Explorer security zones registry entries for advanced users