Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
When the customer does the ACC Test Connection they receive an error message "Reached AWCM, but Cloud Connector is inactive".
Troubleshooting steps needed to be taken: Perform the Test Connection and see the error once again.Verify how many ACC servers are present. If one ACC server perform the following steps: If the ACC version is out of date, please update or contact support for further assistanceIf the ACC version is not out of date: Try to hit the AWCM URL from the ACC server. The URL needs to be in this format "https://awcm url:port/awcm/status"Check if the certificate has expired or not. If the certificate has expired renew the certificate If the certificate is not expired then - collect verbose ACC logs, verbose webconsole logs, Wireshark Check the ACC version If there is more than one ACC server behind the load balancer perform the following steps If the test connection is successful do the same with enabling next servers and disabling all servers to see if the issue is with ACC load balancer Check if they are implicit clustering and the AWCM is externally available by navigating to https://awcm url:port/awcm/statisticsCheck for persistence by hitting the URL https://awcm url:port/awcm/statistics?awsessionid=abc123 on ACC server and on machine from outside network. If the servers are different then customer needs to change the persistence rule on load balancer on their end.To understand more in depth about the persistence please refer to this article which explains persistence in depthAirWatch KB Article regarding Setting up AWCM persistence rules using F5. Try to hit the AWCM URL from the ACC server. The URL needs to be in this format "https://awcm url:port/awcm/status".If the status is not "ok", then check with the network team if there has been any change with the network settings.If the status is "ok" then check for persistence by doing the followingIf the test connection is failing then do the same with enabling next servers and disabling all servers to see if the issue is with ACC load balancer. If it continues to fail with another server as well, perform the following steps: Check if they are implicit clustering and the AWCM is externally available by navigating to https://awcm url:port/awcm/statisticsCheck for persistence by hitting the URL https://awcm url:port/awcm/statistics?awsessionid=abc123 on ACC server and on machine from outside network. If the servers are different then customer needs to change the persistence rule on load balancer on their end.To understand more in depth about the persistence please refer to this article which explains persistence in depthAirWatch KB Article regarding Setting up AWCM persistence rules using F5. Try to hit the AWCM URL from the ACC server. The URL needs to be in this format "https://awcm url:port/awcm/status".If the status is not "ok", then check with the network team if there has been any change with the network settings.If the status is "ok" then check for persistence by doing the following Keep one ACC server active and disable the rest of the server (just stop the ACC service and AirWatch diagnostic service). Perform the test connection If all the above test fails please gather verbose ACC logs, verbose webconsole logs, AWCM logs, and Wireshark report.