Global WCF Configuration Guide

Global WCF
Configuration Guide
AVEVA Solutions Limited
Disclaimer
1.1 AVEVA does not warrant that the use of the AVEVA software will be uninterrupted, error-free or free from
viruses.
1.2 AVEVA shall not be liable for: loss of profits; loss of business; depletion of goodwill and/or similar losses; loss of
anticipated savings; loss of goods; loss of contract; loss of use; loss or corruption of data or information; any
special, indirect, consequential or pure economic loss, costs, damages, charges or expenses which may be
suffered by the user, including any loss suffered by the user resulting from the inaccuracy or invalidity of any data
created by the AVEVA software, irrespective of whether such losses are suffered directly or indirectly, or arise in
contract, tort (including negligence) or otherwise.
1.3 AVEVA's total liability in contract, tort (including negligence), or otherwise, arising in connection with the
performance of the AVEVA software shall be limited to 100% of the licence fees paid in the year in which the user's
claim is brought.
1.4 Clauses 1.1 to 1.3 shall apply to the fullest extent permissible at law.
1.5 In the event of any conflict between the above clauses and the analogous clauses in the software licence under
which the AVEVA software was purchased, the clauses in the software licence shall take precedence.
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, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries.
All rights are reserved to AVEVA Solutions Limited 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 Limited. Where such permission is granted, it expressly requires
that this copyright notice, and the above disclaimer, 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 Limited. The user may not reverse
engineer, decompile, copy, or adapt the software. Neither the whole, nor part of the software described in this
publication may be incorporated into any third-party software, product, machine, or system without the prior written
permission of AVEVA Solutions Limited, save as permitted by law. Any such unauthorised action is strictly
prohibited, and may give rise to civil liabilities and criminal prosecution.
The AVEVA software described in this guide is to be installed and operated strictly in accordance with the terms
and conditions of the respective software licences, and in accordance with the relevant User Documentation.
Unauthorised or unlicensed use of the software is strictly prohibited.
Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved. AVEVA shall not
be liable for any breach or infringement of a third party's intellectual property rights where such breach results from
a user's modification of the AVEVA software or associated documentation.
AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom.
Trademark
AVEVA and Tribon are registered trademarks of AVEVA Solutions Limited or its subsidiaries. Unauthorised use of
the AVEVA or Tribon trademarks is strictly forbidden.
AVEVA product/software names are trademarks or registered trademarks of AVEVA Solutions Limited or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).
The copyright, trademark rights, or other intellectual property rights in any other product or software, its name or
logo belongs to its respective owner.
Global WCF Configuration Guide
Revision Sheet
Date Version Comments / Remarks

September 2011 12.1.1 Issued
January 2012 Copyright added to all pages.
January 2013 12.1.SP3 Updated section 1 Introduction, new statement added.
June 2013 12.1.SP4 Remove section Configuration Editor
Contents Page
Global WCF
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Guide Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:2
Software Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1

Microsoft .NET Framework v4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1

Transport Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Message Level Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3
Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:3
Specify Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4
Trust Boundaries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

Global Daemon Node Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:3
Certificate Based Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

Configure the WCF HTTP Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1
© Copyright 1974 to current year. i 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
WCF Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Enable RPC or WCF Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:6
WCF Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:6
Configure Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:8
No Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:8
Transport Level Security with Windows Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:8
Transport Level Security with SSL Certificate based Authentication . . . . . . . . . . . . . . . . . . 6:9
Message Level Security with Windows Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:10
Message Level Security with Certificate based Authentication . . . . . . . . . . . . . . . . . . . . . 6:10
Firewall Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1

Primary Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1
Open Ports in Windows Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1
Make AdmindWCF.exe a Trusted Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:3
Trouble Shooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:1

Configuration File Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:1
Buffer Too Small . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:1
Massive Base Product Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:2
Timeout Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:3
Missing AdmindWCF.exe.config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:3
Missing GlobalWCFClient.config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:4
Remote Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:4
Remote Daemon Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:5
Missing .NET Framework Files - Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:6
Missing .NET Framework Files - Base Product . . . . . . . . . . . . . . . . . . . . . . . . . . 8:6
Missing MS Enterprise Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:7
Binding mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:8
Additional Steps on Windows Server 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:8
Start a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:1

Setup Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:2
© Copyright 1974 to current year. ii 12 Series

Introduction
1 Introduction
AVEVA Global can be used to enhance projects created in either the AVEVA Plant or
AVEVA Marine group of products - henceforth known as the "base product" in this
document.
References to paths and directory settings in this document are used from AVEVA Plant and
should only be used as an example. Other base product paths and directory settings will be
different.
The Global WCF Configuration Guide describes how to configure the Windows
Communication Foundation (WCF) layer of security in AVEVA Global.
The user has the ability to use the WCF protocol in a Global project. The RPC protocol
continues to be available to the user if required.
Important: The Global Client of the base product (PDMS/Marine/Engineering) will by

default continue to use RPC as the security protocol until further configuration
changes are made (see later), although AVEVA Everything3D ™ is configured
with WCF by default.
Global has relied on RPC (Remote Procedure Call) for all inter-location communication.
There are a number of limitations in using the RPC protocol such as a dependency on using
port 135 for traffic and limited support of transport protocol bindings.
The main benefit of using WCF is that it can be fully customised. Through configuration files
the administrator can decide what levels of security to apply (described more in section
Security Features). Global WCF Configuration Guide
The operation of a Global project does not change as a result of enabling WCF functionality.
However the configuration of security has been abstracted from the software and is now
fully customisable through new XML configuration files.
WCF is enabled and configured by modifying values within XML configuration files
described later in section Enable RPC or WCF Security.
1.1 Assumptions
The Global WCF Configuration Guide targets the IT administrator or Global Project
Administrator. Knowledge of AVEVA Global will be helpful but is not essential.
The user must have the correct AVEVA license file before installing the AVEVA Global
Server. The license file is called AVEVA Licensing System (ALS). Refer to the AVEVA
Licensing System (ALS) guide for further information.
© Copyright 1974 to current year. 1:1 12 Series

Introduction
Global 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.
It is assumed that the reader has already installed the base product and Global Server with
the WCF functionality selected (refer to the base product Installation Guide).
1.2 Guide Structure

The guide is divided into chapters and appendices, as follows:
Software Checklist Covers any software and hardware dependencies that the
Global WCF has.
Security Features Describes the main security features that are available to
the administrator when using WCF.
Trust Boundaries Discussed what consideration must be made when

installing Global within a mixed network. Covers how WCF
can traverse different levels of trust boundary.
Certificate Based Describes how the user can apply Certificate based
Authentication authentication to messages and transport in WCF.
WCF Configuration Files Describes the different configuration files used to manage
Global WCF.
Firewall Configuration Describes the steps that must be taken to configure a

firewall to support WCF communication.
Trouble Shooting Common troubleshooting scenarios.
Start a Global Project A simple example of how to start the Global daemon using
the default installed files.

Software Checklist
2 Software Checklist
The user must check that the following items have been installed.
• A valid license file.
• Microsoft .NET Framework 4 (refer to Microsoft .NET Framework v4).
• The latest version of the base product with WCF enabled.
• The latest version of Global Server with WCF enabled.
The user can optionally configure the Global WCF to use a Secure Socket Layer (SSL)
certificate. If this is the case then the following pre-requisites apply:
• A pre-purchased SSL Certificate (described in detail in section Certificate Based
Authentication).
• Windows XP Service Pack 2 Support Tools (If the Operating System being used is
Windows XP). This is required if the steps described in section Bind Certificate With
Windows XP or Windows Server 2003 are to be followed.
Windows Server 2003 Service Pack 1 Support Tools (If the Operating System being used is
Windows Server 2003). This is required if the steps described in section Bind Certificate
With Windows XP or Windows Server 2003 are to be followed.
2.1 Microsoft .NET Framework v4

Windows Communication Foundation (WCF) is a feature that is provided with the Microsoft
.NET Framework.
To be able to run the WCF Global Server the user should check that the Microsoft .NET
Framework 4 has been installed onto all Global daemon computers. This is normally done
as part of the installation process.
The appropriate version of Microsoft .NET Framework is also required on base-product
installations required to initiate a Global operation.
Note: The 12.1.SP4 base product (Plant/Marine/Engineering) requires Microsoft .NET

Framework 3.5 SP1 rather than Microsoft .NET Framework 4.
The base product is installed with the appropriate .NET Framework incorporated and should
be consistent on all computers that Global is deployed to.

Software Checklist

Security Features
3 Security Features
When WCF is enabled as the security provider the administrator can take advantage of
different modes of security. WCF has two major modes of security; these are Transport
Level Security and Message Level Security.
All aspects of security are set within XML configuration files that are described later in WCF
Configuration Files.
The Global Server installation includes sample WCF Configuration files. These are
deployed in the sub-folder GlobalWCF_SampleConfigFiles. These should be used as a
basis when modifying existing Config files. Refer to WCF Configuration Files for further
information.
The following section gives the administrator an overview of the principles behind securing
Global using WCF as an authentication provider.
3.1 Transport Level Security

Transport security provides end to end security by securing the actual method of transport
that messages take between client and server. Transport security has the following
attributes:
• Once authenticated, always trusted.
• Transport security will not work when crossing more than one trust boundary.
• Once authenticated it can subject to threats such as tampering.
• Ideal for intranet communications.
Transport security in WCF depends on the Binding selected.

Security Features
3.2 Message Level Security

Unlike Transport Level Security, Message Level Security will encapsulate the security
credentials and claims with every message along with any message protection (signing or
encryption).
• The message must be authenticated by all recipients.
• Messages can only be read if credentials are verified
• Message security uses the WS-Security specification to secure messages
• Ideal for Internet communication.
3.3 Binding
The administrator can specify the low level communication protocol to use for data transfer.
The available bindings are as follows:
• Transmission Control Protocol (TCP)
• The same protocol used by existing Global RPC services.
• Binary data that is not visible to security checks
• Fast
• Better used for protected connections
• Hypertext Transfer Protocol (HTTP)
• Messages are sent in text, but are verbose
• Transparent to security checks
• Slower performance
• Ideal for unsecured internet connections
• Web Services Security Hypertext Transfer Protocol (wsHTTP)
• Secure encrypted HTTP.
3.4 Encryption
The administrator can configure WCF to encrypt messages along the way.
• Message encryption is ideal for connections made through the Internet without
protection.
• Not required if encryption is provided by the network connection (for example a
VPN).
• Different algorithms are supplied by WCF.

Security Features
• The user can apply proprietary algorithms.

• The default configuration is to use 128bit encryption.
• Up to 256bit encryption is supplied.
Note: Encryption can impact performance.
An example of encryption is illustrated later in section Message Level Security with

Windows Authentication.
3.5 Encoding
Encoding is tied in with the Binding configuration and determines how a message will be
encoded when sent from Client to Server and Server to Client.
• Text - through HTTP
• Verbose, slow but secure.
• Ideal for unprotected communications where performance is not a priority.
• Binary - through TCP
• Ideal for protected communications where performance is a priority.
• Message Transmission Optimisation Mechanism (MTOM) - through wsHTTP.
• An optimisation of Text and Binary. Intelligently sends data in text or binary
attachments.
3.6 Authentication
Authentication will make sure that communication is valid by checking that the sender and
recipient are valid.
• Messages are sent to a known recipient.
• Messages are received from a known sender.
Authentication can be applied to the connection or to each individual message.
Authentication can be through :
• Windows Login Accounts
• Can be used when communications are within the same domain/organisations. If
communication is between different domains/organisations then use Certification.
• Certification
• Use a certificate at both ends of communication to check authenticity.
• The user must purchase a valid certificate from a provider; refer to Certificate
Based Authentication for further information.
3.7 Certification
Certification makes sure that messages are verified between sender and recipient.
• Makes sure that messages are sent to a known recipient.
• Makes sure that messages are received from a known sender.
Certification is recommended for business to business (B2B) communications when
messages:
• Transgress the Internet.

Security Features
• Sent between corporate networks.

Certification can be applied to Transport or Message Level Security.
3.8 Specify Ports

Unlike RPC the user can specify any port when WCF is used as the authentication provider.
Depending on the Binding used the administrator may not need to specify a port, for
example in the case of HTTP the default port of 80 will be used.

Trust Boundaries
4 Trust Boundaries
Before choosing a security profile the administrator must consider the type of network
Global will be deployed to and what trust boundaries will be crossed.
Other influencing factors can be:
• What security is applied already on connections?
• Licence Servers may still need access through Firewalls.
• Database access may still need access through Firewalls.
• There may be a trade off in security verses performance.
The Trust Boundaries section describes the different types of trust boundary that can be
encountered in a networking environment and the theory behind how WCF can be
implemented to secure communications as they pass through these boundaries.
Consider the following network layout:
In this layout Global daemons must communicate with each other while passing through
varying layers of trust boundary. As a different layer of trust is encountered, the
administrator must consider configuring all the Global daemons in the project to
communicate using the (same) appropriate security policy that is robust enough to support

Trust Boundaries
the weakest level of trust boundary encountered within the project.

The different attributes of the trust boundaries illustrated in this diagram are examined
below:
Full Trust Boundary

