ActiveGate timesync test URI returns -1 for both values t1 and t2

[andre_vdveen]

We've set up a Cluster ActiveGate and when we run the test via the CMC web UI -> Public endpoints, we get the expected 4 green ticks back. However, when I do the test using the suggested URI (https://cag-url:9999/mbeacon?type=mts) via mobile or desktop browser (connected to AG network), it returns type=mts&t1=-1&t2=-1

Does anyone have any idea what that means and why this seems to fail, yet the UI tests succeed?

The traffic flow is: device -> F5 -> Cluster AG

Is there any way to see the requests hitting the AG in a log file, or does someone know the URL's used when running the Endpoint test via the CMC web UI? I assume those tests are executed from Mission Control, once the button 'Test connection to URL' is hit?

[Thomas_Wirth1]

You can ignore the response code. The mentioned test only validates that the ActiveGate is reachable from the mobile device and the request is not blocked by a firewall. Therefore your manual test was successfully.

The OneAgents for Android and iOS should be able to connect to the ActiveGateway (assuming that there are no specific security restrictions like blocked POST requests).

[andre_vdveen]

When I run the same test for another client, I get values back for the timestamps i.e. type=mts&t1=1542106538846&t2=1542106538846 and their app monitoring works fine. The client where I get -1 values back, we also get cp=0 back when checking the test URI:

https://cag-url:9999/mbeacon/<environment id>?type=m&app=<app id> (for some reason it scrambles the ampersand character on the forums - for those who need the correct test URI, it can be found here)

You might be onto something there re: the POST requests, I'll have the firewall admins check that out - thanks!

[Thomas_Wirth1]

I assume that your clients use different versions of the ActiveGate. Both values are fine.

The cp=0 value is concerning, because it indicates that the url is not correct or there is a problem and the agent should stop contacting the cluster. Please double check if the id values for environment and application are correct. If there is no typo, then you should open a support ticket. The support team can help you to activate the debug logs for the ActiveGate. The debug logs should show why the request was not accepted.

[Patrick_H]

newer ActiveGates respond with -1 as timesync is no longer needed. The -1 is only for keeping compatibility with older mobile agents which still perform the timesync call and just tells them to proceed without timesync

[andre_vdveen]

Yes, very likely different ActiveGate versions in use at both clients - thanks, I'll take your word for it re: the values 😉

I'm 100% sure the mobile app setup and values for env. ID as well as App ID's are correct, copied and pasted them and double checked too, so I'll open a support ticket then - thanks for your help, much appreciated!

[andre_vdveen · Accepted solution]

Posting the solution here, so that others can hopefully learn from my (silly) mistake: the Cluster license on which we were busy testing this, doesn't have DEM / RUM license! This caused us to get the result of cp=0 which means UEM is disabled, according to the support person I spoke to...that is what made me click that it's not a case of UEM being disabled i.e. on the agent side, but rather that there is no license.

PS: you can check if the agent is enabled for RUM by using this URI in your browser:

hostname.yourdomain/dynaTraceMonitor?type=m&app=<app id> (that should read: mampersandapp=<app id>)