GuideIT High Level Consulting Framework
0 likes376 views
The document outlines essential best practices for implementing Citrix solutions, emphasizing the importance of prioritizing business applications over IT considerations. It details the steps in various phases including defining application requirements, assessing performance, designing the architecture, and deploying infrastructure, all of which require proper planning to avoid failures. The document stresses that successful Citrix deployment hinges on a thorough understanding of the application lifecycle and the involvement of key stakeholders throughout the process.
![I can only help if the customer is willing to follow Citrix best practices. Citrix is “top-of-stack” and
therefore agnostic of the underlying hypervisor. Most projects miss a key component regarding the
primary purpose of using Citrix. This one mistake does result in failure if not immediately but 3-6
months after implementation.
First is the “Define” phase. Here it is important to understand that Citrix is merely a “conduit” for the
business application. Meaning no hardware can or should be ordered prior to creating an application
lifecycle management framework. A preferred hardware vendor can [will] provide some hardware “on
loan” to create the application testing and remediation environment. This eliminates “putting the cart
before the horses”.
Citrix at best is a conduit for the business application. At worse it is a disaster that causes more help
tickets due to lack of planning and poor architecture. Citrix exists to deliver the business application so it
is more closely aligned with the “business” than IT.
The customer needs to understand that each application itself can take 2-4 weeks for initial packaging to
MSI (Microsoft Best Practice) (Terminal Server Best Practice) for deployment to XenApp 6.5 or 7.1. With
that said, Citrix AppDNA can streamline these processes down but final phase is the business application
owner must provide a power user to perform user acceptance testing on the application.
Assuming it pass all these tests, the application must undergo performance testing to make sure it does
not peg the XenApp server processor at 100% with 5 instances (happens every day). Any application
earmarked for Citrix must undergo this process. Citrix does not exist without the business application, I
cannot reiterate this enough.
During this phase, after application testing and remediation – then, and only then, can we create a BOM.
Never before. How do you create a BOM before you know whether or not the business applications will
work or how they will perform?
Most Citrix solutions tank in the first 6 months due to lack of focus on the "business application" side
and all IT centric. Not having an application remediation or approaching Citrix from a business value
add, not IT value add - is #1 issue IMO.
Define Phase
Define all applications earmarked for Citrix
- Define applications by Business Unit
- Define applications by COTS, Web, or Internal Development, Third Party Development
- Define list of application dependencies (Java Run Time and version, Flash, .NET Framework,
Oracle, SQL Client, ODBC, INI, ActiveX, Adobe Reader, Office Suite and Version, and so forth)
Define a small test environment of proposed hardware based on list of applications and number of users
- Complete list of applications required but does not determine final count for Citrix
- Define phase the total # of users refers to power users to test each application
- Business unit responsible for allocating users to UAT the applications pass all the Application
Lifecycle Management Framework tests to work in Citrix XenApp
Define solutions development framework for web and compiled applications that follow 2014 standards
and future requirements to develop software for 64 Bit Operating Systems and recent browser versions
Define initial hardware requirements for Citrix application testing and remediation
- Environment does not need to be exact match for proposed production](https://image.slidesharecdn.com/guideit-high-level-citrix-consult-framework-140222221146-phpapp01/85/GuideIT-High-Level-Consulting-Framework-1-320.jpg)
GuideIT High Level Consulting Framework
- 1. I can only help if the customer is willing to follow Citrix best practices. Citrix is “top-of-stack” and therefore agnostic of the underlying hypervisor. Most projects miss a key component regarding the primary purpose of using Citrix. This one mistake does result in failure if not immediately but 3-6 months after implementation. First is the “Define” phase. Here it is important to understand that Citrix is merely a “conduit” for the business application. Meaning no hardware can or should be ordered prior to creating an application lifecycle management framework. A preferred hardware vendor can [will] provide some hardware “on loan” to create the application testing and remediation environment. This eliminates “putting the cart before the horses”. Citrix at best is a conduit for the business application. At worse it is a disaster that causes more help tickets due to lack of planning and poor architecture. Citrix exists to deliver the business application so it is more closely aligned with the “business” than IT. The customer needs to understand that each application itself can take 2-4 weeks for initial packaging to MSI (Microsoft Best Practice) (Terminal Server Best Practice) for deployment to XenApp 6.5 or 7.1. With that said, Citrix AppDNA can streamline these processes down but final phase is the business application owner must provide a power user to perform user acceptance testing on the application. Assuming it pass all these tests, the application must undergo performance testing to make sure it does not peg the XenApp server processor at 100% with 5 instances (happens every day). Any application earmarked for Citrix must undergo this process. Citrix does not exist without the business application, I cannot reiterate this enough. During this phase, after application testing and remediation – then, and only then, can we create a BOM. Never before. How do you create a BOM before you know whether or not the business applications will work or how they will perform? Most Citrix solutions tank in the first 6 months due to lack of focus on the "business application" side and all IT centric. Not having an application remediation or approaching Citrix from a business value add, not IT value add - is #1 issue IMO. Define Phase Define all applications earmarked for Citrix - Define applications by Business Unit - Define applications by COTS, Web, or Internal Development, Third Party Development - Define list of application dependencies (Java Run Time and version, Flash, .NET Framework, Oracle, SQL Client, ODBC, INI, ActiveX, Adobe Reader, Office Suite and Version, and so forth) Define a small test environment of proposed hardware based on list of applications and number of users - Complete list of applications required but does not determine final count for Citrix - Define phase the total # of users refers to power users to test each application - Business unit responsible for allocating users to UAT the applications pass all the Application Lifecycle Management Framework tests to work in Citrix XenApp Define solutions development framework for web and compiled applications that follow 2014 standards and future requirements to develop software for 64 Bit Operating Systems and recent browser versions Define initial hardware requirements for Citrix application testing and remediation - Environment does not need to be exact match for proposed production
- 2. - Work with vendor to obtain “loaner” hardware post “Design Phase” Hardware should closely match proposed design for performance analysis reporting during “Assess Phase” Define initial storage requirements for physical hosts - SAN requiring HBA’s, dual HBA’s for HA - NAS Storage for MSI files or virtual applications Define networking requirements - Netscaler internal VIPs’ - Netscaler external (internet) VIPs’ - # of routable IPs’ - # of private IPs’ - Static IPs’ or DHCP IP’s, Subnets, Gateways - Use of ICA proxy Define priority of application migrations (low hanging fruit first) - Lease remediation steps - Smallest # of users - Quickest to package and deploy - Best performance results on 2008R2 64 Bit Define monitoring requirements - Prepare the monitoring team for future state - Define a list of monitoring requirements for proactive versus reactive monitoring - Most monitoring solutions are designed to provide a holistic monitoring of server uptime, processor, memory, network, and storage but not necessarily ability to interface with the Citrix native API to monitor Citrix Services, collect IMA specific data, Citrix user data, proactively monitor the ICA/HDX stack and services specific to each component o XenApp, XenDesktop, Provisioning Services, Netscaler Define Help Desk impact - To prevent Level 1 tickets from bypassing help desk straight to Tier 2 or 3 it is recommended to work with the Help Desk manager and provide information in the form of a Help Desk troubleshooting Guide that uses the Desktop Director or CMC tool provided to Help Desk for resetting sessions, logging off users, gathering data before transferring to Tier 2. - Offer to create a troubleshooting guide of problems that take 3-5 minutes or less to remediate. - Offer to train the help desk team per the schedule that the Help Desk Manager can arrange o The more you document and train, the quicker the end user obtains a “First hit ticket closure” versus information gathering session then ticket transfer to another queue o The more you document and train, the less tickets referred to Tier 2 and 3 therefore allowing Tier 2 to focus more on Administration and Tier 3 on Engineering responsibility Define application lifecycle and remediation framework - MSI packaging with DLL Conflict remediation or Virtual Application utilizing AppV or other Define application compatibility and UAT test environment - Define and build temporary environment utilizing proposed hardware solution - Define and build temporary infrastructure servers to allow for application performance testing o Post packaging or virtual application creation o Critical to determining application compliance and # of instances per XenApp is not an issue relative to the planned horizontal expansion (expand out not up) - Define requirements for each application and User Acceptance Testing o Obtain power user from each BU for each application to perform Application Functionality Testing and create a runbook with screen shots for every function tested
- 3. o Obtain signature for power user that tested per application Define Hypervisor Requirements - XenServer, free, supports XenDesktop VHD format native - Microsoft Hyper-v, free, supports XenDesktop VHD format native - Vmware ESX, requires VCenter, requires conversion from VHD to VMDK format o Other benefits relative to management tools such as VCenter, VCloud Suite Define Active Directory Requirements - Citrix Administrators Domain Local Group - Citrix Service Accounts if applicable - Adding subnets to Active Directory Sites and Services - Providing local domain controllers for every domain requiring authentication - Dedicated Citrix Organizational Unit Structure - Block inheritance at top of initial Citrix OU structure o Best practice, eliminates desktop logon scripts and other non-relevant policies - Creation of Group Policy Objects associated with XenApp, XenDesktop, Provisioning Server o Define required policies o Link GPOs’ to appropriate OUs’ under primary OU Define Site Checklist for remote sites - Document bandwidth of each remote site accessing Citrix new production - Define PC or Thin Client requirements - Define Citrix Receiver Versioning Requirements - Define minimum WAN requirements based on # of users per site with 20% growth rate factor - Define necessity for WAAS device at site o Define vendor; Cisco WAAS or Citrix Cloudbridge (examples) - Define minimum requirement of 100MB Full Switches at the site with devices hardcoded for 100 Full – again, this is minimum requirement - Define maximum latency allowance per WAN segment o Take baseline measurements of latency prior to adding ICA Traffic - Define holistic checklist comprised of input from Citrix team, Networking Team, and Desktop Engineering (See Example Spreadsheet provided) Assess Phase Assess application testing results - Assess timelines for applications that failed that can be remediated - Assess list of applications that are not candidates for Citrix, advise BU and recommend alternatives Assess application performance testing of applications meeting Citrix requirements - Provides the baseline for all functional applications meeting Citrix requirements o Utilized later to ascertain performance issues relative to baseline Assess use case scenarios and gather project requirements per BU - Assess XenApp published application to XenDesktop ratio and license requirement - Assess XenApp shared desktop ratio and license requirement - Assess leveraging Provisioning Server and total # of VDISKs for XenApp and VDI o Goal is least # of images (VDISKs) for XenApp or XenDesktop Assess XenApp and XenDesktop Policy Requirements - Printing policies (Universal Printing Driver) - Special policies by AD Group or Servers Assess user profile requirements based on # of users and preferred technology
- 4. - Roaming profiles Appsense for Roaming profiles Liquidware Profile Unity for Roaming Profiles Citrix Profile Manager Redirected folders Design Phase Design phase 100% dependent on Define and Assess Phase being completed Design the architecture: Scalability, local redundancy, high availability, disaster recovery Design physical hardware initial scale based on actual # of applications defined to be compatible with Design required number of Provisioning Servers required to host XenApp Virtual Servers Design required number of Provisioning Servers required to host XenDesktop sessions utilizing XenDesktop DDCs’ to manage images and Desktop Groups Design required # of dedicated XenDesktop Desktop Controllers required to host X number of required concurrent XenDesktops Design required # of dedicated XenApp Controllers for the farm versus Session Hosting Servers required to manage X number of maximum # of provisioned XenApp servers Citrix including performance testing analysis of each application Design operational processes required to implement architecture Design sustain processes required to maintain operational success Design monitoring infrastructure components for proactive versus reactive Design the hypervisor architecture for scalability, agility, local redundancy, high availability, disaster recovery, capacity management Design high availability for Citrix XML XenApp processes such as virtual or physical Netscaler VIPs’ with multiple servers defined in the XenApp XML VIP Design high availability for Citrix XML XenDesktop processes such as virtual or physical Netscaler VIPs’ with multiple servers defined in the XenDesktop (DDCs’) XML VIP Deploy Phase Deploy hardware, storage, and software infrastructure components Deploy Citrix ready applications per Define Phase Monitor Phase Monitoring the environment is critical. Utilizing existing monitoring tools or deploying Citrix specific monitoring tools Every component should be monitored for processor, memory, storage IO (LUNS or local), and service specific monitoring to each role: XenApp Controllers, XenApp hosting servers, XenDesktop Controllers, Hypervisor, WANS, core switches, top of rack or end of rack switches back to core (if used), VCenter, network cards (particularly on PVS), Netscalers, MPLS connections, dependency routers/switches/VPN equipment. Monitoring is generally handled by Tier-1 resources, generally referred to as Citrix Administrators with minimum CCA certification and 1-4 years’ experience. Brian Murphy