In a full trust boundary there is a reduced risk of security threats because communication is
within the corporate network.
The network is an open system and therefore the administrator can consider configuring the
WCF Transport Level Security Mode set to None.
In this environment no security is required so the administrator can set the Binding to
unsecured method of communication such as basicHTTP or TCP. This will also allow for
faster data transfer within this type of network.
Encryption can be set to none.
The administrator could consider using Encoding. Binary through TCP would provide the
fastest solution.
Authentication None required.
Sample configuration files are supplied that demonstrate how to configure WCF Global to
use no security in an open network environment; this is also covered more in detail later in
section Configure Security.
Partial Trust Boundaries

In a zone where there is a partial level of trust the administrator can assume that some
degree of security must be applied. This will in most cases depend on individual
configurations.
WCF provides the flexibility to be able to apply varying levels of security. The administrator
can select from pre-build sample configuration files supplied with the Global, refer to
Configure Security for further details.
No Trust Boundaries
In a no trust zone there is a high risk of security threats.
The network is a closed system and therefore the administrator must consider configuring
WCF with a high level of security.
The administrator must use Transport Level Security where connections are already
protected through a VPN (Virtual Private Network) and Message Level Security where there
is no VPN.
Note: When a high level of security is applied there will be degradation in performance.
The administrator must consider one of the following secure Bindings:
wsHTTP Most secure
basicHTTP Where external filters verify messages
TCP Faster, but cannot verify contents
The administrator must consider applying data Encryption.

Trust Boundaries
No encryption is necessary for VPN connections because the VPN connection inherently
uses an encryption algorithm. If the connection is not a VPN then at least a 128bit
encryption algorithm should be used.
The administrator should use text Encoding which can be verified.
For Authentication use Windows Authentication if on the same domain and Certification if
not.
There are sample configuration files for Windows authentication and SSL Certified settings.
Sample configuration files are described later in section Configure Security.
4.1 Global Daemon Node Communication

The Global daemon operates in two parts, a client and service. This architecture gives the
administrator the opportunity to configure the way that the service listens and how data is
transmitted through the client.
The client and service have their own configuration files that are maintained separately. The
AdmindWCF.exe.config file controls configuration of the service and the
GlobalWCFClient.config file controls configuration of the client.
The nature of these configuration files is described in detail in section Configure Security.
The following describes the theory behind how the administrator should configure settings
between computer nodes hosting Global daemons. The binding used must be consistent
across all nodes/trust boundaries.
In the illustration above each circle represents a different physical computer node. Each
node is running an instance of the Global daemon. Each node will have its own
AdmindWCF.exe.config and GlobalWCFClient.config file.
The left and right Satellite nodes are configured to use wsHTTP for client and service. The
central Hub node is able to communicate with both by having an endpoint exposed for
wsHTTP. Endpoints are discussed further in section WCF Endpoint.
Note: Multiple end points are not currently supported, therefore a Global project must use
the same binding configuration (NetTCP, HTTP or wsHTTP) across all daemon
nodes for the project (i.e. Hub to Sat and Sat to Sat).
Different projects can use different configurations by having a separate copy of the Global
server installation (and therefore configuration files) for each project.

Trust Boundaries

Certificate Based Authentication
5 Certificate Based Authentication
It is possible to configure Global WCF to authenticate Global data exchanges against a valid
SSL certificate.
The following section describes how to prepare and install a certificate ready for use by
Global WCF.
If the user does not intend to use an SSL certificate then skip to section WCF Configuration
Files.
5.1 Configure the WCF HTTP Endpoint

Authentication can be configured for base product to Daemon, or Daemon to Daemon
communications.
The following steps describe the configuration process to bind an x.509 SSL Certificate to
a Hypertext Transfer Protocol (HTTP) port for the purpose of authenticating incoming
requests.
A certificate must be obtained from a Root Authority such as Verisign or Thawte, refer to the
following web pages for more information:

http://www.verisign.co.uk/ssl/
http://www.thawte.com/ssl/
The user must install the certificate on Server machine.
The certificate on the Server machine will be validated against the root Certification
Authority (CA) as shown below:
• Open Certificates Snap In

The user must first open a Certificate Snap In inside the Machine Management Console
(MMC).
• Click Start > Run and then type Command to open a Command Prompt window.
• Type mmc and click the ENTER key.
Note: To view certificates in the local machine store, the user must be logged in as an
Administrator.
• Click File > Add/Remove Snap In.

• Click Add.
• In the Add Standalone Snap-in window, select Certificates.
• Click Add.
• In the Certificates snap-in window, select Computer account and click Next. If the
user is not logged in as an Administrator, then that user can only manage certificates
for the currently logged in account.
• In the Select Computer window leave the default selection Local computer and click
Finish.
• In the Add Standalone Snap-in window click Close.
• On the Add/Remove Snap-in window click OK.

• In the Console Root window, click Certificates (Local Computer) to view the
certificate stores for the computer.
• Import Certificate
From the MMC the user can import a pre-purchased certificate.
• Navigate to Certificates (Local Computer) > Personal > Certificates.
• Right click Certificates and select All Tasks > Import.
• The Certificate Import Wizard will guide the user through importing a certificate file.
• Obtain Certificate Thumb Print

After importing a certificate the user must obtain the certificate thumb print.
• Navigate to Certificates (Local Computer) > Personal > Certificates and select
<your certificate name>. In the following example the certificate is listed as
'tempCert'.
• Double Click on the certificate to open a Certificate window.

• Click the Details Tab.
• Select the Thumbprint option from the list.

• Copy the hexadecimal string to the Windows clipboard by highlighting the string and
pressing down CTRL+C on the keyboard.
• Bind Certificate With Windows Vista, Windows Server 2008 r2 or Windows 7

If the user is running the Windows XP or Windows Server 2003 Operating System then skip
to section Bind Certificate With Windows XP or Windows Server 2003.
Bind the certificate to an HTTP port by using the following command on the command
prompt:
netsh http add sslcert ipport=0.0.0.0:8000
certhash=7cc85c21bbdcfc68e630d4a497d4948298ebdcb7
appid={00112233-4455-6677-8899-AABBCCDDEEFF}
Note: The above is one command and should be entered on 1 line.
At the certhash parameter, paste the value copied to the clipboard in the previous steps
making sure that spaces are removed from the hexadecimal string.
Note: If the user enters an invalid thumbprint, the command will still succeed, but the client
will not be able to communicate with the service as the thumbprint does not refer to a
valid certificate.
• The certhash parameter specifies the thumbprint of the certificate.

• The ipport parameter specifies the IP address and port.
Note: The IP address 0.0.0.0 specifies the local computer.
• The appid parameter is a random GUID (Globally unique identifier) that can be used to
identify the owning application.

• Bind Certificate With Windows XP or Windows Server 2003

