Yup. SSH. You read right.

In this article, I'll be explaining how to execute Remote Powershell over SSH.
Naturally, this applies to Active Directory and DNS as well as anything that you plan to manage using Powershell.

Why Powershell? Well, many times I've walked into a customer's environment and seen a ton of investment in Powershell for varying levels of automation. Also, you'll often find that Windows gurus know Powershell but not necessarily Python and YAML (Ansible) or Javascript (vRO) for automation. This is where it becomes easy to automate provisioning or cleanup if we use something like vRO, Ansible, Chef, Puppet, etc.

Regardless of the investment, here's the truth about DNS: it has no real API that we can easily leverage except through Powershell. I'm about to show you how to bind this all together elegantly and easily.

Use case 1: vRA/vRO and Microsoft DNS

So, if you've read my previous articles on vRA 6 and integration with DNS, this post replaces those since they're dated and the method used in 6 is no longer advised in 7:
Microsoft DNS Integration with vRA: Part 1 &
MICROSOFT DNS INTEGRATION WITH VRA: PART 2

Onwards with new stuff.

What you'll need

Windows Server with DNS installed and operational.
Another Windows Server, we'll call this one the mediator
- Bitvise SSH server installed (more on this below)
- RSAT enabled (more on this below)
vRA and vRO already configured.
Connectivity from vRO to the mediator (port 22, TCP)
Connectivity from the mediator to the DNS server(s) for RPC and DCOM using TCP ports 135, 445, 1024-1034
- technet article

Right, so in vRA 7, you know there's the event broker, and that we effectively hook up events during the lifecycle of a VM to call out to a vRO Workflow when conditions are met. So why aren't we using vRO's Powershell plugin? The simple answer is just "trust me".

The Mediator

This is what we're calling our intermediary Windows server, with Powershell and stuff installed on it.

Bitvise SSH Server

On this mediator Windows Server, we need to install a product called Bitvise SSH Server.
You can probably get away with free or open source SSH Servers on Windows, but they are not common and not really that reliable. You can find Bitvise SSH Server here. At the time of this writing, the cost is around $100 for a license.
I've used Bitvise before and it works, but in the end I'm not endorsing a product here - it's your choice. We simply need a reliable SSH Server installed, listening for SSH connections.

Once you've configured your SSH Server, decide how you want to authenticate against it. This could be via Server Key, Service Account, Builtin Login etc.

RSAT (Remote Server Administration Tools) Feature

Another thing we need to install on the Mediator server is the RSAT tools. This is as simple as enabling the feature on Windows 2012. Remember that we could also remotely administer AD if we wanted to use this feature.

Note: Installing this feature will not create a new DNS Server on the Mediator. It will simply install the MMC snapin and the relevant Powershell Modules so that we can remotely administer the relevant system. If you selected AD, it would also install the relevant MMC snapins for AD.

Enabling RSAT Feature on Windows Server 2012

Once your RSAT Feature is installed, you should be good to go. I'd also take the liberty of ensuring you have the latest patches and Powershell versions installed, and you should be ready to continue on to the next section: executing your scripts.

Below, I took the liberty of creating a quick flow diagram showing how vRO will initiate a call via SSH to the Mediator. Bitvise listens for commands and executes whatever you tell it to. In this case, we can simply execute the relevant DNS commands to add or remove an entry. Consider:

Add-DnsServerResourceRecordA -Name "host23" -ZoneName "contoso.com" -AllowUpdateAny -IPv4Address "172.18.99.23" -TimeToLive 01:00:00

More Powershell commands for DNS management here.

Use Case 2: Ansible and Active Directory

In this use case, you might not be using vRO, but rather something like Puppet, Chef or Ansible to perform your automation. Either way, the principle is identical.

You may ask "Why don't you simply use the WinRM feature in Ansible to execute AD CmdLets?". Well, because it's complex and requires changes to the AD Server in most cases. Here's a list of reasons we'd want to use SSH and the Bitvise solution above as opposed to WinRM:

Active Directory Servers need WinRM installed and configured
Ports needs to be opened for 5985/5986 from Ansible hub to AD servers
If Authentication fails, you need to to enable CredSSP on the AD servers
Firewall or security constraints

What you'll need

Operational Active Directory Server(s) and domain(s)
Another Windows Server, we'll call this one the mediator
- Bitvise SSH server installed (more on this below)
- RSAT enabled (more on this below)
Ansible already installed and configured
Connectivity from Ansible hub to the mediator (port 22, TCP [SSH])
Connectivity from the mediator to the AD server(s) for RPC and DCOM using TCP ports 135, 445, 1024-1034
- technet article

Right, so in vRA 7, you know there's the event broker, and that we effectively hook up events during the lifecycle of a VM to call out to a vRO Workflow when conditions are met. So why aren't we using vRO's Powershell plugin? The simple answer is just "trust me".

The Mediator

Follow the section in the first Use Case above. The principle is identical. You need an SSH Server listening on your mediator server and you need the relevant AD CmdLets (RSAT) in order to remotely administer Active Directory. In the sample image above, in that section, instead of installing DNS, simply choose Active Directory.

Below is a diagram depicting the flow from Ansible to Active Directory. The idea is execute a Powershell command on the Mediator over SSH from Ansible. It's really pretty simple. In terms of authentication, you can actually configure Bitvise to execute on the behalf of a service account. This means that whatever Powershell you execute via Bitvise, that Service Account will need privileges to administer the relevant OUs or Domains in question.

Now that your mediator is set up, it's time to consider the Powershell you'll be executing to manage Active Directory. For example:

New-ADComputer -Name "FABRIKAM-SRV2" -SamAccountName "FABRIKAM-SRV2" -Path "OU=ApplicationServers,OU=ComputerAccounts,OU=Managed,DC=FABRIKAM,DC=COM"

or...

Remove-ADComputer -Identity "FABRIKAM-SRV2"

The YAML (Ansible)

---
# Run the command locally
- name: Run SSH Powershell Command to Remove Computer
  command: "ssh -q user@mediator.local 'SomeScript.ps1 {{ machine_name }}'"
  register: psresult
  delegate_to: 127.0.0.1

# Show the output
- name: Debug the result
  debug: var=psresult

Consider the above YAML. We're executing an SSH command straight from the Ansible hub (Linux). For the user, this will need to be either a service account or a local user on that server.

Either way, you will need to replace "mediator.local" with the FQDN or IP of the Mediator Server. In addition, SomeScript.ps1 will be a script you write and copy locally on that Mediator Server. You can also simply execute commands individually - you don't need an actual script to run.

The {{ machine_name }} portion is a variable in Ansible. Typically, this might be a machine you are currently destroying, and Ansible is cleaning up. Either way, the use cases are vast but I hope this principle helps you like it's helped me in the past!