Best Practices Guide for Provisioning Services and XenApp

Transcription

1 White Paper Citrix Cnsulting Best Practices Guide fr Prvisining Services and XenApp Designing an enterprise slutin fr the fast prvisining f XenApp servers

2 Table f cntents Best Practices Guide fr Prvisining Services and XenApp... 1 Overview... 1 vdisk Optins... 1 vdisk Types... 1 vdisk Cache... 2 Target Device RAM... 3 Target Device Lcal Strage... 3 Target Device Shared Strage... 4 Prvisining Services Lcal Strage... 4 Prvisining Services Shared Strage... 5 Netwrk Optins... 5 Bt Device Manager... 5 Operating System Tuning... 6 Event Lgs... 6 Aut Update... 6 Grup Plicies... 7 Organizatinal Units... 7 XenApp Tuning... 8 Applicatin Delivery... 8 Applicatin Cache... 9 Autmate Applicatin Pre-Cache Pagefile Multiple Partitins Drive Remapping Web Interface Data Cllectrs Applicatin Tuning Machine Specific Registry Keys Maintenance Autmatic Updating f vdisks Revisin Histry... 19

3 Overview Being able t add new XenApp servers t a farm in a matter f minutes, guaranteeing server cnsistency acrss similar XenApp wrklads and being able t quickly rllut changes t an entire farm are sme f the significant benefits fr dynamically delivering XenApp by using Prvisining Services. Althugh the slutin is fairly simple t setup and implement, a few areas must be cnsidered if the envirnment is t wrk mst effectively. These areas cver the fllwing tpics: vdisk Optins Netwrk Optins Operating System Tuning XenApp Tuning Applicatin Tuning Maintenance vdisk Optins XenApp servers require a slutin that delivers speed, cnsistency and availability while simplifying the envirnment. These cre criteria will help determine the best apprach fr designing a slutin that integrates Prvisining Services with XenApp. The first decisin area fcuses n the apprpriate vdisk ptins fr a XenApp wrklad: vdisk Types vdisk Cache vdisk Types The first vdisk type is Private Image mde, where each target device will have its wn vdisk. The vdisk is cnfigured in a read/write fashin, where all changes are stred within the vdisk fr future use. T imprve cnsistency and manageability, Prvisining Services can stream images t multiple devices frm a single vdisk. The vdisk is cnfigured as read-nly t allw fr the sharing between the multiple target devices. Prir t Prvisining Services 5 SP1, any write that the target device tried t perfrm n the vdisk was stred in a write cache, a temprary strage lcatin destryed each time the target device was restarted. With Prvisining Services 5 SP1, there is nw the ptin fr the re-use f the write cache after a rebt ccurs, using a slutin called Differential Disks. With the additin f differential disks, in what circumstances shuld changes be saved between rebts and when shuld the changes be destryed? The best decisin is based n the scenari and the benefits f each disk type. Descriptin Standard Image Private Image Differential Image Each target devices stres vdisk writes in a unique change file that is destryed upn each target device rebt. Benefits Servers revert back t a cnsistent, ptimized and apprved state after each rebt Strage requirements are reduced as the Each target device has a dedicate vdisk image cnfigured in a read/write fashin. All changes are part f the vdisk. Cmplete persnalizatin f the envirnment because all changes are stred, but at a cst f strage and supprt. Each target device stres vdisk writes in a unique file that is kept upn subsequent rebts, allwing the server t keep cnfiguratin changes, until the base vdisk is mdified. Allws fr greater levels f system persnalizatin by nt discarding system-level changes upn subsequent rebts. 1

