Global Server

Installation Guide
AVEVA Solutions Ltd

Disclaimer
Information of a technical nature, and particulars of the product and its use, is given by AVEVA
Solutions Ltd and its subsidiaries without warranty. AVEVA Solutions Ltd and its subsidiaries disclaim
any and all warranties and conditions, expressed or implied, to the fullest extent permitted by law.

Neither the author nor AVEVA Solutions Ltd, or any of its subsidiaries, shall be liable to any person or
entity for any actions, claims, loss or damage arising from the use or possession of any information,
particulars, or errors in this publication, or any incorrect use of the product, whatsoever.

Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every
part of it (including source code, object code, any data contained in it, the manual and any other
documentation supplied with it) belongs to AVEVA Solutions Ltd or its subsidiaries.

All other rights are reserved to AVEVA Solutions Ltd and its subsidiaries. The information contained in
this document is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval
system, or transmitted without the prior written permission of AVEVA Solutions Ltd. Where such
permission is granted, it expressly requires that this Disclaimer and Copyright notice is prominently
displayed at the beginning of every copy that is made.

The manual and associated documentation may not be adapted, reproduced, or copied, in any material
or electronic form, without the prior written permission of AVEVA Solutions Ltd. The user may also not
reverse engineer, decompile, copy, or adapt the associated software. Neither the whole, nor part of the
product described in this publication may be incorporated into any third-party software, product,
machine, or system without the prior written permission of AVEVA Solutions Ltd, save as permitted by
law. Any such unauthorised action is strictly prohibited, and may give rise to civil liabilities and criminal
prosecution.

The AVEVA products described in this guide are to be installed and operated strictly in accordance with
the terms and conditions of the respective license agreements, and in accordance with the relevant
User Documentation. Unauthorised or unlicensed use of the product is strictly prohibited.

First published September 2007

© AVEVA Solutions Ltd, and its subsidiaries

AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom

Trademarks
AVEVA and Tribon are registered trademarks of AVEVA Solutions Ltd or its subsidiaries. Unauthorised
use of the AVEVA or Tribon trademarks is strictly forbidden.

AVEVA product names are trademarks or registered trademarks of AVEVA Solutions Ltd or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).

The copyright, trade mark rights, or other intellectual property rights in any other product, its name or
logo belongs to its respective owner.
 Global Server Installation Guide

Global Server Installation Guide

Contents Page

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Software and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
AVEVA Security File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1

Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
Uninstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:7
Modifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:8
Repairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:9
Healing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:9
Modified New and Removed Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:9
User Modified Appware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:9
Models, Sample Data and Example Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:10
Changing Default File Replacement Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 2:10
Post Deployed .bat files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:11
Pre-Deployed .bat files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:11
.bat file Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:11
Network (Admin) Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:11
What is an Administrative Installation?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:11
Creating an Administrative Installation Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:11
Issues with Administrative Installation Points . . . . . . . . . . . . . . . . . . . . . . . . . 2:12
.NET Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:12
Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:13
Using Files within the Source Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:13

i 12.0
 Global Server Installation Guide

Network Throughput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:13

Advantages of a Network Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:14
Running Global from Network Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:14
Administrative Installation Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:15
Patching Administrative Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:15
Copying a Local Deployment to a File Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2:15
Feature Id Reference List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:16
Feature Tree Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:16
Selecting Features from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:16
Command Line Definable Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:17
Sample Command Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:17

ii 12.0
 Global Server Installation Guide
Introduction

1 Introduction

The Global Server Installation Guide explains how to install AVEVA Global Server, as
supplied by AVEVA Solutions Ltd., on a DVD, onto a workstation which is running under the
Windows XP, Windows 2003 or later.

1.1 Hardware
It is recommended that the Global daemon is installed on a separate file server.

CPU 2 GHz Intel P4 (Dual core or dual processors recommended)

RAM 1 GB system memory

HDD 500 GB Ultra SCSI II HPL (10000+ rpm) (two or more 500 GB,
SATA-300 RAID recommended)

Network 100 Mb/sec LAN

The above specification are recommended when running the Global daemon on a file
server.
For hardware requirements for client machines running the base product refer the relevant
installation guide for that product.

1.2 Software and Configuration

The Global daemon uses RPC, which is part of the standard Windows software, and so no
additional software has to be installed.

