Terminal Server Questions

[Moltuae]

I'm at the step of configuring the RD Connection Broker for High Availability,

Are you sure that's what you need? ie, are you planning to create server clusters and add multiple RD connection brokers? I usually just have a single RD connection broker (which is continuously replicated to another physical server using Hper-V replica in case of a server outage). I use multiple RDSH servers (or 'collections') but not multiple gateways, brokers, etc.

 

[trevm999]

I doubt you will find many here that have setup a connection broker for high availability because for it to really be highly available you need the SQL server to be highly available and that costs $$ in licencing.

Once you've installed the connection broker it will have set up a database. Install SSMS and check it out, it will be educational.

You can also use powershell to test connecting to the DB using a connection string

 

[HCHTech]

Are you sure that's what you need? ie, are you planning to create server clusters and add multiple RD connection brokers?

Ahh, Maybe not. In the guide I am using, it mentions creating a "Cluster of one", making it easy to add more later. I think I'm confusing that with making a "Collection of one". As I understand it, you only need SQL if you are creating a cluster, since otherwise it uses the "internal database" and you don't need a SQL instance for that. This is where guides get you in trouble.

I think I'm going to back up, get rid of the SQL and the attempted Cluster and go forward with the "Collection of one" idea instead of the "Cluster of one".

Also, just received my copy of "RDS - The Complete Guide". More reading ahead!

 

[Moltuae]

Yeah, clusters are probably not something you need to get into, especially if you're visualizing everything. If you have multiple physical servers you can just use Hyper-V Replica for fail-over and redundancy. RDSH collections are much simpler to set up; you just add each server to the collection. Once I have a single RDSH server configured how I want it, I usually just make more of them by cloning.

Also, just received my copy of "RDS - The Complete Guide". More reading ahead!

Sounds like an interesting read.

My various 'Mastering ...' books have actually been updated now, after your thread made me realize my copies were shamefully out of date. I had a few relatives stuck what to buy me for Xmas, so decided to add a few to my wish-list

 

[HCHTech]

Well, in the last week, I've setup, broken, torn down & re-setup my RDSH Lab project at least 4 times - ha. I've got it working again, and have enough understanding to ask a few more questions. I've currently got 4 VMs. A DC, an Appserver (with all of the RDS roles except the session host), an RDSH, and a domain-joined workstation VM.

• I'm using user profile disks, and as described and expected, this creates VHDX files on the separate server. This brings up a couple of questions:
  • The names of the VHDX files do not contain the username but instead use the GUID, which means tracking/identifying them once you have 50 users seems like a nightmare.
  • I have accessed as a two separate users so far, and there are 4 VHDX files:
    • UVHD-S-1-5-21-2616074207-3976263559-3910418752-500.VHDX - 1.45GB (dated today, I believe at time of logon of the most recent user)​
    • UVHD-S-1-5-21-2616074207-3976263559-3910418752-1107.VHDX - 200MB (dated 4 minutes after the first file, possibly time of disconnect)​
    • UVHD-S-1-5-21-2616074207-3976263559-3910418752-1115.VHDX - 200MB (dated same as the first file)​
    • UVHD-template - 135MB (dated yesterday, I understand this is created when you first turn on UPDs)​
    • Given that I expect the UPDs to be small, maybe the original large one is from when I installed all of the applications from an admin login - which involved moving an 800MB directory to the server. not really sure.​
  • How are these things maintained? If a user comes to you with a "I deleted this important thing in my documents folder, can you get it back for me?" question, how do you do that? I'm assuming you have to restore the entire user profile VHD (once you have identified which one belongs to that user) to a separate location, then mount it separately to pick through and find that item?
  • How robust are they? Can they be corrupted (of course this must be true) just like a "regular" user profile? Do you have instances where you have to delete them altogether and let them recreate to solve a problem? Any other nightmare problems I haven't foreseen?

• How do you load updates to the applications installed on the RDSH servers when you have more than one RDSH server in a collection? I'm guessing "one server at a time", which means kicking everyone off server 1 to do the update there, then kicking everyone off of server 2 and back onto server 1 so you can do the update on server 2, then finally opening up server 2 again so the load balancing can work as intended. I'm concerned that this would turn out to be quite a long project if you just stop new connections on server 1 and wait for folks to disconnect. I think of all the trouble I have now getting users to get out (and stay out) of an application so I can update it, and I'm not thinking this new configuration is going to be easier.
• I like the idea of "maintenance without downtime" (with the reservations above) you get by having 2 or more RDSH servers in a collection, but in reality, this only applies to the RDSH servers. Unless you have two of the server(s) with the rest of the roles (licensing, web access, connection broker) you still have required downtime to maintain THOSE servers. I think this seriously dilutes the maintenance advantage I thought I would be getting. Load balancing is still important and likely the primary advantage of having multiple RDSH servers.
• And speaking of maintenance, if you have 2 RDSH servers, I would think not only "can you" load Windows updates on them separately without downtime, but it would follow that once you update server 1, you then MUST update server 2 as soon as practicable. It would seem too risky that an Windows update might change something important which would mean having collection members at different update levels for any time at all would be a recipe for problems.
• The RDS book I purchased covered the "change user /install" command, luckily, as I didn't find it elsewhere. That worked for everything I installed so far on my test setup, switching back to "change user /execute" when the installation was finished. I didn't try the "GUI way" to do this with the control panel app. For an ongoing setup, it made me wonder if this could be done (a new app could be installed) while the server was in use by workers. I'm going to presume not, but thought I would ask. Which begs the question, "What types of things can you do to the RDSH server while it is being used?
• If you are only using full-desktop-experience sessions (as opposed to remote apps), then asking the end users to log into the RDWEB portal seems pointless. They have to put in their credentials on the portal, only to be presented with an RDP file they can download, which when downloaded and run, asks them to put in their credentials again. So doing this once and saving that RDP file on their remote computer desktop would seem to be a better answer. Is there an SSO option I'm missing here?
• Is there any way to remote into a user session while it is in use? I'm thinking not, as it acts just like RDP - so remote support where you want the user to demonstrate their issue in front of you would involve remoting into the computer they are using to access the session, not into the session itself.
• Initially, I was thinking that this whole solution would avoid having to force users to use a VPN connection, but given @YeOldeStonecat 's comments, I don't think that's a good idea. I think it's safer to keep using the VPNs.

That's enough for now - I appreciate the feedback.

 

[Moltuae]

• I'm using user profile disks, and as described and expected, this creates VHDX files on the separate server. This brings up a couple of questions:

I don't use user profile disks - I've found them to be more hassle than they're worth. I use group policies and scripts to pre-configure applications, where necessary, and folder redirection. User's personalized application settings aren't transferred between application on different machines but I've never found that to be an issue in any of my customer's applications. The only real exception being browser profiles, for which they're asked to register with chrome to enable profile synchronization, if needed.

• How do you load updates to the applications installed on the RDSH servers when you have more than one RDSH server in a collection? I'm guessing "one server at a time", which means kicking everyone off server 1 to do the update there, then kicking everyone off of server 2 and back onto server 1 so you can do the update on server 2, then finally opening up server 2 again so the load balancing can work as intended. I'm concerned that this would turn out to be quite a long project if you just stop new connections on server 1 and wait for folks to disconnect. I think of all the trouble I have now getting users to get out (and stay out) of an application so I can update it, and I'm not thinking this new configuration is going to be easier.

Precisely that.

The day before I plan to do updates I disallow logins to the relevant server(s). The following day (now that everyone is logged out), I update the server(s). Once I've finished and confirmed everything is working as expected, I re-allow logins and disallow logins to the alternate server(s). Then the next day, I update those servers, check them and re-allow access.

• I like the idea of "maintenance without downtime" (with the reservations above) you get by having 2 or more RDSH servers in a collection, but in reality, this only applies to the RDSH servers. Unless you have two of the server(s) with the rest of the roles (licensing, web access, connection broker) you still have required downtime to maintain THOSE servers. I think this seriously dilutes the maintenance advantage I thought I would be getting. Load balancing is still important and likely the primary advantage of having multiple RDSH servers.

The downtime for those servers is usually quite minimal. Firstly, you're not going to have user applications installed on there, so you're usually just doing Windows updates once a month. Secondly, rebooting those servers isn't anything like as disruptive. It usually just means that nobody can log in for a few minutes. Anybody already logged in won't be affected, only new logins.