On Windows XP and Windows Server 2003 configurations the Netsh.exe command is not
supported. The user can however use the httpcfg command supplied with Microsoft
Support Tools.
The user can download the Windows XP Support tools from the following site:
http://www.microsoft.com/downloads/details.aspx?FamilyId=49AE8576-9BB9-4126-9761-
BA8011FABF38&displaylang=en
The Windows Server 2003 Support Tools can be downloaded from the following site:
http://support.microsoft.com/kb/892777
After installing the support tools use the following command to bind an SSL certificate with a
chosen HTTP port:
httpcfg set ssl -i 0.0.0.0:8012 -h
7cc85c21bbdcfc68e630d4a497d4948298ebdcb7
Note: The above is one command and should be entered on 1 line.
At the -h parameter, paste the value copied to the clipboard in the previous steps making
sure that spaces are removed from the hexadecimal string.
If this command is successful, it will report the message:
"HttpSetServiceConfiguration completed with 0."
Note: If the user enters an invalid thumbprint, the command will still succeed, but the client
will not be able to communicate with the service as the thumbprint does not refer to a
valid certificate.
This command binds the certificate with the thumbprint indicated with the -h flag to the port
indicated by the -i flag. The port is specified as the IP address of the computer followed by
the port. The IP address 0.0.0.0 specifies the local computer.

WCF Configuration Files
6 WCF Configuration Files
Global WCF makes use of configuration files to load runtime settings for connecting to
remote locations and to determine the security settings applied to Global communications.
Constructor Module Configuration files are configuration files used by any base product
module that supports Global operation either directly or through data extracts (for example
Admin, Design or Draft).
All Constructor Module Configuration files reference the GlobalWCFClient.config file
(described later) for WCF configuration data. If GlobalWCFClient.config is absent, or not
referenced from adm.exe.config or Constructor module config files, then Global will default
back to using RPC communication.
In most cases the administrator will not need to modify the content of the Constructor
Module Configuration files.
A complete list of Constructor Module configuration files is listed below.
adm.exe.config Used to configure the base product Admin Module for use with
the WCF Global Server.
des.exe.config Used to configure the base product Design Module for use with
diagrams.exe.config Used to configure the base product Diagrams Module for use
with the WCF Global Server.

tags.exe.config Used to configure the base product Tags Module for use with
draw.exe.config Used to configure the base product Draw Module for use with
dra.exe.config Used to configure the base product Draft Module for use with
the WCF Global Server, (only available with PDMS).
iss.exe.config Used to configure the base product IsoDraft Module for use
with the WCF Global Server.
smm.exe.config Used to configure the base product Schematic Model Manager

Module for use with the WCF Global Server.
spc.exe.config Used to configure the base product Specon Module for use with
marodes.exe.config Used to configure AVEVA Marine applications:

marhdes.exe.config Outfitting Design, Hull Design, Outfitting Draft and Hull Draft.
marodra.exe.config
mardra.exe.config
In addition to the Constructor Module configuration files the following configuration files are
provided:
AdmindWCF.exe.config Used to determine server side security settings for

daemons.
GlobalWCFClient.config Contains the main client side configuration settings used

for WCF communication.
The file GlobalWCFClient.config file is used for
determining client-side security settings - both for client
daemon to server daemon communications and base
product to server daemon.
Note: The content of the base product and Global Server

GlobalWCFClient.config must be consistent.
The Global daemon is a client/server application. The server will listen to inbound
communication by using a service with exposed Endpoints (discussed later in section WCF
Endpoint). Outbound communication is handled by the client. The configuration of client and
service are maintained in separate files:

The figure below illustrates the use of the configuration files when multiple nodes are
present.
On the base product workstation the constructor module adm.exe.config is shown to

reference the GlobalWCFClient.config file stored locally on that node. The copy of the
Globalwcfclient.config file on the base product work station contains all of the WCF client
configuration settings for being able to communicate with Global at a different location.
The base product machine is a client therefore there is no requirement for the
AdmindWCF.exe.config (which is required only for service configuration).
The Cambridge node has its own AdmindWCF.exe.config and GlobalWCFClient.config
file.
Referring to the illustration above, the base product configuration files will be located in the
folder in which the base product was installed. Refer to the relevant installation guide.
For PDMS, an example default installation path would be:
C:\AVEVA\Plant\PDMS12.1.xx (where xx = <version number>)
For AVEVA Everything 3D™, an example default installation path would be:
C:\Program Files (x86)\AVEVA\Plant\E3Dx.xx. (where x.xx =
<version number>)
Each of the Global Server nodes will have an instance of the Global Server files installed to
the following path:

C:\AVEVA\GlobalServer (PDMS)
or
C:\Program Files (x86)\AVEVA\Global Server (AVEVA Everything
3D™)
Important: Only edit XML configuration files inside a plain text ANSI editor to avoid file
corruption. Do not open the configuration files inside a text editor that uses Rich
Text such as Microsoft WordPad. AVEVA recommend editing the files inside
Microsoft Notepad unless a suitable XML editor is available.
Sets of sample configuration files are available for different Protocols and Security options.
These are available in a sub folder of the Global installed product. For example
C:\Program Files (x86)\AVEVA\Global
Server\GlobalWCF_SampleConfigFiles
The supplied configuration files are example only.
For more complex configurations containing multiple endpoints, refer to AVEVA Support.
Updates to Configuration files and those for previous versions will be made available
through the Knowledge base for the Global product on the AVEVA Helpdesk.
On the Knowledge Base, the files are supplied in a version specific ZIP file attached to the
relevant Knowledge base item. The contents of the GlobalWCF_SampleConfigFiles folder
file must be extracted to a folder before they can be viewed or edited.
The GlobalWCF_SampleConfigFiles folder is situated below the Global Installed folder, for
example:
C:\AVEVA\GlobalServer12.1.xx (where xx = <version number>)
or
C:\Program Files (x86)\AVEVA\GlobalServer12.1.xx (where xx =
<version number>)
Each folder contains 2 files:
• admindWCF.exe.config
• GlobalWCFClient.config
The following sub-folders will be created below the GlobalWCF_SampleConfigFiles folder
for each different sample configuration:
• MessageSecurityCertificateAuthentication\basicHttp
• MessageSecurityWindowsAuthentication\netTcp
• MessageSecurityWindowsAuthentication\wsHttp
• NoSecurity\basicHttp
• NoSecurity\netTcp
• NoSecurity\wsHttp
• TransportSecurityCertificateAuthentication\basicHttp
• TransportSecurityCertificateAuthentication\netTcp
• TransportSecurityCertificateAuthentication\wsHttp
• TransportSecurityWindowsAuthentication\basicHttp
• TransportSecurityWindowsAuthentication\netTcp

• TransportSecurityWindowsAuthentication\wsHttp
Important: The globalWCFClient.config file used by the Global client in the base product
(PDMS, AVEVA Everything3D™ and related products) must be consistent with
the config files used by the Global daemon. The file admindWCF.exe.config
must contain a suitable endpoint to receive communications from the base
product.
Open the AdmindWCF.exe.config or GlobalWCFClient.config file in an XML or text

