Geeks With Blogs

News Clicky Web Analytics

web stats View David Caddick ('s profile on LinkedIn

Search this Site!

Locations of visitors to this page
View My Stats eXTReMe Tracker
This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed within are my own and should not be attributed to any other Individual, Company or the one I work for. I just happen to be a classic techie who is passionate about getting things to work as they should do (and are sometimes advertised and marketed as being able to?) and when I can I drop notes here to help others falling in to the same traps that I have fallen in to. If this has helped then please pass it on - if you feel that I have commented in error or disagree then please feel free to discuss with me either publically or privately? Cheers, Dave
Thin Clients, VDI and Linux integration from the front lines.... Raw and sometimes unedited notes based on my experiences with VMware, Thin Clients, Linux etc.

Please be aware that this is not verified at all - but this is posted here just as a precautionary warning until such time as it is verified? Better to be safe than sorry?

***UPDATE: This is a real issue only IF there is a Firewall between the Licensing Server and the Servers hosting Citrix Products

A colleague of mine sent me this:

I took down  x,xxx users on Monday because I upgraded our License Server to PS 4.5 on Friday afternoon.  Everyone went down 11am Monday morning.
Quick look at the firewalls showed that port 1603 was being blocked between all PS servers and the Licensing Server <>.  Although telnet on 27000 worked between PS servers and licensing server.
I had the Security Team open the port and all was back to normal, comms resumed....35 minutes down time, what the heck?  where did this port come from.  None of my research, preparation showed this. <Integrator Support> have not heard of this additional port 1603.  <Integrator Support>  then raised call with Citrix, but Citrix have passed onto to much higher levels as the 1, 2nd line teams don't know.....

And this is further supported by another colleague:
I did hit this one at <Customer> when implementing CAG.  For some reason, there appears to be this additional port requirement over and above the documented 27000.  I didn't pursue it, but it's heck of annoying.
We didn't get the prob in Production with <Customer>, as we did a test in the lab to see what the impact would be, and encountered no issues.  But then there were no firewalls between the licence server and the PServers.

So reviewing Readme for Citrix Licensing 4.5 (for Windows) lead me to the following article:

It would appear that this comes about as a result of the Citrix Vendor Daemon
As listed in: Licensing: Firewalls and Security Considerations




Reason for Change

See this Section for Procedure

Citrix vendor daemon

By default, the port on which the Citrix vendor daemon communicates changes dynamically—the CitrixLicensing service chooses a new port every time it restarts.

If a firewall is between the license server and the computers running your products, you must configure a static Citrix vendor daemon port number.

Setting a Static Citrix Vendor Daemon Port Number

License manager daemon

By default, the License Manager daemon communicates over the default TCP port of 27000. If port 27000 is already in use on your license server, you must change the port number the license server uses to communicate with Citrix products.

Changing the License Manager Daemon Port Number

The upshot of this is that it might still be possible for this to fail until the Citrix Vendor Daemon is locked to a static port? However it does beg the question regarding Citrix's 30 day grace period?

Posted on Thursday, June 28, 2007 1:33 PM Citrix , Security | Back to top

Comments on this post: Potential issue with Citrix Licensing Server needing access to 27000 AND 1603 **IF** there is a Firewall between the LS and the other Citrix Servers?

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Dave Caddick | Powered by: