Blog: IE

On Windows Server 2008, I was trying to get Java installed, but Internet Explorer kept saying that I was unable to download the file because of my security settings.  My options for changing the security zone settings were grayed out, and adding the Java website to my trusted sites did not work.  I investigated whether group policies were blocking my ability to edit the zone settings, but it turned out that there were no IE-related group policies.  It turned out that I had to run IE as an administrator (right-click and select “run as administrator”) to get access to the zone settings.


Most people know about the cookies that internet browsers use to store information.  It's easy to configure browser settings to not allow cookies, only allow trusted cookies, and to delete cookies when exiting the browser.  What slips around the radar are Local Stored Objects (LSO), also known as super-cookies or Flash cookies.

LSO’s use Flash technology to store more information than regular cookies.  In addition, LSO’s can be used to recreate, or respawn, deleted cookies.  More than half of the internet’s top websites use a little known capability of Adobe’s Flash plug-in to track users and store information about them, but only four of them mention the so-called Flash Cookies in their privacy policies according to UC Berkeley researchers.

To control these Flash cookies, you have to use the controls on Adobe’s site.  According to Wikipedia,  “Users can only opt-out of Local Shared Objects globally by using the Global Storage Settings panel of the online Settings Manager at Adobe's website. Users can also opt-out of them on a per-site basis by right-clicking the Flash player and selecting 'Settings'.  Adobe's online-only Website Storage Settings panel was created to let users view and delete LSOs on a per-domain basis. It is also possible to completely disallow LSOs from a specific domain by setting the storage space to "0 KB", however, although no data is stored, empty directories with the name of the domain are nonetheless created. Add-onextensions that allow the user to view and delete LSOs have also been created for the Firefox Web browser, e.g. BetterPrivacy.”


While debugging a problem that required uploading files to a website, one of the files started getting an error at the start of the upload instead of at the end.  This didn’t make sense because the problem being debugged was after the file was uploaded to the website.  This looked like another problem instead of the original problem we were hunting.   We suspected that the problem was connected to the file being uploaded instead of the website.  When we looked for the file on the Desktop it wasn’t there.  This was odd.  Went back to Internet Explorer and the file was displayed in Internet Explorer’s  file dialog.   But the file was not on the Desktop.  We tried closing Internet Explorer and restarting, but Internet Explorer still showed the phantom file. 

It turns out this is an artifact of Internet Explorer’s sandbox implementation on Vista or Windows 7.  Under certain conditions Internet Explorer writes to a virtualized Desktop folder located on the file system at: C:\Users\xxx\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\xxx\Desktop.  If you have need to move or remove the files in the “Virtualized” directory, the easiest solution is to open the file browser dialog in Internet Explorer and then move or delete the files from inside that dialog. [more]

More information is available in a article by Mark Russinovich:


Recently a customer had opened a phishing e-mail making rounds starting around the first of September.  This was an e-mail that is reported as an IRS version of Zeus Bot (some additional info:

After the virus definitions caught up with this, it was quarantined off and seemed to only affect the user profile on the terminal server where it was opened.  However, users started reporting also that Internet Explorer was crashing randomly. [more]

Looking through the event logs, I could see that IE was crashing from a faulting module named RASADHLP.dll.   This file is a remote access dialup helper and shouldn’t even be in use.  After comparing the files in Windows\system32 directory with another terminal server at the location, the files appeared identical.  However, the problematic server had another copy of RASADHLP.dll under C:\Program Files\Internet Explorer.

Further investigation of this file showed the creation date as the same day that the user received and opened the phishing e-mail.  Also it showed the user as the Owner of that file.  It is likely that IE was trying to use this file in it’s program directory first before the one in system32.

After renaming the file, IE was working without any problems.  The file was removed from the system.  Users running as non-admins likely helped to isolate the malware, but it still had written a bogus file to IE’s program directory.


A user was having problems opening Adobe PDF files from Internet Explorer getting an error that the file could not be found.  The file could be saved to desktop and then opened from there just fine.   From what I could tell, IE was trying to save the PDF file to a folder in "%Userprofile%\Local Settings\Temporary Internet Files\Content.IE5".

From my admin account, I could browse to the user's Content.IE5 folder, but the user's account was not able to see or browse to this folder at all.  This was causing problems being able to save anything to Temporary Internet Files for retreival.  I checked the permissions on this folder and they all appeared to have sufficient access.

In order to fix this, the Temporary Internet Files for the user needed to be recreated.  This was done by going to Tools, Internet Options, clicking "Settings" under Temporary Internet Files, and selecting "Move Folder".  It will list the current location, so simply select the same location and it will recreate the entire thing. 

After this was done, the user could browse to Content.IE5 folder and save/open PDF files in Internet Explorer.


When building a terminal server, don’t forget to uninstall IE Enhanced Security BEFORE you install terminal services on a Windows 2003 Server, especially if you plan to sysprep the server and image it. For some reason, if you don’t do this, certain keys are left behind in the registry and in the default profile user hive (ntuser.dat file) that cause issues. IEES is uninstalled, but new user profiles created on that server still have remnants and do not function as expected. Users may get the IEES pop-ups when visiting any site that is not in their trusted sites list and it seems to affect JavaScript execution privileges as well. Here is the Microsoft article that addresses this issue ( The workaround if this has happened is to follow Method 4 and then rebuild the affected profiles. If Method 3 is followed, it doesn’t seem be a complete fix from our experience.