UPDATE 01/30/2014

There is a registry hack in Windows 7 to enable this feature again (although I wouldn’t necessarily suggest it… MS doesn’t support it).
You can naviGate to HKEY_CLASSES_ROOT\AppID\{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}  and clear out the value for RunAs.  This will enable the ability to do a runas and have explorer run in a separate process.  If you don’t want to go this route, see the original post below.

In XP we have a nifty little work-around to logging in as an admin without having to log the user off the desktop.  At the command line we can type:

C:\> runas /user:USERNAME@Domain “explorer /e, /separate”

Then it prompts us for our password and up pops a separate explorer shell running as our privileged account.  We can then proceed to do as we need.

In Windows 7 this doesn’t work 🙁  I did a little research and Microsoft now no longer allows us to run explorer as two separate users, simultaneously.  On the one hand this isn’t as much of a problem because Powershell supports UNC paths so we can get to wherever we need to go in the new shell.  I’ve just started reading “Learn Windows Powershell In a Month of Lunches” and I’m liking PS a lot already.  MS seems to be moving towards many of their apps working on top of Powershell (like the Exchange GUI) so it’s a good idea to learn.  You can right-click on Powershell and choose “Run as Administrator” to load it as yourself.  Unless you’re not comfortable with the command line (and you should be if you’re an administrator), I can’t see the need to use the explorer GUI anymore.  However, I wanted to see if I could figure out how to do it…

Let’s say you don’t want to learn Powershell or you have some reason for wanting the GUI (and I’ll set my devil’s advocacy aside for a moment).  I did figure out a way to do it shortly after my frustrating moment of reading about MS’s change with Explorer (I can’t complain too much though, it IS more secure), but not quite like XP.  MS stopped us from running Explorer as two simultaneous users.  All you have to do is kill the explorer process and then start it again as another user.  Since XP, we’ve had a clean way to do this without having to completely logoff the machine or close any other processes open on the PC.  Through this whole procedure, any running processes that were open as the user will stay open and running under their user context.  So here’s the step-by-step:

1. As a precaution you can ask the user to save changes to anything they have open.  However, the process shouldn’t close anything except Explorer.
2. Open a command prompt or powershell as the current user.  This is important!
   1. You can alternately open up Task Manager as the current user so long as they have the ability to do a “Run” (you may have this disabled in your environment for security reasons)
3. Open up another command prompt with your admin privileges.
   1. You can either right-click on cmd or powershell and “Run as Administrator” or…
   2. From the users shell type:
      C:\> runas /user:USERNAME@Domain cmd.exe
4. You should now have two shell windows open.  One under your user context and one under theirs.
5. Click on the Start button.  Put your mouse over in “dead space” next to the shutdown button.  Hold CTRL + ALT + SHIFT and right-click in that dead space.
6. You should have a context menu with “Exit Explorer” as an option.  Click it and you will see the desktop and taskbar disappear as explorer exits.
   1. If you opened Task Manager you’ll see that all other processes continue to run.
7. Now, in the shell under your admin context, type:
   C:\> explorer
8. Explorer will now open up and you’ll see your own desktop.  Go ahead and do whatever you need to do.  You should also close the shell window you have open as your context.  You don’t want to walk away and leave it open for the user to do what they want!
   1. You’ll also notice that all of the applications the user had left open are still open and running on the taskbar.  Again, you’ll also notice it in the Task Manager.
9. CLOSE EVERY WINDOW YOU OPEN UNDER YOUR CONTEXT.  Just as the users running applications stayed open under their credentials, so will yours continue to stay open as you after you switch the desktop back to the user.
   1. This is also a good reason to learn Powershell.  You will only have to remember to close that one window and even if you did leave it open, chances may be good the user wouldn’t know how to use it.
10. Now that we’re done doing our administrative tasks, lets get the desktop back to the user.
11. With the shell still open under their context, perform the clean explorer shutdown in step 5.
    1. If you closed their shell, open one as you and do a runas but for their login and have them type in their password so it will launch.
12. From their shell type:
    C:\> explorer
13. They should now be back to their regular desktop with their same applications still running as them.
14. Since I can’t stress this enough… Open up Task Manager to make sure there are no running processes under your user context!  Because they aren’t an admin, you will need to click the button “Show all users processes” and login as yourself to be able to see them if they still exist.

I only did minimal testing with this shell changing.  However, I didn’t notice any issues with the desktop or user context getting “messed up” because of the switching.  Microsoft intentionally made the CTRL + ALT + SHIFT method for a way of cleanly exiting and restarting explorer.  Desktop icons, background, folder permissions (I only checked one) were appropriate to whoever explorer was currently running as.  I strongly suggest you do some testing yourself, however.  If anything you’ll get more familiar with the process.

I like to give credit when I can, but the only thing I would give credit to someone else for is learning the XP command for running as another user.  It’s been one of my tools for so long I can’t remember, though :\  I did a quick Google search to find something familiar and this page is definitely one I’ve been on before:  http://blogs.msdn.com/b/aaron_margosis/archive/2004/07/07/175488.aspx

You must be logged in to post a comment.