Blog: IE

One of our Tandem Software users was having difficulty downloading a risk assessment document.  The download would start, run for a while, and then error out.  The user was able to download other documents in our software and we were aware of no other users experiencing this same problem.  The problematic document does take a little longer than other documents to download, but not much and the user has been able to download this document in the past.  After some troubleshooting on the user’s computer we could see the download GET request being initiated, but it was aborting before any results were returned. 

Internet explorer doesn’t expose a timeout setting through the Internet Options.  However, there is a registry key that can be set to control the timeout.  I checked my system and this registry key was not set.  When I checked the user’s registry, the key did exist and it was set to a relatively low value.  The user did not recall setting the value and since the only way I’m aware of changing it is through the registry we’re not sure how it was changed.  Increasing the value in the registry key fixed the problem.

Here are the steps to add/change the timeout registry key: [more]

1. Start Registry Editor
2. Locate the following subkey: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
3. If a DWORD entry does not exist named “ReceiveTimeout” then create one.
4. Set the “ReceiveTimeout” value to a number of milliseconds.
5. Restart the computer

You can’t always go off of only the browser version when troubleshooting problems in newer versions of Internet Explorer.  We all know that unfortunately, different browser versions interpret the code for websites differently in some way or another.  When troubleshooting end user problems the first thing I always try to find out is the name of the web browser and the version number being used by the user.  That used to be all you needed to know for Internet Explorer until Microsoft added the option to view web sites in “Compatibility View” to recent versions of IE.

Compatibility View is a cool feature that allows users to view content designed for older web browsers in their newer version of Internet Explorer.  What it basically does is render the web pages as if you were using an older browser.  This works great if you’re having trouble viewing a site in a new browser that worked before you upgraded.  However, “Compatibility View” can turn into “Incompatibility View” if a website was only designed for newer browsers and you turn that feature on. [more]

I’ve seen users accidently and unknowingly turn on the Compatibility View.  After doing that they start having problems with a website that supports their browser version and used to work fine for them.  It’s easy to do since the button is right next to the page refresh button in the address bar.  I’ve also ran into users that have had to use the Compatibility View with other websites in the past so when they run into a problem on a different website they try turning it on and then forget to turn it off when it doesn’t fix their problem.  IE remembers which sites you turned that view on for, so it automatically turns it on the next time you visit the site.

In my opinion the easiest way to view which version your browser is behaving as is to press F12 to open the developer tools window and look for the “Browser Mode” and “Document Mode” settings.  You can click those options to change them.

As part of a Citrix environment overhaul, another network engineer and I discovered a very frustrating limitation of using group policy with Citrix published applications. The problem centers around the inability to apply IE group policy settings using loopback mode processing. I'll warn you ahead of time, there are lots of details so hang with me....and remember this is all going to converge at the application of group policy. Here is what we found...

When a user with an empty roaming profile (new user) has their profile created as the result of running a published application, the user portion of the registry hive (ntuser.dat) is not created in its entirety. The users' hive can be loaded and a number of noticeable differences exist between it and the default user registry hive. If the user profile is created by logging on locally (console), via RDP to the same machine, or via Citrix published desktop on the same machine, the profile that is created is complete. I was unable to find any noticeable differences between the default user registry hive and that of the newly created roaming user profile when the profile was created in this way. Additionally, once an incomplete profile had been created via published application session, the profile could NOT be "fixed" by logging on via RDP or published desktop. Once the registry hive was created in an incomplete fashion, it seemed to be affected from then on. So why are we talking profiles...I thought this was about group policy? Well, it is...I'm getting there. [more]

We found that users running published applications did not have group policy correctly applied. We were trying to set policies on Internet Explorer using Internet Control Panel settings in the user portion of the GPO. Specifically, IE security zone settings such as trusted and intranet sites would not apply. We also noticed that each security zone seemed to be locked. In the Security tab of the Internet Options dialog box, all the icons were the same....blue IE symbol with a lock next to it. The "Sites" button and the "Custom Level" button were also grayed out. So, here is the where the profile problem merges with the group policy problem. I found that by manually exporting certain keys from the default user profile registry hive under \Software\Microsoft\Windows\CurrentVersion\Internet Settings\ and importing them into in a incomplete user registry hive, I could fix the problem. That is, once the keys existed in the user registry hive that pertained to the settings I was trying to set via group policy, the policy was applied correctly...no issues. Makes sense right....if the group policy is setting registry keys in order to apply certain policies, it’s not going to work if the keys don't exist in the first place.

