Quick interesting facts about XenApp 7.5

Posted on April 11, 2014 by Murugan B Iyyappan

StoreFront 2.5 has been released and StoreFront 2.0 is the minimum supported version with XenApp and XenDesktop 7.5.

Provisioning Services version is 7.0 is the minimum supported version.

Requires at least Citrix License Server 11.11 and the old service is replaced by Citrix Web Services for Licensing, which provides similar functionality.

NetScaler Gateway is the replacement option for securing external connections. No more support to Secure Gateway.

Supports hybrid cloud provisioning on Amazon Web Services (AWS) or any public / private cloud.

No Anonymous or no guest permissions to published applications. Using Studio, administrators configure Delivery Groups and then allocate virtual desktops and applications to Delivery Groups.

Shadowing end-users is an integrated feature of the Director component, which uses Microsoft Remote Assistance to allow administrators to shadow and troubleshoot issues.

Custom ICA files were used to enable direct connection from user devices (with the ICA file) to a specific Citrix server. Now this feature is disabled by default, but can be enabled in high-availability mode if the Controller becomes unavailable.

The Microsoft Configuration Manager is the replacement tool for Power and Capacity Management.

No more Session pre-launch, Virtual IP Loopback support, Smart Auditor, Single Sign-on and Oracle database support.

Posted in Citrix XenApp | Tagged , , , , , , , , , | Leave a comment

Explain Provisioning Services Architecture

Posted on April 9, 2014 by Murugan B Iyyappan

Provisioning Services works differently than Machine Creation Services to provide resources to the users. PVS allows machines to be provisioned and re-provisioned in real time from a single shared vDisk. So the administrators can manage and update only on the master vDisk, in some case we can remove from the system itself.

The MCS provisioning machine is all about storage and PVS relies on network. Simple process with PVS is, start off with Master Target Device, capture the disk as a new vDisk and then provision the vDisk to the target devices. The AD-identity (SID) comes from an additional disk in MCS and PVS uses SQL database for this.

After installing and configuring PVS, vDisk can be created by imaging a hard disk (contains OS with Applications) and this vDisk file is stored on the network. The device which is used to create the vDisk is called Master Target Device and the devices that use the vDisk are called target devices.

Updates and writes with MCS are saved to a Differencing Disk, while writes with PVS are saved to a Write Cache.

The target devices download a boot file from the PVS and then use that boot file to start. Based on the device boot configuration settings the appropriate vDisk is located and then mounted on the PVS server. The application and the desktop OS on the vDisk are streamed by the PVS server to the target device.

Instead of pulling down all of the vDisk contents to the target device, the date is brought across the network in real time which dramatically reduces the amount of network bandwidth thereby supporting a larger number of target devices on the network without impacting overall network performing.

Difference between MCS and PVS

MCS and PVS

 

 

 

 

 

 

 

 

 

PVS working process

  1. A target device powers on and uses TFTP to download bootstrap file (ARDBP32.BIN) which provides the target device with the connection required to get its vDisk.
  2. TD uses Bootstrap file to request that PVS to send the boot sector from the vDisk.
  3. PVS access the vDisk from the Store (storage) and dynamically merges the boot sector with the SQL server data to apply appropriate SID based on the MAC address of the TD.

As the target device starts up, further requests for additional sectors from the vDisk are access in the same method. With PVS the entire vDisk is not streamed instead sectors are sent to the target device as needed.

Posted in Citrix | Tagged , , , , , , , , , , | Leave a comment

What is High Availability Mode in XenApp/XenDesktop 7.5?

Posted on April 8, 2014 by Murugan B Iyyappan

If all Delivery Controllers in a XenApp site fail, we can configure the VDA to operate in high availability mode so that users can continue to access and use their desktops. In high availability mode, the VDA will accept direct ICA connections from users, rather than connections brokered by the Controller.

