Welcome back Command Prompt!

After years of trying to kill off the command line, Microsoft seems to be acknowledging the importance of command line interaction. So much so that the upcoming Windows Server 2008 OS can be run completely without a GUI through a Powershell command line. Vista too has come to rely on the command prompt. In fact, there are many tasks that can only be performed from CMD as no GUI equivalent is offered.

It turns out that UAC prevents many tasks from being performed in the GUI at all and the only solution is to go back to the Command Prompt. Some of the UAC related tasks I'd like to highlight are:

1. Elevating scripts such as VBS, HTA or VBA.
2. Working with multiple files that must all be elevated.
3. Running as another user when you already have two tokens.
4. Copying files to sensitive folders like System32.

All of these tasks can be performed from a CMD prompt using the default Vista configuration. In every case there is no GUI equivalent available using Vista defaults. In some cases there are GUI workarounds or specific configurations to enable the functionality needed. These GUI tricks will be presented in future articles, but it is good to know how to work without them using a CMD prompt - you just might venture to a workstation that hasn't been configured to your liking.

1. Elevating scripts such as VBS, HTA or VBA:

There are certainly many file types in use that could require elevation. I just mention VBS, HTA and VBA because they are quite commonly used for administrative scripting and may need elevation. Microsoft has not provided a facility for scripts to carry their own manifest detailing elevation requirements (unlike executables). For a script to get elevated, it must be done manually by an administrator.

The problem is that Windows GUI does not provide any way to manually elevate these scripts. Windows reserves the "Run as Administrator" in the context menu and in the properties screen for executables only. The only recourse is to launch a CMD window elevated. CMD.EXE is an executable and therefore has the option to "Run as Administrator". Furthermore, any processes (read scripts) launched from the CMD window will maintain the elevation afforded CMD by using the same token. (To understand how tokens work, read my article: Let's Talk UAC for the Enterprise.)

Once you get over the ugliness of a fixed width, grey, courier font on a black background, it is really quite a nice way to fly. From an elevated CMD prompt you can launch as many processes as you wish and they will all launch with the Full Token with absolutely no UAC prompting because no token switching takes place. Many techs I work with simply elevate a DOS window at the beginning of their session and return to it throughout the day - they only see one UAC prompt.

The CMD window even helps us to remember what we've done by changing its name - it appends "Administrator" to the front:


Despite CMD giving us added functionality, I still wish Vista would get its act together and let us do our work from the GUI.


2. Working with multiple files that must all be elevated

A similar problem to the scripting elevation difficulties shown above is the problem of working with data files in sensitive areas. You might be modifying the Welcome Center which stores all of its files in the System32\oobe folder. If you were to simply click on a .txt file stored there to edit it - Notepad would open and you would modify it. But when you go to save the document you will get errors like "cannot create" because Notepad is not running with a full token.

I guess the way Microsoft expects you to edit this file is as follows:

1. Identify the type of file and a suitable application to edit it.
2. Go find that application and ask to "Run as Administrator".
3. Use the application's Open dialog to navigate back to your folder and open the file.
4. Edit as necessary and then save.
5. Now repeat this process for each and every file you need to work with.
   

The easiest approach is actually to use the same elevated CMD solution I outlined above. All you have to do from an elevated DOS prompt is:

1. Navigate to your folder (the TAB key helps a lot with this).
2. Type in the name of the file you wish to edit.
3. CMD will find the associated application and run it with the same elevated token.
4. When you then choose to save the data, it will save without any problems or prompting.
5. Now type in the name of the next file you wish to edit...
   

CMD makes it much easier for you to do your work as an administrator than the Vista GUI can.

3. Running as another user when you already have two tokens:

Microsoft made what many techies consider a big mistake when they implemented the "Run as Administrator" feature. It replaces XP's old "Run As..." entry on the context menu but not all of its functionality. There are many posts on the web about it and I wrote my own lengthy article on the subject. The problem is that if you have two tokens when you activate "Run as Administrator", the feature will only ask your consent to elevate to your second token - that's it - you get no other options (I'm ignoring an optional policy setting that forces consent at all times for everyone). This means that if a power user or local administrator wishes to change to another account such as a Domain Admin account when running an app, they are completely unable to. The default Vista GUI provides no capability to do this without setting a group policy that forces all users to get prompted for credentials every time they elevate (impractical).

CMD to the rescue! It turns out that CMD still has a RunAs command that seems to have been ported directly from Windows XP. So much so that the RunAs command knows nothing about tokens and elevation. This is both a blessing and a problem.

The blessing is that the only thing RunAs wants to see is a username. It quite happily runs applications as any userid - no matter what tokens you might have. This is great if a Local Admin wishes to switch to a Domain Admin account in order to manage the network through tools like ADUC or GPMC - problem solved.

But RunAs not understanding tokens still leaves some scenarios out in the cold. If a Power User wishes to switch to a Local Administrator account, he can only do so using this RunAs command from a CMD window. But since RunAs doesn't understand tokens, it simply runs the application using the default, User Token. Somehow the application gets launched directly and Vista misses its opportunity to inspect the manifest and elevate the application. If I use RunAs to switch to a Local Administrator account when launching Regedit, I will just get the following error:


Oh well, even if the command prompt can't give us everything, it's pretty darn handy.


4. Copying files to sensitive folders like System32:

An elevated command prompt is also wonderful for copying files to sensitive folders such as System32. Use any copy command such as Xcopy or Robocopy and it will succeed from an elevated Administrator Token. Try the same thing using Windows Explorer and almost anything can happen.

Windows Explorer has many different ways of behaving depending on how it's options are set and what token(s) a user has. Putting all the variables together results in very unpredictable behavior from the user's perspective. Windows Explorer could just perform the copy as requested, or it might ask a few confirmation and elevation questions before ultimately failing to copy. (I will cover some of these details in a future article.)


I hope I've demonstrated how vital the command prompt has become in Vista. So pull out those old DOS books - talk to 40 somethings in your office and learn how to work with DOS once again!