4 Recmmendatins write cache is reset after each rebt Standard images are a recmmended best practice fr XenApp servers. XenApp servers delivering the same applicatins shuld be: Cnsistent s users d nt experience differences between servers Optimized t allw fr the best applicatin respnse times and prcessing speed There is little need fr Private Images in a XenApp envirnment because f the differences each image will take. This will g against the cre best practice f cnsistency. Differential images are apprpriate fr a small subset f use cases where users have the need t install their wn applicatins. In a XenApp envirnment, this is nt recmmended. Once the base vdisk is mdified, the differential image is destryed and the user must rebuild their persnality int the target device. In an apprved cnfiguratin, especially fr industries requiring strict enfrcement f standards fr certificatin r cmpliance. vdisk Cache One f the majr decisins when designing a Prvisining Services slutin fr XenApp wrklads is fcused n where t stre the write cache. Because a grup f servers utilize the same vdisk image, the vdisk is cnfigured as read-nly. Hwever, this brings abut challenges because simply turning n a streamed server results in the server trying t write infrmatin int the base vdisk. Instead f writing the changes int the base vdisk, the changes are placed int a write cache. Unless differential disks are used, which are nt recmmended fr XenApp, the write cache is destryed each time a server is rebted, thus restring the server t the base image. The write cache cntains anything that is changed during the time between server rebts. Each server has its wn write cache. Depending n what the server is ding and hw the envirnment is cnfigured, the write cache culd grw quite large. Fr instance, starting the server adds t the write cache fr server persnalizatin, XenApp lcal hst cache, pagefile, etc. If an applicatin is streamed nt the XenApp server, the entire applicatin prfile will als increase the size f the write cache. The mre things that change n the server, the larger the write cache will becme. Prvisining Services allws the write cache t be stred in many different areas, each prviding their wn benefits. The ptins are: Target Device RAM Target Device Lcal Strage Target Device Shared Strage Prvisining Services Lcal Strage Prvisining Services Shared Strage Each write cache strage ptin has many different benefits and cncerns, especially fr the XenApp wrklad. Fr mst XenApp envirnments, the best slutin will be the ne that takes n the fllwing characteristics: Fast: XenApp requires a slutin that respnds quickly as XenApp is maintaining live, interactive user sessins. Any delays in the write cache might be nticeable t the users. Dynamic: XenApp servers are delivering many different applicatins and supprting many different users. Each user and applicatin will have an impact n the write cache. The amunt 2

5 cnsumed will change day-t-day. The risks f exhausting write cache space wuld be detrimental t the success f a XenApp envirnment. Available: XenApp servers must be prtected frm envirnment failures, because each server is supprting many users simultaneusly. The write cache slutin selected shuld be ne that des nt impact high-availability ptins frm functining. Based n the afrementined criteria and the explanatin f the different ptins fr write cache, XenApp servers prvisined with Prvisining Services are best suited fr 1. Virtual XenApp Server: Target Device Shared Strage 2. Physical XenApp Servers: Target Device Lcal Strage Target Device RAM Definitin: The first ptin fr write cache strage lcatin is the target device s RAM. A prtin f the target device s RAM is set aside and used fr the write cache. Benefits: Cncerns: Target Device Lcal Strage The main benefit fr using the target device s RAM is it prvides the fastest type f write cache. A prtin f the RAM cannt be used fr the server wrklad. RAM is ften better used fr XenApp applicatins r user sessins than fr write cache. Plus, using RAM t supprt the write cache is mre expensive than using strage. Part f the challenge with using RAM as the write cache strage is determining the amunt f RAM required. Prvisining Services can set aside a certain prtin f RAM fr the write cache, but what happens when the RAM runs ut? The write cache is critical t the stable functining f a prvisined server. When available write cache is exhausted, the server can n lnger make changes, which results in a server failure. If the write cache size is nt estimated crrectly, using a Target Device s RAM might pse detrimental t the stability f the envirnment. Definitin: The secnd ptin fr write cache strage lcatin is the target device s lcal strage. This strage culd be the physical disk drives n the physical server, r it culd be the virtual disk n a virtual server Benefits: Cncerns: This slutin des nt require additinal resurces, in that mst physical servers being prvisined already have lcal disks installed and unused. Althugh target device lcal strage is nt as fast as RAM, it still prvides fast respnse times because the read/write t/frm the write cache is lcal, meaning that the requests d nt have t crss the netwrk. Trying t estimate the size f the write cache is difficult and if dne incrrectly, can result in server failure. Hwever, lcal strage typically prvides mre than enugh space fr the write cache, withut requiring the administratr t estimate space requirements. If the target device is virtualized, using lcal strage will prevent live migratin prcesses frm succeeding because the strage is nt shared acrss virtual infrastructure servers, like XenServer. 3

