Unlikely this issue is likely to hit anyone else, but I spent some time looking at it today and if I do something but don’t blog about it then I haven’t really done it, right? :)
So here’s the situation. We recently introduced laptops in our environment and when laptop users visited our Citrix Storefronts they weren’t getting all the apps we were expecting them to get. This was inspite of them being in the delivery group and having access etc. Users on workstatations or accessing externally (including these same users) had no issue, so it was only laptops related.
The laptops were on a new subnet so I figured something in that must be having restrictions. This was a Citrix environment I inherited so it’s likely the previous admin had setup things differently. Sure enough, I poked around the access policies of the delivery group in Studio an saw a message that it was modified externally. 
No biggie, launch PowerShell, do Add-PSSnapin citrix* and then Get-BrokerAccessPolicyRule -DesktopGroupName <name of the delivery group>.
This showed me that indeed we do have access restricted to certain IP ranges, so I expanded this to include the new subnets for the laptops.
|
1 |
Get-BrokerAccessPolicyRule -DesktopGroupName <name of delivery group> | Set-BrokerAccessPolicyRule -IncludedClientIPs "10.10.0.0/8","192.168.25.0/24","192.168.23.0/24" |
Be sure to put in all the subnets above, both existing and new.
After this the app started appearing in StoreFront. Yay! And if I launched it via the StoreFront website (the so called Receiver for Web) it launches fine. But if I launch it via the Citrix WorkSpace client directly (i.e. by opening the store in the WorkSpace and clicking on the icon) it doesn’t. All I got was an error “The resource is currently unavailable. Try again later.”
I tried enabling logging to save the ICA file etc. but that didn’t help either. The ICA file wasn’t created. No errors on the Delivery Controllers or VDA either… odd!
It sounded like IP restrictions again as the error was instantaenous. As soon as I click the icon I’d get it without any further processing. So I turned off the IP restrictions to see if that helps:
|
1 |
Get-BrokerAccessPolicyRule -DesktopGroupName <name of delivery group> | Set-BrokerAccessPolicyRule -IncludedClientIPFilterEnabled $false |
Yup that did! Interesting. At this point I could have ust turned off IP restrictions as I did above, but I decided to leave it enabled and instead limit the IP restrictions to all the private subnets. That defeats the original purpose am sure, but I couldn’t think of anything as a workaround.
|
1 |
Get-BrokerAccessPolicyRule -DesktopGroupName <name of delivery group> | Set-BrokerAccessPolicyRule -IncludedClientIPFilterEnabled $true -IncludedClientIPs "10.0.0.0/8","172.16.0.0/12","192.168.0.0/16" |
Am thinking when you access the StoreFront via the WorkSpace app and try to launch an app that way, the IP it sends to the StoreFront might not be what you expect? As in, since my laptop has a VPN IP as well as the IP from my home network maybe when the app is actually being launched it sends the latter IP and thus access is restricted? Am not sure, and I suppose I should troubleshoot more via WireShark or similar… but it’s a Friday, I am lazy, and so here that’s that. :)