Welcome to TechEdge.

Welcome to TechEdge

Why Use Twitter @ TechEdge?
Back channel for real-time conversations Broadcast key takeaways Ask questions Event feedback Broadcast key takeaways to colleagues that couldn't attend Ask questions - we'll have a Twitter moderator to queue questions for the presenter to the end of each presentation or answer them among yourselves Let's know what you think of the event - provide your own testimonial Particpate in an open channel conversation with audience members, presenters and colleagues

How to Use Twitter During TechEdge
Twitter will appear on projector screen during: Breaks Q&A Wireless access code: CTXS_Synergy_TE Join the Conversation Contribute: Include #TechEdgeC as part of each Tweet Follow: Visit Enter #TechEdgeC Citrix Twitter moderator will ask presenter best Twitter questions In Twitter lingo, anything preceded by “#” is called a hashtag

Follow Citrix Tech Support on Twitter
Join the Conversation and follow Citrix Tech Owner: Mike Stringer - Sr. Director, Americas/India Support

Citrix Delivery Center
TechEdge 2009

Presenters Kapildev Ramlal Keith McLaughlin Jacob Maynard Don Williams
Sr. Escalation Engineer (XenDesktop, XenApp) Keith McLaughlin Escalation Engineer (Provisioning Server) Jacob Maynard Sr. Escalation Engineer (Acess Gateway Enterprise Edition) Don Williams Escalation Manager (Netscaler)

Agenda Citrix Delivery Center Intro XenDesktop and XenApp XenServer
Provisioning Server Access Gateway Enterprise Edition Use an orange bar to highlight important information. NetScaler

XenApp App virtualization for Windows NetScaler Advanced web app delivery XenServer High performance server virtualization XenDesktop Windows desktop virtualization Citrix Workflow Studio orchestration Citrix Delivery Center

XenApp

Introducing Citrix XenApp
Citrix XenApp was formerly known as Citrix Presentation Server Prior to Citrix Presentation Server, it was known as Citrix MetaFrame, and prior to that, Citrix WinFrame It is the heart of Application Virtualization It delivers applications as an on-demand service to users anywhere using any device

Citrix XenApp Architecture
Utilizes a Farm concept A server farm is a logical grouping of servers running XenApp that share a data store California New York Data Store Florida

Citrix XenApp Architecture – IMA
Independent Management Architecture (IMA) - Infrastructure for inter-server communication A collection of subsystems that control the various features of the Citrix XenApp family of products IMA helps in centralized administration of the farm Implemented in the form of a Windows Service (managed by the Service Control Manager) What is IMA?

Citrix XenApp Architecture – IMA Subsystems
A subsystem is a DLL (*.dll) file. Subsystems allow for a modular plug-in architecture. The subsystem DLL files can be found typically in the following directory: x86 Location Program Files\Citrix\System32\Citrix\IMA\Subsystems x64 Location Program Files (x86)\Citrix\System32\Citrix\IMA\Subsystems

Citrix XenApp Architecture – Farm Data
The Farm relies on data The IMA service is the backbone of the Farm, and is responsible for manipulating the Farm's data Each XenApp server runs the IMA service There are 2 main forms of data: Static Data Data which changes infrequently such as published applications, Citrix Administrators, Citrix policies, etc. Dynamic Data (Dynamic Store) Data which changes frequently, such as connected sessions etc.

The Dynamic Store The dynamic data is stored in in-memory tables on the Data Collector (Dynamic Store). The info can be viewed using the QueryDS.exe utility located in the following directory on the XenApp CD: w2k3\retail\Support\debug\w2k3

The Local Host Cache (Static Data) Is a subset of the Data Store containing information required only by that server Allows the server to operate if the Data Store goes down Must exist and be accessible for the IMA Service to start Is an Access database located on every XenApp server in the farm x86 (Program Files\Citrix\Independent Management Architecture\imalhc.mdb) x64 (Program Files (x86)\Citrix\Independent Management Architecture\imalhc.mdb)

Citrix XenApp Architecture – IMA Startup
ImaRpcSs.dll ImaSrvSs.dll ImaAppSs.dll MfSrvSs.dll MfBrowserSs.dll ImaUserSs.dll ImaDomain.dll RMAlertsSS.dll RMMonitorSS.dll RMSummaryDBSS.dll……………….. Service Control Manager ImaRuntimeSs.dll Required Plug-ins IMASrv.exe PSRequired HKLM\Software\Citrix\MA\Runtime Product Plug-ins PSRequired=0 PSRequired=1 Zone Data Collector LHC LHC LHC

Citrix XenApp Architecture - Zones
A server farm can consist of one or more zones A server farm is typically divided into zones when the servers in the server farm are separated geographically Each zone has a data collector The data collector is responsible for collecting data from member servers and distributing it to other data collectors The first server in the zone is designated as the data collector for the zone, by default

Citrix XenApp Architecture - Zones
ZONE B ZONE C ZONE A Web Interface XML Broker