6 Target Device Shared Strage Definitin: The third ptin fr write cache strage lcatin is n a shared strage device attached t the target device. This slutin is usually nly valid fr envirnments virtualizing the target device with a slutin like Citrix XenServer. This strage is assigned t each virtual machine frm a shared strage repsitry. Benefits: Cncerns: Althugh target device shared strage is nt as fast as RAM r target device lcal strage, it still prvides fast respnse times. If the shared strage infrastructure is a SAN r NAS, the reads/writes will still perfrm adequately because the ptimized shared strage infrastructure will help vercme the time added fr traversing the netwrk. Althugh the cnfiguratin f this slutin requires the identificatin f the shared strage size, the csts assciated with ver-estimating are nt nearly as detrimental as verestimating with RAM. Strage csts are significantly cheaper than RAM s a sizeable buffer ver the space estimates is f little cncern. Because the target device s strage is accessible frm multiple virtual machines, virtual server live migratin, like XenServer XenMtin, is viable. This slutin requires the setup and cnfiguratin f a shared strage slutin. Althugh if XenServer is already being utilized, the same shared strage slutin can be used fr the write cache strage. Prvisining Services Lcal Strage Definitin: The furth ptin fr write cache strage lcatin is n the Prvisining Services lcal strage. This strage uses the physical disks installed within the Prvisining Services. Benefits: Cncerns: This slutin is extremely easy t setup and requires n additinal resurces r cnfiguratin within the envirnment. Requests t/frm the write cache must crss the netwrk and be serviced by the Prvisining Services streaming service. Because the write cache is acrss the netwrk, servicing write cache requests will be slwer than the previusly mentined ptins. The streaming service is respnsible fr sending the apprpriate parts f the vdisk t all target devices. Having the write cache n the Prvisining Services server will negatively impact the server s scalability because the streaming service must als service the write cache requests. Prvisining Services includes a high-availability ptin, but in rder fr this slutin t functin, all Prvisining Services servers must have access t the vdisk and the target device s write cache. When the write cache is stred n ne Prvisining Services server s lcal strage, this makes it impssible fr ther Prvisining Services servers t gain access, thus denying the ability t enable Prvisining Services high-availability. Althugh disk space is fairly inexpensive, chances are the Prvisining Services des nt have an extensive supply f strage space. With each Prvisining Services server supprting a few hundred target devices, it is quite pssible the ttal write cache culd exceed hundreds f gigabytes f strage space. This culd result in 4

7 exhausting all lcal strage n the Prvisining Services server causing a server failure. Prvisining Services Shared Strage Definitin: The fifth ptin fr write cache strage lcatin is n the Prvisining Services server s shared strage. This ptin utilizes a share strage slutin that is cnnected t the Prvisining Services server. Benefits: Cncerns: The shared strage slutin allws fr Prvisining Services high-availability as each server can access the vdisks and the write cache. Size cncerns are mitigated because shared strage devices typically cntain significant amunts f strage and can be expanded easily. This is ne f the slwest slutins because requests t/frm the write cache must crss the netwrk and be serviced by the Prvisining Services streaming service. The Prvisining Services server must then frward the write cache requests nt the shared strage, thus resulting in tw netwrk hps fr the write cache. Prvisining Services scalability is impacted as the streaming service is respnsible fr handling Prvisining Services write cache requests and frwarding them nt the shared strage. The slutin requires the installatin and cnfiguratin f a shared strage slutin int the envirnment. If ne is already present, then this cncern is mitigated. Netwrk Optins In the mst basic cnfiguratin, Prvisining Services utilizes DHCP t assign each target device with an IP address and the lcatin f the bt server and bt image (ptins 66 and 67 if using PXE). Hwever, in certain envirnments using DHCP r mdifying the DHCP scpe ptins t include PXE is nt pssible. In situatins like this, yu may wish t cnsider using the Bt Device Manager ptin. Bt Device Manager Bt device manager (bdm.exe) is a utility included with Prvisining Services that allws target devices t bt frm a vdisk image withut the need f PXE. The bt device manager allws the btstrap image, which is used t cnnect the target device t Prvisining Services servers t receive the apprpriate vdisk image, t be stred n a USB, CD-ROM, ISO image r a hard disk partitin. Simply cnfiguring the target device t use ne f these alternative methds will allw the target device t bt using Prvisining Services withut the need fr PXE. Fr XenApp envirnments, bting frm the bt device manager s image is dne by the fllwing: Virtual XenApp server n XenServer: Stre the bt image in an ISO and mve the ISO file t the ISO Image strage repsitry n XenServer Assign the bt image t the DVD drive fr each virtual machine Cnfigure the virtual machine t bt frm the DVD Physical XenApp Server: Burn the ISO image t a DVD r CD Keep the CD/DVD in the drive, as it is needed fr each start up 5

