Petra Terminal Services Setup

Setup Guide

UPSTREAM ENERGY

Petra Terminal Services

Setup

December 15, 2021

Petra Terminal Services Setup

| i

Petra Terminal Services Setup

December 15, 2021

portion of this publication may be reproduced, reused, or otherwise distributed in any form without prior written

consent of IHS Markit.

TRADEMARKS

IHS Markit and the IHS Markit logo are trademarks of IHS Markit. Other trademarks appearing in this publication are

the property of IHS Markit or their respectiv3e owners.

 
 
ii 
 
Table of Contents 
Table of Contents ........................................................................................................................ii 
Overview ................................................................................................................................... 3 
Implementation Checklist ............................................................................................................ 3 
Hardware, Software and License Requirements ............................................................................ 3 
Server and Environment Specifications .................................................................................... 3 
Software Installation and Environment Configuration .................................................................... 4 
A. Petra Server Software Installation ....................................................................................... 4 
B. Petra Client Installation as a Remote Application ................................................................... 5 
Rolling Out Terminal Server Petra to Users .................................................................................. 6 
A. Method 1 – Running Petra in a Remote Desktop Session ........................................................ 6 
REMOTE SESSION CONFIGURATION AND PERFORMANCE NOTES: ............................................... 7 
B. Method 2 – Publishing the Petra Client as a Remote Application .............................................. 7 
Other Server Maintenance and Configuration Issues ....................................................................11 
Server Maintenance and Usage Guidelines ...............................................................................11 
Overlay Files ........................................................................................................................11 
File Permissions ...................................................................................................................12 
Data Execution Prevention .....................................................................................................12 
WMIC OS Get DataExecutionPrevention SupportPolicy ..............................................................12 
E. Thematic Mapper Installation and Troubleshooting ................................................................13 
ActiveX on the Server to Enable 3DViz Functionality .................................................................13 
Printing and Plotting and External Devices ...............................................................................13 
H. Web Mapping Services Configuration ..................................................................................13 
I. Window-to-Window Operations ...........................................................................................15 
Acknowledgements ....................................................................................................................18 
Appendix 1: Installation and Testing Checklist ...............................................................................18 
Appendix 2: Configuring PowerTools ............................................................................................. 1 
Introduction ............................................................................................................................ 1 
Appendix 4: Troubleshooting Guide ............................................................................................... 2 
 
 

Overview

Terminal Services is a Client/Server installation completely hosted within a Network Server

environment.

All Users launch Petra via either logging into the Terminal Server through Windows Remote

Desktop Connection or launch an RDP Batch file located on their desktop, configured through

Windows Published RemoteApp within the Terminal Server. Network Admins can choose

between either configuration, dependant on client needs.

Terminal Services is designed to increase the performance of a Multi-User Installation

(Client/Server) by mitigating the network communication needed between the Client install

hosted on a User machine and the Server install hosted on the Network Server. With all

installs and data hosted on a single system, this is considered more of a Multi-User

Standalone/Local install hosted on a Network. This configuration cuts out the need for cross

network data packet communications, slowing performance.

Implementation Checklist

Hardware, Software and License Requirements

The basic requirements of implementing this scenario are as follows:

1. A designated terminal service host machine, running Window 2008r2 or Windows 2012r2 (physical

or virtual), equipped with at least 8 GB of RAM per simultaneous user in addition to operating system

memory requirements

2. Enough local disk storage for all project data (with the exception of raster image data), or a

dedicated Storage Area Network (SAN) device for the server

3. Both Petra Client and Server installation software, available for download at

https://www.ihs.com/permission/en/pps-downloads.html

4. Sufficient Microsoft Remote Desktop Services client access licenses to cover all simultaneous users

– these are required even if you intend to use Citrix or HP’s Remote Graphics System; please note

that the installation and configuration of Remote Desktop Services client licenses are the

responsibility of the customer

5. A network license service for Petra with enough licenses to cover simultaneous users – standalone

sentinels will not pass through a remote server connection

Server and Environment Specifications

Our testing was carried out on a virtual Windows 2008r2 server configured with VMWare,

assigned two quad

core processors and 16 GB of memory. Therefore, there were a total of

eight CPU’s available to Petra. The server was situated on a gigabit network, and file copy

speeds to networked thin

client workstations were very good, showing excellent I/O speeds to

conventional Petra clients on the network. Video memory was set to the VMWare maximum of

128 MB per session. This obviously does not represent a true video card capacity, but the

virtual video memory allocated per multiple

screen session. Increasing the allocated video

memory from a lower value to the maximum of 128 MB had a positive effect on screen refresh

and base map performance for the large project tested.

When using Microsoft Windows Server remote sessions as the platform, the administrator must

add the server role of Remote Desktop Services and add all users to that group so they can open

remote desktop sessions. Double

check permissions for all client installation folders – each user

must have full control at their client installation folder. Additional remote desktop licensing on the

server may be required from Microsoft should your plans call for more than two simultaneous

remote desktop users.

Testing has not been done on blade or other specialized remote computing devices with

dedicated video cards. We anticipate that users’ video experience would improve on these

types of machines, though Petra requires a minimum of graphic 3D acceleration.

Initial tests were conducted with the Petra project stored directly on a local virtual disk drive

of the server. Later tests used a Storage Area Network (SAN) disk share, which showed

almost identical performance.

Note: NAS storage which used CIFS-style file management shows poor performance and

is not recommended for terminal services implementation.

Software Installation and Environment Configuration

A. Petra Server Software Installation

The configuration involved the installation of one Petra 3.X Server and multiple user

specific

clients as follows:

1. Before you begin with any installations (do these as administrator), do the following:

a. Set User Account Control (UAC) to the lowest setting – this is critical

