• Introduction
• Lab Environment
• Initial Windows Cluster setup
• Clustering the WinRM service
• Adding the cluster to vRO
• Test vRO PowerShell execution and cluster failover

Introduction

In this post we will take a look how to build and configure a highly available PowerShell host for vRO. The vRO PSHost has always been a single point of failure in a in a clustered (distributed) vRO setup. To accomplish this goal we will be utilizing the Microsoft Windows Failover Clustering feature in Windows Server. In of node/datacenter failure the currently executing PowerShell commands will fail, but subsequent PowerShell commands will continue.

If you want to know how to prepare the Windows PowerShell host or use CredSSP with vRO , visit Using CredSSP with the vCO PowerShell Plugin
If you want to add a PowerShell host with an account other then the default domain administrator account, visit Adding vCO Powershell Host with account other than the default domain administrator account
If you want to know how to add PowerShell hosts from multiple domains, visit How to add PowerShell hosts from multiple domains with Kerberos authentication to the same vRO

The setup in this can be easily used to satisfy the following 2 use cases:

• Use Case 1: Have a highly available vRO Cluster and highly available vRO PSHost in the same site. This setup is located in one site (datacenter/geographical location) . This will allow business continuity in the event of failure of a vRO Cluster node or PowerShell Cluster Node in the same site.



• Use Case 2: Have a geographically (datacenter) dispersed (stretched) vRO setup which utilizes the Multi-Node Plug-in and a geographically (datacenter) dispersed (stretched) and highly available vRO PSHost setup. This setup is distributed across two sites (datacenter/geographical location). This will allow business continuity in the event of failure of a vRO Cluster node or PowerShell Cluster Node in the same site or in the event of failure of the whole datacenter. 

>
>
>

 

Lab Environment

The following environment has been used in all of the examples below:

• Active Directory Domain called vmware.com
• Windows Server 2012 R2 (with FQDN lan1dc1.vmware.com)
  • Domain Controller
  • DNS Server.
  • PowerShell v4 Host.
  • .NET 4 Framework installed (4.0.30319)
• Windows Server 2012 R2 (with FQDN lan2dc1.support.vmware.com)
  • Domain Controller
  • DNS Server.
  • PowerShell v4 Host.
  • .NET 4 Framework installed (4.0.30319)
• Windows Server 2008 R2 SP1 (with FQDN lan1dm1.vmware.com)
  • Domain Member
  • PowerShell v3 Host.
  • .NET 4 Framework installed (4.0.30319)
• vCO 5.5.1.0 Virtual Appliance (with FQDN vco-a-01.vmware.com)
  • vCO PowerShell Plugin installed (version 1.0.6.2283945)

The full lab logical design can be seen HERE.

 

Initial Windows Cluster setup

For the further purpose of this lab the following setup has been set as prerequisite:

• Windows Server 2012 R2 (name: ps-clu-01a, IP: 172.16.50.53) jointed to domain (vmware.com) .DNS A/PTR record added to DNS.
• Windows Server 2012 R2 (name: ps-clu-01b, IP: 172.16.50.54) jointed to domain (vmware.com). DNS A/PTR record added to DNS.
• WinRM has been configured on both windows machines as per the following blog post. CredSSP specific steps have not been configured and are not mandatory to demonstrate general PoC of this lab, but are recommended to be executed:

Using CredSSP with the vCO PowerShell Plugin

• A 2 node Windows Failover cluster with the following characteristics has been build:
• Cluster name used to build the cluster is ps-clu-01 (172.16.50.55) and a corresponding DNS A/PTR records have been created  

• Added one (iSCSI) disk as available storage. This disk can be used to store PowerShell scripts or other content that needs to be available when you execute your PowerShell scripts.
• Added one (iSCSI) disk as quorum disk. This disk will be needed to build a Quorum,
• Cluster quorum settings have been set to use a disk Witness in Quorum. 

For general information how to build a Windows Failover Cluster please visit,
Create a Failover Cluster

Clustering the WinRM service

At this point you should have built a two node Microsoft Windows Failover Cluster.
No lets look how to cluster the WinRM service used by vRO to execute PowerShell commands.
Open the Failover Cluster Manager console and connect to your cluster , in this example this is ps-clu-01.vmware.com
Expand the cluster name and navigate to Roles

Click the Before you begin page click Next.
Click the Select Role page select Generic Service and click Next.

Click the Select Service page select Windows Remote Management (WS-Management) Service and click Next.

On the Client Access Point page select a name for this CAP and an ip address under which this service will be reachable. In this example I will select ps-clu-01-winrm as name and 172.16.50.56 as IP Address.
Click Next

Click the Select Storage page optionally select the storage disk that you have shared with your cluster nodes and want to assign to this clustered role. Again this will be the shared storage where you can put your ps scripts or other content used by your scripts.
Select the disk and click Next.

Click the Replicate Registry Settings page click Next.
Click the Confirmation page click Next.
Wait for the setup to finish and click Finish
After successful setup, while on the Role tab, you should see the ps-clu-01-winrm role. Select the Role and you should see the resources assigned to this role.

As you can see form the screenshot the one of the nodes will be the current owner of the ps-clu-01-winrm role. In this case this is ps-clu-01b node. This means that the Windows Remote Management (WS-Management) service should be running on node ps-clu-01b and stopped on ps-clu-01a (or all other nodes)

 

Adding the cluster to vRO

Now after we have a working Windows failover cluster and we have clustered the WinRM service, lets add the Powershell Host Cluster in vRO.
Login to vRO and start the Add a Powershell host workflow.
On the powershell host tab enter:

• For name type the name for this PSHost. In our example this is: ps-clu-01-winrm
• For Host/IP type the name of the WInRM clustered service. In our example this is: ps-clu-01-winrm.vmware.com
• For Port type the port with that you want to use for the WinRM connection (5985 for HTTP, 5986 for HTTPS). In our example (and for simplicity) we will be adding the host with HTTP: 5985

Click Next
On the Host Type tab select:

• PowerShell remote host type: WinRM
• Transport Protocol: HTTP
• Authentication: Kerberos

Click Next
On the User Credentials tab select:

• Session mode: Shared Session
• User name: <select user name with enough credentials that will be used to add the PSHost>
• Password: <type a password for the credentials selected>

 

Click Next

 

Test vRO PowerShell execution and cluster failover

Now lets test the execution and failover.
Star the Invoke a Powershell script workflow.
Select the ps-clu-01-winrm PS host we have just added and click Next.

On the Script page, type : get-content env:computername
This command will return the hostname of the computer on which it is being run. This way we can determine on which cluster node we are executing the command.
Click Submit

You should see output similar to the following showing on which node the command executed. In this case this was node PS-CLU-01B. Remember that this was the node currently owning the ps-clu-01-winrm role:

Now lets transfer the ownership of the ps-clu-01-winrm role to the other node ps-clu-01a.
To do this go back to the Failover Cluster Manager and navigate to Roles.
Right click the ps-clu-01-winrm role and select move > Select Node.
Select the ps-clu-01a node and click OK

After few seconds you should see that the owner of the ps-clu-01-winrm role has changed to node ps-clu-01a.

Go back in vRO and run the Invoke a Powershell script workflow and use same input values as before.
This time the output show that the execution took place on ps-clu-01a which is the current owner of the ps-clu-01-winrm role

You can do a more comprehensive test by Powering off the current ps-clu-01-winrm role and running again the vRO workflow . The execution should success and the return result should point that the execution took place on the active node.

 

DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Photos
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Recipes
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Downloadable Files
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.