8 Cnfigure the server, in the BIOS, t bt frm the DVD drive Operating System Tuning The base part f any vdisk image is the perating system. Having an envirnment that is ptimized will help meet the gals f a well-tuned XenApp envirnment. This sectin fcuses n the best practices fr the fllwing: Event Lgs Aut Update Event Lgs Grup Plicies Organizatinal Units Event lgs are helpful t identify and trublesht issues within the envirnment, and they als act as a security audit lg, which is extremely critical in high-security envirnments. Because the best vdisk type fr XenApp wrklads is a standard image, any changes made t the system are lst upn rebt, which includes the event lg. This eliminates the pssibility f tracking security audit lgs, applicatin issues r perating system issues. Thrugh registry keys, r a plicy setting in Windws 2008, the lcatin f the event lg files can be mdified t a different lcatin, but that lcatin must be a lcal drive. The event lg service starts adding items befre the netwrk services start. If the event lgs are stred n a netwrk share, the event lg will fail t save messages because the netwrk is nt yet available. Hwever, events can still be cnslidated by the fllwing methds: Lcal Strage: If the vdisk cache best practice is being fllwed, each target device is cnfigured with lcal strage: physical servers use lcal disk while virtual servers use a defined virtual disk. Either way the lcal strage appears as a lcally attached disk t the prvisined XenApp server. Redirecting the event lg t the defined lcal disk allws event lg infrmatin t persist between server rebts. Citrix EdgeSight: EdgeSight fr XenApp is included in XenApp Platinum. EdgeSight allws an administratr t cllect, in real-time, any defined errr messages frm any XenApp hst. This allws fr the tracking f nly the mst imprtant and critical alerts. The alerts that are tracked are cmpletely cnfigurable. The slutin can wrk with XenApp servers running n Windws 2003 and Windws Micrsft Event Cllectin Services: In Windws Server 2008, Micrsft includes an Event Cllectin slutin that cllects all events fr a cnfigured alert level acrss any defined server. These events are stred within a single lg file fr future analysis. Aut Update Autmatic updates fr the perating system r installed applicatins are a great way t keep sftware current and prgrammatically address identified security hles. Even withut Prvisining Services, it is a recmmended best practice t disable the autmatic updates fr applicatins and the perating system because all changes t XenApp servers shuld be tested and validated befre rlling ut int prductin. The autmatic update feature circumvents this best practice. Fr systems delivered with Prvisining Services, autmatic updates can create anther ptential issue. In a XenApp envirnment, a grup f XenApp servers will be prvisined frm a standard image, where changes are kept in the write cache and lst during rebt. If this lgic is applied t the autmatic update features f the perating system and applicatins, ne can quickly realize that every time the server is rebted, the update services will identify new updates and make requests t update. This will happen fr every XenApp server after every rebt, until the base image is updated 6

9 t include the new patches. As a recmmended best practice, the perating system and applicatins shuld have the autmatic update features disabled. The XenApp administrative team shuld assess each update. Once the update is apprved, the base vdisk image fr the XenApp server shuld be updated. When the XenApp servers are rebted, they will be using a vdisk image cntaining the latest updates. Grup Plicies Active Directry grup plicies are a great way t enfrce system-level r user-level settings n a grup f servers. Using Prvisining Services brings abut a new set f recmmended plicies, as explained in the fllwing table: Plicy Path Value Justificatin Machine Passwrds Organizatinal Units Cmputer Cnfiguratin Windws Settings Security Settings Lcal Plicies Security Optins Dmain Member: Disable machine accunt passwrd changes Enabled Prvisining Services will manage and maintain each target device s machine passwrd within Active Directry. If the target device updates the passwrd n its wn, Prvisining Services will supply the wrng passwrd, thus causing issues fr dmain membership. As a lng-standing best practice, XenApp servers have warranted their wn rganizatinal unit within Active Directry fr rganizatinal and plicy enfrcement purpses. The recmmendatin has als included breaking ut specific XenApp rles int their wn OU, s each identical grup f servers wuld have the same plicies applied. Typically, this creates an Active Directry structure like the fllwing: Dmain XenApp Infrastructure Americas EMEA Pacific Data Cllectr Web Interface With the inclusin f Prvisining Services int the XenApp architecture, this recmmendatin des nt change. In fact, this best practice becmes even mre imprtant because there will be special plicy settings specifically fr prvisined servers, explained in the previus sectin. Depending n hw Prvisining Services is integrated with XenApp will help t determine if new OUs are required. If the OU cntains a set f XenApp servers all prvisined with the same vdisk, then any Prvisining Services related plicies can be applied t the entire OU. If the OU cntains prvisined and nn-prvisined XenApp servers, all hsting the same applicatins, then a new OU shuld be created that cntains nly the prvisined XenApp servers. If the OU cntains prvisined and nn-prvisined XenApp servers hsting different applicatins, then multiple OUs shuld be created cntaining nly identical servers. With Prvisining Services, the XenApp OU structure might resemble smething like the fllwing: 7

10 Dmain XenApp Infrastructure Americas EMEA Pacific Data Cllectr Web Interface Prvisined Static Prvisined Static Prvisined Static Each OU cntains: 1. Similar servers: Applicatins, infrastructure cmpnents, XenApp cmpnents 2. Similar delivery prcesses: Prvisined r nt prvisined XenApp Tuning Installed n tp f the perating system is XenApp. The XenApp Prep utility manages many f the technical prcesses that must be dne t a XenApp server s it can be prvisined successfully with Prvisining Services. Hwever, there are a few ther areas that must be cnsidered: Applicatin Delivery Applicatin Cache Autmate Applicatin Pre-Cache Pagefile Multiple Partitins Drive Remapping Web Interface Data Cllectrs Applicatin Delivery One f the majr challenges with creating a base XenApp image is determining what t include and what nt t include. Of curse, yu need the perating system and XenApp and Prvisining Services tls, but beynd that what is recmmended and why? Take the fllwing scenari: due t business reasns, an envirnment has three sets f XenApp servers hsting different line-f-business applicatins. All three line-f-business applicatins are dependent n Micrsft Excel fr viewing and editing integrated spreadsheets. Shuld Micrsft Excel be part f the base image r shuld it be a streamed applicatin? There answer is there is n right r wrng answer; it is all dependent n ther factrs within the envirnment. The decisin t include cre applicatins is ftentimes a result in the belief that the base image shuld cntain the greatest number f items that are cmmn between XenApp servers. If every server requires the same applicatin, mre netwrk bandwidth will be used when the applicatin is streamed t every server as part f the applicatin streaming prcess. Als, applicatin streaming, in the default cnfiguratin, des nt initially start as fast as a previusly installed applicatin because the applicatin must be sent acrss the wire. Thus, users will experience latency while the applicatin is streamed fr the first time (this latency can be vercme with applicatin pre-caching, as explained in the Applicatin Cache sectin). 8