b. Temporarily disable virus scanning

2. Allocate a physical or virtual server capable of hosting multiple simultaneous user sessions. The

least expensive solution is Microsoft’s Remote Desktop Services (RDS); Citrix is another option.

Newer versions of Microsoft Server also provide RemoteFX virtualization, but that is not required for

this implementation. If using Microsoft Server RDS, be sure to add a server role of Remote Desktop

Services in order to allow more than two simultaneous remote users and make sure you have

sufficient Microsoft client access licenses (“CALs”) to enable multiple RDS users. Add all future users

to the remote desktop user group via their Active Directory usernames.

3. Install the Petra Server software and take all defaults; we recommend the use of the separate client

and server installers – run the server*.exe installer as administrator:

4. Follow screen prompts to complete software installation.

a. Place a copy of your Petra.ini file (a sample is in the server installation folder inside the

\Parms directory) into the Petra server installation folder, making sure the network license

server is cited as the value of FLEXLMLICPATH, and uncomment FLEXLM=ENABLED. Be sure

to use a fully qualified domain name or IP address.

NOTE: A local Petra license server may give optimum performance, but our tests showed

excellent results even when using a central license server. Although not heavy, a local

license server will obviously eliminate network licensing traffic.

5. Make sure the PETRA License From option is set to Network Server and that you have access to

licenses using the appropriate license server:

Petra Version

Flexera Version

License Fie

Vendor Domain

3.8.3 and earlier

LMTools

Geoplus.lic

Geoplus.exe

3.9.x

LMAdmin

IHS.lic

IHS,exe

a. Petra 3.8.x and earlier: LMTools with a geoplus.lic and geoplus.exe vendor daemon, or

LMAdmin with a geoplus.lic and geoplus.exe vendor daemon

b. Petra 3.9.x and later: LMAdmin with a IHS.lic file and IHS.exe vendor daemon

B. Petra Client Installation as a Remote Application

1. Next, we will install the Petra client as a remote application using the Windows Remote App

Manager tool.

2. Before doing this, create a separate folder for each user, named for their Windows username, and

containing a \geoplus1 and \PriParms folder to accept the client and private parms,

respectively. For example:

o C:\Petra\PetraUsers\BSmith\geoplus1 (to hold the user’s Petra client software)

o C:\Petra\PetraUsers\BSmith\PriParms (to hold the users’ private parms files by project)

3. Go to the server’s Control Panel, and using the Small or Large icons view, select Install Application

on Remote Desktop...

Important: If you do not see this option, then the Remote Desktop Services Role has

not yet been activated on your terminal services host. That task is beyond the scope of

this document, as is the configuration of the remote desktop client access license server

setup to support this role. Microsoft documentation and the installation wizard will guide

4. Browse to the client installer – you may have to change the file type from “Setup Programs” to

“Programs” to see the .exe installer:

5. Once selected, click Next >.

6. Do not close the Run Installation Program window until the Petra client installer has finished:

7. Alter the path to the desired user

‐

specific installation folder and its \geoplus1 subfolder. In this

example, the user named “user1.”

8. Proceed with the installation.

9. When the config.exe tool opens (below), begin filling it out with the correct information.

a. For the System Path, browse to the Petra server installation folder, and select the geostart.exe

file.

b. Next, substitute the Windows %username% variable to point to the user’s own client installation

in lieu of the actual Active Directory username. This is necessary because only one entry for this

information is allowed in the server’s registry, for all users.

c. Confirm the Petra project folder is correct.

d. Finally, select a generic folder location to indicate the users’ private parms folder, or leave this

blank; we suggest you use the %username% windows variable to specify a path that’s unique to

the login user. With multiple users on one machine, we recommend that you place priparms for

all users in a common master folder so they don’t get scattered across your network; it’s critical

to substitute the %username% variable for WindowsUserName so that Petra would go to that

location first. We’ve used the folder C:\Petra\PetraUsers\%username%\PriParms as our master

location.

Note: Changing the Private Parms (“PriParms”) path in config.exe doesn’t do much

otherthan set the default location for PriParms. The user can still choose other locations

when creating a new project or connecting to one.

10. The installation will run and complete.

11. Return and close the Finish Admin Install window to complete the installation.

12. Before proceeding to the next step, confirm the user’s Client installation by navigating to the folder;

open config.exe to confirm the proper settings are still in place.

13. Repeat this process for the remaining users. We have not encountered problems when simply

copying the \geoplus1 installation folder from user-named path to user-named path. The

%username% variable will assure that these are not confused. That said, run config.exe from each

user’s client folder to assure that all values are correct.

14. Finally, create a client path that literally uses “%username%” as part of the folder structure. For

example: C:\Petra\PetraUsers\%username%\geoplus1. Make sure all public and private

parms files that real users have are replicated under this location. This path may be required for

future project repair steps or connecting a tool to Petra such as IHS Markit’s PowerTools that may

not be able to resolve the %username% variable. In this scenario, the literal path can be used by the

application, but it must be properly populated with Parms information and project .ini files. See the

Appendix for PowerTools setup.

Rolling Out Terminal Server Petra to Users

There are two methods available to rollout the Petra client to users:

Method 1 - Run Petra in a Remote Desktop Session

Method 2 - Publish the client as a Remote Application

Method 2 requires more configuration of the server (as outlined in the following sections) but

once completed, performance is the same except for some minor functionality issues

discussed later. The key difference is that when running Petra in an RDS (method 1), the user

will have unrestricted access to the terminal server desktop. This might raise security

concerns with some customers. Publishing Petra as a remote app will alleviate these concerns

but as users will not have access to the remote desktop, a means of saving Petra

generated

files to a different location will need to be implemented.

A. Method 1 – Running Petra in a Remote Desktop Session

WARNING: Make sure that user accounts DO NOT have administrator privileges on the

terminal services Petra host; if they do, they will not be able to launch Petra

simultaneously.

Make certain that all potential users are added to the server’s Remote Desktop user group.

1. Create a generalized petra.bat file to launch each private petra.exe file in the individual client

install folders (see below) and give this file or a shortcut to each end user (e.g. place it on the user’s

Desktop on their remote desktop). They will have to log in to the terminal services machine and then

launch the Petra client with the petra.bat file.

2. If administrator rights are not removed from users, you will see a message that you cannot run

multiple copies of Petra when the second user attempts to start Petra:

Note: This is due to the fact that administrators are always globally aware on a machine

and cannot launch processes and be invisible to another admin account. Non-

administrators can launch private sessions of an application and not interfere with

each other.

REMOTE SESSION CONFIGURATION AND PERFORMANCE NOTES:

The terminal server administrator can govern the resources passed through from the local machine to the

terminal server. These include local hard and USB drives and printers.

Petra will not be able to print to a printer passed through from a local workstation unless all print drivers

have been configured on the terminal server. This would include PDF creation from Petra content with the

help of a local application like Adobe Acrobat.

Users should use caution when using identically mapped drives as referred to both on their workstation

and the server, as both will be visible in Windows Explorer on the terminal server host.

Files saved to mapped drives may be delayed in their appearance in Windows Explorer for the server-

mapped drive and may actually appear sooner on the local workstation-mapped drive.

Users should, however, avoid working with large files via their local workstation drive mapping as

performance may be poor.

Administrators may wish to consider limiting the pass-through of local drives to reduce potential

confusion

The next section describes an alternative way of distributing the Petra client that addresses

many of these problems, although it may introduce some window

window interaction

issues, described below.

B. Method 2 – Publishing the Petra Client as a Remote Application

An alternative

method

of making the Petra client available to end users without using an

entire remote desktop session is to publish the recently

installed Petra client as an icon on a

company terminal services web page or URL. This icon link stores the application and host

information and can be used to launch Petra from any machine on the local network, or from

a machine linked anywhere via a VPN connection. This makes it very useful as a tool on a

laptop computer at a wellsite or for users running Petra at home or in a different city who

would like to print on their local printers, etc.

There may be a few minor inconveniences to this technique; for example, window

window

interactions in Petra are occasionally affected. In particular, the Petra “jump to well on Map

from Main” function may not work properly, and a work

around solution is provided later in

this document. Otherwise, this solution works well, and users see “remote” Petra as just

another application on their own desktop without the hassle of using an additional, remote

desktop.

Here are step-by-step instructions on implementing this solution on a Windows 2012r2 server

after the Remote Desktop services role and the Petra client software have been installed.

1. On the Windows 2012r2 terminal server host machine, select the Windows Server Manager Tool

from the Start screen.

2. In the Server Manager window, on the left-hand side, select Remote Desktop Services, then

Collections.

3. In the top-right corner of the Collections window, click on the TASKS drop-down menu and select

“Create Session Collection”. The Create Collection window will open.

4. In the “Before you begin” window, confirm that the listed tasks have been completed. Then click

Next >.

5. Give your new collection a name. “Petra” would be a suitable example. Click Next >.Select the RD

Session Host Servers to add to this collection. Click Next >.

6. Select the user group(s) that you wish to have access to the Petra collection. Click Next >.

7. In the “Specify user profile disks” window, turn off the option to “Enable user profile disks”. Click

Next >.

8. In the “Confirm selections” window, verify the selections you have made and click Create.

9. Once the operation has successfully completed, click Close.

10. We will now publish Petra as a RemoteApp. In the Server Manager > Remote Desktop Services

window, you should now see your newly-created Collection name (e.g. Petra). Select this. In the

REMOTEAPP PROGRAMS section, click on TASKS, and select Publish RemoteApp Programs.In the

“Select RemoteApp programs” window, select Petra in the list of applications. Click Next >.

11. In the “Confirmation” window, click Publish.

12. Once this process has completed, click Close.

13. You should now see Petra in the list of REMOTEAPP PROGRAMS.

14. The final configuration step is to set options such as local monitor usage, printer pass-through, etc.

15. In the Server Manager window, select Remote Desktop Services > Collections > Petra. Under

PROPERTIES, click on the TASKS drop-down menu and select Edit Properties.

16. Select and edit the various Session Collection windows based on your individual needs. An example

of a Client Settings configuration is shown below. This particular configuration will:

a) Allow Printer pass-through to make the user’s local printers available,

b) Allow Clipboard functionality so user can copy and paste between the remote application and

local Windows applications on their desktop,

c) Allow drives on the client device to be accessed.

Starting and Configuring the Petra Virtual NT

1. On the terminal server, open a PowerShell window and identify the IP address of the server. In the

example below, this would be the IPv4 address.

2. Open an internet browser on a client workstation and type in the server IP address preceded by

https:// and followed by /RDWeb. Click Enter.

Note: that configuration of the Web Server Security Certificate is the responsibility of the

customer.

3. Click “Continue to this website” to open the RD Web Access window. Enter your Domain\user name

and Password, select the correct Security option, and click Sign in.

4. In the subsequent window, click once on the Petra RemoteApp icon

5. Click Connect to access the remote Petra app (you may also select the “Show Details” drop-down to

edit which resources the remote server can access on your machine for this connection only).

6. You may momentarily see a remote desktop image. If so, click OK.

7. The Petra startup window will then appear showing the user’s login name. Click OK.

8. When first opening a project, you should create an initial connection to both the desired project and

the private parms area to assure all paths are correct. To make the connection to the new project

the first time it is opened in the new environment:

a) On the Welcome to Petra window, select the third option Create a NEW Project

