RunAs with Explorer
This is the latest post in my series about how to run with limited user privileges on Windows XP and to use administrator privileges only as needed. In my first post, I wrote “Unfortunately, Windows does not yet make running as non-admin as straightforward as it needs to be.” This is probably nowhere more glaring than when trying to run Explorer in a different security context. Many tasks in Windows are most easily performed in Explorer, and some can be performed only in Explorer. But when you try to use Run As with explorer.exe with a default XP configuration, nothing happens. This post is all about how to get it to work.
Needing Explorer as admin
Some of the scenarios in which you may want to run Explorer as admin include:
1) Setting file/folder security settings (ACL editor).
2) Sharing folders
3) Control Panel applets/subfolders that are handled by Explorer, including:
a. Folder Options, including viewing and setting file type associations, actions, and context menu options.
b. Printers and Faxes, including installing a local printer
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:
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:
Or to get really interesting, browse directly to shell namespace folders. This command line will take you directly to Network Connections:
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.