Citrix XenApp Architecture – Change Notification
Access Management Console Member Server 2512 Member Server 2513 Member Server 2512 2512 Data Collector Data Store Member Server Data Collector 2512 2512 Member Server Zone A Member Server Member Server Zone B 2) The member server writes the change to the DS and forwards the information to the DC via TCP port 2512 Change is made on the CMC via TCP port 2513 The DC updates the LHC on the member servers in its zones via TCP port 2512 and forwards the information to all the other DC’s 4) The other DCs send the information to their member servers

Citrix XenApp Architecture - Licensing
Farm A Farm A License Server Server 2 Server 1 Server 2 Server 1 Data collector Data collector Server 3 Server 4 Server 3 Server 4 All farm servers must be configured to access a license server with valid licenses for Presentation Server A single license server can be used by one or more server farms If connection to the license server is lost, licenses remain available to the servers running Presentation Server for 30 days

Citrix XenApp Architecture – Web Interface & SG
Web Interface provides users with access to published applications and content through a standard web browser or Program Neighborhood Agent Secure Gateway (SG) provides a secure encrypted channel for HTTP and ICA traffic over the web SG contacts the Secure Ticket Authority on a server running XenApp to authenticate connections through session tickets

From Logon to Launch Active Directory XML Broker Web Interface LHC
Authentication XML Service Basic Networking CDF Tracing XML Broker Web Interface CDF Trace Verify User Logon Rights Event Logs Network Trace LHC Lists Servers Apps Trusts Data Store IIS Logs Network Trace Data Collector Client Dynamic Store Member Services

Citrix XenApp - Troubleshooting
IMA performance counters IMA related registry entries IMA service startup troubleshooting Frequently seen database issues troubleshooting with DSMAINT, DSCHECK, etc. LHC troubleshooting Event logging CDF tracing

XenDesktop Setup

Active Directory Integration
Uses Kerberos to Authenticate DDC to VM traffic Desktops discover DDCs No Schema change

Active Directory Integration
Create an OU for XD farm Run Active Directory Configuration Wizard

XenDesktop Setup Wizard
Integrates with Hosting Infrastructure Creates multiple virtual desktops Integrates with PVS The XenDesktop Setup Wizard makes execution and provisioning of your Virtual Desktops simple and quick. When running the wizard, you’re asked to choose all the necessary pieces and the wizard puts them together into a desktop group. Choose the farm from the active directory infrastructure Choose your hosting infrastructure Choose the template machine from that infrastructure Choose the correct PVS vDisk Name the desktops and choose the quantity Place them into the correct AD OU Setup your desktop group The wizard will then create the desktops, provision them and place them into the desktop group.

Integrating with PVS

Pool Management

Services Involved Citrix Pool Management Service
Hosting Infrastructure XenServer Pool Master Vmware Virtual Center MS SCVMM Virtual Machines Pool Master Pool Management Service

Pool Management Virtual Machines Pool Master
Desktop Delivery Controller Pool Management Service In order to speed user login and connection, XenDesktop will keep a pool of Virtual machines powered up to receive new connections. This pool can be configured through the AMC. The idle pool allows user to connect to a desktop without having to wait for it to be powered on and booted. The Pool Management service runs on all DDC servers in the farm, however only the ZDC is actively managing the pool. Failover is similar to the ZDC election process and if the ZDC/primary pool manager goes down, the server elected to the new ZDC will take over. The pool management service maintains the state of each VDA. When the pool needs to be replenished, the service makes a call to the hosting infrastructure, either the XenServer PoolMaster, Vmware Virtual Center or Hyper-V. The call asks for specific VMs to be powered on. The calls are throttled to 10% of the total pool in order to prevent overwhelming the hosting infrastructure. Once the VDA is registered, then it is added to the pool. If the VDA does not register in 3 minutes, then the pool management service places it in an error state and attempts to start a new machine in its place.

Troubleshooting Logging in Pool Management Service XenServer logs
CTX117452 XenServer logs CDF Tracing XDPing tool

XenServer

Agenda XenServer Benefits Live Migration Xenmotion High Availability
Provisioning VM with PVS XenApp Performance Disaster Recovery

Presentation Title Goes Here
Insert Version Number Here Why Virtualize? IT flexibility/agility Predictable scaling to dynamically respond to business need Key part of disaster recovery strategy Improve application availability Server or data center consolidation Higher utilization leads to greater consolidation Promotes greater centralization and security "Green Computing" Consume less power, cooling, and real estate Support DevTest environments Works for both IT shops and development houses Additional benefits of going virtual Creating New Servers is fast and easy No driver hassles moving to new hardware Zero downtime hardware maintenance with XenMotion Disaster recovery plans simplified © 2007 Citrix Systems, Inc.—All rights reserved.

XenMotion – Live VM Movement
XenMotion allows minimal downtime movement of VMs between physical systems Generally ms of actual “downtime” Most of the downtime is related to network switch moving IP traffic to new port XenMotion allows you to move a live VM from one physical server to another without any service downtime. The switchover period is normally around ms. In XenEnterprise v4 XenMotion is an operator-initiated operation.

