Windows Explored

One of our techs reported that when trying to go to the home page of a specific website in IE 7-8, they were instead being routed to a slightly different URL. She did some minor troubleshooting by trying the same site from another workstation with no problems. We also tried the same URL and were not able to recreate the problem. We took a few different approaches and after an hour we gave up.

Still curious, I connected after hours to the workstation exhibiting the problem. I started by logging on as a local admin account, which would ensure that domain account policies would not interfere and could be eliminated as a cause, and I was able to reproduce the problem. This was telling because it meant that we were likely dealing with an issue that was workstation specific, not user, otherwise when the tech logged into the other workstation when she tested earlier, her roaming profile would have included the user specific settings, i.e. the suspect setting was not residing in HKCU but instead likely present in HKLM. Earlier tests also further isolated the issue specifically to IE since other browsers were not being redirected.

The breakthrough came when I decided to stop ignoring the site content. The site in question was wageworks.com. Here is the site you should be directed to when you type this into your browser:

This is the site that the tech was being routed to instead, wageworks.com/choose.htm, with no ability to navigate to the actual non-mobile home page:

It looks like one uses this URL to logon from a mobile device. With that, my first suspicion was that a mobile device app was running on the workstation. A quick look at the running processes revealed an Apple mobile device service was present. I shut it down along with an associated user mode process that it also installs but was still be redirected to the mobile login portal. My next conclusion was that something about the browser is telling this site that it’s a mobile browser. I turned to quick search on the Internet and searched “browser detected as mobile”, saw various references to the User Agent key in the Windows registry, which pointed me to this MSDN article: Understanding User-Agent Strings.

In short, the purpose of the strings in the User Agent key:

When you visit a webpage, your browser sends the user-agent string to the server hosting the site that you are visiting. This string indicates which browser you are using, its version number, and details about your system, such as operating system and version. The web server can use this information to provide content that is tailored for your specific browser.

To view the current state of the User Agent strings, type javascript:alert(navigator.userAgent) into the address bar in IE:

Alternatively, you can navigate to HKLM\Software\Microsoft\Windows\Current Version\Internet Settings\5.0\User Agent.

This key also exists in HKCU. Normally, you will find the presence of another key named Post Platform or Pre Platform that may also contain these strings (REG_SZ types).

To troubleshoot which string the browser was sending to the website that was causing it to believe IE 7-8¹ might be a mobile browser, I started by deleting the less common strings. Since the .NET keys are normal, I removed the non-native Windows components, like AmiciLLCVersion2.5, OfficeLiveConnector.1.4, OfficeLivePatch.1.3, and InfoPath.1. Eventually, I isolated the redirect to the OfficeLiveConnector.1.4 string, which is a set of services for the Windows Live products. Here’s the kicker: user agent strings sent to the website you are visiting don’t necessarily read the string in the context of the complete string². Instead, a part of the string is enough to tell the website to adjust to the browser type. Knowing that, I further isolated just “nec” as the part of the OfficeLiveConnector1.4 string that was telling WageWorks that this browser might be mobile. Resolving then was just a matter of deleting the string (maybe with some loss of functionality for web pages that rely on recognizing this Windows Live component?).

The other part of the mystery is why “nec” is enough to tell WageWorks that IE 7 or 8 browser is mobile. Likely, there is something server side that is looking at the User Agent strings but I didn’t see anything telling in the web page scripts or html content, but web page internals is not my area of knowledge. An example of this query would be something like this (php):

<? if ( stristr($ua, "blackberry")
or stristr($ua, "iPhone") or
stristr($ua,"pda") or
stristr($ua, "Mobile"))
{ $DEVICE_TYPE="MOBILE"; }…
blah blah blah

The next step is to inform the website admin of this issue, since the presence of the Office Live Connector can be quite common and cause issues with other visitors to the site.

To see how this works with more common sites, you can add the string “iphone” or “blackberry”, visit www.bing.com and you should be redirected to the the mobile site, http://m.bing.com/?mid=10006.

¹ IE 9 is not affected in the same way since “the user-agent string no longer includes feature tokens during HTTP negotiation.” However, if you use compatibility mode in IE 9, then the user agent string assumes IE 7 and you can faithfully recreate the problem with IE 9.

² There seems to be\was a common issue where a string named Creative AutoUpdate is known to cause this with some web sites that also host mobile versions of their pages. This is because this string includes “pda”, obviously a string that might be used to identify your browser as mobile.

UPDATE

There are a couple other UAs in the registry I failed to mention:
HKLM\Software\Microsoft\Windows\Current Version\Internet Settings\User Agent
HKCU\Software\Microsoft\Windows\Current Version\Internet Settings\User Agent

Specifically, there was a string in HKCU that is user specific and randomly generated. This actually also ended be the cause for another user also having the same issue as her unique string just happened to contain nec:

I don’t know what the purpose of this string is.

UPDATE 2

In the above screenshot, I assumed that deleting the string was enough to resolve the issue of our other user being redirected to the mobile site. Although this was true, it was only temporary; the same string was recreated after logging on the next day, resulting in the same problem. After speaking with a colleague, he mentioned our cloud-based web filtering provider adds a unique string to the UA of each user via a process (pim.exe) that runs at logon. This string, or hash as it is referred to, is unique for the user and then remains with them. The process is outlined here:

• PIM adds -XS headers to the browser’s user agent string
• Included in this string is a unique hash that identifies the user in our Scanning tower
  This detail is encrypted
• Upon logon, PIM sends an out-of-bound request to the scanning tower and uploads the group information for that user
• These groups are automatically created in ScanCenter
• Following registration, each time a request to the Web is made, only the hash is sent to us along with the request and we can identify the user and apply the correct policy according to the relevant group(s)

In short, to resolve a case where the UA hash is the problem, we need to run the pim process as the user but with a switch that tells it to create a new hash for that user. The downside to that is it needs to be done for each Windows session since the logon script runs a different switch that calculates the same hash as it is based on username and domain.