RunAs with Explorer

This is the latest post in my series about how to run with limited user privileges on Windows XP and to use administrator privileges only as needed.  In my first post, I wrote “Unfortunately, Windows does not yet make running as non-admin as straightforward as it needs to be.”  This is probably nowhere more glaring than when trying to run Explorer in a different security context.  Many tasks in Windows are most easily performed in Explorer, and some can be performed only in Explorer.  But when you try to use Run As with explorer.exe with a default XP configuration, nothing happens.  This post is all about how to get it to work.


Needing Explorer as admin


Some of the scenarios in which you may want to run Explorer as admin include:

1)       Setting file/folder security settings (ACL editor).

2)       Sharing folders

3)       Control Panel applets/subfolders that are handled by Explorer, including:

a.       Folder Options, including viewing and setting file type associations, actions, and context menu options.

b.       Printers and Faxes, including installing a local printer

c.       Fonts

d.       Network Connections, including settings for the pre-SP2 Internet Connection Firewall.  (See side notes below)

e.       Scheduled Tasks

f.         Scanners and Cameras

Some of these tasks can be accomplished with command line utilities.  But you really need to get out more if you actually prefer to use subinacl.exe when the GUI ACL editor can do the job.


Two side notes about Network Connections:


  1. .cpl files are Control Panel extensions.  As I noted in "RunAs" basic (and intermediate) topics, you can use RunAs with .cpl files, or launch them directly from your admin cmd prompt.  In the system32 folder, the file properties of ncpa.cpl show that it is the “Network Connections Control-Panel Stub”.  So why doesn’t RunAs work with Network Connections?  Because that stub merely calls the ShellExecuteEx API to launch an item in the shell namespace, which appears as a folder within Explorer.


  1. With SP2, there is a new Windows Firewall control panel applet (firewall.cpl), so you no longer need to go through Explorer and Network Connections in order to manage the firewall settings.




Making it work


The reason RunAs doesn’t work with Explorer is because when explorer.exe starts, by default it looks to the current desktop for an already running instance of itself.  The new instance notifies the previous one, which performs the requested operation while the new process quietly exits.  Since explorer.exe also provides the interactive shell – the desktop and the taskbar – explorer.exe is always running except in unusual circumstances.


Creating such an unusual circumstance is one way to allow a new explorer.exe to run in a different security context.  The downside is that once you do that everything running within the new explorer.exe or started from it will run in that alternate context.  You still don’t have both contexts living side by side.


There are two viable options:

1)       Use Internet Explorer instead of (Windows) Explorer; and/or

2)       Set the flag that allows explorer.exe to work with RunAs.


Option 1.  Use Internet Explorer instead of (Windows) Explorer


I briefly discussed this in my post about RunAs, and Keith Brown also discusses it in his upcoming book.  Unlike explorer.exe, Internet Explorer is perfectly willing to work with RunAs.  Two ways you can get there are

1)       start iexplore.exe from an admin cmd prompt (see my “ie.cmd” tips in the earlier post); or

2)       right-click on an Internet Explorer icon and choose Run As.  This approach does not work with the IE icon on the desktop or at the top of the Start menu, but it does work with the one in the Quick Launch bar if that is displayed in your taskbar.


Once you have IE running, you are not restricted to browsing web sites.  Type a local address in the address bar, such as “C:\”, and all of a sudden, IE starts looking a lot like Explorer.  The toolbar and the menu options change, and you can easily browse your file system, Control Panel and its subfolders.


You can also type the names of certain shell folders in the address bar to browse them.  For example, try typing any of these in the IE address bar:  My Computer, Control Panel, or My Documents.  From Control Panel, Network Connections and the other subfolders become accessible.


To save steps, specify the target location on the IE command line.  E.g., with ie.cmd in your path:

C:\>ie.cmd c:\projects

Or to get really interesting, browse directly to shell namespace folders.  This command line will take you directly to Network Connections:

C:\>ie.cmd ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{7007ACC7-3202-11D1-AAD2-00805FC1270E}



Option 2.  Set the flag that allows explorer.exe to work with RunAs


It’s actually very simple.  The trick is to set the folder option to “Launch folder windows in a separate process”.  This is a per-user option, off by default, that needs to be set for the target user account.  That is, if you want to use RunAs to start explorer.exe as MyAdminAccount, then MyAdminAccount needs to have the “separate process” option set.  Once this flag has been set, you can start explorer.exe with RunAs, or from your admin cmd shell.



Why use explorer.exe instead of IE?


It’s just personal preference, but there are a few reasons I tend to use explorer.exe instead of Internet Explorer for admin tasks:

1)       explorer.exe is in the path, so it is easier to use from a command line.  The folder where iexplore.exe lives isn’t in the path.

2)       explorer.exe offers more flexibility through its command line options.  For example, I use /e,/root, all the time.  Explorer’s command-line options are supposed to be described in KB 314853 (“Explorer.exe Command-Line Options for Windows XP”), but the documentation is actually more accurate in KB 130510, even though the latter was written for Windows 95!


I have a handful of .cmd command script files that open rooted windows in various special folders such as Network Connections, Printers and Faxes, etc.  These make useful RunAs targets, and work well from the command line as well.


How do you set the “separate process” flag, then?


You want to start explorer.exe as local admin, but you haven’t set the “separate process” flag for the local admin account yet.  The GUI you need for this is in Folder Options, which runs within Explorer.  Which you can’t run as admin, since you haven’t set the flag yet!  Here are a couple of ways to get around that chicken-and-egg problem without having to log out and log back in as local admin:

1)       Start IE as admin, enter a local address in the address bar to change the menus to those of Explorer, and choose Tools / Folder Options / View.  Check “Launch folder windows in a separate process.”

2)       Manipulate the setting directly in the registry.  Run regedit as admin, navigate to HKCU \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ Advanced.  Change the SeparateProcess DWORD value to 1.  Or just rename and run this .reg file from an admin cmd shell.


The setting takes effect immediately.


More info about Explorer’s Separate Process flag


I must point out that supporting RunAs is not the purpose for “Launch folder windows in a separate process”.  The fact that it does is merely a side effect, and an unintended one at that.  Without “separate process” enabled, all Explorer windows run in the same explorer.exe process that also hosts the desktop and the taskbar.  With the setting enabled, the desktop+taskbar gets its own explorer.exe process, and all Explorer windows share a separate explorer.exe.  There are some minor exceptions.  If you press Win+E, the new window that appears actually lives in the desktop+taskbar process, not the process that owns the other shell windows.  And every time you create a rooted Explorer window with the /root, command line option (a.k.a., “Explore from here”), it gets its own, brand-new process.  The real purpose behind the setting is to make it possible to isolate Explorer windows from the desktop+taskbar, so that if a bad shell extension is loaded which crashes or hangs an Explorer window, it is less likely to affect the desktop and the taskbar.


How do I tell my admin windows from my normal windows?


Once you have IE and/or Explorer windows running in different security contexts, it becomes important to be able to tell them apart – particularly since in certain odd scenarios, a new window will actually run in a different security context from that which you intended.  As mentioned in my "RunAs" post, the easiest way is to run TweakUI as admin and change the admin’s background bitmaps for IE and for Explorer.  (This bitmap works nicely.)


However, in an upcoming post I will show you how you can temporarily elevate your normal User account for admin tasks.  You could then have two Explorer windows running as the same user, one with normal User privileges and one with admin privileges.  Since the background bitmaps are associated with a user account, rather than a privilege level, they won’t help you tell them apart!  I’ll also present a solution for that.


