Server Name Indication (SNI) and SSL VPN

Been working a lot around PCI Citrix initiatives for the last couple of months.  After speaking with some very smart Citrix NetScaler folks, they were kind enough to provide a lot of information to me around security and SSL VPN which I am sharing with you.  Take notice that Windows XP and IE 7 is not supported and it puts so many companies at risk.

Many People are unfamiliar with Server Name Indication (SNI).  In a nutshell, when client computer browsers or SSL based VPNs are negotiating encryption with a server, there is no information which can be gleaned by the server in order to determine which virtual host the client is actually requesting.  This is due to the fact that the HOSTNAME of the subsequent request is contained in the encrypted header which would not be visible until after the received data was decrypted as it made its way down the stack.  This is problematic with respect to virtual hosting since each server or appliance can serve many hosts through the same address.  If it is desired to secure the data of that host through SSL, then a 1:1 mapping of hostname to IP address is currently required (not so good)

Client: (TLS Handshake) Hello, I support XYZ Encryption.
Server
: (TLS Handshake) Hi There, Here is my Public Certificate, and lets use this encryption algorithm.
Client
: (TLS Handshake) Sounds good to me.
Client
: (Encrypted) HTTP Request
Server
: (Encrypted) HTTP Reply

What about ‘STARTTLS’ or TLS ‘Upgrade’ in HTTP/1.1?

STARTTLS is another standard which is commonly used by protocols such as SMTP, POP, IMAP, and LDAP.  Back in the day, it was common practice to have parallel secure ports for most protocols.  For example,  with SMTP, POP, IMAP, and LDAP, and HTTP you have 25/465 110/995 145/993 389/636, and 80/443 respectively. The idea of  STARTTLS was born when the IETF which governs internet assigned numbers and ports decided back in 1997 at some meeting that the issuing of paralell “secure” ports for all protcols should be depricated.   With STARTTLS, when the connection to the server host is established, the client sends a plantext command with the virtual host name.  This has enough information for the server to decide which certificate to offer for the SSL/TLS handshake.

Client: (TLS Handshake) Hello, I support XYZ Encryption.
Client: (Cleartext) I am using server ‘access.mycompany.com
Server: (Cleartext) By The Way, I also support TLS Encryptionn.
Client: (Cleartext) Lets use Encryption, aka ‘STARTTLS’.
Client: (TLS Handshake) Hello, I support XYZ Encryption.
Server: (TLS Handshake) Hi There, Here is my Public Certificate, and lets use this encryption algorithm.
Client: (TLS Handshake) Sounds good to me.
Client & Server: (Encrypted) Exchange Data
 
 A similar method for web browsers, and SSL VPN clients was derived in the HTTP/1.1 specification and is called TLS Upgrade. HTTP/1.1 TLS Upgrade method can be applied to upgrade an open HTTP connection. In a nutshell, the client would include this in a request:
 
GET http://access.mycompany.com/securestuff HTTP/1.1
Host: access.mycompany.com
Upgrade: TLS/1.0
Connection: Upgrade
 
The server in turn might respond with:
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
 
The main benefit with these methods are that you can have both naked and secure traffic traversing through the same  port.  Main problems to this and likely why these methods have not been adopted are that all methods would require that any proxy servers in between the client and server also support this method.  A proxy server that did not acknowledge it or perhaps strips the command (could also happen on a legacy firewall), would potentially present a man-in-the-middle attack.  A lesser issue might be that you have a user perception issue as there is a certain familiarity with port 443 being the “secure” port.  On the server end of things, you would also need to have the unsecure port open for the application in question which may not be the case.

The Solution

An extension to SSL/TLS called Server Name Indication (SNI) addresses this issue by sending the name of the virtual host as part of the SSL/TLS negotiation. This enables the server to bind the correct virtual host early and present the browser with the certificate containing a CN matching that in the SNI header.  This method also has far fewer complications associated with it as compared to TLS Upgrade or STARTTLS.  The SNI extension is described in gross detail here. With SNI, you would have a sequence like:

