After you deployed your vRA environment you can start configuring it. However I would suggest to check your deployment first to see if everything is working fine. This is also a good way to determine a baseline of your environment. In case you missed my first part about the deployment you can find it here.
To jog our memory I’m adding the layout of the vRA environment we deployed in part1.
|VRA0010||vRealize Automation Appliance (VIP)|
|VRA0011||vRealize Automation Appliance (Node 1)|
|VRA0012||vRealize Automation Appliance (Node 2)|
|VRA0013||vRealize Automation Appliance (Node 3)|
|VRAW0010||vRealize Automation IaaS Web (VIP)|
|VRAW0011||vRealize Automation IaaS Web + Model Manager 1|
|VRAW0012||vRealize Automation IaaS Web 2|
|VRAM0010||vRealize Automation IaaS Manager (VIP)|
|VRAM0011||vRealize Automation IaaS Manager + DEM Orchestrator 1|
|VRAM0012||vRealize Automation IaaS Manager + DEM Orchestrator 2|
|CSQL0001||MSSQL Database Server cluster name|
|RSQL0001||MSSQL Database Server resource (client access point)|
|SQL0001||vRealize Automation IaaS MSSQL Database (Node 1)|
|SQL0002||vRealize Automation IaaS MSSQL Database (Node 2)|
|VRAD001||vRealize Automation IaaS DEM Worker (Node1)|
|VRAD002||vRealize Automation IaaS DEM Worker (Node2)|
|VRAP001||vRealize Automation IaaS Proxy Agent (Node 1)|
|VRAP002||vRealize Automation IaaS Proxy Agent (Node 2)|
|VRAP003||vRealize Automation IaaS Proxy Agent (Node 3)|
|VRAP004||vRealize Automation IaaS Proxy Agent (Node 4)|
1. Check SSO
Connect to your VAMI interface https://fqdn_vra_appliance:5480. Go to vRA Settings => SSO. Check if the status of SSO is connected.
2. Check Licensing
Check if the license never expires or matches the license you received.
3. Check Database
By default your deployment is done in Async mode. This should be in synchronous mode. Click on “Sync Mode” and wait for the change.
When the change is done you should see below screen.
4. Check Messaging
Check if “Connection Status” is connected and “rabbitMQ process” is running.
5. Check Cluster
Check if the current node is in cluster mode
6. Check Orchestrator
Check if the embedded Orchestrator is running, if not start it.
7. Check Services
Make sure that all your services are registered
8. Check Time Zone
In system => Time Zone, correct your time zone if necessary.
9. Check status Web servers
If you go to this URL (https://VRAW0011.vkasaert.com/WAPI/api/status & https://VRAW0012.vkasaert.com/WAPI/api/status) you should receive a JSON file with the config of your services. These should be in state “Registered”.
Off course you need to receive the same JSON file behind your loadbalancer URL ( https://VRAW0010.vkasaert.com/WAPI/api/status).
Do these tests with IE and add all 3 websites to your trusted sites!
10. Check status Management servers
If you go to this URL (https://VRAM0011.vkasaert.com/VMPS) you should see below image.
By default you don’t have an active-active environment on your management servers so you only need to do that on the active node you configured during your LCM deployment.
Here the same comment if you access your loadbalancer URL (https://VRAM0010.vkasaert.com/VMPS) you should get the same screen.
11. Check the logs of your default tenant
Connect with the “configurationadmin” userid to your default tenant https://fqdn_loadbalancer_vra_appliances/vcac/
Go to Infrastructure => Monitoring => Log and check if you have any errors. I did have some errors and you can find the solution at the end in the section encountered issues.
If you checked all the above you should be ready to start the config of your vRA deployment. Stay tuned for my next blog article as that one will be discussing the configuration 🙂
1.PhysicalHostPingService: ignoring exception: 1.
When I logged in with my configurationadmin on my default tenant I had below error in the logs (Infrastructure => Monitoring => Log)
PhysicalHostPingService: ignoring exception:
Error executing query usp_SelectAgent
Inner Exception: Error executing query usp_SelectAgentCapabilities
In the stack trace:
On all your Iaas & SQL servers you need to make sure that MSDTC is configured correctly. Go to Administrative tools => Component Services. Once opened go to My Computer => Distributed Transaction Coordinator => Local DTC.
Right click on “Local DTC” and choose properties.
Go to the tab security and configure as in the printscreen. In my case Network DTC Access wasn’t checked and the 4 other options neither.
After changing this setting I had now 1 entry every 3 min. Before I had multiple entries every min. So there was progress, but not yet solved.
Because the error was related to my management servers I checked the logs @C:\Program Files (x86)\VMware\vCAC\Server\Logs\All.log. Here I could see there were still issues with MSDTC.
Content of the all.log:
System.ApplicationException: Error executing query usp_SelectAgentCapabilities —> System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. —> System.Runtime.InteropServices.COMException: 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)
After troubleshooting, I found that I needed to enable some firewall rules because the firewall was active in this environment. In my case I had to enable below firewall rules that were linked to the Distributed Transaction Coordinator. Don’t forget that these firewall rules have to be enabled on all your Iaas & SQL servers.
After that all I didn’t receive anymore errors in my logs 🙂