Comments (178)
  1. Steve says:

    This is the best blog ever. I have tried and failed to run as non admin for years. Now using your tips its practical. I admit since I use windows 2003 server as my desktop I also have a WTS session open as admin, but I find I am using it less and less. With your latest tip in explorer one of my last reasons to have WTS will have gone! Great work. I wish MS had done it years ago though.

  2. Steve – thanks. But if you’re using Server 2003 and can use remote desktop (terminal services) for multiple simultaneous security contexts, you’re actually much better off for several reasons: First, the Windows desktop – and Explorer in particular – was not designed with support for multiple security contexts in mind, so "odd things" will happen from time to time. Also, the Windows desktop is kind of its own security boundary – anything can send messages to any other window on the same desktop. If the target window is running in an elevated context, it can be very easy for an unprivileged caller to run code at an elevated priv level through the target window. This is the basis of so-called "shatter" attacks, and why it can be very dangerous for system services to host windows on the interactive desktop.

    If I could use Remote Desktop on XP to connect back to the same XP box in a different security context, I would probably use RunAs much less often.

  3. Marty says:

    Is there any way to use RunAs with Explorer to remotely connect to Scheduled Tasks on another machine?

  4. Marty – very interesting question. I assume you need RunAs because you need a different account from the one you’re logged in under?

    You can use RunAs, but it’s probably easier to NET USE instead. First, this is the basic Explorer command I would use for all the below examples:

    explorer /e,/root,\servername

    Then browse to "Scheduled Tasks" from the Folders toolbar. If you want to skip that extra step of starting at the server root and instead browse directly to the remote Scheduled Tasks folder, you can use this command line:

    explorer /e,/root,\servername::{D6277990-4C6A-11CF-8D87-00AA0060F5BF}

    Now, in order to get the necessary remote access permissions if you don’t already have them, there are three ways I can think of:

    1. Just run the above command. You’ll get a dialog prompt for username/password. Enter them in the dialog.

    2. Do a NET USE ahead of time:

    NET USE \servername /u:domainusername *

    The * at the end says "prompt me for the password before attempting the connection. This saves waiting for the timeout using the wrong pwd. Then run the Explorer command.

    3. Use RUNAS /NETONLY:

    RUNAS /NETONLY /u:domainusername "explorer /e,/root,\servername"

    /NETONLY creates a new logon session with your existing token, but with the account you specify for all SSPI-based network access. Because Explorer needs to run in this new logon session instead of that of your desktop, you need to set the SeparateProcess flag for your *current* account to make this work.

  5. Michael Meyers-Jouan says:


    You mention that you will be addressing how to temporarily elevate your normal User account for admin tasks. PLEASE, PLEASE, PLEASE — as soon as you can!

    My biggest beef is installation and activation processes that require Admin privileges, but that also require that the User ID be the ID of the user who will be running the application later:

    Activating Microsoft Reader

    Installing Pocket PC apps where the installer requires Admin privileges, but the scheduling of the download via ActiveSync fails when using RunAs.

    The only solution I’ve been able to find so far is to log off my normal, Non-Admin account, log in as Admin, add the normal account to the Admins, log off as Admin, log in as the normal (now Admin) account, run the process, log off the normal account, hit Ctrl+Alt+Del to get the Windows Classic login dialogue so I can log in as Admin, remove the normal account from the Admin group, log off as Admin, and log back in to the normal (Non-Admin) account. Whew!

    Therefere, any procedure that can TEMPORARILY elevate my normal (Non-Admin) account to successfully complete installations and activations would be a HUGE benefit.

  6. How to quickly and temporarily give your non-admin account administrator privileges, without having to log out.

  7. Michael M-J — OK, it’s posted:

    Sorry for the delay. Thanks for your patience!

  8. Junior says:


    I really need a way of making the ncpa.cpl applet work with RunAs. We want to have delegated access to helpdesk personnel, so that they can disable/enable the network card on our servers. Their accounts are user level accounts. I’d like to write an encrypted script to run the ncpa.cpl applet with admin credentials.

    Is this possible?

    Thank you in advance.


  9. Martin Sauter says:

    Just what I was looking for! I was reading an article in a German computer magazine but they forgot to point out how to make the explorer work with runas.

    Thanks a lot!


  10. Junior – it might be easier and safer to make the helpdesk people members of the local "Network Configuration Operators" group. This granularly gives them the ability to configure network settings, without giving them the keys to the castle.

  11. Junior says:

    The group you mentioned is only available in Windows 2003. We’re running a Windows 2000 domain and I need to give the helpdesk operators access to change the network settings on DCs.

    Is there a way to get this to work?

  12. Aaron Margosis is a Microsoft employee who is writing a weblog on running Windows with least privilege on the desktop. If you are having trouble running applications under an account with less privileges than administrator, there are many useful suggestions…

  13. MBA says:

    Helpful For MBA Fans.

  14. Anonymous says:

    Eric Johansen Malware Research » A Cure for your IE Blues?

  15. Complete list of Aaron Margosis’ non-admin / least privilege posts, for easy lookup.

  16. As I prepare for an upcoming talk at Tech-Ed 2005 on Least Privilege for Developers, it’s worth reviewing…

  17. tonyso says:

    Get your friends and family, all those folks that come to you for computer help once their machines have…

  18. Josh says:

    found this by mistake, and have always been wondering how to do what you talk about. MUCH THANKS!!!!!!!!!!!!!!!!!

  19. Josh says:

    I do have a couple questions.

    1) Through the internet explorer route, you can get into Control Panel but lets say you want to change someone’s background. I couldn’t get it to work. Lets say you want to change a file association, you can’t because your now running as an admin. I’ve found a work-around for this, just open the image in IE and use set as background.

    2) Is it possible to be logged in as a normal user and use the runas command like you have indicated but also be able to change file associations?



  20. Josh-

    Re background: Why not just set the background while running as the regular user? That’s not a privileged operation, so RunAs would just get in the way.

    File association is completely different – file associations are global to the computer (stored in HKCR –> HKLMSoftwareClasses). You need to run Explorer as admin (or IE as admin then browse to the file system) to get to Tools / Folder Options so that you can set those.

  21. Marco says:

    and it works with the password encrypt tool Runasspc.



  22. OK, the last entry was a teaser for a blog entry or two on what developers can and IMHO should do regarding…

  23. Scott Crawford says:

    Thanks much for the service you’re doing for the community. I’m a sys admin for a small school and for several years we’ve not allowed our users to run as anything other than normal users, but this year we’ve started forcing our IT staff to do the same, albeit they have access to an admin account.

    ANYWAY…the problem I’m having that I don’t see mentioned anywhere is that when running explorer with alternate credentials, there is no longer an automatic refresh. For instance if I delete a file, it will still show in the explorer window until I hit F5. Similarly, when copying a file to an explorer window, the new file doesn’t show up until F5.

    Granted, this is only a nuisance with a simple workaround, but it gets rather aggravating when browsing files. Is anyone else seeing this? And if not, any ideas why we are? We running XP SP2 with all the patches and its happened for everyone so far.


  24. As you probably know from my old posts, I log into my Windows computers with a normal user account (I’m…

  25. As you probably know from my old posts, I log into my Windows computers with a normal user account (I’m…

  26. As you probably know from my old posts, I log into my Windows computers with a normal user account (I’m…

  27. cheeze says:

    I noticed that "start iexplore" seems to resolve IE’s path. Easy to remember and launch.

    Thanks for the good info.

  28. Marc Denton says:

    Just like Scott Crawford I’m experiensing the same problem with refreshing te explorer window when run with diffrent credentials.

    Ik there is a workarourond for that problem I would like to know what it is…

    Very helpfull blog by the way.

  29. Pascal Roy says:

    Juste like Scott Crawford and Marc Denton, I’m experiencing the same "Explorer not automatically refreshing" problem and telling customers to remember to hit F5… If anyone finds a solution to this, posting it here would be greatly appreciated.

  30. Thomas says:

    Hi, After stumbling on this article, i tried your suggestions with success, but i noticed that everytime i start an (i)explorer via my admin-cmdshell, the folders for cookies, temp internet files and history are created, not in the admin’s profile path, but inside the temp folder!

    Any ideas why?

  31. Marcel says:

    I am very interested in this RUNAS trick. I use RunAs very often from within encrypted VBScript to allow my mobile users to attempt certain tasks. The trick for IE with shell namespace folders doesn’t seem to work with me.

    I have realised the same exact options as mentioned:

    C:>ie.cmd ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}::{21EC2020-3AEA-1069-A2DD-08002B30309D}::{7007ACC7-3202-11D1-AAD2-00805FC1270E}

    However when run from command-line, IE starts but with error:


    Cannot find file:

    file:///::%7B20D04FE0-3AEA-1069-A2D8-08002B30309D%7D::%7B21EC2020-3AEA-1069-A2DD-08002B30309D%7D::%7B7007ACC7-3202-11D1-AAD2-00805FC1270E%7D. Internet address incorrect.


    somehow the ‘{‘-character gets transformed into %7B and the ‘}’-character gets transformed into %7D.

    Any idea why? Has this something to do with character page?

  32. Guillaume says:

    I have this setting in both my user and admin profiles :



    It will create one Explorer.exe for the shell and another one for everything else. If you set this flag it will behave just like the "separate process", but will be usable when you do log interactively as an admin.

    You gessed it, I have little memory on some machines !

  33. Guillaume, from what I’m told, DesktopProcess really doesn’t do anything different from SeparateProcess. SeparateProcess is recommended.

  34. MikeL says:

    Why not just rename explorer.exe to xplorer.exe, or something similar? That is how I publish folders, etc through Citrix and it works fine. Rename explorer.exe to whatever, then launch that. Any reason that won’t work?

  35. Romain says:


    Good article, really!

    However, I have noticed that in IE7 Beta 1, it is not possible (well, in fact I didn’t find out how to…) to "run as" iexplore, and then type "C:" in the address bar to view local folders in Administrator mode.

    As you said, this tip works fine with IE6 (I was using it before), but with IE7, a new window is created, and it runs in the current user’s context, not in the administrator’s context.

    I think this kind of issue will be removed in later releases… I hope so.

  36. yecril says:

    Romain: It seems this change is a deliberate security patch. I hope it will stay. Using Internet Explorer as Computer Explorer is an abuse anyhow. The two guys should be split.

  37. Martin O' Donnell says:

    The Explorer refresh problem is really the most irritating thing I have encountered about running as non-admin. Is there any hope for a reg hack or patch to resolve this? Can anyone even explain why exactly this happens? Aaron, very grateful for your work, indispensable source of information.

  38. jib says:

    Not a fix or anything, but other programs like the excellent Total Commander works very good with RunAs. Total Commander even displays its current user context in the main window title.

  39. Tom Holden says:

    Just a note but for those of you that are using runas on iexplore (either through command prompt or through right click)…. you are going to hate IE7, if you attempt to browse a file area (i.e. not a web page) then it spawns a new explorer window looking at that location.

    And if you are running IE7 as your admin account and do the same then you will find that the newly spawned window isn’t running under your admin account any longer but has dropped down to the currently logged on users permissions! So once Vista comes along (and probably just XP next year) you are going to be stuffed without taking this chaps advice.

    And that is why I had to find this web page yesterday… and a bloody good find it is too! Cracking stuff. Thankyou.

  40. badri says:

    Oddly enough i always used RunAs with IE, but recently found out that just a /separate switch with launches explorer in a seperate process with using Lauch as seperate process set

    runas /user:Username "explorer /separate,c:PathToDir"

  41. Romain & Tom Holden:  I just got confirmation that by design IE7 on XP will no longer browse the file system.  If you try to, it will send a DDE message to Explorer, which opens a new window in the current user context.

  42. flipdoubt says:

    None of these tips work for me on a ThinkPad T43 with XP Pro SP2.

    I get a silly runtime error when I try the /separate trick:

    Microsoft Visual C++ Runtime Library

    Runtime Error!

    This application has requested the Runtime to terminate in an unusual way.

    Using Aaron’s ie.cmd works without runas, but with runsas results in the same message described above.

  43. flipdoubt – That may be coming from a toolbar or BHO.  Try disabling extensions like Adobe, MSN, Yahoo, etc. and see if the problem goes away.  If you are comfortable with SysInternals’ Process Explorer, take a look at the call stack generating that error message and see if it points to a particular DLL.

  44. Martin O' Donnell says:


    I realise this is a presumtuous request but no harm in asking, right? You’re a software developer and you have an unrivaled understanding of LUA on MS operating systems and the OS infrastructure. Do you think you could write something that would make Windows Explorer automatically refresh when running in profiles other than the currently logged in user?

  45. OAS says:

    Aaron, You save my brain from eruption !

    You are a genius, continue !!!



  46. Hugo Bonilla says:

    Since I can fulfil a scrips with Run seize in which(whom) it(he,she) includes the user and the password in the same Scrips

  47. Hugo Bonilla says:

    Since I can realize a scrips with RunAs in which it includes the user and the password in the same Scrips

  48. Hugo Bonilla – if the question is, "Can I write a script that uses RunAs and gives it the password to use," the answer is no.  RunAs accepts passwords only from the keyboard.  It was designed this way to help people avoid the unsafe practice of putting passwords in script files.

  49. Qingzi Bu says:

    Rahh! I can’t believe the IE team decided IE7 isn’t going to let me browse local directories (under the correct user context)!

    The option #2 as you say, works because of a mere unintended side effect. There’s no telling when they might decide to ‘fix’ it, too!

    *mumble mumble* It’s better that IE and explorer are now separate you say?  *mumble mumble* But but… aww damn you for being right.

  50. A systematic approach for working around LUA bugs that avoids unnecessary exposure – "the rest of the story"

  51. PaulL says:

    Having recently implemented the secondary account principle across my IT support organisation, I’ve found this information invaluable.

    One of the tech support team came up with this tip for adding a "OpenExplorerAsAdmin" option to the Limited User’s context menu in Explorer.  This allows you to find a folder you need to manage, right-click, fill in your password for your admin account, and bingo! an elevated Explorer opens. Combined with Privbar, the whole thing becomes straight foward…

    Modify the text below (inserting your admin user details, save as a .reg file, and import into your workstation’s Registry…

    —-  reg file starts here  —

        Windows Registry Editor Version 5.00


        @="Open An Explorer Window as Admin User"


       @="runas.exe /user:DOMAINADMINUSER  "explorer.exe  /SEPARATE,%L""

    —-  reg file ends here  —

    As a further tip, we use the same username for the secondary account as the user has for the primary account, but with a "!" prefix. This allows me to create standardised "admin" cmd files or shortcuts for the team, using %UserDomain%!%UserName% variables; the team can use the shortcuts without modification.

  52. Martin O' Donnell says:

    I’m aware that there are security issues with using the /savecred switch with runas because the credentials are essentially saved for the runas command rather than the specific shortcut or exe that one would intend, which means the saved credentials can then be manipulated to run any shortcut or exe on the system, but can anyone tell me how the credentials are saved? i.e. is there any encryption involved? Is the password hashed in the registry or is it just stored as plain text?

  53. Martin O’Donnell:  The password is stored in the credentials manager, encrypted with a DPAPI key (which is based indirectly on your own account password).  It remains there until you remove it.  You can also lose access to it if your account password is reset (as opposed to changed).

    You can "unsave" it by going to the "Stored User Names and Passwords" UI, selecting the account and removing its password.  To get to that UI, run the following command:

    "%windir%system32rundll32.exe" shell32.dll,Control_RunDLL keymgr.dll

  54. Tom says:

    It’s a good idea to use the variable %programfiles% instead of c:program files so that you get a path to the correct folder regardless of which drive it is on.

    This is mainly for instances where you are creating batches for many computers to run.

  55. Tom – good advice.  Is there a violation here that I hadn’t noticed?

  56. Martin O' Donnell says:

    Hopefully someone can help me with this. I’m trying to create a reg file very similar to the one described by PaulL but it modifies HKEY CURRENT USER instead of HKEY LOCAL MACHINE. I also want the reg file to find the current %username% and append the letter "a" to the end of it to run explorer in the admin user’s context. I’ve found the following syntax works fine from a command prompt :

    runas.exe /user:domain%username%"a" "explorer.exe  /SEPARATE ,%L"

    It requests the password for the admin account e.g. usera and then it runs explorer in a separate process exactly as I want. But if I use this syntax in the reg file and then try to browse a folder as admin, it requests the password for usernamea instead. Can someone tell me how I can make the registry find the %username% value or is there some other way I can achieve this?

    PaulL thanks for that reg file, very useful.

  57. entity says:

    RunAs with Explorer works fine with me. My final problem is to prevent users from typing commands in the address bar and run them as administrator.

    Is there a way to call explorer.exe and hide the address bar, navigation bar and menu bar?

    Thanks for any reply.

  58. entity – Why do you need to give untrusted users an Explorer running as admin?  There are all kinds of things they could do from there.

  59. tekNerd says:

    Actually I was looking for an explanation why WIN+E doesn’t start explorer in a separate process.

    I see that this is normal behavior and is nothing wrong with my windows.


    Peace out!

  60. entity says:

    Aaron – My intension was to run explorer.exe using admin permissions calling "Network Connections" directly. This is primarily for non-privileged roaming users who need to change NIC-Settings (speed, etc.) depending on their location. Members of the "Network Configuration Operators" group do not have the right to change hardware-settings. To prevent users from running other stuff from this particular explorer.exe-instance i thought about hiding ‘address bar’, ‘navigation bar’ and ‘menu bar’.Any hint to make this work? Thanks!

  61. entity — it’s not clear to me 1) how you’re getting them the admin window in the first place, or 2) exactly what it is they’d need to change – don’t NICs/drivers usually determine speed fine by themselves?

    But assuming those two items are resolved:  is it something that could be accomplished with netsh scripts instead?  There’s a lot less trouble you can do with netsh than with Explorer.

  62. Ajay says:

    XP Home doesn’t have the "Local Users and Groups" option under Control Panel->Adminstrative Tools->Computer Management.  Is there another way to make an LUA account on an XP Home installation a member of the "Network Configuration Operators" group?  This is on a laptap that needs to be able to repair the wireless network connection when needed.

  63. Ajay says:

    My workaround is using what you describe in this article to open the Network Connections and repair it that way.  Until reading these comments I wasn’t even aware that the Network Config Operators group existed and it sounds like a much more convenient way to do what I need.  Keep up the excellent work Aaron!

  64. Ajay – I don’t have a Home Edition box handy at the moment.  I don’t know for certain whether this would work, but I think it would – run the following from a CMD prompt running as admin:

    net localgroup "Network Configuration Operators" %COMPUTERNAME%account /ADD

    That should be on one line, of course, and "account" should be replaced with the name of the user account you want to add.  If there is a space in the name, then put quotation marks around %COMPUTERNAME%account.

    HTH, and thanks for the kind words.

  65. Ajay says:

    It looks like the "Network Configuration Operators" group doesn’t exist on XP Home.  I typed:

    net localgroup

    just to see what groups exist and the list came back.





    Doing the same on my XP Pro desktop shows a much longer list of groups including the Network Config Operators.  Thanks for the suggestion, I’ll do a Google search to see if there is a way to add that group to XP Home

  66. Ajay – Don’t bother searching – if the group isn’t defined, then the objects that are ACLed for NCO on XP Pro won’t be ACLed so on XP Home.  Adding the group won’t have any meaning on Home.

  67. Ajay says:

    Thank for your help on this.

  68. Larry says:

    Does anyone know why the following behavior occurs?  We have RUNAS disallowed in a user lockdown (Software Restrictions) – both the path and the hash.  

    Anyway, if you ran RUNAS from the Run command it fails.  But, if you click on Start/Programs an then right click on IE you can run “RUN AS”.  Does anyone know what causes this to work?

    Thank you.


    Larry, what exactly are you disabling through SRP?  Are you disabling RUNAS.EXE?  The dialog interface doesn’t use RUNAS.EXE.  — Aaron
  69. Larry says:

    Aaron – In the software restrictions policy I am using c:windowssystem32runas.exe.  Am I incorrect?  If so, what does the dialog interface use?  Thanks very much.


    RUNAS.EXE is a console application.  The dialog interface just runs within Explorer.exe.  There might be a supportable policy-based way to remove it from the interface, but off the top of my head I can’t say for certain.  You can disable the Secondary Logon service.  That will prevent use of other accounts, but should still allow the use of the “Run As…” dialog with the “protect my computer” option.

    Out of curiosity, why do you want to block the use of RunAs?

    — Aaron

  70. Larry says:


    We want a user to be able to do work in a limited fashion and keep him or her from dropping the file anywhere but in their local profile.  Data in the profile will only be accessible using this account and prevents other accounts from getting to the data.  Doing this is one of about 10 steps we have in place to safeguard sensitive info.

    Thanks very much for the great feedback.


    Assuming all users running as LUA, the primary defense has to be the prevention of User A from getting User B’s credentials or accessing User B’s desktop while User B is logged on.  Use of hardware tokens and/or user education re strong passphrases will be much more powerful than preventing RunAs.  RunAs shouldn’t even be a real risk.  Note that if User A has User B’s password but no RunAs, User A can simply log on to the computer as User B…


    — Aaron

  71. McoreD says:

    Many thanks for Option 2.  Set the flag that allows explorer.exe to work with RunAs

    I’ve been doing it in Option 1:

    runas /user:administrator ""%programfiles%Internet Exploreriexplore.exe" E:\"

    which restricted me using IE7. Now I can use IE7. 🙂

  72. Les says:

    Where can I find the GUID for other things like the scheduled tasks in the post’s example? Is this something you’ve just ‘picked-up’ over the years or is there a library on Technet?

    Les:  the identifier for Scheduled Tasks is


    (BTW, this is already in the collection of scripts referenced in the post.)  They might be publicly documented somewhere.  The way I found them is by right-clicking on them in Explorer and choosing “Explore from here” after installing that little trick into the registry.  Then the address bar shows the namespace identifier instead of “Scheduled Tasks”.  Again, this is most likely a side effect of implementation, rather than by intentional design.

    Add this to the registry to get “Explore From Here”:

    Windows Registry Editor Version 5.00

    @=”Explore From Here”

    @=”Explorer.exe /e,/root,/idlist,%I”


    — Aaron

  73. TerDale says:

    @Les: you can find a reference for such GUIDs at:


    @Aaron: thanks for the "Explore from here" tip, still really fruitful to monitor all your posts! 😉

  74. dolf vm says:

    After absorbing and applying this very useful blog (thanks Aaron!), I cannot resolve a probably minor but very annoying problem. Already addressed by some others but there was no reaction to it yet.

    Using explorer with administrative rights in the way you explained, does the job just right except one thing. Explorer doesn’t refresh. So I have to press F5 after each action (and then scroll back to the place I came from). That can become very cumbersome when I have a lot of filemanaging to do. Of course I refuse to login to admin as stubbern as I am.

    Is there a solution or at least an explanation to this problem? To me it feels like a bug because it seems that explorer just sends it’s refresh event to the user’s original explorer process in stead of the process from where the filehanding was done. I tried the separateprocess flag as well as using the /separator switch and even MakeMeAdmin (the c’t magazine version) but the result is the same.

    So theoretically I could think of a solution: first a new explorer process must me launched from the original user with the original limited rights, using the /separate switch so that a real new process is lauched (which isn’t the case using the flag as I can see with the taskmanager). Then that process’ rights should be altered using a program that is run with administrative rights of course. I have no idea if Windows has such a possibility of altering a process’ rights without killing it first. Moreover, I am not able to write such a program (in the first coming 10 years or so).

    Hopefully someone found a simpler solution or workaround.

    The idea of Explorer running in multiple simultaneous security contexts was not considered in the design of Explorer.  What you’re seeing is another side effect of that (like the fact that getting multiple simultaneous contexts doesn’t happen easily).  Don’t forget that Explorer was originally designed to run on systems with as little as 4MB of RAM (yes, 8MB was the lowest you’d want to go, but 4MB was within spec).

    The main Explorer process is the single collection point for capturing the change notification events.  It pushes that information to the processes that own other Explorer windows.  That “push” requires access to the process which is typically blocked when it’s in a different security context.  One could write code to run within all Explorer processes to open the access up, but that increases security risk.

    — Aaron

  75. dolf vm says:

    Thx Aaron, you cleared me up. Especially the fact that the event push fails due to the different security context makes sense.

    As do all your explanations on this blog. I wonder how many computers on this earth have become a safer place thanks to this blog. Lots I guess 🙂

    Working with limited rights is in fact the base of all protection. Which is a known fact for decades already and slowly MS starts to realize this. I ‘ve red that multi user functionality in Vista is more mature and that indeed the default security context for users is limited. At last!

    I also changed security of the autostart locations that can still be accessed by a LUA. Using the little program gavu.exe that came with the c’t MakeMeAdmin. So now I feel so safe that I almost feel the urge to disable all my malware scanners and firewall and surf around the most dangerous sites, downloading and opening all the suspicious files and attachments I can think of. Just to see how much harm can be done apart from messing up my LUA itself.

    with regards,

  76. Martin O' Donnell says:

    It seems a shame that Microsoft can offer no solution to the auto-refresh problem. Many organisations would use the secondary logon service with windows explorer to mitigate the risk of accidentally deleting or corrupting critical or restricted data. This flaw actually increases that risk rather than reducing it. There must be a secure way of accomplishing auto-refresh with Windows Explorer, many third party companies provide file manager applications that work fine under the secondary logon service and even display the current user context in the title bar (e.g. Total Commander It seems Microsoft are either unable to produce a file manager that is compatible with the secondary logon service, or else they are using XP flaws as Vista selling points.

    Martin O’ Donnell

    As I mentioned earlier, Explorer was designed with very different goals in mind from what we’re talking about here, and with very different constraints.  Clearly a file manager with that refresh capability can be built, but it would require significant rearchitecting to achieve this goal with Explorer on XP, and with high likelihood of application compatibility impact on all users — including the vast majority that never use secondary logon.  Remember also that Explorer is much more than just a file manager.

    — Aaron

  77. Martin O' Donnell says:

    I understand that Explorer was originally designed for systems with very limited memory and that the concept of multiple simultaneous security contexts had not yet emerged, but this just seems like another way of saying that it runs on an archaeic foundation that Microsoft never developed or restructured sufficently to provide compatibility with modern security principles and requirements. After all, it’s not like the secondary logon service was introduced post XP and hence we can’t expect compatibility with Explorer, they were packaged together in the same OS, they just don’t work properly together.

  78. Henrik Jensen says:

    re. the Refresh in Explorer

    The automatic refresh problem is not a specific Explorer problem. All applications that uses the CommonDialog component inherits this problem. Try doing a save as/open in any program that uses the standard CommonDialog component and, try to create a new folder in the dialog box. Nothing seems to happen until you’ve refreshed the Dialogbox, and now there’s a "New Folder" created. This is even true if you use the new WinForms classes in .NET VS2005. Just tested it. What a shame 🙁


  79. Don says:

    This method to launch another explorer instance with Admin level access has been very helpful and I’ve applied it on WinXP running IE7. However, is there a way for this to work on Vista as well? When I attempt it, I find that another process is loaded into memory (although I need to use an Admin account to display the second, elevated instance in Task Manager), however the window never displays on screen. This is the case whether my currently logged on account is a member of the local admins group on the machine or not.

  80. Ubirajara says:

    I’m another user that suffer with the refresh problem…

  81. Thank you for posting this! I’ve been using an LUA approach at work for a number of years (runas/iexplore.exe for admin tasks). After deploying IE7, this no longer worked as noted by other commenters and I felt like my right hand was whacked off. OK, that’s exaggerated, but you get the picture. Thanks to you, I am now using Windows Explorer for my administrative tasks.

  82. Adam Szofran says:

    Unfortunately, the RTM version of Vista doesn’t seem to allow explorer windows with different credentials to run on the same desktop, even with the "SeparateProcess" flag turned on.  You can use RUNAS to start another explorer window, but it only flashes on the screen briefly before being killed.

    Additionally, IE7 displays the message "The RUNAS command is not supported" if you try to RUNAS a different user.

    Does anyone know a workaround for either one of these?

  83. Chris King says:

    This works fine on XP:

    runas /user:domainuser “explorer /separate,\server01share$”

    but not on Vista. I can set up a command prompt to runas admin but that is local admin.

    Anyone get explorer to run in seperate process as different user on Vista??


    Chris King:  Not as far as I can tell.  I can get it to run non-elevated and elevated as a single user, but I haven’t found a way to have it running as different users on the same desktop.

    — Aaron

  84. tmf says:

    I have recently converted to using a non-admin account and this blog has been of great assistance.

    I do have a couple of problems though – I have successfully managed to run Windows Explorer as an Admin, however when right clicking on a folder that my non-admin account does not have access to and trying to use the Search function I get “Access is denied”.

    The other issue is when trying to lauch Word documents from my Administrator instance of Explorer I get an error message “Microsoft Office Word 11.0 – There is not enough memory or disk space to run Word.” When trying to open an Excel document nothing happens. I am able to open Text documents successfully.

    tmf:  interesting issues.  If you install PrivBar, you’ll see that when you right-click and choose Search, you get a new window running as the desktop user.  The current instance of Explorer does not directly launch the child window — I suspect that instead it’s broadcasting a DDE message that gets handled by the desktop instance of explorer.exe.  Instead of right-clicking and choosing Search, just open the “Search” Explorer Bar on the admin window.  Three ways to do that:  click on the “Search” button in the “standard buttons” toolbar; press Ctrl-E; or choose View / Explorer Bar / Search.  The search will then be performed by the admin explorer.exe.

    I’m not surprised that running Word or Excel in a different security context is problematic.  I suspect there’s a lot of interaction with the shell going on there.  I’m pretty sure it also won’t allow a second instance of the process to run if there is already an instance running on the desktop.  (Notepad is a much simpler little app and doesn’t have those issues.)  Can you instead just put the documents in a location where the non-admin account can access them?


    — Aaron

  85. Martin O' Donnell says:

    tmf, I have no problem launching Office apps from Explorer running in the admin context. I am running Word 2002 SP3. The error you have described often occurs for the default user due to a corruption of the file. This can be recreated by searching for and renaming the existing file then relaunching Word. This will also reset custom styles, custom toolbars, macros, and AutoText entries back to default settings. In you case I would recommend searching for the file, renaming it, then try launching a Word doc through Explorer running in the admin context, if it works, then try it as the default user. If that works, happy days! Otherwise you might consider a complete removal and reinstallation of Office.

  86. IE is definitely the most insecure gateway to a PC. So I was thinking: why not run it in a guest account…

  87. Michael O'Dell II says:


    I’ve been following your LUA articles here, and even printed out the whitepaper a while back, since I discovered them. Although I am using your MakeMeAdmin script, I actually run multiple different modified versions of it; one starts a cmd shell, the second starts the Control Panel directly, the third starts Microsoft Update directly, and the fourth starts Explorer directly. One interesting thing I’ve noticed is, if you set _Prog_ in the script to “explorer /root,%USERPROFILE%” (for example), it will run explorer as your user account in the Administrators group, but rooted at your admin account’s profile directory rather than your own.


    Michael [krylancelo(at)elitemail(dot)org]

    Michael – interesting observation!  The reason that happens is because at the time the _Prog_ and USERPROFILE variables are evaluated, you are running as the admin account.  If you really wanted, you could change the script so that _Prog_ is evaluated on the “first pass” and passed as an arg to the “second pass” (along with %_User_%).  Managing quoting correctly would certainly be a bit of an exercise!

    — Aaron

  88. Michael O'Dell II says:

    Aaron: I might try playing with that idea; I have done a bit with cmd scripting in recent times already. On another note, I seem to be either stuck or caught on imagination. In the past couple days, I remembered at one point getting one of my systems to allow me to run LUA and– for example– open My Documents from the Start Menu under the Users group, then run my Admin Explorer.cmd (your MakeMeAdmin script with “explorer /root,” as the _Prog_ value) to open Explorer at C: under the Administrators group, then run another Explorer instance without the cmd script (such as clicking My Computer on the Start Menu, or even “explorer /root,” from the Run dialog) and having it revert back to the original LUA-token process. After losing that and trying to get it to work again (for a whole day), I think I may have imagined it, as after that possible incident I’ve been able to get up to three separate explorer processes with their own tokens (started by Desktop/Taskbar, My Documents as LUA, C: as Admin). After that, I can’t open any more Explorer instances under the LUA token; only under the Admin token through Admin Explorer.cmd.

    Did I imagine it? Or maybe I’ve just been missing something that I happened to do that first time around.


    Michael [krylancelo(at)elitemail(dot)org]

    Michael — no, you probably didn’t imagine it.  It’s just that when you’ve got multiple simultaneous security contexts and you’re invoking stuff through the shell, things can be a little unpredictable.  Windows and a lot of apps use DDE (dynamic data exchange) a lot.  So, an app will broadcast a DDE message to find a running server that can handle some request (e.g., to display a folder).  Other processes will get that request and determine whether they should respond affirmatively.  Once one does, it will handle the request.  When you have processes running in different security contexts, it’s basically impossible to predict whether an admin process will respond, or a regular user process.


    — Aaron

  89. Michael O'Dell II says:


    I’ve been playing with the Admin Shell script I modified from your MakeMeAdmin; I’ve tested what I have below and it seems to work (at least in the tests I’ve run), with the variables being evaluated on the first pass as you mentioned. Notice the cd command goes to %USERPROFILE%, as a means to easily check the evaluation time of the variables. I’m not a professional with such things, so there could very well be problems with the code or an easier way to do something I’ve done, but it works as far as I can tell. ;P


    Michael [krylancelo(at)elitemail(dot)org]

    @echo off


    set _Admin_=%COMPUTERNAME%Administrator


    set _Group_=Administrators

    set _Prog_=cmd.exe /k Title *** %_User_% as Administrator *** ^^^&^^^& cd %USERPROFILE% ^^^&^^^& color 43

    if “%1″==”” (

    runas /u:”%_Admin_%” “%~s0 “%_User_%” “%_Group_%” “%_Prog_%””

    if ERRORLEVEL 1 echo. && pause

    ) else (

    echo Adding user %1 to group %2…

    net localgroup “%2” “%1” /ADD

    if ERRORLEVEL 1 echo. && pause


    echo Starting program in new logon session…

    runas /u:%1 %3

    if ERRORLEVEL 1 echo. && pause


    echo Removing user %1 from group %2…

    net localgroup “%2” “%1” /DELETE

    if ERRORLEVEL 1 echo. && pause



    Michael — I thought about it some more and came up with a much simpler solution.  Just change the “set _Prog_” line to the following — doubling up on the % symbols:

    set _Prog_=”cmd.exe /k Title *** %* as Admin *** && cd %%USERPROFILE%% && color 4F”

    So instead of evaluating %USERPROFILE% while running as the local admin, it will put “cd %USERPROFILE%” on the cmd.exe command line.  %USERPROFILE% will then be evaluated by the target process, running as the regular-user-as-admin.


    — Aaron

  90. Michael O'Dell II says:

    Okay, there must be something wrong with my laptop. I’m running both my desktop and laptop as LUA under Windows XP Pro SP2 with my modified MakeMeAdmin scripts (I’ll limit this post to the Admin-level Control Panel launcher). Both systems have PrivBar installed and setup, both systems have the separate-processes flag set for Administrator and my user account. When I launch Admin Control.cmd on the desktop, it asks for the two passwords and launches an Admin-level Control Panel session. When I launch the same script on the laptop, it asks for the two passwords and launches a /User-level/ Control Panel session. I’ve added some extra ‘pause’ commands to the laptop’s script, so I can watch it as it progresses, and everything looks fine. I’ve even opened up the Computer Management window and checked on my user account’s Member Of tab at each relative interval– at the start of the script, after addition to the Administrators group, after the CP session has been launched, and after removal from the Administrators group. At the start of the script, my account is only in the Users group; after the script adds me to Administrators, the management console shows membership to both; after launching the CP session, I’m still a member of both; after removal from Administrators, it drops back down to just Users. I’m at a loss as to why I can launch my admin scripts properly on one system and not the other, when there’s no difference in the configurations of the systems.

    I know you said that the separate-process flags are set on both systems, but that’s what it sounds like — missing the separate-process flag for your regular user account.  Also, how are you starting Control Panel?  Instead of using Control.exe as your command line, see whether this works better:

    explorer /root,::{20D04FE0-3AEA-1069-A2D8-08002B30309D}::{21EC2020-3AEA-1069-A2DD-08002B30309D}


    — Aaron

  91. Michael O'Dell II says:


    Hm… Well, that explorer line did cause the script to start running the Control Panel properly (as an Administrator); however, my Admin Explorer still seems to not want to create its own process/token pair. The _Prog_ is set to “explorer /root,” and it adds and removes my account from the Administrators group properly; but the resulting Explorer window does not generate its own process/token set, nor does PrivBar say the window is running with an Administrators-group token.

    I did solve the Admin Explorer problem in the same way; your use of the {…} tags reminded me of some Keys I’d seen in the Registry, so I looked them up to find that the first one in that line was My Computer. By setting the _Prog_ to “explorer /root,::{20D04FE0-3AEA-1069-A2D8-08002B30309D}” (just My Computer, without the ::{…} Control Panel addition) I was able to get it to start an Admin explorer session rooted at My Computer.

    One question still remains; why do I have to do this on my laptop to get these scripts working, while on my desktop they work with _Prog_ set to just “explorer” and “control”?


    Michael [krylancelo(at)elitemail(dot)org]

    For more examples of starting explorer with namespace GUIDs, see the “handful of .cmd command script files” referenced in the post above.

    I don’t have a ready answer for your last question, though.  Most likely a configuration difference, but hard to tell from here.

    — Aaron 

  92. Royce says:

    I used this extensively over the last few years and worked flawless.  Even created shortcut to IE w/in the IE directory and set the shortcut to always prompt for credentials, then created a corresponding apppaths key (HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths) for iexplore2 so I could just go Start-Run-iexplore2 and it would prompt for credentials.

    However, since upgrading to IE7, I can’t get this to work.  When I put in a drive or network path in the address bar, it simply opens up another explorer window with my regular acct’s reduced permissions.  What gives?  Any workarounds or alternative solutions????


    Royce:  IE7 has been “dis-integrated” from Windows Explorer, and will not browse the file system.  If you enter a file system path in the address bar, IE7 will send a DDE message to the shell, which will then open a new Explorer window in the desktop context.

    The “separate process” method described above (Option 2) still works fine, though.  (The bummer for me is that on XP it no longer works with the “protect my computer” option.  On Vista, it runs in Low IL “protected mode”, though, which is very good.)


    — Aaron

  93. Katherine says:

    I am trying to find a solution to an admin problem we are having using the Volume Shadow copies to restore files.  We use the best practise of logging in with a non admin account and using runas with an admin account.  When we run windows explorer using run as and try to view the previous versions snapshots we just get an error saying it does not exist.  If we use IE6 it works fine, IE7 of course does not as it launchs as the normal user account.

    We know the admin account has rights to access everything as if we log on to the PC with this account it works fine.  We are trying to resolve this problem so that we can delegate the restore jobs to other support teams, any one got any ideas?

    Katherine – a few questions:

    1. Does the shadow copy UI not appear for the non-admin user?  It should be available for non-admins.
    2. What is the mechanism and/or command line you’re using to get the admin Explorer window?
    3. Is the SeparateProcess flag set in the profile of the target [admin] account (as described in this blog post)?
    4. How are you confirming the security context of the admin Explorer window?  (E.g., PrivBar?)
    5. Is the result different if you use an Explorer window started from a MakeMeAdmin prompt?  (Note:  you need to set the SeparateProcess flag for your non-admin account.)


    — Aaron

  94. Katherine says:

    Aaron in answer to your questions:

    1. The shadow copy UI appears for any user who has permissions on that folder.  The UI only fails to appear when we try runas on explorer.

    2.The command we use is a simple runas command as follows to open windows explorer using our administrative account. “runas /user:domainadminusername explorer.exe” a command prompt window appears asking for the account password and when entered windows explorer opens.

    3.I believe so, I can use runas with windows explorer and it works, I followed the instructions in the blog to run internet explorer as the admin account and the box is ticked.

    4.We don’t use anything like the privbar, we know which account explorer is running as by the level of access we have to shared files and folders etc.  Our day to day normal account has no admin access to shared folders, we must use the admin account to access these.  You can tell quite quickly if you are not running it with your admin account as you can not access the folders you need to complete the task.

    5.When I try the makemeadmin and run explorer.exe from the command prompt that it launchs I can view the volume shadow copies, so it works.  The only thing with this is that the groups details I choose to add my normal account to is a domain local group and not the local administrators group of my machine. The people we want to delegate this job to will not have the rights to amend this group to add their own accounts in to the group membership.  This is an excellent tool for those of us with more rights to be able to use but doesn’t quite solve the problem of being able to delegate it just yet.  

    Can you tell me whether there is anyway to ensure that when the windows are closed the account is removed from the group it has been added into, when I checked the group in AD users and computers my account does not show as being a member, so we would have no way of tracking people using this tool and adding themselves to groups, is this right?

    Thanks for the help so far, I will definitely be recommending the makemeadmin tool for the rest of my team, think the solution to the delegation problem is getting closer!

    Katherine — the response I’ve gotten to this is that Explorer was never tested with RunAs and is not really supported.  All kinds of strange and unexpected things can happen when used that way.  You might be able to get some things to work, but (as I alluded in my post) that’s just a happy accident.  (I don’t have an environment set up where I can experiment with your scenario, else I would try to dig in deeper.)

    — Aaron

  95. LAR says:

    Great blog…Don’t know if anyone has mentioned it but is there anything wrong with using \$ to run explorer as admin?  And, how do you run explorer as admin in Vista?


    Not sure what good it does to browse \$ — you have to be running as an admin to see that share.

    I haven’t experimented with it a lot on Vista yet, but starting Explorer from an elevated command prompt seems to work if you supply a path.  E.g.,
            explorer c:
    If the “Launch folder windows in a separate process” option is enabled, supplying a path doesn’t seem to be needed.

    PrivBar works with IE and Explorer on Vista, and will show you the privilege level at which the window is running.


    — Aaron

  96. LAR says:

    Thanks for the tip on Vista.  I guess my only point about browsing to the share is if you are running under the context of a regular user and try to open the share you will get prompted for an admin’s user/password.

  97. Chet says:

    Am I missing something? “Launch folder windows in a separate process” is enabled for every account on my Vista machine, but I can’t get an Explorer window via a runas (or an elevated command prompt). The command appears to be ignored. I use this trick every day on XP; I’m not sure I can function without it.

    Chet, I don’t know — what I described above works for me.  Can you elaborate on “the command appears to be ignored” — which command, and how does it seem to be ignored?  If a window is appearing, how are you determining what security context it is in?  (E.g., PrivBar, Process Explorer, …?)

    Also:  runas.exe can start a program in a different security context, but it won’t be elevated.  E.g., if you’re running as a Standard User and use runas.exe to start something with an admin account, it will run with the admin account but with its “filtered” token.  You can’t get the elevated token without going through the elevation UI.


    — Aaron

  98. Chet says:

    Wow, thank you so much for the quick reply. Here’s my unfortunate situation…

    Vista Enterprise, load just a few hours old. Two users: “Setup” (member of Administrators) and “Chet” (standard user).

    Logged in as Setup, opened Computer, Tools / Folder Options – View, checked Launch folder windows in a separate process. Logged out.

    Logged in as Chet, opened a command prompt.

    runas /user:Setup “notepad.exe C:Windowssystem32driversetchosts.” — enter password, Notepad opens the hosts file.

    runas /user:Setup “explorer.exe /root,C:Users” — enter password, I see the “Attempting to start” message, and then the command prompt, but no Explorer window ever opens.

    runas /user:Setup cmd.exe, then from that prompt, explorer.exe /root,C:Users — no Explorer window.

    Thinking I’d buggered my machine, I loaded a second one and got the same results. Neither machine is (yet) on a domain.

    Chet — OK, this is an interesting issue.  The shell team did not want to support this kind of use of Explorer, and so made a significant effort not to allow it to happen.  What I found earlier was that if you’re logged on as a member of Administrators, it turns out to be pretty easy to run instances of Explorer both in unelevated and elevated contexts.  However, what you describe appears to be the case as well:  if you’re logged on as one user, I haven’t found a way to run an instance of Explorer as a different user.  (Also note what I said about runas.exe not giving you full admin permissions — you might be able to open the hosts file with Notepad that way, but you shouldn’t be able to write changes to it.  For that matter, all Users can read the hosts file.)


    — Aaron

  99. Matt says:

    I have run into the same thing.  I can log in with my normal user (domain) account, launch an elevated command prompt with a domain admin accout (the command prompt does inherit all rights of the domain admin account), then launch explorer.  The explorer window may or may not have a local admin token, but I don’t really care.  What I need from this alternate explorer instance is access to files, etc. that only the admin account, and not my normal user account, has access to.  UAC works great to protect the machine, which is nice, but what I am far more concerned about is my privileged IT users logging in and running IE and Outlook with accounts that have elevated access to netowrk resources.  Runas with explorer in XP seemed to solve this problem, but with Vista I am stuck.

    Matt:  RunAs with Explorer has always been kind of risky on XP — especially if you aren’t also using PrivBar so you can really tell which window is running as which user — behavior is at best non-deterministic.  An option you have now that you didn’t have on XP (domain-joined, at least) is that now Fast User Switching is always available — if you need an Explorer instance running as another user, you can Switch User to that user, with better isolation between apps running as different users.  Another thing I should point out is that even if your users are members of Administrators, Outlook will still run with standard user privileges (as will most things), and IE in Protected Mode will run with even lower privileges than that.


    — Aaron

    Matt:  Just re-read the post — your “privileged IT users logging in and running IE and Outlook with accounts that have elevated access to network resources…”  I assume you’re referring to people who are domain admins?  Is it feasible in your environment for those users to have their standard accounts for email, etc., and separate domain admin accounts for doing administrative tasks?

    — Aaron

  100. Chet says:

    Aaron — what Matt’s asking for, and what you’ve suggested, is exactly what Vista has taken away. I don’t want to be logged into my desktop as a domain admin all day, but I do need to occasionally do things that require Explorer (or IE) to run under my domain admin account (because you can’t do everything through MMC). Fast User Switching is a step backwards from what some of us are doing now — doing different tasks with different credentials from one desktop. It’s the network equivalent of UAC. Maybe it was an unintended feature in XP, but I’d hoped that it would have been embraced by Vista rather than branded as misbehavior and squashed. I suppose we have the industry’s glacial adoption of LUA in general to blame for that. I just hope the idea isn’t completely dead.

    This hits me especially hard, as I’ve been using launch-under-different-account to isolate imperfect applications for years — not because the app needed to be local admin, but because the user needed to be prohibited from having unrestricted desktop access to the network resources those apps require. Alas, more and more applications become "web-enabled" (i.e. Internet-Explorer-launched) to solve software deployment problems (!) without actually shoring up their security problems, and Microsoft has just taken away my best (and really only) way to secure them.

    Looks like I picked the wrong week to quit drinking. 🙂

  101. Matt says:

    Exactly Chet.  My domain admins, as well as a few others who have privileged domain accounts, log in with a standard user account to perform most tasks.  Using the combination of runas with Explorer and PrivBar, while not perfect by any means, is a lot more fast and efficient than using "Fast" user switching.

    My main point here being that UAC does nothing to protect network resources.  It only checks to see if the action I am performing is allowed due to membership of the local Administrators group.  If I am in the local administrators group of a server that has the default admin share enabled my account can still connect to \servernamec$windowssystem32 and do whatever I want there, unaffected by UAC on my Vista workstation, right?

    I have worked my way around this for now by using 2xExplorer instead(it works fine running as admin), but this doesn’t let me take advantage of the improvements made to Explorer in Vista, and I really don’t understand why MS wanted to get rid of this feature, unintended or not.

  102. cpetrich says:

    I’ve searched without success for an article to explain why the Runas context menu item may be missing…and consequently how to get it back…suggestions?


  103. Voy says:

    I agree with Matt and Chet – this appears to be a step backwards in Vista. We’re losing something we came to rely on for years. We used that feature to try to improve security. Vista took this feature away. How is that supposed to improve security?

  104. DDE Question says:

    Aaron, can you help me with this question:

    In Vista:

    I login as user1 and launch Internet Explorer.

    Then, I use runas to launch cmd.exe as user2.

    OK, so now as user2, at the command prompt, I type “whatever.htm”.

    That HTM file will launch as user1, NOT user2. This same thing happened to me in Windows XP.

    I restricted user2 with a GPO preventing just about every type of behavior, and it doesn’t matter, this type of crossover still occurs.

    I really want a way to solve this. I suspect it’s related to DDE, DCOM, or something. I want to restrict user2 so that I can run apps that can’t “crossover” to user1. I want the applications I run as user2 on my desktop, just not in any way able to access or run as user1.

    Thanks for any help you can give.

    On XP, you could get around this by starting the target process (iexplore.exe) directly.  If you executed a command line like “…iexplore.exe  whatever.htm”, you’d run iexplore.exe as User2 and it would open “whatever.htm”.  By specifying only the document name, you left it up to the shell to determine what should handle it.  It used DDE to find an appropriate server, and it found one in the existing iexplore.exe process.

    On Windows Vista, that command line won’t help you either.  Internet Explorer on Windows Vista specifically checks to see whether it is being executed as a different user, and refuses to run if that is the case.  (The reason is because IE communicates with a broker process — ieuser.exe — that runs as the interactive user.)

    Some apps will just work the way you’re describing, but others expect some amount of desktop integration, which typically implies a single security context.  What you need is to run the apps on separate desktops (e.g., Fast User Switching).

    Hope this helps.

    — Aaron

  105. maria says:


    is there any way of hidding “runas” in the context menu when right-click on any Application

    or shortcut. Or, at least, don’t displaying the username of the Administration account?


    Maria – there is no value in trying to hide the name of admin accounts on the system.  Anyone on the computer can enumerate the members of the admins group.  As long as the admins have strong passwords (or require smartcard logon), there should be no problem with usernames being exposed.

    — Aaron

    [update 2007-06-26]  That said, there is a Group Policy setting to disable the enumeration and display of administrative accounts in the credentials dialog.  It is in Computer ConfigurationAdministrative TemplatesWindows ComponentsCredential User Interface; the setting is “Enumerate administrator accounts on elevation”.  Set it to “Disabled” to get the behavior you’re requesting.  Another setting you may want to consider is the elevation prompt behavior for standard users — you can set this to “Automatically deny elevation requests” to prevent standard users from elevating at all.  It’s in Local Security Policy, Security Options, “User Account Control: Behavior of the elevation prompt for standard users”.


    — Aaron

  106. Interactive Desktop says:

    Hi Aaron, this is in response to your answer about 4 comments up regarding my question about file associations and Internet Explorer on the desktop. See here:

    Briefly, to sum it up, I want to prevent applications running as different users from communicating if they are running on the same desktop. I think this was pretty much impossible in XP, and I also think most people don’t realize this (thinking it’s safe to run malware as a “limited” user, when it is not). I had hoped there was some type of advance in vista.

    To make myself clearer I’m referring to is something like what is described here:

    Regardless of the particular event they describe (which could be fixed for all I know), I think the point I make is similar. Do you know anything I can do to prevent against different user apps from communicating on the desktop in Vista? (Besides start the app logged on as a different user and then vnc over or something from my desktop so that the app appears on my desktop)

    Thanks again Aaron

    Are there really, truly people who think it is “safe” to run malware that way?  Wow.

    There are a LOT of issues (flaws) with that haxorcitos document.  One that I must address is that while I’m sure the MSRC said that the observed behavior was “by design”, I’m just as certain they did not agree that it is a “design flaw“.  Big, big difference there.

    The desktop is a shared resource.  The window manager renders objects on it, and processes (or more accurately, threads) associated with that desktop can enumerate its windows and send messages to them.  It is designed specifically to allow interaction between programs.  And because of that it has been Microsoft’s long-standing guidance to discourage developers from designing services that create windows on the interactive desktop.

    Windows Vista makes some significant changes, but not exactly what you’re looking for:

    * Services now run in a separate session from those of interactive logons, and so even poorly written services will no longer display UI on the same desktop as user programs (unless they go way out of their way to do so).

    * Vista has introduced the concept of Integrity Levels into the OS.  Objects and resources at higher integrity levels have a certain amount of protection from access by lower integrity objects/resources.  With respect to window messaging, lower IL processes cannot send window messages to the windows of higher IL processes – particularly those of applications running fully elevated.  However, if you are logged on as User1 and you use “RunAs” to start a program as (non-admin) User2 on the same desktop, those processes will typically run at Medium IL and can send window messages to one another.

    If you are concerned about programs interacting with one another, they should not share a common desktop.  And if you are testing malware, I would recommend doing so on a dedicated machine on an isolated network (if a network is needed) containing no data of any value.  The machine should be wiped regularly.


    — Aaron

  107. AlexT says:

    Hey man thanks a lot for this, I shoulda looked here before! Keep up!

  108. dbabits says:

    I tried every option listed-no luck. I’m using Vista home premium and am trying to launch appwiz.cpl as root, to unistall some apps.

    No matter what i try, it loads in the existing restricted instance of explorer.

    This is the idiotism of Windows 101-running programs in the same process as shell.

    dbabits:  What I wrote in this blog post applies to XP and Server 2003, but not to Vista.  With Vista, you don’t really need any of this.  Instead of trying to run appwiz.cpl as admin, just go into Control Panel, click on “Uninstall a program”, which is under “Programs”.  (If you’re showing Classic View, double click on “Programs and Features”.)  When you do something that requires admin privileges, Vista will prompt you.


    — Aaron

  109. hailbob says:

    So how do you deal with being able to run windows explorer as admin through Vista?

  110. dbabits says:


    Doing what you suggested gives me this:

    “You do not have access to make the required system configuration modifications.Please rerun this installation from an administrators account”. No prompts.Vista home premium.

    thank you.


    Dimas, sorry for the late follow-up.  What program(s) are you trying to uninstall?

    — Aaron

  111. DriverDude says:

    Before reading about the Explorer-as-different-user tricks here, I sometimes used Notepad’s Open dialog as a quickie mini-Explorer. Takes a few more keystrokes but those Common Dialogs are damn useful sometimes. ;=)

  112. AlexaN says:

    Thanks for the tips. To avoid automatic refresh problem with explorer, i’ve been trying to run Runas with ACDSee, but it always fails with error: Unable to locate component. Any ideas why? It has no problem when i launched it from explorer running with admin credentials.

  113. Bruce MacDonald says:

    >> “Instead of trying to run appwiz.cpl as admin, just go into Control Panel, click on “Uninstall a program”, which is under “Programs”.  (If you’re showing Classic View, double click on “Programs and Features”.)  When you do something that requires admin privileges, Vista will prompt you.” <<

    This does not work for the “Utilities and SDK for UNIX-based Applications” install. When attempting to remove/change the install it reports that “Setup has insufficient privleges to continue”

    Bruce:  Known issue, but I’m told it should affect “change” only, not “remove”, and that the error message should also tell you what you need to do to proceed.  Is this not what you are seeing?

    — Aaron

  114. Niklauz says:

    For Option 2 to work (exporer under admin context) it requires that the admin account that you are using already has a profile on that computer. If that user has not logged on locally and therefore does not have a local profile, trying to run explorer with runas does not work (at least in my tests). So IMHO this is not suitable for large support teams where any memeber could have the requirements to use runas but does not have a local profile on that machine already.

    Niklauz:  RunAs will cause a profile to be created for the target user if the profile doesn’t already exist (*).  The problem you’ll run into if Explorer is the first process you try to run is that the SeparateProcess flag will not have been set yet.  If instead the first process you run is “regedit pathExplorerSeparateProcess.reg” (using the reg file described in the post), then Explorer will work as a RunAs target.

    (*) Minor nit:  the profile will not be created if you specify /noprofile on the runas.exe command line, but you won’t want to do that here anyway.


    — Aaron

  115. Alterro says:

    What steps are required to use IE7 as Windows Explorer with Admin privileges ? I use "Run As" option to run IE7 and Windows XP SP2.

  116. Andrew Speer says:

    The following command should start the network control panel via runas:

    runas /user:<username> "cmd /c start iexplore ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}::{21EC2020-3AEA-1069-A2DD-08002B30309D}::{7007acc7-3202-11d1-aad2-00805fc1270e}"

    Works with XP SP2, GUID strings may vary from OS to OS.

  117. What becomes of all my earlier non-admin tips, tricks and recommendations vis-à-vis RunAs, MakeMeAdmin, PrivBar and their interactions with IE and Explorer? The short answer is that Vista changes just about everything with respect to running with least

  118. Rob M says:

    great post, worked great, perfect help, thanks!

  119. mixty says:

    Sorry this is a question from a newbie.

    Using the separate window process I can get multiple explorer.exe running but sometimes when the initial non-admin explorer.exe crashes and makes the taskbar disappear, I have no way to get it back, because when I run explorer.exe it is always a new window, not the initial explorer.exe with the taskbar. So, the taskbar is forever gone unless the computer is restarted.

    Is there a workground for this?


    [Aaron Margosis] What happens if you close all the other instances of explorer.exe first, then start a new Explorer.exe?

  120. mixty says:

    It happened when explorer.exe crashed, but the explorer.exe hasn’t crashed again since then so I can’t tell. If I kill all running explorer.exe by myself, re-running the explorer.exe would bring back the taskbar just fine though.

    Anyway, that could be just occasional. No big deal? Thanks a lot anyway!

  121. arhmm says:

    what is explorer user prompt and how to set 1 for myself for my blog

  122. Will Morton says:

    I’ve been using RunAs in my org for a while now, Win2K Pro and WinXP Pro.  I’ve got a bunch of different shortcuts set up to many different things.  The problem that I have suddenly noticed since going to XP is when I open a Windows Explorer window, all drives that I originally had mapped as my LUA are gone with my AD admin creds.

    Any ideas how to solve THAT problem?

    [Aaron Margosis] Pretty sure this is not new to XP.  Mapped drives, SUBST mappings, etc., belong to a specific logon session.  RunAs creates a new logon session, so while you’ll still have all the “global” drive letters (those associated with real volumes and/or belonging to System), all the mappings that come from logon scripts and so forth will not be shared.

  123. ChuckAB says:

    Got a tip from some friends on <a href=">UserFriendly</a&gt; that suggested an even simpler way to use explorer for admin tasks: From explorer, choose Tools | Map Network Drive | Choose "(none)" | Set the "Connect using a different user name."  Enter \<i>computername</i> in the "Folder" block and it will connect to the remote computer with the indicated credentials asking for a password when needed.

  124. Paul Mahoney says:

    The easiest method I’ve found to open the network connections with elevated privileges is to set the separate process flag as described above under "How do you set the “separate process” flag, then?" – then from your admin command shell type "control netconnections" (without the quotation marks) -hey presto the network connections will open up with administrative privileges.

  125. RosarioM says:

    For the refresh issue, has anyone played with a replacement file explorer? I was testing with Freesoft Labs File Explorer. At first it looked like it might work, where it would refresh when a new folder is created, but then I saw some of the same issues with refresh.


  126. ct says:

    you can use xplorer² from

    there is a special registry key called GIOPT_ALTAREFRESH

    which works around the runas refresh problem

    the detailed thread can be found here:

  127. tony says:

    i have got a big problem and i need help please,, my roblem is that when i want to connect to the internet i go to the control panal i double click on network connection and a msg apears it says "windows explorer has encountered a problem and needs to close . we are sorry for the inconvenience" so anybody can help me ???

  128. RodneyMullen says:

    If you want to start the explorer.exe in Vista as Administrator xou should have to create a shortcut to the explorer.exe and edit the settings of shortcut. First make right-click on the shortcut and go to the register shortcut and then to advanced. Now you make a check to run the link in Administrative Mode and thats it.

    You can rename the shortcut for example to "explorer-admin" and save in C:Windows so that you can run it from the command.promt by simply typing "explorer-admin"

    Enjoy 🙂

  129. Jason says:

    Great article, I ran into a problem though.  Since I hadn’t been able to figure out how to runas explorer I’d just get my cmd prompt admin and launch iexplore.exe.  However, I encountered an issue with I think IE7, that once I would try to change the URL to something local, it would just open up explorer there and not transfer the permissions.  I followed the flag guide, and it worked great.  However I then noticed when I hit ALT-CTRL-DEL it would say NON-ADMIN USER is logged on, but if I clicked the Start menu it had ADMIN NAME above it.  I checked the process and there were a number of processes now running with admin rights that I could not kill.  Basically, it gave admin rights to the start menu as well.  Logging off and back on seemed to fix it, but thats why I’m doing this, is to get around logging off and logging back in.  If anyone has any insight into this send me an e-mail.

    killerkop(at)yahoo(dot)com  (fixed for spam bots)  thanks.

  130. 2xThank’s for greate post.7b I compleatly agree with last post.  ziw

    <a href="">паркет и ламинат</a> 0v

  131. Alexander says:


    There is a really nice app called Advanced Run ( This is a great alternative for a standard Windows Run dialog box. You are able to specify user credentials to run whatever command you need. You are able to open documents with ‘Advanced Run…’ context menu item. You are able to specify Shell Verbs to perform advanced actions over the document you work with. Command templates and shortcuts are really great features that allow user to increase his performance by automating frequently actions. Furthermore, there is a possibility to share settings over a local network. Personally I believe people need such a great program because it’s not convenient and not flexible to use RUNAS command and other alternates such as Sudo for Windows are not such user friendly and powerful. Check it out!


  132. Jonathan says:

    I learned this trick about RunAS with iExplore not too long ago and have loved this ever since. However, this trick doesn’t seem to work with IE7 (even in WinXP) which is a shame.

    I’m probably going to try the explorer in a new process trick soon.


  133. If you want to start the explorer.exe in Vista as Administrator xou should have to create a shortcut to the explorer.exe and edit the settings of shortcut. First make right-click on the shortcut and go to the register shortcut and then to advanced. Now you make a check to run the link in Administrative Mode and thats it.

    You can rename the shortcut for example to “explorer-admin” and save in C:Windows so that you can run it from the command.promt by simply typing “explorer-admin”

    Enjoy 🙂

    [Aaron Margosis]  I don’t suppose you actually tested and verified this “solution” before you posted it, did you?  I know you can get the elevation prompt, but does the Explorer window that finally appears actually have admin rights?  How did you verify that?  I’ve written about this a few times on this blog.  Explorer resists running in multiple security contexts, and it succeeds only in certain scenarios.  I just tried it the way you described and it didn’t work (verified with PrivBar).

  134. Jay G. says:

    If you want to use the iexplore.exe trick in XP after upgrading to IE7, you can still use the IE6 executable the IE7 installer hides at %SYSTEMROOT%IE7IEXPLORE.EXE

    Note that this trick doesn’t work in Vista, as Vista shipped with IE7, so no IE6 files exist on it.

    As an aside, the links to the various files by Aaron in the blog article on top aren’t currently working. These are the files ie.cmd.txt , , ExplorerSeparateProcess.reg.txt , and AdminExplorer.bmp .

    [Aaron Margosis]  That won’t give you IE6.  It might look something like IE6, but it’s actuallly going to be an unsupported and unsupportable mix of IE6 and IE7 components.  Also please note that the files in that folder are not updated by Windows Update, so you could easily be running unpatched and vulnerable code.  (I think the purpose of that folder is to support uninstall of IE7 on XP.  It is not intended to be used for anything else.)

    Sorry about those files — I switched personal ISPs and forgot that I had those files hosted there until they decommissioned my file store.  I did get PrivBar and MakeMeAdmin back up again…

  135. Steve says:

    Tks for the great tips. A few years ago I gave up running as a std user after a 3 hour attempt to get explorer to function w/admin privs. I did eventually use the ie process, which is a very ugly way to do it.

    The frustration encountered looking for ugly hacks to get power, time, virus scan, etc to work as std user over a period of a few weeks was unprecedented. So, I eventually settled on running as admin along w/DMR.

    Again, tks for the tips.

  136. Vimal says:

    use the utility in the below link to run explorer with different user account in ur machine

  137. Willem says:

    Aaron, Setting the SeparateProcess DWORD to 1 in XP Pro SP3 has a strange and unwanted side-effect: If an admin-user right-clicks a network connection and chooses "Status", nothing happens, the statuswindow does not show up. I verified this on several systems with different hardware.

    If I enable the taskbar icon for a network connection the status-window *does* show up if I right-click that one.

    This side-effect does not occur for a limited rights user.

    It is not a disaster because we still have the ipconfig command to get the same status information, but it makes me suspicious: Will there be other side-effects?

    Greetings and a happy new year from the Netherlands!

  138. Hath1 says:

    Can you update your link for the file?  I just spent forever trying to find these again not being able to remember what they were called, and now that I finally did they don’t exist anymore!

  139. Corbo says:

    Works well.

    I made a shortcut "runas /user:administrator explorer".  I then edited the shortcut to show a red background and white text in the command prompt.

    This way when you click on it you get a bright red window prompting you for the admins password, you can’t fail to know you’re working at an elevated level.

  140. ukdtweak says:

    An excellent blog…

    I have two bat files, first gives a choice of user accounts, once selected and correct password entered, the script calls a new bat file with multiple choices to start common apps from compmgmt to taskmgr and explorer etc… even have an opton to call a third bat file to install printers from the domain…

    I have these in a shared folder on a file server so all our engineers can access and run it on any pc in the company.

    Fantastic, made moving the team to limited accounts so much easier.

  141. Dylan says:

    start-run runas /u:domainID cmd

    in the command window,

    c:> control panel

  142. Guy says:

    I was looking for this since a long long time. Thanks!!!

  143. ciscokid says:

    Aaron, any chance you could upload the ‘’ file again? It would be very much appreciated! Thx, Steve

  144. tom says:

    indeed, the ‘handful of .cmd command script files’ link is no longer working. Please re-upload?

  145. Kiristo says:

    I miss using XP.  Modified the registry for the separate process and was smooth sailing, everything I needed to run with elevated rights I ran through an MMC which I ran with my admin account.  Granted, I still do the same thing, I just had to get a 3rd party file explorer.  Directory Opus is pretty sweet, better than windows explorer, but it would be nice to not have to get an additional piece of software just to do what you used to be able to do with Window’s built in tools.  Any news on explorer working with elevated rights again in Windows 7?  

  146. jimmyc says:

    Thanks for the solution. I tried the runas admin for IE and then went to c: and set run as a separate process but it still would not start.

    Had to login as admin to set it.

  147. Jeff D says:

    Has anybody been able to get Windows Explorer to work with admin permissions in Windows 7? I know you can shift-right click to run BAT files, EXE’s, etc. with a different account which is great but it would be nice to have everything in the Explorer window available with elevated permissions.

    [Aaron Margosis]  I haven’t.  What I do on a Server 2008 R2 system I have is to run a remote-desktop client to connect back to the same system using the built in admin account, for which everything runs elevated.  That’s not possible on Windows client (XP, Vista, Win7).  What you can do, although it’s kind of goofy, is to run Notepad elevated, choose File | Open, choose “All Files” in the file type dropdown, and resize the window as large as it can go.

  148. Jeff D says:

    Aaron, thanks for the prompt reply! It is a Windows 7 client so the RDP option is out so I tried the notepad option and it looked promising. I was able to map a drive which was great but when I tried to do something such as run an exe, it merely opened it in notepad. I’m wondering if you tried this option and were able to get more functionality out of it? Any advice would be greatly appreciated.

    [Aaron Margosis]  Remember that you’re in a file-open dialog, so if you double-click a file, it’s going to open it in Notepad!  To run the file, right-click it and choose “Open” instead of “Select”.

  149. Jeff D says:

    Thanks again Aaron. Using “Open” instead of “Select” was the ticket. I was able to use the notepad solution to run a BAT file, an EXE, and a reg hack. I wasn’t able to get to Control Panel from the Notepad window. Is there a way?

    [Aaron Margosis]  I don’t see a way to do it through Notepad either.  But is it really important?  It’s not like in XP — things that need to be run elevated prompt for elevation.

  150. Jeff D says:

    One example is an app we have the requires the short date format to be mm/dd/yyyy. We have a reg hack that runs as part of our login scripts to set the format. When we use our accounts with elevated permissions for the first time, we used to go to Control Panel to make the change. The workaround we used today was to manually run the reg hack via the elevated notepad. I have a feeling we’ll be able to find workarounds if any other Control Panel needs arise.

    [Aaron Margosis] I thought short-date-format would be a user preference, not a machine-wide setting. Are you sure you need elevation to set that?  (Seems kind of unfortunate that the app has that bug. Any chance of getting the bug fixed instead of having to override user preferences that way?)

  151. Dustin Graves says:

    runas /u:domainadmin cmd

    connect c: (or any other drive)

    This will run explorer as admin from user account.

    [Aaron Margosis]  What does “connect c:” mean?

  152. Farfolomew says:

    "What you can do, although it’s kind of goofy, is to run Notepad elevated, choose File | Open, choose "All Files" in the file type dropdown, and resize the window as large as it can go."

    The problem with this method is the inability to select more than one file/folder.  If you’re doing any sort of file manipulation on multiple objects this can be a frustrating limitation.  It turns out Microsoft Word 2007 (winword.exe) allows multiple file selection in it’s Open dialogue box.  I tried looking for a built-in Vista/7 program that allows multiple file selection, but couldn’t find one.  If you run across one, please post it as an alternative to using Notepad and Word.

  153. DJTNT says:

    This part runs ok "runas /u:domainadmin cmd"

    But the "connect c:" part makes no sense to me either. Something must surely be missing here?

  154. Vilius says:

    Ok maybe it’s not possible to run explorer elevated in windows 7.

    How about running explorer with BUITINadministrators group(not elevated) – anyone succeeded ?

    (I mean interactive logon is made from simple user)

  155. Piere says:

    Found a great trick !

    runas /u:administrator "explorer.exe /separate"

    It is working very well on XP/IE7.

    (Found at

  156. David Reabow says:

    1. Use RunAs to run Task Manager under the Administrator account. (Close any open task manager windows first)

    2. Kill all explorer processes

    3. Use task manager (File – New Task) to start Explorer. Just type  "Explorer"  and enter (without quotes).

    4. The desktop will now be running under the Admin account. You can access Control panel, run apps

    etc under the admin account.

    To put it back:

    1. Kill all Explorer processes & Task Manager

    2. CTRL-ALT-DEL –  opens task manager under the original users account.

    3. Use task manager (File – New Task) to start Explorer.

    You should be back at the users desktop and all programs etc that were running should still be running.

    NOTE: Looking at the processes in taskmanager will show you which account everything is running as.

  157. @Vilius

    I have explained here how to run the Explorer in Vista/7 with elevated rights:…/144776-unable-to-open-an-elevated-windows-explorer-window

  158. espinete says:

    handful of .cmd command script files ?? fails 404 error

  159. WinUser says:

    so… I’m assuming this is not valid for Win 10

    [Aaron Margosis] The article targeted XP only, and was obsolete beginning with Windows Vista.

Comments are closed.

Skip to main content