Client: (TLS Handshake) Hello, I support XYZ Encryption, and I am trying to connect to
access.mycompany.com‘.
Server: (TLS Handshake) Hi There, Here is my Public Certificate, and lets use this encryption algorithm.
Client: (TLS Handshake) Sounds good to me.
Client: (Encrypted) HTTP Request
Server: (Encrypted) HTTP Reply
 

But Don’t Browser’s and Servers need to support this extension in order for this to work?

Yup, that is the idea.  As with any RFC, extension, or modification you have to have adoption by the software developers, and hardware vendors which in turn are driven by the adoption or request of the technology by the IT community.  The latter is only done through education and practical application examples which is one of my main drivers for writing this blog post.  At the time of this writing, there are no known Remote Access Appliances which support this RFC extension.  Below is the list of known browsers, servers, and SSL application libraries which do support the SNI extension:

Browsers

Servers

  • Apache with mod_gnutls or mod_ssl
  • Cherokee if compiled with TLS support
  • New versions of lighttpd 1.4.x and 1.5.x
  • Nginx with an accompanying OpenSSL built with SNI support
  • OS X 10.5.6

Libraries

  • Mozilla NSS
  • OpenSSL
    • 0.9.8f – not compiled in by default, can be compiled in with config option ‘–enable-tlsext’.
    • Unreleased 0.9.9 is likely to include SNI compiled in by default.
  • GNU TLS

Unsupported Operating Systems Browsers, and Libraries

The following combinations do not support SNI.

  • Windows XP and Internet Explorer 6 or 7
  • Konqueror/KDE in any version
  • Microsoft Internet Information Server IIS
  • Sun Java System Web Server
  • Microsoft.Net
  • Sun Java JSEE

What SNI could add to SSL-based VPN Solutions?

So what does this mean with respect to Remote Access Solutions such as Citrix Access GatewayF5 Firepass, or Juniper Secure Access remote access solutions?  The benefits of adopting support for SNI are wide an varying, but here is my first pass at a few:

  • Since the SNI would be presented to the access appliance before the SSL negotiation finalized, specific SSL policies such as supported cipher suites, could be bound to the session.   This would be useful where you needed to meet more stringent security requirements such as FIPS level 1/2 for specific hosts, or where you had a client application which used a specific type of encryption that you needed to utilize.
  • As cloud computing is becoming more prevalent, service providers are going to need a means to offer customers secure access to their applications and content.  Since many cloud services are based on anycast addresses (floating IP), CNAME records, and also servicing 1000′s of users, a 1:1 option for customer:IP is not practical or possible. SNI presents a cheap, workable alternative to having no secure offering.
  • Enterprises who wish to publicly expose their intranet or line of business applications securely may want to do so through a remote access appliance, but not want to allocate multiple public IP addresses.
  • Businesses who have only been allocated a single IP address and are using Port Address Translation (PAT) to serve up multiple applications.  This is actually pretty common since many businesses are provisioned with ADSL which uses DHCP assign IP addresses. Most companies use a remote access device as an all-in-one solution for outbound RNAT, inbound VPN, and line of business applications, and firewall.
About these ads

Outlook’s taskbar icon occassionally shows as PowerPoint

While working on a XenApp 6.5 project for a large company, I heard from one of the IT Directors that Outlook 2010 was showing the PowerPoint icon in the taskbar… Naturally I immediately attempted to reproduce the issue and was not able to.

Microsoft confirms this bug can affect you in the following scenario.

  • This is only happening on Windows 2008 R2 (Std or Ent Editions)
  • This is happening over RDP and ICA sessions, regardless
  • This is happening to Office 2010 (x64), Office 2007, and Office 2003 suites.

What I noticed after scratching my head a bit, this bug only occurred on the first launch of Outlook in an RDS/XenApp Desktop session.  Once the app was closed and reopened the icon showed the correct Outlook icon.  That is until you logged out and back in again and the PowerPoint icon came back for the initial launch of the app, of course completely randomly.

After doing some research, I was able to find a private hot fix from our friends at Microsoft, after applying the patch the issue was resolved.

Incorrect Outlook icon

Provisioning Services antivirus exclusions

Citrix wrote an excellent article about the PVS Antivirus exclusions and thought I will share it with you.  In my experience with PVS, this is very crucial step as it will ensure you don’t interrupt the streaming process and/or slow things down.