editor.
Important: AVEVA recommend editing the files inside Microsoft Notepad if an XML editor is
not available. Only edit XML configuration files inside a plain text ANSI editor to
avoid file corruption. Do not open the configuration files inside a text editor that
uses Rich Text such as Microsoft WordPad.
Note: Sets of sample configuration files are supplied as part of the Global Server
installation in the sub-folder GlobalWCF_SampleConfigFiles. Config files must be
deployed consistently for both Global Server and Global Client throughout a Global
project. The appropriate GlobalWCFClient.config file must be deployed to all Base
products which use Global.
Sample Configuration files are supplied for different Security settings and Bindings.

6.1 Enable RPC or WCF Security

The user must modify the GlobalWCFClient.config to enable WCF functionality in the base
product.
An advanced user can edit the content of the GlobalWCFClient.config file directly.
Locate the following GLOBAL_PROTOCOL key:
The user can toggle the value between WCF or RPC.

Set the value to WCF to use WCF as the authentication provider.
<add key="GLOBAL_PROTOCOL" value="WCF" />
Important: If the GLOBAL_PROTOCOL key is not present in the configuration file then the
default of RPC will be used.
Note: The user must close and re-open the base product if the communication method is
changed.
6.2 WCF Endpoint

As a service the Global Daemon exposes endpoints. The term ‘Endpoint’ is used to describe
an address that can be specified where the Service will listen for incoming communications.
This address is used by the base product and Daemon clients to establish a communication
connection for transferring of messages.
An Endpoint consists of:
Address Location on the Internet/Intranet where the Daemon Service can be

reached.
Binding what transport protocol the communication should occur on.
Contract What the Service does.
Baseaddress:
The user must configure the baseaddress key in both the GlobalWCFClient.config file
and the AdmindWCF.exe.config file.
<appSettings>
<add key="baseaddress" value="http://localhost:8000/
Design_Time_Addresses/GlobalWcfServiceLib/
GlobalWcfService_11_1_201011/" />
<add key="GLOBAL_PROTOCOL" value="RPC" />

</appSettings>
In the above example the HTTP protocol is used. Depending on the requirement the
protocol can be changed to HTTPS or NET.TCP (this must be consistent with the chosen
Binding).
The value localhost can be replaced with the name of the computer running the daemon (if
on a different machine).
Note: Better performance can be achieved if using localhost than the hostname of the
local machine if on the same machine.
The value 8000 determines the port number used for WCF communication. The value can
be set to any port number, although the administrator must make sure that the port is not
blocked by a firewall (refer to Firewall Configuration).
The Design_Time_Addresses will be automatically replaced at run time with the UUID
(Universally Unique Identifier) as specified in the base product project.
The remainder of the baseaddress must be left unchanged.
Note: Multiple end points are not currently supported, therefore a Global project must use
the same binding configuration (NetTCP, HTTP or wsHTTP) across all daemon
nodes for the project (i.e. Hub to Sat and Sat to Sat).
Note: Different projects can use different configurations by having a separate copy of the
Global server installation (and therefore configuration files) for each project.
Binding:
The binding determines the transfer protocol for the communication. The user must edit the
Client binding in the GlobalWCFClient.config file and the Service binding in the
AdmindWCF.exe.config file.
Open the GlobalWCFClient.config file and locate the following Client code block:
<client>
<endpoint address="" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IGlobalWcfService"
contract="IGlobalWcfService_11_1_201011"
name="WSHttpBinding_IGlobalWcfService">
</endpoint>
</client>
Edit the binding attribute to one of the following supported Binding values:
• BasicHTTP –raw HTTP such as a Web page.
• wsHTTP –secured HTTP such as a Banking web page.
• netTCP –TCP such as RPC communications.
Important: Other than the Binding the user must leave the parameters unchanged.
Open the AdmindWCF.exe.config file and locate the following code Services block:
<services>
<service behaviorConfiguration="GlobalWcfServiceBehavior"
name="GlobalWcfServiceLib.GlobalWcfService">
<endpoint address=""
binding="basicHttpBinding"

bindingConfiguration="BasicHttpBinding_IGlobalWcf
Service"
contract="GlobalWcfServiceLib.IGlobalWcfService_1
1_1_201011"
behaviorConfiguration="ValidationBehavior">
</endpoint>
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
</services>
Edit the service binding in the same way described for the client binding.
Note: The settings made in the GlobalWCFClient.config and AdmindWCF.exe.config

files must be consistent.
6.3 Configure Security

The following section describes the parts of the configuration file that determines what
security is applied when Global is deployed.
There are 3 modes of security that can be applied
• None
• Transport
• Message
6.3.1 No Security
For all netTcp, basic Http and wsHttp bindings security is disabled when the Security Mode
value is set to None:
<security mode="None">
</security>
To view an example of configuration files with no security, navigate to the Samples folder
GlobalWCF_SampleConfigFiles and navigate to the sub-folder NoSecurity [Folder
NoSecurity should be the appropriate sub-folder for the section].
6.3.2 Transport Level Security with Windows Authentication

Windows authentication can be used only within an Intranet scenario where Global
daemons are deployed inside of a secured network or sites connected through a VPN
(Virtual Private Network).
Note: It is assumed that where the login details are the same.
The following XML is used to configure the binding to use Windows based authentication.
<security mode="Transport">
<transport clientCredentialType="Windows" proxyCredential-
Type=”None” realm=”” />
</security>
Note: The settings made in the GlobalWCFClient.config and AdmindWCF.exe.config
files must be consistent.
Transport security assumes that once connected messages are safe.

To view an example of configuration files with Windows authentication, extract the contents
of the GlobalWCF_SampleConfigFiles folder and navigate to the sub folder
TransportSecurityWindowsAuthentication.
6.3.3 Transport Level Security with SSL Certificate based Authentication

Certificate based authentication can be used when Global daemons are communicating
through an unsecured network or different trust boundaries.
The following XML is used to configure the binding to use Certificate based authentication.
Note: The following setting must be consistent within the GlobalWCFClient.config and
AdmindWCF.exe.config files.
<security mode="Transport">
<transport clientCredentialType="Certificate"/>
</security>
Note: The user must make sure that a certificate has been pre-installed and configured.
Refer to the section Certificate Based Authentication.
The user must specify information about the certificate to enable network level security with
certificate authentication.
The following block is specified in the Service behaviour and must be modified in the
<serviceBehaviors>
<behavior name="GlobalWcfServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceCredentials>
<clientCertificate>
<authentication trustedStoreLocation="LocalMachine"
certificateValidationMode="None">
</authentication>
</clientCertificate>
<serviceCertificate findValue="tempCert"
x509FindType="FindBySubjectName" storeLoca-
tion="LocalMachine" />
</serviceCredentials>
</behavior>
</serviceBehaviors>
The user must specify:
httpsGetEnabled Must be set to true
trustedStoreLocation The location of the trusted store for the certificate
findValue Certificate identifier within the trusted store Refer to

