ShellRunAs v1.0

Today, Mark and Jon finally shipped ShellRunAs, a Sysinternals free tool that adds a “Run as Different User” option to the right-click context menu.


The command-line Runas utility is handy for launching programs under different accounts, but it’s not convenient if you’re a heavy Explorer user. ShellRunas provides functionality similar to that of Runas to launch programs as a different user via a convenient shell context-menu entry.

ShellRunas works on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

This has been a HUGE request from IT Pros, so please enjoy!

ShellRunAs v1.0

Comments (17)

  1. luc raymond says:

    what’s the difference between this and holding the SHIFT key and selecting RUN AS when right clicking on an executable?  

  2. tony says:

    yea I was going to ask the same question then I realized they went to all this work to save an extra keystroke 🙂

  3. Anders Jensen says:

    Hi, can i get this util working with explorer.exe ?

    Seems to be impossible in Vista to run the explorer.exe as another user.

    Please help

  4. Ryan says:

    If you’re not running as an administrator, isn’t "Run as administrator" more or less the same?  You can enter any credentials you want at the prompt….

  5. cjacks says:

    luc raymond and tony,

    I assume you two are running XP? There is no longer a context menu extension for Windows Vista. That’s why we built it. We don’t support XP because it’s useful there, just because we knew people would grab it as part of SysInternals Suite and try it out. I can think of no reason to use this on XP.

    Anders – it won’t work on explorer because explorer is single instance. It launches, sees another instance, and goes away. The same reason why you can’t elevateit.

    Ryan – it’s different than Run as administrator, because you don’t have to elevate. You can run as an admin user, but be running as that user with non-elevated credentials. We pulled the functionality because we thought Run as Administrator covered it for us. IT Pros let us know otherwise. Also, it supports net only credentials, which Run as Administrator doesn’t.

  6. Scott says:

    This utility is a good first step towards solving some of the Vista shell gaps from an IT pro perspective.

    The inability to run an explorer window as another user is a killer when trying to remotely support file shares. We don’t want the support folks running their machines day to day using an account with god-like access. We want them to be able to launch an explorer window under their privileged account and then close it when they are done (like they can on XP).

  7. tony says:

    ok this even makes less sense why don’t u just let the uac handle this for you? If the app needs to be elevated doesn’t the UAC detect this and kick in? Your right I don’t use vista much!


  8. cjacks says:

    Tony – I’m confused about the question you’re asking. So, I’ll just explain the relationship with elevation, and hopefully that will clear things up.

    Right click – Run as administrator will always take a token up to the highest level possible. If you use an admin account, then you get an unfiltered token, no matter what.

    With Sysinternals runas, you elevate based on the manifest and the account you’re using. If the app is manifested as requireAdministrator, and the token can elevate, then it will. If it’s highest available and it can, it will, but if it can’t, it won’t. Finally, if it’s asInvoker (or nothing), then we don’t elevate, regardless of whether or not you can. The semantics are quite different.

    Keep in mind that many enterprises don’t allow for elevation at all. They don’t hand out admin credentials, and to avoid confusing users with credential prompts they can’t respond to, they have UAC turned on, but set to automatically deny requests to elevate. That means that you cannot leverage Run as administrator. However, with ShellRunAs, you can have an IT Pro who is running as a standard user with thier domain account. They can have a second domain account, also not a member of the local admins group, but a member of a powerful admin group at the enterprise level. They run as themselves for the purpose of their software, such as email, but then run just a single MMC window as a domain admin account to run ADUC or Exchange Admin or GP or whatnot, which they don’t have to elevate to launch. Yes, you could achieve many of the scenarios we can come up with using runas.exe, but not only is it a little clunky, there are a few that we miss.

  9. tony says:

    ok I was going to break this down for you but its not worth the effort, and I don’t want to sound like I’m arguing with you, so peace I’m out.


    and yes the last paragraph describes exactly how we run things around here all the da’s have second accounts and no we don’t login to desktops with these accounts…

  10. cjacks says:

    tony – wasn’t trying to ward you off. This is a workaround for now, and we’re working on a long-term in-box fix. So, if we’ve missed something, feel free to share, so we can get it in the real fix. Personally, this tool doesn’t dramatically affect my productivity (I have no use for it), so I don’t know if we’ve missed the mark or not – hopefully not, but do let us know if you’d like!

  11. mstahl says:

    Actually, I think this IS pretty useful on XP. We are in the process of removing admin access for day-to-day usage and right-clicking an app or mmc snap-in, changing to be "The following user" and then entering all the credentials, is faster.

    What would make this better is if it would remember usernames and domain so all you would have to do is enter the password or change the user in the drop-down and then enter the password.

    I’m using the shortcut method at this time and having to create all the short-cuts isn’t fun and as we roll out to all admin users having them do the same would be painful. This tool can majorly decrease the workload.

  12. mstahl says:

    "and then entering all the credentials, is faster. "

    Oops, meant to say, isn’t faster or is slower.

  13. DesktopJinx says:

    Chris – you said "They can have a second domain account, also not a member of the local admins group, but a member of a powerful admin group at the enterprise level. They run as themselves for the purpose of their software, such as email, but then run just a single MMC window as a domain admin account to run ADUC or Exchange Admin or GP or whatnot, which they don’t have to elevate to launch."

    That’s exactly what I want to do, but

    shellrunas mmc.exe

    given my domain admin (who is not a local admin) results in this heartbreaker:

    (X) Error launching application:

       The requested operation requires elevation.

    Argh. What am I missing?

  14. cjacks says:


    The code has evolved quite a bit since I last had my hands on it, and the command line usage is something new. You’re getting ERROR_ELEVATION_REQUIRED. I’m guessing the account you’re launching it from is a protected admin account on the box, even if the domain admin one isn’t. Does it work if you use the shell extension to right click it? I think they make take divergent code paths. Let me know.



  15. Anders Jensen says:

    Getting error when trying to launch "dhcpmgmt.msc" with ShellRunAS both from Adm Tools, and direct link below.

    "Error launching program: The system cannot find the file specified".


    What can be the problem ?


  16. cjacks says:

    Hi Anders,

    I’d get Process Monitor on there and see what that tells you.