When VDA lost its communication with the Controller, high availability mode is initiated only after a set period of time has elapsed. By default, this is 5 minutes (300 seconds). We can also configure the time period. HA mode is enabled for 30 days.

Once in HA mode, the VDA attempts to register with a Controller for up to 30 days, while the user continues to use the desktop in this mode. When the Controller later becomes available before 30 days, the desktop registers and the user’s session continues uninterrupted, but any subsequent connection is brokered by the Controller as normal. If after 30 days the desktop is unable to register with the Controller, the desktop stops listening for connections and is no longer available.

High availability mode is suitable only for use with dedicated desktops, where the mapping between the user and the VDA is known. We cannot configure high availability mode for users with pooled desktops.

To enable high availability mode in the VDA machine:

  1. Set the HighAvailability and HaRegistrarTimeout values in the registry keys.
  2. Provide users with an ICA launch file that will enable them to make direct ICA connections. We have to create an ICA file for each user who requires this feature.

To configure the VDA to operate in HA mode when necessary, add the following registry keys. You must do this after the VDA has been installed.

1. Add the following registry entry

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VirtualDesktopAgent:

Name: HighAvailability

Type: REG_DWORD

Values: 1/0

1 = enables high availability mode

0 (zero) = disables high availability mode

2. Change the VDA registering time period with the Controller before initiating HA mode:

Name: HaRegistrarTimeout

Type: REG_DWORD

Value: 300. The default is 300 seconds.

3. Restart the virtual desktop.

Prepare an ICA launch file

To establish a direct ICA connection to desktops, provide users with a Minimal ICA launch file that they can use should communication with the Controller fail. We must create an ICA launch file for each user who requires this feature and users should only use this ICA launch file when it is appropriate.

Open Notepad on the client computer and copy and paste the below Minimal ICA Launch file content:

Change the following fields:
USER_LOGON_NAME_HERE to the actual user’s logon name
USER_PASSWORD_HERE to the actual user’s clear text password
DOMAIN_NAME_HERE to the actual domain name
DESKTOP_IP_ADDRESS_HERE to the desktop’s IP address
Save the file with a relevant name and with an .ICA extension to an easy to find location on the computer of the client.

High availability mode limitations

High availability mode is suitable for use only with dedicated desktops; you cannot configure this for use with pooled desktops.

Policies originating on the Controller, such as those governing client drive mapping and access to the clipboard, will not function as there is no connection to the Controller. Policies originating from the Domain Controller and Local Group Policy are unaffected.

As it is directly connecting there will not be a communication with NetScaler Gateway and Remote Access.

Posted in Citrix | Tagged , , , | Leave a comment

What is new in XenApp 7.5?

Posted on April 8, 2014 by Murugan B Iyyappan

The XenApp 7.5 now moves to the FlexCast Management Architecture (FMA) as same as XenDesktop, brings conceptual and more flexible architecture. Here are the differences between XenApp 6 entities and terminology in a XenApp 7.5 world.

FlexCast Management Architecture

The FlexCast Management Architecture (FMA) is a service-oriented architecture that allows interoperability and management modularity across Citrix technologies. FMA provides a platform for application delivery, mobility, services, flexible provisioning, and cloud management.

FMA replaces the Independent Management Architecture (IMA) used in XenApp 6.x

Elements in the new architecture

Delivery Sites

Farms were the top level objects in XenApp 6.x. In XenApp 7.5, the Delivery Site is the highest level item. Sites offer applications and desktops to groups of users.

The FMA requires that you must be in a domain to deploy a site. For example, to install the XenApp servers, your account must have both local administrator privileges and be a Domain Administrator in the Active Directory.

Session Machine Catalogs and Delivery Groups

Machines hosting applications in XenApp 6.x belonged to Worker Groups for efficient management of the applications and server software. Administrators could manage all machines in a Worker Group as a single unit for their application management and load balancing needs. Folders were used to organize applications and machines.

