Summary: Microsoft Scripting Guy, Ed Wilson, talks about installing the free Remote Server Administration Tools for Windows PowerShell 3.0 in Windows 8.

Microsoft Scripting Guy, Ed Wilson, is here. This morning is an awesome morning. Our friends from Hamburg, Germany have been hanging out all weekend, and it has been a blast. We have spent a bit of time talking about Windows PowerShell training and some of the challenges related to that. We have also shared a love for tea. Yep. It has been a great weekend. Not only that, but the weather also cooperated—it has been sunny and not too humid.

One of the first things I do when I build a new computer running Windows 8, is install the Windows 8 Remote Server Administration Tools (RSAT) tools. After I do this, I gain access to many new and useful cmdlets that make it easy to administer everything from Active Directory Domain Services to Windows Software Update Services.

Getting the Windows 8 RSAT tools

For a free download of the tools, see Remote Server Administration Tools for Windows 8 on the Microsoft Download Center. There are two versions available on the download page: a 32-bit version and a 64-bit version. Finding the actual download is pretty easy—I click the big red Download button that is shown in the following image.

I can install the RSAT tools for Windows 8 on computers running Windows 8 or Windows 8 Pro. I cannot install them on my Windows Surface RT, but I can install them on my Windows Surface Pro.

The first thing I need to know is if my computer x86 or is it x64. The way that I usually find this out is to query an environmental variable as shown here:

PS C:\Users\ed.IAMMRED> $env:PROCESSOR_ARCHITECTURE

x86

Before I install the RSAT tools on my computer, I use the following script to to see how many cmdlets and functions are currently on my computer— I have 989.

PS C:\Users\ed.IAMMRED> gcm -CommandType cmdlet, function | measure

Count    : 989

Average  :

Sum      :

Maximum  :

Minimum  :

Property :

So I click the big red Download button to select my appropriate package.

Now, I have a choice. I can download the package and install it offline. Or if I choose Run, the file spools to a Temp folder, and it performs the installation from there. This works great if I have good Internet bandwidth, and if I do not anticipate needing to perform the installation again anytime soon. I will open the file, and after a quick security scan, the installation begins. Here is the dialog box I see:

While the RSAT installs, a progress bar tracks the percentage of completion. This is shown here:

The first thing I do after the installation is complete is use the Update-Help cmdlet to update the Help for the newly installed modules. This is shown here:

PS C:\Users\ed.IAMMRED> update-help -Module * -Force

After I install the RSAT tools, I check to see how many cmdlets and functions I now have. The number is 1757 as seen here:

PS C:\Users\ed.IAMMRED> gcm -CommandType cmdlet, function | measure

Count    : 1757

Average  :

Sum      :

Maximum  :

Minimum  :

Property :

Unlike previous versions of the RSAT tools, now when I install the tools, all of the modules and support tools automatically install. In previous versions, I had to go into Programs in Control Panel, select Turn Windows features on or off, and then scroll down to Remote Server Administration Tools to turn on each tool. Now, I only need to do this if I want to turn off a feature. This menu is shown here:

After the tools install and I have updated the Help, I can open the Windows PowerShell console (or the Windows PowerShell ISE) and begin to use the tools. The cool thing is that I can use the cmdlets from the Active Directory module to query a domain controller that is running Windows Server 2008. This is shown here:

PS C:\Users\ed.IAMMRED> Get-ADUser -Filter * -Server dc1 | select -Last 1

DistinguishedName : CN=anothertestuser,OU=Testou,DC=iammred,DC=net

Enabled           : False

GivenName         :

Name              : anothertestuser

ObjectClass       : user

ObjectGUID        : 36b19f4d-081b-4435-89cf-5979defe8c32

SamAccountName    : $9E1000-86BJ2L7MPKB4

SID               : S-1-5-21-1457956834-3844189528-3541350385-1481

Surname           :

UserPrincipalName :

