6 Application Engineering

This task involves all aspects of repackaging the application. All application installations must use the
Windows Installer engine, meaning the output of this phase has to be an MSI package that conforms to set
standards.

6.1 Snapshot Environment

Item Number 3.1

Task Snapshot Environment

Description When performing a snapshot of an installation program, it is essential to capture only

the content and settings pertaining to that installation. An image that isn’t clean may
prohibit visibility of the package content already present on the image. Machines that
are not clean may capture erroneous data that does not belong to the application.
This task involves defining the base image on which package snapshots are captured.

Value Starting with a clean image is the most important factor that affects successful
repackaging.

Recommendation  Basic operating system, including any major service packs (for example, Microsoft
s Windows XP SP2) only.

 Install only the prerequisites necessary to install the application.

 Carry out this task on a segregated LAN because clean machines will have neither
the security updates nor any anti-virus tools.

 Virtual images can be used where package capture is executed for hardware
independent applications.

 Dedicated physical images should be prepared for hardware-dependent

applications.

Alternatives  As above but with latest hot fixes.

 As above but with antivirus software.

 Physical machines could be used for all applications.

Risks  Package capture with the latest hot fixes or antivirus software, while secure,
involves an overhead in image maintenance and introduces implicit dependencies.

 Slow re-imaging for physical machines may result in poor package turnaround
times.

Challenges  Keeping up to date with hot fixes and antivirus software

 Supporting the isolated repackaging environment

Implementation Assuming that all the packagers will have same desktop configuration a snapshot
image is created that includes the supported OS and the latest major service pack. A
similar approach is taken for virtual images as well.
 All packagers must always reload a fresh image when repackaging a new application.

Session Decision Citigroup snapshot capturing environment will use the Base OS and Major service
pack, with security releases rolled up into quarterly bundles. A virus scanner will be
present. Only dependent applications necessary to capture the package will be
installed, no core applications will be in the capturing environment, this reduces any
implicit dependencies to a minimum. Snapshots will be taken on Windows 2K SP4 and
tested on all supported operating systems. Applications that require Windows XP only
or fail to function when captures on Windows 2K will be re-captured using a Windows
XP environment. This assumes that applications captured and working on Windows 2K
will also work on Windows XP without modification, although this does not logically
follow in practice it is does work, and saves time. Applications which do require
different handling for the two operating systems will generate two MSI files, these will
be merged into a single MSI with the property [VersionNT] used to provide the
necessary conditions on the components, this can be a lengthy process. Virtual
imaging technology will be used. The virus scanner will automatically update itself, a
challenge is keeping these self updating elements on the exclusion list.
Two IDs would be created. One that will require administrator privilege (packaxxxxx)
and another one (packuxxxxx) that will mimic the user ID privilege.
Having two test PCs in addition to a Production PC. This will increase productivity and
turnaround time to develop packages.
6.2 Application Repository
Item Number 3.2

Task Application Repository

Description To ensure predictability and continuity of service, it is imperative that a strict process
is adhered to in management of application sources as well as configuration and
release management.
A well-structured folder layout or configuration management system should be used to
ensure traceability.

Value Simple maintenance across the packages and easier lifecycle management.

Recommendation Storage units for the following items are necessary:

s
 Source binaries

 Project workspace/work-in-progress

 Built MSI database

 Documentation and reports

Alternatives None

Risks Difficult application management with little traceability.

Challenges Configuration effort required.

Implementation All application repositories will be centrally managed by AMS. AMS folder structure will
be configured as per Citigroup’s requirements.
Session Decision Citigroup will utilize a common packaging structure to hold each package. It will
improve clarity, organization and allow any team member to continue working on the
package with little extra effort.
Packages\Package\Project Workspace contains the captured source and the
working project files, for vendor supplied MSIs this may just contain Transforms since
no capturing is done.
Packages\Package\Documentation contains the documentation provided to install
the product and, when completed, the reports a validation files for the finished MSI.
Packages\Package\Original Install contains a copy of the original media, licensing
may request the deletion of the content of this folder once the package goes into
production
Packages\Package\Built MSI contains individual release folders R01, …
Packages\Package\Built MSI\R01 contains the installable MSI and CABinet file,
plus any transforms, any deployment notes or install command line batch files may
also be copied here from the documentation folder.