x509FindType The type of find value for the search
storeLocation Certificate Store: localMachine/Currentuser (determined by

the certificate).

The GlobalWCFClient.config file has an equivalent <endpointBehaviors> element

that must be modified to match the configuration changes made in the Service Behaviours
of the AdmindWCF.exe.config file.
To view an example of configuration files with Certificate based authentication, extract the
contents of the GlobalWCF_SampleConfigFiles folder file and navigate to the sub folder
TransportSecurityCertificateAuthentication.
6.3.4 Message Level Security with Windows Authentication

Message level security can be enabled for scenarios where Global daemons need to make
sure each message exchanged is protected. Windows authentication can only be used
where the Global daemons are deployed in same domain or in two trusted domains.
<security mode="Message">
<transport clientCredentialType="Windows"
proxyCredentialType="None" realm="" />
<message clientCredentialType="Windows"
negotiateServiceCredential="true"
algorithmSuite="Basic128Sha256Rsa15"
establishSecurityContext="true" />
</security>
To view an example of configuration files with Message Level Security using Windows
authentication, extract the contents of the GlobalWCF_SampleConfigFiles folder file and
navigate to the sub folder MessageSecurityWindowsAuthentication.
6.3.5 Message Level Security with Certificate based Authentication

In addition to Windows Authentication, Message Level Security can be configured to use an
SSL certificate to authenticate the exchange of messages.
Note: Message Level Security with Certificate based Authentication is a more complicated
option compared to Windows Authentication. There can also be a loss in
performance based on the size of the message and strength of the SSL certificate
used for authentication.
<security
authenticationMode="MutualCertificate"
requireDerivedKeys="false"
messageProtectionOrder="SignBeforeEncrypt"
messageSecurityVersion="WSSecurity11WSTrustFebruary2005WSSecu
reConversationFebruary2005WSSecurityPolicy11BasicSecurityProf
ile10">
<secureConversationBootstrap />
</security>

The Security parameters are described below:
authenticationMode How the certificate is authenticated
requireDerivedKeys Required security setting relating to Certificate keys
MessageProtectionOrder How the message is signed
messageSecurityVersion Determines the Web-standards to apply to messages
The following block is specified in the Service behaviour and must be modified in the
The user must specify:
httpsGetEnabled Must be set to true
trustedStoreLocation The location of the trusted store for the certificate
findValue Certificate identifier within the trusted store
x509FindType The type of find value for the search
storeLocation Certificate Store: localMachine/Currentuser (determined by

the certificate).
<serviceBehaviors>
<dataContractSerializer
maxItemsInObjectGraph="2147483647"/>
<serviceMetadata httpGetEnabled="true"/>
<serviceCredentials>
<clientCertificate>
<authentication trustedStoreLocation="LocalMachine"
certificateValidationMode="None"></authentication>
</clientCertificate>
<serviceCertificate findValue="tempCert"
x509FindType="FindBySubjectName"
storeLocation="LocalMachine"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
The GlobalWCFClient.config file has an equivalent <endpointBehaviors> element
that must be modified to match the configuration changes made in the Service Behaviours
of the AdmindWCF.exe.config file.
To view an example of configuration files with Message Level Security using Certificate
based authentication, extract the contents of the GlobalWCF_SampleConfigFiles folder
file and navigate to the sub folder MessageSecurityCertificateAuthentication.


Firewall Configuration
7 Firewall Configuration
The administrator must make sure that a firewall is correctly configured to allow Global WCF
to operate correctly.
Attention must be paid to the choice of ports that are used when the administrator modifies
the WCF Configuration Files supplied with Global WCF.
When the user configures the WCF Endpoint, in most cases a binding will be made to a
specific port (for example port 8001). The administrator must make sure that the port is not
blocked in any way by a firewall.
7.1 Primary Considerations

In a corporate network the following main points must be addressed to correctly configure a
firewall to support WCF communication:
The user must open the port number on the protocol according to the configuration files
(refer to WCF Configuration Files). The Global WCF default protocol is HTTP on port 8000
(the default HTTP Port of 80 is used if a port is not specified).
Each Global project should be configured to run on its own port, so the user may need to
open a range of ports.
It is possible to make use of an existing Firewall configuration previously used by RPC. One
of the TCP ports in the dynamic range (ports >1024) can be configured to be used by WCF.
If the dynamic port range has been restricted (if the Group policy registry edits as suggested
in the original RPC IT Configuration such as 5000-5020), the port used should be within this
range.
If RPC is no longer used in a project then the administrator is advised to secure the ports
previously used for RPC communication, this is primarily port 135.
7.2 Open Ports in Windows Firewall

The choice of firewall technology implemented in an organisation will vary, but to illustrate a
configuration the following section shows how the administrator can configure the built in
firewall supplied with Microsoft Windows XP.
Although simplified, the principles demonstrated in this section apply to all firewall vendors.
In Windows XP click Start > Control Panel.
Double click to open the Windows Firewall.

Note: In some cases the Firewall configuration can be can be controlled by a Group Policy
on the network Domain Controller. In this case the administrator can configure the
firewall settings centrally on the domain controller. The same principles described
here will apply.
Click the Exceptions tab.

Click Add Port.

Add a descriptive name and then specify the port that has been set up for the WCF
Endpoint.
Important: The administrator must repeat the process to add an open port to any satellite
daemons on other machines in the network to establish a clear two way
communication without being blocked by the firewall.
Click OK save the changes.
7.3 Make AdmindWCF.exe a Trusted Application

With the Windows Firewall Exceptions tab still open from the previous section click on Add
a Program.
A window will be displayed that allows the user to add a program to a list of trusted
applications. When the selected applications attempts to communicate over the network it
will be considered trusted communication and will not be blocked by the Windows firewall.
The user must add the AdmindWCF.exe file located in the following folder:
C:\<globalserver_installed_path><version number>


Trouble Shooting
8 Trouble Shooting
8.1 Configuration File Limits

In some scenarios certain maximum limits set in the configuration file effect the operation of
Global WCF.
A series of error scenarios is listed below with suggested solutions:
8.2 Buffer Too Small

Error description:
Global stops operating and returns the following error " The remote server returned an
unexpected response: (400) Bad Request."
Solution:
Double the existing values of the maxReceivedMessageSize and maxBufferSize
attributes.
Note: the maxBufferSize attribute is available only in basicHttpBinding.
The minimum size for these attributes is 64KB (65536 bytes) and Maximum allowed value is
4 GB (4294967296 bytes).
The following table summarizes all suggested memory sizes and equivalent decimal values.
Size Value Size Value Size Value

