Setting color for *all* CMD shells based on admin/elevation status

In my RunAs… and MakeMeAdmin posts, I recommend making your admin command shells visually different to set them apart from non-admin ones.  You can change the default console window color on a per-account basis, but that doesn’t help when the same account may be used in both admin and non-admin contexts (such as with Vista’s UAC admin-approval mode).  You can use the cmd.exe /T command-line option, or its built-in COLOR command, but it works only if you remember to use it each and every time.

Here’s a way to make the differentiation happen with a one-time, one-line configuration change on your system, that will work on all CMD.EXE shells you run.  The idea is to run a non-destructive command that requires admin privileges from a CMD autorun location, test for success and set the console’s color accordingly.  You can also change the title at the same time.

This can probably use some refinement.  For the non-destructive admin operation on Windows XP/2003, I suggest “bootcfg /query“; on Windows Vista, I suggest “bcdedit /enum“.  The autorun location I’ve been playing with is:

    [HKLM\Software\Microsoft\Command Processor]
    “AutoRun” (REG_SZ)

The command syntax you can set the “AutoRun” value to for Windows XP/2003 is:

    bootcfg /query >nul 2>nul && (color FC && title ADMIN) || (color 07 && title NONADMIN)

and for Windows Vista, set it to:

    bcdedit /enum >nul 2>nul && (color FC && title ADMIN) || (color 07 && title NONADMIN)

Any output or error message is redirected to “nul” so you don’t see it.  If the command succeeds (&&), you’re running with admin/elevated privileges; the console color will change to bright-red-on-white (FC) and the title changed to “ADMIN“.  If the command fails (||), the console color will be white-on-black (07) and the title changed to “NONADMIN“.  Feel free to change the colors or titles to suit your taste.

All that stuff works only for CMD.EXE.  For Windows PowerShell, take a look at these:

Also for PowerShell — Staffan Gustafsson converted MakeMeAdmin to a PowerShell script:

[2007-06-25:  Update posted here.]

