Conditional Access per HostPool or RDP properties conditional on clients
Good day all, I am struggling with the RDP properties of our different host pools. Corporate policy states that nothing should be able to be redirected from the local device. Which is fine and for the Full Desktop publishing we have configured this so on the host pool in RDP properties. However, now we have a separate host pool for a remote app. This remote I would only like to be able to connect to from the desktop host pool (nested) and not from the local device. As this is a Remote App the users need to interact with this application with the clipboard. So I want to know if there is a method, and if not, request a feature to make this possible. With kind regards,
Applications not launching with latest AVD update
Hello there fellow users - first time poster. I also have an open ticket with Microsoft with this particular issue. I feel like this is something obvious I'm missing here though and any ideas would certainly be appreciated. My org utilizes AVD for connecting to a AVD pool of terminal servers for end users. Within that pool are application groups and clients assigned to the groups, although application groups by and large have the same clients. Here's our typical workspace: The issue we are currently having, is that with the last 2 or 3 recent versions of Remote Desktop, and only on SOME computers, is that the applications will not launch properly. The application will begin to launch for a second or so, and then stop and disappear. This is the last thing an affected user sees before the launch box disappears (AVD will remain open): As a work around, we've had affected users/workstations remove the latest version and install version 1.2.2688.0 where this behavior does NOT occur. There are no relevant windows event logs from what I can tell. All affected users are using Windows 10. Here are my AVD RDP Properties in Azure: Thank you!Announcing public preview of RDP Shortpath transport for Windows Virtual Desktop
As we promised during the Microsoft Ignite conference, we are introducing a new capability that can take into account the type of network you are connecting from, and when possible, establish a direct peer-to-peer UDP transport rather than using the Windows Virtual Desktop gateways. For a starter, I would like to remind you that Windows Virtual Desktop uses Remote Desktop Protocol (RDP) to provide remote display and input capabilities over network connections. RDP has initially released 22 years ago with Windows NT 4.0 Terminal Server Edition and was continuously evolving with every Microsoft Windows and Windows Server release. From the beginning, RDP developed to be independent of its underlying transport stack, and today it supports multiple types of transport. It could be a Hyper-V bus transport for managing VMs using the Enhanced Session Mode or TCP-based transport in Quick Assist, or combined TCP/UDP transport for on-premises deployments. When we designed Windows Virtual Desktop, we built an entirely new transport called Reverse Connect. Reverse connect transport is used both for establishing the remote session and for carrying RDP traffic. Unlike the on-premises RDS deployments, reverse connect transport doesn't use an inbound TCP listener to receive incoming RDP connections. Instead, it is using outbound connectivity to the Windows Virtual Desktop infrastructure over the HTTPS connection. This gives a secure and simple way to implement connectivity for your remote desktops. For the details about reverse connect, see a brand new topic in Windows Virtual Desktop documentation. While reverse connect gives a secure and reliable way of communicating with desktop, it is based on TCP protocol, and its performance is heavily dependent on the network latency. It also inherits other drawbacks from TCP, such as slow start, congestion control, and others. Introducing RDP Shortpath RDP Shortpath is a family of UDP-based transports that extend Windows Virtual Desktop connectivity options. Key benefits of Shortpath are: RDP Shortpath transport is based on top of a highly efficient Universal Rate Control Protocol (URCP). URCP enhances UDP with active monitoring of the network conditions and provides fair and full link utilization. URCP operates at low delay and loss levels as needed by Remote Desktop. URCP achieves the best performance by dynamically learning network parameters and providing protocol with a rate control mechanism. RDP Shortpath establishes the direct connectivity between Remote Desktop client and Session Host. Direct connectivity reduces the dependency on the Windows Virtual Desktop gateways, improves the connection's reliability, and increases the bandwidth available for each user session. The removal of additional relay reduces the round-trip time, which improves user experience with latency-sensitive applications and input methods. RDP Shortpath brings support for configuring Quality of Service (QoS) priority for RDP connections through a Differentiated Services Code Point (DSCP) marks RDP Shortpath transport allows limiting outbound network traffic by specifying a throttle rate for each session. Sounds good? Then try it yourself by following the detailed documentation. Feedback We'd like to hear from you about your experiences with this public preview! For questions, requests, comments, and other feedback about RDP Shortpath, please use this feedback form. Don't hesitate to post feature suggestions on: https://aka.ms/wvdfbk Next steps Learn more in the brand-new networking section of Windows Virtual Desktop documentation : Understanding Windows Virtual Desktop network connectivity Windows Virtual Desktop RDP Shortpath Implement Quality of Service (QoS) for Windows Virtual Desktop Remote Desktop Protocol bandwidth requirements
RDP over VPN to Azure VM - what have I missed
Hi, I've set up a Virtual Machine in Azure; it has an app which links to an Azure SQL Database. When I log into aka.ms/wvdarmweb with the user acct which has access to the app, all works fine. Now I'm trying to setup RDP over VPN, and have followed the Microsoft tutorial documents. Virtual Network Gateway is setup, Admin authority went thru ok, download of Azure VPN was fine, and connection has been established from a client machine to Azure over the VPN. Tick tick tick tick, great stuff. I download and start the RDP for the VM, the computer name defaults to "10.0.0.7". I click Connect and get "Remote Desktop can't connect to the remote computer for one of these reasons:" and three possible reasons display. Well, for reason 2 and 3, the remote computer is on and available on the network (otherwise I wouldn't be able to login in via the portal, I guess). So it must be the first reason "Remote access to the server is not enabled." Any suggestions as to what I might have missed? VM Inbound rules on the NIC include AllowRD (3389), AllowPSRemoting (5986), AllowVnetInBound (any). Several users have access to the VM, as demonstrated by access to it via the portal. Thanks