• And speaking of maintenance, if you have 2 RDSH servers, I would think not only "can you" load Windows updates on them separately without downtime, but it would follow that once you update server 1, you then MUST update server 2 as soon as practicable. It would seem too risky that an Windows update might change something important which would mean having collection members at different update levels for any time at all would be a recipe for problems.

Never had a problem. What I often do though is log into all of them (as an admin) and install the updates while they're in use, then all I have to do is reboot them in turn later (once everyone is logged out). The only exception is LoB software that uses a common database, requiring each installation to be on the same version. But that's unavoidable -- with such software you usually have database updates to install too, so planned maintenance and downtime is expected.

• If you are only using full-desktop-experience sessions (as opposed to remote apps), then asking the end users to log into the RDWEB portal seems pointless. They have to put in their credentials on the portal, only to be presented with an RDP file they can download, which when downloaded and run, asks them to put in their credentials again. So doing this once and saving that RDP file on their remote computer desktop would seem to be a better answer. Is there an SSO option I'm missing here?

I just give them an RDP shortcut (to use over VPN, where necessary). I've never bothered with the portal. Seems a bit pointless and confusing for most users. I create RemoteApp shortcuts too -- much simpler.

• Is there any way to remote into a user session while it is in use? I'm thinking not, as it acts just like RDP - so remote support where you want the user to demonstrate their issue in front of you would involve remoting into the computer they are using to access the session, not into the session itself.

Yes. In Collections -> Connections, right-click the logged in user and select 'Shadow'.

Depending on your Remote Support software you may be able to connect directly into the user's RDP session that way too. In ScreenConnect, for example, you just log directly into the RDSH server (as an admin) then select the user's login session.

Initially, I was thinking that this whole solution would avoid having to force users to use a VPN connection, but given @YeOldeStonecat 's comments, I don't think that's a good idea. I think it's safer to keep using the VPNs.

I always use VPN. I like the extra layer of security. And while the RDweb portal might be considered secure, I just prefer not expose things like that directly to the internet. Additionally, where we have GDPR to contend with in the UK, having no ports forwarded/open, makes it easier to remain compliant.

 

[trevm999]

I think UPD is pretty much legacy at this point. FSLogix licencing is included with Windows.

With FSLogix you can configure the naming scheme, we use username_SID
We didn't have issues with temp profiles, but you can prevent logon when it's a temp profile. We did enable preventing logon when FSlogix vhdx doesn't mount, because having a local profile created and someone working in it is a major PITA with our LoB software.

Sounds like you got the file restore idea right, pull the vhdx backup and mount to get the files.

 

[trevm999]

Haven't had issues with servers on different Windows updates. MS Office is an issue though, had to disable autoupdating when using UPD/FSLogix

 

[trevm999]

If you're only going to do 2 hosts, it might not be worth it to do FSLogix/UPD unless you have a good reason (like performance)

 

[HCHTech]

I think UPD is pretty much legacy at this point. FSLogix licencing is included with Windows.

Thanks - had no idea, which is no surprise. Hardest part of learning about this finding out enough of the stuff that isn't in the books (like FSLogix) so you don't do something stupid when it comes to client setups. In my reading, UPDs "fixed" the problems with earlier methods. No harm/no foul in the lab, though.

If I don't do redirected folders/UPD/FSLogix, then the RDSH server has to have more storage, of course. It just sounded "neater" to me to put the user stuff on a different server.

If you're only going to do 2 hosts, it might not be worth it to do FSLogix/UPD unless you have a good reason (like performance)

I'm concerned about performance, definitely. Since the setup that this lab is training me for will be for a client that is used to well-specced physical desktops for everyone, moving to fewer, shared workstations for folks in the office and RDSH for remote should not feel like a downgrade to the users if I can avoid it.

 

[trevm999]

The performance would be vs redirected folders, and is probably only a factor in situations where something is making a ton of tiny calls the network share. There is overhead to each individual network call, this is why we use FSLogix, because we use a program that does that.

 

[trevm999]

For us, with 7 hosts and 140 users, space requires for each host was a factor in the decision, however MS Office / Teams can really cause VHDX ballooning, so there ends up being free disk space tied up in the VHDX. We have a VHDX shrinking script that runs every night, but it only works when people log out. So some people it probably has never run for.

"Use the red log off icon on the desktop"
"You mean the red x in the top right corner?"
fml

 

