Topic: PowerShell Remoting Continued

Notice: This post is a part of the PowerShell Monday series — a group of quick and easy to read mini lessons that briefly cover beginning and intermediate PowerShell topics. As a PowerShell enthusiast, this seemed like a beneficial way to ensure those around me at work were consistently learning new things about Windows PowerShell. At some point, I decided I would share these posts here, as well. Here’s the PowerShell Monday Table of Contents.

Last week was our initial discussion of PowerShell Remoting (PS Remoting). As it’s so necessary, I figured we’d keep with it for at least another week. Previously we used Invoke-Command to run a single command on a few remote computers. Let’s start today, by switching this around and sending a few commands, to a single, remote computer.

In this example, we start in section 1 (listed as <#1#>), by echoing the computer’s name, just as we did in last week’s PSMonday. In section 2, we assign the results of two mildly different commands to the $Folders and $FolderCount variables. $Folders will store the names of the directories on the current root drive, separated by commas. $FolderCount will store the number of directories on the current root drive. Once those variables are populated, we then echo their values, as part of two separate strings, in section 3.

Invoke-Command -ComputerName MEMSRV01 -ScriptBlock {
    <#1#>"**** $env:COMPUTERNAME ****"

    <#2#>$Folders = (Get-ChildItem -Path \ -Directory) -join ', '
    $FolderCount = (Get-ChildItem -Path \ -Directory).Count

    <#3#>"Root Drive Folders : $Folders"
    "Root Drive Folder Count : $FolderCount"
}

**** MEMSRV01 ****
Root Drive Folders : inetpub, PerfLogs, Program Files, Program Files (x86), support, Users, Windows
Root Drive Folder Count : 7

There is an option to assign the script block to a variable, and then use the variable as part of the Invoke-Command command. This might make the code a bit more readable. Here’s an example.

$ScriptBlock = {
    "**** $env:COMPUTERNAME ****"

    $Folders = (Get-ChildItem -Path \ -Directory) -join ', '
    $FolderCount = (Get-ChildItem -Path \ -Directory).Count

    "Root Drive Folders : $Folders"
    "Root Drive Folder Count : $FolderCount"
}

Invoke-Command -ComputerName MEMSRV01 -ScriptBlock $ScriptBlock

Either way you do it, these script blocks still have the potential to become rather lengthy. In this case, we might consider the -FilePath parameter. Instead of the -ScriptBlock parameter and a script block, Invoke-Command will read in the contents of a .ps1 file and run that against the remote computer.  Here’s the same code as above, that’s been saved as C:\ICMTestFile.ps1.

With this file in place, we’ll rerun the previous commands using the -FilePath parameter and the path to the file as the parameter value.

Invoke-Command -ComputerName MEMSRV01 -FilePath C:\ICMTestFile.ps1

**** MEMSRV01 ****
Root Drive Folders : inetpub, PerfLogs, Program Files, Program Files (x86), support, Users, Windows
Root Drive Folder Count : 7

As you begin to use Invoke-Command and want to run more and more commands, keep this option in mind. Now, with that said, I think it’s important to know that I don’t personally see the -FilePath option used much. Consider why. When writing your own scripts and functions, or reading someone else’s, you’ll have to go outside of the script or function file to view what Invoke-Command is doing, and that could become tiresome, and difficult when troubleshooting.

Topic: PowerShell Remoting

Notice: This post is a part of the PowerShell Monday series — a group of quick and easy to read mini lessons that briefly cover beginning and intermediate PowerShell topics. As a PowerShell enthusiast, this seemed like a beneficial way to ensure those around me at work were consistently learning new things about Windows PowerShell. At some point, I decided I would share these posts here, as well. Here’s the PowerShell Monday Table of Contents.

When Windows PowerShell 2.0 was released, it came with some welcoming new features. One of the biggest, was PowerShell Remoting. Let’s discuss PS Remoting in regard to two cmdlets: Enter-PSSession and Invoke-Command.

Enter-PSSession allows for a fully interactive PowerShell remoting session. It’s as though you’re sitting at the PowerShell prompt on the remote computer, with the ability to interactively enter commands and immediately see those results. Using Enter-PSSession is considered one-to-one PS Remoting. Here’s an example of using Enter-PSSession with the explanation beneath that.

Enter-PSSession -ComputerName DC01

[DC01]: PS C:\Users\tommymaynard\Documents> Set-Location -Path \
[DC01]: PS C:\> "**** $env:COMPUTERNAME ****"
**** DC01 ****
[DC01]: PS C:\> Exit-PSSession
PS C:>

Let’s discuss each of the above lines in this example. The first line is the command we used to connect to the DC01 computer. Once connected, we move to the root of the drive using the Set-Location cmdlet. This isn’t a requirement, but a shorter path will offer more area in which to type. Then, we instructed the computer to echo four asterisks, a space, the value stored in the computer name environmental variable, another space, and another four asterisks. This is proof, outside the computer’s name in square brackets at the left of the prompt, that we really are on the remote computer. Finally, we run Exit-PSSession to exit the PS Remoting session on DC01, and return to the local computer.

Invoke-Command allows you to send a command to a remote computer, have it run, and have the results sent back and displayed in your console, on the local computer. While you can do this against a single computer, this is considered one-to-many PS Remoting, and you’ll see why momentarily. The next example does the same thing as we did in the above, Enter-PSSession example.

Invoke-Command -ComputerName DC01 -ScriptBlock {"**** $env:COMPUTERNAME ****"}

**** DC01 ****

Invoke-Command has some great features: One, it can run against multiple computers, as you may have already picked up on, or simply knew, and two, it can do this at the same time. Now, there is a built-in limitation of 32 computers that it will run against at once; however, that can be changed with the -ThrottleLimit parameter and a parameter value of something other than 32.

Invoke-Command -ComputerName DC01,DC02,DC03,DC04 -ScriptBlock {"**** $env:COMPUTERNAME ****"}

**** DC01 ****
**** DC04 ****
**** DC02 ****
**** DC03 ****

Because this last example ran against multiple computers at once, you won’t always get the results back in the order you might expect. This is because it’s up to how quickly each computer can be reached, how quickly each command(s) can be run, and how quickly each computer can send the results back to the local computer. This command above could’ve been written as is shown below.

Invoke-Command -ComputerName (Get-ADDomainController -Filter *) -ScriptBlock {"**** $env:COMPUTERNAME ****"}

**** DC01 ****
**** DC02 ****
**** DC04 ****
**** DC03 ****

Start to consider all those times you use Remote Desktop. Are there times you can skip that somewhat lengthy process, and instead return the results you’re after, using PowerShell Remoting?

Topic: Less Used Variable Properties Continued II

Notice: This post is a part of the PowerShell Monday series — a group of quick and easy to read mini lessons that briefly cover beginning and intermediate PowerShell topics. As a PowerShell enthusiast, this seemed like a beneficial way to ensure those around me at work were consistently learning new things about Windows PowerShell. At some point, I decided I would share these posts here, as well. Here’s the PowerShell Monday Table of Contents.

Last week we discussed the option of making our variables read-only. This means that without the -Force parameter, read-only variables cannot be overwritten, cleared, or deleted. This level of protection for our variable’s values is good, but it might not be the best option in some cases. Today we’ll focus on the constant option for the Options property. Let’s first create a new variable, verify it’s a constant, and then try to change its value.

New-Variable -Name String6 -Value "Here’s a new Monday variable." -Option Constant

(Get-Variable -Name String6).Options
Constant

Set-Variable -Name String6 -Value 'Can we change it?'

Set-Variable : Cannot overwrite variable String6 because it is read-only or constant.

As mentioned, with a read-only variable, we used the -Force parameter to overwrite, clear, and delete, and it worked. Let’s try that with our constant variable.

Set-Variable -Name String6 -Value ‘Can we change it?' -Force

Set-Variable : Cannot overwrite variable String6 because it is read-only or constant.

Even with the -Force parameter we can’t change the variable’s value. Let’s attempt to clear it (remove its value), with the -Force parameter.

Clear-Variable -Name String6 -Force

Clear-Variable : Cannot overwrite variable String6 because it is read-only or constant.

No luck. In both cases we get the same error. Let’s try to remove the variable in its entirety.

Remove-Variable -Name String6 -Force

Remove-Variable : Cannot remove variable String6 because it is constant or read-only. If the variable is read-only, try the operation again specifying the Force option.

Still no luck, although we did get a mildly different message. If you create a variable that’s a constant, you can’t get rid of it, or modify it, until you end the PowerShell session; however, if it’s read-only, you’ll have some protection, and still be able to modify things, if necessary. Keep these options in mind, as you may find yourself wanting to add some protection, to your otherwise do-anything-you-want-to-them-at-any-time variables.

Bonus: Last week we saw that we were able to create a variable and then make it read-only. When we create a constant variable, the option has to be applied when the variable is first created. If you create a variable and then try to make it constant, you’ll receive the below error.

Set-Variable : Existing variable String7 cannot be made constant. Variables can be made constant only at creation time.

Topic: Less Used Variable Properties Continued I

Notice: This post is a part of the PowerShell Monday series — a group of quick and easy to read mini lessons that briefly cover beginning and intermediate PowerShell topics. As a PowerShell enthusiast, this seemed like a beneficial way to ensure those around me at work were consistently learning new things about Windows PowerShell. At some point, I decided I would share these posts here, as well. Here’s the PowerShell Monday Table of Contents.

As was mentioned last week, variables have some properties we don’t often use, and many of us, may not even know about them. Last week we briefly learned about the Description property of a variable, and today, we’ll start to learn about the Options property.

While a variable’s Options property is set to None by default, there’s at least two other possibilities, and one of them, is ReadOnly. The first example uses New-Variable to create a new, read-only variable named String3, and Get-Variable and Select-Object to return all the variable’s properties.

New-Variable -Name String3 -Value 'A new week; another Monday.' -Option ReadOnly

Get-Variable -Name String3 | Select-Object *

Name        : String3
Description :
Value       : A new week; another Monday.
Visibility  : Public
Module      :
ModuleName  :
Options     : ReadOnly
Attributes  : {}

Now, what does it mean that it’s read-only? It means that we can’t change the value that’s stored by the variable, as is indicated below.

Set-Variable -Name String3 -Value 'A new week; another Friday!'

Set-Variable : Cannot overwrite variable String3 because it is read-only or constant.

Notice in the error message that it indicates we can’t overwrite the variable because the variable is read-only or constant. It turns out that we actually can change the value stored in a read-only variable, if we use the -Force parameter.

Set-Variable -Name String3 -Value 'We Want Friday!' -Force

Get-Variable -Name String3 | Select-Object *

Name        : String3
Description :
Value       : We Want Friday!
Visibility  : Public
Module      :
ModuleName  :
Options     : ReadOnly
Attributes  : {}

So, in the end, a read-only variable can be overwritten if absolutely necessary. Keep this read-only option in mind as you create variables in Windows PowerShell. There may be times you create variables and want to mostly protect the original, stored value. In that case, you can choose to make them read-only.

If we already have a variable created, how do we then make it read-only? We have to use Set-Variable, whether we created the variable with New-Variable, or the standard way, as is used below.

$String4 = 'Last variable for today.'
$String4

Last variable for today.

(Get-Variable -Name String4).Options
None

Get-Variable -Name String4 | Set-Variable -Option ReadOnly

(Get-Variable -Name String4).Options
ReadOnly

To clear a variable’s value (to continue to allow a variable to exist, but to remove the value it stored), we have to use the -Force parameter. Same goes for removing the entire variable; that will also require the -Force parameter if it’s a read-only variable.

Clear-Variable -Name String3 -Force

Remove-Variable -Name String4 -Force