Windows Explored

Not too long ago we began to see a rash of IE problems when trying to install or run various ActiveX controls and plugins. Often, there was no literal error, the ActiveX control would just try to install again after revisiting the page, often indicating that it was successfully installed, but then only fail to run. We would initially troubleshoot by running IE elevated because standard users could not install ActiveX controls. The odd thing was that this always resolved the issue temporarily, so long as we left that session of the browser opened. Once closed, the problem resumed. Eventually, after much head scratching, we realized that the affected users Internet Explorer pinned in the Taskbar was pointing to C:\Program Files\Internet Explorer but when we would troubleshoot, we were elevating from the proper C:\Program Files (x86)\Internet Explorer folder since we are a 64 bit shop now. The question still remain, though, how the IE shortcut pinned to the taskbar was getting its path changed to the 64 bit version of IE. Since most, if not all the users, were recent Windows 7 migrations, we are guessing something went funky in the task sequence.

UPDATE

Even after writing this it still didn’t occur to me that IE Bitness was again the issue when encountering a Java error in IE for a Citrix published app.

Manually logging into the server confirmed that Java was installed and working. It didn’t come to me that IE might be running in the wrong bitness until after I looked at the HKU\S-1-5-21…SID\Software\ key of the user profiles on the Citrix box and saw that the JavaSoft key was not being created. A script was used to launch the app and went something like this.

…

The InternetExplorer.Application object in a 64 bit OS will launch the 64 bit version of IE since the OS will default to the 64 bit wscript engine. To work around this, force the 32 bit wscript engine: