Plant Design System (PDS) Citrix Guidedocshare04.docshare.tips/files/29398/293982400.pdf ·...

Plant Design System (PDS) Citrix Guide

Version 2011 (V12)

June 2011

DPDS3-PE-200058B

Copyright

Copyright © 2009-2011 Intergraph Corporation. All Rights Reserved.

Including software, file formats, and audiovisual displays; may be used pursuant to applicable software license agreement; contains confidential and proprietary information of Intergraph and/or third parties which is protected by copyright law, trade secret law, and international treaty, and may not be provided or otherwise made available without proper authorization from Intergraph Corporation.

U.S. Government Restricted Rights Legend

Use, duplication, or disclosure by the government is subject to restrictions as set forth below. For civilian agencies: This was developed at private expense and is "restricted computer software" submitted with restricted rights in accordance with subparagraphs (a) through (d) of the Commercial Computer Software - Restricted Rights clause at 52.227-19 of the Federal Acquisition Regulations ("FAR") and its successors, and is unpublished and all rights are reserved under the copyright laws of the United States. For units of the Department of Defense ("DoD"): This is "commercial computer software" as defined at DFARS 252.227-7014 and the rights of the Government are as specified at DFARS 227.7202-3.

Unpublished - rights reserved under the copyright laws of the United States.

Intergraph Corporation P.O. Box 240000 Huntsville, AL 35813

Terms of Use

Use of this software product is subject to the End User License Agreement ("EULA") delivered with this software product unless the licensee has a valid signed license for this software product with Intergraph Corporation. If the licensee has a valid signed license for this software product with Intergraph Corporation, the valid signed license shall take precedence and govern the use of this software product. Subject to the terms contained within the applicable license agreement, Intergraph Corporation gives licensee permission to print a reasonable number of copies of the documentation as defined in the applicable license agreement and delivered with the software product for licensee's internal, non-commercial use. The documentation may not be printed for resale or redistribution.

Warranties and Liabilities

All warranties given by Intergraph Corporation about equipment or software are set forth in the EULA provided with the software or applicable license for the software product signed by Intergraph Corporation, and nothing stated in, or implied by, this document or its contents shall be considered or deemed a modification or amendment of such warranties. Intergraph believes the information in this publication is accurate as of its publication date.

The information and the software discussed in this document are subject to change without notice and are subject to applicable technical product descriptions. Intergraph Corporation is not responsible for any error that may appear in this document.

The software discussed in this document is furnished under a license and may be used or copied only in accordance with the terms of this license. No responsibility is assumed by Intergraph for the use or reliability of software on equipment that is not supplied by Intergraph or its affiliated companies. THE USER OF THE SOFTWARE IS EXPECTED TO MAKE THE FINAL EVALUATION AS TO THE USEFULNESS OF THE SOFTWARE IN HIS OWN ENVIRONMENT.

Intergraph is not responsible for the accuracy of delivered data including, but not limited to, catalog, reference and symbol data. Users should verify for themselves that the data is accurate and suitable for their project work.

Trademarks

Intergraph, the Intergraph logo, PDS, SmartPlant, FrameWorks, I-Convert, I-Export, I-Sketch, SmartMarine, IntelliShip, INtools, ISOGEN, MARIAN, SmartSketch, SPOOLGEN, SupportManager, and SupportModeler are trademarks or registered trademarks of Intergraph Corporation or its subsidiaries in the United States and other countries. Microsoft and Windows are registered trademarks of Microsoft Corporation. Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of Oracle Corporation and/or its affiliates. MicroStation is a registered trademark of Bentley Systems Inc, all rights reserved. Other brands and product names are trademarks of their respective owners.

Plant Design System (PDS) Citrix Guide 3

Contents Preface PDS ................................................................................................................................................. 5

What's New with Citrix Integration ............................................................................................................ 6

Plant Design System (PDS) and Citrix ...................................................................................................... 7

Custom CMD Files for Publishing PDS .................................................................................................. 7 PDS.CMD Files ....................................................................................................................................... 8

Commands Set in PDS.CMD ........................................................................................................... 8 TEMP Variables .................................................................................................................................... 12

Installation of SmartPlant License Manager ........................................................................................... 17

Windows Firewall for Windows XP and Windows 2003 ....................................................................... 18 SmartPlant License Manager and Citrix ............................................................................................... 19

Additional Citrix Implementation Topics ................................................................................................ 23

Adding Application Path Statements to the System Path ..................................................................... 23 Publishing Complex Links or Shortcuts ................................................................................................ 25 Configuring Dual Monitors .................................................................................................................... 25 Citrix Client Time Zones ........................................................................................................................ 28 Disable the Citrix Virtual Memory Optimizer ......................................................................................... 29 Batch Jobs and the Citrix Server .......................................................................................................... 33

Modifying Batch Queues for Redirected Processing ...................................................................... 33

Index ........................................................................................................................................................... 43

Contents

4 Plant Design System (PDS) Citrix Guide


This document provides command reference information and procedural instructions for the Plant Design System (PDS).

List of PDS Documentation

DPDS3-PB-200003 - DesignReview Integrator (PD_Review) Reference Guide

DPDS3-PB-200004 - Drawing Manager (PD_Draw) User's Guide

DPDS3-PB-200005 - EE Raceway Modeling Reference Guide

DPDS3-PB-200006 - Interference Checker/Manager (PD_Clash) User's Guide

DPDS3-PB-200010 - PDS 3D Theory User's Guide

DPDS3-PB-200013 - PDS EDEN Interface Reference Guide Volume I : Piping

DPDS3-PB-200015 - PDS Equipment Modeling (PD_EQP) User's Guide

DPDS3-PB-200017 - PDS ISOGEN Reference Guide, Vol. 1

DPDS3-PB-200022 - PDS Piping Component Data Reference Guide

DPDS3-PB-200023 - PDS Project Setup Technical Reference

DPDS3-PB-200025 - PDS Stress Analysis Interface (PD_Stress) User's Guide

DPDS3-PB-200026 - Pipe Supports Modeler Reference Guide

DPDS3-PB-200028 - Piping Design Graphics (PD_Design) Reference Guide

DPDS3-PB-200030 - Project Administrator (PD_Project) Reference Guide

DPDS3-PB-200033 - Project Engineer HVAC (PE-HVAC) Reference Guide

DPDS3-PB-200034 - Reference Data Manager (PD_Data) Reference Guide

DPDS3-PB-200035 - Report Manager (PD_Report) User's Guide

DPDS3-PB-200041 - PDS EDEN Interface Reference Guide Volume 2 : Equipment

DPDS3-PB-200042 - PDS EDEN Interface Reference Guide Volume 3 : Pipe Supports

DPDS3-PE-200016 - PDS Express Project Creation Quick Start Guide

DPDS3-PE-200052 - PDS Ortho Draw User's Guide

DPDS3-PE-200029 - Piping Model Builder (PD_Model) Reference Guide

DPDS3-PE-200031 - Project Engineer HVAC Getting Started Guide

DPDS3-PE-200032 - Project Engineer HVAC Overview

DPDS3-PE-200045 - PDS Label Library Merger Utility

DPDS3-PE-200047 - PDS Reference Data Auditing Tool

DPDS3-PE-200048 - Pipe Supports Explorer Utility

DPDS3-PE-200050 - Batch Services Quick Start Guide

DPDS3-PE-200051 - Batch Services User's Guide

Preface PDS

What's New with Citrix Integration


The following changes have been made to the Citrix integration with Plant Design System (PDS) guide.

Version 2011 (V12)

No changes were made for this release.

What's New with Citrix Integration


S E C T I O N 1

Plant Design System (PDS) can be setup to run with Citrix XENAPP6. This document contains information you will need to install and configure SmartPlant License Manager and Plant Design System (PDS) that is not covered in the Citrix documentation.

Custom CMD Files for Publishing PDS Using an ASCII editor such as Notepad, create the following CMD files in the following locations. You then need to use the Citrix standard workflow to publish the CMD files as an application. That application can then be started by users to activate PDS.

Filename: UpdatePlantMonument.cmd Location: C:\WIN32APP\INGR\PDPROJEC\bin Contents: C:\WIN32APP\INGR\PDSHELL\bin\pdsicon.exe; C:\WIN32APP\INGR\PDPROJEC\bin\pdmonument.exe

Filename: PipeSupExplorer.cmd Location: C:\WIN32APP\INGR\PDSHELL\bin\ Contents: C:\WIN32APP\INGR\PDSHELL\bin\pdsicon.exe; C:\WIN32APP\INGR\PDSHELL\share\PsmExplorer.exe

Filename: ExpressProjCreate.cmd Location: C:\WIN32APP\INGR\PDSHELL\share Contents: C:\WIN32APP\INGR\PDSHELL\bin\pdsicon.exe; C:\WIN32APP\INGR\PDSHELL\bin\pdexpress.exe

Filename: VerifyRDB.cmd Location: C:\WIN32APP\INGR\PDDATA\bin Contents: C:\WIN32APP\INGR\PDSHELL\bin\pdsicon.exe; C:\WIN32APP\INGR\PDDATA\bin\ver_ref.exe

Filename: AuditTools.cmd Location: C:\WIN32APP\INGR\PDSHELL\bin Contents: C:\WIN32APP\INGR\PDSHELL\bin\pdsicon.exe; C:\WIN32APP\INGR\PDSHELL\share\audit.exe

Filename: MDP.cmd Location: C:\WIN32APP\INGR\PDSHELL\share Contents: C:\WIN32APP\INGR\PDSHELL\bin\pdsicon.exe; C:\WIN32APP\INGR\PDSHELL\share\pdMDPgui.exe

Filename: PARNU2.cmd Location: C:\WIN32APP\INGR\PARNU\Bin Contents: C:\Win32APP\INGR\PARNU\bin\nuparnu.exe; C:\Win32APP\INGR\PARNU\bin\parnu.cmd

Filename: PARNU1.cmd Location: C:\WIN32APP\INGR\PARNU\bin Contents: C:\WIN32APP\INGR\PARNU\bin\; C:\Win32APP\INGR\PEHVAC\share\; C:\WIN32APP\INGR\PARNU\bin\; C:\WIN32APP\INGR\PARNU\bin\NUPARNU.EXE; C:\Win32APP\INGR\PEHVAC\share\pehperl; C:\WIN32APP\INGR\PARNU\bin\parnu.cmd

Plant Design System (PDS) and Citrix



PDS.CMD Files You can define unique PDS.CMD files for users by selecting the Current User option on the PDS 3D Control File dialog box. By using unique PDS.CMD files, each user can have their own user menu preference resource file, their own font resource file, and their own config resource file.

For more information about the environment variables that you can set, see Commands Set in PDS.CMD (on page 8).

Commands Set in PDS.CMD The PDS.CMD file sets up the working environment within PDS and starts the software. Each user can have their own PDS.CMD file or all users can share the same PDS.CMD file.

Example of a PDS.CMD File @rem = '

@echo off

pdsperl %0.cmd %1 %2 %3 %4 %5 %6 %7 %8 %9

goto endofperl

';

$ENV{'GRAPHICS_TOP'} = 'YES';

$ENV{'PROJ_FILE'} = 'proj1\\';

$ENV{'PROJ_ADDR'} = 'docdata\d';

$PD_SHELL = $ARGV[0];

$appname = "$PD_SHELL\\bin\\pdshell";

#

# If more than one argument, then

# first argument is the path to the utility

# second argument is the executable file name

#