64KB 65536 4MB 4194304 256MB 268435456
128KB 131072 8MB 8388608 512MB 536870912
256KB 262144 16MB 16777216 1 GB 1073741824
512KB 524288 32MB 33554432 2 GB 2147483648
1MB 1048576 64MB 67108864 4 GB 4294967296
2MB 2097152 128MB 134217728
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IGlobalWcfService"
closeTimeout="00:01:00" openTimeout="00:01:00"
receiveTimeout="00:10:00" sendTimeout="00:01:00"

Trouble Shooting
transferMode="Buffered" messageEncoding="Mtom"
maxBufferPoolSize="1048576" maxBufferSize="1048576"
maxReceivedMessageSize="1048576">
<readerQuotas maxDepth="32"
maxStringContentLength="1048576"
maxArrayLength="1048576" maxBytesPerRead="4096"
maxNameTableCharCount="16384" />
</security>
</binding>
</basicHttpBinding>
</bindings>
8.3 Massive Base Product Projects

Error description:
In some situations the below error can occur while working with massive base product
projects with a large number of databases (of more than 5000).
"Failed send Reply to HUB: There was an error while trying to serialize parameter http://
tempuri.org/:results. The InnerException message was 'Maximum number of items that can
be serialized or deserialized in an object graph is '65536'. Change the object graph or
increase the MaxItemsInObjectGraph quota '."
Solution:
Double the quota for the MaxItemsInObjectGraph attribute. Refer to the table for
suggested values. The minimum size for this attribute is 64KB (65536 bytes) and Maximum
allowed value is 2 GB (2147483647 bytes).
<behaviors>
<endpointBehaviors>
<behavior name="ValidationBehavior">
<dataContractSerializer maxItemsInObjectGraph="
1048576"/>
<validation enabled="true" ruleset="RuleSetA" />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<dataContractSerializer
maxItemsInObjectGraph="1048576"/>
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>

Trouble Shooting
8.4 Timeout Too Low

Error description:
If the communication channel (Internet or Intranet connection) between two install locations
is slow, there could be the possibility of a timeout event being trigged before the intended
operation has completed. In that situation the user might get the following error:
"The request channel timed out while waiting for a reply after 00:01:00. Increase the timeout
value passed to the call to Request or increase the SendTimeout value on the Binding"
Solution:
To avoid a timeout error, increase the following highlighted Timeout values until this error is
no longer occurs:
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IGlobalWcfService"
closeTimeout="00:01:00"
openTimeout="00:01:00"
receiveTimeout="00:10:00"
sendTimeout="00:01:00"
transferMode="Buffered"
messageEncoding="Mtom"
maxBufferPoolSize="1048576"
maxBufferSize="1048576"
maxReceivedMessageSize="1048576">
<readerQuotas maxDepth="32"
maxStringContentLength="1048576" maxArrayLength="1048576"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
</security>
</binding>
</basicHttpBinding>
</bindings>
Example : <Hours>:<Minutes>: <Seconds>
00 : 02 : 00
8.5 Missing AdmindWCF.exe.config

Error description:
The daemon does not start and reports the error below:

Trouble Shooting
Solution:
The AdmindWCF.exe.config file is missing from the AVEVA_DESIGN_EXE directory.
The AdmindWCF.exe.config file will be installed from installation, check that the file has not
been deleted.
8.6 Missing GlobalWCFClient.config

Error description:
The daemon starts, but reports the error below:
Solution:
The globalWCFClient.config file is missing from the AVEVA_DESIGN_EXE directory.
The globalWCFClient.config file will be installed from installation, check that the file has not
been deleted.
8.7 Remote Ping

Error description:
A remote Daemon ping failed.
Solution:
Base product gives the same error when the local daemon is down.
Base product will give the same error if running the RPC daemon.

Trouble Shooting
Check for the below highlighted error and make sure that the daemon is running. Refer also
to Remote Daemon Down.
8.8 Remote Daemon Down

Error description:
Error when trying to contact a remote daemon which is down
Solution:
Check for a TCP error 10061 as shown below:

Trouble Shooting
Check and restart the remote daemon.
8.9 Missing .NET Framework Files - Daemon

Error description:
A long error is output in the console similar to that shown below:
Solution:
The error is generated because files are missing in the Operating System that Global has a
dependency on.
The highlighted reference number is an indication that Global is attempting to locate files
that are part of the .NET Framework 4.
Refer to section Microsoft .NET Framework v4 and download version 4 of the Microsoft
.NET Framework.
8.10 Missing .NET Framework Files - Base Product

Error description:

Trouble Shooting
The base product monitor console outputs a truncated error as shown below:
Solution:
dependency on.
The highlighted reference number is an indication that Global is attempting to locate files
that are part of the .NET Framework 3.5.
Refer to section Microsoft .NET Framework v4 and download version 3.5 of the Microsoft
.NET Framework.
8.11 Missing MS Enterprise Library

Error description:
A long error is output in the console similar to that shown below:

Trouble Shooting
Solution:
dependency on.
The highlighted reference is an indication that the Microsoft Enterprise Libraries cannot be
found.
Microsoft Enterprise Library 4.1 is installed by default but if the user is copying the daemon
components to another workstation then the following components must also be copied:
8.12 Binding mismatch

Error description:
To successfully complete a communication the client and the target service must use the
same binding
The example below is a netTCP binding client trying to connect to a HTTP binding Service:
Solution:
The user must modify the configuration files so that the client and service communicate
using the same binding. Refer to WCF Configuration Files.
8.13 Additional Steps on Windows Server 2008

The user must complete additional steps if the installed operating system is Windows Server
2008.

Trouble Shooting
In Windows Server 2008 there are two default install locations, one for 32bit applications
(C:\Program Files(x86)) and one for native 64bit (C:\Program Files).
The WCF Global Server has a dependency on files that are by default installed into the
following path on a Windows Server 2008 machine:
C:\Program Files(x86)\Microsoft Enterprise Library 4.1 - October 2008\Bin\
The user must manually copy all DLL files from this folder to the following location, for
example:
C:\AVEVA\PLANT\PDMS12.1.1\
Or to:
C:\AVEVA\GlobalServer12.1.1\
Note: The user must have Administrative rights to be able to copy files from the C:\Program
Files(x86) folder

Trouble Shooting