This illustrates the structure for the example Active Registry Monitor v1.38

As a general housekeeping action pre-deployment any build folders in the Project

Workspace folder will be cleaned out and the build tree itself removed. The completed
installable package will be moved to the Built MSI release folder and latest or each
Build Log, Package Report and Validation Output will be moved to the documentation
folder. This provides a quick mechanism to validate that the package is complete and
also a static location to hold the MSI for conflict solving or moving to deployment. It
the build tree still exists then this is work in progress, if the build tree is gone and the
reports are in the documentation folder then you are preparing for deployment.

Additional internal releases (for example bug fixes in packaging or configuration

changes from the requestor) will be held in the R02 and subsequent folders. Only the
old MSI files need to be maintained for comparison and patching purposes. On no
account should the public version number be updated, in this example it will always
remain v1.38 no mater how many revisions are re-issued to deployment.

6.3 Custom Exclusion List

Item Number 3.3

Task Custom Exclusion List

Description Creation and maintenance of an exclusion list aids in creating uncontaminated

packages and reduces the cleanup effort after the capture process. Ensuring
consistent use of a common exclusion list across the package development team
reduces support costs and improves consistency of packages. Proactive management
of the exclusion list is recommended based on feedback from the package developers.

Value Improves junk removal and reduces package cleanup effort.

Recommendation This list can be created by capturing machine tick over without any applications
s running and also during a reboot scenario.

Alternatives Not to use an exclusion list or tool default list

Risks Package cleanup effort and personnel skill-level requirements are increased

Challenges  Establishing a single point for exclusion list maintenance.

 Ensuring the list is used throughout the team

Implementation A custom exclusion list will be developed by running an empty snapshot and rebooting
the machine. The captured data items that are obviously junk will be added to the
custom exclusions list.
Continual maintenance of this list is required when packager sees erroneous items.

Session Decision Citigroup will use a custom exclusion list and it will be version controlled by a central
body and published to a central location, usually within the standard template folder.
Updates to the list can be made by any team member who finds erroneous registry or
file entries which should be excluded. Justification for the addition of the entries to
exclude may be sought from the team at large, if the entry is not obviously noise.
Nilesh Doshi or similar role will maintain this exclusion list.

6.4 Relative Install Location

Item Number 3.4

Task Relative Install Location

Description This topic refers to flexibility of the installation program when determining its
installation path. This will be primarily determined by the design of the directory table
and the use of Windows Installer properties rather than relative paths.
This task defines the primary destination folder for the captured application.

Value Flexible application relocation and configuration settings.

Recommendation Define a single variable that governs the location/relocation of the application.
s

Alternatives None

Risks Changing the default install location could disable the application if non-relative
paths exist.

Challenges Ensuring the package has used relative paths in all possible configuration settings.
Implementation All applications will use the InstallShield predefined public property INSTALLDIR as a
relative root for all the components that are part of a legacy repackaged installation.
For all third-party installation, the install location will be left as-is.

Session Decision INSTALLDIR will be used within the packages to define the primary install folder for
that package. Changing INSTALLDIR on the command line should move the entire
product to that new folder without orphaning any components or registry keys. This
will provide the most flexibility of the packages. For INSTALLDIR to be set correctly as
an alias the final column of that row in the Directory table must be a single dot on its
own.

6.5 Application Shortcuts

Item Number 3.5

Task Application Shortcuts

Description Decisions on shortcut destination and structure will probably be determined by a

desktop design team and will be part of the enterprise standards for the corporation.
This task defines the standard for handling shortcuts in a package.

Value  Consistent desktop user environment

 Maintains application integrity

Recommendation  Advertise all shortcuts associated with delivered executables or documents.