So things have come full circle. Group policy isn't working because the user profile is messed up. So why is the user profile not getting created correctly? Well, this is actually a Microsoft problem --> http://support.microsoft.com/kb/899270. And the script they provide doesn’t work…we tried it. Actually, there is more to the problem than that, but here is a summary of the information that we gathered. By design, Citrix published applications, remote applications in Windows 2008, and the "start this application on connection" functionality of RDP (mstsc.exe) running against Windows 2003 servers implement limited logon functionality so that the session footprint is smaller than a normal desktop session. Part of the "limited functionality" is that the user session does not start explorer.exe. So, any application that depends wholly or in part on explorer.exe could have issues. Some of the important pieces of functionality that explorer.exe implements are the following:

1. The run registry entry
2. The RunOne registry entry
3. Startup applications 

If you have ever noticed the small gray box that is displayed the first time you log on as a new user, you have seen the effects of explorer.exe running at session logon. It goes by fast, but it says something like "applying internet explorer customizations", "setting up windows media player..."...stuff like that. That little box is normally initiated by explorer.exe. It is called runonce.exe. What we found was that if we initiated runonce.exe in a logon script, the user was created correctly when running published application; thus, group policy was applied correctly as well. Testing also showed that this process could also fix a previously created broken user registry hive (ntuser.dat). All we had to do is add the following to our logon.bat file

start /MIN %windir%\system32\runonce.exe /AlternateShellStartup