If you are like me and decide to run the TFTP boot process on separate servers, you can create TFTP HA utilizing the NetScalers, if you decide to go this route which I recommend, you will need to exclude the TFTP directory on the separate TFTP hosts.  You can read about how to HA the PVS  TFTP boot process via the NetScalers from a previous post I wrote, which let me tell you it was no easy task.

To read the entire Citrix article about the Antivirus exclusions, click here.

A few recommended Server Side file exclusions.

C:\Windows\System32\drivers\CVhdBusP6.sys => (PVS 6.1)
C:\Windows\System32\drivers\CVhdBus2.sys => (PVS 5.6)
C:\Windows\System32\drivers\CFsDep2.sys => (PVS 5.6 and PVS 6.1)
C:\Program Files\Citrix\Provisioning Services\BNTFTP.EXE => (PVS 5.6 and PVS 6.1)
C:\ProgramData\Citrix\Provisioning Services\Tftpboot\ARDBP32.BIN => (PVS 5.6 and PVS 6.1)
D:\Store => ( i.e. local vdisk store)

A few recommended Server Side processes to be excluded.
C:\Program Files\Citrix\Provisioning Services\StreamService.exe => (All versions)
C:\Program Files\Citrix\Provisioning Services\StreamProcess.exe => (All versions)
C:\Program Files\Citrix\Provisioning Services\soapserver.exe => (All versions)

A few recommended Target Device exclusions.
C:\Windows\System32\drivers\bnistack.sys => (Only targets, Win2003/XP)
C:\Windows\System32\drivers\bnistack6.sys => (Only targets, 2008/Win7)
C:\Windows\System32\drivers\BNNF.sys => (Only targets)
C:\Windows\System32\drivers\BNNS.sys => (Only targets, Win2003/XP)
C:\Windows\System32\drivers\BNNS6.sys => (Doesn’t exist anymore with PVS6.1 Agent)
C:\Windows\System32\drivers\BNPort.sys => (Only targets)
C:\Windows\System32\drivers\CFsDep2.sys => (Only targets, Win2003/XP)
C:\Windows\System32\drivers\CVhdBusP52.sys => (Only targets, Win2003/XP)
C:\Program Files\Citrix\Provisioning Services\BNDevice.exe => (Only targets, 2008/Win7)
C:\Program Files\Citrix\Provisioning Services\TargetOSOptimizer.exe => (Only targets, 2008/Win7)

 

New XenApp/XenDesktop preview – Project (Avalon) Excalibur Technology

Citrix has released today the Tech Preview of the new XenDesktop/XenApp version.

Project (Avalon) Excalibur Technology Preview is our next-generation, unified desktop and app virtualization technology that is reinventing the delivery of Windows apps and desktops for mobility in the cloud-era.  The availability of this tech preview will allow Citrix customers and partners to have a first-hand look at a new unified FlexCast infrastructure combining VDI and Hosted Shared desktops and apps from a single platform.

New features include:

  • Simplified, unified, and expanded FlexCast 2.0 architecture New unified FlexCast 2.0 architecture combines simplified and integrated provisioning and personalization tools for both desktops and apps, delivered from either a desktop-based or server-based operating system.
  • Windows Server 2012 and Windows 8 Host Windows 8 VDI desktops or VM hosted applications in addition to Windows Server 2012 server-based desktops and applications. This tech preview also supports Windows 2008R2/SP1 and Windows 7.
  • SuperCodec for Optimized Graphics New enhancements to HDX using Deep Compression Codec technology double the visual performance of desktops and apps to mobile devices dynamically adapting for device type, form factor and network connection while still leveraging the processing power of modern tablets and smartphones
  • Storefront for apps & data Create centralized enterprise app stores to deliver desktops, applications, and other resources to users on any device, anywhere with the Citrix StoreFront.
  • Intelligent configuration tools New intelligent configuration tools for deploying desktops and apps that proactively check configuration errors in real time while streamlining the provisioning of profile management and storefront settings.
  • Delegated Administration Enterprise-class administration model includes role-based access, custom roles with configurable permissions, and fine-grained, object-based control.
  • Advanced Configuration Logging Capture site configuration changes and administrative activities within a single tool, Desktop Studio.  Use Desktop Studio to diagnose and troubleshoot problems after configuration changes are made, assist change management, track configurations, and report administration activity.
  • Personal vDisk Improvements Improve scalability with performance enhancements designed to optimize resource utilization, deliver updates faster with the newly enhanced personal vDisk update process, and experience how an improved architecture increases the number of apps compatible with personal vDisk technology.