s
 Remove all shortcuts to uninstall routines.

 Remove desktop shortcuts to avoid clutter (Move to Programs menu).

 Move shortcuts on the Start or Programs menu to a more standardized enterprise

structure.

 Document additional shortcut-related application requirements in the discovery

phase.

Alternatives Leave the application defaults.

Risks  Non-advertised shortcuts reduce Windows Installer’s ability to perform self repair
and install on demand.

 Unassociated legacy uninstall icons.

 Cluttering of the Start menu or desktop.

Challenges Enterprise agreement on the standardized structure

Implementation All shortcuts in an application will be converted to advertised shortcuts. This includes
third-party packages as well.
Session Decision All shortcuts will be the advertised style, where possible. Shortcuts to files which are
not included in the package are allowed to be non-advertised. Shortcuts to documents
which do not use the default verb are allowed to be non-advertised. Advertised
shortcuts provide protection for the application by leveraging the Windows Installer
self-repair mechanism.

Applications with a single shortcut should move the location to the folder:
Start Menu\Programs\Applications
Applications with multiple icons will be in the Application Name folder:
Start Menu\Programs\Office
PROVISO: A test will be carried out on the Terminal Server to ensure adequate per-
user data files can be repaired into existence using the standard MSI mechanism (test
package written and issued with instructions to Alex A, pending analysis of test
results).

6.6 Setup Template.

Item Number 3.6

Task Setup Template

Description Standard templates form the basis for all package creation. Including generic
configuration and packaging standards settings in the template helps reduce the
packaging effort and improve uniformity.
This task addresses the pre-population of installation elements that are to be
replicated across all packages.

Value Consistent package design

Recommendation These items should be included in your template

s
 Launch conditions

 Business specific properties

 Limited UI settings

 Custom actions, and tables to support them

 Any necessary enterprise auditing entries

 Build format definitions

 Add or Remove Programs (ARP) settings

Alternatives Use an empty template.

Risks  Inconsistent implementation across the packaging team

 Increased QA effort

Challenges Gathering the business requirements for the entire enterprise can be challenging.

Implementation A standard setup template will be created using the Editor tool in AdminStudio.
 Refer to section 10, “Setup Project Template,” for more information on creating a
standard project setup template.

Session Decision Citigroup has now built a global packaging template v1.0 for use within the packaging
environment. The details of the content and how it should be used are held in a
separate document.

6.7 MSI Build Format

Item Number 3.7

Task MSI Build Format

Description Correct definition of the build format is important. It is largely dictated by the
deployment tool, but also affects installation requirements.

Value Deployment-friendly packages

Recommendation Include the following information in the setup template for a Single MSI database
s format:

 Each MSI database denotes a single package.

 Can be secured against malicious, or viral, attack with a digital certificate.

 Any required transforms.

Include the following information in the setup template for an External cabinet file:

 Can be secured against malicious, or viral, attack with a digital certificate.

 Reduces deployment server space.

 Reduces install-time bandwidth.

 Reduces install-time workstation disk overhead.

 Reduces install duration.

 Any required transforms.

Exclude the following from the template:

 Setup.exe stub.

 Scripting engines. (Deploy as a dependency if needed.)

 Middleware runtimes. (Deploy as a dependency if needed.)

Alternatives If your deployment tool is unable to cater to this optimal format then other available
options include

 Single MSI plus External uncompressed files

 Single MSI plus External compressed cabinets

 Single MSI incorporating compressed cabinets internally

Risks Deployment tool incompatibility

Challenges It may be a challenge to modify vendor-delivered MSI packages to this format.

Implementation The setup template will be authored to include the default releases as per the
recommendations.
All third-party MSI packages will be converted to an uncompressed image using
administration installation.