1.3 AVEVA Security File

You must have the correct AVEVA license file before you can use AVEVA Global Server.
The file is controlled by the network security product called Flexman. Refer to the Flexman
Installation and Configuration Guide for more information.
Global now requires a license for Hub and Satellites. At the hub location each project
daemon will take out a GLOBAL license entry. At each Satellite each project daemon will
take out a GLOBALSAT license. A project daemon at a Satellite may use a spare Hub
license (GLOBAL) if no satellite license (GLOBALSAT) is available.

1:1 12.0
 Global Server Installation Guide
Introduction

1:2 12.0
 Global Server Installation Guide
Installation

2 Installation

The AVEVA Global Server installation must be carried out by a System Administrator.
Make sure you close any other applications you have running.
Insert the installation DVD into the DVD ROM drive. If the autostart feature on your PC is
enabled your browser will automatically load the correct file on the disc and display the
Installation menu:

Note: The exact appearance of forms and screens may be different depending on which
browser you are using. The forms used in this manual are from Microsoft Internet
Explorer 7.

If you didn’t have your browser running, or the page failed to load, use Windows Explorer to
navigate to the disc in DVD ROM drive and double-click on the file setup.exe; alternatively,
right-click and choose your browser from the Open With option on the popup menu.
Global is supplied on a DVD as part of a suite of applications. Click on AVEVA Global
Server to display the Release Documents screen.

Click INSTALL to display the Global Setup Wizard.

2:1 12.0
 Global Server Installation Guide
Installation

The user has the option to change where the Global Setup Wizard installs the Global Server
files by clicking Advanced to display the Custom Setup window.

2:2 12.0
 Global Server Installation Guide
Installation

A default Location folder C:\Aveva\Global12.xx\ is recommended for the installation, which

can be changed by clicking Browse to display the Change destination folder window. The
user can now navigate to an existing folder or create a new folder. Click OK to accept the
destination folder.

Feature Configurable Default Path

AVEVA Global Server Yes C:\AVEVA\Global12.0.SP6

To check if enough disk space is available click Disk Usage to display the Disk Space
Requirement window. Highlighted volumes indicates that there is not enough disk space
available for the selected features. The user can remove some of the files from the
highlighted volumes, install fewer features or select a different destination volume. Click OK
to return to the Custom Setup window.
Click Back to step back a stage, Cancel to terminate the Setup Wizard or Next to display
the Ready to install Global window.
Clicking Install on the Welcome to the Global Setup Wizard accepts the default
installation settings and also displays the Ready to install Global window.

2:3 12.0
 Global Server Installation Guide
Installation

Click Install to start the installation.

2:4 12.0
 Global Server Installation Guide
Installation

During the installation process the screen displays a Cancel button, which can be clicked to
stop the installation. When selected a window is displayed asking for confirmation that the
Global installation is to be cancelled.

Selecting Yes displays a screen showing the Global Setup Wizard was interrupted.

2:5 12.0
 Global Server Installation Guide
Installation

Click Finish to exit the screen and installation.

Selecting No on the confirm screen returns you to the Installing Global screen and
continues the installation.
Once the files have been copied a final window is displayed confirming that the install
process is complete. Click Finish to close the installation application.

2:6 12.0
 Global Server Installation Guide
Installation

Once the files have been copied onto the system, post configuration is required. For
information regarding configuration of Global refer to the Global User Guide and Running
Global Projects in that order.

2.1 Uninstall
Complete removal of an installation can be accomplished by several methods.
• Removing it from Start > Settings > Control Panel > Add/Remove Programs applet
• Right clicking on the MSI file that installed it, and selecting Uninstall
• Running the command MSIEXEC /X [Path to Original MSI]
• Running the command MSIEXEC /X {ProductCode of MSI}
Removal of individual Features is also possible from the command Line, using the
REMOVE property or by changing the installation state via the Add/Remove Programs
applet.

Note: Uninstalling the Global installation will not uninstall Microsoft's .NET Framework or
downgrade the Windows Installer Service. The .NET Framework must be removed
separately if required.

2:7 12.0
 Global Server Installation Guide
Installation

