• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Citrix Application Management Framework
 

Citrix Application Management Framework

on

  • 588 views

Brian Murphy

Brian Murphy
101 E. Park Blvd, STE 711
Plano, TX 75074
(M) 214.476.4513
Brian.Murphy@guideit.com

Statistics

Views

Total Views
588
Views on SlideShare
588
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Citrix Application Management Framework Citrix Application Management Framework Document Transcript

    • Citrix Application Lifecycle Framework BY BRIAN MURPHY Page 1 of 46
    • TABLE OF CONTENTS SUMMARY .................................................................................................................................................................4 PHASE ONE ...............................................................................................................................................................5 THE DON’TS ..............................................................................................................................................................5 THE DO’S ..................................................................................................................................................................6 CORE COMPONENTS .................................................................................................................................................7 SERVICE LEVEL AGREEMENT GOALS ..........................................................................................................................7 IMMEDIATE GOALS .....................................................................................................................................................8 APPLICATION LIFECYCLE MANAGEMENT......................................................................................................................9 DEFINITION OF END USER EXPERIENCE (EUC) ........................................................................................................ 10 APPLICATION LIFECYCLE MANAGEMENT ........................................................................................................ 11 APPLICATION PACKAGING PROCESS FLOW DIAGRAM ............................................................................................... 12 APPLICATION PACKAGING ................................................................................................................................. 13 SETUP.EXE INSTALLATION FORMAT ......................................................................................................................... 13 VENDOR SUPPLIED MSI’S ....................................................................................................................................... 13 NO SETUP ROUTINE PROVIDED ............................................................................................................................... 13 STANDARDS AND PROCEDURES ....................................................................................................................... 14 GENERAL FUNDAMENTALS ...................................................................................................................................... 14 EXPLANATION OF ©W INDOWS INSTALLER FILE TYPES: ............................................................................................. 14 APPLICATION PACKAGE FOLDER ............................................................................................................................. 14 MERGE MODULES .................................................................................................................................................. 15 PATCHES ................................................................................................................................................................ 16 INTRODUCTION TO PATCH FILES .............................................................................................................................. 16 NAMING CONVENTION............................................................................................................................................. 17 Standardized Naming Schema for Patches ..................................................................................................... 17 Transforms (MST) and Features ...................................................................................................................... 17 APPLICATION DEPENDENCIES AND REQUIREMENTS .................................................................................................. 17 SRM APPLICATIONS ............................................................................................................................................... 17 MSI PROPERTIES ................................................................................................................................................... 18 PACKAGING AND SECURITY EXCEPTIONS ................................................................................................................. 18 Files and Directories ......................................................................................................................................... 18 File and Directory Permissions ......................................................................................................................... 19 Registry Permissions ........................................................................................................................................ 19 Files and Directories ......................................................................................................................................... 19 File System Permissions .................................................................................................................................. 19 Registry Permissions ........................................................................................................................................ 19 NAMING CONVENTIONS ....................................................................................................................................... 20 SAMPLE PACKAGE PROCESS ............................................................................................................................ 21 WISE PACKAGE STUDIO......................................................................................................................................... 21 Install ©WISE Package Studio ......................................................................................................................... 21 SetupCapture ................................................................................................................................................... 22 SOFTWARE INSTALLATION PROCESS .............................................................................................................. 28 PACKAGER’S CHECKLIST ................................................................................................................................... 42 Page 2 of 46
    • REFERENCED DOCUMENTS................................................................................................................................ 43 REFERENCED COPYRIGHTS ............................................................................................................................... 44 Reference Information ...................................................................................................................................... 44 DOCUMENT CONTROL SHEET ............................................................................................................................ 45 DOCUMENT NAME, LOCATION, AND OWNER ............................................................................................................. 45 CONTINUOUS IMPROVEMENT ................................................................................................................................... 45 DOCUMENT HISTORY .............................................................................................................................................. 45 DEFINITIONS .......................................................................................................................................................... 46 REFERENCES ......................................................................................................................................................... 46 Page 3 of 46
    • Summary Application Lifecycle Deployment of new applications, updates, and software patches is one of the most common – and important – functions of any Citrix hosting framework. This framework maintains the reliability and stability of the XenApp hosting tier while providing internal or external application developers a proven and repeatable process. This document defines a framework for a repeatable, successful, deployment process to properly package, QA, UAT, and future updates relative to deployment of business applications to Citrix. Properly preparing software packages for deployment across an organization is a complex process involving multiple steps, including repackaging, customization, impact assessment, QA and UAT. The software packaging process can become exponentially more complex as a company’s size increases, especially when the organization has multiple offices and software packaging centers across the globe. Application Lifecycle Management must be centralized and utilize a best practice framework for success. Otherwise, different teams follow ad hoc processes; the entire organization suffers. Problems include: Costly Deployment Catastrophes – Deploying a poorly prepared software package can erase important files required by mission-critical software, causing those software programs to fail. The resulting downtime can force company productivity to a halt, increase IT help desk costs, and – depending on the importance of the application – potentially cost the organization millions in lost revenue opportunities. Software Rollout Delays – Without a clear, orderly process in place for preparing an application for deployment, bottlenecks and packaging issues can take far too long to resolve and software rollouts can suffer lengthy delays. Inefficient or Overloaded Packagers – Citrix Management cannot obtain accurate global view of who in IT is working on what projects, so packaging assignments are often unevenly distributed. This means that projects that might have been completed right away - if properly assigned - are instead overlooked, assigned to the wrong packager, or stuck in QA or UAT; for example. Duplicated Packaging Efforts – Lack of having a centralized Application Lifecycle Management for Business Applications results in disparate packaging teams, duplicate work streams, potential for multiple strategies when a single cohesive packaging initiative is required for success and Center of Excellence. Lost Application Data – Data generated by the software packaging process is invaluable for improving the way, AIGGS manage, package, and update applications. However, if the entire process is not centrally managed – or if the data remains scattered in various spreadsheets, documents, and email communications – it isn’t available to the global Application Lifecycle Management Team preventing a Center of Excellence for Citrix Application Deployment. Page 4 of 38
    • Phase One Primary focus for phase one is proper architecture of XenApp 6.5 Feature Release 2 while in parallel a strategy for migration of legacy applications to the new infrastructure. Citrix is a conduit for the business application. Strategy is highly focused on the business application and compatibility with performance as pertinent and primary goals for the new architecture. Prior to migration, all applications must: 1. Create an inventory as it resides on the local Citrix server to include; a. Application name b. Application version c. Application contact(s) d. Application local dependencies i. Some applications require special fonts installed in C:WindowsFonts ii. Some applications require JRE – Java Run Time and specific versions 1. JRE 1.7 supported in new production iii. Some applications require ActiveX controls to run for printing or other purposes iv. Some applications require Oracle Client and corresponding ODBC and/or INI files v. Some applications require SQL Tools/Client installed with ODBC and/or INI files e. Application client dependencies i. Some applications require special fonts installed in C:WindowsFonts 2. Create an application matrix mapping from application to middleware to backend database The Don’ts               Not having an Application Lifecycle Management Plan – Application Center of Excellence Not leveraging MSI and Windows Installer Best Practices to create clean, pristine application(s) Not leveraging MSI and Windows Installer Best Practices to create clean, pristine application patches Not leveraging MSI and Windows Installer Best Practices to create clean, pristine new releases Not leveraging a centralized MSI application NAS or SMB share repository Not testing the applications first before ordering hardware or architecture of Citrix Not analysing application usage patterns before ordering hardware or architecture of Citrix Not using ©Citrix XenApp 6.5 Feature Pack 2 to host your applications o Versus hosting in a virtual operating system aka virtual operating system (VDI/VOS) Not using ©Citrix Provisioning Services to host a single read-only XenApp VDISK images o Cost save o Agility o Scale out not up o Dynamic capacity at demand Not installing applications, AV, inventory agents in read-only XenApp Dynamic VDISKs o Cost save o Image is read-only, streamed, memory and write-cache disk only o Reality – no longer a typical server; read-only  One image to update, applications only, huge cost savings on agents Not installing anything other than ©Citrix Universal Receiver Not using ©Citrix AppDNA for MSI Packaging analysis and remediation steps o Streamlines application migrations from legacy platforms Not using qualified packagers for Citrix / RDS environment o Standard desktop packaging does not apply to multi-user RDS/Citrix Not providing adequate workstations, tools, and software for packagers o Tools combined with expertise equals success otherwise failure Page 5 of 38
    • o Packaging applications utilize software such as DellWyse Packaging Studio with Conflict Analysis is critical to stabilize the applications and future deployments of patches and new releases The Do’s                Do create MSI databases with files extrapolated to a centralized share Do import those MSI databases into a conflict analysis repository Do utilize Wyse Package Studio Do utilize packagers with expert knowledge of MSI packaging as it pertains to: o Windows Installer Service 5.0 (Windows Server 2008 R2) o Packaging for Remote Desktop Services in Microsoft Server 2008 R2 o Packaging for Citrix XenApp 6.5 / 7.0 / 7.1 / 7.X o Do utilize merge modules, triggers, coding where applicable Do have a goal of 90% of applications packaged o 5% network hosted o 5% streamed to XenApp such as Microsoft App-V where applicable Do centralize application packages to one share Do run Citrix AppDNA against the MSI packages for QA o Produces list of Citrix specific remediation steps Do create a list of “low hanging fruit” based on AppDNA results  Do convert the users with the largest # of low hanging fruit first Do analyse every remote site after applications o # of users per site o # of users per site on shift differentials o # of time zones domestic and abroad Do analyse bandwidth per site o Consolidation has many benefits most of all the reduction of CIR rates per site equates to monthly OPEX cost saves Do analyse telecom per site o Telecom can be consolidated using ©Citrix XenApp 6.5 Feature Pack 2 and hosting the Cisco or Avaya Softphone in XenApp 6.5 Feature Pack 2 – Been there and done it. Do analyse license usage per application and look for concurrent cost saves by hosting the application in XenApp 6.5 Feature Pack 2 and hard coding usage based on worldwide usage patterns reducing the need for: o COTS applications o Any concurrent license or non-named user license o SQL licensing if not processor based o Remote Desktop CALs’ o ©Citrix CALs’ o List goes on – many cost saves to be had by centralizing everything Do leverage ©Citrix Branch Repeater for better WAN performance and possibly further reduction in CIR rates or bandwidth per site. Do leverage ©Citrix Cloud Bridge for B2B connections (versus high cost private circuits). Do leverage ©Citrix Netscaler with Content Switch and wild card certificates o Combined with Insight for Netscaler – web and HDX o Enable AppFlow on Netscaler to Insight devices The intent of this document is to expose one of the most egregious errors when implementing XenApp 6.5 Feature Pack 2 (Published Application). Published Applications create agility and efficiency for IT Operations, Help Desk and most important – end users. All is lost without a defined “Application Lifecycle Management” or “Center Of Excellence” for application packaging, ongoing updates, patches, new releases. Published Application is merely a conduit for the business application and ultimately a way for all users to access their business applications needed to perform their jobs. Published Application allows users to do this from any device, from any location, and any time. The experience made consistent across device(s) utilizing: 1. ©Citrix Universal Receiver 4.X, 5.X, X.X 2. ©Citrix Storefront 2.X, 3.X, X.X Page 6 of 38
    • Next, the #1 reason why most implementations fail is “Application Lifecycle Management”. You never buy hardware [other than proof of concept] [called “just enough”] prior to application validation in the new XenApp 6.5 Feature Pack 2 environment. Published Application is a “conduit for the business application”. The goal is to make the business application available from anywhere, anytime, on any device. The core components consist of: Core Components 1. ©Citrix XenApp 6.5 Feature Pack 2 2. ©Citrix Provisioning Services 3. ©Citrix Netscaler Access Gateway 10.x a. ©Citrix AppFlow for Insight enabled 4. ©Citrix Insight 10.x 5. ©Citrix EdgeSight 5.4 for XenApp 6.5 Feature Pack 2 6. ©Citrix Director 2.1 for XenApp 6.5 Feature Pack 2 a. Insight and EdgeSight data now integrate direct to Director Console 7. ©Citrix Cloud Bridge 7.1 (formerly Branch Repeater) a. By default accelerate ICA/HDX traffic across Wide Area Networks addressing both high latency and lower bandwidth constraints 8. ©Citrix AppDNA 7.0 9. ©Citrix Storefront 2.1 10. ©Citrix Merchandising Server 2.2 11. ©Citrix Licensing Server 11.11.1 12. ©Citrix Provisioning Services 6.1.x 13. ©Liquidware Profile Unity or ©Appsense 14. ©Vmware ESX Hypervisor 15. ©Microsoft SQL 2008R2 SP1 running on Server 2008R2 SP1 Enterprise Edition, 2-node Cluster 16. ©Wyse Package Studio with Conflict Analysis Module (SQL Backend) Service Level Agreement Goals 1. ©Citrix XenApp 6.5 Feature Pack 2: 10 second < logon 2. Two (2) tickets per 8000 concurrent users 3. ©Citrix Provisioning Services 6.1.1/7.1 Virtual OS: 15 IOPs’ or less with read-only single VDISK a. This advantage Provisioning Services to stream instances of single VDISK from NAS shared drive or NFS shared drive leveraged by Provisioning Services 6.1.x. 4. ©Citrix XenApp 6.5 Feature Pack 2 average of 50,000 IOPs’ per 2200 applications a. This alone should convince you that leveraging ©Citrix XenApp 6.5 Feature Pack 2 on 2008R2 and beyond [2012 to 2XXX) RDS/RDP server is the only way to host your applications b. Assumption is 90% are MSI packages, installed silent mode c. Assumption 5% are network applications hosted on NAS, CIFS, or SMB share d. Assumption 5% are “streamed applications” – updating MSI packages done correctly is far easier than streaming applications. 5. The goal, as indicated above, is packaging to MSI so that applications can utilize Microsoft Windows Installer Service. MSI packaging is Best Practice. ©Citrix implemented properly saves money in the following areas;  ROI  TCO  CAPEX  OPEX Page 7 of 38
    • Understanding that my recommendations should be utilized for deploying applications to Windows Server OS running Remote Desktop Services [formerly Terminal Services] (RDS) running ©Citrix XenApp 6.5 Feature Pack 2 (formerly Presentation Server, Metaframe, Winframe). The standards based on Microsoft Windows Installer Technology (also referred to as “MSI”). With that said, the names of ©Citrix XenApp 6.5 Feature Pack 2, Provisioning Services, and Remote Desktop Services, et cetera are destined to change at some point in the future. Please consider these placeholders only as I will provide a definitions summary as to the purpose each technology at the end of this document. Immediate Goals           Proven, Citrix solutions architecture with repeatable processes relative to virtual hosted applications, architecture, Application Lifecycle Management (Application Center of Excellence) , hardware refresh lifecycles, operations training and documentation, Help Desk training and documentation Iron clad agreements with Change Management and Help Desk relative to UAT, run book, and ticket queue priority assignments Customer inspired unique authentication design allowing for customized Published Application using on template for the entire company yet ability for customer to choose logon banners, drastic reduction of logon scripts required for applications by moving this and other logic to the published application, drastic reduction of network aggregate bandwidth requirements per site and working with third-party vendor before and after to determine CIR adjustments where monthly costs for bandwidth has become the most beneficial OPEX savings for some companies Emphasis on EUC satisfaction in the production solution is critical and most important in all implementations closely followed by a paradigm impact to all internal IT teams where the focus is making life easier for IT services at the happiness of end-users Operations, Windows Server Team, Desktop Support, Help Desk, Storage, Networking, Firewall Team, and Change Management, efficiency impacts for business units requesting access to business applications and IT Security Fulfilment or HR o Depends on which tower does the security fulfilment In some cases, with the goal being streamline the entire procurement process by focusing on the Corporate Business Applications, proven repeatable process for migration of all COTS, internal developed, external developed, direct vendor managed, basically having a strategy that addresses the consolidation of all business applications to a centralized location regardless of the number of applications; hence, the term repeatable in practical use is relative whether 300 or 3000 applications – it just works and leveraging published application best practices combined with Application Lifecycle Management (ALM) is what guarantees previous experienced success The unique design, combined with a proven project plan, dynamic capacity, maximum utilization of underlying hosts (goal 200%), workflows, escalation paths, application lifecycle proprietary process including custom agreements with Help Desk management and Change Control management team approvals new process is immediately implemented with a customized letter sent to all Business Unit management to emphasize the critical role of allocating 1 to 3 power user UAT resources whereby user is shadowed during UAT to assist with creating of application run books which helps shift priority of success relative to new production applications working in a shared virtual cloud; therefore, preventing end users from pointing the finger immediately at the new solution when evidence is provided showing the power user did not UAT that report or that query after review of the run book Citrix AppDNA does expedite application migrations and set the standard for “Application Lifecycle Management” analysis with remediation steps. AppDNA run against a network share hosting MSI packages. It assigns a # by weight of how many remediation steps are required and lists those remediation steps. A score of one is considered “low hanging fruit” and five is where having the best packagers is required Relative to my reasons for stating ©Citrix as my preferred vendor for virtualization, virtual desktop and server, and all the top layer tools to ascertain application viability, followed by remediation steps, the tools to find these remediation steps and reduce migration of applications by 50% or greater. All the components required at the delivery stack including login GUI, support for any authentication model, Global Load Balancing, Routing by Proximity, Client NAP with DMZ ability, SSL VPN with split tunnel and split DNS, Content Switch, SSL compression, application layer 7, 4-tiered Firewall and specific QOS between sites for better application performance prior to ICA delivery. Page 8 of 38
    •       Hardware, software, and process level monitoring tools with elite custom reporting. Including in-depth HDX and Web utilizing Insight for Netscaler and enabling AppFlow. Elite custom proactive monitoring with automated remediation steps, alerts, and built in workflow for adhering to change management procedures. True support for any device such as; phones (iPhone, IPad, and newer IOS’s coming soon, laptops, zero clients, thin-clients, desktops of any vendor, any software client such as the various Linux builds such as Debian (becoming popular), any IOS, to Open BSD, Macintosh, and all versions of Windows. With HDX, ability to create SaaS Desktops for purpose of running Internet only applications to high end virtual TV’s for watching videos on Amazon Instant Video, Amazon Prime, Netflix, intranet training, live video, video-ondemand, investor relation video for internal employees and so forth Support for call-center telephony software, customer service chat for banks and other organizations, support for Skype Video, Google Voice and Video, Microsoft Lync with Video plug-in, Video conferencing, Cisco IP Soft Phone, and Avaya Softphone You can purchase the software and tools herein but what matters most is the depth of knowledge of your packager or packaging team. Spare no expense, they specialize in packaging for RDS/Citrix environments and should be paid accordingly o Packaging applications utilize software such as DellWyse Packaging Studio with Conflict Analysis is critical to stabilize the applications and future deployments of patches and new releases Application Lifecycle Management One of the main objectives of these standards is to guarantee consistency across the organization. A package fulfilling the requirements set down in these guidelines and the Windows Installer SDK should automatically be consistent with Windows Server and Windows Client by simply utilizing the appropriate MST and therefore easy to deploy. Requirements:  Windows Installer (MSI)  Windows Client OS – Windows 7  Windows Server OS – Server 2008 R2 running Remote Desktop Services  Altiris Package Studio  ©Citrix XenApp 6.5 Feature Pack 2 - multi-user environment utilizing published applications  ©Citrix XenApp 6.5 Feature Pack 2 – leveraging read only desktops that obtain the published application from the XenApp 6.5 Feature Pack 2 solution The following processes implemented as pre-requisites:  WISE Package Studio is the preferred tool or a reputable tool that performs some of the same functionality such as loading the meta-data into SQL database on every MSI package for conflict analysis reporting  High-end workstation for hosting VMWare Workstation and hosting the binaries, images, snaps, and users connecting for UAT. This is one option is most efficient when there are a small group of packagers they can have up to four VM’s running and everything is maintained and managed by each packager.  The second option is providing a “Packaging” instance of XenApp 6.5 Feature Pack 2 or XenApp 6.5 Feature Pack 2. The packager must package to the environment where the application will reside. If the MSI installs on XenApp 6.5 Feature Pack 2 then the VM must match the current OS for the XenApp 6.5 Feature Pack 2 farm.  VMWare Workstation or Oracle Box (Free) utilized for packaging, QA, and testing in order to reduce rebuild time. VMWare/Oracle rebuilds done instantaneously by simply powering off the virtual machine and choosing to revert to the clean build.  Oracle Box seems equally as stable yet is free of charge. Simply Google “Oracle Box Free Download”. It allows you to create Published Application in several flavours.  Conflict Analysis  AppDNA remediation steps  Some of these you will find can be fixed with a prefix script with all the variables or “reg add” or path statements and so forth  Then simply host the prefix script on your NFS/CIFS/SMB share and the publish application points to the .cmd, .bat, .vbs scripts. Business Applications + Application Lifecycle Management advantages the following:  Leverage Windows Installer Server to create best practice MSI packages Page 9 of 38
    •               Wyse Packager + Wyse Conflict Analysis and DLL Remediation ©Citrix AppDNA application analysis for Published Application with 1 to 5 rating and application specific remediation steps to resolve application working in ©Citrix XenApp 6.5 Feature Pack 2 Low hanging fruit identified by AppDNA – remediation steps to production ready MSI packages Master packaging team dedicated to multi-user application packaging Full customer UAT by power user Packager and power user working together while packager takes screenshot of every function User signs off on the new “run book” for each application tested Iron clad agreement with Change management & Help Desk stating user cannot open Severity 1 or 2 ticket for anything not UATd’ post implementation of new install to production Creation of run-book for each application during UAT and screen capture for Help Desk and Change Management and Customer Reference Policy stating naming standards for packages Windows Installer Service creates a GUID for each new package, that GUID is tied to the patch (MSP) or version aka clean uninstall and new install which is fully automated by Windows Installer Service by capturing new package and new GUID associated to old GUID and trigger to perform clean uninstall Document when to patch, policy that everything is patched as MSI/MSP and documented whether single dll or regkey change That GUID is associated to the primary GUID; and, using triggers create workflow install and dependency installs. o In other words, you can have prerequisites so if this GUID (appA) does not exist it installs App A first, then appB, then AppB1 regkey change Published Application influences all of IT. Every team in IT must cooperate or management must be prepared to offer choices. Definition of End User Experience (EUC) “Real” End User Experience is defined by the three primary components that dynamically interact to constantly impact how End Users experience IT Services in real-time:    Physical, Virtual Application, Virtual Desktop OS, Streamed Desktop OS,and Mobile Device Performance – Storage, Event Log, Hung Processes, Application Crashes and Blue Screens of Death, WMI, Top Resource Consumers, Network Read/ Write, Boot and Logon Profiling, Hypervisor, Remote File Share, Battery, Wi-Fi and Cellular Network Application Performance – Latency, response time and “key-to-glass” transaction time for user workflows across any application, e.g., HTTP(s), RIA/AJAX, Thick Client, .NET, WPF, Native iOS and Android apps, Citrix ICA/HDX, Vmware PCoIP and Microsoft RDP User Productivity – Application, module and business function usage statistics, e.g. trades executed, calls closed, emails sent, invoices created, etc. including usage trail, execution time and time spent. Page 10 of 38
    • Application Lifecycle Management This document should be referred in conjunction with the Microsoft Windows Installer SDK. The SDK contains a wealth of detailed information and guidelines which this document does not duplicate. As a general principle, anything written in the SDK is valid in terms of packaging standards and procedures. The basic idea behind this is to make MSI packages portable and easy to support. One of the main objectives of these standards is to guarantee consistency across the organization. A package fulfilling the requirements set down in these guidelines and the Windows Installer SDK should automatically be consistent with Windows Server and Windows Client by simply utilizing the appropriate MST and therefore easy to deploy. It is assumed that the reader is technically proficient in the following areas;  Windows Installer (MSI)  Windows Client OS – Windows XP and Windows 7  Altiris Package Studio  ©Citrix XenApp - multi-user environment utilizing published applications  ©Citrix XenDesktop – leveraging read only desktops that obtain the published application from the XenApp solution In order for this process to be used, the following processes should be implemented as pre-requisites:  WISE Package Studio is the preferred tool or a reputable tool that performs some of the same functionality such as loading the meta-data into SQL database on every MSI package for conflict analysis reporting  High end workstation for hosting VMWare Workstation and hosting the binaries, images, snaps, and users connecting for UAT. This is one option and generally the fastest when there are a small group of packagers they can have up to 4 VM’s running and everything is maintained and managed by each packager.  The second option is providing a “Packaging” instance of XenApp or XenDesktop. The packager must package to the environment where the application will reside. If the MSI installs on XenApp then the VM must match the current OS for the XenApp farm.  VMWare Workstation can be used for packaging, QA, and testing in order to reduce rebuild time. VMWare rebuilds are done instantaneously by simply powering off the virtual machine and choosing to revert to the clean build.  Oracle Box seems equally as stable yet is free of charge. Simply Google “Oracle Box Free Download”. It allows you to create VOSSKS in several flavours.  Conflict Analysis  AppDNA remediation steps  Some of these you will find can be fixed with a prefix script with all the variables or “reg add” or path statements and so forth  Then simply host the prefix script on your NFS/CIFS/SMB share and the publish application points to the .cmd, .bat, .vbs scripts. Business Applications + Application Lifecycle Management leverages the following:  Leverage Windows Installer Server to create best practice MSI packages  Wyse Packager + Wyse Conflict Analysis and DLL Remediation  ©Citrix AppDNA application analysis for VOS with 1 to 5 rating and application specific remediation steps to resolve application working in ©Citrix XenApp  Low hanging fruit identified by AppDNA – remediation steps to production ready MSI packages  Master packaging team dedicated to multi-user application packaging  Full customer UAT by power user  Packager and power user working together while packager takes screenshot of every function  User signs off on the new “run book” for each application tested  Iron clad agreement with Change management & Help Desk stating user cannot open Severity 1 or 2 ticket for anything not UATd’ post implementation of new install to production  Creation of run-book for each application during UAT and screen capture for Help Desk and Change Management and Customer Reference Page 11 of 38
    •     Policy stating naming standards for packages Windows Installer Service creates a GUID for each new package, that GUID is tied to the patch (MSP) or version aka clean uninstall and new install which is fully automated by Windows Installer Service by capturing new package and new GUID associated to old GUID and trigger to perform clean uninstall Document when to patch, policy that everything is patched as MSI/MSP and documented whether single dll or regkey change That GUID is associated to the primary GUID and using triggers create workflow install and dependency installs. o In other words, you can have prerequisites so if this GUID (appA) does not exist it installs App A first, then appB, then AppB1 regkey change VOS impacts all of IT. Every team in IT must cooperate or management must be prepared to offer choices. Application Packaging Process Flow Diagram Packaging request is processed and assigned Packaging Process Pass Self Test? Yes UAT No No Yes Pass UAT? QA Yes No Pass QA? Page 12 of 38 Deployment
    • Application Packaging All packages should include a Microsoft ©Word document, based on the ‘Application Package Template’. This document is created by the packager when finished packaging an application. It will contain the following information:               Application Name Version Packager Details (Name and Contact Number) Date MSI Details (Product, Package and Upgrade Codes) Installation Instructions Technical Information Special Instructions to Deployment Team (if any) Dependency Information SQL.INI, TNSNAMES.ORA Strings (if any) ODBC information (if any) Useful Contacts ©Citrix Deployment Info (if needed) Verification Script Any section of the application package documentation that is left intentionally blank should be marked “N/A or None”. Once the document is complete it should be reviewed and edited as required. Setup.exe Installation Format This is where the installation source is provided by running a setup routine in a non-MSI format. Use ©Wise Setup Capture and related tools to capture changes to the workstation. Vendor Supplied MSI’s It is preferred to use vendor-supplied MSI’s. However, there are cases where this creates problems due to custom actions and poorly scripted MSI’s, etc. A snapshot of the MSI will be allowed, dependent on the integrator to decide on the most suitable option. No Setup Routine Provided This can occur where the application is a set of files to be placed in a single directory or just an ODBC entry with few registry keys. In such cases, create a new installation from within ©Wise or use ©Wise Setup Capture and related tools to build the package. Page 13 of 38
    • Standards and Procedures General Fundamentals                  All ©Windows Installer file types are supported (MSI, MSP, MST and MSM). Variables (©Windows Installer or System) will be used to support single integrations. No hard coded settings will be included in any package. There will be one MSI file per package. Multiple MSI files per package are not permitted. An application that requires several MSI files must be packaged using several packages. Nested installations of MSI files are not permitted (i.e. one MSI file cannot call another). All packages must support silent installation Suppress Reboot on Installation. If Reboot is required, it must be listed in the QA Exceptions section of Application Document. All packages should be thin MSI’s with external support files. All Developer packages should be packaged to same standards as end-user packages excluding rights issues. Where VB Script Custom Actions are required, the code must be viewable and editable within the ©Wise Package Studio tool. Clean uninstallation of packages is required and must be tested prior to production deployment. MST’s packaged against a vendor MSI should be considered a package, MST’s packaged against a produced MSI should be considered Localisation. Transforms must be delivered under the same folder as the MSI file. Automatic updates of applications from the Internet are forbidden. It is not permitted to specify IP addresses anywhere in the package. The DNS representative value of the IP address should be entered instead. If any of the standards in this standards document are not followed, an exception request should be made. Explanation of ©Windows Installer File Types: File Extension Description MSI The ©Windows Installer database file MST The ©Windows Installer transform file (applied to an MSI file) MSP The ©Windows Installer patch file (used to patch an MSI installation) MSM The ©Windows Installer merge module file (merged into an MSI file) Application Package Folder All package folders should contain the following:  MSI file  MST file (if applicable)  Application Packaging Document  Supporting Files Page 14 of 38
    • Merge Modules Merge modules are pre-compiled libraries of components (files, registry changes, and other system changes) that install a discrete portion of your application. They cannot be run alone, but must be merged with a ©Windows Installer database (MSI file). Merge modules give you flexibility in developing installations because you can break the installation of your application into logical chunks and share merge modules between projects. With ©Wise for ©Windows Installer the selection of a module to include in your installation is automatic. If your application uses a resource that is included in a merge module a dialog box will appear asking you if you would like to include the merge module with your application. Choose “yes” whenever this option is given. The module plus any dependent modules are automatically integrated with your MSI file. All table entries etc. will automatically be updated with the module specific information. The ©Wise database of merge modules should be the trusted source of Vendor-supplied merge modules approved for Application Packaging and will be updated on a weekly basis. It is recommended that all sites should use the same merge modules to maintain consistency. To download the latest Merge Modules, go to: www.wise.com Page 15 of 38
    • Patches Introduction to Patch Files Patches provide the ©Windows Installer Service with a mechanism for implementing upgrades of installed applications. These applications, of course, must have been installed by the Installer Service originally. Patches are represented as .MSP files and represent the difference between the MSI presently installed (through the old package) and the upgraded MSI file (through the new package). Based on what changes we are making to the package, we can categorize patches as Small Updates, Minor Upgrades and Major Upgrades. The below table compares the differences: Type of update Product code Product Version Description Small Update No change No change An update to one or two files that is too small to warrant changing the Product Version. The package code in the Revision Number Summary Property does change. Can be shipped as a full installation package or as a patch package. Minor Upgrade No change Changed A small update making changes significant enough to warrant changing the Product Version property. Can be shipped as a full installation package or as a patch package. Major Upgrades Changed Changed A comprehensive update of the product warranting a change in the Product Code property. Shipped as a patch package or as a full product installation package. If an update changes .msi file and application files, but does not change the Product Code property or Product Version property, it is termed a small update. If an update changes the Product Version, but does not change the Product Code, it is termed a minor upgrade. If the update changes the installation into an entirely different product, the Product Code must change and the update is termed a major upgrade. It is a good practice to adopt a standardized naming schema for Patches that are created and distributed by the Windows System Engineering AI (Application Integration) team. Page 16 of 38
    • Naming Convention    Create consistency across all ©Windows Installer Patch files that are deployed across the firm. Easily recognize the LOB application to which a specific patch is applied to. To maintain a systematic inventory of all applications and patches. Standardized Naming Schema for Patches AppName-VersionNumber-PVersionNumber.MSP MyCompany: Company Info for inventory purposes AppName: Application Name as it was used in the original MSI. VersionNumber: Original version P: Represents a Patch file VersionNumber: The new version number being assigned through patch. Appname-606-P607.MSP Scenario 1: If this is a small update with one or two files, no changes in Product Code and ProductVersion are necessary. And the patch file will be named as below. Appname-606-P606.MSP Scenario 2: If this is a minor upgrade with a significant change in installation, like EXE, and dll changes, we will change the Product Version but Product Code will still remain same. Appname-606-P607.MSP Scenario 3: For major upgrades, whole new package will be created with new ProductCode and new Product Version which will uninstall the application with older version. Transforms (MST) and Features       Transforms are files with MST extension that are applied to an MSI file at install time. An MST will deliver any informational and configuration changes that are required for the package. Transforms are not permitted to change the “ProductVersion” A transform cannot be uninstalled, replaced or added without uninstalling the entire application. Transforms cannot contain the same resources as MSI file. All requested changes to vendor packages should be delivered by a Transform. Features - The common standard is to use “Complete” feature which is also part of the default ©WISE template. However, additional Features may be used and the option is left to the packager as to the best choice. Features should be explicitly enabled and disabled by specifying the ADDLOCAL and REMOVE MSI properties respectively. This should be specified on the “msiexec” command line. Application Dependencies and Requirements Applications with particular system requirements (e.g. disk space, memory size, install software, etc) should have these requirements checked and built in to the MSI package. Additionally all dependencies should appear in the welcome dialog. All SRM’s required by an application must be detailed within the MSI’s welcome dialogue box. SRM Applications Examples for Shared Runtime Module (SRM) applications are:  MyCompany-Oracle-Client-10g-SRM  MyCompany-Sybase-PC-Client-12-5-SRM  How to use SRM Applications  All the SRM applications are used as dependencies for LOB [Line Of Business] applications. No LOB application package should have files that belong to 38 SRM. any Page 17 of
    •    For example, when APPA1.exe is installed, the install routine also copies files Crystal Reports 10. In such case, Crystal Reports 10 must be packaged separately as an SRM and should be called as a dependency for APPPA1. Each SRM must be packaged to allow support for multiple versions. The names of package folder, MSI, and Application Package doc will have SRM at the end. (for e.g., MyCompany-Sybase-PC-Client-12-5-SRM) MSI Properties Packagers should make use of the predefined MSI property values as much as possible. This particularly includes, for example, the list of properties given in the ©Windows Installer SDK under the heading “System Folder Properties”. Using such properties makes packages portable and robust. Fortunately WFWI tends to make use of these properties automatically as required. Default ©WISE template has the following properties set: Property Value Description ALLUSERS 2 “Per-machine” installation must be supported. Most software installation will be performed with Administrator level security credentials thus ensuring “per-machine” installation. INSTALLTIME 10 Packager can right click it and select Details to amend the value field to the estimated time (mins) for installation – the default is 10 minutes. REBOOT Really Suppress Req1 None Req2 None Does not allow MsiExec.EXE to cause a reboot. If required, the software distribution mechanism handles reboots. Packager should use this value to mention “dependency” information. If there is only one dependency, then “Req2” and “Req3” properties can be deleted. Default is “None” -------Same as above----- Req3 None -------Same as above----- Packaging and Security Exceptions The Application Packager will attempt to package each application to the defined standards. If they are unable to package the application to standards and have it function properly, they have been permitted within limits, to have acceptable deviations from the standard provided these deviations are well documented in the Application Packaging Document. The following are examples of exceptions they have been pre-approved for: Files and Directories    Files located in C:WindowsSystem32Drivers Files located in C:WindowsSystem32Fonts Apps requiring Files in more than one directory under C:Program Files - e.g.: Additional Files located in C:Program FilesCommon Files Page 18 of 38
    •  Add additional rights to directories from within the MSI – the rights should be added to the ‘everyone’ group. File and Directory Permissions   Allowed to grant write permissions on files e.g.: C:Program FilesAppmyfile.ext Allowed to grant write permissions on folders e.g.: C:Program FilesAppLogs Registry Permissions              Allowed to grant write permissions to the User Group to registry keys of the packaged application eg: HKLMSoftwareMyApp Allowed to grant write permissions to the User Group to registry values and data of the packaged application e.g.: HKLMSoftwareMyAppSetting1 | mydata Setting Security on a Registry Value in a Package: Select “Installation Expert” Tab Select “Registry” in the Feature Details section on the left. Select the desired feature (normally “Complete”) from the “Current Feature” dropdown box. In the lower left hand pane, expand the registry tree display as needed and navigate to the desired registry key. (Note that if the desired key does not exist, it can be located in the upper left hand pane and dragged and dropped to the lower left pane) Right click the value to be operated on from the lower right pane then click “Details”. (Note that if the desired value does not exist, it can be navigated to in the upper left and right hand panes and dragged and dropped to the lower right pane) Select the “Permissions” Tab Leave the “Domain” box empty and enter “Everyone” in the Box labelled “User”. Check the boxes by the permissions you require on the file. Click “Add” Setting Security Permissions for a Registry value inside a Package is now complete. Note: Though the packagers are allowed to make certain exceptions mentioned above, they have been given limits on how far they can deviate from standards. For some standards there are hard and fast rules that may not be deviated from. The following is a list of standard items AI packagers cannot violate during the packaging process. These deviations need prior approval from the senior level Management. Files and Directories     Not allowed to write files located in other directories to enable the application to function e.g.: C: Must document files located in C:Windows Must document files located in C:WindowsSystem Must document files located in C:WindowsSystem32 File System Permissions      Not allow to grant write permissions to the User Group to the root of C: directory Not allow to grant write permissions to the User Group to the root of C:Windows and its’ children directories Not allow to grant write permissions to the User Group to the C:Program Files directory Not allow to grant write permissions to the User Group to the C:Program FilesCommon Files directory Not allowed to grant write permissions on files under C:Windows directory. Registry Permissions   Not allowed to grant write permissions to the User Group to any root hive Not allowed to grant write permissions to the User Group to HKLMSoftware. Page 19 of 38
    • Naming Conventions Name Package Folder Description Name of the package folder. This will have the same name as MSI. Examples MyCompany-MyApp-6-6 MSI Name of the MSI file, if not vendor provided. Every MSI name should contain the name of the app and version number. The name should start with MyCompany. MyCompany-MyApp-6-6.msi MST Name of the MST file. If the MSI is vendor provided, use this name as the base for all other names in this section. MyCompany-MyApp-6-6.mst MyCompany-MyApp-6-6.msi Multiple MSTs should be named to indicate the purpose of each MST. Name of the Application Package doc Destination Directory Name of the AP document provided with the application package. For SRM packages, document’s name will have SRM at the end. Capture the default directory the install routine creates. No version number required. MyCompany-MyApp-6-6.doc MyCompany-Oracle-Client-10gSRM.doc C:ProdMyAppsMyApp C:Program FilesMyApp Note: Some 32 bit applications should be installed in a short-name directory such as C:Prod being default it would go to (x86) directory on 64 bit and some applications cannot “read” this type of path statement. Add/Remove programs in Control Panel Only admin users will see this. The name appearing in the Add/Remove control panel is the name specified in the Product Details of the MSI. The name should be based on the MSI file name including the version and Release number (but without the '-'s). Page 20 of 38 MyCompany MyApp 6.6
    • Sample Package Process WISE Package Studio This section is a sample only of a generic package preparation. These steps will be performed by Windows Systems Engineering to prepare the application package for testing and deployment. Install ©WISE Package Studio    Map network drive Y: to Wise Share Point Make sure to have the latest "WISE Template" in "Y:Wise Share PointTemplates" folder 'Default Merge Modules Directory' is set to Y:Merge Modules as below ©Wise Package Studio – Merge Modules Page 21 of 38
    • SetupCapture  From your desktop, click on Start-->Programs-->Wise-->Wise Package Studio  Login with a valid ID and Password ©Wise Package Studio - SQL Server Login  From the SetupCapture screen, double-click on SetupCapture ©Wise Package Studio - Tools Page 22 of 38
    • 1) Select SetupCapture and click on Next SetupCapture – Welcome screen 2) The ‘Specify Target Installation File’ screen will display 3) Click on Browse SetupCapture – Specify Target Installation File   Browse to the location of the project file where the MSI file will be saved Name the project file (WSI) in the File name field as per the naming standards described in this document and click on Save Note: The SAMPLE below has been provided for reference only. Page 23 of 38
    • MyCompany-MyApp1-5-0-1 MyCompany-MyApp1-5-0-1 Save WSI File per the naming standards   The ‘Specify Target Installation File’ screen will display with the ‘Target Installation’ populated with the MSI file information Click on Next Z:CaptureMy-App1-V5-0-1My-App1-V5-0-1.msi SetupCapture – Specify Target Installation File Page 24 of 38
    •    The ‘SetupCapture Welcome’ screen will display Leave the default settings for ‘Configuration File Location: Local PC’ Click on Settings SetupCapture – Select Settings    The ‘SetupCapture Configuration’ screen will display Select the ‘Directories to Watch’ panel Add more drives and directories if the application installs files in other locations, otherwise leave the default values and process by clicking on OK Setup Capture Configuration Settings Page 25 of 38
    •  Select ‘Snapshot’ and click on Next to take the system snapshot before the application is installed Setup Capture – Capture Methodology screen   The ‘Begin Installation Capture’ screen will display Click on Next Setup Capture – Begin Installation Capture Page 26 of 38
    •  This will scan all the files, directories and registry information on your computer Setup Capture – Begin Installation Capture – Scan Status    When complete, click on Next The ‘Execute Installation’ screen will display Click on Browse to select the executable in the ‘.EXE Name:’ field X:ProdTo-Be-MSIMyApp1Setup.exe SetupCapture – Execute Installation  Click on Execute to complete the Software Installation Process Page 27 of 38
    • Software Installation Process Note: These steps may not be same for every application install   The ‘Setup’ screen will display Click on Next Software Installation Process – Setup Screen  Browse for the destination folder and click on Next C:ProdMyApp1 Setup – Choose Destination Location Page 28 of 38
    •  Select the ‘Setup Type’ and click on Next Setup – Select the Setup Type  Select the ‘Program Folder’ and click on Next My App1 Setup – Select Program Folder Page 29 of 38
    •  The setup program will process and you can view the status from the ‘Setup Status ‘screen that will display Setup Status  When complete, click on Finish Setup – Setup Complete screen Page 30 of 38
    •   The ‘SetupCapture – Execute Installation’ screen will display After installing the application, any changes or customizations can be made at this point before taking the snapshot again (i.e. adding ODBC entries, updating INI files etc.). SetupCapture – Execute Installation screen    Once all the changes are made, click on Next The ‘End Installation Capture’ screen will display Click on Next SetupCapture – End Installation Capture Page 31 of 38
    •   At this point, SetupCapture will scan the computer again to find any differences When complete, click on Next SetupCapture – End Installation Capture – Scan Status screen   The ‘SetupCapture Inclusions’ screen will display Verify the content and click on Next C:ProdMyApp1Subdirectory C:ProdMyApp1Subdirectory C:ProdMyApp1Subdirectoryjre C:ProdMyApp1Subdirectoryjre C:ProdMyApp1Subdirectoryjre C:ProdMyApp1Subdirectoryjre C:ProdMyApp1Subdirectoryjre C:ProdMyApp1Subdirectoryjre C:ProdMyApp1Subdirectoryjre C:ProdMyApp1Subdirectoryjre C:ProdMyApp1Subdirectoryjrebin C:ProdMyApp1Subdirectoryjrebin SetupCapture – Inclusions screen Page 32 of 38
    • The ‘SetupCapture Exclusions’ screen will display Verify the content and click on Next SetupCapture – Exclusions screen   The ‘Finish’ screen will display. Verify the default directories and click on Finish Page 33 of 38
    • My App1 SetupCapture – Finish screen Page 34 of 38
    •  SetupCapture will process and will generate capture reports My App1 SetupCapture – Finish – Generating Capture Reports  When complete with capturing reports, the ‘Saving Installation’ screen will display Saving Installation progress screen  At this point, it will save the installation capture into a Project file (WSI) Page 35 of 38
    •   From your desktop, launch the ‘©Wise Package Studio’ application (click on Start-->Programs-->Wise-->Wise Package Studio) Double-click on Windows Installer Editor ©Wise Package Studio – Windows Installer Editor  Login with a valid ID and Password SQL Server Login screen Page 36 of 38
    •   The ‘Installation Expert’ screen will display Click on Product Details CompanyName-AppName-Version Company Name Version # C:ProdMyApp fileserverpackagescapture Windows Installer Editor - Installation Expert  Enter in the following information, per the standards outlined in this document: o Product Name o Manufacturer o Version o Default Directory SAMPLE: Product Name: MyCompany-MyApp1-V5.0.1 Manufacturer: Business Unit Version: 5.0.1 Default Directory: Click on "Change" button to select working directory. (C:ProdBusinessUnitMyApp1) Page 37 of 38
    •  Select the ‘General Information’ panel My Company MyApp1 5.0.1 Brian Murphy Figure 1:  Installation Expert – General Information screen Fill in the information as shown above Note: Make sure to have the same Title name as the Product Name   Click on Compile Click on Local Compile when prompted Figure 2: Local Compile Page 38 of 38
    •  The ‘Saving Installation’ screen will display Figure 3:    Saving Installation progress screen Once compiled, you will have the MSI file saved in the package folder Close the project file (WSI) and edit the MSI that has been saved From the ‘Installation Expert’ screen, click on Files My App1 My App1 Subdir Installation Expert – Files screen  Clean up all the unnecessary files that are captured Note: In this example, "WindowsSystem32tssesdir" folder and its contents can be deleted. It is up to the packager to keep the package as clean as possible with file and registry information. Page 39 of 38
    •  From the ‘Installation Expert’ screen, click on Registry My App1 Installation Expert – Registry screen   Clean up any unnecessary Registry keys From the ‘Setup Editor’ screen, select Components My App1 My App1 Setup Editor – Components screen  Verify that there are no RED components or components with empty key paths Page 40 of 38
    •   Save the MSI file Test the package by installing on a test machine Page 41 of 38
    • Packager’s Checklist Checklist Details Pre-Packaging Checklist Setup files available? Install Instructions available? Technical contacts? Any connectivity requirements? Test scripts available? Test ID and Password? Dependencies? Any special hardware requirements? Setup files include vendor MSI? Create an MST as per standards. MSI Capture Checklist Do you have the latest ©WISE template? In Installation ExpertProduct Details, Have you entered “Product Name”, “Manufacturer”, “Version” info properly? General Information: Have you filled in the “Title”, “Subject” and “Author” details? Product Name and Title should be same without dashes Are you using Merge Modules? Did you clean up unnecessary files? Did you cleanup unnecessary reg keys? Any components that are marked RED? Any components that are missing key path info? No hard coded IP addresses, server names or user names? Page 42 of 38 Comment
    • Referenced Documents Document Name Application Package Template Description Team Owner Template used to document the detailed description for application package deployments. Packaging Team Microsoft Windows Installer SDK Microsoft packaging standard More details can be found at: http://www.arnebrachhold.de/2005/05/24/microsoft-component-installersoftware-development-kit-spring-2005 Microsoft Page 43 of 38
    • Referenced Copyrights Reference Information Copyright ©Altiris Network America, Inc. All rights reserved. http://www.altirispro.com/Products/Altiris/index.html Copyright ©Citrix ©Citrix Systems, Inc. All rights reserved. http://www.©Citrix.com/lang/English/home.asp Copyright ©Windows Microsoft Corporation. All rights reserved. http://www.microsoft.com/ Copyright ©Word Microsoft Corporation. All rights reserved. http://www.microsoft.com/ Copyright ©VMWare VMware, Inc. All rights reserved. http://www.vmware.com/ Copyright ©Wise Altiris Corporation. All rights reserved. http://www.wise.com/ ** Altiris purchased Wise product line. Copyright ©Altiris Altiris Corporation. All rights reserved. http://www.altiris.com/ ** Altiris purchased Wise product line. Copyright ©Dell Dell Corporation. All rights reserved. http://www.dell.com/ Copyright ©Liquidware Labs Liquidware Labs Corporation. All rights reserved. http://www.liquidwarelabs.com/products/profileunity.asp ** Profile Unity Page 44 of 38
    • Document Control Sheet Document Name, Location, and Owner Name Location Citrix Application Packaging Methodology Creator Brian Murphy Continuous Improvement The procedure defined in this document is subject to regular review based on input from Dell associates. Suggestions for improvement to the content of this document should be submitted using the Dell Services Change Procedure. Document History Version Date Revision history or Review (Author) 1.0 10/6/2013 Document creation / Brian Murphy 1.1 10/8/2013 Minor revisions / Brian Murphy Page 45 of 38
    • Definitions BOS TOS VDI VOS VOSI Bottom of Stack Top Of Stack Virtual Desktop Infrastructure Virtual Operating System Virtual Operating System Infrastructure References Reference Link Source Microsoft - Before Installing Failover Clustering Microsoft Installing a SQL Server 2008 R2 Failover Cluster Microsoft Hardware and Software Requirements for Installing SQL Server 2008 R2 Microsoft Editions and Components of SQL Server 2008 R2 Microsoft Features Supported by the Editions of SQL Server 2008 R2 Microsoft How to: Create a New SQL Server Failover Cluster (Setup) Microsoft Using Upgrade Advisor to Prepare for Upgrades Microsoft SQL Server support policy for Microsoft Clustering Microsoft Microsoft 2008 R2 and SQL 2008 R2 Failover Clustering Microsoft What's New in Failover Clusters in Windows Server 2008 Microsoft What's New in Failover Clusters in Windows Server 2008 R2 Microsoft Additional Tests in Cluster Validation Microsoft Support for SQL Server on iSCSI technology components Microsoft Microsoft Certified Server Catalog for Windows 2008 R2 Microsoft Catalog - Certified for Windows Server 2008 R2 – OS Microsoft Catalog - Works with Windows Server 2008 R2 – OS Microsoft Catalog - Supports Windows Server 2008 R2 - OS Microsoft SQL Server 2008 - Before Installing Failover Clustering Microsoft Features Supported by the Editions of SQL Server 2008 R2 Microsoft Page 46 of 38