We have a MAG-4610 running 7.2R1 and are having problems getting more than 2 OSX Pulse clients to connect simultaneously. We understand we are using one feature that isn't technically supported (location awareness). Pulse is 18.104.22.16807
The behavior is that only two OSx Pulse clients can connect. The first one that connects is fine. The next connection is fine. The third knocks the second off. Second reconnects fine, and knocks off the third.
Windows clients and https clients seem to be fine, however we don't have the resources to test this in depth.
Anyone else have this problem, or the reverse - OSX clients connecting happily in large numbers?
Authentication is Active Directory, role mapping is in use. The problem doesn't seem to be related to roles, but again, our resources for testing are somewhat limited.
At least three, which is better than before and all I have to test with. I suppose the answer then is "it's unsupported, don't use it". Disappointing, but if that's the answer, I guess we'll have to deal.
Any reason not to think more connections will work properly?
I will note that I don't see our specific configuration listed as not supported in the Pulse 3.0R4 relase notes - the only location awareness issue mentioned involves "automatically when the machine starts". Our configuration was "Automatically after user signs in to the desktop."
Follow up, for the record
Apparently Location Awareness does work, and our problem had nothing to do with it. Our problem is because of imaging - we installed Pulse on a master image, then imaged many laptops. What we didn't know is that a guid is generated on installation, and is then the same on all the clones. This makes the access server see all connections as coming from the same endpoint, and connections are allowed as per the simultaneous connection policy.
It seems the fix isn't too hard, but it took a long time to get the correct answer out of JTAC.
The fix is really hard for an enterprise which uses a software distribution method which clones images, particularly if the enterprise has thousands of PCs.
1) I understand Juniper is aware of the issue and working on a fix
2) If you know about the issue *before* building your images, the fix is very simple - remove the machine "local" GUID from connstore.dat (or whatever the Windows equiv is) before locking the master. Then there is no problem. The first time Pulse is started on the imaged machines, it will generate a new local guid and life will be good.
We found it simple to push out/run a bash script based fix for our Mac users with Apple Remote Desktop central management, although I wouldn't want to deal with hundreds or thousands this way. I am happily unfamiliar with mass deployment of Windows clients so can't speak to that.
Also for the record - this issue is noted in KB25581. I should also say that while it took JTac a few days to get us the right answer, they did in fact get there.