Comments (18)

  1. Pavel Lebedinsky says:

    You could also do something like this:

    cacls %windir%system32configsystemprofile >nul 2>nul && echo admin || echo non-admin

    This should work on both XP and Vista.

  2. Harris says:


    Just an FYI, there’s an error in MakeMeAdmin.ps1 that you referenced.  The “if” statement in the SuPowershell function should read “if($SuAccount)” not “if(!$SuAccount)”.

    Otherwise, that’s awesome, thanks for point it out!


    Harris — thanks, yeah, that didn’t look right to me either.  I tried to post your comments as a reply on that page, but I don’t know whether it went through or not.

    — Aaron

  3. Ross Presser says:

    Put the bare command


    in HKCUsoftwaremicrosoftCommand Processor *for the admin account only*. No test required.

    Of course if you have several admin accounts that you use — e.g. a local one and a domain one — put it in each one.

    On my own machine I sometimes run in an account which is not a Domain admin but is an admin of the local machine, and I need to distinguish. The BOOTCFG trick won’t distinguish between them .. so I would depend on HKCU.

    Ross:  The problem here is that with MakeMeAdmin on XP/2003 and with UAC’s Admin-Approval Mode on Vista, you can have two CMD windows side by side running as the same user, one with admin/elevated permissions and the other not.  Tying to HKCU won’t help.

    — Aaron

  4. Staffan Gustafsson says:

    I have to point out that the representation of the script I wrote is incorrect.

    You can see a correct version at via google groups at

    On ArchiveSat, the critical lines says:

    if (!$SuAccount)

       $StartInfo = new-object System.Diagnostics.ProcessStartInfo

    On Google:

    if (!$SuAccount){



    Makes quite a difference, doesn’t it? 🙂


  5. Ross Presser says:

    >> Ross:  The problem here is that with MakeMeAdmin on XP/2003 and with UAC’s Admin-Approval Mode on Vista, you can have two CMD windows side by side running as the same user, one with admin/elevated permissions and the other not.  Tying to HKCU won’t help. <<

    Aaron: Good point, and if I used MakeMeAdmin like I’m supposed to, I’d have hit that myself. 🙂 Well, is there some kind of test that can distinguish between local machine admin and domain admin?

    Ross:  Perhaps something like “dir \mydcc$”, replacing “mydc” with the name of a domain controller that’s always online?  Or if it works in your environment, “dir \%USERDNSDOMAIN%c$”?  (Note that %USERDNSDOMAIN% should expand to nothing for local accounts — which works for this purpose since you want local accounts to fail the test.)

    Let me know whether this works for you — I plan to post an update on this topic in the next few days.


    — Aaron

  6. anonymous says:

    Very bad thing I found out: it turns every Cmd Console into ANSI mode, yet all subsequently invoked Cmd instance pertain UNICODE.

    Test case:

    for /f “delims=” %i in (‘dir /s /b /a-d’) do echo “%i”

    This will break for the first file, since the cmd instance invoking the ‘dir’ command returns unicode, but the calling shell is ANSI and thus stumbles upon the Unicode BOM at the beginning.

    Can you provide more clarification?  Every CMD is ANSI by default.  The only way I know of to make its pipe/redirection output be Unicode is by starting CMD with the /U switch.  I tried starting command shells with /U both with and without the AutoRun value and found no difference in the output — and in particular, I saw no BOM in any of the output.  The specific test I tried was to run this command in the %TEMP% folder:

    (for /f “delims=” %i in (‘dir /s /b /a-d’) do echo “%i”) > dir.txt

    — Aaron

  7. Ronnie Miller says:

    Here is a way to change the color if you are running under a Domain Administrator context.

    “c:program fileswindows resource kitstoolsifmember.exe” “mydomaindomain admins” >nul 2>nul && (color 07) || (color FC)

    -or you can copy ifmember.exe to somewhere in your path.  Of course, change mydomain to the name of your domain.

    FYI to readers who don’t already know this:  “ifmember.exe” comes with the Windows Server 2003 Resource Kit Tools, freely downloadable from

    — Aaron

  8. Chris R says:

    I just wanted to let you know there are some side affects that cause things to break when using your bootcfg trick.  

    For example we have a Visual Studio 2003 project which runs the following command line function as a Pre-Build Event.  

    xcopy ….exe_dir ….debug /d /e /y /EXCLUDE:….exe_direxclude.txt

    With the trick in place it xcopy fails during the build, although the same code works fine from a command window.

    Visual Studio executes the command by generating the following batch file.

    Creating temporary file “r:MyProjectReleaseobjMyDllBAT000002.bat” with contents


    @echo off

    xcopy ….exe_dir ….release /d /e /y /EXCLUDE:….exe_direxclude.txt

    if errorlevel 1 goto VCReportError

    goto VCEnd


    echo Project : error PRJ0019: A tool returned an error code from “Copy exe_dir to release”

    exit 1



    Creating command line “r:MyProjectReleaseobjMyDllBAT000002.bat”

    When run the output is:

    Copy exe_dir to release

    0 File(s) copied

    MyDll : error PRJ0002 : error result returned from ‘r:MyProjectreleaseobjMyDllbat000002.bat’

    Removing the AutoRun value fixes the problem, so I don’t expect you to troubleshoot this. I just want to warn others.  

    Chris R:  Thanks, I’ve been meaning to post a follow-up.  It’s actually the COLOR command in the AutoRun value that messes up some Visual Studio build events.  It happens for Visual Studio 2005 as well.

    — Aaron

  9. Jeff Chadbourne says:

    Thanks Chris R!  This was driving me nuts. I was getting Pre-build errors too, and couldn’t figure out why.

    I was able to fix this by adding:

    & echo > nul

    which will run the echo after either the admin or non-admin commands run.  This will return errorlevel 0 to VS.Net which will allow the pre-build event to complete.

  10. Improvements on my earlier post about setting color and title for CMD (and PowerShell) windows, based on admin/elevation status

  11. Improvements on my earlier post about setting color and title for CMD (and PowerShell) windows, based on admin/elevation status

  12. 1fThank’s.3k I compleatly disagree with last post .  viw

    <a href="">паркет</a&gt; 3b

  13. Czerno says:

    Hi, Aaron! I wish to thank you for your great "non admin" postings !

    What command would you suggest for use on Windows 2000 (where bootcfg isn’t available) to distinguish between admin/non admin status ?

    Also, I need something which will not depend on NTFS permissions.

    Thanks once more


  14. Czerno says:

    re my above question, found a solution viz

    use the command line registry tool reg.exe,

    for instance :

    reg update softwaremytrick=1

    There might be more elegant ways…



  15. Ross Presser says:

    In Windows 7, BOOTCFG always always returns errorlevel 1, even when it succeeds when running as Administrator. Here’s a refinement:

    (BOOTCFG /query 2>nul |FINDSTR Entries >nul) && (COLOR 47) || (COLOR 07 & echo>nul)

    This uses FINDSTR to search the BOOTCFG output for the word "Entries", which it should always have if it succeeds. It also adds the "echo>nul" for the non-admin case, to clear the errorlevel.

    Windows 7 already adds the "Administrator" to the title bar, but if you still need the color change, here it is.

  16. abqbill says:

    There’s also IsAdmin.exe ( It returns 0 if the current user is not a member of Administrators, 1 if the user is an elevated administrator, or 2 if the user is a non-elevated administrator.

    Bill Stewart

  17. Philip says:

    I have had trouble getting the above commands to work for me on Windows 7.  However, the following seems to work for me.

    (if not %SESSIONNAME%==Console color 47)