b) On the next Create New PETRA Project window, select the second option: “Connect to an

Existing Shared Project”

c) Next, browse to the correct project public folder location and double-click on it; click NEXT

d) On the Personal parameters window, browse to the top-most personal parameters folder.

Go no lower than that; if the project parm folder exists, it will be used, if it does not, it will

be automatically created

e) Click Finish

Once the project opens, check for proper operations, data content, etc. Make sure all potential

users have Full Control over the Petra project folder and their priparms folders. Open the Map

module and make sure all the users’ overlays are present where expected, along with map

settings files (*.MAP). Check for proper raster log locations – paths may have changed during

the project relocation to the TS server. Instructions for this operation are in the next section

of this document.

Project Copying and Miscellaneous File Locations

A. Moving Project Folders

Project folders, as well as the user private parms folders, must be relocated to the terminal

services machine. For simplicity, you may wish to mirror the mapped drives in the two

environments to maintain user familiarity, raster log storage paths and other mappings.

Edit the <Project>.ini file in each project folder to mirror the new network paths, and make

sure a copy of this file is located there, as well as in:

• The users’ private parms folders and

• The Petra Server installation folder’s PARMS subfolder (\petrasrv\PARMS)

When migrating from a standalone environment, you may need to segregate private parms

files from local workstations into their related user private parms folders on the server. For

example, for a TX_SOUTH project, there must be a TX_SOUTH.ini file inside two folders such

as P:Petra\Petra_Projects\TX_SOUTH and P:\Petra\PetraUsers\user1\PriParms\TX_SOUTH.

Plus, any other private files related to that project must go into that latter user’s priparms

folder.

<ProjectName>.ini

PublicDir (updated path to the relocated

project folder)

PrivateDir (set by project originator, not

otherwise used)

Petra Project Folder

Private Parms Folder*

* References to these locations are set in config.exe but are superseded by user selections when making an

initial connection to a project. See the section Project Opening in the New Environment, below

B. Checking and Editing Raster Calibration and Image

File Paths

If project folder locations have changed with the implementation of terminal services, both the

calibration file locations (.lic files) and TIF image files may require updating to reflect the new

locations. Petra captures the locations of both of these files in its database, plus the location

of the TIF file is captured inside the ASCII .lic file. Unless both are updated, rasters will be

unavailable for the raster calibration window view, or the cross

section module.

Begin by running a report on these locations before the project is relocated to the terminal

server:

1. On the Raster tab of the Petra main window, click on the Group Maintenance button

2. On the subsequent Log Image Group Maintenance window, click on the Misc & Tools tab

3. Select the initial drop-down list item of “Export Summary Report CSV File”, and then click on Perform

Selected Task...

4. Select a name for the export file, which will be saved by default in the project’s Reports subfolder

5. The output file listing will begin; note that this may take several minutes or even a few hours for a large project on a busy

network

6. The report will open in Notepad in its comma-separated value format, but close that and open it in Excel instead

7. Fix any misaligned columns, then sort and search the COMMENT column for mention of any missing LIC or TIF files or paths

Occasionally some file locations can be lost to Petra, most often due to one of the following

reasons:

1. The Petra project folder is moved to a different place on the network (i.e. the new terminal server),

or in the worst case scenario, out of the original domain if domain-named locations were used

2. TIF files are deleted from their original locations

3. LIC files are deleted or moved from their original locations

4. A network mapped drive is disconnected or changed

5. A private drive mapping unrecognized by the general user community is used by a data loader

Finally, use one or a combination of the tools in the raster maintenance Misc & Tools window

to fix these issues. These could include the following:

6. Use the imagesearch.txt file to specify additional network locations for TIF files

7. Use Find/Replace LIC/TIF Path Prefixes to change mapped drive designations, for example, or Use

Resolve Image Paths to enlist the imagesearch.txt file to find and fix network locations

8. You can also import the rasters from the current locations by using the LIC files:

a) On Main, click Project > Import > Raster Logs from > PETRA LIC Files

b) On the next window, click Select Files...

c) Either browse to them, or take the next windows advice to drag and drop selected LIC files onto

the white space on the import window

d) Select the desired parameters, and import the files

e) This will connect the remote TIFF files to this Petra project

Other Server Maintenance and Configuration Issues

Server Maintenance and Usage Guidelines

It is wise to schedule periodic reboots of the terminal server host machine. This will clear

orphaned sessions and recapture system memory that may be scattered and lost after

multiple days of heavy use. Also, request that users log off and end their sessions at the end

of each work day. This will lengthen periods of stability of the system, but should things go

awry, a reboot will normally fix them.

Overlay Files

Users may have to modify the default location from which overlay files are opened in Petra

Map. There is no global path setting for the current overlay; overlay files can be saved or

opened from any location the user chooses. Petra, by virtue of priparms, will remember the

last loaded overlay and path. Usually, when a project is moved from server to server, the

next time a user opens the project the map module still points to the old location. The only

way around this is to use Overlay > Open the overlay from the new location inside the map.

Petra will then remember that new copy/path for next time.

Petra’s Map Overlay functionality allows you to “associate” a layer, meaning it’s offloaded to

an external .LAY file and then referenced to a layer in Petra. This method is commonly used

for shared layers such as leases.

In a traditional client/server or standalone install, if you were to remove/rename/delete this

file, it simply would not show up in the map and be inaccessible until you reestablished the

connection.

In Terminal Services however, this results in a “map has stopped working” error that prevents

the Map module from opening. We therefore recommend disassociating any layer of this type

prior to migrating projects to the Terminal Server, and re

associating them afterwards.

File Permissions

After copying any files around your network, ALWAYS check their security settings to make

sure users have full control to Project and personal parms folders and files. If they do not,