XenMotion Enables Zero Downtime
Xen Hypervisor Xen Hypervisor Xen Hypervisor Shared Storage

XenApp Optimizations Specific performance optimizations for XenApp
Pre-built VM Templates for installing XenApp on XenServer Luckily, we supply an interface to let the admin tweek the multiplier. The multiplier is a number that is multiplied by trhe amount of memory from the algorithm discussed previously. Total memory = (1.5 X VM Memory) * Multiplier This properties dialog is accessible by right-clicking the VM node, and choosing properties. The XenApp multiplier should be left at that for XenApp virtual machines

Simplifying Disaster Recovery
Xen Hypervisor Xen Hypervisor Automated backup of VM metadata to SR Replication of SR includes Virtual Disks and VM metadata Attach replicated SR Restore of VM metadata will recreate VMs Xen Hypervisor 1 Xen Hypervisor 4 2 1 3 3 Even if you are not using remote storage you can backup VMs and move them around using our import/export functionality. Again since the VMs are isolated from any hardware differences between the underlying servers you remove all of the driver headache found when moving a physical OS instance around to different boxes. Shared Storage Shared Storage 4 2 Production Site DR Site

High Availability High availability (HA) provides automatic restarts for VMs in a resource pool When HA is enabled; XenServer continually monitors the health of the servers in a resource pool XenServer uses heartbeats on the network and a storage device (Heartbeat SR) to determine the state of the servers in the resource pool If a server in the resource pool fails, the VMs running on it automatically restart on another server If the master fails, a new server is automatically selected to take over the master role When the High Availability feature is enabled, XenServer continually monitors the health of the servers in a pool. If a server in the pool suffers a failure, the virtual machines running on it will automatically be restarted on another, healthy, server. Additionally, if the server that fails is the master, a new server will be selected to take over the master role automatically, meaning that you will be able to continue to manage the XenServer pool. XenServer uses heartbeating over the network and a storage device (via the 'Heartbeat SR') to determine the state of the servers in a resource pool.

HA Requirements Requirements for enabling the HA feature include:
Shared storage, including at least one iSCSI or Fibre Channel LUN of size 356MiB or greater for the heartbeat storage repository A XenServer resource pool Adequate licenses on all hosts Agile VMs Note: a separate shared storage setup is required for Metadata Requirements for configuration In order to use the HA feature, you will require: • Shared storage, including at least one iSCSI or Fibre Channel LUN of size 356MiB or greater. This LUN will be used for the Heartbeat SR. • A XenServer pool (this feature provides high availability at the server level within a single resource pool). • Adequate licenses on all hosts.

Considerations for HA The iSCSI or Fibre Channel LUN is only required for the storage heartbeat. Only agile VMs can be protected by the HA feature An agile VM: Has its virtual disks on shared storage Does not have a connection to a local DVD drive configured Has its virtual network interfaces on pool-wide networks Note: It is a good practice to use a bonded management interface on the servers in the pool if HA is enabled, and multipathed storage for the Heartbeat SR The HA mechanism creates two volumes on the heartbeat storage repository: 4MiB heartbeat volume used for heartbeats. 256MiB metadata volume Stores pool master metadata to be used in the case of master failover. In order for a virtual machine to be protected by the HA feature, it must be agile. This means that it must have its virtual disks on shared storage (any type of shared storage may be used; the iSCSI or Fibre Channel LUN is only required the storage heartbeat and can be used for virtual disk storage if you prefer, but this is not necessary), must not have a connection to a local DVD drive configured, and should have its virtual network interfaces on pool-wide networks. It is highly recommended to use a bonded management interface on the servers in the pool if HA is enabled, and multipathed storage for the Heartbeat SR.

Restart Protection Levels
Each VM protected by HA has a restart priority and a flag indicating it is to be protected by HA If a restart priority is specified, any protected VM that is halted, such as in the event of a server failure, automatically restarts on another server Protection levels include: High Medium Low Best effort Do not restart For each virtual machine you wish to protect, set the restart priority to High, Medium or Low by selecting them, right-clicking and then selecting a priority from the shortcut menu. To select more than one virtual machine, click at the start of the selection, scroll to the end of the selection, and then hold down SHIFT while you click where you want the selection to end. To select several virtual machines that are not next to each other in the list, click the first one, press CTRL, and then click the additional virtual machines that you want to select. Select High, Medium or Low to protect a virtual machine and specify the order in which it will be restarted in the event of failure. Select Best Effort if you do not need to include a virtual machine in your failure plan. Virtual machines with this restart setting are not guaranteed to be restarted, but if they are believed to have failed and if there is sufficient resource available after all other protected virtual machines have been successfully started, they will be restarted on a live server. Best Effort is the only restart priority available to non-agile virtual machines, that is, virtual machines that have local storage or that have a connection to a local DVD drive configured or that have local virtual network interfaces. Select Do not restart if you never want the virtual machine to be restarted automatically. The failover capacity for the pool given the resources available and the restart priorities you have specified is shown on the right of the list of virtual machine.

