Citrix

Configuring the vDisk access mode in PVS

vDiskAccessMode

 

  • Standard Image – Select this mode if a vDisk is shared by multiple target devices (write-cache options enabled).
  • Private Image – Select this mode if a vDisk is only used by a single target device (read/write access is enabled).

accessMode

Standard Image mode

Standard Image mode allows multiple target devices to stream from a single vDisk image at the same time. This reduces the amount of vDisk management and reduces storage requirements.

When a vDisk is configured to use Standard Image mode, it is set to read-only mode. Each target device then builds a write cache to store any writes the operating system needs to make. There are several write-cache options available. Because the vDisk is read-only, each time a target device boots, it always boots from a ‘clean’ vDisk. If a machine becomes infected with a virus or spyware, the target device only needs to reboot the image.

When updates are made to a vDisk in Standard Image mode, changes against the base vDisk image are captured in a differencing disk file (.avhdx), resulting in a new version of the base image. Each new version remains directly associated with the base image. Versioning allows for the updates captured in the differencing disk to be staged (Maintenance, Test, Production) before those changes become available to Production devices. If issues are encountered with a version, that version can simply be reverted.

Although each target device uses the same vDisk, Provisioning Services personalizes the streamed image for each target device, providing the information needed to ensure the device is uniquely identifiable on the network. You can also specify additional personality settings for each device: you can store application-specific values in the database and retrieve the target device’s unique value as the device loads.

Private Image mode

A vDisk that is in Private Image mode closely models how a computer uses a regular hard drive. That is, only one target device can use a Private Image vDisk at a time.

The following illustrates Private Image vDisks (read/write) that are each assigned to a single production device, and a Standard Image vDisk (read-only) that is assigned to and shared by a collection of production devices. For Standard Image vDisks, write cache options include cache on server disk, on a device’s hard disk drive, or in the device’s RAM.

 

To configure the vDisk mode and any applicable write cache destination

Note: Only write cache destinations that are supported for Standard access mode appear enabled.
  1. On the Console, right-click on the vDisk for which you want to configure the vDisk access mode, then select vDisk Properties. The vDisk Properties dialog appears.
  2. Click on the General tab, then select the image mode (Standard or Private) that applies to this vDisk from the Access Mode drop-down list.
  3. If Standard image was selected, from the cache destination drop-down list, select the appropriate write cache destination.
  4. Click OK to exit the vDisk Properties dialog.

 

Advertisements
Citrix

Provisioning Services or Machine Creation Services (2016 Edition)

When you want to migrate from Citrix 6.5 to Citrix 7.x, you need to make some decisions and one of the most important one is to choose whether to go for PVS or MCS. I have done some searches and found a lot of articles but some of them are really good and based on the real experiences. Have a look at this : (when you are making decisions)

PVSvMCS

And this;

compare

From Barry Schiffer web site, he explains and puts things in a different perspective for anyone making this decision;

Let’s start with the first decision in the tree in which we ask the question about using a XenDesktop only, XenApp only or mixed platform. The reason for this is that, before XenDesktop 7, it wasn’t possible to do MCS for XenApp load. Since XenDesktop 7 it’s actually possible to use Machine Creation Services for XenApp.

IOPS

In the old days we were worried about boot and logoff storms because of the amount of IOPS this generated on our expensive shared storage systems. If so we would advice to use Provisioning Services because of better IOPS caching possibilities.

Lots has changed in the past few years but the IOPS load is pretty much still the same, yet the decision making process changed. The reason for this change is that we now have more knowledge about the amount of IOPS and vendors jumped in and created new solutions offering huge amounts of IOPS on central or local storage.
On the hypervisor level we are now able to do live storage migrations. This helps us when we need to perform management tasks and don’t have the time to wait for all of the users to close their sessions.

Thin Provisioning

For Machine Creation Services it’s highly recommended to use a storage solution that offers the ability to utilize thin provisioning. This way we only use as much data as we need for write caching. If we don’t utilize thin provisioning each target will use as much disk space as the configured base image.

Persistency

Another decision is the need for dedicated aka persistent virtual desktops. If we need persistency you were forced to use Machine Creation Services. The reason for this decision was based on the fact that Provisioning Services falls back to Server Side caching when the cache had to be persistent. This method of caching results in a crappy desktop performance.
Since the introduction of Citrix Provisioning Services 6 we are able to offer persistent caching on the local target hard disk, which pretty much solves this issue. We therefore are now able to utilize Provisioning Services and Machine Creation Services for persistent desktops.

Physical vs Virtual

When we have a demand for physical virtual desktops we still need Provisioning Services. Machine Creation Services integrates on the hypervisor storage layer and therefore can’t be used on a physical target. This is the simplest decision of them all!

Advanced Image Management

As a reader of my blog you should already know that I like automation therefore I would never update images but instead rollout a new image. This way I can retest my image deployment every once in a while . Not of lesser importance I can always go back to my deployment run books to see how a certain component was installed for troubleshooting purposes.

If you care about image versioning and do a lot of image updates Provisioning Services is your way to go. Provisioning Services gives you greater flexibility to work with image versions and updates. Not everyone agrees with me on this one so I have decided to keep this out of the decision tree for now.

Multiple image locations or multiple images

This section has been added after publishing the article because the decisions attracts some attention, mostly by the guys from Atlantis Computing which must mean this market space has their full attention:). When we look at the Provisioning Services (PVS) architecture we have a central image store, the PVS server, for the sake of keeping things simple I’m not going into where PVS gets the image from local, filer, DFS et cetera. Machine Creation Services (MCS) works on the storage layer and places the image on each datastore which is used for targets.
When I create a new image or update an image with PVS I just change the pointer for each target and I’m done. With MCS that’s different, MCS first creates a single imagefile from a VM snapshot and when finished copies that image to each datastore. This process takes up CPU, IO and network resources and can take up to an hour in one of my production platforms (SSD 10Gbit et cetera).
So imagine a VDI cluster with 12 hosts with locally presented storage, this could be SSD, FusionIO or just as easily Atlantis ILIO. This would mean we have, at least, 12 storage datastores. With PVS this all stays simple, PVS is the central image location. With MCS this would mean we copy the base image to 12 different datastores.
Aside from the multiple image locations think about what happens if you have more then one image. This is not uncommon in enterprises, an example could be a VDI image, an RDS image with Internet Explorer 10 and one with Internet Explorer 11. This would mean that for MCS we copy not one image to 12 datastores but three images to 12 datastores. Think about the time and resources going into maintaining those images.
My decision would therefore be to stick with Provisioning Services when you have more then a couple of datastores or images. 

Thanks Barry Schiffer, this is an awesome article.

 

Citrix

Citrix Provisioning Services PVS

Citrix Provisioning Services (PVS) allows you to have a single instance image management of your XenApp and/or XenDesktop VMs. A single image means you only have to update a single image which is then streamed to hundreds of desktops.

In a production environment, PVS consists of at least two PVS servers for High Availability. A disk image is taken from a reference computer which has been built up with all patches, applications etc installed and configured, and the vDisk image is imported into PVS. The imported vDisk image usually sits on locally attached storage on each PVS server. ‘Target device’ VMs are created without a C: drive and set to boot from network. The MAC addresses of the VMs are added to the PVS database so that when the VMs PXE boot the PVS server knows which vDisk to provide. The first time a vDisk is streamed to a target device the vDisk is cached in memory on the PVS server.

Since we are streaming a single vDisk to multiple computers, the vDisk must be read-only to avoid corruption. But Windows can’t run off a read-only disk, so thanks to Citrix  PVS to have a ‘write cache’ . There is also default location for the write cache, however it is very slow and not ideal under high availability. Attaching a small (10GB) disk to each VM for the write cache is a good approach – this disk can reside on local host storage, the SAN. When the PVS target device reboots, the write cache is cleared so each boot is a ‘first boot’. To ensure there is no data loss, use redirected folders and a good profile management system. Since PVS 7.1, Citrix introduced a new write cache option called ‘Cache in device RAM with overflow on hard disk’. The option takes a chunk of VM memory and uses it as a disk cache which provides a massive performance boost over other write cache options.

Let me go through Write Cache options that Citrix PVS offers;

Write Cache in Provisioning Services Server

In PVS, the term “write cache” is used to describe all the cache modes. The write cache includes data written by the target device. If data is written to the PVS server vDisk in a caching mode, the data is not written back to the base vDisk. Instead, it is written to a write cache file in one of the following locations:

  • Cache on device hard disk
  • Cache in device RAM
  • Cache on device RAM with overflow on hard disk
  • Cache on server

When the target device is booted, write cache information is checked to determine the presence of the cache file. If the cache file is not present, the data is then read from the original vDisk file.
All current versions of PVS have the option for distributing write cache. It is called Multiple Write Cache Paths. The multiple write cache paths (for a store) option provides the capability of distributing the write cache files across multiple physical media. This feature helps to improve I/O throughput for heavily loaded servers.
When a target device starts the server chooses one of the write cache paths from the list based on the MAC address of the client. The goal of selecting a path based on the MAC address is to get an even distribution of the clients across the available paths. The algorithm selects the same path for a given client each time that client is booted.
This functionality is needed to ensure that during a High Availability (HA) failover the new server would choose the same write cache for the client (otherwise it would not be able to find the write cache file and the client would hang). If the defined write cache path is not available to a server, the server falls back to the standard vDisk path.
It is not recommended for the Cache on the server to be used in production environments.

Cache on device Hard Disk

Requirements

  • Local HD in every device using the vDisk.
  • The local HD must contain Basic Volume pre-formatted with a Windows NTFS file system with at list 512MB of free space.

The cache on local HD is stored in a file on a secondary local hard drive of the device. It gets created as an invisible file in the root folder of the secondary local HD. The cache file size grows, as needed, but never gets larger than the original vDisk, and frequently not larger than the free space on the original vDisk. It is slower than RAM cache, but faster than Server cache and works in a HA environment.

Cache in device RAM

Requirement

  • Appropriate amount of physical memory on the machine.

The cache is stored in client RAM (memory). The maximum size of the cache is fixed by a setting in vDisk properties. All written data can be read from local RAM instead of going back to the server. RAM cache is faster than cache on server and works in a HA environment.
Note: If more different sectors are written than the size of the cache, the device stops.

Cache on device RAM with overflow on Hard Disk

Requirement

  • Provisioning Service 7.1 or later.
  • Windows 7, Windows Server 2008 R2 or later.
  • Local HD in every device using the vDisk.

When RAM is zero, the target device write cache is only written to the local disk. When RAM is not zero, the target device write cache is written to RAM first. When RAM is full, the least recently used block of data is written to the local Write Cache disk to accommodate newer data on RAM. The amount of RAM specified is the non-paged kernel memory that the target device consumes.

Cache on Server

Requirements

  • Enough space allocated to where the server cache will be stored.
Server cache is stored in a file on the server, or on a share, SAN, or other location. The file size grows, as needed, but never gets larger than the original vDisk, and frequently not larger than the free space on the original vDisk. It is slower than RAM cache because all reads/writes have to go to the server and be read from a file. The cache gets deleted when the device reboots, that is, on every boot the device reverts to the base image. Changes remain only during a single boot session. Server cache works in a HA environment if all server cache locations to resolve to the same physical storage location. This case type is not recommended for a production environment.
Citrix

Adding Licensing on your Citrix Environment

We have got a Lab environment in here, by default you get 30-day trials which is really not enough to go through everything and practice what you need. So you need to login to mycitrix.com (you might need to register or you can use your company’s account). Under you details on the left hand side go to > Previews/Betas – License Retrieval