But I can also use cmdlets that only exist in Windows Server 2012 as shown here:

PS C:\Users\ed.IAMMRED> Get-DhcpServerInDC

IPAddress            DnsName

---------            -------

192.168.0.152        wds1.iammred.net

Well, that is about it for today. Join me tomorrow as we begin a series written by Windows PowerShell MVP, Sean Kearney, about automating DiskPart. It is cool stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Use Windows PowerShell to get the BitLocker recovery key.

Summary: Microsoft Scripting Guy, Ed Wilson, talks about the decision points for deciding how to use Windows PowerShell to access Active Directory Domain Services.

 Hey, Scripting Guy! I am a bit confused. I see various blogs and scripts on the Script Repository, and some always use a third-party snap-in to access Active Directory Directory Domain Services (AD DS). Others seem to use .NET Framework code to access AD DS, and still others are using a module that looks like it is part of Windows PowerShell. What is the best way to access AD DS?

—CB

 Hello CB,

Microsoft Scripting Guy, Ed Wilson, is here. This morning it is actually cool here in Charlotte, North Carolina. In fact, it is way cool because the Scripting Wife found a place on the Internet so she could order some chocolate covered Macadamia nuts. By the way, they go very well with Earl Grey tea with a cinnamon stick. The chocolate, the cinnamon, and the touch of bergamot combine to create an exquisite taste sensation. So, I am out on the lanai sipping tea, nibbling on chocolate covered Macadamia nuts and checking my email on my Surface RT, and I ran across this email to scripter@microsoft.com from CB.

Supportability—the big advantage

When comparing options for working with Active Directory Domain Services from within Windows PowerShell, one option stands above all the others: supportability. When I use the Active Directory module from Microsoft, it is supported. For me, this means a lot. So if something does not work out perfectly, I know it is supported.

I gain access to the Active Directory module in two ways. On a domain controller that is running at least Windows Server 2008 R2, I add the Active Directory management feature, and I have access to the Active Directory module. I can access it locally on the server, or I can use remoting or implicit remoting to access the cmdlets from my workstation. For more information about remoting, see Use PowerShell Active Directory Cmdlets Without Installing Any Software.

I can also install the Remote Server Admin Tools (RSAT) on my workstation. The version I install depends on the version of the operating system that I have on my workstation. For more information, see What's Up with Active Directory Domain Services Cmdlets?

Note  If I install Active Directory Management Service for Windows Server 2008, I do not get access to the Active Directory module on the server. I must install the RSAT tools on my workstation for management purposes. For more information, see Install Active Directory Management Service for Easy PowerShell Access.

Usability

In my mind, the cmdlets from the Active Directory module are easy to use. They are a little quirky, but after I get used to the quirks, they simply make sense. Therefore, to create a new user in an organizational unit (OU) named testou in the Iammred.net domain, I type the following:

New-ADUser -Name mynewtestuser -Path 'ou=testou,dc=iammred,dc=net'
If I want to use the [adsi] type accelerator to create a new user, I type something like this:

$adsi = [adsi]"LDAP://dc=iammred,dc=net"

$de = $adsi.Create('user','cn=anothertestuser,ou=testou')

$de.setinfo()

One big problem with using this methodology (besides the fact that it is more typing and less intuitive), is the fact that tab expansion does not work properly. Therefore, some of the methods I want to use do not show up when I press the Tab key.

The advantage, of using the [adsi] type accelerator is that I can use it no matter what version of Windows AD DS is running in. I do not have to have the AD Management service installed, nor do I need a server running at least Windows Server 2008 R2. If my domain meets the minimum guidelines for using the Active Directory module, there is really no decision—I can use the module and use the cmdlets. They are easy, and they are powerful.

CB, that is all there is to using the Active Directory module. Join me tomorrow when I will talk about Windows PowerShell 3.0 in Windows 8. It is a way cool post, and a great way to continue your weekend. See you then.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Summary: Use a Windows PowerShell cmdlet to retrieve logged information about Windows PowerShell.

 How can I easily find logged information about Windows PowerShell?

 Use the Get-WinEvent cmdlet and look for a LogName with powershell in the name:

