Recently I had an issue with vRealize Automation communicating with my SQL Server.  Unfortunately, the IaaS database plays a fundamental part in any vRA installation, so any problem with it will severely limit your deployment.

My particular issue involved vRA’s inability to create reservations on endpoints, in particular vCenter.  From the errors observed in the IaaS log, it became apparent very quickly that this was down to a communication failure with Microsoft DTC.

Despite following the recommendations in VMware’s knowledgebase article 2089503, the IaaS server was continuing to have issues.  Running DTCping on both servers gave no errors, but the more thorough DTCtester refused to work.

The SQL server showed a number of incoming DTC transactions, however 99.9% of them showed as aborted.  The issue was clearly not down to communication, but something else.  Authentication maybe?

It then occurred to me that both boxes being in different domains had something to do with it.

The workaround

Unfortunately with both servers being in different domains, the workaround is not very pretty, or more worryingly, secure.

It involves lowering the security of both servers by disabling authentication.  In anything other than a lab environment, you might want to seek further advice before implementing this.

On both servers, access the MSDTC properties and click the Security tab:

In the Transaction Manager Communication box, click the No Authentication Required radio button.

To achieve the same in PowerShell, using the following:

# Variables

$msdtcKey = Get-ChildItem “Registry::HKEY_LOCAL_MACHINE\Cluster\Resources” | Where-Object {([string](Get-ItemProperty -path “Registry::$_”).”Type”) -match “Distributed Transaction Coordinator”}
$key1 = "FallbackToUnsecureRPCIfNecessary"
$key2 = "TurnOffRpcSecurity"

Set-ItemProperty -path “Registry::$msdtcKey\MSDTCPRIVATE\MSDTC” -name $key1 -Value 0
Set-ItemProperty -path “Registry::$msdtcKey\MSDTCPRIVATE\MSDTC” -name $key2 -Value 1

I’d like to thank my good friend John Yates for spending a few hours on this with me and helping me solve it.  If it wasn’t for him, I’d still be pestering VMware day and night for a solution.  John is quite the developer whizz in the UK and you should check him out on LinkedIn.