Citrix has documented this problem in a support article (http://support.citrix.com/article/CTX104374) and they refer back to the previous MS KB listed above. Numerous forums threads exist on this issue and we were unable to find a resolution elsewhere that did not include scripting registry imports to the user profile at logon. This workaround seems to be a more flexible and reliable.

This approach is certainly not for everyone, but here is what I have done to mitigate the problem with so many certificate authorities out there.  The Comodo breach of March 2011, for example, allowed some bad guys to use a registration authority to generate valid certificates for Google, Yahoo, Skype, etc.  There are companies that sell boxes with software that will generate a valid certificates on the fly for every secure web site you visit in order to be able to observe your traffic.  With so many CAs, the risk of misuse has increased.  These comments mainly apply to Windows.

I think it was during May 2010, I edited the trust level on the root CA certificates in Firefox to only trust about 10 of them.  I think I have had to trust maybe two more since then.  I started with the list at http://netsekure.org/2010/05/results-after-30-days-of-almost-no-trusted-cas.  There are several links on this page that explain a lot about how Windows handles certificates.  This is one of the major reasons I use Firefox instead of IE.

To change the trust level of certificates in Firefox, go to Options, select the Encryption tab, and then the View Certificates button.  This brings up the Certificate Manger window.  The Authorities tab in the Certificate Manage window is where all the CAs are listed. Select each certificate and then select the Edit Trust button at the bottom.  This is where you can disable trusting each CA’s certificate. [more]

I also run the Firefox Addon Certificate Patrol which saves every certificate and warns me if a certificate has changed.  The primary blogger with the Tor Project, phobos (I don’t know the real name), suggests being your own certificate authority in a manual sort of way and not trusting any external certificate authorities (https://blog.torproject.org/blog/life-without-ca). I decided not to go that far.

If you prefer another browser such as Google Chrome or Internet Explorer, the procedure will be different.   Chrome and IE use the Windows certificate store, so you will have to delete the certificates that you do not want to trust.  Opera has it’s own store, but operates like Windows, downloading additional root certificates behind your back.  You may be able to preload these and remove the trust, but I have not taken the time to look into this.  I know nothing about how Safari handles certificates.

As I mentioned at the begining of the article, this approach is not for everyone.  However, for technical users with a little patience you can greatly reduce the likelihood you'll fall susceptible to a spoofed SSL certificate.

After the December 2010 Internet Explorer 8 updates I was seeing some strange behavior for a couple sites including gotomeeting.com.  Users could get to the first page, but if they clicked on any of the links they would get a page cannot be displayed error.  It appeared like the user could browse to the first page via the proxy, but all subsequent pages were being sent direct. 

It turns out the IE8 updates changed the behavior of the WPAD script that we were using and we had to edit the following line:
proxy = "PROXY proxy.company.com:8080; DIRECT";

We had to change it to look like:
proxy = "PROXY proxy.company.com:8080";

After making this change the sites in question began to work.

I had looked at a problem with IE where the user worked frequently with data input into form fields.  The problem that they had was that it would not start giving the auto complete suggestions as they started typing. 

I checked Internet Options -> Content -> AutoComplete Settings and verified that the "Forms" option was checked.  Since it appeared that everything was enabled to do what the user wanted, I selected the "Delete AutoComplete history" option.  After clearing the history, the auto complete started working again. 

I am unsure whether or not the files containing the information for this feature were corrupt or possibly too large to continue working.

The Level Platforms Service Center website is probably not very standards-compliant.  We've know for some time that Firefox and Chrome browsers don’t render it properly, but I’ve recently seen more critical problems, such as the Site Management page showing a blank site-list in Chrome.  Some of the monitoring procedures require these pages, so using IE (or Firefox add-on like IE Tab) may be the only way to see everything properly.

The Internet Explorer 9 Beta is out and already I can see several new features and improvements over previous versions. While it still isn’t enough to get me to switch from Chrome, they are making serious improvements in the UI and how it handles certain websites. One new feature, however, I find quite interesting. They’re called jump lists and basically, it’s a bookmark on steroids.

Windows 7 has allowed you to pin applications to the taskbar for easy access. IE also provided the ability to switch tabs via the pinned application on the taskbar. Now, they have taken it to the next level. You can pin a specific site to the taskbar and open to it as if you were starting a new application. Currently, this is an IE only feature, but Microsoft hopes to turn it into a standard for other browsers to follow suit. [more]

Let’s say, you browse to http://arstechnica.com and you want to pin their site to your taskbar. Click/drag the tab to your taskbar and it will automatically pin. Notice that the icon has changed.

Then when you click on it, it opens up a “special” version of IE with its own special colors and icons.

This information is grabbed from the favicon.

Finally, the jump list. Right-click on the pinned application:

Notice that there are new “tasks”. When you click on one of these, it opens that specific page. The code to add this information is really simple.

<!-- C-razy IE9 stuff --><meta name="application-name" content="Ars Technica"/>
<meta name="msapplication-starturl" content="http://arstechnica.com/"/>
<meta name="msapplication-tooltip" content="Ars Technica: Serving the technologist for 1.2 decades"/>
<meta name="msapplication-task" content="name=News;action-uri=http://arstechnica.com/;icon-uri=http://arstechnica.com/favicon.ico"/>
<meta name="msapplication-task" content="name=Features;action-uri=http://arstechnica.com/features/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-features.ico"/>
<meta name="msapplication-task" content="name=OpenForum;action-uri=http://arstechnica.com/civis/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-forum.ico"/>
<meta name="msapplication-task" content="name=One Microsoft Way;action-uri=http://arstechnica.com/microsoft/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-omw.ico"/>
<meta name="msapplication-task" content="name=Subscribe;action-uri=http://arstechnica.com/subscriptions/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-subscribe.ico"/>

I’ve added this to one of my sites within minutes and all works as intended. Now because the jump list is actually pinned to the taskbar, the Windows team had to modify the structure of their code to allow IE to do this. This is why it still requires a reboot to install IE9. They’re modifying the kernel to allow for jump lists. Pretty neat stuff.

When changing some settings in Internet Explorer recently, I stumbled across the “Use SSL 3.0” and “Use TLS 1.2” settings under the Advanced tab of Internet Options.  For a long time, I have been running without SSL 2.0, TLS 1.0, and TLS 1.1 enabled, but I wondered if SSL 3.0 is even necessary anymore (TLS superseded SSL 3.0 in 1999).  So I unchecked the “Use SSL 3.0” check box.  I did the same in my Firefox settings.  I ran that way for at least a couple of weeks without any noticeable issues.  Then last week I was onsite at a bank and tried to use the Cisco AnyConnect SSL VPN.  It did not connect, so I tried it that night from the hotel.  It still did not connect.  The Cisco IPSEC VPN client worked perfectly.  After a couple of days of the AnyConnect client not working, I was about to send an email to one of our network engineers asking if anything had changed when I remembered the “Use SSL 3.0” setting.  After re-enabling SSL 3.0 in both IE and Firefox, the AnyConnect client worked.  Aside from the SSL 3.0 setting breaking AnyConnect, the more general GOTCHA is that the AnyConnect client uses at least some of the web browser settings when establishing its connection, so I now know to include them when troubleshooting the VPN.