Get-WinEvent -LogName *powershell*

Summary: Microsoft Scripting Guy, Ed Wilson, concludes his five-part series about Windows PowerShell Workflow.

 Hey, Scripting Guy! I have a number of commands that I want to run against several remote servers. The commands include stuff that must happen prior to something else happening. But then, there are also some things that I would like to happen as fast as possible. Is this permissible? If so, do I have to write two different workflows?

—TB

 Hello TB,

Microsoft Scripting Guy, Ed Wilson, is here. This afternoon I am sipping an awesome cup of Oolong tea with a cinnamon stick, jasmine flower, and lemon grass. The flavor is just about perfect. In the background, I am listening to Ravel. Outside, the sky is dark and it is raining. The thunder seems to punctuate the music.

Note  This is the last post in a five-part series about Windows PowerShell Workflow for “mere mortals.” Before you read this post, please read: 

• PowerShell Workflow for Mere Mortals: Part 1
• PowerShell Workflow for Mere Mortals: Part 2
• PowerShell Workflow for Mere Mortals: Part 3
• PowerShell Workflow for Mere Mortals: Part 4

For more information about workflow, see these Hey, Scripting Guy! Blog posts: Windows PowerShell Workflow. 

Well TB, the good news is that you do not need to write two different workflows to enable parallel processing and sequential processing. Windows PowerShell Workflows are flexible enough to handle both in the same workflow.

Adding a sequence activity to a workflow

To add a sequence activity to a Windows PowerShell Workflow, all I need to do is use the Sequence keyword and specify a script block. When I do this, it causes the commands in the sequence script block to run sequentially and in the specified order.

The key concept here is that a Sequence activity occurs within a Parallel activity. The Sequence activity is required when I want commands to run in a particular order. This is because commands running inside a Parallel activity run in an undetermined order.

The commands in the Sequence script block run in parallel with all of the commands in the Parallel activity. But the commands within the Sequence script block run in the order in which they appear in the script block. The following workflow illustrates this technique:

workflow get-winfeatures

{

 Parallel {

    Get-WindowsFeature -Name PowerShell*

    InlineScript {$env:COMPUTERNAME}

    Sequence {

        Get-date

        $PSVersionTable.PSVersion } }

}

In the previous workflow, the order for Get-WindowsFeature, the inline script, and the Sequence activity is not determined. The only thing I know for sure is that the Get-Date command runs before I obtain the PSVersion because this is the order that I specified in the Sequence activity script block.

To run my workflow, I first run the PS1 script that contains the workflow. Next, I call the workflow and I pass two computer names to it via the PSComputerName automatic parameter. Here is my command:

get-winfeatures -PSComputerName server1, server2

The image that follows shows the Windows PowerShell ISE where I call the workflow. It also illustrates the order in which the commands ran this time. Note that the commands in the Sequence script block ran in the specified order—that is, Get-Date executed before $PsVersionTable.PSVersion. Also notice that they were in the same Parallel stream of execution.

Some workflow coolness

One of the cool things about this workflow, is that I ran it from my laptop running Windows 8. What is so cool about that? Well, the Get-WindowsFeature cmdlet does not work on desktop operating systems. Therefore, I ran a command from my laptop—a command which does not exist on my laptop, but it does exist on the target computers, Server1 and Server2.

Another cool workflow feature is the InlineScript activity. I am able to access an environmental variable from the remote servers. The InlineScript activity allows me to do things that otherwise would not be permitted in a Windows PowerShell Workflow. It adds a lot of flexibility.

TB, that is all there is to using Windows PowerShell Workflow and specifying Sequence information. This concludes Windows PowerShell Workflow week. Join me tomorrow when I will talk about Active Directory with Windows PowerShell.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy