Heads up - Due to popular demand, I've rewritten this article to include a more elegant solution for vRA 7.x - it's available here.
Hello again. In Part 1, we covered the concept and the requirement for this solution.
In a nutshell, this is a scalable solution to easily integrate with Microsoft DNS in a fashion that requires no additional servers, appliances or configurations, other than the DEM machines.
Prerequisites
Obviously, we need to jump through a few hoops in order to enable the functionality we need on the DEMs.
WinRM on the DEMs
First off, we need to make sure our DEMs are capable of running remote Powershell CmdLets. To do this, we open a powershell prompt and type in:
WinRM quickconfig
This sets up the basics for WinRM.
WinRM on the DNS Server
You will need to enable WinRM on the DNS Server as well. This is done by doing the same bit above. In some cases, you will need to specify the DEMs as trusted hosts. This is achieved by running the following:
winrm set winrm/config/client '@{TrustedHosts="DEMServerA,DEMServerB"}'
Note: Don't copy and paste - rather open a prompt and type it out - the CLI often misinterprets unicode vs ascii characters or expects something slightly different and fails on character mismatches.
RSAT - DNS
Now, listen up. If you're running Windows Server 2012 or greater on your DNS Servers, you need to enable the CmdLets for DNS on the DEMs. Why? Well, we're using built-in Microsoft Powershell CmdLets, already built for us, to create the remote DNS entries.
How does this happen?
We leverage a CmdLet called Add-DnsServerResourceRecordA.
Why only for 2012 or greater? You'll see in the scripts that we use the above for 2012, but this is not supported on 2008 or 2008 R2 servers, which is when we use DnsCmd.exe.
Incidentally, I read somewhere that this approach is being deprecated, hence the forward-looking support for Powershell Cmdlets.
Again. If you're using 2008 or 2008 R2 on your DNS Server, you can skip this part.
In order to enable the Cmdlet, we need to install the RSAT (Remote Server Administration Tools) Feature within Windows, specifically for DNS:
Ports and Networking Concerns
This particular solution uses WinRM. The Powershell files are open for you to see what's in them. In particular, the ports for a CimSession or Powershell Remote Execution are as follows:
| Source | Dest | Port | Type | Description |
|---|---|---|---|---|
| DEM(s) | DNS Server(s) | 5985 | TCP | WinRM (HTTP) |
| DEM(s) | DNS Server(s) | 5986 | TCP | WinRM Secure (HTTPS) |
Installing the Extension
The prerequisite to this step is to download the files. These can be found here in a zip archive.
Download and Extract the Files onto a Manager Server
Copy all of these files, and paste them on a manager server. Then establish a remote session on the relevant manger server.
You'll find these files in the zip:
- VirtualNebula.DNS.Integration.CreateEntry.xaml
- VirtualNebula.DNS.Integration.RemoveEntry.xaml
- VirtualNebula.DNS.Integration.CreateEntry.Script.ps1
- VirtualNebula.DNS.Integration.RemoveEntry.Script.ps1
- VirtualNebula.DNS.Integration.Provision-hook.xml
- VirtualNebula.DNS.Integration.Disposing-hook.xml
There are 3 parts to installing these extensions:
- Install the XAML workflows in the Repository.
- Install the Powershell Files (ps1) in the Repository.
- Paste the XML Workflow hooks into the XmlDb.
Installing the XAML files
"C:\Progam Files (x86)\VMware\vCAC"Open up a Powershell (or Command) Prompt and Change Directory to this folder. From there, we need to find the Model Manager Data Folder:
[Drive]:\[InstallPath]\VMware\vCAC\Model Manager Data\Once you have this, execute the following command:
.\RepoUtil.exe Workflow-Install -n "VirtuaNebula.DNS.Integration.CreateEntry" -f "[path to]\VirtuaNebula.DNS.Integration.CreateEntry.xaml" –d "Creates a Microsoft DNS Entry"
Next, we install the second workflow by running the following command:
.\RepoUtil.exe Workflow-Install -n "VirtuaNebula.DNS.Integration.RemoveEntry" -f "[path to]\VirtuaNebula.DNS.Integration.RemoveEntry.xaml" –d "Removes a Microsoft DNS Entry"Installing the Powershell files
The first thing you'll need to do is edit the Powershell Files.
Be sure to change the path to reflect the correct path where you installed your DEM Worker.
There are smarter ways to do this (like doing a search for the DLL on the machine) but I feel that overhead can be avoided. Also, using the "current directory" tends to resolve as the system32 folder, but that can also be avoided. Up to you - if you want to get fancy, have at it :-)
The code in grey indicates commented code that I created to use the current DEM hostname as a means to determine the installation path for the scenario I was experiencing.
[Drive]:\[InstallPath]\VMware\vCAC\Server\ToolsRun the following command to install the powershell script for the first workflow:
.\CloudUtil.exe File-Import -n "VirtualNebula.DNS.Integration.CreateEntry.Script" -f "[path to]\VirtualNebula.DNS.Integration.CreateEntry.Script.ps1" –d "Script to create a Microsoft DNS Entry"
Now, run the following command to install the powershell script for second workflow:
.\CloudUtil.exe File-Import -n "VirtualNebula.DNS.Integration.RemoveEntry.Script" -f "[path to]\VirtualNebula.DNS.Integration.RemoveEntry.Script.ps1" –d "Script to delete a Microsoft DNS Entry"
**Note: If the above “CloudUtil.exe” or “Tools” directory does not exist, install the vRA Designer Application (found at the bottom of the vRA IaaS Installer page), and use CloudUtil.exe in the installation path once installed.
Configuring the Workflow Hooks
[Drive]:\[InstallPath]\VMware\vCAC\Server\ExternalWorkflows\xmldbOnce located, copy these two ".xml" files from the zip you downloaded earlier:
VirtualNebula.DNS.Integration.Provision-hook.xml
VirtualNebula.DNS.Integration.Disposing-hook.xml
and paste them there.
Required Custom Properties
| Property Name | Description | Value Sample |
|---|---|---|
| VirtualNebula.DNS.Integration.Server | ** Gating Property ** Defines the Server on which to create the DNS entry | IP or FQDN "10.1.1.2" or "dc01.domain.com" |
| VirtualNebula.DNS.Integration.ZoneName | The Forward Lookup Zone in which to create the entry | "domain.com" |
| VirtualNebula.DNS.Integration.AdminUsername | Domain Administrator User account | "Administrator" for local domain, else "DOMAIN\Administrator" |
| VirtualNebula.DNS.Integration.AdminPassword |
Password for the user account to create a DNS entry. This property MUST be encrypted (select 'Encrypted' when entering the property in vRA) | ************ |
| VirtualNebula.DNS.Integration.Is2012orGreater |
Whether the target DNS Server is a Windows 2012 server or greater. Eg. if the DNS Server is a 2008 R2 server, the value is false. If you're not sure, leave it as false. | "true" or "false" |
The above properties can be placed in a Build Profile or at the Blueprint level.
Additional Information / Tweaks
By now, I'm pretty sure you've figured out that the states in question here are "Provisioned" and "Disposing". The reason I chose "Provisioned" is simply because by this stage, we are certain that the machine has an IP, has gone through custom naming (if any) and has an operating system provisioned. The caveat here is that if the Customization Spec has already been applied to the guest O/S (in the case of Windows), the machine was probably already joined to the domain. In this case, the DNS entry was most likely already created too.
Changing the Lifecycle Phase
If you find that this is the case, simply change the contents of the "VirtualNebula.DNS.Integration.Provision-hook.xml" XML file to to reflect "BuildingMachine" and also modify the phase and save it as follows:
<plugin fullName="DynamicOps.External.RepositoryWorkflows.InvokeRepositoryWorkflow" priority="2"> <MasterWFStateCriteria>BuildingMachine</MasterWFStateCriteria> <MasterWFTypeFullNameCriteria>*</MasterWFTypeFullNameCriteria> <ExecuteWhen>PostActivityExecution</ExecuteWhen>
Don't use "Write-Host"
I know you may want to debug, but don't use "Write-Host" in the Powershell Files. It fails. If you want to see information, write to a file somewhere.
Feel free to ping me