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

1. Citrix Application Lifecycle Framework
BY BRIAN MURPHY
Page 1 of 46

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 





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

10. 













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

11. 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

12. 



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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 


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

19. 
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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 


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

26. 
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

27. 
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

28. 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

29. 
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

30. 
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

31. 

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

32. 

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

33. 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

34. My App1
SetupCapture – Finish screen
Page 34 of 38

35. 
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

36. 

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

37. 

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

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

39. 
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

40. 
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

41. 

Save the MSI file
Test the package by installing on a test machine
Page 41 of 38

42. 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

43. 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

44. 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

45. 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

46. 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