[HCHTech]

Ok, I'm stuck again. This is maddening - I probably I just need to let it go for a day or so and look with fresh eyes, I don't know.

I have a workstation VM on the test LAN for the LAB, and from that workstation, everything works. But when I try from outside the lan or over the web, I can get to the login page by using https://rds.mydomain.com/rdweb, and I can log in with a lan user, but the RDP shortcut for the collection won't open a desktop session - I just get "The remote resource can't be reached. Check your connection and try again."

I have the SSL certificate for rds.mydomain.com (and it was been installed on the Sonicwall, and the server with the Connection Broker Role, and it is properly loaded for each role in the Deployment options (Each role service shows Level = Trusted and Status = OK). I have a public DNS record pointing to the static IP I'm using for this traffic, I have a firewall rule to only allow incoming traffic on port 443, and forward it to the server that has the Connection Broker role. All of this must be working because I can get to the RDS login page when attempting access over the internet.

I've been through all of the deployment options about 46 times and don't see anything that looks out of place. I've been through all of the event logs on the server that has the connection broker role and don't see anything related. I've been through the event logs on the RDSH server and don't see anything out of place there either. I've toggled on the checkbox for "Bypass RD Gateway server for local addresses" as a test, but that doesn't change anything - Access from the LAN workstation works, but access over the internet doesn't.

Can someone point me to where I should be looking for clues on where this is breaking down?

 

[Sky-Knight]

That sounds like the gateway service either isn't working or isn't configured to deliver the correct links.

The .RDP file is downloadable, save it somewhere and edit it with a text editor. Verify your connection string is something that publicly resolves.

The Sonicwall doesn't need the certificate, but it does need to forward TCP 443 to the RDP Gateway.

 

[HCHTech]

Ok, - I have Server manager on the Lab DC connected to all servers. In the "Events" section of the "Servers" screen under "Remote Desktop Services", I see two errors:

LAB-APPSVR (this is the server with all roles except session host) 1280 Remote Desktop Services failed to join the Connection Broker on server LAB-Appsvr.LAB.local.

and

LAB-APPSVR 1306 Remote Desktop Connection Broker Client failed to redirect the user LAB\VMUser1

I actually looked for those errors on the APPSVR itself in event viewer, Applications and Services Logs\Microsoft\Windows\TerminalServices-SessionBroker-Client, just to confirm that's where they were being generated.

So I think you are correct. The server is being identified by its internal DNS name, not by something publicly resolvable. I have a forward lookup zone specified in DNS on the DC for rds.mydomain.com, pointing to the IP address of the Connection Broker. So, I should change the Server FQDN in the deployment configuration of the RD Connection Broker Role Service to be rds.mydomain.com? Is that what you are saying? Since this server has all of the roles other than Session Host, I presume I should do that for the RD Gateway, RD Licensing & RD WebAccess Role Service as well?

 

[HCHTech]

That sounds like the gateway service either isn't working or isn't configured to deliver the correct links.

The .RDP file is downloadable, save it somewhere and edit it with a text editor. Verify your connection string is something that publicly resolves.

The Sonicwall doesn't need the certificate, but it does need to forward TCP 443 to the RDP Gateway.

Hey, @Sky-Knight - I'm still fighting with this, and I'm having trouble finding the problem. Here's where I am:

1. If I'm inside the network, I can RDP to the IP address of the gateway/connection broker server, and it works. I get a session on the RDSH host.
2. If I'm outside the network, but VPN into the firewall, I can do the same thing. RDP to the IP address of the gateway/connection broker server, and it works. Because, if I have a VPN session, I'm not actually outside the network - duh.
3. If I try without the VPN to RDP to the FQDM (rds.mydomain.com) I'm using, it doesn't work. I get the message that the 'remote resource cannot be reached'.
4. If, from outside the network, I browse to https://rds.mydomain.com, I get the IIS screen on the gateway/connection broker server. This tells me my firewall rule is working as desired.
5. If, from outside the network, I browse to https://rds.mydomain.com/rdweb, I get the RDWebAccess login page, on which I can use a domain username and credential to successfully log in and see the RDP shortcut to the collection. If I download this, it doesn't work, producing the message that the 'remote resource cannot be reached'.
6. If I open that RDP shortcut in notepad, there is more than one line that refers to the server. Here is the relevant section:
=============
full address:s:LAB-APPSVR.HCHLAB.LOCAL
gatewayhostname:s:LAB-APPSVR.HCHLAB.local
workspace id:s:Lab-AppSvr.HCHLAB.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.LAB_Collection
use multimon:i:1
alternate full address:s:LAB-APPSVR.HCHLAB.LOCAL
=============

I have tried changing one and all of those lines, but I'm not sure what it is looking for, and I cannot find error messages in the logs anywhere that point me to the solution.

PLUS - if it think about this logically, If I'm using RDP to come in from outside, then that traffic is going to be on 3389, isn't it? My firewall rule is blocking everything except for 443, so how could that ever work? As a test, I tried allowing all traffic in the firewall rule, but that didn't help, because I think the lines in the RDP are wrong. I just don't know what the right answer is, so I'm stuck.

FURTHER, if the collective wisdom is that outside access should be over VPN anyway, then why don't I just use the IP address, which works, and skip the domain name and certificate altogether? I'd like to keep using the domain name even over the VPN, but that isn't working and I can't seem to find the salient clue about exactly where the failure point is.

I'm working on this whole thing off hours, and after a couple weeks of spinning my wheels, I'm losing the motivation to continue on that path. I guess I'm having trouble understanding why modifications to the RDP shortcut are even necessary, given proper setup of this whole thing. Considering outside access is the primary function being supported here, why doesn't it work out of the box? It strikes me like if you bought a new car and it wouldn't work until you hand-made your own ignition key!

 

[SAFCasper]

gatewayhostname:s:
This one needs to be rds.mydomain.com or whatever external domain you are using. This should resolve to your firewalls public IP which then forwards 443 TCP internally to your RD Gateway server. Also 3391 UDP should be forwarded but not essential it just improves performance/features..

I'd also make an internal DNS record for rds.mydomain.com to point to the internal IP of your server. This way RDP files work both internal and external.

You NEVER open 3389 to the public internet. The entire purpose of your RD Gateway is to secure everything behind HTTPS.


PS.
You are correct. If you use a VPN or only RDP internally there is no requirement for the RD Gateway role. Same goes for RD Web really, although it's still useful for users to download preconfigured RDP files.

 

[Sky-Knight]

@HCHTech, RDS Deployment Properties, RD Gateway Tab (Based on Google since I don't have one of these handy to go look myself)

You have it configured to deploy using LAB-APPSVR.HCHLAB.LOCAL when it should be rds.mydomain.com

As SAFCasper indicated, it really helps to have mydomain.com resolving on the DC, so you can make your internal network resolve private IP addresses for public names. That way you can configure your RDS deployment to use the Internet names all the time, instead of trying to straddle the divide between two name spaces.

Let DNS handle the split and save your hair!

For the record, this is why Microsoft told us to stop using .local, and start using AD.mydomain.com for AD environments... ad.mydomain.com won't be available to the world just the same, but it also means you can make public records that can support it with a click. You can't publicly support.local ever... and it presents issues on many defaults when you have systems like RDS that have to jump the gap.

Note, every single network I support is still .local based, so I say the above knowing full well I have a TON of old stuff out there. You likely do too, so you get to learn to adapt now as I have.

 

[HCHTech]

This one needs to be rds.mydomain.com or whatever external domain you are using. This should resolve to your firewalls public IP which then forwards 443 TCP internally to your RD Gateway server. Also 3391 UDP should be forwarded but not essential it just improves performance/features..

I'm aware 3389 shouldn't be open, but when you are grabbing at straws you have to test every possibility. I already have an internal DNS forward lookup zone that points rds.mydomain.com to the ip address of the gateway server.

My question remains, though.....if I'm using RDP to come in from the outside, isn't that traffic BY DEFAULT going to be on 3389? Maybe I should be using RDP to connect from outside to rds.mydomain.com:443?

 

[Sky-Knight]

@HCHTech You're chasing squirrels.

You just need to reset the published names, the cluster figures all that out. And yes, when you're done it's all RDP proxied over https, so you're only forwarding TCP 443 in from the world.

Set-RDPublishedName

Seems to be the powershell command to do this, it seems it was removed from the Server 2016 GUI? and never put back in 2019?

I need to setup a lab myself.