2.2 Modifying
There are several ways to modify an installed installation. For example:
• Changing it from Start > Settings > Control Panel > Add/Remove Programs applet
• Right clicking on the MSI file that installed it, and selecting Install, then selecting
Change at the subsequent window.
• Running the command MSIEXEC /I [Path to Original MSI], then selecting Change at
the subsequent window.
• Running the command MSIEXEC /I {ProductCode of MSI}, then selecting Change at
the subsequent window.
Once the Change option is selected the Custom Setup window is displayed allowing the
user to change which features are installed.

The Change option can not be used to change the Location Path. If the user wants to
change the Location Path, the current installation must be removed and then re-installed
using the new Location Path.

Note: Never move files by other means, as this may trigger healing, however Copying files
to other locations will not cause problems.

2:8 12.0
 Global Server Installation Guide
Installation

2.3 Repairing
If any programs stop working, or the installation has knowingly been damaged, then Repair
may fix the problem.
There are several ways to repair an installation. For example:
• Changing it from Start > Settings > Control Panel > Add/Remove Programs applet
• Right clicking on the MSI file that installed it, and selecting Install, then selecting Repair
at the subsequent window.
• Running the command MSIEXEC /F [Path to Original MSI], then selecting Repair at the
subsequent window.
• Running the command MSIEXEC /F {ProductCode of MSI}, then selecting Repair at
the subsequent window.
Repairing installations causes them to heal themselves. For more information refer to
Healing.

2.4 Healing
MSI technology has inbuilt self repairing mechanisms. As such it is generally unwise to alter
file and folder names, shortcuts or registry manually, as this may trigger the MSI which
deployed the files to redeploy them.
However, it is expected that some users will wish to alter Appware, "Sample Data" Shortcuts
and .bat file variables. As such, AVEVA installations have been designed to minimise the
ability of the MSI to heal itself in such cases.
Sample Data, Models, example projects and shortcuts, should not trigger healing if they are
deleted or altered. The consequence of making shortcuts editable/deletable is that MSI
Advertising will not function.

2.5 Modified New and Removed Files

Irrespective of whether an MSI is installing, changing state, or repairing, files are removed/
deployed/overwritten based upon certain file version rules. As such, the changes caused by
a repair or an installation depend upon the initial state of the computer.

2.5.1 User Modified Appware

In MSI/Deployment terms, Modified appware files constitute un-versioned, language neutral
files, whose "Created Date" and "Modified Date" differ. However, if appware files have been
moved or handled in certain ways, then it is possible that the "Created Date" and "Modified
Date" will not differ, in which case the file replacement behaviour of the installation will be
different.
In the case where an appware files "Created Date" and "Modified Date" is different, no MSI
will ever overwrite such a file. So Modified appware will never be upgraded (by default),
changed or bug fixed by an AVEVA MSI or Patch.
In the case where a modified appware files "Created Date" and "Modified Date does not
differ, the appware file with the newest date will prevail (by default). This scenario is most
likely to happen when installing a Patch or an MSI which is not classed as a "Service Pack"
or a "Full Release", since releases with more minor designations are not side-by-side
deployable, as they are intended as upgrades to pre-existing releases.

2:9 12.0
 Global Server Installation Guide
Installation

Once appware has been modified, it must fall to the author/owner to maintain the changes,
since there is no reliable way to reconcile code differences. In extreme cases this may mean
that AVEVA installations cannot be used to deploy appware, and those clients must make
their own code merges.

2.6 Models, Sample Data and Example Projects

It is in the nature of Models, Samples and Examples, that:
• The constituent parts are often interdependent in some way.
• Interdependencies will vary between releases and can be difficult and risky to migrate
automatically.
• Their file footprint is apt to change drastically.
• They will not always be required.
• They may be moved, copied and shared.
• File paths and folder names may change in time.
• Parts of them may be re-used in other scenarios.
• They can be supported or migrated across many versions of an application.
• Many different programs may work with them and with data derived from them.
Hence, it is felt that Models, Samples and Examples:
• Should be regarded as separate entities in their own right.
• Have a lifecycle which is likely to differ from the applications which they service.
• May be released with installations which install applications, but should be as easy as
possible to divorce from such installations.
• Are unsuited to Repair or Patching by installations.
• Are risky to de-install/remove when applications are removed.
• Should be released holistically.
• Should be available separately from application installations in special cases.
• May suit release in a simple compressed archives (.zip file or self extracting executable
say).
Current AVEVA MSI installations attempt to address these requirements by completely
removing an installations ability to heal its Models, Samples and Examples. If a new copy is
required, the installation must be completely removed, and then reinstalled. Repairing will
not restore Models, Samples or Examples.
Uninstalls, are achieved by deleting the root folders where the Models, Samples and
Examples where deployed to. It is important to remove them if they are to be retained.

2.7 Changing Default File Replacement Behaviour

It is possible to alter default file replacement behaviour in circumstances where an MSI
installation or Patch is launched from a command line. This is achieved with the
REINSTALLMODE property or the /f command line switch. Otherwise default file
replacement rules will apply.
Default file replacement rules should suit most users.
It is desirable to change file replacement behaviour, in situations where the Date/Time
stamps of files might not support the required replacement of files.

2:10 12.0
 Global Server Installation Guide
Installation

2.7.1 Post Deployed .bat files

The .bat files which AVEVA installations deploy and edit are regarded as necessary for the
applications to work, and so could be repaired by the installation if they are removed.
However, they can be edited or replaced post deployment without risk, as long as the files
"Created Date" and "Modified Date" is different (this stops an MSI from overwriting the file).

2.7.2 Pre-Deployed .bat files

It is feasible to replace .bat files before deployment, in the case where deployments are
staged from Admin Installations. However the details and issues concerning Admin
Installations are beyond the scope of this manual.
It is also possible to add additional files to an MSI installation, but an MSI table editor of
some sort would be required. This is not a trivial option, and may well require the services of
a professional re-packager. However it can be accomplished without compromising an
installations ability to be patched.

2.7.3 .bat file Shortcuts

All the shortcuts pointing to the .bat files are of the non-advertised or normal type. As such
they can be deleted and edited, without triggering healing.

2.8 Network (Admin) Installations

2.8.1 What is an Administrative Installation?

Administrative Installation Mode is a type of .msi installation, which only causes an
uncompressed copy of the original installation to be generated to a specified location
(TARGETDIR). It does not install applications, it creates another installation.
The installations media (deployable files) is unpacked into a subfolder beneath the
regenerated .msi file, rather than stored in external .cab files or in .cab files embedded
within the .msi file itself. The resultant folder structure created resembles that, which a
(Typical) local deployment would create by default.
Administrative installations do not become installed onto the computer which spawned it.
They only transform the source installation into an uncompressed variant of itself during this
process.

2.8.2 Creating an Administrative Installation Point

To create an admin installation from an installation, start the installation from the Command
Line as follows:
MSIEXEC /A [Path to MSI File]
At the appropriate dialog

2:11 12.0
 Global Server Installation Guide
Installation

Then enter the location where the "Admin Installation" is to be created.

Conversely, the following Command Line will achieve the same result quietly:
MSIEXEC /A [Path to MSI File] /QN TARGETDIR=[Path to Admin Installation]

2.9 Issues with Administrative Installation Points

2.9.1 .NET Security

.NET security defaults to not allowing .NET program code to execute if it resides in a
network location. There are several ways to “Trust” such locations, but Trusted it must be, if
programs are to run across a network.
.NET security can cause issues when running Global across the network where the add-in
assemblies reside on a different machine to the .NET runtime. The default security level for
the local intranet is not set to Full Trust, which means that programs may not be able to
access resources on the local machine. To overcome this, the intranet security may be set
to Full Trust, though this means that any .NET assembly may run. Alternatively, Full Trust
may be given to a specified group of strongly named assemblies.
Full Trust is configured using the code access security policy tool caspol. First of all the
assemblies must be strongly named. Then caspol is run on each client machine to add all

2:12 12.0
 Global Server Installation Guide
Installation

the assemblies on a given server directory to a group and give Full Trust to this group as
follows:
To trust all assemblies in a given folder:
caspol -m -ag LocalIntranet_Zone -url \\<ServerName>\<FolderName>\*
FullTrust -n "<Name>" -d "<Description>"
OR to trust all assemblies with the same strong name:
CasPol.exe -m -ag LocalIntranet_Zone -strong –file
\\<ServerName>\<FolderName>\<assemblyName> -noname -noversion
FullTrust -n "Aveva" -d "Full trust for Aveva products"
where <ServerName> is the UNC (Uniform Naming Convention)
The format of a UNC path is:
\\<servername>\<sharename>\<directory>
where:

