TSplus as an alternative to RDS without paying RDS license fees to microsoft
Hello, We are evaluating whether to use TSplus (https://www.terminalserviceplus.eu/) as an alternative to Microsoft RDS/Terminal Server. According to TSplus we can not install or uninstall the RDS role, so we do not use RDS CALs and use TSplus CALs. This way it would not be necessary to pay for Windows Remote Desktop licenses. Is this correct? I can't find any information from Microsoft about it reading documentation. As I see it is correct that using TSPlus without installing Microsoft RDS it would not be necessary to pay Remote Desktop licenses. Could someone confirm me that it is so?
Remote Desktop Web Access HTML5 certificate error after replacing
Hi everyone. We needed to update our certificate in our RDS servers. Unfortunately, now users receive this alert: I know this is old, but I was hoping maybe someone found a better solution. Stuff that I tested to reduce the problem: clear cookies for specific sites at the end of a session clear images and files when the browser close (running this manually solves this most of the time). Deployed the certificate thumbprint as GPO. (didn't have to before but maybe will assist later) Allow .RDP files from valid publishers and user's default .RDP settings (we use a wildcard certificate, so this is ashot in the dark.) Any help would be appreciated. Rahamim.
Solutions for WVD client not connecting
I, and it seems many others, have had issues connecting to windows virtual desktop after provisioning seemed successful. This manifests with the web client giving errors after opening port, or with the desktop client saying something went wrong and a vague explanation. Turns out there are a few rules that must be followed that aren’t mentioned anywhere I looked. 1) the user you are logging in with must be from the local AD or from the AADDS ... NOT an AzureAD user. It must be synced but it must originate from local AD. It must be a domain user. You won’t see what the issue it, but it will fail. Your domain controller does the sign in Authentication, but it’s initiated through azure, so it must be synced and visible in azure but actually created in domain. AzureAD users won’t sync back to the domain so that’s why it needs to be created in domain. Remember to add the domain user to the app group via add-rdsappgroupuser as well. 2) you can’t be logged into windows with a different Microsoft account for the desktop client. The new client apparently looks at the windows accounts, and you will see there is no way to change accounts from the desktop client. This is very annoying. Since it’s tied together if you are logged into a personal Microsoft account or one not from your local AD that’s not been added to the appgroup, it will fail. I was testing accounts but I was logged into windows with my personal Microsoft account and it always gave errors. I logged out, and into the local computer account , and the desktop client worked fine. I figured this out because after I removed the additional testing accounts from windows users I got a Login screen but then it still failed with the same “something went wrong” error. This led me to think it might be getting confused because I could have multiple work accounts on computer and the client never asked which to use. Instead of a VM issue it’s just the client isn’t smart enough to ask which account you want to use even after login. Item 3 also led to to realize that it’s getting confused with accounts. 3) use incognito to test web client. Even though I logged out of azure portal, out of my own Microsoft account, etc, the web client kept failing to connect. BUT if I ran incognito it connected. This told me the app isn’t able to distinguish the account I needed to use. Again, my personal account still had a trace somewhere in the browser and this kept causing issues. WVD kept trying to use an account that’s not part of my WVD setup, hence failure. Try incognito. I hope these items help you out. None of these were made clear and I beat my head for 3 days re-launching WVD VMs and tenants. Turns out the setup was fine the whole time. It’s the WVD clients that suck. The desktop client must have a way to login a user and NOT pull from windows. Or at least give the user a clear error that explain what account it’s trying to log in with. Just telling me what account it tried to used on either the desktop client or webclient would have identified this in an instant. The diagnostics log weren’t clear enough either. Ultimately Please just separated the sign ins. Not everyone wants to use SSO, especially a remote worked on their personal laptop that’s not domain joined, or joined to a different domain. Hope this helped some people out.
On-Prem RDS NLA troubleshooting
Hi, I'm working to support integration of my customer with a new parent company. Our environment, we'll call this Site A: Windows Server 2016 w/Essentials Role, Windows 2016 w/MultiPoint Role, Windows 10 Pro desktops (1909). Local AD Domain runs AAD Connect using password hash sync. Is now connected using site-to-site VPN and 2-way forest trust to.... (We have site-to-site VPN to both Site 1 and Site 2 below) Their environment: Site 1: 2x DCs Windows Server 2016 Std 1x Terminal Server running Windows Server 2016 DC *this is just a Windows Server 2016 set up as a Session Host, there's no RD Gateway, Broker, etc because those things are hard <shrug> Site 2: 1x DC Windows Server 2012 Mostly people connecting into our Multipoint server Our users connect from the Windows 10 desktops and MultiPoint server (joined to our domain) into the Site 1 Terminal Server (joined to the remote domain) and primarily run an Access app there. On a frequent basis our users get disconnected - they usually get the generic disconnected message....when they try to re-connect they generally get an NLA error. Anecdotally it appears to happen when Site A - Site 2 VPN connection drops. I understand using NLA the RDS server tries to communicate back to the domain to authenticate the machine that's trying to connect.....but every article I find about RDS and NLA is "how to disable NLA," which we don't want to do. Any resources or links discussing how to troubleshoot NLA in the RDS context? Beyond that....would the RDS be trying to authenticate the client PCs via the trust through its own domain, or contacting our DC directly? Which domain should we be nltest-ing? Thanks in advance! -Greg C
Embedding remote desktop web client in IFrame
Hi, we are currently working on a custom solution for a customer that builds upon Virtual Desktop. We have built a "cloud hub" website where the user manages everything from their profile, storage, viewing costs and dashboards. The customer would like to embed the Azure Virtual Desktop web client inside this website (i.e. not opening a new browser window/tab). Is this possible today? I tried creating a simple test.html with only an iframe tag and the page (as shown below). See attached image for result: <iframe width="560" height="315" src="https://rdweb.wvd.microsoft.com/arm/webclient/index.html" frameborder="0" allowfullscreen></iframe>