Session Decision Citigroup will use a single MSI and a CABinet as a build format. Crucially the CABinet
file will not be streamed into the MSI database due to the overhead at install time that
this introduces. Both the MSI and the CAB can be signed at some future date when a
digital signature and private key have been obtained. Group policies may then be
used to restrict the installation of unsigned packages. Digital signing will become
more important if Windows Vista is introduced since security of code against malicious
or viral attack is high on it’s agenda. Patch creation is achieved by comparison of
uncompressed sources and so the standard template will include an additional
uncompressed build format specifically for use in the creation of patches. It is not a
deployment format only a patch creation format.

Citigroup will also include an uncompressed format build within the MSI template but
this is strictly for the purposes of creation of Patches and is not intended as a viable
format for the distribution of packages.

6.8 Handling Common Components

Item Number 3.8

Task Handling Common Components

Description The correct sharing of resources requires proper reference counting of installation
items. Windows installer solves this problem by using merge modules.

Value Package integrity is maintained through proper reference counting.

Recommendation  Merge modules should be held in, and used from, a central repository, ensuring
s consistency.

 Use supplied industry-standard merge modules.

 Proactively create custom merge modules for re-use.

 Where deployed, modification and maintenance of vendor supplied component

codes may be required.

Alternatives None

Risks Unsynchronized component reference counting leads to unwarranted removal of

shared resources, resulting in broken applications.
Challenges Management of merge modules

 Across multiple development locations

 For third-party components

 For latest version issues

Post-deployment synchronization of new-vendor merge modules

Implementation All merge modules provided by Macrovision and other reliable industry sources will be
published in a shared location. All packaging desktops will be configured to read
merge modules from this location. This merge module location configuration will be
carried out by deploying AdminStudio by using a customized transform.

Session Decision Citigroup will use the commonly available industry standard Merge Modules (.MSM
files) they will be maintained in a central location on the repository. In the interests of
speed the central repository should be copied to a local folder on the developer’s
machine and accessed from there, this provides faster access. Maintenance of this
central store of Merge Modules will be necessary keeping it up to date and ensuring
that all team members are in synch with any changes to the MSM pool. In addition
Citigroup may take a pro-active stance of creating Merge Modules for common
components, this will reduce somewhat the Conflict Solving task, but since creation of
high quality MSM files is non-trivial this is not a required action, it is optional.

If the merge modules are not copied locally, the AdminStudio editor tool can typically
be slow (~60 seconds) when it opens since it reads all available .MSM package codes.
Opening local copies of the MSMs is faster. The risk of having the files copied locally
to the Packaging Engineer’s desktop is inconsistency among the same regional team.
To remediate this, a script will be developed that will copy the files from a central
repository to the regional repository and from regional repository to the Packaging
Engineer’s desktop. A flag would identify a change and trigger a copy of the merge
modules automatically. The script will be executed at logon time and can be execute
manually as well.

6.9 Packaging Environment Configuration

Item Number 3.9

Task Packaging Environment Configuration

Description Configuring the environment to allow efficient sharing of common resources across the
team

Value Consistency of package quality created from any source

Recommendation Ensure sharing of the following items:
s
 Custom exclusion lists

 Merge modules

 Tool configuration

 Setup template

 Virtual machine image storage

 Standardization transform for vendor packages

 Latest automation/validation tools

Alternatives None

Risks Inconsistent implementation of standards may result in additional QA effort that

slows package turnaround time.

Challenges Maintenance of the shared environment life cycle

Implementation All shared AdminStudio resources will be hosted at a central location. AdminStudio
setup will be tweaked using a transform so that all tools refer to the shared location
rather then a local one. Furthermore, the transform will be authored enforce
compliance by removing all local shared resources.

Session Decision Citigroup will use a centralized repository for the items mentioned above. Further this
central store will be replicated down to the regional level and steps must be taken to
ensure that the two remain in synch. Updates to the central repository must be
propagated, within a reasonable time, to all regions. The time frame for updates is
dependent on the change, however the listed items are remarkably rarely updated
and largely static. An installation transform will be created to pre-configure
AdminStudio to integrate with this common packaging environment.

Location:

6.10 Application Isolation

Item Number 3.10

Task Application Isolation

Description Windows XP supports true isolation for any 32-bit application via Win32 assemblies
and manifests.