<servername> The Network name

<sharename> The name of the share

<directory> Any additional directories below the shared directory.

caspol can be found in c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ or is part of

the .NET Framework 2.0 SDK which can be downloaded from:
http://www.microsoft.com/downloads/details.aspx?FamilyID=fe6f2099-b7b4-4f47-a244-
c96d69c35dec&displaylang=en

2.9.2 Signing
Newer windows operating systems have code signing embedded into their security. As
such, AVEVA have begun signing .msi files and .cab files for installations which are not
restricted to Windows XP or older operating systems.
Unfortunately, the Administrative Installation process recreates and/or alters the source .msi
file and removes .cab files altogether, thus removing any file signatures. Changes to signed
file always invalidates its signature.

2.9.3 Using Files within the Source Installation

MSI databases can be authored to allow Features to be installed in the "Will be installed to
run from network" state. AVEVA Installations do not currently support this mode; however it
may be made available if requested.
The "Will be installed to run from network" option is otherwise known as run-from-network.
In this mode, files are not copied onto the target computer, but registry, shortcuts and file
edits do occur on the target computer, and they address the programs which reside inside
the source installation.

2.9.4 Network Throughput

Admin installations can be very suitable for staging large deployments, because
uncompressed installations usually travel better over networks because they are even more
fragmented. The overall size is typically much larger; however this is still tends to be easier
on Packet Switching Networks.

2:13 12.0
 Global Server Installation Guide
Installation

2.9.5 Advantages of a Network Installation

Once computers address files across a network, it becomes crucial that the files are
accessible whenever required. This then begs questions regarding:
• Network Reliability
• Network Performance
• File Server Reliability
• File Server Performance
• Change Synchronisation
• Change Granularity
Common reasons for storing programs on file Servers are:
• To avoid the network loading of large and un-staggered rollouts.
• To guarantee the user base is working with the same files.
• To prevent tampering with programs and settings.
• To maintain a tradition.
All of these issues are of course resolvable with locally deployed applications

Note: Direct editing of .msi's is discouraged in favour of Transforms (.mst files).

2.10 Running Global from Network Locations

Running programs directly from network locations is discouraged because:
• AVEVA installations have been redesigned to deploy well across networks.
• Network reliability and performance is less of a factor.
• Patch rollback functionality only works with local installations.
However, it is recognised that network based programs suit circumstances where:
• Multiple instances of the same program are required.
• An embedded tradition of working this way exists.
• Change impacts Quality Control systems.
So this information is provided to facilitate successful over network operation.
Definitive instructions on how to run AVEVA programs from network file servers are
impractical, given the many ways in which AVEVA programs can interact with each other
and with Project data. Not to mention other possible permutations.
So the following information is deliberately general and lacking in detail and it is aimed at
assisting a highly skilled readership.
The following things must happen if programs are to be run directly from a file server:
• The programs and the projects environment must be correctly defined.
• Appropriate .NET Trust should be granted to the programs network location.
• Visual Studio 2008 C++ Runtimes should be pre-installed.
• .NETFramework Redistributable should be pre-installed.
• The appropriate shortcuts and drive mappings should be provisioned.

2:14 12.0
 Global Server Installation Guide
Installation

2.10.1 Administrative Installation Points

The Files and Folders extracted to an "Administrative Installation Point" are laid out in a
fundamentally identical way to a local installation. Additionally, files which are normally
deployed to operating system folders will also be visible, but will play no functional part
unless deployed locally.
Some Configuration files will be incomplete, or have incorrect data in them, as they are not
edited until they are deployed (Locally). These files may require manual editing and concern
which Modules, Addins, Addons and "User Interface Modifications" are loaded.

2.10.2 Patching Administrative Installations

A slightly different Patch is required for an administrative installation than for a local
installation, and standard AVEVA patches target local installations. If such a Patch is applied
to an Administrative Installation Point, the patch will succeed. However, any local
installations which have previously been deployed from it will cease to recognise it as their
source installation. So as long as local deployments have not occurred, an Administrative
installation is patchable with an AVEVA patch. Similarly, if programs within the installation
are addressed by a clients own means, then the Administrative Installation can be patched
at any time with impunity. Since in this event the Installation has not been deployed (Locally)
and so only the media state has any effect.
AVEVA patches are supplied inside an executable wrapper. To apply them to an
administrative image, the patch must be extracted and the appropriated command line
used. The appropriate command switch is /C which extracts the contents to the current
folder.

