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...

Use Windows PowerShell to get the BitLocker recovery key. ...( read more )

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...

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...