Value Isolation is a mechanism to resolve backward-compatibility issues that cannot be

handled by simple segregation.

Recommendation Additional processing to isolate applications is only necessary when compatibility

s issues are detected in product functionality tests.

Alternatives None
Risks If application incompatibility issues are found, then not isolating the packages is
obviously high risk.

Challenges  Detection of incompatibility amongst applications and resources is difficult.

 Building application assemblies and manifests is a complex task.

 Association of component assemblies with parent executables is not obvious.

 Significant functionality testing is required after isolation.

Implementation When necessary, AdminStudio’s Application Isolation Wizard tool will be used isolate
application DLLs.

Session Decision The positive decision point which was offered was at Integration Testing (or Conflict
Solving) when ACE07 or ACE08 issues are generated between incompatible DLLs.
Once the conflict is detected the applications can be tested one against the other to
find out if backwards compatibility has been broken in that file. In addition, not only
must the ACE07/08 be seen and the two versions be incompatible, but it must also be
a self-registering file (DLL/OCX/EXE), non-self registering files can be re-homed and
included into AppPath statements to cater for incompatibilities. If all these conditions
are met then application isolation will achieve resolution of incompatibility problems.
This needs to be confirmed via a test.
A flow chart would be helpful to illustrate the decision points (in week 4 of the
session).

6.11 Application Source Management

Item Number 3.11

Task Application Source Management

Description Applications installed using MSI can be made source resilient by setting the
SOURCELIST property.

Value Source location can be configured after deployment.

Recommendation Use environment variables.

s

Alternatives Scripted maintenance of application source via custom actions

Risks Unavailability of alternate resources to manage repair

Challenges Agreement and management of common environment variables across an

enterprise

Implementation A custom environment variable will be defined that will point to the root of the
alternate package distribution point.
All packages will be configured to append the new location to the SOURCELIST
property by using custom actions.
Session Decision Citigroup’s cornerstone principle of creating generic packages dictates the inclusion of
this entry in the MSI database even though the current choice of deployment tool (HP
Radia) may override this setting. The value of this SOURCELIST property should be set
to an environment variable used to locate the local source %MSI_SOURCE_ROOT%\
[ProductName]\[ProductVersion]\ The environment variable itself can be set by Group
Policies at user login time. The property itself must be set in a custom action since
property value column in the property table is not “formatted” column and hence does
not resolve at install time.

6.12 Handling Current User Settings

Item Number 3.12

Task Handling Current User Settings

Description A standard mechanism provides user configuration to all users. Packages should also
be designed to minimize the impact of self-repair.

Value Minimizes user inconvenience

Recommendation  Design packages such that user components are contained in a parent feature.
s
 Entry points should be placed in the lowest-level feature.

 Ensure that HKCU key is used as KeyPath for user data.

 Use the ActiveSetup method when an entry point is not available.

Alternatives Create a custom action to modify the REINSTALLMODE property to minimize the
registry repair time.

Risks Inefficient self repair

Challenges  Implementation for vendor MSI packages

 Identification of user components

Implementation Appropriate AdminStudio tools will be used to tweak the packages as per the
standards.
Session Decision Citigroup will support current user settings via the use of AdminStudio toolset, this will
automatically separate per-machine from per-user registry settings. In addition per-
user data files will be supported by creation of additional per-user registry keys. This
forces the MSI to repair for new users of the application running the product after
installation, the per-user data file is installed just in time, in addition custom actions
may run to configure the file perhaps with user specific details.
During this discussion an additional topic arose and although not entirely restricted to
current user settings forum it is an important gap in the process…

Citigroup requests a mechanism to provide dynamic runtime configuration of products.

