NetScaler Console Service Agent comms.
What URL's does it need to hit to run?
Hello!
I had a question from R last week. She was setting up NetScaler Console Service Agent in Azure and just couldn’t get the communications to work as expected. The deployment script is used to hook the new agent up with the NetScale Console Cloud service.
The agent is necessary for comms between her Azure hosted NetScaler’s and the NetScaler Console Service itself. In this case the Console Service hosts all the NetScaler licenses, plus the management and analytics capabilities. It is therefore a key step to get the agent setup.
She said: We have allowed a big list of URL’s(based on docs recommendations), but the deployment script is still failing on the comms step. How do we verify the agent has the correct comms?
I thought this was a good process as I have not had that many other people asking this, that said, maybe there are a few gaps in the docs. Hence this article.
Step 1: Check the URL’s needed from the docs page.
docs here: https://docs.netscaler.com/en-us/netscaler-console-service/system-requirements.
Setting up the agent in azure has this process. For the most part this was fine, there was a just an issue for her to login, as the account that had been specified during deployment didn’t let her login. They used an account name of ‘nsrecover’ with their own password (setup during the config stage) and she could access the cli.
Once in the cli, she tried to run the deployment script, she has the service URL and activation code ready to past into the ssh agent. She seemed to have all the URL’s that were advised, but it still failed.
Step 2: Check support doc diag utility.
I needed some advice, so checked with Jay in support. Thanks for the help Jay! Jay suggested this support doc. Honestly, it was gold dust. The python agent_diag.py script polls the key URL’s the agent needs and verifies which it has a problem with. You can then get Captain firewall to open those up. Also, the list of URL’s that the agent needs was quite short, this makes it easy to lock down the list to just what is needed. Least privilege and all that..
This script was run by Jay on his system in India, his console is onboarded to the Asia control plane, hence the second and third lines have ‘Juhu’ URL’s. Emea have ‘Carmel’ as the name of the service for this area.
> shell
bash-3.2# cd /mps/python/util/
bash-3.2# python agent_diag.py
Agent Diagnostic Started
checking if agent proxy configured
agent proxy not configured
checking DNS configuration
DNS is working
checking device to NetScaler Console connection
agent to NetScaler Console connection adm.cloud.com is good
agent to NetScaler Console connection juhu.adm.cloud.com is good
agent to NetScaler Console connection juhu.agent.adm.cloud.com is good
agent to NetScaler Console connection trust.citrixnetworkapi.net is good
agent to NetScaler Console connection download.citrixnetworkapi.net is good
agent to NetScaler Console connection adm-prod-backup-juhu.s3.amazonaws.com is good
agent to NetScaler Console connection cas-eh-ns-alias.servicebus.windows.net is good
Agent Diagnostic Done
bash-3.2#
When I run my EMEA control plane agent, I get this output.
agent to NetScaler Console connection adm.cloud.com is good
agent to NetScaler Console connection carmel.adm.cloud.com is good
agent to NetScaler Console connection carmel.agent.adm.cloud.com is good
agent to NetScaler Console connection trust.citrixnetworkapi.net is good
agent to NetScaler Console connection download.citrixnetworkapi.net is good
agent to NetScaler Console connection adm-prod-backup-juhu.s3.amazonaws.com is good
agent to NetScaler Console connection cas-eh-ns-alias.servicebus.windows.net is good
Obviously, my agent has no issues.
Step 3: If all else fails, grab a packet trace.
Sometimes, you just need to take a look on the wire. This support doc, covers the tracing options for the agent.
Summary
I thought this utility was very handy, it is a simple thing, but might just save you some time.