RunAs with Explorer

Artikel
07/07/2004

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:

.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.

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 <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.

Freigeben über

RunAs with Explorer

Comments

Zusätzliche Ressourcen