Tuesday 26 April 2016

Remote Desktop Services 301: Some Advanced RDS Setup Guidelines

Here are some of the key tenants we’ve picked up deploying standalone and farm based Remote Desktop Services (RDS) for our Small Business Solution (SBS) on-premises and in our cloud.

Virtual Desktop Infrastructure, or VDI for short, covers both Remote Desktop Services standalone, farm, and desktop operating system deployments.

This list, while not totally comprehensive, covers a lot of ground.

  • Hardware, Storage, and Networking
    • GHz and Cores are king
      • Balance core count and GHz versus cost
      • NOTE: Server 2016 licensing will be, and is as of this writing, based on core count!
        • Today is 2 sockets tomorrow is a server total of 16 cores
        • Additional Cores purchased in pairs
        • Example 1: Dual Socket 8 Core pair = 16 Cores total so OK in current and 2016 licensing
        • Example 2: Dual Socket 12 Core pair = 24 Cores total so base license of 16 Cores plus a purchase of 4 licenses (2 cores per license) would be required
        • NOTE: Examples may not line up with actual license terms! Please verify when 2016 goes live.
    • RAM is cheap so load up now versus later
    • Balanced RAM setup is better than Unbalanced
      • Balanced: 4x 16GB in primary memory channel slot
        • Best performance
      • Unbalanced: 4x 16GB in primary and 4x 8GB in secondary
        • Performance hit
    • ~500MB of RAM per user per session to start
    • 25-50 IOPS per user depending on workloads/workflows RDS/VDI
      • Average 2.5” 10K SAS is ~250 to 400 IOPS depending on stack format (stripe/block sizes)
    • Latency kills
      • Direct Attached SAS or Hyper-Converged is best
      • Lots of small reads/writes
    • Average 16bpp RDS session single monitor 23” or 24” wide: ~95KB/Second
      • Average dual monitor ~150KB/Second
      • Bandwidth use is reduced substantially with a newer OS serving and connecting remotely (RDP version)
  • LoBs (Line of Business applications)
    • QuickBooks, Chrome, Firefox, and Sage are huge performance hogs in RDSH
      • Be mindful of LoB requirements and provision wisely
    • Keep the LoB database/server backend somewhere else
    • In larger settings dedicate an RDSH and RemoteApp to the resource hog LoB(s)
  • User Profile Disks
    • Office 2013 and Exchange 2013 are a wash in this setting
      • Search is difficult if not broken
    • Search Index database will bloat and fill the system disk! (Blog post with “fix”)
    • Office 2016, though still a bit buggy as of this writing, and Exchange 2016 address UPDs and search
    • Be mindful of network fabrics between UPDs and RDSH(s)
    • Set the UPD initial size a lot larger than needed as it can’t be changed later without a series of manual steps
      • UPDs are dynamic
      • Keep storage limits in mind because of this
  • Printing
    • Printers with PCL 5/6 engines built-in are preferred
      • Host-based printers are a no-go for us
    • HP Professional series LaserJet printers are our go-to
    • HP MFPs are preferred over Copiers
      • Copier engines tend to be hacked into Windows while the HP MFP is built as a printer out of the box

Previous post on the matter: Some Remote Desktop Session Host Guidelines.

Here’s a snippet of Intel’s current Intel Xeon Processor E5-2600v4 line sorted by base frequency in GHz:


Depending on the deployment type we’re deploying either E5-2643v4 or E5-2667v4 processors for higher density setups at this time. We are keeping at or under eight cores per socket unless we absolutely require more due to the upcoming sockets to cores changes in Windows Server licensing.

If you’d like a copy of that spreadsheet ping us or visit the Intel Ark site.

Philip Elder
Microsoft High Availability MVP
Co-Author: SBS 2008 Blueprint Book
Our Cloud

No comments: