| Date: | March 25, 2005 / year-entry #75 |
| Tags: | tipssupport |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050325-00/?p=36073 |
| Comments: | 26 |
| Summary: | This is one of those poorly-worded options. In the Start menu configuration dialog, you can choose to uncheck "Enable dragging and dropping". This setting disables drag/drop but also disables right-click context menus. The connection between the two is explained in the Group Policy Editor, but is unfortunately oversimplified in the general-public configuration dialog. Why does... |
This is one of those poorly-worded options. In the Start menu configuration dialog, you can choose to uncheck "Enable dragging and dropping". This setting disables drag/drop but also disables right-click context menus. The connection between the two is explained in the Group Policy Editor, but is unfortunately oversimplified in the general-public configuration dialog. Why does disabling dragging and dropping also disable context menus? History, of course. Originally, the "Disable drag/drop on the Start menu" setting was a system policy, intended to be set by corporate IT departments to prevent their employees from damaging the Start menu. With this setting, users could no longer drag items around to rearrange or reorganize their Start menu items. This is a good thing in corporate environments because it reduces support calls. But very quickly, the IT departments found a loophole in this policy: You could right-click an item on the Start menu and select Cut, Copy, Paste, Delete, or Sort by Name, thereby giving you access to the operations that the policy was trying to block. Therefore, they requested that the scope of the policy be expanded so that it also disabled the context menu. In Windows XP, it was decided to expose what used to be an advanced deployment setting to the primary UI, and so it was. Since it's the same setting, it carried the loophole-closure with it. |
Comments (26)
Comments are closed. |
Wow, I just figured my install was borked when I could no longer right-click on anything in the Start menu. Thanks for the tip, and I surely agree with the "poorly-worded" verdict.
I wouldn’t call that "poorly-worded"… I would call it "wrongly-worded".
It’s not wrong; it still does disable drag and drop. It just leaves out some information but a better description would help for sure.
Wouldn’t that sort of restrictions be more properly handled by putting the appropriate ACL on the Start Menu’s folder ?
I’m often amazed at how easy these policy-level restrictions are to get around. The last time was at TechEd Europe 2004, where it took me all of five minutes to open an Explorer window for C: on a machine where the "obvious" ways (My Computer icon, Start/Run…) had been hidden by policy (in fact, I seem to remember that what they had overlooked was precisely the start menu rightclicking !). I immediately closed it of course and walked away ; but it just confirmed to me that even for Microsoft employees, really locking down a windows desktop was hard.
Cheers,
–Jonathan
How come that when you install an application on Windows 2003 Server with the default OS settings, its icon goes into the sorted position but on Windows XP with the default settings (which are the same as on 2003), the icon goes to the bottom of the Programs list?
"Wouldn’t that sort of restrictions be more properly handled by putting the appropriate ACL on the Start Menu’s folder?"
Changing ACLs would stop Delete and Cut/Paste, but wouldn’t stop Copy or Sort by Name.
What a mess. Which PM owned this feature in XP?
Anonymous C:
Isn’t that fantastic? I keep reporting that bug and it keeps getting marked as "As Designed" or "Could not reproduce"
The correct fix would be to allow right clicking, and if the user tries to change the menu with right clicks, just pop up a message saying "Feature disabled by system policy" or something of the sort.
Ivan.
"Hmmm, I would have thought that there’s an ACL you could put on the directory that would prevent copying and sorting"
Sort order is stored in the registry, not in the folder on disk.
Ivan: I don’t know about correct; that could leave a loophole for shell extensions, for one. Besides, there isn’t really anything you can do via right clicking that isn’t changing the menu, so simple prevention is valid. (The Prevention vs. Popup standards seem to be at war all through windows.)
My favorite policy was one that would remove Windows Explorer and My Computer and the Run command to prevent people from messing up display models at stores and other such nonsense. You could get around it by opening notepad, then opening explorer.exe as text. It looked horrible, but would add the shortcut to your Recent Documents folder and you could run the app normally from there.
foxyshadis:then you would deal with shell extensions too, that’s up to the implementor. Also you could want to copy a start menu entry to the desktop, or view its properties.
3/25/2005 11:56 AM Pavel Lebedinsky
> The goal for most of these restrictions […]
> is to prevent people from accidentally
> messing up their systems, not to provide any
> kind of security
I would have thought so too. But then disabling drag-and-drop would only disable drag-and-drop and would not disable right-clicking. That is, it would have remained as originally designed.
Um, actually extending the scope stuck to the original design, which was "Prevent users from (accidentally) screwing up their Start menu". The policy was doing exactly what it was intended. It was expressed by using the phrase "Disable drag/drop" since drag/drop was the most common way people were doing it – that’s the "magic phrase" that system administrators were looking for in the documentation.
Hmmm, I would have thought that there’s an ACL you could put on the directory that would prevent copying and sorting…
Speaking of which, is it safe to assume that this feature *doesn’t* do anything about the user’s ability to simply navigate to the directory and mangle it by hand with Explorer? I would think that only ACLs could prevent that.
Why is that less of a loophole?
What I need is a low-level keyboard hook that filters out special keys (ctrl, alt, esc, F#, etc) so that my kids don’t accidentally screw up everything else when they are randomly hitting keys :)
Kristoffer Henriksson: "It’s not wrong; it still does disable drag and drop. It just leaves out some information but a better description would help for sure."
I hear "Uninstall Word" is a correct, if incomplete, description for "Format hard drive"?
Slightly off-topic (but still right-click related), when I right click a file and use the Send To menu in XP, the items in that menu are in random order. I’m used to "3 1/2 floppy (A)" being first, and everything in alphabetical order, the way I remember from Windows 95 through Windows 2000. (It’s broken like this only my XP Pro machine; the list is properly sorted on my Windows 2000 machine.)
My default view of the actual SendTo folder shows things sorted, but of course that doesn’t affect what shows up when I right click a file and navigate down to "Send To".
I have Googled for ways to fix this, and nothing comes up. It’s a little annoying, since I like having things in order… ;-)
Doug, just take those particular keys off the keyboard and only put ’em back on when you yourself are using the computer :D
doesn’t get much more low-level than that.
you could also download the plans for that tiny PIC keyboard logger that goes in between the PS2 connectors and just change the code a bit to filter out those keys unless you enter some special combination of other keys to re-enable them.
just make sure you don’t lose the keys if you take them off! :)
"Sort order is stored in the registry, not in the folder on disk."
As I remember, the Registry also has ACL.
Now if only developers would stop being lazy and require Administrator privs for everything…
3/25/2005 5:58 PM Raymond Chen
> Um, actually extending the scope stuck to
> the original design, which was "Prevent
> users from (accidentally) screwing up their
> Start menu".
OK. When I accidentally screw up my Start menu, usually it’s the same way I accidentally move files from one folder to another and stuff like that, by having fingers that click at different times from when I want them to. Second-most-often is if I’ve intentionally started a drag operation to put a shortcut at the top or bottom of the menu, and then some popup steals focus and the shortcut moves to the desktop instead of to a new location in the Start menu. Doing a right-click followed by some action other than cancel seems to me as most likely non-accidental.
Maybe that’s why you put "(accidental)" in parentheses? Mr. Lebedinsky and I didn’t, and I guess we did misunderstand the original intention.
Wouldn’t the correct original fix have been to just add another policy, "disable right-click on start menu"? Seems trivial to me.
>The last time was at TechEd Europe 2004, >where it took me all of five minutes to open >an Explorer window for C: on a machine
You need to consider what such policy restrictions are *designed* for – ie to reduce support overhead in corporate deployments. They are not a lockdown mechanism. They can *contribute* to an overall lockdown strategy, but are not the be all and end all.
So getting an explorer window to C: might sound like a real script kiddy type achievement, but if the system is locked down in the real context, then this would be meaningless due to the NTFS ACLs and audit settings that would be in place.
You’re kind of saying that you were able to break a window and hey presto you could get into a car by bypassing its security – the window’s primary purpose is not there to stop people getting into the car, although in can serve as a level in a defence in depth strategy.
UGH! Currently it’s my biggest gripe about Explorer… Figured it was a bug.