things will break. In addition, many Petra functions require a write-back to the project folder,

e.g. raster file and web mapping utilities. Beware of any group policies that may interfere with

group permissions on folders and shares. It is critical that all users have unimpeded Full

Control to the Petra project folder and private parms areas.

Data Execution Prevention

There is strong evidence that Data Execution Prevention (DEP) settings of 3 (the default for

Server 2008r2 and Windows 7) may cause intermittent crashing of Petra during file I/O

operations when Petra is running under terminal services. DEP is a safety precaution built into

Windows operating systems that prevents the unauthorized execution of code in certain areas

of memory. It is adjustable from 0 (no DEP) to 3 (no exceptions). A setting of 2 designates

only essential Windows files are subject to it, which is a logical level of protection. A non-

administrator on the server can check the DEP level with this command issues in a Windows

command window, and values are explained in the table below:

WMIC OS Get DataExecutionPrevention SupportPolicy

DataExecutionPrevention Support

Policy property value

Policy Level

Description

OptIn (default

configuration)

Only Windows system components and

services have DEP applied

OptOut

DEP is enabled for all processes.

Administrators can manually create a list

of specific applications which do not have

DEP applied

AlwaysOn

DEP is enabled for all processes

AlwaysOff

DEP is not enabled for any processes

If you have been experiencing lockups or crashes in Main, Map or Cross-section when users

are saving or loading WSN lists, overlays, map settings, etc., change this setting on your

server’s operating system and reboot the server.

The server administrator can quickly make changes as follows A subsequent server reboot is

required.

1. From the Windows 2012r2 Start window, right-click on Computer (or This PC), and select

Properties,

2. Click on Advanced System Settings,

3. Under the Performance area, click the Settings button,

4. Go to the Data Execution Prevention tab on the next window,

5. Select “Turn on DEP for essential Windows programs and services only”.

E. Thematic Mapper Installation and Troubleshooting

The Petra Thematic Mapper tool requires ESRI Map Object common files to be installed;

currently these must be version 2.2 or higher. The installer is available at:

https://petraftp.ihsenergy.com/mo22rt.exe

Once run, it places the resulting files into:

C:\Program Files (x86)\Common Files\ESRI

There are occasions when the installer above does not complete and the .dll’s are not

registered on the terminal server host. This is typically due to virus scanner or User Account

Control interference on the Windows server operating system. If this happens, a server

administrator should:

1. Open a command window (right-click on cmd.exe, and run as administrator)

2. Navigate to the folder C:\Program Files (x86)\Common files\ESRI

3. Issue these two commands:

o C:\Program Files (x86)\Common Files\ESRI>regsvr32 Shape20.dll

o C:\Program Files (x86)\Common Files\ESRI>regsvr32 Mo20.ocx

4. Try starting the Thematic Mapper from Petra Main to see if this succeeds. If not, try registering

additional files in the ESRI folder

ActiveX on the Server to Enable 3DViz Functionality

The 3DViz module requires the enablement of ActiveX on your terminal server. This may

require the installation of a patch from Microsoft, available at

http://support.microsoft.com/kb/2508120 .

Printing and Plotting and External Devices

If you have published the Petra client (user by user), the users’ local printers can be passed

through and available for use by the Petra application. You can run a test by clicking in Petra

Main on Project > Summary Report. Notepad should open, containing the project summary

report; try printing this to a local printer to assure proper functionality.

External devices such as digitizing tablets will likely not pass through the remote desktop

protocol and Petra may have to be run in conventional client

server mode on the machine to

which the tablet is connected.

H. Web Mapping Services Configuration

If Web Mapping Services (WMS) are to be used in Petra Map, the terminal server must be able

to access the appropriate external URL’s. A default service in Petra users is

https://www.datadoors.net which is a brokerage service to miscellaneous types of WMS data.

If your server is not configured to properly access this external URL, users will normally see

one of the following results:

1. “The supplied Web Map Service returned invalid response” message appears

2. “The specific Web Map Service is currently unavailable” message appears

3. “The Web Map Service URL you have entered is not in proper format” message appears, or

4. The Map module will crash

We have seen instances where a WMS section should be added to the PETRA.ini file located in

the petrasrv server installation folder. The following entries provide information to Petra for

locating the datadoors WMS broker site:

[WMS]

;; Details are in section 5.12 WMS Section in the PETRA Usage In Large

Multiuser Environments manual

url1=http://www.datadoors.net/__streaminguid.862a6ffd-8b23-4189-be61-

249af4b6c766/wms.ashx

;;user1=username

;;password1=password

description1=www.datadoors.net

;;url2=http://www.server.xyz2

;;description2=Description for url2

;;url3=http://www.server.xyz3

;;description3=Description for url3

;;url4=http://www.server.xyz4

;;description4=Description for url4

ConnectTimeout=5000

There are two external WMS accessibility tests that should be run to determine if external

internet mapping services are available to your terminal server:

1. On Petra Main, go to the Location tab, select a well, and click on the Bing Maps icon. A small

window should open with a satellite image showing the well location.

2. On the Petra Map window, look for and click the “wrench” icon on the left column under Imagery.

When the Petra Web Map Service window opens, click the Get Spatial Energy button, and you

should then see a collection of map thumbnail images, below.

3. Select one of these and click OK. On the next window, confirm the site you want and click OK.

4. If the imagery does not soon appear on Map, check the settings on the Imagery area of the Quick

List column of Map. They should look similar to what’s below:

The WMS layer should now be visible on your Map window.

One way to check firewall permissions is to “tcping” the Datadoors.net URL. If this ping is

successful, you will have confirmed that 1) ports are not blocked by firewalls or antivirus

settings, 2) paths are not filtered by corporate proxy servers, and 3) the DNS is functional.

