This might not always be possible based on your configuration, but it is ideal since it keeps all the network traffic within VMware. In order to reduce latency and the likelihood of a UPD disconnect the server hosting the UPD share should be on the same VMware host as the RDS servers.

The next time the user signs into the server their index will load instantly. What they have done is create their own 'UPD' that stores all the user's Outlook and index data. The solution is to configure FSLogix Office 365 containers. You could disable the index back off, but it will lead to performance issues and it won't actually fix the issue. This will become a major issue when you have 5+ users on a server and the index throttles itself. The result is that the next time the user logs into the RDS and opens Outlook their search index will need to rebuild. This means that when a UPD is disconnected the user's index data is deleted. On Server 20 (Server 2019 does not have this issue, but it doesn't support Office) the Windows Search index is machine wide. I'll keep this updated any time I find new improvements.īefore you even consider deploying UPDs you need to be aware of this limitation. The goal of this article will be to configure the RDS and file servers in a way that maximizes performance and reduces the likelihood of UPD disconnects. User Profile Disks (UPDs) are great for load balanced RDS farms since it allows users to seamlessly roam from server to server. Some of the items below apply to FSL Profile Containers. After months of testing I recommend deploying FSLogix Profile Containers instead of User Profile Disks.

Loading profile outlook 2019