11 There is als a business aspect t this decisin. In sme rganizatins, ne set f administratrs is respnsible fr applicatins and anther set is respnsible fr the XenApp cnfiguratin. By separating the applicatins frm the base image, the technical slutin can align mre clsely with the rganizatinal structure f the business. Base Image Applicatin Inclusin Benefits Base image and applicatins included in a single server rle, which will allw fr the fastest rebuild and delivery times. Less netwrk bandwidth is used because the applicatins are already present in the base image and n additinal installatins are required. The cmplete image can be deplyed during ff hurs s as t nt impact availability f the XenApp servers during the day. Applicatin startup time is shrter because the applicatin is already part f the image and des nt need t be streamed. Cncerns Cre applicatin versining changes can impact the base image. Fr example, if all servers require the same versin f Micrsft Excel, n issues are raised. Hwever, when individual applicatin upgrades ccur, sme applicatins might require Excel 2007 while thers require an lder versin. This wuld have a prfund impact n the cntents f the base image. Mdifying an applicatin within an image will impact all servers that rely n the image. This might require different levels f change cntrl fr applicatins that are integrated with the base image and applicatins that are nt integrated. Mre images t maintain, which can make supprt mre difficult, althugh the number f Prvisining Services images is still far fewer than the number f images required fr ther server build slutins. Base Image Applicatin Exclusin With fewer items included in the base image, maintaining the image is easier as nly the cre perating system and XenApp are prvisined initially. XenApp base images are managed with ne set f tls, and applicatins and crrespnding updates are managed with a different set f tls. This makes it easier t have multiple administratrs respnsible fr different areas f expertise. XenApp sils becme a thing f the past. A single XenApp server image can be used t deliver any applicatin at anytime. A single image t maintain fr the entire XenApp farm greatly simplifies supprt. Streaming applicatins will increase netwrk utilizatin during startup, althugh this can be mitigated with applicatin precaching. In the default cnfiguratin, the first user starting an applicatin will ntice a pause befre applicatin startup as the applicatin is streamed t the server. This can be vercme with applicatin precaching. Nt every applicatin can be streamed. Althugh XenApp streaming has imprved t include mre applicatins, there are sme that cannt be streamed because they require special functinality Regardless f the decisin n which applicatins t include and exclude in the base image, the fllwing are general best practices fr the base image: All relevant perating system and XenApp htfixes and service packs shuld be included in the base image. The mst cmmn perating system and XenApp cnfiguratin shuld be used fr the base image. If 80% f the servers require a specific setting while anther 20% d nt, the base image shuld include the special setting. The base image shuld include all apprpriate XenApp plugins. If applicatin streaming will be used, the streaming plugin shuld be installed as part f the base image. Depending n the usage f server certificates, the apprpriate rt certificate shuld be part f the base image. Applicatin Cache Sme envirnments have chsen t simplify their XenApp envirnment with the use f XenApp applicatin streaming. This slutin utilizes a XenApp server (prvisined r static) withut any applicatins. Once the XenApp administratr publishes a streamed applicatin t a XenApp server, 9

12 the applicatin prfile is streamed t the XenApp server as needed. The act f applicatin streaming has a direct impact n the prvisined server. The streamed applicatin is a change t the base vdisk image. These changes are stred within the write cache fr each prvisined XenApp server. Depending n the size f the applicatin, the simple prcess f delivering an applicatin n tp f a Prvisining services streamed XenApp server can make the write cache grw by many gigabytes as shwn in the fllwing diagram: Write Cache Swap & Temp File Prvisining Server vdisk Strage Prvisined XenApp Server Decmpressed App Streaming Cache App CAB files XenApp Hsts Applicatin Hub Using a prvisined XenApp server generates the typical swap and temp files, which is added int the write cache. When a streamed applicatin is requested fr the first time, prtins f the applicatin prfile are delivered t the XenApp server frm the Applicatin Hub. This prcess immediately increases the in use size f the write cache, in additin t delaying applicatin startup times as the prfile is delivered.. Depending n the write cache ptin selected, this culd have a significant impact n the usability and speed f the XenApp server. If the write cache size is a cncern, then a pre-cache ptin exists that speeds up applicatin launches as well as reduce the size f the write cache. This prcess is shwn in the fllwing figure. Write Cache Swap & Temp File Prvisining Server vdisk Strage Prvisined XenApp Server Decmpressed App Streaming Cache XenApp Hsts Applicatin Hub 10

