Forum Discussion
Fravocado_30155
Nimbostratus
NimbostratusAPM as an RDP Proxy but still get to RD Web Access page?
Hello,
I am currently trying to understand if deploying the F5 with Microsoft Remote Desktop Gateway servers will fit our needs. I am not sure if using the APM to proxy remote connections will work. I am looking to replace the RDS gateway roles on my servers with the F5 iapp but not sure if I can keep the RDS Web Access component. Using the F5 as an RDS Gateway would provide us HA --so this looks great, but I'd like to keep the ability to use the web access page that users can click the remoteApps that are published to a RDS collection. Does the F5 remove that ability when using the APM to proxy remote collections?
Thank you, Franz
In v13.0, APM can read items from a RemoteApp feed and SSO + proxy them to your APM users in an APM webtop. This would be quite difficult to implement on prior versions, so I’d recommend you wait for that release. v13.0 is going to be released within a few months.
This new version can publish RemoteApps (app virtualization) and also publish native RDP Resources (desktop virtualization) to IOS, Android, Mac, and Windows using the native Microsoft client. This requires installation of the Microsoft RD app.
You can also request access to the beta program here on DevCentral if you'd like to test it out in a non production environment.
Edit: the iOS part only works correctly in the case that you don't use RD Broker.
In v13.0, APM can read items from a RemoteApp feed and SSO + proxy them to your APM users in an APM webtop. This would be quite difficult to implement on prior versions, so I’d recommend you wait for that release. v13.0 is going to be released within a few months.
This new version can publish RemoteApps (app virtualization) and also publish native RDP Resources (desktop virtualization) to IOS, Android, Mac, and Windows using the native Microsoft client. This requires installation of the Microsoft RD app.
You can also request access to the beta program here on DevCentral if you'd like to test it out in a non production environment.
Edit: the iOS part only works correctly in the case that you don't use RD Broker.
Fravocado_30155Thank you for the information. With version 11.5 is it still possible to get to remote apps without using the webtop? As in once authenticating thru the F5 users are routed to the Remote Destkop Services Web Access portal? Or is proxying RD connections in this version more like only being able to launch and RDC client?
Thank you! Franz
Not easily, no. This is why the feature as implemented in the new version.
Manuel_Cristob3Hi Lucas,,is there any deployment guide and/or iapp that we can use to leverage v 13? thanks
Manuel_Cristob2question:
we have a couple of VIPs on separate LTM+APMs and we want to do persistence based on the VDI token-id Do you have a recommendation? maybe a universal irule?
- LeeH
This thread has been very helpful in getting us up and running in a sandbox environment. We've run into a dead end though in trying to apply this to our production environment.
In both environments we have separate boxes for APM and LTM, but we have only been using APM for now in both. The major difference between our two environments would be licensing: in sandbox we have APM running with a Lab license, and in production we have APM licensed with limited LTM licensing (no load balancing). Webtop is populating properly with all the Remote Apps but when opening the downloaded *.rdp files we get a fairly generic "Your computer can't connect to the remote computer because and error occurred". One thing we see different in the APM logs is it looks like even though we have a Kerberos SSO profile assigned to the Remote Desktop profile, we are only seeing NTLM attempts server-side. Both production and sandbox are using the default/unmodified "vdi" profile. We are seeing entries in APM logs like the following after launching *.rdp:
Apr 27 15:04:48 F5-APM-V2 err tmm[11517]: 019cffff:3: /Common/RDITAccessPolicy:Common:00000000: VDI profile on /Common/RDIT does not have associated NTLM Auth profile or ECA profile is missing Apr 27 15:04:48 F5-APM-V2 debug tmm[11517]: 019cffff:7: /Common/RDITAccessPolicy:Common:00000000: RD: [C] XXX.XXX.XXX.XXX.53685 i XXX.XXX.XXX.XXX.443: server-side connection was reset, reason: iRule execution (reject command)Has anyone else encountered this, or have any thoughts? Thanks!
This ECA error indicates that VDI is falling back from the protocol used by newer clients to the older protocol. The older one requires NTLM credentials from the client. How to set that up is documented here, it's somewhat different than the newer implementation:
To make sure it uses the newer protocol, use a newer client. You're probably testing with Windows 7. Install this:
https://support.microsoft.com/en-us/help/2923545/update-for-rdp-8.1-is-available-for-windows-7-sp1
Windows 8.1, Mac (updated from the app store), or Windows 10 will contain the newer client.
- LeeH
Thanks Lucas. We are definitely testing with Windows 10 clients in production. In sandbox we had joined and created the NTLM account and tested and it worked with Windows 7. In production we just started simple with no NTLM and ONLY using Win10.
What version are you running?
Lee_55137This thread has been very helpful in getting us up and running in a sandbox environment. We've run into a dead end though in trying to apply this to our production environment.
In both environments we have separate boxes for APM and LTM, but we have only been using APM for now in both. The major difference between our two environments would be licensing: in sandbox we have APM running with a Lab license, and in production we have APM licensed with limited LTM licensing (no load balancing). Webtop is populating properly with all the Remote Apps but when opening the downloaded *.rdp files we get a fairly generic "Your computer can't connect to the remote computer because and error occurred". One thing we see different in the APM logs is it looks like even though we have a Kerberos SSO profile assigned to the Remote Desktop profile, we are only seeing NTLM attempts server-side. Both production and sandbox are using the default/unmodified "vdi" profile. We are seeing entries in APM logs like the following after launching *.rdp:
Apr 27 15:04:48 F5-APM-V2 err tmm[11517]: 019cffff:3: /Common/RDITAccessPolicy:Common:00000000: VDI profile on /Common/RDIT does not have associated NTLM Auth profile or ECA profile is missing Apr 27 15:04:48 F5-APM-V2 debug tmm[11517]: 019cffff:7: /Common/RDITAccessPolicy:Common:00000000: RD: [C] XXX.XXX.XXX.XXX.53685 i XXX.XXX.XXX.XXX.443: server-side connection was reset, reason: iRule execution (reject command)Has anyone else encountered this, or have any thoughts? Thanks!
This ECA error indicates that VDI is falling back from the protocol used by newer clients to the older protocol. The older one requires NTLM credentials from the client. How to set that up is documented here, it's somewhat different than the newer implementation:
To make sure it uses the newer protocol, use a newer client. You're probably testing with Windows 7. Install this:
https://support.microsoft.com/en-us/help/2923545/update-for-rdp-8.1-is-available-for-windows-7-sp1
Windows 8.1, Mac (updated from the app store), or Windows 10 will contain the newer client.
- Lee_55137
Thanks Lucas. We are definitely testing with Windows 10 clients in production. In sandbox we had joined and created the NTLM account and tested and it worked with Windows 7. In production we just started simple with no NTLM and ONLY using Win10.
What version are you running?
Bernd961Hi, I'm trying to configure this, but already have some difficulties with the Kerberos SSO configuration. Does somebody have a cookbook how to set it up and which settings to choose for the matching AD user ? regards, Bernd