With a valid My Citrix ID you can download this Tech Preview here.

XenApp 6.5 / XenDesktop 5.6 Best Practice Policies

One of the most common mistakes that Citrix Engineers make in a XenApp/XenDesktop deployment is not taking the time to fully understand Citrix Policies.  There are several articles such as the XenApp and Desktop Policy Planning Guide and the XenDesktop and XenApp Best Practices Reference Guide I suggest reading.

I been in environments running pretty large farms where policies are not applied at all.  It is very important to take the time to go over these, as you can provide better session control and most importantly a better end user experience, specially when working with high latency connections for remote offices.

The policies below are from a collection of the docs mentioned above, as well as my own experience.

XenApp Baseline User Policy:

Apply this policy as your baseline to all users connecting to your XenApp farm.

ICA\Adobe Flash Delivery\Flash Redirection
Flash acceleration – Enabled
Flash default behavior – Enable Flash Redirection
Flash event logging – Enabled
Flash intelligent fallback – Enabled
Flash latency threshold – 30 milliseconds

ICA\Audio
Audio Plug N Play – Allow
Audio quality – Medium
Client audio redirection –  Allow
Client microphone redirection –  Prohibit

ICA\Desktop UI
Desktop wallpaper – Allowed
Menu animation – Allowed
View window contents while dragging – prohibited

ICA\File Redirection
Client floppy drives – Prohibit
Client optical drives – Prohibit
Host to client redirection  Disable
Read-only client drive access – Disable
Use asynchronous writes – Enabled

ICA\Port Redirection
Auto connect client COM ports – Disable
Auto connect client LPT ports – Disable
Client COM port redirection – Disable
Client LPT port redirection – Disable

ICA\Printing
Client printer redirection – Allow
Default printer – Set to client’s main printer
Printer auto creation log preference – Errors
Wait for printers to be created (desktop) – Disabled

ICA\Printing\Client Printers
Auto-create client printers – Default printer only
Auto-generate generic universal driver – Disabled
Client printer names – Standard names
Direct connections to print servers – enabled
Retained and restored client printers – Allowed

ICA\Printing\Drivers
Automatic installation of in-bo printer drivers – Disabled
Universal driver usage – Use Universal Printing only if requested driver is unavailable

ICA\Printing\Universal Printing
Universal printing EMF processing mode – Spool to printer
Universal printing image compression limit – Best Quality
Universal printing optimization defaults – Standard Quality
Caching of embedded images
Caching of embedded fonts
Universal printing preview preference – Use for auto-generated and generic

ICA\Session Limits
Linger Disconnect Timer Interval – 5 Minutes
Linger Terminate Timer Interval – 10 Minutes
Pre-Launch Disconnect Timer Interval – 15 Minutes
Pre-Launch Terminate Timer Interval – 30 Minutes

ICA\Shadowing
Log shadow attempts – Allow
Notify user of pending shadow connections – Allow
Users who can shadow other users – Defined by security

ICA\Time Zone Control
Estimate local time for legacy clients – Enable
Use local time of client –  Use Client time zone

ICA\TWAIN devices
Client TWAIN device redirection – Enabled
TWAIN compression level – low

ICA\Visual Display\Moving Images
Moving Image Compression – Enabled
Server Session Settings
Session importance – Normal
Single Sign-on – Disabled

XenApp Baseline Computer Policy Setting.

Apply this policy as your baseline to all Servers in your XenApp farm.

ICA
ICA listener connection timeout – 120000 ms
ICA listener port number – 1494

ICA\Auto Client Reconnect
Auto client reconnect – Allow
Auto client reconnect authentication – Not required
Auto client reconnect logging – Disabled

ICA\End User Monitoring
ICA round trip calculation – Enable
ICA round trip calculations for idle connections – Disable

