I'm using 2X ApplicationServer for Windows Terminal Server. It uses port 81 to connect to the Application server and then RDP 3389 to the Terminal Servers from the Application server. I have added a diagram to review.
I have added a policy to Optimize (TFO Only) for port 81 to accelerate the connection between a client and the app server (App server and Terminal Server farm).
Is this the best way to optimize RDP? The RDP policy (MS-Terminal-Services) appears to be TFO only by default, but does anyone compress (DRE and/or LZ) any of this for further acceleration? Is this possible?
The reason I ask is because we have several people in remote offices trying to view pictures and mapping software, which can get quite "laggy" over an RDP session at times.
What are the client and server OS's involved. RDP uses native encryption and compression by default, which is why the default WAAS policy is set to TFO only. If the native RDP encryption and compression are disabled, full optimisation can be used with WAAS.
Thanks for the info, Zach. I did some searching and indeed did find you stating this in the posting.
I am Windows Server 2003 R2 and Windows XP. However, by using the 2X application, it appears that the clients connect to the broker server on port 81 and then the broker server connects through RDP to the back-end terminal servers.
I am not sure how to put a policy in for this end-to-end level of connectivity, but for now I have added a policy to use TFO between clients and the broker server via port 81.
I have determined that this will ONLY work when connecting DIRECTLY from an RDP client to a Terminal Server. However, if you use an "overlay" program such as 2X, or VisionApp, etc., acceleration will not occur. It is still trying to connect on port 3389 for RDP though so I am scratching my head.
Will this be resolved? Is there a reason why acceleration will not occur even though the connection is still taking place on port 3389?
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...