Yet another plus for being a consultant is running into issues never seen before, searching for a solution, seeing tens of thousands of hits with no solution in sight, and coming up with a solution. I have done many XenApp 7.x and XenDesktop 7.x deployments where Internet Exploder, I mean Explorer, 10, and 11, were used, and I have never seen or heard of this issue. On a recent project, I was asked to finish a XenApp 7.6 deployment running Windows Server 2012 and Server 2012 R2. One of the issues I was tasked to resolve was that IE 10 and 11 had two weird issues for any user, regular or administrator. This is how we solved the issue.

This project allowed the users to use Google Chrome, Mozilla Firefox, or Microsoft Internet Explorer (IE).  There were some sites (intranet and Internet) that required the use of IE. IE exhibited the same two issues whether the user was regular or administrator or whether a local or managed profile was used. The two issues were:

1. If IE were opened with no URL supplied, the user would get a blank white screen that stayed for a few seconds and then abruptly ended.
2. If IE were opened with a URL supplied, the site’s page would display, but nothing could be done in IE. If an additional tab were opened, IE would go into a death spiral with just a spinning circle until the process was terminated.

I searched using various search terms and just saw tens of thousands of hits with people reporting the same two issues but no real solution anywhere in sight. I finally came across the right search terms of “terminal server troubleshooting internet explorer” and came across a “solution” for this customer. I say “solution” because I don’t like the solution or understand why it is necessary.

The MSDN article I found is Things to do when troubleshooting Internet Explorer Terminal Server and Profiles issues. That is an interesting article to read.

We also placed a call to Citrix Support and also needed to use CTX127874.

Our solution was to create a new group policy with two logon scripts.

Script1  contains a batch file (named ResetIE.bat) with the following contents:

"C:\Windows\SysWOW64\ie4uinit.exe" -UserIconConfig 
"C:\Windows\System32\ie4uinit.exe" -BaseSettings 
"C:\Windows\SysWOW64\ie4uinit.exe" -BaseSettings 
"C:\Windows\System32\ie4uinit.exe" -UserIconConfig 
"C:\Windows\System32\regsvr32.exe" /s /n /i:/UserInstall C:\Windows\system32\themeui.dll 
"C:\Windows\System32\regsvr32.exe" /s /n /i:U shell32.dll 
"C:\Windows\System32\regsvr32.exe" /s /n /i:/UserInstall C:\Windows\system32\themeui.dll 
"C:\Windows\System32\regsvr32.exe" /s /n /i:U shell32.dll 
"C:\Windows\SysWOW64\rundll32.exe" C:\Windows\SysWOW64\mscories.dll;Install 
"C:\Windows\System32\rundll32.exe" C:\Windows\system32\mscories.dll;Install 
"C:\Windows\System32\unregmp2.exe" /FirstLogon /Shortcuts /RegBrowsers /ResetMUI 
"C:\Windows\System32\unregmp2.exe" /FirstLogon /Shortcuts /RegBrowsers /ResetMUI 
"C:\Program Files\Windows Mail\WinMail.exe" OCInstallUserConfigOE 
"C:\Program Files (x86)\Windows Mail\WinMail.exe" OCInstallUserConfigOE

There are three lines we had to remove from what the MSDN article said to use:

"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iedkcs32.dll";BrandIEActiveSetup SIGNUP 
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll";BrandIEActiveSetup SIGNUP 
"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iesetup.dll";IEHardenAdmin

Those three lines gave us DLL errors with popup dialog boxes.

Script2 follows the instructions in CTX127874, as shown in Figure 1.

Running these two scripts in a User group policy, as shown in Figure 2, allows IE 10 and 11 to work every time.

Why this is needed is beyond me. Some people say it is a registry permissions issue when creating/updating the profile, but the IE issues happen even for domain admins. All we care about is that the users can use IE 10 and 11 in their new XenApp 7.6 environment.

Thanks

Webster