Install time resolution of configuration is reasonably trivial, but at product runtime the
MSI is not active and given a successful install the repair mechanism will not be
triggered, hence no custom actions can run. It is obvious therefore that this request
can only be solved outside of the MSI framework. A wrapper VBScript around each
EXE (underneath every shortcut) was proposed taking its configuration from some
centrally located database of configuration settings for the product. This is an invasive
approach and will result in non-standard packages. However the wrapper is
implemented a requirement of its function will be to ensure the application is ready to
execute. Generally this is done via the Advertised shortcut since this provides an
entry point for Windows Installer to do the application integrity check. If the shortcuts
are removed or hidden then the wrapper must ensure that the Windows Installer is
prompted to perform the application integrity checking however the application is
instantiated.

This additional topic still requires research, the wrapper VBScript is in the design
phase. The scope of the wrapper is not fully determined. Not all applications will
require runtime configuration, inclusion of this single point of failure underneath every
application shortcut in the business could be construed as a risk.

6.13 Package Cleanup

Item Number 3.13

Task Package Cleanup

Description Remove unwanted resources that were captured but not part of the original
application.

Value Improves package quality and ensures better integration

Recommendation  Ensure that resources that do not belong to the application are removed from the
s package.

 Analyze removed resources for inclusion in an exclusion list.

Alternatives None
Risks Unclean packages are likely to

 Take longer to integrate

 Increase QA effort

 Break existing applications on removal

 Require unnecessary repair for unrelated resources

Challenges  An expert skill level is required for consistent results across the team.

 Elimination of unwanted resources can be subjective.

 This process can be very time consuming.

 Implementation for vendor MSI packages.

Implementation The first line of defense will be the custom exclusion lists. These lists need to be
updated frequently as new items that must be excluded come along.
Additional cleanup will be carried out by running the MICE rules.
Please refer to the “MICE Rules” section for more information.

Session Decision Citigroup’s package cleanup regime will include: removal of junk keys; removal of
Darwin descriptors (if a snapshot of a vendor was necessary); inclusion of repeat
offender junk keys into the central exclusion list. The implementation of MICE scripts
(or similar) to automate the cleansing process of the .ISM prior to building the
application. Whatever the mechanism of cleaning the package manual or automatic,
the quality of the packages should an equally high standard, low quality packages has
less chance of being reused across the board. Validation will provide a common
measuring stick with which to compare quality. A Citigroup safe edition of MICE will be
developed in the validation session.

6.14 Standardization Transform

Item Number 3.14

Task Standardization Transform

Description Creation of transforms incorporating standards to be applied to vendor MSI packages

Value Consistent package design for all applications

Recommendation Replicate setup template content in a transform.

s

Alternatives Not to modify vendor MSI packages

Risks Vendor MSI packages are not standardized for use within the business.

Challenges Evaluating contradiction between business standards and vendor package content

Implementation A standardized transform will be generated for MSI packages and stored in the
repository. Hybrid MSI packages will be converted to standard MSI packages by using
the conversion wizard in AdminStudio.
Session Decision Citigroup will use a standardization transform to apply the same business logic and
MSI template content to vendor supplied MSIs. The use of this transform is essential
otherwise vendor packages are not visible from an auditing point of view. The content
of this transform must remain in synch with the modifications to the MSI template, and
be maintained in the same manner.

6.15 Handling Localization Requirements

Item Number 3.15

Task Handling Localization Requirements

Description Managing package content based on regional requirements

Value Support for regional business needs

Recommendation For repackaging applications—maintain one package per region.

s

Alternatives Merge all resources into a single package and build installation locale conditions.

Risks  Using a single locale package for all regions may result in user dissatisfaction.

 Special language skills may be required for packaging and QA.

Challenges Management of regional requirements for package deployment

Implementation Appropriate conditions will be set at launch using the standard MSI locator tables.

Session Decision Citigroup will handle per region customization at the regional level, but conflicts solve
the application along with the Global pool of applications. Tolerances may greater if
conflict exist between a regionally customized package and the same package
customized in a different region.

6.16 Component Rules

Item Number 3.16

Task Component Rules

Description Standards for designing components

Value  Increased resiliency of applications

 Install on demand

 Advertised functionality of application

 Improved package integration due to increased database visibility

Recommendation Follow Microsoft’s SDK best practices for internally developed packages.
s

