RDS 2019 Setup and RDS License Role
-
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
Working on replacing two 2k8R2 TS servers with RDS 2019. These two servers host a LOB application with about 50 users.
Due to a few issues with our current setup and LOB app limitations, my plan is to create two RDS servers holding their own RDSH, RDCB, and RDWA roles. Each server will have their own collection (Containing only itself)
My question is, can these two servers still connect to one RDS License server (which will be located on a DC)? (I don't see why not but figured I'd check)
I know this is convoluted but it will change in the future to a single RDSH server with all roles as we will be upgrading to the new version of our LOB app connecting to a backend SQL Server.
Question answered, but curious, why not have Broker/Gateway/Web roles on their own server/VM then have two collections set up along with their respective session hosts configured on that VM?
That would make things like user profile disks (FSLogix) and load balancing, and certificates, a lot simpler to work with along with getting Single Sign-On configured in AD.
I was not planning on using the RDGW as my user come in via a SSLVPN.
As for the rest, my current issues are, Windows licensing costs (keep them down as I keep trying to move services off of windows), going from 2K8R2 to 2019, we will need to use both old version and new version at the same time, limitations in the old version of our LOB app keeps my configuration options very limited without dorking up the current data, and trying to do this will minimal distraction to my in-house users and our remote clients from a tech side.
Just moving to the new version of our LOB app is going to be a wallop to our users.
This convoluted setup is temporary until the old LOB version dies. Its the best I could come up with based on my research, RDS requirements, licensing costs (Server, CALs, RDS CALs..etc...), LOB and user requirements/limitations.
RDGW provides a layer of protection whether via HTTPS 443 port forwarding, which is the only way to publish RDS Internet facing IMNSHO, or using a VPN of any sort.
(been busy the last couple days)
I have an SSLVPN setup already so I am good here.Using a single Broker setup would simplify management and ease of connection for users.
I would like to use as single Broker if possible.
Q. - If I have ServerRDS1 with RDSH/RDWA/RDCB with a Collection1 that includes ServerRDS1 and I setup ServerRDS2 with RDSH/RDWA, can I just add a Collection2 that includes just ServerRDS2?
In the future, I am looking to get down to one RDSH/RDCB/RDWA for my remote clients only. I won't need a second one.
One option would be to use one collection session host setup for the user's dedicated desktop and then publish the other session host's software installed as RemoteApps back to those users. That keeps things relatively clean in the user's local profiles.
I will look into this a little further. I have never used RemoteApps before as the need was not there.
Each collection will have its own dedicated session host(s). So, a new collection would need to be added and then a new session host which is set up for whatever app to be delivered via RemoteApp.
Do I HAVE to use RemoteApp in this situation? Can users still RDP directly to the RDSH in Collection2? (I don't see why I couldn't but I may be missing something)
You can add as many session hosts to existing collections as is needed and the broker will load balance accordingly (UPD/FSLogix needed here).
Good to know. If I do have a server farm in the future, then I would use UPD/FSLogix at that time.
We avoid deploying all-in-one RDS solutions as much as possible. 95% of all maintenance with reboots will be run on the session host. The Broker/Gateway/Web can stay up while all of that is done. Plus, with load balancing multiple session hosts it's possible to run or fix something while the farm is online.
I would prefer my setup this way but my Windows licenses are limited (Grrhhh).
Collection 2 would be another desktop session then. Users need one desktop session to work from. The RemoteApp collection(s) provide some flexibility for distributing CPU/RAM resources across other virtual machines instead of one monolithic session host.
Direct answer: No. But 2 different desktops would be somewhat confusing?
ServerRDS1 in Collection1 would be to connect to the new SQL LOB app only
ServerRDS2 in Collection2 would be for old LOB app. Access to old and new version cannot co-exist on the same server at the same time (LOB app limitations).Each user would have only one desktop session.
Remote clients will connect to ServerRDS2 until their data is converted to new LOB app (I will then give them a new RDP connection to ServerRDS1).
Internal employees will have have one RDP desktop for access to ServerRDS2 and use their local pc when their clients data is converted to new LOB app.
UPD should be used all the time. No local profiles on the session host. No UPD/FSLogix means no ability to add another session host down the line.
From what I read, I can move to UPD down the road if I like, correct?
I am looking for ServerRDS2 to go away within a year or so.
Talk to a SPLA license provider. Depending on your setup, the extra VM license via Server Standard SPLA would be inexpensive.
This I would have to look into. We current have a volume license with SA and two more years on the contract.
-
@pmoncho said in RDS 2019 Setup and RDS License Role:
From what I read, I can move to UPD down the road if I like, correct?
I believe you can change settings on the collection to use UPD later. The caveat being there is no import of profile so when you do that everyone is starting fresh.
-
@NDC said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
From what I read, I can move to UPD down the road if I like, correct?
I believe you can change settings on the collection to use UPD later. The caveat being there is no import of profile so when you do that everyone is starting fresh.
That is good to know. I was toying with using it on my new RDS deployment.
-
@NDC said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
From what I read, I can move to UPD down the road if I like, correct?
I believe you can change settings on the collection to use UPD later. The caveat being there is no import of profile so when you do that everyone is starting fresh.
Thanks. No real issue as all they have access to is a single shortcut and printers. I pretty much lock them down.
-
@wrx7m said in RDS 2019 Setup and RDS License Role:
@NDC said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
From what I read, I can move to UPD down the road if I like, correct?
I believe you can change settings on the collection to use UPD later. The caveat being there is no import of profile so when you do that everyone is starting fresh.
That is good to know. I was toying with using it on my new RDS deployment.
I was wondering whether you were going to choose UPD's or not.
-
Why setup UPD if there is literally only one RDS host? yes the OP has two - but for two completely separate things.
-
@Dashrender said in RDS 2019 Setup and RDS License Role:
Why setup UPD if there is literally only one RDS host? yes the OP has two - but for two completely separate things.
That is a good question. I would only have one host, so... if there isn't a benefit to a single server, then I won't be using it.
-
@pmoncho said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@pmoncho said in RDS 2019 Setup and RDS License Role:
Working on replacing two 2k8R2 TS servers with RDS 2019. These two servers host a LOB application with about 50 users.
Due to a few issues with our current setup and LOB app limitations, my plan is to create two RDS servers holding their own RDSH, RDCB, and RDWA roles. Each server will have their own collection (Containing only itself)
My question is, can these two servers still connect to one RDS License server (which will be located on a DC)? (I don't see why not but figured I'd check)
I know this is convoluted but it will change in the future to a single RDSH server with all roles as we will be upgrading to the new version of our LOB app connecting to a backend SQL Server.
Question answered, but curious, why not have Broker/Gateway/Web roles on their own server/VM then have two collections set up along with their respective session hosts configured on that VM?
That would make things like user profile disks (FSLogix) and load balancing, and certificates, a lot simpler to work with along with getting Single Sign-On configured in AD.
I was not planning on using the RDGW as my user come in via a SSLVPN.
As for the rest, my current issues are, Windows licensing costs (keep them down as I keep trying to move services off of windows), going from 2K8R2 to 2019, we will need to use both old version and new version at the same time, limitations in the old version of our LOB app keeps my configuration options very limited without dorking up the current data, and trying to do this will minimal distraction to my in-house users and our remote clients from a tech side.
Just moving to the new version of our LOB app is going to be a wallop to our users.
This convoluted setup is temporary until the old LOB version dies. Its the best I could come up with based on my research, RDS requirements, licensing costs (Server, CALs, RDS CALs..etc...), LOB and user requirements/limitations.
RDGW provides a layer of protection whether via HTTPS 443 port forwarding, which is the only way to publish RDS Internet facing IMNSHO, or using a VPN of any sort.
(been busy the last couple days)
I have an SSLVPN setup already so I am good here.Using a single Broker setup would simplify management and ease of connection for users.
I would like to use as single Broker if possible.
Q. - If I have ServerRDS1 with RDSH/RDWA/RDCB with a Collection1 that includes ServerRDS1 and I setup ServerRDS2 with RDSH/RDWA, can I just add a Collection2 that includes just ServerRDS2?
In the future, I am looking to get down to one RDSH/RDCB/RDWA for my remote clients only. I won't need a second one.
One option would be to use one collection session host setup for the user's dedicated desktop and then publish the other session host's software installed as RemoteApps back to those users. That keeps things relatively clean in the user's local profiles.
I will look into this a little further. I have never used RemoteApps before as the need was not there.
Each collection will have its own dedicated session host(s). So, a new collection would need to be added and then a new session host which is set up for whatever app to be delivered via RemoteApp.
Do I HAVE to use RemoteApp in this situation? Can users still RDP directly to the RDSH in Collection2? (I don't see why I couldn't but I may be missing something)
You can add as many session hosts to existing collections as is needed and the broker will load balance accordingly (UPD/FSLogix needed here).
Good to know. If I do have a server farm in the future, then I would use UPD/FSLogix at that time.
We avoid deploying all-in-one RDS solutions as much as possible. 95% of all maintenance with reboots will be run on the session host. The Broker/Gateway/Web can stay up while all of that is done. Plus, with load balancing multiple session hosts it's possible to run or fix something while the farm is online.
I would prefer my setup this way but my Windows licenses are limited (Grrhhh).
Collection 2 would be another desktop session then. Users need one desktop session to work from. The RemoteApp collection(s) provide some flexibility for distributing CPU/RAM resources across other virtual machines instead of one monolithic session host.
Direct answer: No. But 2 different desktops would be somewhat confusing?
ServerRDS1 in Collection1 would be to connect to the new SQL LOB app only
ServerRDS2 in Collection2 would be for old LOB app. Access to old and new version cannot co-exist on the same server at the same time (LOB app limitations).Each user would have only one desktop session.
Remote clients will connect to ServerRDS2 until their data is converted to new LOB app (I will then give them a new RDP connection to ServerRDS1).
Internal employees will have have one RDP desktop for access to ServerRDS2 and use their local pc when their clients data is converted to new LOB app.
UPD should be used all the time. No local profiles on the session host. No UPD/FSLogix means no ability to add another session host down the line.
From what I read, I can move to UPD down the road if I like, correct?
I am looking for ServerRDS2 to go away within a year or so.
Talk to a SPLA license provider. Depending on your setup, the extra VM license via Server Standard SPLA would be inexpensive.
This I would have to look into. We current have a volume license with SA and two more years on the contract.
The UPD setting on the Broker is set. There's no changing it short of creating a new collection and setting up session hosts and profiles. There may be a hack out there, but we've never done it and wouldn't.
-
@Dashrender said in RDS 2019 Setup and RDS License Role:
Why setup UPD if there is literally only one RDS host? yes the OP has two - but for two completely separate things.
Portability.
Recoverability.
Profile migration simplicity.
Storage management is a lot simpler.
C:\Users\%UserName% problem does not exist.
Archiving is simpler for users that leave the org. Archive the .VHDX file.
Profile choke fix: Rename the .VHDX file to .OLD, log the user on, migrate their data. Done.We won't deploy using local storage profiles even on a separate partition. UPDs are way easier to work with all around.
-
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@Dashrender said in RDS 2019 Setup and RDS License Role:
Why setup UPD if there is literally only one RDS host? yes the OP has two - but for two completely separate things.
Portability.
Recoverability.
Profile migration simplicity.
Storage management is a lot simpler.
C:\Users\%UserName% problem does not exist.
Archiving is simpler for users that leave the org. Archive the .VHDX file.
Profile choke fix: Rename the .VHDX file to .OLD, log the user on, migrate their data. Done.We won't deploy using local storage profiles even on a separate partition. UPDs are way easier to work with all around.
Awesome - some great reasons there.. OK.. cool!
-
@PhlipElder said in RDS 2019 Setup and RDS License Role:
C:\Users%UserName% problem does not exist.
What is this problem? I modify the registry to force new user profiles to be created on a D:\ partition, which is a separate VD.
-
@PhlipElder said in RDS 2019 Setup and RDS License Role:
Archiving is simpler for users that leave the org. Archive the .VHDX file.
Profile choke fix: Rename the .VHDX file to .OLD, log the user on, migrate their data. Done.Is this specific to Hyper-V or is that even related to the way this works?
-
@wrx7m said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
C:\Users%UserName% problem does not exist.
What is this problem? I modify the registry to force new user profiles to be created on a D:\ partition, which is a separate VD.
IMNSHO, it's a mess.
It can be easier for malware to get around.
No registry hack required. -
@wrx7m said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
Archiving is simpler for users that leave the org. Archive the .VHDX file.
Profile choke fix: Rename the .VHDX file to .OLD, log the user on, migrate their data. Done.Is this specific to Hyper-V or is that even related to the way this works?
The User Profile Disk is a dynamic .VHDX file that gets created in the designated storage location.
It can be set up with a storage limit. 5GB, 10GB, or more. Whatever maximum user GB size may be needed.
^^^ This is another reason to use UPDs/FSLogix. Storage sprall.UPD TIP: Once the RDS setup is complete and the TEMPLATE.VHDX is created in the designated location, mount the TEMPLATE.VHDX file, and shrink the partition down to a "starter size" GB, and dismount it.
Example: We have a setup where we deployed 30GB maximum UPDs.
We edit the template to shrink the partition to 10GB. That's all a new user gets when they log on the first time. If they hit a warning for low storage down the road, we can do one of two things:
1: Clean-up your mess
2: Log them off, mount the .VHDX, expand the partition by 5GB or more, dismount the .VHDX, and have the user log on. They get instant storage increases. -
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@wrx7m said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
Archiving is simpler for users that leave the org. Archive the .VHDX file.
Profile choke fix: Rename the .VHDX file to .OLD, log the user on, migrate their data. Done.Is this specific to Hyper-V or is that even related to the way this works?
The User Profile Disk is a dynamic .VHDX file that gets created in the designated storage location.
It can be set up with a storage limit. 5GB, 10GB, or more. Whatever maximum user GB size may be needed.
^^^ This is another reason to use UPDs/FSLogix. Storage sprall.UPD TIP: Once the RDS setup is complete and the TEMPLATE.VHDX is created in the designated location, mount the TEMPLATE.VHDX file, and shrink the partition down to a "starter size" GB, and dismount it.
Example: We have a setup where we deployed 30GB maximum UPDs.
We edit the template to shrink the partition to 10GB. That's all a new user gets when they log on the first time. If they hit a warning for low storage down the road, we can do one of two things:
1: Clean-up your mess
2: Log them off, mount the .VHDX, expand the partition by 5GB or more, dismount the .VHDX, and have the user log on. They get instant storage increases.Good info. You gave me much to think about.
Are UPD's still worth it if I expect a user to use <200MB? Everything our users need on the RDSH server is in the LOB app?
-
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@wrx7m said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
Archiving is simpler for users that leave the org. Archive the .VHDX file.
Profile choke fix: Rename the .VHDX file to .OLD, log the user on, migrate their data. Done.Is this specific to Hyper-V or is that even related to the way this works?
The User Profile Disk is a dynamic .VHDX file that gets created in the designated storage location.
It can be set up with a storage limit. 5GB, 10GB, or more. Whatever maximum user GB size may be needed.
^^^ This is another reason to use UPDs/FSLogix. Storage sprall.UPD TIP: Once the RDS setup is complete and the TEMPLATE.VHDX is created in the designated location, mount the TEMPLATE.VHDX file, and shrink the partition down to a "starter size" GB, and dismount it.
Example: We have a setup where we deployed 30GB maximum UPDs.
We edit the template to shrink the partition to 10GB. That's all a new user gets when they log on the first time. If they hit a warning for low storage down the road, we can do one of two things:
1: Clean-up your mess
2: Log them off, mount the .VHDX, expand the partition by 5GB or more, dismount the .VHDX, and have the user log on. They get instant storage increases.10 GB in a profile? what are they saving in there? I can see giving them maybe 2, but even a 2 GB profile seems HUGE.
-
Profiles can be 1-2 GB easy even without the user intentionally adding things to it. Every program out there seems to want to pack info into the profile these days and not in small quantities.
-
@NDC said in RDS 2019 Setup and RDS License Role:
Profiles can be 1-2 GB easy even without the user intentionally adding things to it. Every program out there seems to want to pack info into the profile these days and not in small quantities.
Sure, fine (though I generally don't see them much over a 1 GB) but 10 GB or the ridiculous 30GB they start at as stated above? I suppose I have an ISO directory on my desktop right now that's 10 GB itself.. so that's in my profile... but if I'm on a TS, I'm likely not doing that.
-
@pmoncho said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@wrx7m said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
Archiving is simpler for users that leave the org. Archive the .VHDX file.
Profile choke fix: Rename the .VHDX file to .OLD, log the user on, migrate their data. Done.Is this specific to Hyper-V or is that even related to the way this works?
The User Profile Disk is a dynamic .VHDX file that gets created in the designated storage location.
It can be set up with a storage limit. 5GB, 10GB, or more. Whatever maximum user GB size may be needed.
^^^ This is another reason to use UPDs/FSLogix. Storage sprall.UPD TIP: Once the RDS setup is complete and the TEMPLATE.VHDX is created in the designated location, mount the TEMPLATE.VHDX file, and shrink the partition down to a "starter size" GB, and dismount it.
Example: We have a setup where we deployed 30GB maximum UPDs.
We edit the template to shrink the partition to 10GB. That's all a new user gets when they log on the first time. If they hit a warning for low storage down the road, we can do one of two things:
1: Clean-up your mess
2: Log them off, mount the .VHDX, expand the partition by 5GB or more, dismount the .VHDX, and have the user log on. They get instant storage increases.Good info. You gave me much to think about.
Are UPD's still worth it if I expect a user to use <200MB? Everything our users need on the RDSH server is in the LOB app?
I think so. After working with them for a while, it becomes fairly clear as to the "why".
-
@Dashrender said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
@wrx7m said in RDS 2019 Setup and RDS License Role:
@PhlipElder said in RDS 2019 Setup and RDS License Role:
Archiving is simpler for users that leave the org. Archive the .VHDX file.
Profile choke fix: Rename the .VHDX file to .OLD, log the user on, migrate their data. Done.Is this specific to Hyper-V or is that even related to the way this works?
The User Profile Disk is a dynamic .VHDX file that gets created in the designated storage location.
It can be set up with a storage limit. 5GB, 10GB, or more. Whatever maximum user GB size may be needed.
^^^ This is another reason to use UPDs/FSLogix. Storage sprall.UPD TIP: Once the RDS setup is complete and the TEMPLATE.VHDX is created in the designated location, mount the TEMPLATE.VHDX file, and shrink the partition down to a "starter size" GB, and dismount it.
Example: We have a setup where we deployed 30GB maximum UPDs.
We edit the template to shrink the partition to 10GB. That's all a new user gets when they log on the first time. If they hit a warning for low storage down the road, we can do one of two things:
1: Clean-up your mess
2: Log them off, mount the .VHDX, expand the partition by 5GB or more, dismount the .VHDX, and have the user log on. They get instant storage increases.10 GB in a profile? what are they saving in there? I can see giving them maybe 2, but even a 2 GB profile seems HUGE.
Remember, these are dynamic VHDX files. They start out at something like 4096 KB in size. If there's nothing much to go into the profile, then edit the template down to 500MB with a 1GB default size. They only use physical storage as they grow.
NOTE: If you need to enlarge the profile beyond the default maximum sized set when the farm was set up then it is a two step process with the user logged off:
1: Expand the .VHDX by needed GB
2: Mount and expand the partition then dismountThe user can then log on and they now have more space.
