Hello.  Thanks for posting.  Unfortunately I don’t have a resolution, but can related to your problem.  I’m confused and a bit frustrated to say the least.  At any rate, I have been trying to work through two issues, which the second issue overlaps a bit with your efforts: Restoring browser-based logins Restoring working upgrade prompt via PDC (Pulse Desktop Client) logins With regard to your experience, I think whatever Pulse Client version has the radio/option button selected when navigating to Users > Pulse Secure Client > Components is the current active one.  I wish it was a little more evident on the UI.  But, I have the same experience as you, when I have an older version of PDC on a Windows endpoint and login to the 9.1R11.5 PCS device, I do get prompted for the upgrade, but then NOTHING after I click “Upgrade”.  I was sure hoping that the upgrade prompt was going to be resolved in 9.1R11.5, but that does not appear to be the case.   For your 9.1R11.4 issues... I see in in the release notes for 9.1R11.4 there is a known issue - (PRS-400668): Symptom: Pulse Desktop Client (PDC) always displays upgrade prompt even when client version on the endpoint and the server are same. Clicking on upgrade prompt performs no action (Cosmetic/UI issue). Condition: Occurs when the Pulse Desktop Client has Symantec signed binaries and the PCS on which it is hosted (9.1R11.3/ 9.1R10.2/ 9.1R9.2/ 9.1R8.4) is signed by Digicert. Workaround: Disable End-point upgrade on Pulse Connect Secure (PCS). Enable again only when a higher version of PDC is activated on PCS and let the users trigger the client upgrade through the browser.   For my situation, I am testing PCS 9.1R11.5. And I will add though that I have Pulse Client package 9.1R10 as my active client package (my company’s current standard), so my testing has been trying to get the upgrade prompt to upgrade my 9.1R7 client to 9.1R10 in my testing.  But I don’t think the client version matters; as you indicate I think it’s a bug or two with 9.1R4 and 9.1R5.   I think your steps are correct though.  If you are wanting to run PCS 9.1R5 and for clients to have PDC 9.11R5, then yea, upgrade the appliance, activate the new PDC, and ensure the “Enable web installation and automatic upgrade of Pulse Secure clients" option is checked. Historically that has worked, but seems to be bug(s) with the latest versions.   I probably didn’t state anything in here you didn’t already know, but know you are aren’t the only one having issues.  I’ll likely be opening a support case and see what the best path forward is.   ... View more

I actually never pursued this configuratio/solution as we were simultaneously  looking at another platform/vendor to accomplish the end goal.  The other platform is likely what we'll end up using based on progress thus far.  Apologies I don't have better info for you! ... View more

Your post caught my eye, as I've been involved in split-tunneling O365's "optimized" category on Pulse as well. Unfortunately I don't really have an answer for you (sorry), but I will share what I'm seeing as there is some weirdness (similar to what you describe).   Both  52.112.0.0/14 and 52.120.0.0/14 are set to be excluded from the tunnel on our policy. Out of curiousity, I did some investigation and noticed that for users on Pulse with Split-Tunneling setup for O365, I see nbname traffic (udp 137) is still using the tunnel back to the data center [no idea if that traffic is important or used], but tcp traffic (essentially just 443) is being split-tunneled as desired (based on wireshark captures).  I also see some the udp 3478-3481 traffic coming back to the data center, when I expect that to be split-tunneled based on configuration.  Kinda strange.  I wouldn't expect protocol (tcp, udcp, icmp, etc) to play any role in how the traffic is routed...it should just get routed all the same!  Especially since it's the split-tunneling policy is set via IPv4 for this, so no FQDN bugs at play.   I would say the bulk of the traffic to these  52.112.0.0/14 and 52.120.0.0/14 subnets is in fact being split-tunneled and going straight to O365 and we have performance gains because of this -- however there's still some traffic coming back via tunnel as you mentioned.  Not sure why that is!  Certainly would like to hear others' comments or ideas as to why. ... View more

Similar story here.  Typically cannot get much more than 20-25 Mbps on a Windows client with a 200Mbps ISP link via an ESP tunnel.  Interesting comparison though is that a Mac endpoint on same ISP link gets MUCH better, approx 120 - 150Mbps. Actively working with Pulse Support on identifying what performance gains on Windows are possible. ... View more

I have investigated the same idea and do not believe there is an API-driven or programmatical method to do this -- I could certainly be missing something though.  I will be manually disabling when concurrent usage dips below a threshhold to lengthen the life (and value) of the ICE license; in today's day and age it is unfortunate to resort to this, but I that's where I find myself. ... View more

Hey, thanks for the reply.  Since I'm using the "Detailed Rules" option for each VPN tunneling access control policy, unfortunately there is not a description field available for each rule in these policies.  There is a description field for the policy itself, but not the rules.  In more recent code versions, the the FQDN field was added for each rule to allow based on FQDN -- but what we need to be added next is a comments field! Oh that would be nice to have a comment field available for each rule.  Come on Pulse, add that functionality to the next code version! :) ... View more