13 In this example, the vdisk image includes a pre-cache f the streamed applicatins. Users still have t access the applicatins as befre, but the applicatins are already present n the vdisk s the applicatin stream prcess is cmplete, eliminating the need t stream prtins f the prfile and impacting the write cache. The challenge with ding the pre-cache f the streamed applicatin is that each time a streamed applicatin is updated, the applicatin cache within vdisk image must als be updated. This adds mre steps int the applicatin update prcess. Hwever, nt every applicatin update requires an update t the applicatin cache n the vdisk, nly majr updates are a cncern. Fr example, if an applicatin has a new patch r a new file update, simply updating the applicatin prfile is adequate. When a user tries t start the applicatin n a prvisined XenApp server, mst f the applicatin cache is crrect except fr ne r tw files. Thse tw items are updated frm the applicatin hub, and nly slightly increase the size f the write cache. Hwever, if a large update t an applicatin is perfrmed, like adding a service pack t Micrsft Office, then it wuld be advantageus t refresh the applicatin cache n the vdisk because these updates impact a large percentage f the files in the cache. When the applicatin is executed, all f the updated files are streamed dwn and placed in the write cache. A third ptin exists that is able t vercme the challenges with pre-caching and n-the-fly streaming, and that is Cache Redirectin. The verall gal is t keep the maintenance f the envirnment simple while prviding an ptimized envirnment fr the user s they experience a high-definitin experience. If the physical and virtual XenApp servers are designed in such a way that they are allcated strage t hld the Prvisining Services write cache, the same defined strage can als cntain the applicatin streaming cache, as shwn in the fllwing figure: This type f architecture prvides the fllwing benefits ver the ther t previusly mentined ptins: Faster applicatin launch after server rebts because the applicatin cache persists Easier applicatin maintenance because the applicatin cache is decupled frm the vdisk Autmate Applicatin Pre-Cache A cmmn cncern with streamed applicatins is the initial startup time. When a user tries t start a new applicatin, the applicatin is nt yet n the server. The applicatin request will start the streaming prcess where parts f the applicatin are sent ver the netwrk t the XenApp server. Depending n the applicatin and envirnment, applicatin startup time can vary greatly. XenApp 11

14 allws streamed applicatins t be pre-delivered allwing fr faster startup time. T accmplish this when using prvisined servers, d the fllwing items: Nte: This prcess will increase the size f the write cache because the applicatin stream happens t the vdisk in standard image mde (read-nly). Fr a greater understanding int the write cache and applicatin streaming, see the previus sectin n Applicatin Cache. 12

15 Pre-Cache Streamed Applicatins Screensht Descriptin 1 On the Prvisining Server, launch the Prvisining Server Cnsle. Select a Target Device -> File -> Prperties Select the Persnality tab and select Add Enter in the fllwing: Select OK Select OK Name: RADE String: Path t all applicatin prfiles t be delivered t the target device separate by cmmas. 2 Within Active Directry Users and Cmputers n the Dmain Cntrller Select the Organizatinal Unit cntaining the servers requiring pre-applicatin delivery With the OU highlighted, select Actin -> Prperties Select the Grup Plicy tab and select New entering in a name fr the plicy Select Edit The Grup Plicy Object Editr appears. Select Cmputer Cnfiguratin -> Windws Settings -> Scripts (Startup/Shutdwn) Highlight the Startup name Select Actin -> Prperties 13