ICA\Graphics
Display memory limit   32768 KB
Display mode degrade preference – Degrade Color Depth First
Dynamic Windows preview – Enabled
Image caching – Enabled
Maimum allowed color depth   32 bit
Notify user when display mode is degraded – Disabled
Queuing and tossing – Enabled

ICA\Graphics Caching
Persistent Cache Threshold – 3000000 Kbps

ICA\Keep Alive
ICA keep alive timeout – 60 seconds
ICA keep alives – Enabled

ICA\Multimedia
Windows Media Redirection – Allowed

ICA\Session Reliability
Session reliability connections – Prohibited

ICA Shadowing
Shadowing – Allow

Licensing
License server host name – License Server name
License server port – 27000
Server Settings
DNS address resolution – Enabled
Full icon caching – enabled

Server Settings\Health Monitoring and Recovery
Health Monitoring – Enabled
Health Monitoring tests – Use Defaults (please configure as you see fit.)

Server Settings\Memory/CPU
CPU Management server lever – preferential load balancing
Memory optimization – Enabled
Memory optimization interval – enabled

Server Settings\Reboot Behaviour
Reboot logon disable time – Choose a value to suit your clients
Reboot Schedule frequency – Choose a value to suit your clients
Reboot Schedule start date  – Reboot Schedule Choose first day of the reboot
Reboot Schedule time – Choose time to restart server
Reboot warning interval – Choose interval which the users are notified about pending restart
Reboot warning users – enabled
Scheduled Reboots – enabled

XML Service
Trust XML requests – enabled
XML server port – 8080

XenApp WAN/External User Policy.

Apply this policy for users working from branch offices or remote locations with low bandwidth and/or high latency connections.

ICA\Adobe Flash Delivery\Flash Redirection
Flash acceleration – Enabled

ICA\Audio
Audio quality –  Medium

ICA\Client Sensors\Location
Allow applications to use the physical locations of the client device – allowed (Tablet Devices)

ICA\Desktop UI
Desktop wallpaper – prohibited
Menu animation – prohibited
View window contents while dragging – prohibited

ICA\File Redirection 
Use asynchronous writes – Enabled

ICA\Mobile Experience
Automatic Keyboard Display – Enabled (Tablet Devices)
Launch touch-optimized desktop – Enabled (Tablet Devices)
Remote the combo box – Enabled (Tablet Devices)

ICA\Printing  Wait for printers to be created (desktop) – Disabled

ICA\Printing\Universal Printing 
Universal printing optimization defaults – Standard Quality
Caching of embedded images
Caching of embedded fonts

ICA\TWAIN devices
Client TWAIN device redirection – Disabled

ICA\Visual Display 
Max Frames per Second – 15 FPS

ICA\Visual Display\Still Images
Extra Color Compression – Enabled
Extra Color Compression Threshold – 8192 kbps
Lossy compression level – High
Lossy compression level threshold value – Unlimited

XenDesktop Shadowing via Desktop Director – WinRM configuration for Windows 7

I think we can all agree that XenDesktop has VMware View beat as far as feature sets are concerned.  One of the best features of a XenDesktop 5.5/5.6 is the Virtual Desktop management via the Desktop Director.  It provides Admins, Support/NOC folks with an excellent overview on what is going on inside your deployment which can be utilized for user connection troubleshooting.  What is really nice, is that it gives you information on user sessions including Audio, USB devices, Flash Redirection, Printing as well as others.  One of the best features is to allow connections (AKA Shadowing) directly to XD sessions.

HDX session information

To use this feature you must configure WinRM, if this is not set up on your XD’s, you will receive the error below when establishing a connection, which will end up in a call at 2:00 AM for the Admins

Remote Assistance Connection issue

WinRM

Unlike Windows XP, WinRM is installed by default on a Windows 7 desktop so there is no need to install it.

Enabling Offer Remote Assistance Helpers Group

Creating a new GPO and assign it to the OU with the XD AD computer objects.  Edit the group policy and navigate to Computer Configuration –> Policies –> Administrative Templates –> System –> Remote Assistance:

clip_image002

Open up the setting Solicited Remote Assistance, enable the feature and set the following configuration as such:

Permit remote control of this computer: Allow helpers to remotely control the computer

