Using PowerShell Remoting to Manage Multiple AppAssure Core Servers

In my last blog, I was logged directly into an AppAssure Core server via remote desktop and was running PowerShell commands in the PowerShell console directly on the server. Managing your servers by RDPing directly into them is a bad practice in my opinion. In this blog, I’ll explore a few options that could be used to manage an AppAssure Core server with PowerShell without having to resort to logging directly into it with Remote Desktop.

Note: All of the following examples require PowerShell remoting to be enabled on the remote AppAssure Core servers. PowerShell remoting has already been enabled on the servers in the following scenarios by running Enable-PSRemoting on each of the servers. All of the servers in this scenario are running Windows Server 2008 R2, if they were running Windows Server 2012, PowerShell remoting would be enabled by default.

The first option to manage a single AppAssure Core server at a time via PowerShell remoting is to select the “New Remote PowerShell Tab” from the file menu of the PowerShell version 2 or version 3 ISE (Integrated Scripting Environment):

appassure117-1

This is basically the same thing as using the Enter-PSSession PowerShell cmdlet to enter a 1 to 1 remoting session in the PowerShell console.

Another option is to use implicit remoting. In the following example, I’m using the New-PSSession cmdlet to create a persistent connection to one of my remote AppAssure Core servers. This portion of the command is inside of the parenthesis so it executes first and then the results of it are used as the input for the Session parameter of Import-PSSessison. The Import-PSSession cmdlet, in this example, is used to import the cmdlets from the AppAssurePowerShellModule from the remote session that was created by the New-PSSession cmdlet into the current session. Later on, I’ll show that these imported cmdlets are created as functions temporarily in the local session almost like shortcuts to the actual cmdlets on the remote server that the module is actually located on.

appassure117-2

If you tried this same syntax on a remote server that has PowerShell version 2 installed, it will generate an error as shown in this example where I’m attempting to import the ActiveDirectory module from a server that only has PowerShell version 2 installed:

Import-PSSession : Running the Get-Command command in a remote session
returned no results.
At line:1 char:1
+ Import-PSSession -Session (New-PSSession -ComputerName dc01) -Module
ActiveDire …
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidResult: (:) [Import-PSSession], ArgumentException
+ FullyQualifiedErrorId : ErrorNoResultsFromRemoteEnd,Microsoft.PowerShell
.Commands.ImportPSSessionCommand

appassure117-21

When the remote server is running PowerShell version 2, the module will need to be imported and it’s much easier to accomplish with multiple lines instead of a one liner:

appassure117-22

Back to our AppAssure scenario, the following example is being run on my local computer which doesn’t have the AppAssurePowerShellModule installed. Except for some formatting issues with the default output, you would never know that this module isn’t installed:

appassure117-3

The really cool thing is I can import this same AppAssure PowerShell module from more than one AppAssure Core server, each with different credentials, and use the -Prefix parameter to have different prefixes added to the cmdlets from the different servers:

appassure117-4b

Now I can run a PowerShell one liner which will execute against the three different AppAssure Core servers that are in different Active Directory domains, use the necessary credentials for each domain, and return results for all of the AppAssure agents:

appassure117-5a

Here’s a list showing the cmdlets from this module that are added to the local computer temporarily as functions which are kind of like shortcuts to the actual cmdlets on the AppAssure servers that I’ve created the persistent connections to. Notice the cmdlets have site1, site2, and site3 prefixes. This is how I can have the same module imported multiple times and how PowerShell knows which server to send the command to:

appassure117-6a

The last option that I’ll demonstrate and probably the simplest is to use the PowerShell remoting Invoke-Command cmdlet for one to many remoting. At first I didn’t think I would be able to use Invoke-Command due to the requirement in this scenario to use different credentials for each server. I figured it out though, and here’s how to use it.

Store each of the persistent connections in a variable using the necessary credentials (different credentials) for each of the three AppAssure Core servers in this scenario:

appassure117-7

Use the -Session parameter with Invoke-Command and specify the variables instead of using the -ComputerName parameter and computer names (What I normally use):

appassure117-8

Automagically, you have results from all three servers using the three different persistent connections that were created and the different credentials are used for each one.

µ

Leave a Reply

%d bloggers like this: