By: Chris Alleaume, Trimax Americas / Dataglove Inc.
INTRODUCTION
In particular use cases, customers using vRealize Automation either decide not to use IPAM or perhaps have an isolated environment while there is a need to integrate with Microsoft DNS Servers directly.
Throughout the last few years in the field, I’ve never really come across a rock-solid way to integrate vRA with MS DNS that didn’t involve pulling my hair out and crying in frustration while my head hurt from hitting it against the wall repeatedly.
More accurately, I haven’t come across a viable solution to this problem that addressed my customers’ needs until now.
In this article, I’ll be covering a much less painful way to integrate with MS DNS.
CONTEXT
I recently addressed a use case exposing a requirement to create a Microsoft DNS A record (with PTR) whenever a virtual machine is provisioned through vRA.
Now, normally, when using Active-Directory integrated DNS, when a (windows) machine joins a domain, the DNS entry is created.
But what about different operating systems? Nothing.
My particular use case, in fact, involved the potential to create an A-Record in one of over 100 disparate domains at provision time.
The result is a solution that has the proven ability to connect to remote DNS Servers in different domains.
Now, you’re probably aware that there is no Microsoft DNS plug-in for vRO. Yes, there’s a powershell plug-in for vRO, but it fell short of the mark on a few counts.
It’s easy enough to write this solution in C#, but that leaves the code compiled and less editable.
So I figured I would do this using Powershell which will run on the DEM(s).
MISCONCEPTIONS
Let’s first clear something up. I was questioned time and again as to why I didn’t just use the vRO plug-in for Powershell. Well, there are a number of reasons:
In a production environment with sensitivity to the already cumbersome, load-balanced, highly available implementation, we had Identity (SSO1), vRA1, vRA2, vRO1, vRO2, SQL 1, SQL 2, IaaS1, IaaS2, DEM1 and DEM2. That’s a fair amount of VMs. Then we had load balancers. The DEMs live in a separate VLAN. The reasons for this design are many, not in the scope of this article.
Suffice it to say that the vRO powershell plug-in was not an option and it does not scale well and does not abide by a highly available design without a good deal of customization.
THE SOLUTION
This is a summary. More detail on my blog.
The solution is a relatively simple one. It involves creating powershell that executes on the DEMs. This design inherits the Highly-Available design of the IaaS portion of vRA.
We don’t need powershell hosts, because the DEMs are Windows Servers which will double up as powershell hosts inherently.
The DEMs effectively execute a workflow which, in turn spits a bunch of custom properties at a powershell script as arguments.
This powershell script establishes a WinRM Session against the DNS server and executes the relevant command to create a DNS entry on the destination server, in the specified zone.
It takes into account the differences between Windows 2008 and Windows 2012, and uses DnsCmd.exe where necessary to address the limited support for the relevant snap-ins in 2008 / 2008 R2.
An excerpt of my script shows these commands:
Similarly, when a machine is disposed of, another script is executed to remove the above record in a similar fashion.
SECURITY
I’ve seen a few solutions in the past and one of the constant struggles is around secure management of credential information.
This particular solution decrypts passwords (stored as encrypted custom properties) from vRA.
This mitigates the risk of passing clear-text passwords across the solution and provides peace of mind.
DETAILS
For the details and to download the package containing all the files required,
I have a two-part article detailing this topic on my blog site: www.virtualnebula.com