A ping command is insufficient to test the WAN accessibility to the WMS site, so we

recommend that you download and use a tcping utility. One is available at

www.elifulkerson.com/projects/tcping.php Open a Windows command window, go to the

folder containing the tcping.exe downloaded file, and issue the command

tcping

datadoors.net

. The expected results will look like this:

Probing

- time=31.257ms

Probing

- time=37.565ms

Probing

- time=34.322ms

Probing

- time=33.946ms

Ping statistics for 69.164.148.97:80

4 probes sent.

4 successful, 0 failed.

Approximate trip times in milli-seconds:

Minimum = 31.257ms, Maximum = 37.565ms, Average =

34.273ms

Again, from the command line, issue the nslookup command to find the name corresponding

to the IP address. For example,

C:\>nslookup 69.164.148.97

Server: google-public-dns-a.google.com

Address: 8.8.8.8

Name: parked.peakcolo.com

Address: 69.164.148.97

You should expect to be able to see, for the datadoors.net site, both of the following:

1. That the tcping command returns an IP address with an open port 80

2. That the URL of parked.peakcolo.com is returned

If these results are not seen, then the firewall or antivirus is not configured to allow access to

the datadoors.net URL, and WMS will not work. The installation of a firewall client on the

terminal server may be required, or the proxy server otherwise configured to pass through

the datadoors.net URL.

I. Window-to-Window Operations

With the Remote App “virtualized” application, occasionally window-to-window operations in

Petra are affected. One such operation is the “jump to well” from Main to Map – the cursor

jumps to the Map window but may not fall on the desired well, especially when the virtualized

modules are on different monitors. This operation is unaffected when using Petra on an entire

remote desktop environment.

A work-around for this scenario is to, on Map, click Wells > Symbol Location and Style... On

that menu’s Options tab, enter a zoom factor of, say, 10 for “Zoom Factor When Highlight

Well From Main” and click OK. The next time a user hits the F8 key on Main to jump to Map,

the map will zoom in on the target well to make it easy to spot even though the cursor may

not fall directly on it. If the highlight circle is too small to be readily visible, increase its size

on the Symbol tab.

It has been brought to our attention by a customer that upgrading local operating systems to

Windows 10 on the Desktop and Windows Server 2012 on the server side addresses some of

these functionality problems since this introduces RDP upgrades. Alternatively, the RDP

software version can be upgraded independently of the OS to perhaps achieve improvements.

We have not independently verified this.

J. Minimum Curvature/Flex Gridding Error

During workflow validation testing of Petra Terminal Services, errors have been observed

when users attempt to create a grid in the Map module using minimum curvature or when

turning on the grid flexing option. These errors were first seen on a new, Windows 2012r2

server with a 64 bit Operating System, however the identical problem has since been

observed on a 2008r2 and, most recently, a Windows 2016 server. A common feature does

appear to be the use of a new (or upgraded) 64 bit OS.

Errors have been observed when attempting to create certain types of Contour Grid in the

Petra Mapping module. Specifically, when the “Surface Style” is set to Minimum Curvature or

when the “Smooth Contours Using Grid Flexing” option is turned on (as below).

These errors are, in order:

blockmean.exe - System Error

The program can’t start because MSVCR100.dll is missing from your computer. Try reinstalling the

program to fix the problem.

surface.exe - System Error

The program can’t start because MSVCR100.dll is missing from your computer. Try reinstalling the

program to fix the problem.

grd2xyz.exe - System Error

The program can’t start because MSVCR100.dll is missing from your computer. Try reinstalling the

program to fix the problem.

Alternatively, the errors may state the following:

The application was unable to start correctly. Click OK to close the application

These can be dismissed without closing/crashing the Mapping module, but the grid is not

created.

A common feature of these errors appears to be the use of Petra on a new (or upgraded) 64

bit Operating System, whether on Terminal Services or as a standalone application. The three

executables identified above are located in the petrasrv\GMT folder and are used by Petra

when creating grids using Minimum Curvature as a Surface Style or turning on the Grid

Flexing option. Attempting to run these executables from this directory (even as an

administrator) has been shown to produce the same errors as those produced during the

problematic gridding operation.

Although an msvcr100.dll may be present in the C:\Windows\System32 folder, these gridding

executables require the correct msvcr100.dll to be in the C:\Windows\SysWOW64 directory on

a 64 bit OS. If there is no msvcr100.dll in this directory, you will get the error stating that:

The program can’t start because MSVCR100.dll is missing from your computer. Try

reinstalling the program to fix the problem.

Note: you will see this error even if there is an msvcr100.dll in C:\Windows\System32.

Even if there is an msvcr100.dll in C:\Windows\SysWOW64, we have observed that this .dll

may not be the correct version for these three executables. This will give the second type of

error:

The application was unable to start correctly (0xc000007b). Click OK to close the application.

This issue has been resolved in each case by identifying the problem .dll (usually an

msvcr100.dll but on one occasion an msvcp100.dll) and sending the customer a (zipped) copy

of this from the C:\Windows\SysWOW64 directory on a working Petra installation. The

Operating System of the source installation should match that of the problem OS (i.e. 64 bit,

2008r2 vs 2012r2 vs standalone*). Upon receipt the customer should unzip the file (virus

scans have a tendency to prevent unzipped .dlls from being received via email) and copy it to

the C:\Windows \SysWOW64 directory of the terminal server or standalone installation.

*Note: The only exception to this is that equivalent 2012r2 dlls have resolved these errors on

2016 servers. While this fix has worked, Petra is still not officially certified on Windows 2016.

Confirm that this has resolved the problem by running each of the blockmean, surface, and

grd2xyz executables from the petrasrv\GMT directory. If no error is seen with each of these,

