Re: Desktop shortcuts don't work

I don't see anything that strikes me from a security perspective. It seems like maybe you have desktop redirection enabled in a policy that's applied to servers as well as client PCs. Since the permissions on the redirected Desktop folder seem OK, have you run that tool to check the context menu handlers? I'm just speculating that that might be the cause, but it'll just take a couple of seconds to check. Context menu handlers are like when your antivirus app adds "Scan for viruses" to your r-click menu. It's not uncommon for them to cause really bizarre issues, often but not always related to right-clicking.

The other diagnostic tool you could try is filemon - start monitoring, try to access the shortcut, and see what it logs when it fails. http://technet.microsoft.com/en-us/sysinternals/bb545046.aspx


"Matthew" <adminNOSPAM@xxxxxxxxxxx> wrote in message news:uzLZXv9CKHA.3708@xxxxxxxxxxxxxxxxxxxxxxx
Sorry, I'm logged in as Administrator. Under Documents and Settings\Administrator, there is no Desktop folder. Same deal on my workstation, so I assumed that was the way it goes.

Under All Users\Desktop, a grayed out Full Control is given to Administrators group, as well as System

Under Documents and Settings\Administrator, Full Control is clear (not grayed out) for Administrator, Administrators, and System.

The shortcut has grayed out Full Control given to Administrator and to System. INterestingly, if I click on Advanced Security Settings for eventvwr.exe shortcut on desktop, permissions for Administrator are Inherited From \users\administrator\Desktop.

Aha, so that's where the user's desktop folder is! Security there is Full Control for Administrator and SYSTEM.

So you don't think there's anything malicious or nefarious going on, based on just this little weirdness?

Thanks!

Matthew

"Dave Nickason [SBS MVP]" <gwdibble@xxxxxxxxxxxxxxxxxxxxxx> wrote in message news:unxGPm9CKHA.4692@xxxxxxxxxxxxxxxxxxxxxxx
I've got that SID listed at the top level of Documents and Settings as well. I'm not sure why it's showing as Account Unknown but it doesn't seem like anything to worry about.

I'd be more interested in the security settings for the Desktop folder under the profile of the logged in user. Are you logging in as Administrator, or with some other account? For the Desktop folders, you'd expect the Administrators security group, the user (Administrator or other), and System to have full control. The permissions should be inherited from the top level - for example, c:\documents and settings\administrator, or c:\documents and settings\administrator.domainname.

I don't really think permissions are the issue given that some shortcuts work and others don't. At least, if it's permissions, it seems like it would be those on the target rather than on the Desktop folder. If you log in with the actual 500 account - Administrator - do you get the same result?


"Matthew" <adminNOSPAM@xxxxxxxxxxx> wrote in message news:%23nqaIZ9CKHA.1248@xxxxxxxxxxxxxxxxxxxxxxx
I've learned from here: http://support.microsoft.com/kb/243330 that this is a well-known Security Identifier for the Power Users group:

SID: S-1-5-32-547
Name: Power Users
Description: A built-in group. By default, the group has no members. Power users can create local users and groups; modify and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups. Power users also can install programs; create, manage, and delete local printers; and create and delete file shares.

Why would it have these permissions, and why would it be identified by its SID instead of its name?

Thanks,

Matthew

"Matthew" <adminNOSPAM@xxxxxxxxxxx> wrote in message news:%23Z%23BqS9CKHA.3724@xxxxxxxxxxxxxxxxxxxxxxx
Uh oh.

In the Security tab of the server's C:\Documents and Settings, under Group or user names, it lists Account Unknown(S-1-5-32-547). Permissions checked are Read&Execute, List Folder Contents, Read.

Permissions for this unknown user over C:\Documents and Settings\All Users\Desktop are less specific - every box except Full Control is checked and grayed out.

Is this as concerning as it sounds? Should I remove the account from permissions on these directories? What other directories could this account have access to? Has something taken over?? Yikes?!

Thanks!!

Matt


"Dave Nickason [SBS MVP]" <gwdibble@xxxxxxxxxxxxxxxxxxxxxx> wrote in message news:OEwrAI9CKHA.5068@xxxxxxxxxxxxxxxxxxxxxxx
That's odd. So if you copy and paste the shortcut from Admin Tools onto the desktop, it doesn't work? And the one on the Admin Tools menu works as expected, with all other things being equal?

You've looked at the permissions on the shortcuts, targets, and Desktop folder, right? And checked the event logs?

I guess at this point I'd start by taking a look at the context menu handlers, which are often to blame for bizarre behavior. What you do is to run the Shell Extensions Manager from http://www.nirsoft.net/utils/shexview.html. Sort by Type and disable all the 3rd party (non-Microsoft) context menu handlers ("Context Menu" under Type). If the shortcuts start working, you can re-enable the handlers one at a time to find which one is to blame.

This isn't the classic symptom of a bad context menu handler, but it'll only take a second to try. If you find it's that, you can just see if the vendor has a newer version, or leave it disabled.


"Matthew" <adminNOSPAM@xxxxxxxxxxx> wrote in message news:uirCss8CKHA.1252@xxxxxxxxxxxxxxxxxxxxxxx
Hi,

Wondering if I should be concerned about this. SBS 2003. Long ago, I placed shortcuts on the desktop to access Event Viewer and Active Directory Users and Computers. These shortcuts always worked fine.

Now, clicking on them results in:

C:\WINDOWS\system32\eventvwr.msc
Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.

I have no problem accessing them by going to Start > Administrative tools, or by typing their path in Start > Run.

I have no problem with any other shortcuts on the desktop.

I'm concerned about not having permissions from a shortcut.

I can delete them. Then I try to re-add them, by copying them from their location in Administrative Tools, or by creating shortcuts and moving them to the desktop. These don't work, either.

If I try to rt-click on desktop, Create Shortcut, and browse to eventvwr.msc, it says Cannot create shortcut. I can create shortcut in this manner to eventvwr.exe, but the shortcut doesn't work, with same error msg as above.

Is this something to be concerned about, or is this just tightened security?

Thanks in advance!!

Matthew













.

Relevant Pages

  • Re: Too late for Administrators Password?
    ... if you're going to be messing with permissions then ALWAYS FIRST SET ... folder and click the Security Options folder. ... Next, administrator, you need to have the security tab show when you ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Desktop shortcuts dont work
    ... Since the permissions on the redirected ... Desktop folder seem OK, have you run that tool to check the context menu ... The shortcut has grayed out Full Control given to Administrator and to ...
    (microsoft.public.windows.server.sbs)
  • RE: receiving access denied message on all folders in logical pa
    ... but there is not a 'security' or advance button on either. ... > Administrator account (e.g. it may be called Administrator, ... > Click on the Ownership tab ... > Review the listed permissions configuration and adjust as desired ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Administrator/User security issues
    ... > folders for testing the security. ... > permissions but the admin. ... >>Any Administrator can do and undo anything any ...
    (microsoft.public.windowsxp.security_admin)
  • More security questions
    ... I have studied a number of articles and documents about user-level security ... From what I can tell, when I go to User and Group permissions and view ... on the shortcut fills in that person's user ID. ... In a split database, I'm still trying to sort out when I assign ...
    (microsoft.public.access.security)
Loading