Note: Patches cannot be rolled back from Administrative Installation Points. A copy must
be made before the patch is applied, in order to rollback.

Note: Patches cause changes to the .msi file, which invalidates any security certificates
applied to the installation.

2.11 Copying a Local Deployment to a File Server

Installing normally to a local computer and then copying the programs to a network location,
as a way to create a network based installation has several advantages over an
"Administrative Installation Point":
• The fundamental configuration file editing has happened.
• The Local installation need only include the required applications.
Note: Running a normal (Local) installation, and choosing a network drive as a target for
the programs will fail to install. This is because file editing is performed with the local
System Accounts credentials, which are not normally recognised by other
computers.

2:15 12.0
 Global Server Installation Guide
Installation

2.12 Feature Id Reference List

Feature Id Title Description

GLOBAL AVEVA Global Server Installs the Remote Procedure Call (RPC) Global
Server feature. This is required to allow Global
locations to communicate.

2.12.1 Feature Tree Hierarchy

The following diagram shows the Global installation SelectionTree by Feature Id's. Ancestor
(Parent) Features to the Left, Descendant (Child) Features to the Right.
GLOBAL

2.13 Selecting Features from the Command Line

Features can be in the following states:
• Run Locally
• Run from Source
• Not Present
• Advertised
There are several ways of controlling Feature states, but for the sake of clarity this
discussion will be limited to the ADDLOCAL and REMOVE Properties. The ADDSOURCE
Property is considered less relevant, as the "Will be installed to run from network" Feature
option, is not available to Features within this installation.
The ADDLOCAL and REMOVE Properties are comma separated lists of an installations'
Feature Id's. Any Features intended to be "Run Locally", will be listed in the ADDLOCAL
Property, whilst any Features intended not to be installed will be listed in the REMOVE
Property.
As previously stated, de-selection commands override inclusion commands. The reason for
this is because the REMOVE Property is evaluated after the ADDLOCAL property. The
partial list below shows the order in which FeatureState Properties are evaluated by the MSI
Service:
1. ADDLOCAL
2. REMOVE
3. ADDSOURCE
4. ADDDEFAULT
5. REINSTALL
6. ADVERTISE

2:16 12.0
 Global Server Installation Guide
Installation

2.14 Command Line Definable Directories

The following directories can be set on the Command Line, in the same way that Properties
are assigned.

Directory Id Explanation
PRODUCTDIR Root folder of the Global Application
TARGETDIR Target location for an Administrative Installation
ROOTDRIVE The Partition where All Applications will be targeted (unless
application directories are set).

As with Properties, Directories for which the Id's are all uppercase, can be re-defined on a
Command Line. They must also be addressed in uppercase on the Command Line,
because Id's are case sensitive.
e.g. PRODUCTDIR="C:\Some Path with Spaces in it\"
Will make Global install to:
"C:\Some Path with Spaces in it"
Rather than to:
C:\AVEVA\Global\12.0.SP6

Note: There is no space around the equals (=) sign.

Note: The quotes surround the value, and would be unnecessary is the value had no space
within it.

2.14.1 Sample Command Lines

A most definitive reference to MSI Command Line arguments can be found here. The
following examples have been tested, but are only intended to demonstrate general
Command Line principles.
In Windows 7 and Windows Server 2008 make sure that the command line has been
opened using the option Run as administrator so that the silent install application has the
correct User Access Control (UAC).

2:17 12.0
 Global Server Installation Guide
Installation

Example 1 Installing Everything

Installs all Features
Using the "E:\" drive.
Unattended Installation showing a progress bar with no cancel button and no finished
dialog. Never attempt to Reboot
Create a basic log
MSIEXEC /I [Path to MSI] /QB-! /L [Path to Log] ADDLOCAL=all ROOTDRIVE=E:\
REBOOT=ReallySuppress

Example 2 Removing an Installation

Uninstall everything showing a progress bar with a finished dialog and no cancel dialog
MSIEXEC /X [Path to MSI] /QB!

2:18 12.0