PowerShell with ISE, shaken not stirred

powershell-ise

Many people think of Windows PowerShell as a command line interface (CLI) rather than a graphical user interface (GUI). Shouldn’t it be called a textual user interface (TUI)?

Two peas in a pod, the Console Host (conhost.exe) and PowerShell (powershell.exe) provide a classic cmd.exe style window  for typical the shell experience. Actually, in Windows Server 2008 R2 (and Windows 7), not only does conhost.exe host powershell.exe, but also cmd.exe. Therefore, the window environment that the Windows Command Prompt and Windows PowerShell version 2.0 each run in is the same in these latest versions of Windows.

But there is another way – bring on the ISE! On Windows Server 2008 R2, PowerShell can be run in another hosting environment, namely the Windows PowerShell Integrated Scripting Environment (ISE). How?

Right-click the PowerShell icon in the taskbar, and then chose Windows PowerShell ISE from the menu. Alternately, you could choose Windows PowerShell ISE from the submenu on most PowerShell items in the Start Menu or Administrative Tools. For yet another approach, in either the Windows PowerShell console, Cmd.exe, or in the Start/Search or Start/Run… box, type, powershell_ise.exe.

Once you are in PowerShell ISE, you should have a menu bar with File, Edit, View, Debug, and Help menus; a toolbar offers an array of editing and debugging tools; then there are three panes of the window beneath those, and a status bar at the bottom. The three main panes of the window are (a) a tabbed editor called the Script pane, (b) the command output pane simply referred to as the Output pane, and (c) a prompt for the current command – this is named the Command pane. Script, Output, Command. Let’s look at each of these.

First, there’s no reason to not take PowerShell ISE fullscreen, so if you’re following along on Windows 7 or Windows Server 2008 R2 in PowerShell v2.0, launch the ISE and go fullscreen. Now. Why be cramped into a small little window with three panes? Also, cozy on up to your <Control> key, because it can really help with navigation.

For serious scripting, or actually even for casual scripting, you can quickly tire of Notepad. Having a tabbed editor integrated into PowerShell ISE is nice. Even better – you can put it where you want it. Type <Ctrl>+1 to show the Script pane on the top (default), <Ctrl>+2 to show it on the right, or <Ctrl>+3 to maximize it so it takes up the whole PowerShell ISE window. When you’re just focused in interactive commands you can hide the script pane simply by typing <Ctrl>+R, which can be used again to bring the script pane back again. If your cursor is in one of the other panes, you can quickly navigate to the script pane by typing <Ctrl>+I (think “input”). Note that you can edit data files (XML, CSV, etc.), text, PowerShell scripts (.ps1), batch files (.bat), or whatever else you want in the the script pane.

Are you interested in learning more about the PowerShell ISE? Tune in to this blog soon for more on the other components. In the meantime, maybe you’ll throw out Notepad and start doing all your file edits in the PowerShell ISE script pane?

Having Your Cake (Windows 7) and Eating it Too (Server Management in PowerShell)

So, now that you’re running Windows 7, you’re wondering how you can use all of the great Windows PowerShell version 2.0 features for managing your servers, although you’re not really to upgrade your organization’s production servers to Windows Server 2008 R2 yet, right?

Well, whether or not you were wondering that, you’re in luck. With Microsoft’s downloadable Remote Server Administration Tools for Windows 7 <http://www.microsoft.com/downloads/details.aspx?FamilyID=7D2F6AD7-656B-4313-A005-4E344E43997D&displaylang=en>, you can use a Windows 7 Professional, Enterprise, or even Ultimate workstation (or notebook) to manage many features of Windows Server 2003 and Windows Server 2008 without having to wait for Windows Server 2008 R2. Yes, it’s true, there’s great synergy between Windows 7 and Windows Server 2008 R2 (which I still sometimes refer to as Windows 7 Server), yet there’s also a great deal of backward compatibility in the management tools.

The reasonable expense and low risk of running Windows 7 on one administrative workstation to manage your servers (and other workstations) in more effective ways using PowerShell version 2.0 is great bargain. For those of you wanting to get off of XP and Vista for systems administration, the wait is over. Well yes, you could manage your systems from Snow Leopard, but that’s another story. We’re talking about Windows 7 and PowerShell version 2.0 for now. Even if you can get Windows PowerShell version 2.0 for Vista or XP, Windows 7 does have many other advantages, doesn’t it? Let’s not dwell on that.

One example of how the Remote Server Administration Tools (RSAT) for Windows 7 can help bring the power of PowerShell v2.0 is the Active Directory management tools included in the Active Directory module for PowerShell which is part of the RSAT AD DS and AD LDS Tools. Once again, not only can Windows Server 2008 R2 based domain controllers be managed using these tools, but Active Directory environments based on Windows Server 2008 and Windows Server 2003 domain  controllers can be managed now with them. This does not require any schema changes. It simply entails using new tools with your existing directory services.

The Active Directory module for PowerShell v2.0 includes a PowerShell provider and several cmdlets. The provider allows navigation into your Active Directory naming contexts (a.k.a partitions) in the same way you would navigate the file system. In other words, using PowerShell’s Set-Location cmdlet (or the “cd” alias for it), you can navigate into your domains, your forest configuration, schema, or DNS zone naming contexts. For example, to go to the default Users container of the domain 777.wernerconsulting.com, we could use:

cd AD:”cn=Users,dc=777,dc=wernerconsulting,dc=com”

The reason we use quotation marks is so that PowerShell doesn’t interpret the different portions of the distinguished name (DN) as separate string in a list, but as one complete string.

Once we have used the AD provider to navigate to the proper location, we can more easily work with the Active Directory objects there. Performing creation, viewing, modification, deletion, and reporting tasks are amazingly straightforward. For example, the New-ADUser cmdlet allows creation of new user account objects in the directory, as follows:

New-ADUser “Alex Wombat”

New-ADUser “Wanda Wombat”

To create ten test user accounts, we could use:

1..10 | %{ New-ADUser “Test $_” }

Of course, any number of accounts could be created this way using the range (..) operator, or the Import-CSV cmdlet could be used to control the details of the names of the test users and other relevant attributes. In a recent post, we looked at how names could be randomly generated from sample lists of first and last names. Fusing that technique with this one could easily be used to create pseudo-realistic test accounts, groups, and a similar technique could be used to create relationships between the accounts.

Familiar cmdlets such as Get-ChildItem (aliased by default as gci, ls, and dir) could be used to view the existing objects in the directory because of the abstraction that the AD provider offers, yet the Active Directory module also adds 76 AD-specific cmdlets.

In summary, the new Active Directory module in PowerShell version 2.0 offers some great flexibility for Active Directory management, and this and many more modules and tools in the Remote Service Administration Tools (RSAT) download for Windows 7 allow Windows 7 based management stations to be used for managing existing systems such as AD Domain Services (AD DS) and AD Lightweight Directory Services (AD LDS (ADAM)) deployments without needing to upgrade to Windows Server 2008 R2 or its new AD schema.