TS Agent on Citrix XenApp 6.0 farm

[CRHC]

Hello,

Our XenApp farm IP range is dynamic and the servers could spin up on any number of IPs within a couple of segments.  Does a TS Agent entry for every single possible IP need to be added on the PAN device, or can I configure it to look at a subnet range? My attempts at using subnets have not worked, but single IP entries do work.  Thanks!

Mikes

[CMG]

I too am in this situation.. unfortunately I'm not currently aware of any solution other than manually specifying each individual potential TS_AGENT host address.. and the pain with this is the constant alerts you'll get notifying you that TS_Agents aren't responding (ie the ips which arent currently been utilised)..

Given the partnership between Citrix and Palo Alto I would have expected better.. and the TS_Agent functionality in general (whereby it reserve's/ assigns blocks of source ports to users to allow identification) is very "kludgey".. and has caused us problems in several deployments causing Citrix/services to hang/crash. Just been advised recently it looks like the culprit behind stability problems with our Citrix MS Lync HDX redirection..

Would love to hear if anybody worked out a best practice solution.

[CMG]

Perhaps it might be possible to do something via the PAN REST API?

Perhaps create a boot/startup script on your Citrix image that on startup detects it's ip address and register's itself with the PAN FW via the REST API? 

(If that functionality exists in the API)

And also create a shutdown script to do the opposite on shutdown (i.e deregister itself from the PAN FW so as to prevent all the TSAgents not responding alerts).

[CMG]

Best solution we got working in the end was 2x PVS DHCP servers (for HA) configured with explicit DHCP reservations for each Xenapp server. Exact replica of reservations on both DHCP servers means it doesnt matter which one replies first the XA server will allways get the same address.

PAN FW explictly configured with all Xenapp servers addresses. The administration overhead can be lessened with a bit of scripting..

The REST API was a nice thought but likely not functional as it would require a COMMIT for each change to take affect (e.g server added in / removed).. not much of a problem if its  only a single server going up and down occassionally.. but if you where rebooting 200+ XA servers you'd likely be in a world of hurt.

Cheers,