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

I've created an IE9 ThinApp for a line of business application in our environment. I have successfully created a number of restrictions using the registry key [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Toolbars\Restrictions], however I have not found one that will prevent users from pressing the Alt key and gaining access to the Menu Bar when IE is in focus.

When IE is in focus... I don't want to disable usage of the Alt key for any other applications, just IE. I'm already aware that the "NoMenuBar" dword simply hides the Menu Bar, and does nothing to prevent the user from gaining access to it using the Alt key while IE is in focus. Is there an alternative registry key, group policy setting, or other method with which I can persistently hide the Menu Bar?
SnAkEhIpSAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

gr8gonzoConsultantCommented:
You cannot do this without a custom ActiveX control (and even then, I'm not 100% sure it's possible). If an ActiveX can trap the keystroke, then it should be able to suppress it:

https://msdn.microsoft.com/en-us/library/3476fwez(v=vs.71).aspx

However, building an ActiveX control is not a simple thing, so you'd likely have to find a developer that is comfortable doing it and have him/him her create it for you.
0
Steve BinkCommented:
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.
0
gr8gonzoConsultantCommented:
If only there was a Like button....
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

SnAkEhIpSAuthor Commented:
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?
0
gr8gonzoConsultantCommented:
No, it cannot be done via configuration. Again, customization or nun only.
0
Squidly_ManCommented:
JCB431 - You are correct on your last assumption, assuming the capturing of the ALT key could be done natively (you would then potentially be able to capture/update the project with the settings).  I think the others are correct here though, I'm not sure it's possible unless you can do so with an ActiveX component embedded into the app (IE9) or the ThinApp package.

What you might be able to do instead is, check for focus using script coding such as powershell, VB Script, or some other coding which you execute either within IE or the ThinApp package.  

Assuming you utilize VB Scripting, it is possible to embed this into the ThinApp package by making it part of the project using the ThinApp Scripting template provided by VMware.   You could then conduct some sort of validation check to ensure the application is always in the foreground - and if not, either prompt the user or close the application.

See the VMware ThinApp Blog Posting "Adding Non-Active Directory Validation Logic to a ThinApp Package" as a reference for some ideas.  I would then suggest Googling for VB Script examples to check application focus and if not active, then either prompt or just reset as active.

You'll need to test how this might work for you both natively and within a ThinApp package but it is worth a shot to see if it addresses your need.

Hope this helps!
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SnAkEhIpSAuthor Commented:
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.
0
gr8gonzoConsultantCommented:
Out of curiosity, what is the motivation for trying to prevent access to the menu bar?
0
SnAkEhIpSAuthor Commented:
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.
0
gr8gonzoConsultantCommented:
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.
0
SnAkEhIpSAuthor Commented:
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.
0
gr8gonzoConsultantCommented:
Okay, I thought the apps were all on-premise. That said, you could also potentially go down the route of simply using GPO to deploy IE configuration to force it to use quirks or compatibility modes for different sites (you'd just have to test which mode to use for which site). Here's a guide on how to do it:

http://www.danielclasson.com/guide-how-to-force-specific-sites-to-always-run-in-compatibility-view-using-group-policy/
0
SnAkEhIpSAuthor Commented:
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.
0
SnAkEhIpSAuthor Commented:
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.
0
SnAkEhIpSAuthor Commented:
Thanks to everyone for their input.
0
gr8gonzoConsultantCommented:
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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Web Browsers

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.