How can I turn off the CTRL+U key combination in IE 11?

hmm, did you consider using a custom browser for you help pages?

Lateral thinking approach ...
Try

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IEDevTools

Select allOpen in new window

Add DWORD  "Disabled" = 1

Add a user software policy deniying user to run iexplore.exe.
A user intent on running, is able to..
Configure proxy on the server and limit the server connected user .....

The "Disabled" registry entry didn't change the situation.  There MUST be some "trick" out there for this one key combo!?

Did you try

NoViewSource - Disable the ability to view the page source HTML

Select allOpen in new window

From your last kiosk question?

Yes, I have that in my registry settings.  It hides the "View Source" option when you "right-click", but I've gone farther and disabled the right-click option altogether.  Problem is, this registry entry has NO AFFECT on the CTRL+U key combo!!!

You may need to disable this at machine rather than IE level
Try a Scancode entry for ctrl+u (you’ll need separate entries for left and right Ctrl keys)
http://www.northcode.com/blog.php/2007/07/25/Securing-Windows-For-Use-As-A-Kiosk

there are many potential other ways to start  a variety of .........
does the system have a centrally managed ant-virus security i.e. mcaffee, symantec end point that an application logging and notification rule when a user violates policy, .....


what is the application that you are presenting to the user, limiting it to just that application....

If it is a web based app, why does the user need rdp application....

MASQ, your solution is a little too radical for the situation I'm facing.  In theory, the corporate users "should" be following the appropriate corporate guidelines and should NOT be attempting to "subvert" my system using a rather obscure key combination like CTRL+U to gain access to my server.  As much as I'm trying to protect myself against the "worst-case" scenario, I can't make the CTRL keys inoperable for all the users who are using the system correctly.

Arnold, I have to admit that I don't really understand your suggestion.  I am running Symantec Endpoint Security on my server and SEP has protected my server from these malware attacks.  Again, my objective is to avoid even the possibility of someone gaining inappropriate access to be able to even attempt to do something that might initiate a malware attack (which will most likely be caught by SEP anyway).  If you could provide some specific details on what you're proposing (using SEP as the solution...), that might help me out....Thanks!

SEP includes application control, defining  a log rule for user running cmd.exe, iexplore.exe or you can configure the action of SEP application to deny the user's attempt to run anything other than the speciific programs/applications.

What rights do the users have on your system, limited, standard users?

https://support.symantec.com/en_US/article.HOWTO126038.html
 

I understand your need to limit what you disclose does each user has their own login..

Not disabling Ctrl completely, just in combination with “U”, perhaps that would be more acceptable?
This example using Microsoft’s Keyboard Layout Creator tool to remap the keyboard in the registry.
http://www.sensefulsolutions.com/2010/08/how-to-fix-keyboard-shortcuts-in-klc-eg.html

I like both of your suggestions.

Arnold, I'm not very conversant in SEP although I really like it.  Your suggestions could resolve a lot of my issues, especially where users can potentially run a program (like "cmd.exe), which is something I just can't totally disable within my software since I need to provide a certain level of functionality.  The users have standard (Domain Users) rights, they do NOT have any administrative rights, and, yes, they each have their own login credentials (currently somewhere between 500-600 users, but this will be growing over the next year or so).

MASQ, If I can disable CTRL+U, that works for me too, since that key combination is not used anywhere else in my application.

Finally, I'm a "early to bed, early to rise" person, so I'm done for today, but I will be looking into both of your suggestions tomorrow.
Thanks!

Just a comment:

In theory, the corporate users "should" be following the appropriate corporate guidelines and should NOT be attempting to "subvert" my system using a rather obscure key combination like CTRL+U to gain access to my server.

Imho a normal user cannot really mess up a server, assuming that you have not given him additional permissions.

On the other side: such a server has indeed a greater attack surface, thus a greater chance, that something went wrong. But this means: you should already have a quick server restore/reimage (from backup in place). And I, if your concerns are valid, then you should even consider reimaging the server regularly (e.g. on weekends).

Another option (untested): When Docker for Windows works as under Linux, then you'll get a good isolation level. So this maybe also an approach for running remote apps instead of remote desktop.

Your point is well taken and I do make a "bare bones" backup of my server every night and rotate the backup destination between 2 external devices so that I always have a secure and complete backup I can recover from.  My primary concern is my client's data, but secondary to that would be whatever damage someone with "intent" might do (albeit without having administrative rights) to my system.  The corporation is taking appropriate steps to investigate and possibly "censure" the individuals that have been identified over the past few months of introducing malware to my network.  SEP was able to prevent any corruption, but security is still a concern as it is for most companies.

An additional comment:

When I say backup/restore/reimage your server, then I mean the OS volume - assuming that you have an OS volume and a separate DATA volume.

For protecting your DATA volume: You need to consider file versioning and/or high-frequency backups.
BUT: NTFS permissions MUST be set properly so that nothing bad can happen at all.