Capture((9

On the right you will see any available licenses, if not you can scroll right down to request more which will give you additional licenses.

Captureiutre

Click on the Serial Number and you will get  a warning about your license server name which is case sensitive. Yes you need to right exactly the same letters appear in the name.

Capturehdfgd

Click on Continue,

Capturhdhse

Under Host ID you need to write your License server name and then you will be able to download and save your .lic file.

On your Citrix Studio > click on Licensing on the left …

Capturejhshfs

and on the right Click on Add Licenses

Capturenjnj

Browse where you saved your license file. That should give you 90-day Evaluation or if you have got proper license you can use this as well.

Captursfgghe

One more thing to check is the “Production Edition”, make sure it is right version you want to use and you can do this by going in to “Edit Production Edition” under Actions on the right hand side.

 

 

Citrix

Citrix XenApp / Xendesktop 7.6 Technical overview -1

This is from Citrix website and I think it is awesome article which explains the new architecture with a plain English. Very easy to read and understand.

XenApp and XenDesktop are virtualization solutions that give IT control of virtual machines, applications, licensing, and security while providing anywhere access for any device.

XenApp and XenDesktop allow:

  • End users to run applications and desktops independently of the device’s operating system and interface.
  • Administrators to manage the network and provide or restrict access from selected devices or from all devices.
  • Administrators to manage an entire network from a single data center.

XenApp and XenDesktop share a unified architecture called FlexCast Management Architecture (FMA). FMA’s key features are the ability to run multiple versions of XenApp or XenDesktop from a single Site and integrated provisioning.

FMA key components

A typical XenApp or XenDesktop environment consists of a few key technology components, which interact when users connect to applications and desktops, and log data about Site activity.

Citrix Receiver
A software client that is installed on the user device, supplies the connection to the virtual machine via TCP port 80 or 443, and communicates with StoreFront using the StoreFront Service API.
StoreFront

The interface that authenticates users, manages applications and desktops, and hosts the application store. StoreFront communicates with the Delivery Controller using XML.

Delivery Controller
The central management component of a XenApp or XenDesktop Site that consists of services that manage resources, applications, and desktops; and optimize and balance the loads of user connections.
Virtual Delivery Agent (VDA)
An agent that is installed on machines running Windows Server or Windows desktop operating systems that allows these machines and the resources they host to be made available to users. The VDA-installed machines running Windows Server OS allow the machine to host multiple connections for multiple users and are connected to users on one of the following ports:

  • TCP port 80 or port 443 if SSL is enabled
  • TCP port 2598, if Citrix Gateway Protocol (CGP) is enabled, which enables session reliability
  • TCP port 1494 if CGP is disabled or if the user is connecting with a legacy client
Broker Service
A Delivery Controller service that tracks which users are logged in and where, what session resources the users have, and if users need to reconnect to existing applications. The Broker Service executes PowerShell and communicates with the Broker agent over TCP port 80. It does not have the option to use TCP port 443.
Broker agent
An agent that hosts multiple plugins and collects real-time data. The Broker agent is located on the VDA and is connected to the Controller by TCP port 80. It does not have the option to use TCP port 443.
Monitor Service
A Delivery Controller component that collects historical data and puts it in the Site database by default. The Monitor Service communicates on TCP port 80 or 443.
ICA File/Stack
Bundled user information that is required to connect to the VDA.
Site Database
A Microsoft SQL database that stores data for the Delivery Controller, such as site policies, machine catalogs, and delivery groups.
NetScaler Gateway
A data-access solution that provides secure access inside or outside the LAN’s firewall with additional credentials.
Director
A web-based tool that allows administers access to real-time data from the Broker agent, historical data from the Site database, and HDX data from NetScaler for troubleshooting and support. Director communicates with the Controller on TCP port 80 or 443.
Studio

A management console that allows administers to configure and manage Sites, and gives access to real-time data from the Broker agent. Studio communicates with the Controller on TCP port 80.

Citrix

XenApp and XenDesktop 7.13

The product release includes the following new and enhanced features.

Installation

New page in VDA installers:

The graphical wizards of the VDA installers (except VDAWorkstationCoreSetup.exe) have a new page named Additional Components. This page lists several components that can be installed.

App-V
User Profile Manager
User Profile Manager WMI Plugin
Machine Identity Service
AppDisk and Personal vDisk

By default, all of these additional components are selected if you select “Create a master image” on the Environment page of the VDA installation wizard. If you select “Enable Remote PC Access” on the Environment page, none of the additional components are selected by default.

This feature brings the graphical and command-line interfaces of the VDA installers into closer equivalency. Each of these components can be omitted from a command-line installation by using the /exclude option. (By design, the VDAWorkstationCoreSetup.exe VDA installer cannot install any of these components.)

If you upgrade a VDA that does not have those components already installed, default settings could result in those components being installed during the upgrade, unless you specifically exclude them or use the VDAWorkstationCoreServices.exe installer.

Installing Citrix App-V components when installing a VDA:

Previously, you enabled or disabled installation of the Citrix App-V software on the Features page of the VDA installer wizards (except VDAWorkstationCoreSetup.exe). To disable Citrix App-V software installation from the VDA command line, you used the /no_appv option.

Now, you enable or disable Citrix App-V software installation on the Additional Components page of the VDA installation wizards (except VDAWorkstationCoreSetup.exe). To disable Citrix App-V software installation from the command line, use the /exclude “Citrix Personalization for App-V – VDA” option. (The /no_appv command-line option is no longer valid.)

If you enable the Citrix Personalization for App-V – VDA check box, the “Citrix AppDisk / Personal vDisk” components are automatically selected. This is a known issue in this release. You can prevent this by installing the VDA from the command line containing the /exclude “Personal vDisk” option.

Additional UDP ports opened in firewall during VDA installation:

If you enable the new HDX adaptive transport policy setting, UDP ports 1494 and 2598 are automatically opened in the Windows firewall by default when you install or upgrade a VDA using the graphical interface. (These ports are listed on the Firewall page of the installation wizard). These ports are used for communication with the Delivery Controller.

When installing a VDA from the command line, specify the new /enable_hdx_udp_ports option when using the new adaptive transport policy setting.

Note: TCP ports 1494 and 2598 are opened automatically for use during fallback or when the adaptive transport feature is not used. Those TCP ports are already covered with the existing /enable_hdx_ports option.

Application Group session sharing

When applications in an Application Group are started, by default they reuse existing sessions to launch faster and use fewer resources. In previous releases, although you could prevent application session sharing between Application Groups, applications in the same Application Group would always session share.

You can now configure Application Groups so that application session sharing is disabled between applications in the same Application Group. In some circumstances this may be desirable: for example, you may want users to start non-seamless applications in full size application windows on separate monitors. In this mode applications in the Application Group always run in separate sessions which are indistinguishable from each other for subsequent brokering and reconnection purposes. If a disconnected session exists which is already running the requested application, it is reconnected. You can disable application session sharing using the PowerShell SDK only.

AppDisk

AppDisk includes the following new features and enhancements:

  • Updated logging mechanism. An enhancement to the AppDisk logging and support paradigm allows an administrator to obtain diagnostic information and optionally upload it to the Citrix Insight Services (CIS) website.

Session Recording

Session Recording includes the following new and enhanced features:

  • Database names are configurable. You can use a custom name or the default database name for the Session Recording Database and for the Administrator Logging Database.
  • Database high availability. Session Recording supports three solutions for database high availability based on Microsoft SQL Server.

Director

Director includes the following new and enhanced features:

  • Application-centric troubleshooting. This enhancement facilitates troubleshooting of active application instances in a XenApp and XenDesktop Site with the introduction of a new Application Instances slice-n-dice page in the Filters view. The page displays all active application instances on VDAs of Server OS, and their idle state information.
    Additionally, the Sessions slice-n-dice page is extended to include the session idle time metric enabling easy identification of idle sessions. You can sort and filter the session and application instances based on their idle time measurements and select instances to log off or disconnect.
    The Application Instances filter page and idle time measurements in the Sessions filter pages are available if Director, the Delivery Controller(s), and VDAs are version 7.13 or later.
  • Transport protocol on Session Details panel. The Director Session Details panel is enhanced to display the transport protocol in use for the session. The protocol is displayed as TCP or UDP for the HDX connection type based on the new HDX adaptive transport technology.

Virtual Delivery Agents (VDAs) 7.13

Version 7.13 of the VDA for Server OS and the VDA for Desktop OS include the following enhancements to HDX technologies:

  • Adaptive transport. Adaptive transport for XenApp and XenDesktop optimizes data transport by applying a new Citrix protocol called Enlightened Data Transport (EDT) in preference to TCP whenever possible. Compared to TCP and UDP, EDT delivers a superior user experience on long-haul WAN and internet connections. EDT dynamically responds to changing network conditions while maintaining high server scalability and efficient use of network capacity. EDT is built on UDP and improves data throughput for all ICA virtual channels, including Thinwire display remoting, file transfer (Client Drive Mapping), printing, multimedia redirection. If UDP is not available, adaptive transport automatically reverts to TCP.Enable it using the HDX Adaptive Transport policy setting. The same setting is applicable on both LAN and WAN conditions. This feature requires Citrix Receiver for Windows 4.7 or Citrix Receiver for Mac 12.5. For external secure access, it requires NetScaler Unified Gateway 11.1.51.

  • HDX 3D Pro support for AMD GPUs. Use HDX 3D Pro graphics acceleration technologies with AMD Multiuser GPU (MxGPU) on the AMD FirePro S-series server cards. This release includes support for multimonitors (up to a maximum of six), console blanking, custom resolution, and high frame rate.

  • Access to a high-performance video encoder for Intel Iris Pro graphics processors. The Use hardware encoding for video codec policy setting enables the use of hardware encoding for Intel Iris Pro graphics processors (new in 7.13) and for NVIDIA GRID GPUs (introduced in 7.11). For Intel Iris Pro graphics processors, hardware encoding is supported with VDAs for Desktop OS (in standard or HDX 3D Pro mode) and VDAs for Server OS. For NVIDIA GRID GPUs, hardware encoding is supported with VDAs for Desktop OS in HDX 3D Pro mode.

  • Enhanced drawing features on Wacom tablets. Wacom drawing tablets can connect to published desktops on a remote desktop service (RDS) VM when redirected with generic USB redirection. Though you can use the tablet’s pen device as a mouse device while it is redirected, we recommend that you also maintain a standard USB mouse, which is not redirected, to allow access to local client functions. The redirected device is active only inside the session and doesn’t have control over the local client. Install the driver for the Wacom devices on the hosting RDS OS and the same driver must support each device connected to the server.

  • Enhanced support for Asian languages. Enables the local Input Method Editor (IME) from the client device for entering text into a virtual desktop or application instead of the pre-deployed IME on the server. Using the local IME enables additional language choices because of the various IME brands available for the client. Using the local IME affords you convenience when using client touch keyboards, and an experience that is the same as using a native application. To enable or disable the local IME on the client, use these commands on the command line interface: wfica32.exe /localime:on to enable it and wfica32.exe /localime:off to disable it. The new setting applies to all sessions started after the setting change.

  • Auto client reconnect and session reliability consistency. Auto client reconnect and session reliability allow users to reconnect automatically to their Citrix Receiver sessions after recovering from network disruptions. Updates to auto client reconnect and session reliability policies in Studio are synchronized from server to client, which helps maintain reliable connectivity.

  • Bidirectional content redirection. Enables administrators to specify client to host and host to client URL redirection using group policies. Server policies are set in Studio, and client polices are set from group policy.

  • Client drive mapping. File copying performance is enhanced.

VDA installation and upgrade changes:

  • The 7.13 VDAs contain several new and enhanced features, as described in this section. However, after upgrading your VDAs from version 7.9, 7.11, or 7.12, you do not need to update the Machine Catalog’s functional level. The default (“7.9 (or newer …)”) remains the current functional level.

StoreFront 3.9

StoreFront includes the following new features and enhancements.

  • SAML authentication through StoreFront. Administrators can configure StoreFront to integrate with a SAML Identity Provider in Manage Authentication Methods > SAML Authentication.
  • Import multiple NetScaler Gateway vServer configurations. Administrators can import multiple vServer configurations from the StoreFront management console (Manage NetScaler Gateways > imported from file) or using PowerShell.
  • Configure two URLs for the same NetScaler Gateway using the StoreFront PowerShell SDK. In 3.9, administrators can set a new optional paramater, -gslburl, on the GslbLocation attribute. This simplifies the NetScaler Gateway administration in StoreFront.
  • Support for adaptive transport.
  • Citrix Customer Experience Improvement Program (CEIP). You are now automatically enrolled in CEIP when you install StoreFront.

 

Provisioning Services 7.13

Provisioning Services includes the following new features and enhancements:

  • PVS-Accelerator. This feature enables a PVS proxy to reside in the XenServer’s Control Domain on a host where streaming of a Provisioning Services vDisk is cached at the proxy before being forwarded to the virtual machine. Using the cache, subsequent booting (or any I/O requests) of the virtual machine on the same host can be streamed from the proxy rather than streaming from the server over the network. Using this model, more local resources on the XenServer host are consumed, but streaming from the server over the network saves resources, effectively improving performance.
  • Linux streaming. You can now provision Linux virtual desktops directly in the XenDesktop environment.