if($#ARGV>$[)

{

$appname=$ARGV[0].$ARGV[1];

if($#ARGV>$[+1)

{

shift;

shift;

foreach $argi (@ARGV)

{

$appname .= ' '.$argi;

}

}

}

system "$appname";

__END__

:endofperl

If you want to add environment variables to the PDS.CMD file, add them before the "$PD_Shell = $ARGV[0];" line.

You MUST include an extra backslash for every backslash that is used in pathing text in the pds.cmd file. For example, if the path you want is \\pdsserver\z\projfile, then you need to define the path in the pds.cmd like this: \\\\pdsserver\\z\\projfile.

The following environment variables can be set in the pds.cmd file.

ISO Environment Variables

$ENV{'ISOPATH'} = 'node:directory path\\';

The exported ISOPATH value is loaded by default into the output path directory slot on the Add Default Set form. It is also used as the default path, ISO output node:Path, when extracting an interactive isometric.

$ENV{'ISOOPTION'} = 'node:directory path\defaults file';



The exported ISOOPTION value is loaded by default into the Options File field on the Add Default Set form. It is also used as a default for the options file, ISO Options File, when extracting an interactive isometric.

$ENV{'ISOSEED'} = 'node: directory path\seed file';

The exported ISOSEED value is loaded by default into the Seed File field on the Add Default Set form. It is also used as a default for the seed design file, ISO Seed Design File, when extracting an interactive isometric.

$ENV{'ISOPLOT'} = 'node:directory path\iparm file';

The exported ISOPLOT value is loaded by default into the Plot File field on the Add Default Set form. It is also used as a default for the plot parameters file, ISO Seed Plot File, when plotting an interactive isometric.

$ENV{'ISOBORDER'} = 'node:directory path\border file';

The exported ISOBORDER value is loaded by default into the Border File field on the Add Default Set form.

$ENV{'ISOBATCH'} = 'node:directory path\isobat\\';

The exported ISOBATCH value is loaded by default into the Batch Job Input File field on the Create Batch Job Input form. The isobat file name is optional. If left blank here it can be set for each batch job input, ensuring a unique input file name.

$ENV{'ISOREPORT'} = 'node:directory path\isorpt';

The exported ISOREPORT value is loaded by default into the Output File field on the Batch Data Reports form. The isorpt file name is optional. If left blank here it can be set for each batch data report, ensuring a unique file name.

$ENV{'ISOBATCHQUE'} = 'PDisocreate';

The exported ISOBATCHQUE value is loaded by default into the Process Queue field on the Schedule Batch Job form.

$ENV{'ISO_ASCII_LOAD'} = 'node:directory path\isoascii';

The exported ISO_ASCII_LOAD value is loaded by default into the Filename field on the Bulk Load Lines From ASCII File form.

$ENV{'PDISOFONT'} = 'XX';

The exported PDISOFONT value defines the font that will be used on the output isometric, both on the face of the ISO, and on the MTO on the ISO. The defined font must be a mono-spaced font.

$ENV{'SYMDGN'} = 'node:directory path\symbol.dgn';

$ENV{'SYMNDX'} = 'node:directory path\symbol.ndx';

$ENV{'SYMLIB'} = 'node:directory path\symbol.lib';

The exported values SYMDGN, SYMNDX and SYMLIB are loaded into the Symbol Design Node:File, Symbol Index Node:File and Symbol Library Node:File fields respectively on the Isometric Symbol Editor form.

$ENV{'ISOUSRREFDIM'} = 'node:directory path\filespec.dat';

where,

node

= the hostname of the project file server,

directory path

= the directory path containing the reference data file,

filespec.dat

= the name of the gridline reference data file.



For example,

$ENV{'ISOUSRREFDIM'} = 'pdsserv1:e:\proj1\project\fw_bldg_a.dat';

After this variable is set, the data in the file filespec.dat will be referenced as a result of enabling Intergraph option 71 in the isometric options file. Note that this file will be used in place of the file fw_projname.dat which is the gridline reference data file by default. When utilizing this variable, the following rules will apply:

If the ISOUSRREFDIM variable is set and points to the proper location of a valid gridline reference data file, this file will be used for placing gridline references on the isometric drawing if Intergraph option 71 is turned on.

If the ISOUSRREFDIM variable is set improperly (for example, UNCpath or filespec are mis-typed) and Intergraph option 71 is turned on, then no references will appear on the face of the iso. That is, the result will be as if no gridline reference data file exists in the project directory.

If the ISOUSRREFDIM variable is not set in the pds.cmd file but option 71 is turned on, then the software will, by default, search for the file fw_projname.dat in the project directory. If it exists and contains valid data, then the gridline reference dimensions will be extracted from this file.

PD_Report Environment Variables

$ENV{‘MDP_IMPLIED_USE_DESIGN_DB’} = 1

Used to report NPD for gaskets and bolts from the Commodity Code labels in the short description. If MDP_IMPLIED_USE_DESIGN is defined, the software retrieves component NPD values from the Design database. If the variable is not defined, the software retrieves the values from the Spec database.

PD_Stress Environment Variables

$ENV{'STRESSPATH'} = 'node:directory path\\';

The exported STRESSPATH value is loaded by default into the Stress Output:Node field on the Stress Analysis form.

$ENV{'STRESSOPTION'} = 'node:users\stress\default file';

The exported STRESSOPTION value is loaded by default into the Stress Options File field on the Stress Analysis form.

PD_Draw Environment Variables

$ENV{'VHL_PPOPS'} = 'command arguments';

The VHL_PPOPS export variable combines a number of arguments with the use of one environment variable, with the arguments separated by a space. These arguments execute certain pre-processing and post-processing options when creating vector hidden line graphics. For example: $ENV{'VHL_PPOPS'} = 'arc backp cell join';

Invokes arc restroking, backplane elimination, cell re-creation and joining of partial elements.

PD_Equip Environment Variables

$ENV{'PD_EIFORMS '} = '\\\\servername\\sharename\\directory\\';

Alternative method to define the Equipment forms directory location. The exported variable allows an individual to use a different set of forms, other than those defined in the Equipment Database Library File Manager. This allows an individual to test things without modifying real data. If this location is undefined in the data manager, PDS uses the forms in



the local machine's eqp directory; c:\win32app\ingr\PDEQP\forms; if it is defined, then every user sees the same forms; if it is exported, it overrides the project setting. This directory path setting needs to be on the local machine.

PD_Shell Environment Variables

$ENV{'iplot_output_directory'} = 'drive:\directory path';

The iplot_output_directory variable determines the output location for iplot files on the local machine.

$ENV{'iplot_dlog_input_monitor'} = 'false';

The iplot_dlog_input_monitor exported variable is used so that PDS will recognize the iplot variable when used at the command line within PDS. This variable was used as a fix to PDS 5.1 due to problem keying in iplot command at the MicroStation keyin window within PD_DESIGN. This command was tested with PDS 6.3.X and Iplot 9.0 and the variable is no longer needed.

$ENV{'PDS_ARCH_TMP'} =' directory path\\';

This exported variable is used to enhance the Project Archival and Retrieval functions. When a Scheduled Project Archive is created, you can specify that the archive be FTP'd to a remote site when complete. The archive will first be created in the TEMP directory of the local node, FTP'd to the remote node, and then deleted from the local node. The location of where the scratch archive is created can be changed using the environment variable PDS_ARCH_TMP (which is useful if the location specified by TEMP cannot accommodate the archive).

$ENV{'PD_IFORMS'} = '\\\\servername\\sharename\\directory\\';

Used to define the PD_Shell forms location rather than the pdshell\forms\ directory on the local machine. Please keep in mind that the folder \\servername\sharename\directory\ must still have a directory under it named forms as that is what this command is looking for.

$ENV{'PD_EDITOR'} = 'node:directory path\editor executable';

Used to define the text editor to be used when revising data through the PD_Shell forms.

$ENV{'PROJ_FILE'} = 'directory path';

Used to define the directory path of the PDS projfile for the current project specifications.

$ENV{'PROJ_ADDR'} = 'Your Proj File Network Address';

Used to specify the node name of the projfile location.

$ENV{'PDS_COMMIT_INTERVAL'} = 'xx';

Used to control the commit interval in all database loading activities in the Project Retrieval Commands. This has the same impact as adjusting the -c option in a risload command line. The default commit value is 25.

$ENV{'NO_TRUNCATE'} = 'YES';

Used to specify whether to use long filenames for dimension tables. Setting this variable to YES allows long filenames. A value of NO limits dimension table filenames to 11 characters (8 characters in the filename, and a 3-character extension).

The variable also works for files extracted from the Graphic Commodities library, the Piping Job Specifications library, and the Assembly library. When you are loading to the libraries with the variable defined:

The filename convention is not limited to 11 characters. Single files can be loaded with the length of the name limited by the size of the PDS key-in field.

The length of individual file names listed in a Load List file are not limited to the size of the key-in field and can have additional characters.



$ENV{'PDS_PF_DISCIPLINE'} = 'discipline_indx_no'; or

$ENV{'PDS_PF_DISCIPLINE'} = 'discipline_name';

Used to specify the Pelican Forge discipline number for the project. This variable can be set to either the discipline number or discipline name from pdtable_111. This variable can also be set as a system environment variable.

$ENV{'PDME_LABEL_SEP_CHAR'} = '-';

Used to specify the concatenation character for multi-line PDME label text. The default character is a dash '-'. There is not restriction on the length of characters that you can use.

$ENV{'PDS_USER_UMENUPREF'} = 'mymenufile.rsc';

Used to specify the user menu preference resource file.

$ENV{'PDS_USER_FONTRSC'} = 'myfonts.rsc';

Used to specify the font resource file.

$ENV{'PDS_USER_CONFIG'} = 'myconfig.cfg';

Used to specify the config resource file.

Project Archival Manager Environment Variables

$ENV{'SUPRESS_UPDATE_LABELS'} = 'YES';

Once this variable is set, the Import Project Retrieval and Scheduled Project Import commands do not update labels while importing the drawings. The label retains the existing definition.

TEMP Variables Setting the TEMP variables for PDS when running in a Citrix environment can be tricky with a couple of issues that you need to be aware of. The suggested workflow given below is just one solution and may not be the best solution for you. You need to work with your Citrix administrators to find your best solution.

First Issue

Processes running on a Citrix platform access the temp folder to store the log files that assist in the troubleshooting and workflows within the PDS application. The default method for creating temporary folders for multiple users (usually pointed to by the TEMP and TMP environment variables) is to create subfolders in the \temp folder using the user's logon ID as the subfolder name. For example, if the TEMP environment variable points to c:\temp, the temporary folder assigned to the user logon ID 4 is c:\temp\4.

After the user is finished and exits that application on Citrix, the temp directory is destroyed and no longer holds the log files and data used during that session; however, these files are needed at times for some workflows in PDS. To overcome this, we suggest that you turn on the Windows FLATTEMP by typing "flattemp /enable" (without the quotes) in a command window. You need to have administrator privileges to do this.

Second Issue

The second issue involves simply setting and using flattemp to give everyone the same temp directory. If two people are running similar or the same process at the same time and the same log file is trying to be written to this folder at the same time, there will be errors. To overcome this, we suggest that each user be provided their own temp folder location by creating a logon script to create, verify, and apply a folder for this specific user at logon time. See below for an example workflow for this.



Example Workflow

Using logon scripts, your administrator can verify if users have their own temp folder on the system. In the sample logon script below, it checks each user at logon to see if they have their own temp folder, if they do not, the script creates a temp folder for the user under C:\Temp\ using their username at logon time (for example: C:\temp\someuser\). The script then sets that user's temp and tmp variable to that folder and requires the user to log into that Citrix application again. The reason for the re-logon is that the temp variable setting does not take effect until that user logs in again. During the logon to the application if the temp variable already exists, the user is not required to log in again and is able to run the Citrix application uninterrupted. It is also possible to use roaming profiles for the users and set the temp variable.

Sample Logon Script

Using gpedit.msc in Windows, you can load the group policy object editor window. Transverse the tree to manipulate the User Configuration > Windows Settings > Scripts (Logon/Logoff) > Logon.

As you can see in this above example at startup the script usrlogon.vbs will run at startup, see below for its contents:

#####################################################

'For getting username

Set shell= WScript.CreateObject("WScript.Shell")



username = shell.ExpandEnvironmentStrings("%USERNAME%")

'For setting users temp variables

Set objShell = WScript.CreateObject("WScript.Shell")

Set colUsrEnvVars = objShell.Environment("USER")

'For creating a folder

ParentFolder = "C:\temp\"

set objShell = CreateObject("Shell.Application")

set objFolder = objShell.NameSpace(ParentFolder)

'code to check for share/folder and or create it

Set objFSO = CreateObject("Scripting.FileSystemObject")

'First we Check if user already has a folder on the share

If objFSO.FolderExists("C:\temp\" & username) Then

'Then we check if the Temp variable is NOT set correctly

If colUsrEnvVars("TEMP") <> "C:\temp\" & username Then

'Set temp variables

colUsrEnvVars("TEMP") = "C:\temp\" & username

colUsrEnvVars("TMP") = "C:\temp\" & username

msgbox "Please Note:" & Chr(13) & Chr(13) & "Since this is your

first logon To this server,"_

& Chr(13) & "your Temp Variable has just been set to" & Chr(13)

& Chr(13) & "c:\temp\"_

& username & Chr(13) & Chr(13) & "Please log on again so it

will take effect."_

& Chr(13) & Chr(13) & " Thank you"

Dim Program

Program = "C:\WINDOWS\system32\logoff.exe"

shell.Run Program

End If

Else

'If user doesn’t have folder already then Create the folder

objFolder.NewFolder username

'Set temp variables

colUsrEnvVars("TEMP") = "C:\temp\" & username

colUsrEnvVars("TMP") = "C:\temp\" & username

msgbox "Please Note:" & Chr(13) & Chr(13) & "Since this is your

first logon To this server,"_

& Chr(13) & "your Temp Variable has just been set to" & Chr(13)

& Chr(13) & "c:\temp\"_

& username & Chr(13) & Chr(13) & "Please log on again so it

will take effect."_

& Chr(13) & Chr(13) & " Thank you"



Program = "C:\WINDOWS\system32\logoff.exe"

shell.Run Program

End If


S E C T I O N 2

Before beginning the product installation, refer to the delivered SmartPlant License Manager readme file for the latest product installation updates. The readme file is delivered in the top level product folder of the product media. Be sure you have the latest version of the SmartPlant License Manager software before beginning the installation. If you do not have the latest version of the software, you can install it using http://ppmapps.intergraph.com/elicense (http://ppmapps.intergraph.com/elicense).

Hardware Configurations

The SmartPlant License Manager licensing machine software should be installed on a stable, single node, hardware configuration (such as a simple PC), with a static IP address, because license key installation and license seat usage authentication depends on the information gathered from the physical hardware. Any automated changes that cause the hardware information not to match with the information used to generate the license key will result in a failure of the authentication process.

Virtual (including VMware®), shadowed, mirrored, dynamic, or distributed hardware configurations cannot be used as a SmartPlant License Manager licensing machine. This includes terminal (application) servers, networked and distributed storage management systems, and so forth. When these specialized systems occur in the user's network, the SmartPlant License Manager licensing machine should be installed on a separate dedicated hardware configuration system. The SmartPlant License Manager licensing machine should be situated on the user's network where it can be accessed by all systems that are running application software that relies on the SmartPlant License Manager licensing machine for license management.

Multiple SmartPlant License Manager licensing machines can be used in the user's network as long as each system is a unique hardware system/installation. If SmartPlant License Manager licensing machines are cloned after the license key has been installed, then the license management will fail on the cloned system. Each SmartPlant License Manager licensing machine requires its own unique license key.

The license machine must have the same version (or later) of SmartPlant License Manager installed as any client machines. In other words, you cannot use a newer version on a client machine to retrieve a license from an older version of SmartPlant License Manager on the licensing machine. The license machine must have the same version (or a newer version) installed than the clients.

You must log in as Administrator to install this software.

1. Insert the Intergraph SmartPlant License Manager media. If the media does not start automatically, double-click Setup.exe in the root folder of the media.

2. Select SmartPlant License Manager Installation.

3. Click Next on the Welcome to the InstallShield Wizard for SmartPlant License Manager page.

4. Enter your name and company name in the User Name and Company Name fields on the Customer Information page. Click Next.

Installation of SmartPlant License Manager

http://ppmapps.intergraph.com/elicense



5. On the Software License Agreement page, select your country from the list and click Display to view the license agreement.

The license agreement is delivered as a PDF file.

6. Carefully read the license agreement. Close the PDF document, and click Yes on the License Agreement page to accept the terms.

7. Select either License Client or License Machine.

8. On the Choose Destination Location page, click Next to install SmartPlant License Manager in the default location. If you want to install the software in another location, click Change and select the new location.

It is recommended that you install SmartPlant License Manager using a path that

contains no spaces, such as c:\win32app\Ingr (the default path).

9. Click Install on the Ready to Install the Program page. A status bar displays the progress of the installation on the Status Setup page.

10. Click Finish on the InstallShield Wizard Complete page to complete installation of SmartPlant License Manager.

Do not delete any files that are created during installation or as a result of using SmartPlant License Manager. Removal of any files causes the license system to fail and can require install, repair, or possibly removal and re-install of SmartPlant License Manager.

Windows Firewall for Windows XP and Windows 2003 SmartPlant License Manager utilizes Transmission Control Protocol (TCP) ports to pass license seats from the SmartPlant License Manager license machine(s) to the workstation(s). TCP port 807 is utilized by the SmartPlant License Manager license machine to ‘listen’ for requests from the workstation(s) for a license seat. If a request is made, a random TCP port is utilized to pass the seat from license machine to client.

Since a firewall is used to prevent unauthorized port access, SmartPlant License Manager has problems working properly with a firewall. Most firewall programs allow an Administrator to open ports to prevent the firewall from interfering with a programs execution. Because SmartPlant License Manager utilizes random ports, there is not a good way to do this unless the firewall program also allows programs to be added to a program list to open ports required by the program. The firewall that is delivered with Microsoft Windows XP and Microsoft Windows 2003 is such a firewall program.

If the user exits the application properly, the license used by the workstation is released back to the pool of licenses available. Sometimes, when an application process is exited abnormally, the license seat is not returned to the License Manager. This is where the SmartPlant License Manager license machine can help. A scavenge routine can be setup to run that will scavenge the network for seats that are reserved. If one is found, the seat can be returned to the pool if it is no longer in use. The firewall prevents the license machine from retrieving the seat and returns a timed out error message.

After installing SP 2 for Microsoft Windows XP or SP1 for Microsoft Windows 2003, pdlice.exe needs to be added to the Exception List for the Windows Firewall (if it is turned on). The following steps will add the appropriate SmartPlant License Manager program to the Exception List, allowing proper scavenging and access to the license machine:

1. Click Start > Control Panel > Windows Firewall.

2. Be sure that the Don't allow exceptions option is not selected.

3. On the Exceptions tab in the Windows Firewall dialog box, click Add Program.



4. In the Add a Program dialog box, click Browse.

5. In the Browse dialog box, find the location of the pdlice.exe program (default location is: c:\win32app\ingr\pdlice\bin or c:\win32app\ingr\splm\bin) in the File name box.

6. Click Open.

7. In the Add a Program dialog box, click Change Scope.

8. Select the My Network (subnet) only option.

9. Click OK.

10. Click OK on the Add a Program dialog box.

11. On the Exceptions tab, verify that pdlice.exe has been added to the Programs and Services list.

12. Click OK to dismiss Windows Firewall.

[Connecting Socket] Connection Time Out is the error message you receive if pdlice.exe is not defined in the Windows Firewall exception list.

SmartPlant License Manager and Citrix Before you install any SmartPlant Enterprise software on a Citrix server, you must install and configure the Citrix software and the corresponding prerequisites on the server. Please refer to your Citrix documentation for more information about any prerequisites.

To run SmartPlant software on a Citrix server, you must install the same prerequisite software that is required for the product to run on a desktop client system. Make sure that any patches or prerequisite software installations are matched to the operating system. For example, a 64-bit operating system may require that some patches or products are also 64-bit. All patches or products should be in accordance with administrative guidance. For more information about software prerequisites for SmartPlant Enterprise products, see the documentation delivered with the product.

Only SmartPlant License Manager client is supported on a Citrix machine.

The SmartPlant License Manager license machine does not support a NAT configuration on a Citrix machine.

Running batch jobs on the Citrix XENAPP 6 server is not supported.

If you are using Citrix, and crossing multiple time zones, the error message SPLM Failed: Server/Client Timers Mismatch by 6+ Hours - <license server> can display. To correct the error, adjust the Citrix server's Time Zone Redirection configuration to prevent it from using the client's local time zone for the Citrix session. For more information, refer to the Citrix's Knowledge Base article Troubleshooting Client Time Zone Issues (http://support.citrix.com/article/CTX303498).



If you have the license machine defined under HK_Current_User for SmartPlant License Manager, you cannot use Test Seat Reservation and Test Seat Release (commands in the SmartPlant License Manager product) to test the licensing machines. Those test options are used to test for the licensing machine configured in the SmartPlant License Manager's registry key (value from HK_Local_Machine in Registry).

Additional information about certified Citrix versions is available on the SmartPlant Enterprise Product Compatibility Matrix on the Intergraph Process, Power & Marine eCustomer Web site. To view this matrix, browse to the following Web address, and type your eCustomer user name and password: https://crmweb.intergraph.com. Click Download Software Updates > Products, and then click the PPM Compatibility Matrices link in the middle of the page.



To install software on a Citrix server, you must log on with an account that has administrator access. Use the Change User Mode Option to set the Terminal Server in the "Installation" mode.

Hardware Requirements

Refer to your Citrix documentation for system hardware requirements for the Citrix server. SmartPlant License Manager has no special hardware requirements beyond those recommended for Windows.

Configure the SmartPlant License Manager Client on Citrix Server

SmartPlant License Manager listens for license requests on TCP port 807, and returns seat information over a randomly selected port. For more information, refer to Windows Firewall for Windows XP and Windows 2003 (on page 18).

Installing and Configuring the Product

Refer to Installation of SmartPlant License Manager for information about installing and configuring SmartPlant License Manager. There are no special requirements for installing SmartPlant License Manager for use with Citrix. Configuring and installing SmartPlant License Manager as a license machine on Citrix is not supported.

Publishing SmartPlant Applications

SmartPlant License Manager does not require any components to be published for user access. Administrative access to the SmartPlant License software can be accomplished by publishing the SmartPlant License Manager application in accordance with standard Citrix practices. Use the provided Start > Intergraph SmartPlant License Manager menu for SmartPlant License Manager as a guide for publishing the individual SmartPlant License Manager applications.

Supported Platforms

SmartPlant License Manager Version 11 or greater

SmartPlant License Manager Version 10

Citrix Presentation Server 4.5.1 64bit Enterprise Edition

Citrix Presentation Server 4.5.1 32bit Enterprise Edition

Citrix Presentation Server 4.5.1 64bit Advanced Edition

Citrix Presentation Server 4.5.1 32bit Advanced Edition

Citrix XENAPP 6 on Microsoft Windows Server 2008 R2

Microsoft Windows Server 2003 Standard Edition

Microsoft Windows Server 2003 R2 Standard Edition

Microsoft Windows Server 2003 R2 Standard Edition Service Pack 2

Microsoft Windows Server 2003 Standard X64 Edition Service Pack 2

Microsoft Windows Server 2003 R2 Enterprise X64 Edition Service Pack 2

Microsoft Windows Server 2008 R2 Enterprise X64 Edition

Known Issues

Configuring SmartPlant License Manager as a license machine on Citrix is not supported.

See Also

Configure a License Machine for Current User

Additional Citrix Implementation Topics


S E C T I O N 3

The following topics contain additional configuration and tuning information related to publishing applications on Citrix.

Adding Application Path Statements to the System Path

Windows stores system path statements for individual executable files under the following registry path (depending on the platform):

32-bit O/S: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\App_name.exe

64-bit O/S: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\App_name.exe

When a program registers an application path this way, Windows adds the path statement to the search path whenever the application is run. This path information becomes part of the System Search Path search order.

When applications are launched through Terminal Services (or Citrix), these path statements are not automatically added. If an application requires this path, then the path information from the appropriate AppPath registry key must be added to the path variable of the System Environment.

Ensure that you back up the current value of the system path to a file for later reference if there is an issue. Making a mistake during the modification of the system path variable can render the computer unusable. It is essential to know the path contents prior to the modification to bring the computer back with any real confidence if there is a problem.

1. In the Registry, copy the data of the Path value for the application executable:

32-bit O/S: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\App_name.exe




64-bit O/S: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\App_name.exe

2. Display the System Properties window via the Control Panel.

3. Click the Advanced tab.

4. Click Environment Variables.

5. In the System variables list, select Path and click Edit.

6. Paste the value data from the Registry to the end of the Path string.

7. Click OK to dismiss all windows.



Publishing Complex Links or Shortcuts Most Citrix applications can be published by inserting the contents of a desktop or start-menu shortcut as the command line of the published application’s Location properties. However some applications use complex switches or command-line arguments that lose their meaning when copied into the Location window of the Citrix Access Management Console. For this situation, it is necessary to create a command line script (.CMD) that will supply the required arguments and parameters to the application being launched.

This .CMD is the object that gets published. This does not compromise the functionality of the application.

1. Copy the command-line string from the Target property of the shortcut.

2. Open Notepad (or any text editor) and paste the string into an empty file.

3. Edit the arguments and switches to replace any relative path notations (such as ..\ and .\) with fully qualified paths.

If an argument with a path name includes a directory or file name with spaces, enclose the argument in double quotes (for example, "C:\Program Files\MyApp\Myapp.exe").

4. Save the file with a .cmd extension.

5. Publish the .CMD file as the application in Citrix. The file acts like a load script that will launch the application with the required arguments as originally intended.

Configuring Dual Monitors After logging into the Citrix portal via the Citrix Web Client, perform the following procedure.

1. Click the Customize User Interface icon on the title bar.



2. Click Connection Preferences.



3. Select the desired screen resolution from the Select window size list.



4. On the title bar, click Return to Application List.

Citrix Client Time Zones When Client Time Zone (CTZ) is enabled, the client passes its time zone information (not the clock time) to the server. The server obtains the clients time zone information (GMT, daylight saving, and so on) and compares it with its own time zone information. If it is different, the server stores the clients' time zone information in the registry.

When the server and client have the same time zone (both EST):

HKey_Users\<<User-SID>>\Software\Citrix\SessionTimeZone\1

"UseRegTimeZone"=dword:00000000

When the server (EST) and client (PST) have different time zones:

[HKEY_CURRENT_USER\Software\Citrix\SessionTimeZone\1]

"Display"="Pacific Standard Time"

"Dlt"="Pacific Daylight Time"

"TZI"=hex:e0,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0a,00,00,00,05,00,0

2,00,00,\

00,00,00,00,00,00,00,04,00,00,00,01,00,02,00,00,00,00,00,00,00

"UseRegTimeZone"=dword:00000001

A time zone hook is loaded for every application running inside that client session. Those applications use the clients' time zone instead of the servers. For older version of ICA Clients, time zone information does not pass to the server. Thus, the server tries to estimate the clients' time zone. The time zone synching happens only during session connection.



You can configure the setting by accessing Server Farm Properties on the MetaFrame Settings tab or through a Policy within the Citrix Management Console.

1. Use local time of ICA Clients: All timestamps for all applications are based on the clients' time instead of the servers.

2. Disable local time estimation: Available after Use Local Time of ICA Clients is selected. This option prevents estimation of local time for ICA Clients other than the ICA Win32 and WinCE Clients.

For Feature Release 1, the ICA Win32 and WinCE Clients distributed with MetaFrame XP send local time information to the MetaFrame server. For all other versions of ICA Clients, the local time is estimated and may not be accurate. For Feature Release 2, the latest versions of ICA Clients distributed with MetaFrame XP send local time information to the MetaFrame server. For earlier versions of ICA Clients, the local time is estimated and may not be accurate. As of Feature Release 2, the Citrix ICA Java Client does not support Client Time Zone Mapping. However, the Citrix ICA Java Client time zone is estimated.

This feature should be disabled in a SmartPlant Foundation integrated environment. For the handling of licensing tokens, SmartPlant License Manager should use the local server time to track the expiration of tokens in the enterprise. If CTZ feature is enabled, the License Server will not be able to accurately track the expiration of tokens, and licensing problems will result.

Disable the Citrix Virtual Memory Optimizer Within Citrix Presentation Server 4.5, there is a service named Virtual Memory Optimization (VMO). The VMO service is inadvertently corrupting the .NET images on the computer. When the application that relies on the image attempts to start, it cannot. It terminates quickly with .NET errors reported to the event logs. The problem is transient because the when the .NET optimizer service runs and the native images are processed and the application works again. The application will work until the VMO kicks in again causing image corruption.

To solve this problem, the Citrix Virtual Memory Optimizer (VMO) service needs to be set to disabled. This is done as a FARM-WIDE policy in the Citrix Access Management Console – the .Net optimizer should be set to Manual (which it is by default).

1. Stop the Citrix Virtual Memory Optimization service and set it to disabled.



Computer Management >Services and Applications > Services > Citrix Virtual Memory Optimization > Disabled.

2. Disable the VMO service as a FARM-WIDE policy.

a. In the Citrix Access Management Console, expand the Citrix Resources and Presentation Server nodes.

b. Right-click Farm, and then click Modify farm properties > Modify Memory/CPU Parameters.



c. In SPEctx – Farm Properties, uncheck Memory Optimization.



To repair the corrupt .NET images in place without removing and reinstalling software:

1. Complete the "Proactive" steps in the previous section: 1.) Stop the VMO service and, 2.) Disable the service as a FARM-WIDE Policy.

2. Open a command prompt to C:\windows\Microsoft.Net\framework64\ and run "ngen.exe update" (Ignore any embedded errors – many are expected. The process will take a few minutes).

3. Open a command prompt to C:\windows\Microsoft.Net\framework\ and run "ngen.exe update" (same-to-same)

This will fix .NET 3.5 and 3.0 and 1.1 images in addition to the 2.0 because the .NET 2.0 NGEN is the unified definition for all of these versions of .NET – there is currently no need to run NGEN for 3.0/3.5/1.1 – just for 2.0. If 2.0 does not exist on the computer, then the 3.0/3.5 NGEN(s) would work.



Batch Jobs and the Citrix Server Running batch jobs on the Citrix server is not supported. However, you can pipe the batch processes from the Citrix server to another computer. For more information, see Modifying Batch Queues for Redirected Processing (on page 33).

Modifying Batch Queues for Redirected Processing When batch jobs are submitted, the processes execute on the client node. In some cases it may be necessary to redirect these processes to a server node that has more compute power and memory. A batch (local) queue can be changed to a pipe (remote) queue using the PDS Queue utility.

1. While logged in as an administrator on the local node, start Batch Manager.

If all PDS queues are created local, the dialog box will display as follows:

The fact that the Queue Type is set to batch indicates that all queues are local to this node.

2. Exit Batch Manager and start the PDS Queue utility. In order to create Queues on a computer using UAC, you must right-click the PDS Queue utility and select Run as administrator.

3. You may get a message that All Products Have Queues Created. Accept this warning.

The Queue Creation utility displays Reading information from the queue.lst file and the

local machine.

The queue.lst file is not to be confused with the queue_descript file. The queue.lst file is located in the same directory with the proj file, and is used by the PDS Queue Creation utility.



The PDS Queue Creation utility dialog box displays.

When this dialog box displays, all products are dithered (in this example) because the PDS Queue Creation utility has determined that queues for all products have been created.

4. By turning on Enable all for configuration, all products become available.

5. Select the product whose queues will be reconfigured (in this example, PD_Clash). After clicking the product, you can click the list by the Queue Name field to display the list of all queues that product uses. If ALL is selected, all of the queues that appear in the list will be reconfigured.

6. In the next figure, you can see that the Pdclash_server queue has been chosen to be reconfigured, the Remote Node box has been checked, and the name of the server has been entered.



Note that when the pipe queue is created, neither the existence of the remote node nor the existence of the corresponding batch queue are checked; you must be certain that the server name is correct and that the corresponding batch queue exists on the specified server.

If the queue already exists, the software turns on Overwrite Existing Queue. You must leave the setting turned on to re-create the existing queue as the new pipe queue.

7. Click OK to display the following message regarding the queue.lst file:

When creating a pipe queue to a remote node, clicking Yes on this dialog box will write information for the specified queue(s) into the queue.lst file. By default, the queue.lst file has entries that look like this:

[PD_Clash Queues]

node=

When a client node that is using this proj file creates a pipe queue used by this discipline and saves the information to the queue.lst file, the information will be changed. Considering the example of the Pdclash_server queue that was created as a pipe queue to the node CADSRV, the PD_Clash entry in the queue.lst file would now look like this:

[PD_Clash Queues]

node=

PDclash_server=CADSRV

When another client node is creating PD_Clash pipe queues using the PDS Queue Configuration utility and Read data from ASCII file has been selected, the node CADSRV will appear in the Remote Node field. In this manner, the System Administrator can create all required pipe queues from one client, change the permissions of the queue.lst file to read only, and then other clients will see the preferred location to create their pipe queues to. Changing the permissions of the queue.lst file to read-only will not stop clients from creating pipe queues to other nodes, but it will show them where they should be created to and also stop them from altering the information in this file.

Some queues are shared by more than one application. For example, the PDreport queue is used by PD_Clash and PD_Projec as well as PD_Report. If PD_Clash pipe queues are created, the information for the PDreport queue will also appear in the PD_Report and PD_Projec sections of the queue.lst file.



8. After creating the pipe queue using the PDS Queue Creation utility, go back into Batch Manager and make sure that the queue was successfully created to the correct destination.



With the queue selected as shown above, click Queue > Properties from the menu bar, then click the Destinations tab to see where this pipe queue's destination is.

This is a quick way to check where batch jobs sent to this queue will be processed. It is possible to add additional destinations to this pipe queue; if the first destination in the list is disabled, the next one will be used. See the on-line help for additional information.

After the pipe queue has been created, the following items should also be checked to make sure the pipe queue can be used successfully:

Does a batch queue by the same name exist on the specified server?

A batch queue with the same name must exist on the server. In this example, the PDclash_server batch queue must exist on the node CADSRV.

Has compatible account mapping been set up?

This is where the use of domain users and groups is critical! Consider the following example:

Client node = PDS1

Logged in user = PDS\mary

Batch services account mapping = PDS\* = PDS\pds

Server node = CADSRV

Batch services account mapping = PDS\* = PDS\pds

File permissions on the project files are:

Everyone Read

PDS\Administrators Full Control

PDS\Domain Users Change

PDS\pds Full Control



When PDS\mary submits a batch job on node PDS1 which is piped to the same queue on the node CADSRV, she will be mapped to the PDS\pds user. Because this user has access to the project files the batch job will complete successfully.

Can the server access the correct schemas file?

Once the batch job starts processing on the server, it will need to attach to the required databases. This means that the server must be able to find the correct schemas file. If all nodes are using the same schemas file, then it may simply be a matter of performing the Locate Schema File operation on the server and locating the shared schemas file. If the batch job cannot attach to the required database an error similar to the following will be seen in the error log (probably located in the c:\temp directory on the server):

*******************************************

* RIS Error: RIS_E_UNKNOWN_SCHEMA (0x8a94a142) *

* *

* default schema pd_xxxxxx *

* *

* No such schema was found in the schema file or *

* a mismatch in the schema password. *

* *

****************************************************

If different schemas files are in use, it may be necessary to use an environment variable, RIS_PARAMETERS, to tell the server which schemas file to use. See Setting the RIS_PARAMETERS Environment Variable (on page 39), for a description of this.

In addition to problems finding the correct schemas file, the batch job may have problems accessing the required project files. This typically happens when a local project is being used with local batch queues, and later the queues are change to pipe queues. Because the project directories have not been shared on the local node, the batch job running on the server cannot access the project files. In this case, the batch log is typically empty. Items to check are: whether or not the correct directories have been shared, what the permissions are on the share, and what the permissions are on the files being shared.

The best way to test redirected batch processing is to start Batch Manager and use the Server > Connect command to connect to your remote server and display its queues. When entering the server name preface it with \\ (for example, \\CADSRV). Arrange the two windows so that both the local pipe queues and the remote batch queues can be seen. With this set up, submit a batch job. Then, quickly switch to Batch Manager to see that the request made it to the server. When the batch job is finished, the output will be sent to the c:\temp directory (or wherever the TEMP environment variable is set to) on the server. See Log Files Produced by PDS Batch Jobs, for a complete listing of log files produced by PDS batch jobs.

See Also Setting the RIS_PARAMETERS Environment Variable (on page 39) Configuring the PDS Batch Mail Utility (on page 40)



Setting the RIS_PARAMETERS Environment Variable

In most cases, where a single schemas file is in use by all nodes, this environment variable does not have to be set. If multiple schemas files are in use, then this environment variable will need to be set to tell the server where to find the correct schemas file.

When a RIS-enabled application needs to access the database, it looks in the parms file in the \win32app\ingr\share\risxx.xx directory to find out where the schemas file is. This file can point to only one schemas file. For example, if the schemas file used by the majority of the PDS projects is located in the c:\ris directory on the server, then you would log on to the server, and do a Locate Schema File operation, and point to this file. If another schemas file is being used for a different set of projects, a copy of the parms file that points to that schemas file should be copied to the server.

For example, the majority of the projects use the databases listed in the schemas file located in the c:\ris directory on the server. However, one project uses a different set of databases listed in a schemas file on Mary's node in the c:\ris directory on her node (PDS1). For her to be able to submit batch processes to the server, the server must know how to get to these databases. A copy of the parms file from Mary's node could be copied to the c:\ris directory on the server and named mary_parms. On Mary's node the environment variable RIS_PARAMETERS would then be set to c:\ris\mary_parms.

When a batch job is sent from Mary's node to the server, the value of RIS_PARAMETERS will also be sent to the server. When the batch process needs to attach to a database, rather than using the parms file in the \win32app\ingr\share\risxx.XX directory (on the server) to find the schemas file, it will look in the location specified by RIS_PARAMETERS (in this example, c:\ris\mary_parms). This parms file points to the schemas file back on Mary's node, and the required databases will be located.

However, setting RIS_PARAMETERS not only affects batch jobs, but also interactive jobs. Once RIS_PARAMETERS is set to c:\ris\mary_parms, then when Mary starts PDS interactively RIS will look in the same place on Mary's node. Therefore, a c:\ris directory must be created on Mary's node and the same parms file copied there and renamed to mary_parms.

All of this will work just fine provided that the value of RIS_PARAMETERS makes it to the server unaltered. The following factors must be considered:

When the batch job is received by the server, the Batch Services account mapping on the server is consulted to see which user this job will run as. In this example, PDS\mary is mapped to PDS\pds. If, on the server, the PDS\pds user has a user environment variable named RIS_PARAMETERS and it is set to a different value, then this value will be used, and the correct databases will not be found.

Assuming the batch job has been received by the server and the PDS\pds user does not have a conflicting user environment variable setting for RIS_PARAMETERS, things can still go wrong. If a system environment variable (used for ALL users) named RIS_PARAMETERS has been set to a conflicting value, then this value will be used, and the correct databases will not be found.

The use of the RIS_PARAMETERS environment variable must be carefully thought out so that its value, as set on a client node, is not overwritten after it reaches the server.



Configuring the PDS Batch Mail Utility

When batch jobs are redirected to the server, the resulting log files are typically placed in the c:\temp directory on the server. You can also have the log files from certain batch processes to be mailed to a specified user.

The PDS Batch Mail utility supports the following mail methods:

MAPI

SMTP

SMTP is more convenient because it sends mails directly to users while MAPI requires users to periodically check the event log for the information.

Security controls from Microsoft Outlook 2003 and later prevent emails from being sent automatically through MAPI; therefore, you must use SMTP when configuring the PDS Batch Mail utility for Microsoft Outlook 2003 and later.

Enabling the PDS Batch Mail Utility through MAPI

1. The server must have the capability to send mails from the user name that the batch job is mapped to. For example, if batch jobs are mapped to the user PDS\pds, then you should be able to log in as that user on the server and send mails.

2. On the server node, Batch Services must be loaded with the Interact with Desktop option, which results in a collapsed DOS window at the bottom of the screen whenever a batch job is running.

3. The following environment variables must be set (either in Control Panel or in the .profile):

PDS_MAIL_RECIPIENT---must be set to an address recognizable by the mail provider. The easiest way to validate this setting is to send mail to the user, and specify the same string used for the environment variable in an interactive mail session.

PDS_MAIL_LOGIN and PDS_MAIL_PASSWORD---must be set if the specified user does not have an active mail session for the same user account. For example, if you stay logged in to your mail provider all day in the same account that the batch jobs are mapped to, you do not have to set these two variables. In addition, PDS_MAIL_PASSWORD is required only if you mail provided requires it when you activate a mail session.

Setting environment variables on Windows is accomplished using Control Panel > System.

As an example, batch jobs submitted by Mary while logged in on her node as PDS\mary are mapped to PDS\pds and then redirected to CADSRV. On CADSRV, all batch jobs are mapped to PDS\pds (*\* = PDS\pds). The pds user logged in on the server and set the PDS_MAIL_RECIPIENT, PDS_MAIL_LOGIN, and PDS_MAIL_PASSWORD environment variables as user environment variables. These were all set for Mary's email address (mmartin). The pds user also verified that while logged in on the server that email can be sent to user mmartin. When batch jobs are initiated by Mary on her node, she will now get email that includes the batch job log file.

There is one problem with this setup---because all batch jobs are mapped to PDS\pds on the server, Mary will be receiving the email when anyone submits a batch job to the server. For each user to receive the email from their own batch jobs, the user's true identity must be preserved throughout the course of the batch job. In this case, rather than:

Mary's node PDS\* = PDS\pds

Server *\* = PDS\pds

You would need:

Mary's node PDS\* = PDS\mary

Server PDS\mary = PDS\mary



Mary's node PDS\mary = PDS\mary

Server PDS\mary = PDS\mary

In the first case, Mary will receive the email from any batch job initiated by a PDS domain user while logged in on her node. In the second case, Mary will receive only the email resulting from batch jobs that she initiates.

One additional note for those using Microsoft Exchange Server as the email provider, the PDS_MAIL_LOGIN environment variable must be set to the profile name (as seen using Control Panel > Mail and Fax > Show Profile).

Enabling the PDS Batch Mail Utility through SMTP

To use the SMTP mail notification, your mail system must be able to handle SMTP mails. In some systems, a program called SMTP gateway provides this functionality. The gateway allows mails to be sent between users running various mail packages. Contact your mail administrator to see if your installation supports the SMTP mail notification.

In addition, you must set the PDS_MAIL_SMTP_ADDRESS environment variable. When sending mails, the utility checks this variable to determine whether to use SMTP. If it is not set, it will use MAPI.

The PDS Mail Utility must be able to recognize the SMTP address to which the mails are sent. The following methods are available to provide this information. The method you choose depends on whether a direct or an indirect SMTP address is available for the receiver. For example, if the mail address is [email protected], you can use the direct method. If you want to use the address [email protected], an alias for the previous address, you must use the indirect method. Contact your mail administrator to determine your mail situation.

Direct SMTP Mail Support

If you want to send mails to a direct SMTP address, then set the PDS_MAIL_SMTP_ADDRESS environment variable with this address. The PDS_MAIL_SMTP_HOST environment variable is not required.

Indirect SMTP Mail Support

If you want to send mails to an indirect SMTP address, then set the PDS_MAIL_SMTP_ADDRESS environment variable with this address, and set the PDS_MAIL_SMTP_HOST environment variable with the SMTP host (the computer that is running SMTP).

When SMTP sends mails, it displays the sender's address as PDSMAIL [username@hostname] where username is the user logged onto the system and hostname is the name of the system where the job is running.


A Adding Application Path Statements to the

System Path • 25 Additional Citrix Implementation Topics • 25

B Batch Jobs and the Citrix Server • 35

C Citrix Client Time Zones • 30 Commands Set in PDS.CMD • 10 Configuring Dual Monitors • 27 Configuring the PDS Batch Mail Utility • 42 Custom CMD Files for Publishing PDS • 9

D Disable the Citrix Virtual Memory Optimizer

• 31

I Installation of SmartPlant License Manager

• 19

M Modifying Batch Queues for Redirected

Processing • 35

P PDS.CMD Files • 10 Plant Design System (PDS) and Citrix • 9 Preface PDS • 5 Publishing Complex Links or Shortcuts • 27

S Setting the RIS_PARAMETERS

Environment Variable • 41 SmartPlant License Manager and Citrix • 21

T TEMP Variables • 14

W What's New with Citrix Integration • 7 Windows Firewall for Windows XP and

Windows 2003 • 20

Index

Plant Design System (PDS) Citrix Guidedocshare04.docshare.tips/files/29398/293982400.pdf ·...

Documents

Transcript of Plant Design System (PDS) Citrix Guidedocshare04.docshare.tips/files/29398/293982400.pdf ·...