16 Pre-Cache Streamed Applicatins Screensht Descriptin 3 The Startup Prperties screen appears Select Add Select Brwse Within the Brwse windw, right-click and select New -> Text Dcument Rename the dcument t PreCache.vbs Right-click the PreCache.vbs file and select Edit Paste the script, cntained in the fllwing rw, within the file. Save and exit ntepad Highlight PreCache.vbs and select Open On the Add a script windw, select OK On the Startup Prperties windw, select OK Clse the remaining windws and screens 4 set wshshell = CreateObject("Wscript.shell") intlp = 0 intstart= 1 intend = 0 ' Ppulate registry with Streaming Applicatin paths based n persnality settings wshshell.run chr(34) & "c:\prgram Files\Citrix\Prvisining Server\getclientinf" & chr(34) & " rade /r=hkey_local_machine\software\build\rade", 1, true ' Read unique applicatin names strradeapps = wshshell.regread("hklm\sftware\build\rade") Set bjregex = CreateObject("VBScript.RegExp") bjregex.ignrecase = True bjregex.glbal = True bjregex.pattern = "," set clmatches = bjregex.execute(strradeapps) ' Fr each pathname, pre-deply the applicatin D until (clmatches.cunt < intlp) intend = Instr(intStart +1, strradeapps, ",") if intend <> 0 then else end if strapp = Mid(strRadeApps, intstart, intend -intstart) strapp = Mid(strRadeApps, intstart) intlp = intlp + 1 intstart = intend + 1 wshshell.run chr(34) & "C:\Prgram Files\Citrix\Streaming Client\radedeply" & chr(34) & " /deply:" & chr(34) & strapp & chr(34) Lp 14

17 When the XenApp servers cntained within the rganizatinal unit starts, the script will execute reading in the persnalizatin settings. The persnalizatin string fr RADE will pre-deply the streamed applicatins t the server. Pagefile Many XenApp cnfiguratins have included a cnfiguratin change t mve the pagefile t a partitin that is different frm the system partitin (C: drive). In sme situatins, if the pagefile partitin was n a cmpletely different physical disk, perfrmance imprvements might be gained. If XenApp is delivered with Prvisining Services, this cnfiguratin shuld be reexamined. The pagefile is underging cnstant mdificatin by the perating system. As physical memry is paged, it is stred in the pagefile. Upn rebt, the cntents f the pagefile are nt imprtant, and it is verwritten n subsequent startups. In a Prvisining Services envirnment, the pagefile will be lcated n the vdisk, but any change made t the file will be recrded in the write cache, because the vdisk image is read-nly. Assigning the pagefile t a different partitin within the vdisk is nt recmmended, because there is n benefit t the functining f the XenApp server. Multiple Partitins Each XenApp envirnment is cnfigured with many different partitin cnfiguratins. Typical cnfiguratins are: One Partitin Server: Partitin 1: Operating System, Pagefile, Applicatins Tw Partitin Server: Partitin 1: Operating System, Pagefile Partitin 2: Applicatins Three Partitin Server Partitin 1: Operating System Partitin 2: Applicatins Partitin 3: Pagefile Prvisining Services can deliver an image with ne r tw partitins, but nt three. Plus, based n the Pagefile sectin abve, there is n gain frm having a separate pagefile partitin n a prvisined XenApp server as the pagefile changes will be stred in the write cache. Althugh tw partitins are supprted, it des increase the cmplexity f the envirnment and des nt ffer any perfrmance benefit t the envirnment. As a general best practice, XenApp servers shuld be cnfigured with a single partitin. Drive Remapping In a few XenApp installatins, the XenApp server drives are remapped t an alternative drive letter (C = M, D = N). The mst cmmn justificatin fr this design cnsideratin was fr users t have their client drives mapped within their XenApp sessins as C and D. Hwever, this apprach shuld be reexamined. Remapping server drives is nt cnsidered a best practice fr XenApp envirnments because: Web Interface Drive remapping is n lnger an ptin in XenApp 5 running n Windws 2008 Server. Giving users access t their lcal C and D drives within a XenApp sessin is cnsidered a security risk. If the applicatins are hsted n the XenApp servers, the data shuld be in the data center fr best applicatin perfrmance. 15

