To keep it simpler operationally, limit to 1 pool per RDS farm. So a session has 2 parents: pool and host. A session connects to a pool, and runs on the host. A farm can have many hosts and many pools, and pool has M:N relationship to host. RDS presents another challenge as it introduces Farm and Host concept. Showing the individual application will make them feel like an Apple Mac application. If you’re delivering Windows applications to Mac users, showing them a Windows desktop will be more confusing than simply showing them the individual applications. It’s not common as the overhead is the same with giving entire desktop. VDI can be used to deliver application session. That’s why vRealize Operations introduces the Usage Disparity metrics. If you are unlucky all the heavy users could end up on the same RDS session host. The initial placement can consider any metrics, but there is no “session vMotion” subsequently within the RDS Farm. It’s simply distributing the session based on initial placement. Hilko Lantiga shares another limitation of RDS is the load balancer does not balance based on actual load. All the sessions compete freely for its resources. Windows 2019 also does not have concept of shares, limit and reservation. When the application or Windows crash, more than 1 user are affected. Shared technology also carries higher availability risk. As you can guess, the shared is cheaper as it has less overhead, but harder to troubleshoot.

The shared architecture is called RDS and the dedicated architecture is called VDI. There are 2 competing architecture to deliver the above (desktop and application):

to organise their files) and use their applications (e.g. At the end of the day, users just wants to access their desktops (e.g.

Esxi vdi