rerun the gridding operation with Minimum Curvature as a Surface Style or turn on the Grid

Flexing option.

Acknowledgements

IHS Markit thanks Whiting Oil and Gas Corporation and Brian Hoffman’s team for permission

to share this information.

The IHS Markit Geoscience Client Services team has assisted several clients with

implementing this scenario, and our shared lessons are helping everyone. We express our

appreciation to everyone who has participated.

Appendix 1: Installation and Testing Checklist

Server has Remote Desktop Services Enabled

Server Data Execution Prevention set to 2

Petra server installation completed (to the petrasrv folder)

Petra.ini file configured with network license server location

First Petra clients installed in AD-named folders, done in RemoteApp mode (from Control Panel)

Subsequent copies made for other AD-named user folders

AD users have full control at respective client locations

Parms folders created

Thematic Mapper installation tested

WMS tested and firewall changes made as necessary

Projects copied over to new location

<Project>.ini files edited and placed in project folders and parms areas

Test Open Map

Test well queries

Test plotting from remote app

Check Raster log locations and performance

Resolve raster log locations if necessary, or reload rasters

Benchmark conventional performance versus terminal services performance

Decide on backup and recovery techniques on the terminal server

Petra Terminal Services Setup

| 1

Appendix 2: Configuring PowerTools

Introduction

PowerTools

is a popular IHS Markit application which allows the viewing and analysis of

wells and their production and test data. PowerTools can extract the data for its analysis

from many sources, including IHS Enerdeq

, IHS PIDM/P2000

, IHS FieldDirect

and Petra.

PowerTools and Petra can run together on a terminal server when both are properly licensed

and configured on the machine.

Enabling PowerTools to find the source Petra projects in a Terminal Services setting requires

special configuration. When searching for the source Petra data, PowerTools first looks for a

set of <Project>.ini files with which it builds a list of Petra project to choose from. Next, to

find and open the path to the Petra DB files, PowerTools open the target project.ini and looks

for the PriParm path found there. Normally, PowerTools looks in a named user’s client path

for all this information, but on a terminal server the registry is set to the

%username%

variable to allow multiple client paths to be found, depending on who’s logging on to the

terminal server. PowerTools, unfortunately, cannot resolve the %username% system

variable, so all the .ini files (in the PUBParms folder) and the PriParms files and their folders

must be replicated under a dummy client path literally containing %username%.

Prepare a Generic Petra Client Path and Public and Private Parms Folders

Our guideline in locating the public and private parms folders is dictated by the Petra

config.exe file:

The Petra project list shown by PowerTools is comprised by all the <ProjectName>.ini files

located in a PARMS folder under the Client Path as set in config.exe. Also, all priparms

folders are arranged as shown in the value for Parms Path above.

As guided by the paths shown in the Config.exe above, follow these steps to locate all PARMS

files:

1. Copy all <ProjectName>.ini files into a PARMS folder under \%username%\geoplus1:

2. Next, copy the project-named subfolders under an operational user’s PriParms folder over to the

equivalent position under %username%:

At this point, all the .ini and parms data is available under the %username% client path

where PowerTools thinks it will find it as informed by registry settings set by Petra’s

config.exe tool.

Install PowerTools on the Terminal Server

Install PowerTools on the terminal server host machine and install a license file as you would normally. You may then either

enable users to run in Remote Desktop mode or publish the remote app.

Configure PowerTools for Each End User:

1. With PowerTools open, select Advanced > Edit User Configuration File, and clear message:

2. Look for the section of the file labeled [Petra]; the default values are as follows:

[Petra]

PetraSharedHost=

PetraSharedPort=

PetraSharedUserName=

PetraSystemPath=C:\GeoPlus1\

PetraClientPath=C:\GeoPlus1\

3. Edit the last two lines to match the config.exe settings:

[Petra]

PetraSharedHost=

PetraSharedPort=

PetraSharedUserName=

PetraSystemPath=C:\petrasrv

PetraClientPath=C:\PetraUsers\%username%\geoPlus1

4. Save the configuration file, reopen and recheck to assure that changes were made, then test your

connection between PowerTools and Petra:

5. If necessary, create a new PowerTools project by selecting File > New Project... and edit the

name line:

6. The Add to Project window will appear at project creation; if it does not, select File > Add to

Project...

7. Select IHS PETRA® version 3 project

8. The Add to Project from PETRA window appears, and you should see your list of projects available

in the drop-down list:

9. Choose the desired Petra project, click OK, and data should begin to import.

10. If you do not see the project list as expected:

a) Make sure all parms folders and .ini files are located under the %username% path

b) Recheck the PowerTools config file to make sure the correct paths are still saved.

Petra Terminal Services Setup

| 1

Appendix 3: Suggested Performance Improvement Test Plan and Table of Test

Results

Project Name: ____________________ Test Date: _________________________ Users: ______________________________

Environment

Users

Open

Main

Open

Map

Load

WSN

Post

Attrib.

on Map

Query

Wells*

Load

Wells

Load

Mon

Prod **

Comments

Conventional Petra, one to

many users

Terminal Services Petra

3.X, one to many users,

local disk storage

Terminal Services, multi-

user, SAN drive storage

(optional)

* Well query is:

** Enerdeq Query or WSN list for the well population:

Appendix 4: Troubleshooting Guide

Problem Area

Description

Possible Cause

Solution

Launching Petra

Cannot launch the

remote app or a remote

desktop window:

“Connection was denied

because the user account

is not authorized for

remote login”

The user is not authorized as a

remote desktop user

The server administrator must add all

potential users to the Remote Desktop

Users group on the server

The user receives the

message: “Cannot run

multiple copies of Petra”

Users are running Petra on remote

desktops but are administrators on

the host

