A common question I come across with customers is, “Now that I’ve built a deployment, how do I install my applications?” That is a great question and if this blog doesn’t answer your question, feel free to email support@mycloudit.com and we’d be happy to help!
Some Notes to Get Us Started
A Rule of Thumb
You should keep your session hosts as generic as possible. Session host servers, as a rule, should only contain applications, not data. We deploy User Profile Disks (UPDs) so no user settings are stored on a session host server. This allows users to connect to any session host server within a collection and still receive all their personalized settings. This also makes session host servers expendable in case one becomes corrupt, or otherwise unusable.
What We Built
Luckily, we have a lot of documentation discussing what MyCloudIT builds for you and how you can move forward. Check out this blog, What We Built for You, to help give you an idea. This will give you a clear understanding of our architecture. Now that you understand what we built and that only applications (and not data) should be installed on the session host servers, we will move on to a golden image.
Golden Image
If you are going to deploy more than 2 session host servers, leveraging a golden image would be beneficial. Here is some additional information on why you should use a golden image. Follow these steps to create a golden image.
Now We Are Ready!
Installation
Applications should be installed on the session host servers; these servers will host the users’ sessions. All the data should be stored on the F: drive of your RDSMGMT server, or additional drives or servers, if you need additional storage. For this discussion, we will assume the F: drive of the RDSMGMT server will be sufficient for this discussion. The F: volume will be 1 TB in size if you requested Premium UPD Storage during the provisioning process, or it will be 2 TB of standard storage if you asked for standard UPD storage. Premium Storage is deployed on 1 TB SSD based disk within Azure. The 1 TB SSD disk provides 5,000 IOPS of disk performance, that is 5,000 Input Output Operations per second. If you chose Standard Storage, your storage consists of 2 1TB Standard unmanaged disks that are then striped together within Windows. We use 2 1TB standard disks so you receive an aggregate throughput of about 1,000 IOPS. Each standard disk is limited to 500 IOPS. UPDs consume a lot of disk IO (IOPS), so we try to provide the best throughput possible based on the storage chosen.
Folders
Once you are past the storage configuration, the F: drive usually has extra capacity that can be used as file storage. There are three folders that are pre-created on the F: drive. The NTDS, SYSVOL, and Shares directories. You are welcome to create additional folders within the F: volume and allow users to store data there, but please do not use the pre-created folders on the F: volume because they each have a specific purpose.
Permissions
Once you create a new folder for your user storage, you can then share out that folder and use the AD security group assigned to your collection as the security control, if collection specific permissions are adequate. As you know, if you need more granular permissions, you can always create them within the Windows Server Active Directory. Once you have your AD permissions configured, you can then share your folder with the specific permissions needed. Below, I’ve created a folder on the F: drive, then assigned the Active Directory permissions for the desktop collection group.
Here I created a Folder named DesktopCollectionGroupStorage. Then given permissions to the Desktop Collection Group Active Directory Security Group to control access to that share.
This makes it easy to manage permissions on a per-collection basis. Keep in mind that each RDS collection is managed by an Active Directory Security Group. Giving the Active Directory Security group permissions to your folder means that anyone added to a collection will automatically have access to the folder.
For example, if you created the standard RDS deployment, there is a Desktop Collection that has already been created for you. When you drill into the actual collection, the details page shows the Active Directory Security Group that manages permissions for the collection. For the Desktop Collection, the security group is named Desktop Collection Group.
The Active Directory Security Group assigned to a collection can always be identified within the Details page of the actual collection. Here, the AD Security Group is named Desktop Collection Group.
When you create a share on the F: of RDSMGMT, if you give the AD group Desktop Collection Group access to the share, then any user in the Desktop Collection collection will automatically have access to this share. This means that users will be able to access the data with either a drive letter mapping to the share, or a direct mapping to \\RDSMGMT\DekstopCollectionGroupStorage .
Going Forward
If you are managing users at the collection level, you can also manage their data access at a collection level if that is appropriate for your solution. When we talk about providing multiple users access to multiple collections, this little permissions management trick will eliminate a lot of permissions management overhead.
I hope I was able to answer your questions within this blog, but if not, please don’t hesitate to email support@mycloudit.com and our support team would be happy to assist with any questions.
Want Future News and Updates Emailed Right to Your Inbox?