In XenApp 7.5 we use a combination of Session Machine Catalogs and Delivery Groups to manage machines, load balancing, and hosted applications or desktops.

A Session Machine Catalog is a collection of machines that are configured and managed alike. A machine belongs to only one catalog. The same applications or desktops are available on all machines of the catalog.

Delivery Groups are designed to deliver applications and desktops to users. A Delivery Group can contain machines from multiple machine catalogs, and a single machine catalog can contribute machines to multiple Delivery Groups. However, one machine can belong to only one Delivery Group. You can manage the software running on machines through the catalogs they belong to. Manage user access to applications through the Delivery Groups.

Virtual Delivery Agents

The Virtual Delivery Agent (VDA) enables connections to applications and desktops. The VDA is installed on the machine that runs the applications or virtual desktops for the user. It enables the machines to register with Delivery Controllers and manage the High Definition eXperience (HDX) connection to a user device.

In XenApp 6.5, worker machines in Worker Groups ran applications for the user and communicated with data collectors. In XenApp 7.5, the VDA communicates with Delivery Controllers that manage the user connections.

The VDA installs on Server OS machines and Desktop OS machines

Delivery Controllers

In XenApp 6.x there was a zone master responsible for user connection requests and communication with hypervisors. In XenApp 7.5 connection requests are distributed and handled by the Controllers in the site. XenApp 6.x zones provided a way to aggregate servers and replicate data across WAN connections. Although zones have no exact equivalent in XenApp 7.5, we can provide users with applications that cross WANs and locations. You can design Delivery Sites for a specific geographical location or data center, and then allow users access to multiple Delivery Sites. App Orchestration with XenApp 7.5 provides capabilities for managing multiple sites in multiple geographies.

Citrix Studio and Citrix Director

Citrix Studio console is used to configure the environments and provide users with access to applications and desktops. Studio replaces the Delivery Services Console and AppCenter in XenApp 6.x.Administrators use Director to monitor the environment, shadow user devices, and troubleshoot IT issues.

Delivering applications

XenApp 6.x used the Publish Application wizard to prepare applications and deliver them to users. In XenApp 7.5, you use Studio to create and add applications to make them available to users who are included in a Delivery Group. Using Studio, you first configure a site, create and specify machine catalogs, and then create Delivery Groups within those machine catalogs. The Delivery Groups determine which users have access to the applications you deliver.

Database

XenApp 7.5 does not use the IMA data store for configuration information. It uses a Microsoft SQL Server database to store configuration and session information and no more support for MS Access and Oracle databases.

Load Management Policy

In XenApp 6.5, load evaluators use predefined measurements to determine the load on a machine. User connections can be matched to the machines with lesser load. In XenApp 7.5, use load management policies for balancing load across machines.

Delegated Administrators

In XenApp 6.5, we created custom administrators and assigned them permissions based on folders and objects. In XenApp 7.5, custom administrators are based on role and scope pairs. A role represents a job function and has defined permissions associated with it to allow delegation. A scope represents a collection of objects. Built-in administrator roles have specific permissions sets, such as help desk, applications, hosting, and catalog. For example, help desk administrators can work only with individual users on specified sites, while full administrators can monitor the entire deployment and resolve system-wide IT issues.

Posted in Citrix XenApp | Tagged , , , , , , | Leave a comment

How big will the XenDesktop transaction log become?

Posted on April 8, 2014 by Murugan B Iyyappan

The XenDesktop database contains both configuration and state information, which must be updated often. A single Virtual Desktop Agent doing nothing for an hour generates approximately 62 kilobytes of transaction log data.

The following are the average transaction log calculations:

Number of Virtual Desktop Agents x 24 Hours x approximately 62 kilobytes of data.

For example, if we have 10 Virtual Desktop Agent in idle state:

10 VDA x 24 hrs x 62K = 14.8 megabytes per day

Note: This can be substantially higher in active environments.

Posted in Citrix XenDesktop | Tagged , , , | Leave a comment