Alternatives None
Risks  Package reliability and support issues

 Upgrading and patching of applications

Challenges  Developer skills, training, and tool capability

 Applying component rules to vendor MSI packages

Implementation AdminStudio Repackager will be configured to create components as per the best
practices. For third-party MSI packages, MICE rules will be executed to ensure
compliance.

Session Decision Citigroup will adhere to Microsoft Best Practices when creating components within the
MSI. This is easily achieved by use of AdminStudio since the repackaging tool
automatically creates its components as per Best Practices.

PROVISIO: Where the application is a vendor supplied MSI from a trusted source and
works well, then in this case deviation from the best practices for component creation
is tolerated. If the application installs poorly and violates best practices then it may be
transformed to adhere or repackaged from scratch, whichever the easier.

6.17 Custom Action Standards

Item Number 3.17

Task Custom Action Standards

Description Means of providing functionality not native to MSI

Value Maintainability of custom code base

Recommendation  Never create a custom action where native support exists.

s
 Never place custom actions in the UI sequence.

 Custom actions that configure the target system should be executed in deferred
mode and must support rollback and uninstall.

 Support custom actions that increase the MSI standard functionality by building
custom tables.

 To facilitate maintenance and visibility, make workarounds for one-off custom

actions open source.

 Maintain a code library for custom actions.

Alternatives None

Risks  Badly authored custom actions may leave a system in an indeterminate state.

 Non-standardized custom actions lead to a lack of maintainability and reusability.

Challenges  Standards development for code creation

 Maintaining a code library for reusability

 Expert skill level required with knowledge of the target environment

Implementation A custom action library will be developed that would include most of the common
custom actions required. When necessary, this library will then be extended as
required.
All packages will use this one library for all custom actions.

Session Decision Citigroup will create a custom action gallery for reuse of standard operations across
the teams. Standard approaches developed by one team can be leveraged by all
teams. This library must be centrally maintained just like the other centralized
resources. The question comes as to what form to implement custom actions
especially sensitive actions such as licensing.

All custom actions will write their initiation termination and any decision they take to
the standard MSI log.

Two formats are suggested VBScript for ease of creation, openness of maintainability
and clarity of auditing and secondly the compiled Windows Installer DLL can be used
when security of action is required. Both can be used from different locations and
interspersed within the same package without issue.

6.18 Configuring ODBC Entries

Item Number 3.18

Task Configuring ODBC Entries

Description Standard methodology for configuring ODBC information

Value  Improves self-repair and installation reliability

 Use of native tables enhances integration reporting

Recommendation Use native ODBC tables in MSI database.

s

Alternatives Use the registry table only if the native tables fail to handle requirements.

Risks Integration and support issues

Challenges Debugging ODBC issues

Implementation AdminStudio’s Repackager tool will be configured to generate ODBC entries as per the
standards for legacy-repackaged applications.
ODBC entries for all third-party MSI package will remain as-is, unless there is a
potential conflict with other packages. When a potential conflict exists, the packages
will be modified as per the standards.
Session Decision Citigroup will utilize the standard ODBC table to deploy ODBC DSNs and Drivers.

PROVISO: In the case where the ODBC driver cannot be deployed using ODBC tables
then, and only then, will the registry table be used to deploy the same settings. This
often occurs due to a missing DLL at install time, perhaps the middleware driver may
not yet be installed, we cannot rely on installation ordering during deployment,
package dependencies do not enforce install order.

6.19 Configuring INI Files

Item Number 3.19

Task Configuring INI Files

Description Standard methodology for configuring INI files

Value Use of native tables enhances integration reporting.

Recommendation Use native INI tables in MSI database to handle INI files.
s

Alternatives Use the registry table only if the native tables fail to handle requirements.

Risks Only improperly formatted INI files should be installed as a file.

Challenges Determining proper structure for large INI files can be difficult.

