Completely prevent users from using Alt to open Menu Bar in IE

You cannot do this without a custom ActiveX control

I disagree.  A testy nun standing next to the user and slapping their hand every time they press the alt key would  also do the trick.

In general, if your security is defined by restricting user-side behavior, you're doing it wrong.

If only there was a Like button....

I just had a flashback from elementary school. I hope the nightmares don't come back.  One thing to consider in the whole equation is that this is a thinapp, so if I could edit something even in the OS to restrict this behavior, it might actually be captured in the build process and workout. Any thoughts?

No, it cannot be done via configuration. Again, customization or nun only.

Ah... there's a glimmer of hope!  I'll give your suggestions some research and post whatever I run into along the way. Like everyone has previously suggested, it may be for not. I suppose as an alternative solution and perhaps a simpler one in the meantime would be to disable any specific options in the registry that they would be able to access from the menu bar. It may turn out to be the most viable option in the end, but I'm still curious about eliminating access to the menu bar altogether. I'll keep you posted. If anyone thinks of anything else, please let me know.

Out of curiosity, what is the motivation for trying to prevent access to the menu bar?

I've got a number of web-based LOB apps that run on specific versions of IE and Java (none on the latest of either) and some that are in direct conflict with other LOB app requirements. This creates a nightmare from a deployment perspective...in comes VMWare ThinApp.

My intent has been to create as much distinction as possible between the IE ThinApps that I create for the end-users and the native IE browser on their host operating system. For each ThinApp, I have achieved this by "re-branding" the browser, restricting site access, hiding the address bar and favorites bar, etc.. The thought occurred to me that if I could disable the menu bar entirely, it would kill user access to all of the remaining settings that need to be restricted.

So first, have you tried to run multiple IE thinapps concurrently? I know there are sometimes some issues with running an app concurrently, and if you have any users that may need to use different versions of IE at the same time to access different systems, I would be sure to thoroughly test that scenario. IE is notoriously whiny. Not saying it can't be done - just saying you should make sure you try it out before you get too much further.

Second, this seems like a backwards solution. Part of the beauty of web-based apps is the ability to be portable / cross-platform (also cross-browser, when done right). In many cases, I've been able to resolve IE versioning problems with legacy apps simply by injecting a meta tag into the legacy apps that forces IE to work in a compatibility mode. That's what the compatibility mode (and quirks mode) is there for - to allow newer IE versions to emulate older versions in order to maintain compatibility with outdated apps.

Just saying - you may want to exhaust all possibilities in terms of configuring the web app before moving to a client-side app deployment solution. It'll probably be much easier to maintain in the long run.

In answer to your first question, not thoroughly. I've tested a few concurrently, but this is really my proof-of-concept phase. After thorough pilot testing has been conducted, I was hoping to get buy-in from management to acquire sufficient ThinApp licenses for full fledged deployment.

Since the LOB apps in reference are typically pre-built, hosted solutions and not custom or entirely on premise, I don't know how to approach the meta tag angle. I'm guessing that I would have to contact each vendor and explore the prospect with them individually. I'm assuming the vendor would ultimately have to be the one to beta test the app using a browser in emulation mode and perform any debugging before they would release it to market; and most importantly, continue to support it.

I would prefer the meta tag angle if pursuing that route is feasible. I just don't know how feasible it would be considering that we do not have ownership of so many of these sites.

I thought I should take a look at the existing site meta tags and go from there. One site contains the following:

<META HTTP-EQUIV="X-UA-Compatible" content="IE=edge,chrome=IE8"/>

Based on what I've researched the tag line indicates usage of Google Chrome Frame for IE8 (and below) otherwise it passes the "Edge" parameter to later versions of IE. The question is which version of IE? GCF is deprecated, so the "IE8" parameter must be a clue that at a minimum it would be IE9, if my understanding is correct.

So testing the site for compatibility with IE, I started with IE11 and worked backward. As it turns out, IE11 and IE10 are not completely compatible with the site. IE9 is completely compatible. IE8 produces a warning at the onset stating that states the site may not be completely compatible with IE8 continue at your own risk.

I tried IE11 and IE10 with Compatibility View enabled and then disabled with no luck. Also attempted to mimic the IE9 settings as best I can tell, yet I still get an error when trying to login to a particular portion of the site. That portion contains the same exact meta tag. I'm still digging for more info...I'll post again tomorrow.

I think in this particular case, there is something going on outside of IE that's causing what appears to be an incompatibility issue with IE on the site. I haven't been able to confirm what that might be yet.  At any rate, I don't want to go off on a tangent. I think you've pretty well answered the question in that we can't "turn off" the Alt option and additionally provided some potential workarounds. Thanks to everyone for your input.

Thanks to everyone for their input.

Just as a note for the future - any grade less than an "A" usually means that there was an incomplete answer (e.g. if someone asks 5 questions and only 3 get answered) or there was a problem with the answer itself.

Even if the ultimate answer is, "You can't do this," you should still award the A grade if that's the correct answer. Not a big deal right now - just saying for the future.