none
Win10 1703 with RSAT 1607 Access Denied RRS feed

  • Question

  • We have a Windows 10 1703 image created with SCCM build and capture.  Whether or not the RSAT update was installed by SCCM or manually afterwards, using shift-right click-run as different user results in access denied.  

    • Double clicking the shortcut works OK
    • Right click run as administrator works OK
    • Navigating to c:\windows\system32\dsa.msc works OK

    Note that navigating to c:\windows\system32 by using "Open File Location" in the right click menu opens the folder in the same window that displayed Windows Administrative Tools.  Right clicking dsa.msc from here also results in access denied.  

    If you right click the shortcut for Active Directory Users and Computers and go to properties, then click on "open file location", a new windows opens.  If you right click dsa.msc here it works OK.  

    It looks like there is some permission issue with c:\programdata\microsoft\windows\start menu\programs\Administrative Tools.  The same issue occurs with tools like services.msc which is not part of RSAT.  

    Folder permissions for the Windows Administrative Tools on the start screen are as follows.  

    • All application packages -> Read and Execute (not inherited)
    • Creator Owner -> Special -> Full (subfolders and files only) (inherited)
    • System -> Full (not inherited)
    • Client_Admins (domain group of local administrators) -> Full (not inherited) -> not sure where that came from
    • Administrators - Full (not inherited)

    What seems to be missing is everyone and users.  Adding them with read&execute and apply to all children does not fix the problem. 

    Windows Administrative Tools is pinned to the start screen using the import-startlayout command. 

    I’m going to comb through some group policy to see if I’m messing up the permissions somehow.  Our tech images should not have admin tools blocked, but the main image does.  Perhaps the policies got crossed.


    Thursday, August 17, 2017 3:46 PM

Answers

  • Easiest way to reproduce:

    • right click your desktop -> New shortcut
    • target is:  c:\windows\explorer.exe "c:\programdata\microsoft\windows\start menu\programs\administrative tools"
    • Double click this shortcut
    • Try and shift-right click services.msc and run as other user.  

    I found that if I navigate to control panel -> Administrative Tools and then drag a shortcut from the address bar to the desktop, that does work and has this for a target, dropping the explorer.exe part.

    "c:\programdata\microsoft\windows\start menu\programs\administrative tools"

    • Marked as answer by Mike Plichta Thursday, August 17, 2017 5:22 PM
    Thursday, August 17, 2017 5:22 PM

All replies

  • It turns out there is a GP being applied that references "c:\programdata\microsoft\windows\start menu\program\Administrative Tools".  The policy is under computer->Security->File System.  Note that this is the "real" path rather than the friendly "Windows Administrative Tools" name the folder gets in explorer.  Turning off the GP and restoring the ACL from a working computer does not fix run as different user for the administrative tools.  

    I'm going to try reimaging now that the policy is no longer applied.

    Thursday, August 17, 2017 4:11 PM
  • After imaging with a stock windows image (SCCM task sequence applies the ISO for 1703, adds drivers, joins domain, adds domain administrator group), the shortcut for services.msc works.  

    What breaks it is adding a shortcut (.lnk file) to c:\windows\explorer.exe "c:\programdata\microsoft\windows\start menu\programs\administrative tools".  The shortcut is placed in c:\programdata\microsoft\windows\start menu\programs and then pinned to the start menu.  It is set to start in "c:\windows".  If you try to run as different user off the .lnk file or it's pinned version, you get access denied. Changing the folder link to %HOMEDRIVE%%HOMEPATH% doesn't fix it.  

    Adding the shortcut breaks the services.msc link in the start screen list under W.  Right clicking "Sservices" -> Open file Location and then right click run as stops working after pinning a shortcut to admin tools to the start menu.

    Unpinning and removing the shortcut restores functionality. 

    Thursday, August 17, 2017 5:16 PM
  • Easiest way to reproduce:

    • right click your desktop -> New shortcut
    • target is:  c:\windows\explorer.exe "c:\programdata\microsoft\windows\start menu\programs\administrative tools"
    • Double click this shortcut
    • Try and shift-right click services.msc and run as other user.  

    I found that if I navigate to control panel -> Administrative Tools and then drag a shortcut from the address bar to the desktop, that does work and has this for a target, dropping the explorer.exe part.

    "c:\programdata\microsoft\windows\start menu\programs\administrative tools"

    • Marked as answer by Mike Plichta Thursday, August 17, 2017 5:22 PM
    Thursday, August 17, 2017 5:22 PM