HA, VMs and Failure Events
View server failure tolerance: In the HA panel in XenCenter Using the ha-plan-exists-for field on the pool object in the CLI If server failures tolerated is greater than zero, the VMs with restart protection levels restart If the pool experiences server failures and the number of tolerable failures drops to zero, a system alert is generated If the tolerable failures are at zero and an additional failure occurs, all VMs that have a restart priority set behave according to the best effort behavior The restart priorities determine the order in which VMs are restarted when a failure occurs. In a given configuration where a number of server failures greater than zero can be tolerated (as indicated in the HA panel in the GUI, or by the ha-plan-exists-for field on the pool object in the CLI), the VMs that have restart priorities High, Medium, and Low are guaranteed to be restarted given the stated number of server failures. If the pool experiences server failures and enters a state where the number of tolerable failures drops to zero, the protected VMs will no longer be guaranteed to be restarted. If this condition is reached, a system alert will be generated. In this case, should an additional failure occur, all VMs that have a restart priority set will behave according to the Best Effort behaviour.

Over committing A pool is overcommitted if the VMs that were running cannot restart, for example there is not enough memory available Other changes that make HA guarantees unsustainable exist, such as changes to VBDs and networks can affect which VMs may be restarted on which hosts If a protected VM cannot be restarted (e.g. the pool is overcommitted), further attempts to start the VM are made as extra capacity becomes available in a pool Note: No running VM is ever stopped or migrated in order to "make room" for a VM with always-run==true to be restarted Overcommitting A pool is overcommitted if the VMs that are currently running could not be restarted elsewhere following a user-defined number of failures. This would happen if there was not enough free memory across the pool to run those VMs following failure. However, there are also more subtle changes which can make HA guarantees unsustainable: changes to VBDs and networks can affect which VMs may be restarted on which hosts. Currently it is not possible for the agent to check all actions before they occur and determine if they will cause violation of HA demands. However there will be an asynchronous notification if HA becomes unsustainable. If a protected VM cannot be restarted at the time of a server failure (for example, if the pool was overcommitted when the failure occurred), further attempts to start this VM will be made as the state of the pool changes. This means that if extra capacity becomes available in a pool (if you shut down a non-essential VM, or add an additional server, for example), a fresh attempt to restart the protected VMs will be made, which may now succeed. Note No running VM will ever be stopped or migrated in order to "make room" for a VM with always-run==true to be restarted.

Over commitment Warning
If an administrator attempts to start or resume a VM and that action would cause the pool to be overcommitted a warning alert appears The administrator is then allowed to cancel the operation, or proceed, where proceeding causes the pool to become overcommitted Over commitment warnings Display in XenCenter Are sent to an address if configured Overcommitment Warning If you attempt to start or resume a VM and that action would cause the pool to be overcommitted a warning alert is raised. This warning is displayed in XenCenter and is also available as a message instance through the Xen API. The message may also be sent to an address if configured. You will then be allowed to cancel the operation, or proceed anyway. This will cause the pool to become overcommitted. The amount of memory used by VMs of different priorities is displayed at the pool and host levels.

Enabling HA on a XenServer Pool
HA is enabled on a pool in either XenCenter or in the command line interface (CLI) HA enablement requires a specified set of priorities that determine the order that VMs restart if a failure occurs Compatible storage repositories include: iSCSI Fibre Channel Note: When HA is enabled, some operations are disabled that would compromise the plan for restarting VMs (e.g. removing a server from a pool). To perform these operations, HA must be temporarily disabled

HA Failure Tolerance The number of failures tolerated determines when an alert is sent. The system recomputes a failover plan as the state of the pool changes. With this computation, the system identifies the capacity of the pool and how many more failures without loss of the liveness guarantee for protected VMs. A system alert is generated when this computed value falls below the specified value.

Configuring HA (XenCenter)
Verify the storage repository is compatible and is attached to the XenServer pool 1 Click on an entry for your resource pool in XenCenter. The HA tab appears in the main view. 2 If HA is configured, an overview of the system status displays. If not, a message appears stating HA is not enabled. Click Configure HA. 3 2 1 3

Configuring HA: High Availability Wizard (XenCenter)
Click Next after the High Availability dialog opens 4 6 5 Select a storage repository and click Next 5 Specify restart protection levels and click Next 6 Click Finish 7 5 6 4

Host Fencing If a server failure occurs, the XenServer self-fences to ensure that the VMs are not running on two servers simultaneously Server failure examples: Loss of network connectivity A problem with the control stack When a fence action is taken, the server immediately is restarted, causing all of the VMs running on it to stop. The other servers detect the VMs are no longer running and the VMs are restarted according to the assigned priorities. The fenced-server enters a reboot sequence and when it has restarted, it attempts to rejoin the resource pool

High Availability – XenServer Host
Three Components High Availability recovery plans created at startup stored in statedb Storage heartbeat to Qurorum Vdisk Network heartbeat over management interface Heartbeat to SR 1 Quorum Database SAN VDIs 2 Heartbeat to Network 3 State.DB Recovery Plans

High Availability – XenServer Host
Peer Based – Enable recovery plan Servers 2 and 3 have not heard from server 1 on the network Server 2 and 3 have not seen an udpate from Server 1 on the Quorum disk Self-Aware – Assume the HA plans are in play Server 1 cannot see Quorum disk Server 1 has not heard from Server 2 or Server 3 Self Fence network – VMs are expected to be started elsewhere Quorum Database SAN VDIs 1 2 3 High Availability in the hypervisor Kernel mode Direct control over local interfaces Never out of resources State.DB

Citrix Provisioning Server

Agenda What active directory issue arise when streaming a vDisk
Common Issues and Best Practices How does Provisioning resolve these issue Introduction: During this training we are going to be talking about Provisioning Server High Availability. How many have setup Provisioning Server before? How many have used High Availability? First we are going to give a brief overview of what High Availability is and the two main configurations it can be setup with.

Two main Streaming concerns with AD
PVS Server SQL Database Domain Controller When streaming multiple end points with the same vDisks there is two major Active Directory concerns. Hostname, since each end point needs to login to the domain they each need a unique hostname. Machine Account Passwords changes. Most environments require machine account password changes for security purposes this can be a problem when streaming in Standard image mode (many targets to one vDisk) since all changes are deleted on reboot. If the Target Device negotiates a new machine account password with AD and reboots the Target Device will revert to the previous password and Active Directory will not allow the machine to logon to the Domain. Hostname TD1 Hostname TD1 Hostname TD1 Hostname TD1

Unique Hostnames When booting to a vDisk in either Standard or Private image the Streaming Service will insert the Name entered in the PVS console as the Target Device. This provides a unique naming convention for Active directory. This is done by editing the hostname Registery Key Value during the boot. TIP: It is import to give UNIQUE names to the Target Devices and not use the same hostname as the Target Device has when booting to Hard Drive.

Machine Account Creation
PVS Server SQL DB Domain Controller Target1 Target1 Add Target1 to Domain When in Standard Image mode Provisioning Server can Manage Machine Account Password Changes. [CLICK1] PVS Server adds Target one to Active Directory It does this by contacting Active Directory and creating the machine Account for the Target. Domain Controller sends the Key to create the Machine Account Password to the PVS which is then stored in the DataBase. [CLICK2] Target Device Boots and the PVS Server writes the Key into the Registery of the Target Device during the boot process] When the Target device boots that key is inserted into registry for reference during AD Authentication. If the Target is booted to the logon screen then added to AD through the console the Target will not have the correct Machine Account Password Until it is rebooted. Boot Target1

Reset Machine Account Password (Manually from Console)
SQL DB Target1 PVS Server Domain Controller Target1 Reset Target1 Key If the password is reset by using the “Resetting Machine Account Password” option through the console the PVS Server contacts the Domain Server Directly and negotiates a new password. This change, like creating the account, requires a reboot before the Target Device will have the change. Target 1 has a existing key and the Machine Account is reset from the Provisioning console. [CLICK] PVS Server sends a reset Machine Account request to the Domain Controller A new key is generated and sent to the Provisioning Server. The Provisioning Stores it in the Database. NOTE: Target1 still has the old credentials and will not authenticate to the domain until it is rebooted. Target1 is rebooted and receives the updated credentials. Target1 Reboot

Machine Account Password Reset (Automatic)
PVS Server SQL DB Password Reset Domain Controller Target1 Target1 Expiration Expiration Target1 No Expiration When Active Directory Machine Account Password Management and Automated Password Support are enabled in the console an expired time is passed into the Target Device on boot with the Password Key. The password has expired Windows will negotiate a new password. This communication is done between the Target and Active Directly the same as it would in a non-streaming environment. The only difference is the PVS Device Service prompts windows to make the change and once the new key is negotiated the PVS Device will relay the new key to the PVS Server and the Database will be updated with the new key. [CLICK1] Target Device Boots Hostname Key and Expiration date/time are entered to registry key. [CLICK2] Machine Account Password Expires [CLICK3] Target1 contacts Domain Controller and resets the password [CLICK4] The BNClient Service send the new key to the PVS Server and it is updated in the DB. Boot Target1

Common Issues Best Practices
Make the Target Name Unique Local Machine Account Password Changes disabled. Do not add the Target devices very deep in the active directory tree. Make the Target Device name unique in the Active Directory structure is key to avoiding trust issues. Do not name the Target Device the same as unprovisioned end point. Make sure local machine account password changes is disabled in the local security policy and in any GPO assigned to the Computer object. Do not add Target Devices more the six or seven tiers deep in the AD Tree.

Access Gateway Enterprise Edition

Access Gateway - Features
The access gateway comes with a full feature set including but not limited to: Remote based authentication User Level Auditing for accounting purposes And Various Clients to support not only Microsoft Client devices, but Unix, Linux, and Mac based users as well. The Key differentiator that really sets the Access Gateway apart from it’s competition; is its ability to seamlessly integrate into the Citrix Delivery Center. Examples of this are: XenApp and XenDesktop Integration where you can use granular SmartAccess policies to custom tailor the end users secure remote access. Also, NetScaler and its LB and GSLB functionality which create that added comfort of redundancy, and disaster recovery.

Access Gateway Enterprise Edition: XenDesktop Integration
To begin, I am going to talk a little bit about Xen Desktop Integration

XenDesktop Integration
AGEE Theory AGEE Theory Take this example of a high level overview where AG-E Integration occurs between Citrix Branch Repeater, Web Interface, and backend published Xen Desktop resources. Typically The access gateway and repeater sit in the DMZ at the edge of your trusted Network With the client coming in across the cloud. The Web Interface and Desktop Delivery Controller are the key components that the gateway communicates with to provide Internal published desktops to the remote user These devices are going to be found sitting in the Private internal network, behind your most secure firewall access controls.

User Experience Access choices delivered to the user are based on SmartAccess policies & EPA results This scenario shows a typical AGEE logon experience with a pre-authentication scan followed by the choices page. Pre-authentication Scan If Successful, Displays the Logon Screen (UID/PWD) After authenticating, a sessions is created and the choices page is displayed

Access Gateway Authentication Disabled No EPA, ICA Proxy On
ICA/CGP ICA + SSL HTTPS Virtual Desktops HTTP(S) User LETS TAKE A LOOK AT THE FIRST ACCESS TYPE, ICA PROXY. HERE THE GATEWAY IS CONFIGURED WITH : AUTHENTICATION DISABLED NO END POINT SCANNING ICA PROXY IS CONFIGURED AS ON USER WILL MAKE A SECURE HTTPS CONNECTION TO THE FQDN OF THE VPN VSERVER. ACCESS GATEWY PROXIES THE REQUEST TO THE WEB INTERFACE BECAUSE AUTHENTICATION IF OFF THE WEB INTERFACE SERVER RESPONDS BACK WITH ITS LOGIN PAGE USER INTERS THEIR CREDENTIALS WEB INTERFACE SENDS AND XML REQUEST TO VALIDATE THE CREDENTIALS AND ENUMERATE PUBLISHED DESKTOPS ONCE THE VALIDATION SUCCEEDS, THE LIST OF AVAILABLE DESKTOPS IS BUILT AND PRESENTED TO THE USER IN AN HTTP RESPONSE. THE USER THEN SELECTS THE DESKTOP OF CHOICE AND THE GATEWAY PROXIES THE ICA OR CGP CONNECTION TO THE DELIVERY CONTROLLER. XML Desktop Delivery Controller Web Interface 5.0

Access Gateway Authentication Enabled EPA Enabled, ICA Proxy On
ICA/CGP ICA + SSL HTTPS Virtual Desktops HTTPS - SSO XML User In this slide ICA Proxy ON, End Point Analysis is also ON and We have enabled Authentication at the Gateway. Note that with Authentication enabled at the gateway, we have no need to keep the Web Interface in the DMZ and thus, have put it in the trusted Network End user experience User hits FQDN of VServer over HTTPS, and Upon the detection of IE the gateway will push the Active X End Point Analysis Client to the end user device Once the End Point Analsyis Scan has determined that the client device meets the criteria for access, the gateway then returns the login portal page to the user. Upon successful Logon, the Access Gateway Will perform a Single Sign-On To Web Interface, and The published set of desktops will be built and presented to the User in an HTTP response. The user will then select their desktop of choice, and again, the gateway will proxy the ICA connection to the backend virtual Desktop. WI 5.0 & Desktop Delivery Controller

WI 5.0 & Desktop Delivery Controller
Access Gateway Authentication Enabled EPA Enabled, Access Gateway client (ICA Proxy Off) Access Gateway ICA/CGP ICA + SSL HTTPS Virtual Desktops HTTPS - SSO XML User In the third example of XenDesktop Integration, we have now set ICA Proxy to OFF, Selected the Agent for the client device and have kept the Authentication and End Point Analysis configuration are both enabled. Here, the client will again make the Secure connection to the VPN Virtual Server The End Point Analysis Client will be pushed Down to the client device and the scan will once again check for compliance. Once the scan completes successfully the Login Portal page is then passed down Upon successful authentication, the Secure Access Client is pushed down and installed on the client device. Once the installation completes, an SSL tunnel is created between the Secure Access Client and the VPN Vserver and the gateway completes the SSO transaction to Web Interface. The configured set of published desktops is then passed down to the client where the client selects the desktop of choice. Here the Desktop ICA connection is streamed through the existing SSL VPN Tunnel and proxied in the backend to the Virtual Desktop. WI 5.0 & Desktop Delivery Controller

Access Gateway Enterprise Edition: XenApp Integration
XenApp integration and XenDesktop Integration are identical aside from the fact that you are now publishing application to users rather than virtual desktops. All of the delivery mechanisms are essentially the same.

XenApp Integration DNS LDAP/ LDAPS Web Interface Remote End User
External DMZ Internal DNS 53 (UDP) LDAP/ LDAPS NSIP 443,80* (HTTP/TCP) NSIP 389/636 (TCP) Web Interface Remote End User VIP SNIP or MIP 80, 8080, 443 (HTTP/TCP) 1494, 2598 (TCP) XenApp * Port 80 used for https redirect In most environments the communication between the AGEE and the backend servers would be as follows: Communication to the DNS and Authentication Server will occur in most topologies using the Netscaler IP. In this example, we are using LDAP or LDAPS which means we need 389 and 636 open from the DMZ to the private network. Communication to the Web Interface and XenApp Servers will occur using the Mapped or Subnet IPs. Typical ports required at the firewall for allowed access will be 80, 443, 1494, and 2598. Last, management traffic generally comes from an internal device to the NSIP. Initially users will connect over 80 or 443 to the NSIP, but once the java administration applet has luanched connections will occur over 3010 for unsecure and 3008 for secured. Depending on whether you connected to HTTP or HTTPS initially will determine if the actual management connection is secured or not. NSIP 443,80 (TCP/HTTP) 3010, 3008 ,22 (TCP)

SmartAccess for XenApp with Access Gateway
XenApp Application List Authentication WI SSO Transaction Policy Evaluation Session Policy Expression Session Profile Client Security Check True policies get sent to XenApp as SmartAccess criteria Policy Name VServer Name XenApp filters by SmartAccess criteria Published Apps XenApp Policies The key aspect of Smart Access is the resulting session policy associated to the users session after its expression has been evaluated by the Gateway. After authentication is when the evaluation occurs, which can be based solely on the policy expression, or can include additional client security checks. The resulting policy name is sent to Web Interface along with the Virtual Server name to be applied as a smart access filter on a XenApp policy during the SSO transaction. This allows the administrator to tailor which of the full set of available applications is presented to the user when coming through the gateway. In this example, you can see that MS Word and Notepad are available, but what you can’t see, is that if this user had authenticated internally they would have had more applications such as financial or database apps. Once one of these apps is launched additional environment variables are tuned based on the resultant set of XenApp policies such as disallowing client drive mapping. In t

+ Denied Access Full Access Reduced Access Restricted Access
Global Access + All Applications & Virtual Channels Full Network Access Reduced Applications & Virtual Channels Restricted network Access SnR Security Remediation Web Site Denied Access Clientless Portal and Access Restricted Access Here is an example of providing different levels of access, based on the results of client security scans. Here, if the user doesn’t have Windows XP they are denied. Full access is given to PC’s with Prism, Symantec, a particluar registry key, and are running XP. Access is reduced as the users have fewer of these components.

Troubleshooting: Potential Issue Areas
External DMZ Internal XenApp + STA Problem Types: XML Settings/ STA Logging Authentication AGEE Smart Access NSIP Authorization STA SNIP or MIP WI 1- WI Site Settings 2- WI Trace 3- Event Log 1- Auth Svr Settings 2- NS Trace 3- aaad.debug STA path on WI VIP 1- Auth Settings 2- NS.log Remote End User LDAP/ LDAPS 1- ProfileSettings 2- NetScaler Trace Security Event Log on DC (LDAP or IAS) 1- NS Trace 2- STA Monitor (newnslog) nssslvpn.txt nssslvpn.txt ICA file - ID LDAP /LDAPS (TCP) - 389/636 DNS Ports and IP rules Ports and IP rules Ports and IP rules

Access Gateway Enterprise Edtion: Netscaler Integration

Netscaler Integration
Important Notes(Only for ICA Proxy Config and the sites do not have a point to point link to communicate with each other): Must use wildcard Cert on VPN Vip DNS Request from both Browser and ICA Client WI Sites must use unique fqds for their local VPN Vip in ICA File.

Potential Gotchas with ICA Proxy and GSLB
Host a wildcard certificate on the VPN VIP Configure each WI Server with a Unique FQDN for the VPN Virtual Server Must host 3 publicly resolvable Address Records: vpn.yourcompany.com site1.yourcompany.com site2.yourcompany.com NOTE!!! – Not an issue when running VPN Client

NetScaler

Problem: Typical Deployment without Citrix NetScaler
Audience participation maybe, ask them what problems they see in this diagram. Where are the points of failure? What would happen if one or both XML service stopped responding properly No alerting, service disruption What would happen if WI stopped responding properly or failed completely Total service disruption What would happen if this site failed Business disruption AGGREGATE NOTES: Only AGEE in this case No AGEE redundancy 3 Primary problems we can solve with NS Problem #1 -WI cant know if XML service is returning legitimate requests and does not provide alerting if XML service fails. Problem #2 - WI is a single point of failure, WI might not detect a node is down and provide HA Problem #3 - No site redundancy Problem #4 – No link redundancy

Aside from AGEE single point of failure, there are 4 Primary problems we can solve with NS Problem #1 -WI cant know if XML service is returning legitimate requests and does not provide alerting if XML service fails. 1. Web Interface does not provide intelligent XML service monitoring

Problem #2 - WI is a single point of failure, WI might not detect a node is down and provide HA 2. Web Interface is not redundant