Maximum ticket time (value): 1

Maximum ticket time (units): Hours

Method for sending e-mail invitations: Simple MAPI

clip_image002[4]

Apply the settings, open up the setting Offer Remote Assistance, enable the feature and configure the settings as such:

Permit remote control of this computer: Allow helpers to remotely control the computer

Helpers: domain\domain admins or your preferred group

**Note: that you can set the helpers to any group you choose.

clip_image002[6]

Image

Apply the settings and you should see the following:

clip_image002[8]

Once the GPO has been applied to the desktops, you should now see the group Offer Remote Assistance Helpers listed:

clip_image002[10]

Image

Once you’ve verified that the GPO has been applied, proceed by attempting to shadow a user’s desktop and remote assistance should launch:

Image

Image

Determining the size of your Provisioning Services Write-Cache

I been prepping to get a new XenDesktop 5.6 FP1 / XenApp 6.5 environment to run with Provisioning Services 6.1.  In the last few weeks, I been collecting lots of information re: best practices, etc.   In the past I worked with PVS versions 5.0, 5.1, 5.2 and 5.6.  However I always ask my self and others “What is the correct size for my write-cache?” A good question and the answer, well “it depends.”  Below is some great information to use for determining the write-cache drive size.

What is Provisioning Services, a write-cache, and why does it matter?

Before we begin a little background on Citrix Provisioning Services (PVS) and how it works. Provisioning Services provides administrators the ability to virtualize a hard disk or workload and then stream it back out to multiple devices. The workloads, which can be server or desktop, are ripped from a physical or virtual disk into Microsoft’s virtual hard disk (VHD) format and treated as a golden master image called a vDisk. This master image is then streamed over the network from a Windows server running the stream service to multiple target devices that were PXE booted.

Device drivers (network and disk) installed on the target devices (physical or virtual) have the intelligence to route disk file requests over the network to the PVS streaming servers which in turn provide the requested files. The entire vDisk is not streamed across the network. Only the files requested by the operating system are streamed across the network. This means that a 30 GB Windows Server 2008 R2 workload that boots off a streamed vDisk may only see 200 MB of files transfer across the network.

When a vDisk is in private mode, the vDisk can be edited and all reads and writes to the vDisk and only one target device may be accessing the vDisk. When a vDisk is in standard mode, it is read-only and no changes can be made to it. Instead all disk write operations are redirected to what is referred to as a write-cache file. The intelligent device drivers are smart enough to redirect writes to the write-cache file and read newly written files from the write-cache file instead of the server when necessary. Also, whenever a target device is rebooted, the write-cache is deleted and recreated and the device boots in a pristine state.
What factors are important in determining the write-cache file size?
When using Citrix Provisioning Services with the vDisk in standard mode you have a write-cache drive location that holds all the writes for the operating system. If the write-cache file fills up unexpectedly, the operating system will behave the same as if the drive ran out of space without any warning, in other words it will blue screen.

The optimum size of write-cache drive does depend on several factors:

Frequency of server reboots. The write-cache file is reset upon each server boot so the size only needs to be large enough to handle the volume between reboots.

Amount of free space available on the c: drive. The space that will be used for new files written to the c: drive is considered the free space available. This is a key value when determining the write-cache drive size.

Amount of data being saved to the c: drive. Data that is written to the c: drive during operation will get stored automatically in the write-cache drive. New files will be stored in the write-cache file and decrease the amount of available space. Replacements for existing files will also be written to the write-cache file but will not marginally affect the amount of free space. For instance, a service pack install on a standard-mode disk will result in the write-cache file holding all the updated files, with very little change in available space.

Size and location of the pagefile. When a local NTFS-formatted drive is found, Provisioning Services moves the Windows pagefile off of the c: drive to the first available NTFS drive, which is also the location of the write-cache file. Therefore, in the default configuration, the write-cache drive will end up holding both the write-cache file and the pagefile. To learn more about correctly sizing your pagefile, see Nick Rintalan’s blog, “The Pagefile Done Right!”.