Remove users from the Administrator’s

group

Petra clients are not properly

configured

Make sure individual Petra clients are

installed in separate folders named for

user active directory names, and that

config.exe is used to specify the path with

the %username% variable. See Page 15.

Windows cannot start the

Remote App program –

“The initial application

you are trying to open is

currently unavailable.

Contact your

administrator to confirm

that the correct settings

are in place for your

client connection.”

The client petra.exe executable may

not be in the list of remote apps.

Use the Remote App Manager to check

and make sure that Petra.exe is a

registered remote app. You may have to

re-create the .rdp file and redistribute it

to users.

Users cannot create a

connection to their

project or priparms area,

and may see an “Access

denied” message

Permissions must be opened up to

give users Full Control over target

Petra project locations and private

parms folders

Check security settings on target folders

and give Full Control to required users

Warning is thrown: “The

project “INI” file contains

The PublicDir path in the project’s

.ini file in the project folder and

Correct the path specification in the

<Project>.ini file

the following problem INI

File “PublicDir” Does Not

Exist ....

perhaps priparms area is incorrect

after migration

Project or client

confusion

Clients appear to be

confused with others

Petra clients are not properly

configured on the terminal server,

or config.exe is improperly set

Make sure individual Petra clients are

installed in separate folders named for

user active directory names, and that

config.exe is used to specify the path with

the %username% variable. See Page 15.

Users are opening the

last project used but

seeing priparms

belonging to others

The Main module shows

the correct project, but

Map shows a different

one

Cannot open project –

priparms are in use

User has another remote session

going

Close other sessions, perhaps by an

admin on the host

Private parms are confused

Assure proper usage of %username% in

config.exe

Petra Performance

Petra slows down

drastically when a second

or third user opens the

project

Petra clients are not properly

configured, or the project is still on

the NAS

Make sure individual Petra clients are

installed in separate folders named for

user active directory names (Page 15),

and that projects (especially the \DB

folder) is moved from the NAS to local

storage on the terminal server host.

Petra Crashing

Saving or opening WSN

lists and other files from

and to Petra causes it to

crash

Data Execution Prevention is still at

default settings

Change DEP settings as administrator

and reset down to 2 (page 39).

Petra Map crashes when

attempting to turn on

WMS

The server cannot reach the WMS

target URL site

Run a tcping command to check to see of

the target URL can be reached (page 44)

Configure, if necessary, a firewall

exception to allow access to the WMS

(www.datadoors.net)

Install a firewall client to allow access to

the port and URL

Insert the correct information in the

[WMS] section of the PETRA.ini file (page

42)

Problems with

printing, plotting and

other devices

Cannot see my list of

printers

User is on remote desktop and local

printers are not passed through

Have an administrator install required

printer drivers on the host if remote

desktops only are being used

User is using a remote app, but local

devices and drivers are not passed

through

Alter RDP settings so as to allow pass-

through of local print drivers (page 29).

Cannot see my local

digitizing table or other

local device

Local device is not passed through

the RDP protocol

Install a Petra client on the local machine,

and configure it to launch Petra from the

host as a conventional client-server

configuration.

Raster Log

Operations

Cannot get raster logs to

appear in the raster

calibration window or in

the cross-section window

Raster log locations in the .lic files

are no longer valid on the terminal

server

Resolve the log locations for your Petra

project (Page 35)

Raster logs are very slow

in appearing in the raster

calibration window or on

a cross- section

Raster log locations in the .lic files

are no longer valid on the terminal

server or may contain a location

difficult to resolve

Resolve the log locations for your Petra

project (Page 35)

Trying to open a raster

log, and get message

related to missing

petraihs.aut file

Raster log source is a subscription

site, and the license file

petraihs.aut is not in the correct

location

Move the petraihs.aut file from the

geoplus1 folder into the C:\petrasrv folder

on the host machine

Project Operations

3DViz will not launch

ActiveX may need enabled on the

server

See Page 41.

The Thematic Mapper tool

will not open

Map Object library are not installed

See Page 41.

My cursor will not jump to

the correct well on Map

Window-to-window operations with

RDP may not allow this to work

properly

See the work-around on page 46.

User cannot find output files

where they saved them

Under certain circumstances, the

appearance of these may be

Check the locally-mapped drive to see if

the file appears there.

delayed on the host drives, but

appear sooner on locally-mapped

drives

Project repair is very slow,

or no faster than it used to

The project’s DB folder is not

contained on a local drive on the

host machine

Move the project folder to a local drive

on the terminal server host machine

Map module is locking up or

crashing

One or more layers in an overlay

file may be linked or associated to

an external layer file.

Remove this link or repair it.

Citrix profiles may be corrupted

Clear user profiles, reset the map module

and try again

Licensing

License file is wrong

If upgrading from 3.8.x to 3.9.x,

the old geoplus.lic file is obsolete

New license manager and file must be

installed, along with a new IHS.exe

daemon. Check with

PetraLicensing@ihs.com

Connectivity

PowerTools IHS Markit

PowerTools project cannot

link to Petra projects

running on the same

terminal server – See

Appendix 2 in this

document

Petra client path incorporating a

literal %username% in the path (in

lieu of a named user) has not been

set up

Set up a path with a literal %username%

string in it, as PowerTools cannot resolve

that system variable; e.g.:

C:\PetraUsers\%username%\geoplus1

Parms folders and project ini files

have not been fully copied to their

respective locations under the

%username% client path

Copy all project.ini paths under the path

C:\PetraUsers\%username%\geoplus1\P

ARMS

Copy all priparms folders (one per

project) to the client path under

%username%, e.g.:

C:\PetraUser\%username%\priparms\Pr

oject1\

C:\PetraUser\%username%\priparms\Pr

oject2\