Shining a light on UAG SP3, IE10 and Windows 8 support
With the release of UAG SP3, Internet Explorer 10 is now supported by UAG. This support extends to both IE10 on Windows 7 and on Windows 8. Internet Explorer 10 has a few changes to its architecture which can be confusing with regards to how it works on 64 bit processors, and most importantly – how it is related to UAG’s support for 64 bit.
As has always been the case, UAG’s support for 64 bit technology was limited, and it still is. Traditionally, it was supported to use 64 bit client operating system (such as Windows 7 64 bit) to connect to a UAG server, but this stipulated that only the 32 bit version of IE be used:
With the release of UAG SP3, it is now supported to use the 64 bit version of IE on a 64 bit version of Windows, but that doesn’t actually mean UAG’s client is now 64 bit. UAG’s client components are still 32 bit only, and the way it works is as follows:
Internet explorer 10 has a tiered structure, where the browser has a manager process, which manages one or more content processes. For example, a tab displaying a website is a content process. On a 32 bit version of Windows, the manager process and the content processes are all 32 bit, of course. On a 64 bit version of Windows IE’s manager process is a 64 bit process. When you run IE10 in Modern UI (the one you run from the start screen), the content processes are 64 bit, but when you run IE in desktop mode (running IE from the taskbar or from a shortcut on the desktop, for instance), the content processes are 32 bit.
So, when you’re using the desktop version of IE on a 64 bit Windows 8, the content process which runs the UAG portal and the UAG client components is a 32 bit process, and so the UAG client components are still 32 bit. Even if you specifically launch the 32 bit version of IE, it still launches the 64 bit manager, and the content processes are still, of course, 32 bit. As such, the limitations that the UAG components have, such as only supporting 32 bit applications for application tunneling* are still in effect.
* 32 bit application for application tunneling When using application tunneling in UAG (SSL-VPN), the tunnel can only interact with 32 bit applications on the client computer. If you run a 64 bit application, it will not be able to “see” the tunnel or to communicate with its designated server. For most applications this is not a problem, as you can simply install the 32 bit version of the app on a 64 bit system using WOW. This situation can sometimes cause confusion, because some components of the operating system itself are 64 bit. For example, if you try to use TELNET to test the SSL-VPN tunnel, it would not work, because the TELNET client that is included with Windows 64 bit is 64 bit itself. To diagnose the tunnel on a 64 bit system, make sure you use 32 bit tools, such as copying the 32 bit version from another computer, or using a 3rd party tool such as PuTTY, which is available in 32 bit versions. |
If you are using the Modern UI version of IE, the content processes are 64 bit (along with their manager), but in this mode, the security model prevents running any browser add-ons. This means that UAG’s client components cannot load regardless of their structure. If you do browse to the UAG portal page on the Modern UI version, the browser will inform the user that they should use the desktop mode:
*important* In the Desktop mode version of IE10, it’s possible to set the content processes to run in 64 bit mode (the setting is Enable Enhanced Protected Mode in the Security Settings of IE), but since the UAG client components don’t really exist in a 64 bit version, setting this doesn’t get around this limitation, and when the content processes run as 64 bit processes, UAG’s client components will not load.
Another thing to know about using UAG with IE10, and is not related to 64bit/32bit is that some of the UAG portal pages, as well as some application pages may not display correctly due to changes to ASP.NET. To resolve this, we recommend installing KB 2600100 on your UAG server or servers.
Blog post written by Erez Ben-Ari and Ran Dolev