Start a Global Project
9 Start a Global Project
Once the Global daemon files have been configured, Global will operate in the same way
that it has historically done so for RPC.
Start a Global Project section summarises in brief how to start an instance of Global on a
machine. Throughout the section reference is made to the Global User Guide which
describes then standard process of starting a daemon. Any differences in WCF
configuration are clearly highlighted in this section.
The administrator must first prepare a project in the base product for use with Global refer to
the Global User Guide (section 4.2 Making the Project Global).
In brief the administrator must load the Admin module within the base product and issue the
following commands at the command line to convert the project for Global use:
Lock
make global
unlock
The user must continue to refer to the Global User Guide to Initialise the Hub location.
Navigate to base product folder:
C:\AVEVA\plant\PDMS12.1.1
Referring to Enable RPC or WCF Security locate the file GlobalWCFClient.config and set
the protocol key within the GlobalWCFClient.config file to WCF.
<add key="GLOBAL_PROTOCOL" value="WCF" />
Global Server is supplied with singleds.bat and multids.bat sample batch files that can be
used to start the Global daemon. The operation of these batch files is consistent with that of
RPC, however these is an addition of a new GLOBAL_PROTOCOL key which controls
whether RPC or WCF is to be used.
Refer to the Global User Guide (section 4.8.3 Single Project Service).
Navigate to the Global Server install path:
C:\AVEVA\GlobalServer12.1.1
Open the singleds.bat file in a text editor.
By default the GLOBAL_PROTOCOL will be set to RPC and WCF will be included as a
remark.
Locate the following:
set GLOBAL_PROTOCOL=RPC
rem set GLOBAL_PROTOCOL=WCF

Delete the RPC line and uncomment the WCF as follows:

set GLOBAL_PROTOCOL=WCF
Modify the projects_dir variable to point to the base product project files.
set projects_dir=C:\AVEVA\plant\PDMS12.1.1\project
Make sure that the evars batch file name is correct for the project.
call "%projects_dir%\Sample\evarsSample.bat" "%projects_dir%"
From the Windows Command Line run the singleds.bat file by using the following syntax:
singleds start sam
The following output will be displayed in the command line:
Important: The daemon is slower to start in WCF mode than RPC. Allow a delay for the
Location to be confirmed.
9.1 Setup Satellite

After starting the Global daemon on the Hub the administrator can start another instance at
a satellite. Once this has been done the administrator can begin customising the way that
communications between the two machines take place through WCF.
Conduct the following steps on the Hub machine:

Create a new transfer folder on the Hub machine. Refer to the Global User Guide (section
4.6 Creating Location Files).

Using the SAM project as an example, navigate to the following folder;

C:\AVEVA\plant\PDMS12.1.1\project\Sample
Create a folder called SAM_SAT as a new transfer folder.
C:\AVEVA\plant\PDMS12.1.1\project\Sample\SAM_SAT
In the Sample folder open the evars batch file for the project inside a text editor. The evars
file for SAM is evarsSample.bat.
Create a new environment variable to point to the SAM_SAT folder:
set SAM_SAT=C:\AVEVA\plant\PDMS12.1.1\project\Sample\SAM_SAT
Launch the base product Admin module.
Create location in admin module
Conduct the following steps on the Satellite machine:

On the satellite make sure that the base product and Global Server have been pre-installed.
Make sure that both have had the WCF enabled.
Copy the contents of the SAM_SAT transfer folder on the Hub:
C:\AVEVA\plant\PDMS12.1.1\project\Sample\SAM_SAT
to the following location on the satellite:
C:\AVEVA\plant\PDMS12.1.1\project\Sample\
Copy the evarsSample.bat file from the Hub to the satellite project folder.
Modify the singleds.bat file on the satellite to point to the evarsSample.bat.

From the command line run the singleds.bat file by using the following syntax:
singleds start sam
On the satellite launch the base product Admin module.
Initialise the Satellite location by clicking Initialise Location.

The Hub and Satellite will now be communicating through Global by using WCF as the
authentication provider.
From the satellite the administrator can test communication by issuing a ping command.
Important: There will be a delay when the first communication is established between
nodes when using WCF.
From the Command Line in the Admin Module enter the following:
On the Hub machine the console window for the daemon will display a summary of
communication between the two workstations:


Global WCF Configuration Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Global WCF Configuration Guide

Uploaded by

Copyright:

Available Formats

Global WCF

Date Version Comments / Remarks

Global WCF Configuration Guide

Software Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1

Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1

Trust Boundaries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

Certificate Based Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

© Copyright 1974 to current year. i 12 Series

WCF Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1

Firewall Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1

Trouble Shooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:1

Start a Global Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:1

© Copyright 1974 to current year. ii 12 Series

Important: The Global Client of the base product (PDMS/Marine/Engineering) will by

© Copyright 1974 to current year. 1:1 12 Series

1.2 Guide Structure

Trust Boundaries Discussed what consideration must be made when

Firewall Configuration Describes the steps that must be taken to configure a

Trouble Shooting Common troubleshooting scenarios.

© Copyright 1974 to current year. 1:2 12 Series

2.1 Microsoft .NET Framework v4

Note: The 12.1.SP4 base product (Plant/Marine/Engineering) requires Microsoft .NET

© Copyright 1974 to current year. 2:1 12 Series

© Copyright 1974 to current year. 2:2 12 Series

3.1 Transport Level Security

Transport security in WCF depends on the Binding selected.

© Copyright 1974 to current year. 3:1 12 Series

3.2 Message Level Security

© Copyright 1974 to current year. 3:2 12 Series

• The user can apply proprietary algorithms.

An example of encryption is illustrated later in section Message Level Security with

© Copyright 1974 to current year. 3:3 12 Series

• Sent between corporate networks.

3.8 Specify Ports

© Copyright 1974 to current year. 3:4 12 Series

© Copyright 1974 to current year. 4:1 12 Series

the weakest level of trust boundary encountered within the project.

Full Trust Boundary

Partial Trust Boundaries

The administrator must consider one of the following secure Bindings:

wsHTTP Most secure

basicHTTP Where external filters verify messages

TCP Faster, but cannot verify contents

The administrator must consider applying data Encryption.

© Copyright 1974 to current year. 4:2 12 Series

4.1 Global Daemon Node Communication

© Copyright 1974 to current year. 4:3 12 Series

© Copyright 1974 to current year. 4:4 12 Series

5 Certificate Based Authentication

5.1 Configure the WCF HTTP Endpoint

© Copyright 1974 to current year. 5:1 12 Series

• Open Certificates Snap In

• Click File > Add/Remove Snap In.

© Copyright 1974 to current year. 5:2 12 Series

• Obtain Certificate Thumb Print

• Double Click on the certificate to open a Certificate window.

© Copyright 1974 to current year. 5:3 12 Series

• Click the Details Tab.

• Select the Thumbprint option from the list.

© Copyright 1974 to current year. 5:4 12 Series

• Bind Certificate With Windows Vista, Windows Server 2008 r2 or Windows 7

• The certhash parameter specifies the thumbprint of the certificate.

© Copyright 1974 to current year. 5:5 12 Series