Partager via

RunAs with Explorer

  • Article

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

  • Anonymous
    July 08, 2004
    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.

  • Anonymous
    July 08, 2004
    The comment has been removed

  • Anonymous
    July 09, 2004
    Is there any way to use RunAs with Explorer to remotely connect to Scheduled Tasks on another machine?

  • Anonymous
    July 09, 2004
    The comment has been removed

  • Anonymous
    July 22, 2004
    Aaron,

    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.

  • Anonymous
    July 23, 2004
    How to quickly and temporarily give your non-admin account administrator privileges, without having to log out.

  • Anonymous
    July 23, 2004
    Michael M-J -- OK, it's posted:
    http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx
    Sorry for the delay. Thanks for your patience!

  • Anonymous
    July 30, 2004
    Hi,

    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.

    Junior
    junlad@hotmail.com

  • Anonymous
    July 31, 2004
    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!
    Martin

  • Anonymous
    August 02, 2004
    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.

  • Anonymous
    August 04, 2004
    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?

  • Anonymous
    October 22, 2004
    IE Security

  • Anonymous
    October 25, 2004
    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...

  • Anonymous
    December 18, 2004
    Helpful For MBA Fans.

  • Anonymous
    January 15, 2005
    Eric Johansen Malware Research » A Cure for your IE Blues?

  • Anonymous
    April 18, 2005
    Complete list of Aaron Margosis' non-admin / least privilege posts, for easy lookup.

  • Anonymous
    April 27, 2005
    As I prepare for an upcoming talk at Tech-Ed 2005 on Least Privilege for Developers, it's worth reviewing...

  • Anonymous
    June 10, 2005
    Get your friends and family, all those folks that come to you for computer help once their machines have...

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

  • Anonymous
    July 15, 2005
    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?

    Thanks,

    Josh

  • Anonymous
    July 18, 2005
    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.

  • Anonymous
    July 27, 2005
    and it works with the password encrypt tool Runasspc.

    Thanks,
    Marco

  • Anonymous
    July 29, 2005
    The comment has been removed

  • Anonymous
    July 30, 2005
    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.

    Thanks

  • Anonymous
    September 16, 2005
    As you probably know from my old posts, I log into my Windows computers with a normal user account (I’m...

  • Anonymous
    September 16, 2005
    As you probably know from my old posts, I log into my Windows computers with a normal user account (I’m...

  • Anonymous
    September 16, 2005
    As you probably know from my old posts, I log into my Windows computers with a normal user account (I’m...

  • Anonymous
    October 19, 2005
    I noticed that "start iexplore" seems to resolve IE's path. Easy to remember and launch.

    Thanks for the good info.

  • Anonymous
    November 05, 2005
    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.

  • Anonymous
    November 10, 2005
    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.

  • Anonymous
    December 04, 2005
    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?

  • Anonymous
    December 08, 2005
    The comment has been removed

  • Anonymous
    December 12, 2005
    I have this setting in both my user and admin profiles :

    [HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer]
    "DesktopProcess"=dword:00000001

    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 !

  • Anonymous
    December 13, 2005
    Guillaume, from what I'm told, DesktopProcess really doesn't do anything different from SeparateProcess. SeparateProcess is recommended.

  • Anonymous
    January 02, 2006
    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?

  • Anonymous
    January 17, 2006
    Hi!

    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.

  • Anonymous
    January 27, 2006
    The comment has been removed

  • Anonymous
    February 01, 2006
    The comment has been removed

  • Anonymous
    February 05, 2006
    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.

  • Anonymous
    February 07, 2006
    The comment has been removed

  • Anonymous
    February 15, 2006
    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"

  • Anonymous
    February 15, 2006
    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.

  • Anonymous
    February 18, 2006
    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.

  • Anonymous
    February 18, 2006
    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.

  • Anonymous
    February 20, 2006
    Aaron,
    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?

  • Anonymous
    March 05, 2006
    Aaron, You save my brain from eruption !
    You are a genius, continue !!!
    Thanks
    OAS

  • Anonymous
    March 20, 2006
    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

  • Anonymous
    March 20, 2006
    Since I can realize a scrips with RunAs in which it includes the user and the password in the same Scrips

  • Anonymous
    March 20, 2006
    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.

  • Anonymous
    March 21, 2006
    The comment has been removed

  • Anonymous
    March 27, 2006
    A systematic approach for working around LUA bugs that avoids unnecessary exposure - "the rest of the story"

  • Anonymous
    April 10, 2006
    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

        [HKEY_LOCAL_MACHINESOFTWAREClassesFoldershellOpenAsAdminUser]
        @="Open An Explorer Window as Admin User"

        [HKEY_LOCAL_MACHINESOFTWAREClassesFoldershellOpenAsAdminUsercommand]
       @="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.

  • Anonymous
    April 17, 2006
    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?

  • Anonymous
    April 18, 2006
    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

  • Anonymous
    April 20, 2006
    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.

  • Anonymous
    April 20, 2006
    Tom - good advice.  Is there a violation here that I hadn't noticed?

  • Anonymous
    May 10, 2006
    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.

  • Anonymous
    May 15, 2006
    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.

  • Anonymous
    May 16, 2006
    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.

  • Anonymous
    May 17, 2006
    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.
    Thanks!

    Peace out!

  • Anonymous
    May 17, 2006
    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!

  • Anonymous
    May 18, 2006
    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.

  • Anonymous
    June 04, 2006
    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.

  • Anonymous
    June 04, 2006
    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!

  • Anonymous
    June 05, 2006
    The comment has been removed

  • Anonymous
    June 05, 2006
    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.

    *Administrators
    *Guests
    *HelpServicesGroup
    *Users

    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

  • Anonymous
    June 05, 2006
    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.

  • Anonymous
    June 05, 2006
    Thank for your help on this.

  • Anonymous
    June 17, 2006
    PingBack from http://blog.joyus.org/2005/12/tip-runas-with-explorer/

  • Anonymous
    June 19, 2006
    The comment has been removed

  • Anonymous
    June 19, 2006
    The comment has been removed

  • Anonymous
    June 20, 2006
    Aaron,

    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.

    Larry 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... HTH -- Aaron

  • Anonymous
    July 21, 2006
    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. :)

  • Anonymous
    July 21, 2006
    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 ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}::{21EC2020-3AEA-1069-A2DD-08002B30309D}::{D6277990-4C6A-11CF-8D87-00AA0060F5BF} (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 [HKEY_CLASSES_ROOTFoldershellrootexplore]
    @="Explore From Here" [HKEY_CLASSES_ROOTFoldershellrootexplorecommand]
    @="Explorer.exe /e,/root,/idlist,%I" HTH -- Aaron

  • Anonymous
    July 24, 2006
    @Les: you can find a reference for such GUIDs at:
    http://www.winguides.com/registry/display.php/61/
    HTH

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

  • Anonymous
    August 01, 2006
    PingBack from http://red.caek.org/?p=11

  • Anonymous
    August 04, 2006
    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

  • Anonymous
    August 06, 2006
    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,
    dolfff

  • Anonymous
    September 06, 2006
    The comment has been removed

  • Anonymous
    September 10, 2006
    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.

  • Anonymous
    September 27, 2006
    The comment has been removed

  • Anonymous
    October 20, 2006
    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.

  • Anonymous
    November 20, 2006
    I'm another user that suffer with the refresh problem...

  • Anonymous
    November 21, 2006
    The comment has been removed

  • Anonymous
    November 22, 2006
    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?

  • Anonymous
    December 21, 2006
    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?? -c 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

  • Anonymous
    January 04, 2007
    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? HTH -- Aaron

  • Anonymous
    January 04, 2007
    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 normal.dot file. This can be recreated by searching for and renaming the existing normal.dot 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.

  • Anonymous
    January 05, 2007
    IE is definitely the most insecure gateway to a PC. So I was thinking: why not run it in a guest account...

  • Anonymous
    January 09, 2007
    Aaron: 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. Regards, 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

  • Anonymous
    January 10, 2007
    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. Regards, 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. HTH -- Aaron

  • Anonymous
    January 10, 2007
    The comment has been removed

  • Anonymous
    January 10, 2007
    The comment has been removed

  • Anonymous
    January 10, 2007
    The comment has been removed

  • Anonymous
    January 11, 2007
    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???? THANKS! 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.) HTH -- Aaron

  • Anonymous
    January 15, 2007
    The comment has been removed

  • Anonymous
    January 24, 2007
    The comment has been removed

  • Anonymous
    January 25, 2007
    Great blog...Don't know if anyone has mentioned it but is there anything wrong with using \127.0.0.1c$ to run explorer as admin?  And, how do you run explorer as admin in Vista? LAR:  Not sure what good it does to browse \127.0.0.1c$ -- 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. HTH -- Aaron

  • Anonymous
    January 26, 2007
    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.

  • Anonymous
    January 27, 2007
    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. HTH -- Aaron

  • Anonymous
    January 28, 2007
    The comment has been removed

  • Anonymous
    January 30, 2007
    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. HTH -- 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

  • Anonymous
    February 01, 2007
    PingBack from http://serverdays.com/2007/02/01/workaround-for-no-explorer-runas-in-vista/

  • Anonymous
    February 03, 2007
    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. :)

  • Anonymous
    February 05, 2007
    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.

  • Anonymous
    February 06, 2007
    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? Thanks

  • Anonymous
    February 06, 2007
    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?

  • Anonymous
    February 21, 2007
    The comment has been removed

  • Anonymous
    February 22, 2007
    PingBack from http://blog.linuxforge.hu/?p=124

  • Anonymous
    February 23, 2007
    The comment has been removed

  • Anonymous
    February 23, 2007
    Hi, 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? Thanks 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". HTH -- Aaron

  • Anonymous
    February 23, 2007
    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: http://blogs.msdn.com/aaron_margosis/archive/2004/07/07/175488.aspx#1738690 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: http://www.haxorcitos.com/MSRC-6005bgs-EN.txt 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. HTH -- Aaron

  • Anonymous
    February 24, 2007
    The comment has been removed

  • Anonymous
    March 10, 2007
    Hey man thanks a lot for this, I shoulda looked here before! Keep up!

  • Anonymous
    March 11, 2007
    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. HTH -- Aaron

  • Anonymous
    March 16, 2007
    So how do you deal with being able to run windows explorer as admin through Vista?

  • Anonymous
    March 17, 2007
    Aaron, 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. Dimas, sorry for the late follow-up.  What program(s) are you trying to uninstall? -- Aaron

  • Anonymous
    March 20, 2007
    The comment has been removed

  • Anonymous
    April 01, 2007
    The comment has been removed

  • Anonymous
    April 16, 2007
    >> "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

  • Anonymous
    April 23, 2007
    PingBack from http://soci.hu/blog/index.php/2007/04/23/vista-ie7-runas-mar-nem-jo-baratok/

  • Anonymous
    April 26, 2007
    The comment has been removed

  • Anonymous
    May 28, 2007
    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.

  • Anonymous
    June 24, 2007
    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.

  • Anonymous
    June 28, 2007
    The comment has been removed

  • Anonymous
    July 05, 2007
    great post, worked great, perfect help, thanks!

  • Anonymous
    August 16, 2007
    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? Thanks. [Aaron Margosis] What happens if you close all the other instances of explorer.exe first, then start a new Explorer.exe?

  • Anonymous
    August 17, 2007
    The comment has been removed

  • Anonymous
    September 02, 2007
    what is explorer user prompt and how to set 1 for myself for my blog

  • Anonymous
    September 25, 2007
    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.

  • Anonymous
    October 09, 2007
    PingBack from http://www.mcseboard.de/windows-forum-ms-backoffice-31/runas-explorer-exe-122525.html#post754701

  • Anonymous
    October 09, 2007
    PingBack from http://edsmiley.com/?p=134

  • Anonymous
    October 12, 2007
    Got a tip from some friends on <a href="http://www.userfriendly.org>UserFriendly</a> 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 &lt;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.

  • Anonymous
    November 25, 2007
    PingBack from http://www.gpconsulting.com/blog/?p=93

  • Anonymous
    December 19, 2007
    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.

  • Anonymous
    February 13, 2008
    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. thanks

  • Anonymous
    May 19, 2008
    you can use xplorer² from http://www.zabkat.com/ there is a special registry key called GIOPT_ALTAREFRESH which works around the runas refresh problem the detailed thread can be found here: http://netez.com/bbs/viewtopic.php?t=4444&highlight=runas

  • Anonymous
    June 01, 2008
    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 ???

  • Anonymous
    June 08, 2008
    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 :-)

  • Anonymous
    July 30, 2008
    The comment has been removed

  • Anonymous
    August 24, 2008
    2xThank's for greate post.7b I compleatly agree with last post.  ziw <a href="http://skuper.ru">паркет и ламинат</a> 0v

  • Anonymous
    October 23, 2008
    The comment has been removed

  • Anonymous
    October 29, 2008
    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. Thanks

  • Anonymous
    November 16, 2008
    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).

  • Anonymous
    November 19, 2008
    The comment has been removed

  • Anonymous
    November 20, 2008
    In regards to the missing files, archive.org has copies of the txt and bmp files: http://web.archive.org/web/20040708051500/http://www.speakeasy.org/~aaronmar/NonAdmin/ie.cmd.txt http://web.archive.org/web/20040708051437/http://www.speakeasy.org/~aaronmar/NonAdmin/ExplorerSeparateProcess.reg.txt http://web.archive.org/web/20040708125708/http://www.speakeasy.org/~aaronmar/NonAdmin/AdminExplorer.bmp

  • Anonymous
    December 19, 2008
    The comment has been removed

  • Anonymous
    January 04, 2009
    use the utility in the below link to run explorer with different user account in ur machine http://simplytoknow.blogspot.com/2008/11/run-windows-explorer-as-another-user.html

  • Anonymous
    January 05, 2009
    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!

  • Anonymous
    January 08, 2009
    Can you update your link for the ShellFolders.zip 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!

  • Anonymous
    January 29, 2009
    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.

  • Anonymous
    February 25, 2009
    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.

  • Anonymous
    April 16, 2009
    start-run runas /u:domainID cmd in the command window, c:> control panel

  • Anonymous
    April 22, 2009
    I was looking for this since a long long time. Thanks!!!

  • Anonymous
    May 04, 2009
    Aaron, any chance you could upload the 'ShellFolders.zip' file again? It would be very much appreciated! Thx, Steve

  • Anonymous
    May 20, 2009
    indeed, the 'handful of .cmd command script files' link is no longer working. Please re-upload?

  • Anonymous
    June 05, 2009
    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?  

  • Anonymous
    December 03, 2009
    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.

  • Anonymous
    December 07, 2009
    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.

  • Anonymous
    December 07, 2009
    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".

  • Anonymous
    December 07, 2009
    The comment has been removed

  • Anonymous
    December 07, 2009
    The comment has been removed

  • Anonymous
    December 29, 2009
    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?

  • Anonymous
    January 31, 2010
    The comment has been removed

  • Anonymous
    February 09, 2010
    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?

  • Anonymous
    March 01, 2010
    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)

  • Anonymous
    March 04, 2010
    are you looking for ShellFolders.zip? just check out on archive.org: http://web.archive.org/web/20040708051500/http://www.speakeasy.org/~aaronmar/NonAdmin/ShellFolders.zip

  • Anonymous
    April 19, 2010
    Found a great trick ! runas /u:administrator "explorer.exe /separate" It is working very well on XP/IE7. (Found at http://stackoverflow.com/questions/13805?tab=votes#tab-top)

  • Anonymous
    June 28, 2010
    The comment has been removed

  • Anonymous
    October 12, 2010
    @Vilius I have explained here how to run the Explorer in Vista/7 with elevated rights: www.msfn.org/.../144776-unable-to-open-an-elevated-windows-explorer-window

  • Anonymous
    June 29, 2011
    handful of .cmd command script files ?? fails 404 error

  • Anonymous
    October 03, 2016
    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.