I am having the following errors in the vRA 7
I have followed the solutions that are found online
However, I am still getting the same error. In the IaaS Server logs, this error was captured:
The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02B)
I have downloaded the DTCPing and both the servers are able to communicate with each other. Firewall has been turned off on both servers.
These servers are not joined to domain and all access are configured on the DNS server.
Appreciate any help on this issue. Thanks!
As I read the subject of your post I was thinking "this sounds like an MSDTC issue".
On reading the detail, the issue may be the lack of domain join. I don't believe vRA is supported to be installed within a workgroup.
I have a vRA 7.1 new installation that is exhibiting these same characteristics, except all windows servers are joined to the same domain. We have turned off all firewalls on IAAS and SQL server. DTCping works fine. We are getting these same errors as the OP in the IAAS Server Logs.
This is related to MSDTC on SQL server and IAAS Manager. You have to ensure that the MSDTC Settings are configured as listed below.
Restart the Manager service, vSphere Agent service and run the data collection.
This is a pre-requisite for all IAAS components. You can also refer to the following KB article.
The main difference is the servers which are not part of domain as per post by wllp Sep 9, 2016 1:44 AM."These servers are not joined to domain and all access are configured on the DNS server"
This is something which needs to be verified. I have not seen any VRA setup with workgroup.' Authentication and access is minimum criteria of the vRA stack. I don't think it will work with WORKGROUP. You need to join the machines to the AD Domain and service account must have local admin access to all the IaaS servers along with SQL for DB.
My situation might be a bit different but I was able to get it resolved with a workaround..
We could create an endpoint, and can see the compute resource but could not see any allocated CPU, memory or storage for the cluster.
We reviewed all settings of MSDTC with SQL and all Iaas Windows server, and it is configured correctly.
We could successfully connect with DTCping and DTC tester from IaaS server to SQL server and reverse.
The environment is not what I would call standard
A DNS zone is defined and is used as the server FQDN, (not the domain name). For example server.siteA.primarydomain.com
The domain the Windows servers are connected too is different. For example domain.primarydomain.com
What I initially thought was that there is a firewall between the vRA environment and Domain Controllers. It's possible that the NETBOIS name lookup is blocked by firewall, because normal DNS short/long/nslookup worked but the NETBIOS lookup for the Domain Controllers fail.
I was able to fix the MSDTC problem by performing the following steps:
1. Added the IP address and NETBIOS names for all our servers and the Domain controllers to each of the servers LMhosts file
2. Changed MSDTC security settings to “no authentication required”
3. Change the account access to MSDTC through the following article
4. ADD domain name and DOMAIN SEARCH PATHS correctly to your VMware appliances. This will help with NETBIOS fixes…
Nr 1 can probably be fixed with NETBIOS firewall ports opened and/or having NETBIOS enabled and correctly configured on the network.