Implementation AdminStudio’s Repackager tool will be configured to generate INI entries as per the
standards for legacy-repackaged applications.
INI entries for all third-party MSI package will remain as-is, unless there is a potential
conflict with other packages. When a potential conflict exists, the packages will be
modified as per the standards.

Session Decision Citigroup will utilize the INI table to deploy the well formatted INI settings. Badly
formatted INI files must either be installed as static files or by using a custom action
(equivalent to a “GREP”). In addition INI settings and sections which are in different
files must be separated into individual components, this improves conflict solving at
the integration and test phase.

6.20 Configuring Environment Settings

Item Number 3.20

Task Configuring Environment Settings

Description Modification of environment settings that may be stored in structured files

Value Stability of target environment

Recommendation  For structured text files, use custom actions to add and remove entries.
s
 For binary or unstructured text files, install as a file.
Alternatives None

Risks Corrupting settings that may be used by other applications, making them
inoperable

Challenges  Increased packaging effort and testing time

 Integration with other packages

Implementation Custom action library will contain custom actions to update the most common
environment settings.

Session Decision Citigroup will use a custom action and a generic table to update entries in text based
files. Binary formatted files would require complex custom actions and must be
written for case by case scenarios, this require DLL actions since VBScript does not
support writing binary streams. It is quicker and easier to deploy the binary file as a
flat static file.

6.21 Handling Shared Extensions

Item Number 3.21

Task Handling Shared Extensions

Description Mechanism to handle multiple applications taking control of the same file extension

Value Retains association for commonly updated file extensions

Recommendation Publish extension usage in a common location that can be used for re-establishing
s associations on uninstall.

Alternatives None

Risks Missing file extension associations can result in orphaned document types.

Challenges Determining the extensions being installed by a package

Implementation Packages will be authored to manage reference counting for all extensions so that
auto-repair can ensure that the extension does not lose its application association.

Session Decision Citigroup will employ the creation of additional breakaway keys which force
application repair and hence re-association of shared extension association when an
application is uninstalled. Registry Location: HKLM\SOFTWARE\Citi\Shared Extensions\
6.22 Use of PATH Environment Setting

Item Number 3.22

Task Use of PATH Environment Setting

Description This task employs a methodology to update the system PATH environment setting to
use AppPath for all application executables.

Value  Allows the specification of more than one path to be used by the application

 Eliminates the impact on the system PATH variable, which is already limited in size

 Allows the operating system to handle the appending and removal of paths during
application launch and shutdown.

Recommendation Use the AppPath key to specify any path requirements for the application instead of
s updating the actual system PATH variable.

Alternatives Use the MSI environment table to update the system path. This approach risks
increasing the system PATH size and may result an inoperable application.

Risks If an application cannot locate any required resources it may fail.

Challenges  Determining all the paths to the resources required by the application

 Adding AppPath for vendor MSI

Implementation All packages will be updated to include AppPath registry keys for all major executables
in the package.

Session Decision Citigroup will substitute the use of AppPath wherever the use of PATH environment
variable is seen. This is supported by the operating system and independent of the
application although many applications today still do no use it. This is a risk free pro-
active step to reducing problems associated with the limit of the PATH variable.

6.23 Handling Local Lockdown Environment

Item Number 3.23

Task Handling Local Lockdown Environment

Description Ensures that the application functions normally with restricted user privileges

Value Necessary for an application to function in a lock down environment

Recommendation  Use the LockPermissions table to overwrite the permissions on the required
s resources.

 Apply permissions to Administrators (Full Control) and Users (As necessary).

Alternatives Use a proprietary tool to modify permissions for required resources.

Risks Application may not function in the users’ security context.

Challenges  Determining security needs of an application

 Working with the security team to avoid GPO’s from overwriting permissions set by
Windows Installer.

Implementation All packages which require resources to be de-secured for User access will be modified
to provide the permissions required. It is important that this information be logged in
WFM for reporting and maintenance purposes.

Session Decision Citigroup will use the LockPermissions table to de-secure application resources
(Files,Folders and Registry Keys) to allow the application to function correctly when
executed by a standard User.