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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.