Location of the write-cache file. The location of the write-cache file is also a factor in determining its size. The write-cache file can be held on the target device’s local disk, the target device’s RAM, or on the streaming server.

  • Target device disk: If the write-cache file is held on the target device’s disk, it could be a local disk to client, local disk to the hypervisor, network storage to the hypervisor, or SAN storage to the hypervisor.
  • Target device RAM: If the write-cache file is held in the target device’s RAM the response time will be faster and in some cases the additional RAM is less expensive than SAN disk.
  • Streaming Server: If the write-cache file is on the server, no preset size is necessary. When using server-side write-cache file, the Provisioning Services streaming server must have enough disk space to hold the write-cache files for all target devices managed.

Determining the correct write-cache drive size is mostly a logical exercise once you understand the relationship of the write-cache file and the pagefile with the write-cache drive.

Guidelines for determining write-cache size
In the old days we would recommend running with server-side write cache for the duration of the pilot project and then find the largest write-cache file on the server before the target devices were rebooted. From there we would just double or triple the size and make that the default size for a write-cache file. That approach works most of the time, but the approach is not so efficient with disk space.

Below are the few guidelines I use when recommending a size for the client-side write-cache drive.

  1. Write-cache drive = write-cache file + pagefile (if pagefile is stored on the write-cache drive)
  2. Write-cache file size should be equal to the amount of free space left on the vDisk image. This will work in most situations, except those where servers receive large file updates immediately after booting. As a rule, your vDisk should not be getting updated while running in standard-mode.
  3. Always account for the pagefile location and size. If it is configured to reside on the c: or d: drive, include it in all size calculations.
  4. Set the pagefile to a predetermined size to make it easier to account for it. Letting Windows manage the pagefile size starts with 1x RAM but it could vary. Manually setting it to a known value will provide a static number to use for calculations.
  5. During the pilot, use server-side write caching to get an idea of the maximum size you might see a file reach between server reboots. Obviously, the server should have a full load and should be subject to the normal production reboot cycle for this to be of value.
  6.  If people die when servers blue screen, set the write-cache drive to the size of the vDisk plus the pagefile size.

In most situations, the recommended write-cache drive size will be free space available on vDisk image plus the pagefile size. For instance, if you have a 30GB Windows Server 2008 R2 vDisk with 16GB used (14GB free) and are running with an 8GB pagefile, I would recommend using a write-cache drive of 22GB calculated as 14GB free space + 8GB for the pagefile. If space doesn’t permit, you have a few options, not all of which may be available to you.

  1. If storage location for the write-cache drive supports thin-provisioning, configure thin-provisioned drives for the write-cache drive to save space.
  2. Use dynamic VHDs (instead of fixed VHDs) though this approach is generally only recommended for XenDesktop workloads. If you choose this approach, you will probably need to periodically reset the size of the dynamic VHD, which can be done with a PowerShell script.
  3. Reboot the servers more frequently which in turn will reduce the maximum size of the write-cache file.
  4. Move the pagefile to a different drive or run without a pagefile.
  5. Use the old school method mentioned earlier to select a write-cache file size that is equal to or larger than the largest write-cache file recorded during the pilot stage. Using this option though may still result in blue screen events.

Of course, if you require 100% uptime and you have the disk space available, the sure-fire write-cache drive size is to set it to the size of the vDisk plus the pagefile size when the pagefile will get placed on the write-cache drive. In other words, if the Windows Server 2008 R2 vDisk image is 30GB and you have an 8GB pagefile configured, setting the write-cache drive size to 38GB will protect against any unforeseen blue screens. However, not everyone has that kind of space available, especially when using the expensive SAN storage for the write-cache drives.

Scalability implications
Just a quick note that large-scale environments, the best practices recommendation is to place the write-cache drive on the client hard disk rather than on the server. Generally speaking, you get about 40-60% more target devices on a single Provisioning Server with client-side write-cache than you do with server-side write-cache drives.  In addition, failover works better as the client target device has its write-cache available no matter which server is streaming the vDisk.

The use of client-side write-cache provides the maximum scalability of the Provisioning Services streaming server because the server does not need to perform both reads and writes for all target devices; rather the server is only required to read the vDisk once, cache the contents, and then stream it out over the network. This saves both CPU and network bandwidth on the streaming server allowing it to manage more target devices.

Follow

Get every new post delivered to your Inbox.

Join 52 other followers