18 In many scenaris, a site s Web Interface servers are identical except fr system-level settings like server name and IP address, which makes the Web Interface server a candidate t prvisin with Prvisining Services. Because Web Interface is the users main pint f presence int a XenApp envirnment, it is critical--regardless f server--that Web Interface prvides the same respnses t users. T prperly prvisin Web Interface, a cmmn base Web Interface rle shuld be created with all pertinent cnsistent cnfiguratins. This will help keep all Web Interface servers synchrnized and help prtect the server as changes will nt be saved during rebts. Hwever, fr high-security envirnments, prvisining Web Interface des bring abut a best practices that shuld be taken int accunt: Certificates: The cmmn image fr the Web Interface must cntain a server certificate if cmmunicatin between the end-pint -> Web Interface r Access Gateway -> Web Interface is t be encrypted. As multiple servers can be delivered frm a single image, certificates pse a challenge that can be slved by: Data Cllectrs Installing multiple server certificates n the Web Interface vdisk. Each server certificate will crrespnd t a ptential server name defined within Prvisining Services. If there will be three Web Interface servers, then the vdisk shuld cntain all three server certificates. Using a wildcard certificate that can be used acrss all prvisined Web Interface servers. The wildcard will dictate the need fr a cmmn naming standard fr the Web Interface servers. The data cllectr is respnsible fr applicatin enumeratin and designating the apprpriate server t hst user cnnectins. Just like Web Interface, rganizatins ften dedicate a primary and ptentially a secndary data cllectr fr fault tlerance. Unless users are lgging n, lgging ff r discnnecting, the data cllectr remains fairly unused. Cnfiguratin differences between a primary and secndary data cllectr are very minr. By prvisining the data cllectr, a single rle culd be used fr all data cllectrs. Even thugh data cllectr prvisining is pssible and recmmended, the fllwing are areas that shuld be taken int accunt: Real Time Metrics: When servers are prvisined, the Resurce Manager (XenApp 4.5) real-time metric infrmatin is lst upn rebt because a cmmn image is used. Resurce Manager summarizes this infrmatin n the lcal server daily. STA: The integratin utility autmatically makes the STA unique because MAC addresses are unique. Hwever, if the MAC address changes because the vdisk is streamed t a new physical/virtual server, the STA n the prvisined server will als change. T avid disruptin, the STA settings within Access Gateway must be updated t cntain the latest STA ID value. Electin Preferences: One imprtant difference between multiple data cllectrs is the electin preference levels. The primary data cllectr shuld be set t Mst Preferred and the backup data cllectr shuld be set t Preferred. Even thugh these tw servers will be delivered frm the same vdisk, these changes will be kept between rebts because this infrmatin is stred within the XenApp data stre. Applicatin Tuning Every XenApp server prvisined with Prvisining services has the exact same registry settings. This is ne f the cre benefits f Prvisining services fr XenApp server cnsistency. Hwever, certain applicatins experience issues with this type f a cnfiguratin, althugh the number f applicatins is minimal. The fllwing subsectins ffers ptins fr dealing with these types f applicatins s they functin apprpriately with Prvisining Services. Machine Specific Registry Keys 16

19 Machine Specific Registry Keys A few applicatins rely n machine specific identificatins in rder t functin prperly. Typically, these applicatins are, but it is nt limited t, systems management sftware. Incrprating the applicatin within a prvisined XenApp server, either incrprated int the vdisk r delivered via XenApp Applicatin streaming results in the applicatin failing because anther instance is running n the netwrk using the same ID. Hwever, these applicatins can still functin by using ne f the recmmended ptins: ID Reset: Third party tls are available that can reset the machine-based ID after the server has bted. A startup script can be executed during server startup, which will dynamically create a new ID fr the applicatin. Even thugh the ID des nt persist between server rebts, the script executes each time the server starts and cmpletes in an extremely shrt amunt f time. The script can either be incrprated int the vdisk image r applied t a set f servers by using an Active Directry Grup Plicy specifying a machine startup script. Persnality: Prvisining services includes a persnality feature allwing unique settings t be passed t the target device during startup. When applied t a target device within the Prvisining services cnsle, the persnality settings are delivered t the running server as a text file n the rt flder. A script, integrated int the vdisk, can read this infrmatin and ppulate the infrmatin int the registry, file system r anywhere else. This allws fr the creatin f unique but static infrmatin that persists between server rebts. Differential Disks: Prvisining services allws many XenApp servers t be based n the same vdisk image, but still retain settings upn server rebts. By using a differential disk, the unique machine ID can persist between server rebts, unless the base vdisk image is mdified. Althugh this is an ptin, the first tw are the preferred methds. Maintenance With a single image being used acrss numerus end pints, prcesses must be fllwed in rder t prperly integrate new updates withut impacting users r systems. The fllwing sectin fcus n simplifying maintenance f images. Autmatic Updating f vdisks Manually updating vdisks is nt a difficult task. Hwever, if dne n a regular basis (daily, weekly, mnthly) n ne r mre vdisks, the time required t maintain vdisks can quickly balln t prblematic levels. The Prvisining Server 5.0/5.1 admin guide (page 109) gives detailed instructins n hw t perfrm the prcess manually. On a high level, the prcess ges as fllws: Lad a machine with a cpy f the prductin vdisk in private mde Make updates Shut dwn and put the vdisk int standard mde Increment the versin number Hwever, with Wrkflw Studi, the prcess can be autmated t be entirely hands-free antivirus updates and perating system patches. Wrkflw Studi (WFS) is designed t reduce repetitive tasks int easy-t-manage wrkflws that can be run either n-demand r n a scheduled basis. Using Wrkflw Studi and Prvisining services built-in CLI, a script can be used t autmate the entire prcess f updating vdisks, allwing fr easy nightly r weekly scheduling with less chance fr human errr. An example script can be fund at the Citrix Develper Netwrk, which can be utilized as-is r mdified t meet the needs f mst deplyments. The script can als be used withut requiring WFS, but sme additinal functinality will need t be implemented in rder t replace WFS s capabilities. Please see the script fr additinal infrmatin. 17

20 18