Problem #3 - No site redundancy 3. No site redundancy

Problem #4 – No link redundancy 4. No link redundancy

Solution: Smart Monitoring
Solution to our first problem (No monitoring) is smart monitors. AGGREGATE NOTES: Proper monitoring is one of the first steps in establishing a resilient XenApp environment. Why? As we saw before, nothing was monitoring web interface intself and Web Interface doesn’t do any intelligent monitoring of the XML service No alerting if anything fails NetScaler provides monitoring beyond a simple ICMP PING, or a TCP port check Verify XML is properly enumerating specific applications and responding in a timely fashion. WHY IS THIS IMPORTANT? XML broker is responsible for user auth, application enumeration, and application launching. A failure here will render users unable to launch applications. XML can potentially be unstable, could result in a black hole. In this case the TCP port may still be responsive, but the XML service has failed. Verify WI is actually serving us a legitimate page Why IS THIS IMPORTANT? WI is the entry point to the environment. If we have a failure here, nobody can accesss the environment through this method

Proper monitoring is one of the first steps in establishing a resilient XenApp environment. Why? As we saw before, nothing was monitoring web interface itself and Web Interface doesn’t do any intelligent monitoring of the XML service No alerting if anything fails Monitoring provides alerting

NetScaler provides monitoring beyond a simple ICMP PING, or a TCP port check Verify XML is properly enumerating specific applications and responding in a timely fashion. WHY IS THIS IMPORTANT? * XML broker is responsible for user auth, application enumeration, and application launching. A failure here will render users unable to launch applications. * XML can potentially be unstable, could result in a black hole. In this case the TCP port may still be responsive, but the XML service has failed. Verify XML Service application enumeration and response time

Verify WI is actually serving us a legitimate page, not just listening on the socket Why IS THIS IMPORTANT? WI is the entry point to the environment. If we have a failure here, nobody can access the environment through this method Verify Web Interface is serving a legitimate response

Solution: High Availability
AGEE HA pair NetScaler HA pair WI now HA and LB XML now HA and LB XML Broker We will detect a totally failed WI and divert traffic We will detect a black holed WI and divert traffic Load balancing (common scenario: shift changes at the office where many users log in at once) Web Interface Detect if a WI server has failed and divert traffic Component High Availability and Load Balancing

XML Service We will detect a totally failed service and divert traffic We will detect a black holed service and divert traffic Load balancing (common scenario: shift changes at the office where many users log in at once) XML Service

Web Interface Detect if a WI server has failed and divert traffic Web Interface

Solution: Link Load Balancing
Achieved component level resiliency with smart monitors and high availability The focus now should be on the link to the internet and eliminate as a single point of failure Bandwidth isn't cheap, so we load balance the links as well as provide redundancy between them. Redundant ISP links

Solution: Business Continuity (GSLB)
As more apps are published, and more users access them the more critical the XenApp environment becomes to the business. In a typical case when a site fails, the admin might do a DNS change, or provide the users an alternate IP to use. Not automatic Cold site equipment is wasted Highly resilient deployment. Provides load balancing between sites, utilizing all of your equipment in an efficient manner. User simply requests an FQDN, NetScaler handles the rest. No change is made on the user side. Provides the BEST site for a user, not just an available site. Use LB methods to determine parameters for “best”. Tolerant of a failure at any layer (AGEE, NS, WI, XML, XA) Tolerant multiple failures in a single site Highly available and load balanced sites

What happens if there is a failure?
Now with a resilient solution, what will happen if components fail? AGGREGATE NOTES: XML broker black hole: NS detects the bad response and directs user traffic to an available server Web Interface failure: NS detects the failure and directs user traffic to an available server, avoiding a total outage. AGEE failure: AGEE is integrated in NS, as such if AGEE fails the NS will fail over to its HA partner and normal operation is continued NetScaler failure: NS is in an HA pair fails over to its HA partner and normal operation is continued Link failure: NetScaler routes traffic through the available link Data Center failure: NetScaler detects and communicates this information via MEP and directs users to an available site. © 2003 Citrix Systems, Inc.—All rights reserved.

Presentation Title Goes Here Insert Version Number Here What happens if there is a failure? Link failure: NetScaler routes traffic through the available link Internet Link © 2003 Citrix Systems, Inc.—All rights reserved.

TechEdge Survey & Posting of PPTs
If you complete the survey, you will be entered to win the $250 Amazon gift card.The winner will be announced May 29th TechEdge survey link: Link will also be ed to all attendees The TechEdge PPTs will be posted on the Knowledge Center by Tuesday, May 5th

Continue Your Learning
Authorized Citrix training is highly recommended as a next step to experiencing the full potential of your Citrix solution. Visit to view a complete list of course offerings and learn how to validate your technical skills with an industry-recognized Citrix Certification.

Welcome to TechEdge.

Similar presentations

Presentation on theme: "Welcome to TechEdge."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Welcome to TechEdge.

Similar presentations

Presentation on theme: "Welcome to TechEdge."— Presentation transcript:

Similar presentations

About project

Feedback