IanG on Tap

I'm a fairly keyboard-centric user, so I usually have a few command line prompts open. Sometimes it's useful to run one as an administrator. (I've been running as a non-admin user on XP for some time, so unlike some, I welcome the whole UAC thing in Vista. The sooner developers get used to non-admin being the default in Windows the better. But sometimes you need to do things as admin.) I like to have a pretty clear visual hint that the power to destroy my machine is just an ill-considered keystroke away, so I usually give my admin prompt windows a red background.

With ordinary Windows command prompts (which are not DOS prompts) it's pretty easy to do that. Just type the command COLOR 4F and you're done. That's quick to type, so I never bothered to find an automated solution.

But with PowerShell it's a little too much effort to do by hand. (By the way, PowerShell is now available for Vista even though the main PowerShell page suggests that the Vista support isn't done yet, at time of writing.) To change the background colour to red, you need to do this:

(get-host).UI.RawUI.Backgroundcolor="DarkRed"

That's long enough that I don't want to commit it to muscle memory. So I decided to add something to my profile to set the colour automatically when I run as admin.

On XP, there's an obvious solution to this: add that line to the profile for your admin user ID, but don't add it to your normal user profile. So if you run as admin, you'll get the admin profile and that'll set the red background. (Or change the prompt to a $, or whatever your preferred cue may be.) However, this doesn't work so well on Vista.

With Vista, user accounts that are in the admin group don't run with admin privileges by default. You are now required to opt in to running with scissors. This means that setting the background colour in an account-specific profile will no longer work, because the same account might launch both admin and non-admin prompts.

The solution is to detect whether we're running with admin privileges or not, and set the background to red if we are. You can use the .NET class library to test for this. I've added the following code to do that in my profile:

& {
  $wid=[System.Security.Principal.WindowsIdentity]::GetCurrent()
  $prp=new-object System.Security.Principal.WindowsPrincipal($wid)
  $adm=[System.Security.Principal.WindowsBuiltInRole]::Administrator
  $IsAdmin=$prp.IsInRole($adm)
  if ($IsAdmin)
  {
    (get-host).UI.RawUI.Backgroundcolor="DarkRed"
    clear-host
  }
}

If I run PowerShell in the normal way, the process token will not include the Administrator role - processes are not elevated by default in Vista, even if you're an admin user. In this case, my code leaves the background colour as it is. But if I choose to elevate, by launching PowerShell with the context menu's "Run as administrator..." option, the process will be launched with full admin privileges. The code shown above will detect this, and it will set the background to red and clear the console window. That last step is necessary because by default, the new background colour only applies to new output, rather than the whole window.

You may be wondering about the slightly curious syntax on the first line. You can remove that opening "& {" and the corresponding "}" at the end, and it will still work. However, this ends up leaving the variables in scope for the entire session. This makes sense because in general, if you're setting variables in your profile it's because you want them to be available from the prompt. But in this case, the variables are just for holding temporary data, so I wrapped everything in a block ("{...}") in order to limit their scope. The ampersand tells PowerShell that I want it to execute the block - without that I would effectively have defined an anonymous function without ever executing it.

[UPDATE 10th Feb 2007: I failed to spot this, but it turns out that Dominick Baier beat me to it on this one. He got in a day ahead of me. Although to be fair, his shows how to set the title bar when running as admin in PowerShell. Same basic technique though.]