Increasing Version Control Space

Increasing
the Space Allocated for Version Control Data Files Page 1 of 263
System Administration
and Maintenance
Key Topics
Developing a Security Scheme
DeltaV Remote Client Overview
DeltaV Database Overview
Version Control
Quick Reference
Recommended Maintenance Practices
Problem Solving
DeltaV Zones
Inside this topic
DeltaV Zones uses a combination of hardware and software to connect separate DeltaV systems (zones). The benefits of connecting DeltaV
systems include:
 Operation functions can be performed on any connected DeltaV system from a single workstation.
 Control strategies can exchange information between systems.
 The DeltaV systems can be administered and configured separately.
 DeltaV upgrades can be applied separately to each connected system.
Note The DeltaV Zones discussed in this section is not related to the DeltaV Zone 1 and Zone 2 I/O cards or installations in hazardous
locations.
Zones Hardware Architecture
The hardware implementation of DeltaV Zones requires the addition of an Inter-Zone Server (IZS) in each DeltaV system. The Inter-Zone
Servers are then connected by an Inter-Zone Control Network (IZCN). The only function of the Inter-Zone Servers and their network is to
communicate Inter-Zone operating data between systems.
Each IZS node must have:
 a network interface connection (NIC) (two for redundant communications) for DeltaV network
 a network interface connection (two for redundant communications) for the Inter-Zone Control Network
The following figure shows a simple example of a DeltaV Zones implementation connecting two DeltaV systems. The purpose of this
diagram is to show how the Inter-Zone Servers connect to the DeltaV network and to each other. The diagram is not intended to be a
recommended configuration.
file://C:\Documents and Settings\Administrator\Local Settings\Temp\~hh776C.htm 05/12/2020
Increasing the Space Allocated for Version Control Data Files Page 2 of 263
Simple Example Zones System
As the figure shows, a DeltaV zone is a DeltaV system that includes an Inter-Zone Server. That is the only difference between a zone and a
system.
A more advanced implementation of zones is shown in the following figure. This network includes redundancy in both DeltaV networks and
in the Inter-Zone Control Network. The figure also includes a plant network as well. Note that OP_STA_A and OP_STA_B have been
configured as Terminal Servers and PPLUS_A and T_CLIENT_1 have been configured as Terminal Clients. With the system configured as
shown ZONE_B can be configured from ZONE_A, ZONE_A cannot be configured from ZONE_B, and both zones can be configured from
the terminal client T_CLIENT_1.
Note In systems with redundant Inter-Zone Servers, there is a loss of communications for several seconds after an IZS switchover occurs.
During this delay, external references in modules are affected. The .CV values are Hold Last Value and .ST values are BadNoCommLUV
(numeric value 24). This delay can last as long as 30 seconds.

You should consider this delay when configuring control strategies with control across zones.
Redundant Inter-Zone Control Network with Plant LAN
After implementing DeltaV Zones you can perform non-control functions between DeltaV systems using standard Windows network support
functions over a separate plant or non-control network. The DeltaV workstations that use the plant network must have sufficient Domain trust
relationships in place. All workstation names must be unique among all connected DeltaV systems (no duplicate workstation names anywhere
within the zones).
Interconnected zone hardware must all be in the same time zone and have the same installed language choice.
The only DeltaV menu options on an IZS are:
 Engineering | FlexLock
 Help | Books Online
 Installation | DeltaV Workstation Configuration
 Operator | DeltaV Login
If your DeltaV systems are configured as workgroups and you need to add users who can log in to the IZS, do the following:
1. From the DeltaV User Manager on another workstation in the system, create the users.
2. Use Replicate Account to copy the account to the IZS.
3. Close the DeltaV User Manager.
4. Download the workstation.
5. Download the IZS.
The user accounts now exist in the IZS.
For more information on installing and setting up IZS hardware and other IZCN network configurations, refer to Installing your DeltaV
Digital Automation System.
Note If you are connecting DeltaV systems that are configured as domains, each system must have a unique domain name.
Implementing Zones
The following figure shows a portion of the DeltaV Explorer hierarchy of a DeltaV system whose zone name is ZONE_A. IZS_A is the Inter-
Zone Server in ZONE_A.
General procedures to implement DeltaV Zones to connect existing DeltaV systems are contained in the following list. For detailed
instructions refer to the appropriate section of the DeltaV documentation.
The following assumes the DeltaV systems are off line (not running a process).
1. Install, configure, and set binding order for network interface connections (NIC) in the Inter-Zone Servers.
2. Connect Inter-Zone Servers to DeltaV Networks and each other through hubs and switches.
3. Upgrade DeltaV software on all workstations within each DeltaV system
4. Install DeltaV software on Inter-Zone Servers.
5. On the Select Your Workstation Type dialog select Inter-Zone Server.
From the ProfessionalPLUS workstation in each DeltaV system:
1. Select the Enable Zones checkbox in the System Preferences dialog.
2. Name the zone from the Properties dialog of top-level node (DeltaV_System) in DeltaV Explorer. This name is how other DeltaV
systems specify this system.
3. Create an Inter-Zone Server under the Control Network. This Inter-Zone Server represents the IZS hardware installed in the DeltaV
system.
4. If you are installing redundant Inter-Zone Servers, select the Inter-Zone Server is redundant checkbox on the server's properties dialog.
5. Create a Remote Zone container under the IZS for every other DeltaV system this system is connected to.
You can create the Remote Zone containers:
 manually,
 by exporting and importing zone topologies,
 by auto-sensing remote zone areas.
If you create the Remote Zone containers manually, the names must be the zone names given to the other systems in their
configurations.
Each Remote Zone container has two subfolders: Local Shared Areas and Remote Zone Areas.
6. In Local Shared Areas under each Remote Zone container, specify the areas in this DeltaV system whose parameter data you want to be
visible in the system represented by the Remote Zone container. You also specify whether the other system has read or read and write
access to each area.
7. Select File | Export | Workstation Configuration to create a cfg file.
8. If you are using zone topologies to create Remote Zone containers, select the Inter-Zone Server, then select Zones Topology Export
from the context menu to create an fhx file of the zone's topology.
From the Inter-Zone Server in each DeltaV system:
1. Run Workstation Configuration.
2. Select Inter-Zone Server in the Select Workstation Type area of the dialog.
3. Browse to and select the .cfg file you created earlier.
4. If you are installing redundant Inter-Zone Servers, refer to Redundant Inter-Zone Servers.
5. Set the Primary and Secondary DeltaV and Primary and Secondary IZCN network NICs.
6. If you want users to be able to write to areas you shared as read and write from other zones, configure Remote Zone Areas.
There are two ways to configure Remote Zone Areas:
 If your Inter-Zone Network is complete and working and you know how you want to share areas with other zones, you can Auto-
sense Remote Zone Areas.
 If your Inter-Zone Network is not complete but you know how you want to share local areas with other zones, you can Export and
Import Zone Topologies.
For a discussion of how Local Shared Areas in one DeltaV system relate to Remote Zone Areas in another DeltaV system refer to
Remote Zone Areas.
7. Assign the Remote Zone Areas to the Alarms and Events subsystem of a local Operator Station (not an Application Station) to have
alarms appear in the alarm banner and displays (if the areas are shared as read and write) and alarms and events to be recorded in the
Event Chronicle. Refer to Inter-Zone Alarms and Events for more information.
Note For a list of hardware alarm messages, including descriptions of the specific error conditions that trigger each message, refer to
Hardware Alarm Messages.
The Remote Zone Areas are also available in the DeltaV User Manager when you assign members to groups or keys to users.
1. After Workstation Configuration completes on the IZS, download the Inter-Zone Server from the ProfessionalPLUS workstation.
2. Create new modules or modify existing modules to read data from other DeltaV systems as required for your situation.
3. Create new operator pictures or modify existing pictures to incorporate data from other DeltaV systems as required for your situation.
You can use the DeltaV Upgrade Picture Expert to use existing pictures to create pictures that access data from other DeltaV systems.
The following sections expand on installation procedures that are unique for DeltaV Zones.
Remote Zone Areas
For example, a DeltaV Zones implementation contains two DeltaV systems whose zone names are ZONE_A and ZONE_B. The following
figure shows part of the DeltaV Explorer hierarchy of ZONE_A.
The ZONE_B Remote Zone container represents the DeltaV system whose zone name is ZONE_B. Under the ZONE_B container the Local
Shared Areas specifies which areas from ZONE_A can be accessed in ZONE_B and whether that access is read only or read and write.
Remote Zone Areas lists the areas in ZONE_B that are defined as Local Shared Areas under ZONE_A in ZONE_B's configuration. The
following table shows how Local Shared Areas and Remote Zone Areas could be configured for ZONE_A.
Configuration from ProfessionalPLUS in ZONE_A
ZONE_B Configuration
Areas in
ZONE_A Local Shared Remote Zone
Areas Areas
AREA_A ZA_AREA10 ZB_AREA20
ZA_AREA10 ZA_AREA12 ZB_AREA21
ZA_AREA11 ZB_AREA22
ZA_AREA12
ZA_AREA13
The following figure shows a split view of DeltaV Explorer in ZONE_A that includes the details for the ZONE_B Remote Zone container
Local Shared Areas and the Remote Zone Areas panes.
In the Local Shared Areas pane ZA_AREA10 has its access defined as Read & Write. That means that users in ZONE_B who have sufficient
rights in ZONE_A can read and change parameter values in this area (if other criteria are met).
In the Remote Zone Areas pane the Name column contains the names that areas in ZONE_B are known by in this system. You can rename the
remote zone areas. The Remote Zone Area Name column shows the area's name in the remote system. If you add a remote zone area whose
name duplicates an existing local or remote zone area name, a number is appended to the name to make it unique in this DeltaV system.
Similarly, from ZONE_B the ZONE_A container's Local Shared Areas and Remote Zone Areas could be configured as shown in the
following table.
Note Area names and Remote Zone Area names must be unique within each DeltaV system. If you attempt to add remote zones areas whose
names already exist within a system, the conflicting names are modified to ensure that they are unique. You can rename the Remote Zone
Areas if you give them names that are unique within the DeltaV system.
Configuration From ProfessionalPLUS in
ZONE_B
ZONE_A Configuration
Areas in
ZONE_B Local Shared Remote Zone
Areas Areas
AREA_A ZB_AREA20 ZA_AREA10
ZB_AREA20 ZB_AREA21 ZA_AREA12
ZB_AREA21 ZB_AREA22
ZB_AREA22
Populating the Remote Zone Areas folder is required if:
 You want users to be able to write to parameters in another zone,
 You want alarms and events from a remote zone to be recorded in a local zone,
 You want alarms from the remote zone to appear in the alarm banner and alarm displays in the local zone.
The tables show how Local Shared Areas defined in one DeltaV system appear as Remote Zone Areas in other zones after adding them from
another system. For example, the areas configured in ZONE_A as Local Shared Areas (ZA_AREA10 and ZA_AREA12) in ZONE_B appear
in ZONE_B's Remote Zone container in ZONE_A as Remote Zone Areas. This relationship between the Local Shared Areas in one DeltaV
systems and the Remote Zone Areas in another DeltaV system is true in both directions for every pair of connected DeltaV systems.
Note If all you need is for data in a zone to be visible from DeltaV Operate or Control Studio in another zone you do not need to configure
Remote Zone Areas. You need only share an area with the other system.
If you delete a local area in one DeltaV system after sharing it and adding it to another DeltaV system as a Remote Zone Area, you must
manually delete the area from the Remote Zone Areas folder in the other system. For example:
The ZONE_A Remote Zone Areas folder in ZONE_B contains AREA_1.
If you then delete AREA_1 in ZONE_A's Local Shared Areas folder, AREA_1 remains in the ZONE_A folder in ZONE_B. You can delete
AREA_1 from the folder to remove it.
Redundant Inter-Zone Servers
In general, redundant Inter-Zone Servers do not complicate the installation and operation of a DeltaV Zones implementation. However, there
are a few things to be aware of if your control system includes redundant servers. A pair of redundant servers is a single logical server to the
DeltaV system. The pair of redundant servers is named and configured when you run Workstation configuration on the pair.
Running Workstation Configuration
When you run Workstation Configuration on either of the pair of redundant Inter-Zone Servers the following popup appears:
If you are running Workstation Configuration on the computer that will be the Active Inter-Zone Server, click Yes. If you are on the computer
that will be the Standby, click No.
Complete the rest of Workstation Configuration on each of the pair.
The DeltaV Status Window
On redundant Inter-Zone Servers the system tray includes the DeltaV Status icon ( ). Click this icon to open the DeltaV Status window:
The window contains the following indicators:
 Power — When illuminated, power is applied to the server.
 Error — When illuminated, an error has been detected (DeltaV services have stopped, not operational, and so on).
 Active — Illuminated when you are at the Active server. The light is solid if the server has been configured, flashing if unconfigured or
being downloaded.
 Standby — Illuminated when you are at the Standby server. The light is solid if the server has been configured, flashing if unconfigured
or being downloaded.
 Pri. CN — Flashing indicates the Primary DeltaV control network is communicating.
 Sec. CN — Flashing indicates the Secondary DeltaV control network is communicating.
Zone to Zone Data Communication
After Inter-Zone Servers and Control Networks are installed and configuration (including Remote Zone Areas) is completed in each of the
connected DeltaV systems, you can read and write information (with some restrictions) between DeltaV systems. DeltaV Zones have a
minimal impact on other DeltaV applications. The following sections explain the effect of implementing zones on other DeltaV applications.
Control Studio and DeltaV Explorer
When DeltaV Zones is enabled you can include data from other DeltaV systems as external or dynamic references if the remote areas are
shared with the local area. Inter-Zone write references are not supported. Disallowing Inter-Zone module-to-module writes ensures that those
responsible for a system's configuration oversee Inter-Zone data (and volume) coming into the system. As a result, the configuration must
include adequate logic to ensure the appropriate action when Inter-Zone reads fail. The syntax required to reference parameters depends on
whether you are referencing them from an expression or a user-defined parameter.
Example addressing in an expression:
 //<zone name>%<module>/<block>/<parameter>.<field>
 //<zone name>%<node>/<subsystem>/<parameter>.<field>
 //<zone name>%<controller>/IO1/<card>/<channel>/<parameter>.<field>
Note Expression references to device signal tags (DSTs) in other systems are not allowed. You must use the physical address (also known as
the I/O path) as shown.
For example, a reference from an expression to a module parameter in another DeltaV system looks like:
//ZONE_B%AI_MOD/AI1/OUT.CV
The .CV field is the default and you do not need to include it. When using a reference field other than the .CV field, you must include the field
name.
Example addressing in user-defined parameters of type external reference:
 <zone name>%<module>/<block>/<parameter>
 <zone name>%<node>/<subsystem>/<parameter>
 <zone name>%<controller>/IO1/<card>/<channel>/<parameter>
For example, a reference to a module parameter in another DeltaV system looks like:
ZONE_B%AI_MOD/AI1/OUT
The leading slashes (//) are not required and are stripped out if you include them. Fields are not allowed in external reference parameters. If
you include a field an error appears when you close the parameter.
If you create references to parameters in the local system that include the local zone name, the local zone name is removed when you save the
parameter or expression.
Dynamic reference parameters between DeltaV systems work as expected with two exceptions:
 You cannot include the zone prefix in a dynamic reference in the local system.
 A dynamic reference between systems stops working if you change the zone name of the system you are referencing.
Paths that do not include zone names are interpreted as referring to a parameter in the DeltaV system where the module is defined.
Browsing to data in other DeltaV systems is not supported. You must enter the path to the parameter in the other system.
DeltaV Operate
The impact of DeltaV Zones on Display configuration and management includes the following:
 Display configuration for multiple systems
 Writing parameters between DeltaV systems
 Alarm and event services and appearance in alarm banner and alarm list
 Zone name appearing in faceplates and detail displays
You can configure displays in a DeltaV Zones environment so users can access information in other DeltaV systems. This is accomplished by
including the zone name in datalink parameter paths. References to parameters in the local DeltaV system (the system in which the display is
viewed) do not need to include the zone name. Example parameter paths in displays:
 DVSYS.<zone name>%<module>/<block>/<parameter>.F_<field>
 DVSYS.<zone name>%<node>/<subsystem>/<parameter>.F_<field>
 DVSYS.<zone name>%<DSTname>/<parameter>.F_<field>
(You can also use
DVSYS.<zone name>%<controller>/IO1/<card>/<channel>/<parameter>.F_<field>)
For example, a datalink configured to access a module parameter from a DeltaV system whose zone name is ZONE_B looks like:
DVSYS.ZONE_B%AI_MOD/PID1/SP.F_CV
Dynamic references between DeltaV systems work as expected with two exceptions:
 You cannot include the zone prefix in a dynamic reference in the local system.
 A dynamic reference between systems stops working if you change the zone name of the system you are referencing.
Paths that do not include a zone name are interpreted to mean a parameter in the DeltaV system where the display is being viewed.
Tag substitutions for faceplate and detail displays cause paths to change from
DVSYS.@MOD@/<block>/<parameter>.A_<field>

to

DVSYS.<zone name>%<module>/<block>/<parameter>.A_<field>
Writing Parameters Between Zones
Writing parameters between DeltaV systems from workstations is supported. This is the method used for all operator initiated parameter
changes (changing mode or setpoint, acknowledging alarms, and so on) and other client applications (OPC data servers, Excel spreadsheets,
and so on). For a user to be able to write to a parameter in another zone from DeltaV Operate the following conditions must be met:
 The remote zone area the parameter is in must be shared with read and write access with the local area.
 The remote area must be included in the local zone's Remote Zone Areas folder for the remote zone
 The datalink in the display must include the remote zone name.
 The user attempting the write must have the correct security key for the remote zone area.
The Inter-Zone Server in the target DeltaV system blocks write access attempts of all types if the parameter resolves to be in a module or node
in a plant area that has not been configured to have read and write access from the DeltaV system attempting to write the parameter.
Writes between DeltaV systems may fail for any of several reasons. The status returned to the application attempting to write the parameter
can be useful when diagnosing the cause of the failure (communications, configuration in either DeltaV system, or other reasons).
Note SIS Secure writes between DeltaV systems are not supported. They can be configured, but fail with an error in run mode.
Considerations When Using Named Set Parameters
The behavior of reads and writes of named set parameters between DeltaV systems depends on how well the named set on the local system
matches the named set on the other system. The following table summarizes the behavior.
ZONE_A and ZONE_B Named Read and Write Behavior Between Systems
Set Configuration
Named sets are identical in both Can read and write parameters in both
systems directions without problems. The remote
named set input parameter will change and
reflect the state selected on the local display
and vise-versa.
Some named set names differ The writes between systems work on states
between systems with identical names, but fail (in either
direction) on the states that are unique in either
system.
Some named set values differ The writes between systems work on states
between systems with identical values, but fail (in either
direction) on the states that are unique in either
system.
Local system does not have named Can read named set parameters from the
set configured remote system, but cannot write to remote
system named set parameters because the
named set is not defined in the local system.
An error message appears but no other
problems result.
If your configuration requires writing named set parameters across zones, ensure that named set definitions are identical in all zones.
Modifying Pictures for use in a Zones Environment
If you are implementing zones in an existing plant so that you can communicate between DeltaV systems, you can use the DeltaV Picture
Upgrade Expert to modify displays from one DeltaV system to use in another system. The expert adds the zone name specified to all
parameter references in a display that do not already specify a zone name. Thus, displays configured for one DeltaV system can be easily
modified for use in another DeltaV system to display information from the original system. Any user-defined variables and color threshold
tables that support your displays must also be available on the local DeltaV system.
Click to Learn How
Zone Name in Faceplate
When a faceplate or detail display opens for a module in a remote zone, the zone name appears above the module or function block tag name.
Process History View and Continuous Historian
This section documents Process History View, Continuous Historian, and the viewing of historical and real-time parameter data in a DeltaV
Zones environment. For information on the Event Chronicle and collection and viewing of events refer to Inter-Zone Alarms and Events.
You cannot assign areas from remote zones to the Continuous Historian subsystem on a workstation. Each DeltaV system defines and
administers its Continuous Historian and historical data collection policy. You can create charts in Process History View that display
information from other DeltaV systems (zones). Inter-Zone Continuous Historian historical data can be managed in one of the following
ways:
 Run the Process History View application on a terminal server node in the other zone.
 Connect the Process History View application to Continuous Historian historical data servers in other zones (using plant network
connections and Continuous Historian client/server communications). These connections do not use the Inter-Zone Control Network.
 Read a limited number of parameters from the other zone into module parameters in this zone, and record historical data on these
parameters.
In Process History View you specify the default Continuous Historian historical data server. This server is used for historical data on all charts
that are configured to use the defaulthost historical data server. You can configure each chart to get its data from a different DeltaV
Continuous Historian historical data server node. Historical data servers from other zones are accessed from the Process History View node
over the plant network. The historical data servers in other zones do not appear in the server selection dialogs. You must know the name and
enter it correctly in the dialog.
The real-time history server is always the OPC data server on the workstation running Process History View.
In a DeltaV Zones environment, specify a parameter in the Parameter Reference Entry dialog in the general form:
<zone name>%<module>/<block>/<parameter>.<field>
Note To access a DST parameter you must use the hardware address (I/O path):

<zone name>%<controller>/IO1/<card>/<channel>/<parameter>.<field>
To see historical data, the parameter must be in the collection list of the Continuous Historian historical data server specified in the chart
configuration (or the default historical data server if the chart does not specify a historical data server).
To see real-time data, the parameter must exist in the zone specified.
Opening Process History View from Faceplates
In a DeltaV Zones environment only real-time data appears in charts opened from faceplates unless the default Continuous Historian historical
data server was previously set to the correct historical data server for the module being viewed because the faceplate does not know which
historian is collecting data for the module.
For example, if Process History View is opened in DeltaV Operate in ZONE_A from a faceplate that is displaying the module MOD_1in
ZONE_B, only real-time data appears on the chart unless the default historical data server was previously set to the historical data server
which is collecting the ZONE_B module MOD_1 historical data.
Diagnostics
You cannot run DeltaV Diagnostics from an Inter-Zone Server (IZS). When Diagnostics is running on another workstation type, select the
Inter-Zone Server in the hierarchy and right click to view diagnostic parameters.
From the Redundancy subsystem of an IZS you can perform a redundancy switchover.
From the Communications subsystem of an IZS you can check the Inter-Zone Control Network integrity. You can also display the
Communications Connection List for the IZS by selecting Display Com Connection List from the Communications subsystem context menu.
The Zones subsystem and the configured zones have diagnostic parameters. These diagnostic parameters are documented in What's this help.
Note DeltaV Diagnostics does not check for time differences between zones. If it is important to your implementation that the time between
different zones be synchronized you must address this in your installation. One way to do this is to include a Network Time Server in each
DeltaV system.
Zones and Security Considerations
There are three places where DeltaV Zones and security interact:
 Local Shared Areas (in remote zone)
 Remote Zone Areas (in local zone)
 User Manager
When you configure Local Shared Areas in DeltaV Explorer, you define the other DeltaV systems that have access to the areas in a system
and whether the access from each other system to each local shared area is read only or read and write. Users can see data from areas in
another DeltaV system if the other system shares those areas with read only access. Users can write data between zones if certain
requirements are met. See Writing Parameters Between Zones for more information.
In the DeltaV User Manager you specify the remote zone areas that the following apply to:
 Assigning groups or keys to users
 Assigning users, keys, and SIS keys to groups
When you make these assignments a Plant Area dialog opens. The drop down list contains all of the local areas and all of the Remote Zone
Areas in this system. The Remote Zone Areas are listed in the format Remote_Zone_Area_Name (Zone_Name).
Auto-sense Remote Zone Areas
Inside this topic
If your configuration of Shared Local Areas in all zones is complete and your Inter-Zone Control Network (IZCN) is communicating, you can
populate the Remote Zone Areas folders in your zones using the Auto-sense Remote Zone Areas feature. From a Remote Zone Area on the
current system, the auto-sense feature searches the corresponding Shared Local Areas folder on the remote zone. If any of your Shared Local
Areas or Remote Zone Areas configuration subsequently change, you can re-run the auto-sense function to update the Remote Zone Areas.
Initially Auto-sensing Remote Zone Areas
The first time you auto-sense remote zone areas all remote zones are placed in the remote zone folder. If the remote zone area name conflicts
with an existing area or remote zone area name in the current zone, it is renamed to eliminate the conflict.
To auto-sense Remote Zone Areas, from the ProfessionalPLUS workstation in each zone:
1. Select the Remote Zone Areas folder under a zone.
2. From the context menu select Auto-Sense Remote Zone Areas.
A dialog appears showing you the remote zone areas created.
If a remote zone area's duplicates an existing local or remote zone area name, a number is appended to the name to make it unique in
this DeltaV system as shown for remote area STEAM in the figure. You can rename remote zone areas.
3. Repeat steps 1 and 2 for every Remote Zone Area folder on this ProfessionalPLUS workstation.
Updating Remote Zone Areas
If you re-run the auto-sense remote zone areas feature, its response depends on changes made to your Local Shared Areas and Remote Zone
Areas configuration. This section outlines the possible changes, their effect on the auto-sense remote zone areas feature, and what actions are
required for each type of change.
The following table summarizes the actions that may occur in response to an auto-sense request and lists possible reasons for the actions.
Action Reason
All shared local areas in the remote zone
No action. are already in this zone's Remote Shared
Areas folder.
A shared local area in the remote zone
Remote Zone Area created.
has not previously been sensed.
A shared local area in the remote zone
Remote Zone Area created with a has not previously been sensed, but its
different name. name conflicts with existing local area or
remote shared area.
Name of the remote shared area has been
Remote Zone Area name
changed to match new name of shared
updated.
local area in remote zone.
Popup appears: Remote Zone
Area area_name no longer exists An area has been deleted from the Shared
as a Local Shared Area. Delete Local Areas folder in the remote zone.
existing area_name and re-scan.
Popup appears: Conflict with
existing Remote Zone Area Auto-sense cannot identify the shared
area_name. Delete existing local area in the remote zone that
area_name and Auto-Sense area_name is mapped to.
Remote Zone Areas again.

Exporting and Importing Zone Topologies
Inside this topic
If you know how you are going to share local areas from each DeltaV system with other zones but your Inter-Zone Control Network (IZCN)
is not complete, you can use the export and import of zone topologies to configure remote zone areas. This method requires that you work
from the ProfessionalPLUS workstation in each zone in succession, twice. The first time you share local areas with the other zones in the
system, then export the zone topology. The second time through you import the zone topology exported from each other zone.
Exporting Zone Topologies
From the ProfessionalPLUS workstation in each zone:
1. If you have not already defined the local areas shared with other zones, do so now.
2. Select the Inter-Zone Server.
3. From the context menu select Zones Topology Export.
4. Select a location and name for the .fhx file, then click Save.
After you complete steps 1 through 4 for each connected DeltaV system, you will have topology .fhx files exported from each of the zones in
your system.
Importing Zone Topologies
Now that you have collected an export .fhx file of each zone's Shared Local Areas, you must import these topologies in every system.
1. Select File | Import | Standard DeltaV Format.
2. Select and import a zone topology .fhx file exported from another DeltaV system.
This step adds Remote Zone Areas under the Remote Zone whose topology you imported. These Remote Zone Areas correspond to the
Local Shared Areas defined in the DeltaV system whose topology you imported.
If a remote zone area's name you are importing duplicates an existing local or remote zone area name, a number is appended to the
name to make it unique in this DeltaV system.
3. Repeat steps 1 and 2 for every other remote DeltaV system (zone).
Example
For example, If three DeltaV systems (ZONE_A, ZONE_B, and ZONE_C) are connected with an Inter-Zone Control Network and you want
alarms and events from at least some of the areas in each system to appear in other systems, or you want alarms to appear in alarm banners
and displays, the general procedure to fully configure Local Shared Areas and Remote Zone Areas in all three systems is:
1. From ZONE_A's ProfessionalPLUS workstation:
a. Create ZONE_B and ZONE_C under the Inter-Zone Server
b. Share local areas in ZONE_B and ZONE_C
c. Export the ZONE_A zone topology
2. From ZONE_B's ProfessionalPLUS workstation:
a. Create ZONE_A and ZONE_C under the Inter-Zone Server
b. Share local areas in ZONE_A and ZONE_C
c. Export the ZONE_B zone topology
3. From ZONE_C's ProfessionalPLUS workstation:
a. Create ZONE_A and ZONE_B under the Inter-Zone Server
b. Share local areas in ZONE_A and ZONE_B
c. Export the ZONE_C zone topology
4. From ZONE_A's ProfessionalPLUS workstation:
a. Import the zone topology exported from ZONE_B
b. Import the zone topology exported from ZONE_C.
5. From ZONE_B's ProfessionalPLUS workstation:
a. Import the zone topology exported from ZONE_A.
b. Import the zone topology exported from ZONE_C.
6. From ZONE_C's ProfessionalPLUS workstation:
a. Import the zone topology exported from ZONE_A
b. Import the zone topology exported from ZONE_B.
Note For a list of hardware alarm messages, including descriptions of the specific error conditions that trigger each message, refer to
Hardware Alarm Messages.
DeltaV Controller Firewall
Inside this topic
The DeltaV Controller Firewall protects DeltaV controllers from Denial of Service (DoS) attacks that originate from DeltaV workstations or
other computers on the DeltaV Control Network that are located on the unprotected side of the firewall. For information on installing the
DeltaV Controller Firewall and firewall specifications, refer to DeltaV Controller Firewall in the Installing Your DeltaV Digital Automation
System manual.
The workstation side of the firewall supports all combinations of workstations up to the standard DeltaV workstation limit. Refer to the
System Capacities table for complete information on workstation limits. The controller side of the firewall supports a maximum of 8
controllers. Firewalls can be added in parallel to share the communications load if the number of controllers requiring protection exceeds 8.
Do not add firewalls in series.
Note To maintain firewall protection for controllers, only controllers should be connected to the controller side of the firewall and only
workstations should be connected to the workstation side of the firewall.
Using a firewall will not adversely affect DeltaV communications as long as the number of controllers, simplex or redundant, on the protected
side of each firewall does not exceed 8.
Important Do not change the firewall configuration unless you are specifically instructed to do so by Emerson Process Management.
Changing the configuration may adversely impact communication with controllers.

Important Preliminary Information
The DeltaV Controller Firewall has been configured by Emerson to permit all standard DeltaV communications between controllers and
workstations. This configuration allows the firewall to support all DeltaV functions as soon as it is installed.
Included in the standard DeltaV communications are several functions that use well-known communications ports. Some of these ports are
used for non-essential communications such as diagnostic information. Users can block these ports if required to further enhance the security
of the firewall.
The firewall provides a very high level of security as shipped from Emerson Process Management. However, new threats are constantly being
developed and added security measures may be required. If your risk analysis shows that your installation might benefit from a higher
protection level, the firewall can be configured to block ICMP (Internet Control Message Protocol). Be aware that if ICMP is blocked, an
ICMP Ping command issued from the DeltaV Diagnostics application will fail. All other DeltaV commands will function properly. The
Multicast Ping command can be used as an alternative to ICMP to ping a device through the firewall . Refer to the KBA AP-0600-0127 for
information on blocking ICMP and using Multicast Ping.
Emerson highly recommends that you change the default root and management password to unique passwords. Refer to KBA AP-0600-0127
for the default password and for instructions on changing the password.
Note Occasionally it may be necessary to update the operating system software in the firewall. Updates are distributed through Emerson's
installed base management organization and are available only to users on DeltaV Foundation Support. Updates from sources other than
Emerson Process Management must not be installed.
Disclaimer- the use of this firewall product only provides an additional layer of protection to your DeltaV controller with respect to certain
types of undesired actions. This firewall represents only one portion of an overall information security system. The use of this product does
not guarantee that your controllers are secure from cyber-attacks, intrusion attempts or other undesired actions. Emerson Process
Management does not represent or warrant, and specifically disclaims any express or implied representation or warranty, that the use of this
product will prevent system disruption due to cyber attacks, intrusion attempts or other undesired actions. Users are solely and completely
responsible for their Control system security, practices and processes, and the proper configuration and use of this firewall product.

Network Topology and Switch Hops
The firewall does not impact the DeltaV system's limit of six switch hops in series. For example, four switches can be on one side of the
firewall and one switch on the other, or three switches on one side of the firewall and two switches on the other side.

Firewall Behavior as an Ethernet Switch
The firewall behaves like an Ethernet switch. That is, it learns addresses on both ports and when an Ethernet Unicast packet arrives at either
port, it forwards the Unicast packet only if the packet contains a destination address for the opposite side. The firewall rules then take over and
determine which Unicast packets should be dropped or rejected based on protocol, address, port, or packet rate. Based on the configuration
rules, the firewall forwards, drops, or rejects Multicast and Broadcast packets. The firewall performs some packet checks to detect illegal or
malformed packets and discards these packets if found. This is similar to a standard Ethernet switch that drops packets with CRC errors.

Configuring the Firewall for use with the DeltaV System
For security and performance reasons, the firewall is supplied from Emerson Process Management with a version of the firewall operating
software that is set up for compatibility with the DeltaV system. No other firewall should be used within the DeltaV Control Network.
The firewall is supplied from Emerson Process Management with a tested set of rules and thresholds that are the controlled trigger
mechanisms for allowing DeltaV packets to transverse the firewall ports. If a packet does not match any of the configured parameters it is
dropped or rejected. For example, if the rate of packets is higher than the configured thresholds, the extra packets are dropped. If the packet
protocol type, port number, or configured address does not match the incoming packet, the packet is rejected. By default, the firewall allows
all properly configured DeltaV workstations and controllers to communicate with each other regardless of whether the firewall is installed on
the Primary or Secondary DeltaV networks. This allows the firewall to be inserted into the DeltaV network without any further configuration.
A maintenance person can easily hot swap the firewall and it will operate with the DeltaV system and provide the protection described in
Level of Protection. Refer to DeltaV Controller Firewall Network Examples for examples of networks that use firewalls.
The firewall's IP address can be changed for web management. Web management is required to change the default passwords which should be
unique for each firewall. Refer to Firewall Management for more information.
Note Although not a recommended practice, it is important to know that if additional rules, which go beyond the Emerson-supplied default
rules, have been applied and the firewall is swapped out with a new firewall from the factory, the new firewall will need to be reconfigured
with the additional rules. Each firewall can be uniquely configured and the configurations can be saved to a server for later retrieval. Any
custom configuration should only increase accessibility, not further restrict it unless otherwise directed in KBA AP-0600-0127 .

Level of Protection
When used with the default configuration and installed per the network diagrams in the Installing Your DeltaV Digital Automation System
manual, the firewall protects DeltaV controllers through its configured thresholds, from some types of severe packet storms referred to as
Denial of Service Attacks. These thresholds should not be changed. Additionally, the firewall applies the configured rules of stateful
inspection to each packet where the purpose of the rules is to inspect packets one-by-one, and then to reject or drop the packets that do not
conform to a standard DeltaV address, port, or protocol.
Note The firewall does not protect the controllers from attacks from external networks. It is designed to protect the controllers from certain
kinds of broadcast attacks that may originate from a DeltaV workstation or other computer located on the "unprotected" side of the firewall on
the DeltaV Control Network. Other measures must be taken to control physical access to the DeltaV network switches and PC hardware.
Some examples are provided in Additional Security Measures.

Managing the Firewall
The firewall is configured and managed from a qualified PC called a Management station. The Management station does not run the DeltaV
software but must run a web browser such as the Internet Explorer. A Management station may already be in use on the DeltaV Control
Network for managing Ethernet switches or for other diagnostic purposes such as an SNMP Management station. To manage the firewall to
inspect firewall logs or enhance firewall rules, the firewall must be managed through a web browser. Additionally, Java software to display
the firewall's graphical images can be downloaded from the Internet at no cost for use on the Management station. Refer to the Installing Your
DeltaV Digital Automation System manual for information on the Management station including information on how to connect the
Management station to the DeltaV Control Network.

About Firewall IP Addresses
To simplify firewall management, the firewall has been configured with these defaults:
 IP address of 10.5.128.18
 Subnet mask of 255.254.0.0
 Root and management password. Refer to KBA AP-0600-0127 for the default password.
The range of supported IP addresses for the firewall is:
 Primary network - 10.5.128.16 through 10.5.128.47
 Secondary network - 10.9.128.16 through 10.9.128.47
Initially, the firewall must be connected to the DeltaV Primary network switch with a standard Ethernet cable at its default IP address. The
Management station that is used to manage the firewall can either reside on the DeltaV network connected to the Primary switch or it can be a
standalone PC on a bench setup. In either case, the Management station's Primary NIC must have its IP address set up for the Primary network
(this is usually 10.4.128.xx). The Management station can then communicate with the firewall immediately without having to change its own
NIC IP address. Refer to the Installing Your DeltaV Digital Automation System manual for information on the Management station.
Note The firewall will not respond to an ICMP Echo request (ping).

Logging On and Re-Addressing a Firewall
Once the firewall is physically connected to the DeltaV Primary network Management station or bench setup Management station with the
Primary IP address, the firewall's IP address can easily be changed by using the Management station's web browser such as the Internet
Explorer to log into the firewall. If the Primary network will have only one firewall, the address can remain at the default address once you
verify that no other device on the network has this address. To log onto the firewall from the Management station's web browser, enter
https://10.5.128.18:443 in the web browser's address bar and accept the security warnings. A view of the firewall with its configuration
options will appear.
If a firewall on the Secondary network will be managed, it must conform to Secondary IP addressing schemes. Connect the firewall that will
ultimately be on the Secondary DeltaV network to the Primary network initially because its default IP address is for the Primary network
(10.5.128.18). Then you can use the Management station to change the IP address.
Note If a firewall already exists on the Primary network at the default address and you anticipate connecting one or more additional firewalls
to the Primary network for long term use or for bench setup, you will need to first re-address the original firewall. Otherwise, the next firewall
connected to the Primary network will have the default IP address which will create an IP address conflict. Give the first firewall on the
network a unique IP address from the supported range (10.5.128.16 through 10.5.128.48 for Primary firewall addresses, and 10.9.128.16
through 10.9.128.48 for Secondary firewall addresses).
Follow these steps to re-address the firewall for the Secondary network:
1. Open the Management station's web browser such as the Internet Explorer and type https://10.5.128.18:443 in the address bar to
connect the Management station to the firewall destined for the Secondary network. The Welcome Screen appears.
2. Find the Network folder on the left side of the Welcome page, expand the folder, and select Stealth to open the Network>Stealth page.
3. In the IP Address field on the Network>Stealth page, change the address to 10.9.128.18.
4. The Netmask field should read 255.254.0.0
5. Click OK.
The Management station immediately loses connection.
6. Move the firewall's cable to the Secondary network switch (assuming the Management station already has a secondary NIC connection
to the Secondary switch).
7. Open the web browser and enter the Secondary address to re-establish communications.
8. Follow these steps to save the configuration:
 Select System Configuration - Profiles and enter a name for the profile.
 Click Save Configuration to Profile.
 Click Download next to the profile name and click Save.
 Verify the filename and location on the Management Station.
 Click Save and Close to save the profile to the desired location.
Repeat this procedure for each firewall making sure that each firewall has a unique address and the profiles are saved.
Note Never use a DeltaV workstation or controller address for a firewall address. Refer to Resetting the Firewall to the Factory Defaults for
information on resetting the firewall to the Emerson default configuration.

Remote Logging
The DeltaV Controller Firewall can direct its firewall log information to the Management station's hard drive. The logs that reside on the
firewall are overwritten when the log buffer is full. Use an external log file if you want to save long periods of log information. Standard
syslog protocol is used to log information to a remote Management station that is connected to the DeltaV network. It is necessary to run a
syslog daemon on the Management station to capture the log messages, otherwise the Management station will delete the messages. Users are
responsible for acquiring the syslog daemon and Emerson Process Management provides no support, recommendations or warranty for any
syslog daemon. The free syslog daemon for Windows is available at http://www.kiwisyslog.com/ but not tested for use with the DeltaV
system. Other syslog daemons are available and may be suitable for your use. Install and run the syslog daemon per the manufacturer's
instructions and then make the following configuration changes on the firewall:
1. Log onto the firewall using the instructions in Logging On and Readdressing a Firewall and select Services from the menu.
2. Select Remote Logging.
3. Select Yes from the drop-down list to activate remote logging, enter the IP address of the Management station, and click OK.
The log file events will be sent to the Management station's hard drive under the directory named when the syslog daemon was installed. The
log's file name is specified by the syslog daemon's manufacturer.

Resetting the Firewall to the Factory Defaults
If a configuration change has been made and the firewall no longer operates properly, for example there is no communication to the
controllers and it is suspected that the firewall is causing the problem, the firewall can be reset, temporarily bypassed with a jumper cable, or
replaced with a new firewall to resolve the problem. (Refer to Verifying the Firewall Software and Configuration for configuration
information). If removing or replacing the firewall resolves the problem, it may be necessary to reset the firewall to the Emerson factory
defaults. This is done by pressing the "R" button on the firewall's front panel in a specific sequence.
Note This procedure can be performed while the firewall is online. However, pressing the "R" button causes a reboot of the firewall and
communications will be lost on the affected DeltaV network (Primary or Secondary) for approximately 30 seconds. Resetting the firewall
while on the DeltaV network is similar to resetting a managed Ethernet switch on the network. Ensure that it is done at an appropriate
maintenance time.
The following instructions explain how to reset the firewall to the DeltaV default settings:
1. Press the "R" button for a period of 1.5 to 7.0 seconds and wait for a continuous Green Status-LED that lasts for about 30 seconds.
2. Press the "R" button slowly 6 times. After 2 seconds, the Status-LED blinks 6 times yellow and then green.
3. Press the "R" button 6 times within 60 seconds. The device then performs a restart. After 30 seconds it can be reached for network
management at: https://10.5.128.18:443.
When this procedure is complete, reinsert the firewall and determine if communications have been restored. If not, return the firewall for
replacement.
Note Performing the recovery procedure on a firewall on the Secondary network, returns the firewall to the original default Primary IP
address. The address must be changed back to a Secondary address according to the instructions provided in Logging on and Re-Addressing a
Firewall.

Using Passwords to Protect the Firewall
The firewall is protected by a default management and root password. Change these passwords immediately after installing the firewall on the
DeltaV Control Network. Refer to KBA AP-0600-0127 for the default root and management passwords.

Verifying the Firewall Software and Configuration
For troubleshooting purposes, Emerson support personnel may ask for the firewall's configuration file. To obtain this file, use the
Management station's web browser such as the Internet Explorer to log into the firewall and download the configuration text file DELTAV
DEFAULT 1-311. The following instructions explain how to save the configuration text file to a disk on the Management station:
1. Open the Management station's web browser and enter the firewall 's IP address, for example https://10.5.128.18:443.
2. The Security Alert dialog opens. Read the information on this dialog and click Yes.
3. The Connect to dialog opens. Enter admin as Username and the default password if these have not changed from the factory settings.
Otherwise, enter your Username and Password and click OK.
4. The firewall's Welcome page opens.
5. Find the System folder on the left side of the Welcome page and expand the folder.
6. Select Configuration-Profiles to open the System > Configuration - Profiles page.
7. In the Name column, find DELTAV DEFAULT 1-311 and click Download.
8. A File Download dialog opens. Read the information on this dialog and click Save.
9. The Save As dialog opens. Chose a file name and location and click Save. This is the file that can be sent to Emerson support for
analysis.
10. If the Download complete dialog opens, click Close.

Saving a Snapshot of the Firewall
If Emerson support asks for a snapshot of the entire firewall setup, you can save it to disk as well. To save a snapshot to disk:
Repeat steps 1 through 4 in Verifying the Firewall Software and Configuration.
1. Find the Support folder on the left side of the Welcome page and expand it.
2. Select Snapshot under the Support folder.
3. Click Download on the Support > Snapshot page.
4. A Download dialog opens. Click Save to save the file as snapshot[1].tar. This file can be sent to Emerson support for analysis.

Additional Security Measures
Additional security measures can be taken for managed switches and for unmanaged switches and hubs.
Managed Switches
Additional measures can be taken to further protect the DeltaV system from unauthorized access. Preventing a physical connection to unused
ports on a managed Ethernet switch is effective in protecting against unauthorized access. A combination of the following two methods is
highly recommended to prevent an unauthorized connection:
 Locking rooms or cabinets to limit access to managed switches
 Using network management to disable the unused switch ports
Note If a managed Ethernet switch has been configured beyond the Emerson factory defaults, (for example, an unused port disabled), and then
replaced for maintenance purposes with a new switch from the factory, notify the appropriate control engineer that the switch has been
replaced and may require re- configuration. When the switch is initially replaced, it will operate properly and all ports will be available for
use. However, it will not have the configuration (such as disabled ports) that engineers may expect it to have. Each switch can be uniquely
configured on an area-by-area basis, and each special configuration, appropriately named for each area, can be saved to a tftp server for later
retrieval.
Unmanaged Switches and Hubs
There is no way to disable the ports when unmanaged hubs or switches are used in conjunction with the firewall. Therefore, the only way to
prevent unauthorized physical connections to these devices is to keep them in a locked enclosure or rack room.
Developing a Security Scheme
Inside this topic
Assigning modules to areas is an important part of defining distinct security areas in the system. Use DeltaV Explorer to create and name
plant areas and DeltaV Explorer or Control Studio to assign modules to plant areas.
Use the following steps to develop a security scheme:
1. Plan the security requirements for specific parameter types and parameter fields. It is important to choose the number of distinct levels
of access control (locks) you will use in your system. Refer to the Parameter and Function Security topic to learn more about how locks
and keys work.
2. Name the locks in your security scheme and describe how the locks are to be used.
3. Create one or more groups to accommodate users with similar security requirements. Groups are not a required part of the scheme, but
they can make security easier to manage when you have multiple users.
4. Create an account for each DeltaV system user.
5. Assign your users to the groups. A user can be assigned to more than one group.
6. Grant keys to the groups to enable the groups to access and change parameters and parameter fields. You can also grant keys to
individual users to enable control not granted to the other members of the groups.

Security Recommendations Summary
The following table lists a summary of the high security recommendations for use with the DeltaV system.
DeltaV Feature Recommendations
BIOS Security Use the BIOS to create a supervisor password that
limits access to the workstations' CMOS settings.
Use the BIOS to lock the boot sequence so that the
workstation cannot be started from the floppy drive or
disk drive.
Workgroups and Domains Use a domain environment for your DeltaV system.
Logging on to the System Make sure that all users with Windows administrator
privileges log off of Windows after they have
finished using the workstation. Do not allow non-
administrative users to log on to the DeltaV system
on top of an underlying Windows Administrator
logon.
When setting up the DeltaV system, enable
Autoswitch Desktop to help protect against operators
and maintenance personnel gaining unrestricted
access to the system when a user with administrator
privileges is logged on to the underlying Windows
system
User Account Passwords Change the DeltaVAdmin password using
ServPwd.exe.
Change the Administrator password using DeltaV
User Manager.
Screen Saver Use the DeltaV screen saver to log off users
automatically after a 10-minute timeout period.
Do not use the Password protected option with the
DeltaV screen saver.
Either use the DeltaV screen saver or do not use a
screen saver at all.
Note For more information about using the DeltaV
screen saver, refer to the Recommended Maintenance
Practices topic.
DeltaV Desktop To secure your operating environment, give operators
access to the DeltaV desktop only and other users,
such as engineers, access to both the DeltaV desktop
and the Windows desktop.

Keep the default setting to restrict unauthorized users
from accessing the Windows desktop.
Autoswitch Desktop Leave Autoswitch Desktop enabled to keep
unauthorized users from accessing the Windows
desktop.
Security of the DeltaV Disable <Ctrl><Alt><Del> to provide a secure
Operate Environment operating environment.
Do not disable the pop-up menu.
Do not disable the menu bar.
Remote Systems The administration of DeltaV accounts should be
done only on the DeltaV server to avoid conflicting
settings and to keep the runtime databases in sync.
Directory and file security should be implemented on
the server (whether in a domain or workgroup) to
protect other resources on the DeltaV server (for
example, drives, directories and files). DeltaV
requires share access to the following directories:
C:\DeltaV\DVData, C:\DeltaV\DVData\Databases
and C:\DeltaV\DVData\Databases\DeltaV_System.
System Security
This book contains information on setting security in DeltaV sofware. Click on an item in the Table of Contents inside this book for more
information.

Workgroups and Domains
Inside this topic
A DeltaV system can be networked through either a workgroup or a domain. In a workgroup environment, user accounts are managed by each
individual workstation. In order to log on to a particular workstation, a user must have an account on that machine. In a domain system, user
accounts are managed by the domain server. All users with a domain account can log on to any workstation that is part of the domain without
having a user account on the individual workstations.
When you access the DeltaV User Manager from a workgroup, you only see the user accounts for the workstation from which you are
accessing the application. Each workstation can have a different set of users. When you access DeltaV User Manager from a workstation on a
domain, you only see the domain user accounts. Local user accounts for the individual workstation can be accessed and modified through the
Windows User Manager. However, for your DeltaV System, you do not need to manage local workstation accounts in a domain. All DeltaV
accounts for a domain system should be managed through the DeltaV User Manager.
For information on workgroups and domains in a remote system, refer to the Remote System Security topic.
Important Emerson Process Management recommends using a domain environment for your DeltaV system rather than a workgroup
environment. A domain environment makes setting up and managing user accounts much easier than doing so in a workgroup environment.
User accounts in a workgroup environment must be set up on each individual workstation and managed individually. In a domain
environment, all the workstations in the domain can be set up and managed through the domain server. Refer to the Domain Accounts topic
for more information.

Domain Accounts
In a domain environment, users do not need to have a local user account to log on to a particular workstation if the workstation is a part of a
domain and the user has a domain account. Domains allow users to access domain computers and resources with one account rather than
having to establish a local account on each workstation. This simplifies user account management. If necessary, a domain user can be
prevented from logging on to a specific machine. Refer to the Domain section in your Windows documentation for more information about
restricting domain accounts' access to specific workstations.
To administer domain accounts from a workstation be sure to log on to a domain administrator account. From an XP workstation, make sure
the domain is selected in the Computer/Domain field. From a Vista workstation, enter the username in the form domain_name\useername. If
you do not include the domain name as shown, and the administrator account exists on the local machine as well as the domain, you are
logged on to the local account. From a local administrator account you cannot create or modify domain user accounts.
When you access DeltaV User Manager application from a workstation in a domain system, you will see the user accounts list for the domain
only. You cannot access the local workstation user accounts from DeltaV User Manager if the workstation is in a domain. To access local
workstation user accounts, use the Windows User Manager. Refer to your Windows documentation for more information.
Note When you modify user accounts in DeltaV User Manager on a workstation in a domain system, you are modifying the domain accounts
and not the local workstation user accounts.

Workgroups (Non-Domain Accounts)
In a workgroup environment, users must have a local user account to be able to log on to the workstation. To create a local account, use
DeltaV User Manager. Once established, user accounts can be modified or deleted with DeltaV User Manager.
Note In a workgroup environment, all users must exist on every workstation in the DeltaV workgroup with the same username and password.
Refer to DeltaV User Manager help for information on replicating accounts across a workgroup.
Creating and Managing Windows Groups
Note There are two types of groups: DeltaV groups and Windows groups. This section refers to the Windows groups. For information on
DeltaV groups, refer to following topic:

The DeltaV User Manager adds users to the appropriate Windows groups automatically when you add or modify user accounts. For example,
users who are assigned a DeltaV account are added to the DeltaV group. Users assigned Windows Administrator privileges are added to the
Administrators group. You grant users these various account types in the user account properties. For more information on the types of user
accounts, refer to the DeltaV User Accounts and Groups topic.
In some circumstances, you might need to add a user to a group using Windows User Manager (which is accessible through Administrative
Tools from the Start Menu). For example, to allow users to view DeltaV Batch Historian data, they must be members of the Domain
DVBHisUser group. Note that this group is different from the Batch Historian Administrator account type, which allows user to modify Batch
Historian data. To add a user to the DVBHisUser group (which allows restricted, read-only access to DeltaV Batch Historian data), you must
use the Windows User Manager. Refer to the Windows User Manager documentation for instructions on adding users to groups.
DeltaV Security Using Organizational Units, Group Policies, and File Permissions
Inside this topic
Some of the security features of Windows Active Directory have been integrated into DeltaV systems installed in domains. In DeltaV
systems, Windows user rights and permissions are controlled by NTFS file access permissions, Organizational Units (OUs), and Group
Policies.
Note NTFS file security can be applied in both workgroup and domain systems. Organization Units and Group Policies are implemented in
domain systems only.

NTFS File Security
NTFS permissions are applied to folders and files and define the user access to these items. User access permissions include but are not
limited to, read, write, execute and delete permissions. NTFS permissions set on folders define the access permissions for the files within that
folder. DeltaV system installation sets NTFS permissions on the DeltaV file structure. These permissions deny non-DeltaV users access to
DeltaV applications and limit access to DeltaV applications to DeltaV users that have been assigned the Default User, Basic Operator or Basic
Configuration role.
Note Access control permissions for the Basic Operator and Basic Configuration groups is based on Deny permissions rather than Allow
permissions. Unlike other permissions, Deny permissions are not cumulative and override all other permissions. Be careful when assigning
users who are members of the Basic Operator or Basic Configuration groups to other groups. These groups' Deny permissions will override
the permissions in any other group that the user is assigned to.
NTFS permissions apply to both workgroup and domain systems. This topic provides more information on user roles. If your DeltaV system
is implemented in a workgroup, the following section on domain security does not apply to your system.
To learn more about NTFS permissions, refer to your Windows documentation.

User Security in Domain Systems
In a domain-based system, "Active Directory" is the Microsoft term used to describe the capabilities for providing and managing user access
from the domain controller. In domains, Active Directory provides the advanced, user access security that is available as part of the operating
system. Microsoft Active Directory has an extensive built-in structure for implementing Organizational Units and Group Policies. A Group
Policy is a set of operating system features that can be turned on and off. Examples of Group Policies are: the ability to enable or disable user
access to DVD drives or to the Start menu, to deny run access to specific applications, or to deny or allow access to modify the Internet
Explorer configuration. A Group Policy Object (GPO) is a collection of Group Policies. Active Directory allows Group Policies to be applied
to Organization Units only; not to users or groups. Organizational Units are containers for GPOs and are configured to be logical
representations of an organization. They can be configured in a hierarchy of levels to divide users and computers into manageable segments
that represent your organization.
The DeltaV software has preconfigured OUs and GPOs so that you can easily use the user access control features of Active Directory. It is not
necessary for you to completely understand the user access control features of Active Directory; however, if you want to learn more about
Organizational Units, NTFS, and Group Policy Objects, refer to your Windows documentation.

DeltaV Organizational Units
The DeltaV system makes use of three OUs: DeltaV Users, DeltaV Workstations, and DeltaV Locked-down Workstations. The OUs are
created on the domain controller during workstation configuration and are visible in the Active Directory Users and Computers utility.
Active Directory Users and Computers Utility on the Domain Controller

DeltaV Users OU
The DeltaV Users OU contains all the DeltaV user accounts. DeltaV service accounts such as DeltaVAdmin are not user accounts and are not
contained within the DeltaV Users OU. As new domain users are created in the DeltaV User Manager, they are moved into the DeltaV Users
OU on the domain controller. The user administrator is not moved to the DeltaV Users OU.
The DeltaV system makes use of two Windows users groups: DeltaV Basic Operator and DeltaV Basic Configuration. A GPO is assigned to
each of these groups: DeltaV Basic Operator and DeltaV Basic Configuration and are linked to the DeltaV Users OU. Although most DeltaV
users reside in the DeltaV Users OU, only users that have been assigned the Basic Operator or Basic Configuration role will have the
corresponding Group Policies applied to them.
The DeltaV Default role is also linked to the DeltaV Users OU but no GPO is assigned to users in the Default role. These users have all of the
operating system access permissions that they had in previous versions of the DeltaV software.
For the settings in the DeltaV Basic Operator and DeltaV Basic Configuration group policies, refer to the Emerson Process Management
Knowledge Base for articles on hardened workstations and GPO settings.
Note DeltaV user accounts reside in the DeltaV Users OU in the Active Directory Users and Computers utility, not in the Users folder.

DeltaV Workstations OU
In addition to setting individual user access, it is also possible to set access on a computer-by-computer basis with machine GPOs. When
applied to a computer, the access restrictions in a machine GPO apply to users of that computer regardless of their individual user access
permissions. For example, if a machine GPO denies access to the DVD drive, then access is denied to all users regardless of their user access
permissions for this capability. In this case, users would need local user access to the computer to access the DVD drive.
With the exception of workstations configured as backup domain controllers, the DeltaV Workstations OU contains all domain workstations
such as Operator Stations and Application Stations. During installation and workstation configuration (where the computer joins a domain),
the computer accounts are moved to the DeltaV Workstations OU.
By default, no group policies are applied to the DeltaV Workstations OU. This OU has been created as a convenience for users who may want
to create and deploy machine GPOs for their DeltaV system. If you do not want to use machine GPOs, you can ignore this feature and DeltaV
workstations will continue to operate as usual. If you do create a GPO to apply to this OU, it is your responsibility to fully test the policies and
their impact on the workstations and control network before implementing them. Use only Microsoft tools such as the Microsoft Group Policy
Editor to create a GPO. Emerson Process Management strongly suggests that if you want to use machine GPOs in a DeltaV system, you
contact Emerson Process Management SureService to assist in this effort.
Note DeltaV workstations reside in the DeltaV Workstations OU in the Active Directory Users and Computers utility, not in the Computers
folder.

DeltaV Locked-down Workstations OU
You may find it desirable to deploy a machine GPO on certain Operator Stations. The DeltaV Locked-down Workstation OU was created to
aid in this effort. The DeltaV Locked-down Workstations OU does not contain any workstations by default but has a default GPO applied to it
that was developed by Emerson Process Management. You can use Windows tools to move your DeltaV workstations, such as Operator
Stations on the plant floor, into this OU. Workstations moved into the DeltaV Locked-down Workstation OU are subject to the settings in the
DeltaV Locked-down Workstations group policy.
Note Due to the complexity of local and wide area plant networks and IT departments' requirements for security and access privileges, it is not
possible to define a set of default Group Policy settings that meet all needs for locking down workstations. The DeltaV Locked-down
Workstations Group Policy contains an example set of restrictions and allowances. These settings are not considered to be the correct settings
for every DeltaV installation. Depending upon your plant or corporate policies, these settings may need to be modified (even to make basic
DeltaV functions work as expected). Contact Emerson Process Management's SureService group for consultation services on your Group
Policy settings.
For the settings in the DeltaV Locked-down Workstations group policy, refer to the Emerson Process Management Knowledge Base for
articles on hardened workstations and GPO settings.

Security Settings and User Roles
The DeltaV system uses user roles to provide different levels of access to the system. Users are assigned roles in the DeltaV User Manager
application. There are three user roles: Default, Basic Operator, and Basic Configuration. In a workgroup environment, user roles use NTFS
access permissions to control access to DeltaV applications and to some Windows applications. In a domain environment, user roles use
NTFS access permissions plus GPO settings to further restrict the Windows features from users.
Users cannot be assigned GPOs in workgroups. In workgroups, all security settings must be made and managed at each local computer. If you
want to use GPOs and centrally manage user access, the DeltaV system must be installed in a domain.

NTFS Settings Applied to User Roles
This section list the permissions granted to each user role.

Default Role
The Default role provides operating system access to Windows applications that do not require administrator privileges. In general, it provides
the operating system access generally granted to the Windows user group "Everyone". The Default role provides access to all DeltaV
applications which allows users in this role to launch most DeltaV applications. The Default role provides all of the same user access
privileges available in previous versions of the DeltaV software. If you do not want different levels of operating system access for your
DeltaV users, assign the Default role to all users.
DeltaV applications also have internal security that restricts what the user can do with the application. For some applications such as DeltaV
User Manager, non-Administrators are not allowed access to the application at all. This is application security and not operating system
security. Application security is beyond the scope of this document but is included here to ensure that users understand that permission to
launch an application does not necessarily grant full access to the application's functionality. Application access is granted using DeltaV locks
and keys. Refer to Parameter, Field, and Function Security for more information on locks and keys.

Basic Configuration Role
The Basic Configuration role is intended to provide a level of operating system access between the unrestricted Default role and the more
restricted Basic Configuration role. The Basic Configuration role has the same operating system permissions as the Default Role; however,
the user permissions can be modified for different levels of operating system access.
The Basic Configuration role is intended to give administrators the ability to custom configure a set of user privileges that are more restrictive
than the Default role but not as restrictive as the Basic Operator role. As an example, administrators might modify the user permissions for the
Basic Configuration role to restrict users from performing some actions in the operating system or to block access to DeltaV applications for
which they do not need access. Users who are responsible only for creating DeltaV configurations might be assigned to this role. Typically,
these users do not have operational responsibilities beyond testing configurations. Similarly, users assigned to this role might not require
administrative access to the operating system.
Users in the Basic Configuration role have access to the Windows desktop and can run most applications. The Basic Configuration GPO can
be used to deny access to operating system functions such as Windows Media Player or Windows Movie Maker that would never be used on
any DeltaV workstation regardless of the user's responsibilities.

Basic Operator Role
The Basic Operator role has Read and Execute permissions on DeltaV files. Only operators should be assigned to this role. This role has very
restricted access to DeltaV files and the GPO settings deny access to most operating system features. If a user is somehow able to bypass the
DeltaV FlexLock Application, the GPO settings will deny them easy access to programs and operating system capabilities. Users assigned to
the Basic Operator role are restricted from any of the administrator account types (DeltaV Administrator, DeltaV Batch Historian
Administrator, DeltaV Event Chronicle Administrator) and from Windows Desktop Access.
Users assigned to the Basic Operator role can create, change, and delete in the following DVData folders:
 Charts
 Batch
 InSight
 Neural
 Graphics-iFix
 Graphics-iFix\Pic\frsFactoryData
 RemoteSystems
Users assigned to the Basic Operator role can create and change in the following DVData folders:
 Graphics-iFix\Local
 Graphics-iFix\PDB
Users assigned to the Basic Operator role can only run the following DeltaV applications:
 Batch History View
 Batch Operator Interface
 Control Studio
 DeltaV Explorer
 DeltaV Logger
 DeltaV Logon
 DeltaV Operator Run mode
 AMSMenu
 Diagnostics
 MPC Operate
 MPC Operate Pro
 MPC Diagnostics
 Process History View
 Books Online
 InSight
 Neural
 FlexLock
 Condition Summary
Users assigned to the Basic Operator role are restricted from using the following Windows applications:
 Notepad
 MSPaint
 Calculator
 Windows Media Player
 Windows Movie Maker

GPO Settings Applied to User Roles
In addition to NTFS security settings, access to Windows features is further controlled by Group Policies in domain systems. The DeltaV
Users OU has two GPOs that apply to it: DeltaV Basic Operator GPO and DeltaV Basic Configuration GPO. When a domain user is assigned
a role in the DeltaV User Manager, that role determines which GPO applies to the user. For example, if the user is assigned the Basic Operator
role, the group policies in the Basic Operator GPO will be applied to the user. If the user is assigned the Basic Configuration role, the group
policies in the Basic Configuration GPO are applied to the user.
For the policy settings that are enabled for the DeltaV system, refer to the Emerson Process Management Knowledge Base for articles on
hardened workstations and GPO settings. It is highly recommended that you not modify the DeltaV GPOs. When the DeltaV system is re-
installed, the GPOs are restored to the factory settings. However when the DeltaV Upgrade Wizard is used, DeltaV installation leaves the
DeltaV GPOs intact and does not restore them to the factory settings. If you must modify the GPOs, use the DeltaV GPO as a template and
create your own GPO from it; do not modify the DeltaV GPO directly. Use only Microsoft tools such as the Microsoft Group Policy Editor to
modify GPO settings.

Preventing Users from Running Unauthorized Software
In domain environments, Microsoft's software restriction policies can be used to prevent certain software programs from running under any
circumstances. In domains, software restriction policies are created for a particular GPO. The policies are enforced against users associated
with that GPO. A software restriction policy consists of a default rule about whether programs are allowed to run and exceptions to that rule.
The default rule can be set to Unrestricted or Disallowed; that is run or do not run. Setting the default rule to Unrestricted allows an
administrator to define exceptions; for example, the set of programs that are not allowed to run. A more secure approach is to set the default
rule to Disallowed and specify only the programs that are known and trusted to run.
For complete information on software restriction policies, refer to the Microsoft TechNet article at http://technet.microsoft.com/en-
us/library/bb457006.aspx. If this link is not working, use your internet browser to search for information from Microsoft on how to implement
software restriction policies.
The Microsoft Management Console is used to create software restriction policies. This utility can be downloaded from
http://www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887&displaylang=en.
After downloading the Microsoft Management Console, follow these steps to access it and use its online help to create software restriction
policies:
1. Log onto the domain controller with an Administrator account.
2. Click Start | Run, type gpmc.msc in the Run dialog, and click OK. The Group Policy Management Console opens.
3. Click Help | Help Topics.
4. In the left pane of the Microsoft Management Console online help, find Group Policy Object Editor Extensions under Concepts and
select the link for the Security settings topics.
5. Use the help topics under Software restriction policies for information on how to create policies.
Environmental Security Protection for Operators
Environmental security protection is used to create a secure environment in DeltaV Operate that prevents the operator from navigating to
unauthorized applications or from performing unauthorized actions.
Securing the DeltaV Operate Environment
You can use the Environment Protection dialog box in the Configure mode of DeltaV Operate to secure the environment. (You must have
Configure privileges in order to access Configure mode.) All of your pictures share the same environment settings.
Protected actions in DeltaV Operate are as follows:
 starting other tasks
 opening unauthorized pictures
 switching to unauthorized tasks
 closing the current picture
 exiting DeltaV Operate
 restarting the computer using <Ctrl> <Alt> <Delete>
Note After installing the DeltaV software, restart the operating system before attempting to use environment protection for the first time.
To secure the DeltaV Operate environment:
1. Click Workspace | User Preferences. The User Preferences dialog box opens. Click the Environment Protection tab.
Environmental Protection Tab for DeltaV Operate
The following table describes the behavior of the Environment Protection settings.
Setting Description Applications / Desktops

Affected
Disable title bar and menu Does not display the title Disabled for DeltaV Operate
bar. bar or the menu bar. only on both the Windows
Removes the minimize, and DeltaV desktops.
maximize, and exit
buttons from the title
bar.
Disable menu bar. Does not display the Disabled for the operator's
menu bar. interface only on both the
Windows and DeltaV
desktops.
Disable the Workspace pull- Disables all entries in Disabled for DeltaV Operate
down menu. the Workspace menu only on both the Windows
selection in Run mode. and DeltaV desktops.
Disable <Ctrl><Alt><Del>. <Ctrl><Alt><Del> is Disabled on both the
ignored. Windows and DeltaV
desktops as long as DeltaV
Operate is running on either
desktop.
Disable task switching. Alt + Tab is ignored. Alt + Tab is disabled on
Removes minimize, both the Windows and
maximize, and exit DeltaV desktops as long as
buttons from the title DeltaV Operate is running
bar. on either desktop.

Title bar is only affected on
DeltaV Operate.
Disable VBE access. Disables access to the Disabled for the DeltaV
Visual Basic Editor in Operate only on both the
Run mode. Windows and DeltaV
desktops.
Disable Workspace file Disables the menu Disabled for DeltaV Operate
menu accelerators. accelerators that exists only on both the Windows
for the entries under the and DeltaV desktops.
File menu.
Disable Open accelerator. Disable the Ctrl+O Disabled for DeltaV Operate
accelerator. only on both the Windows
and DeltaV desktops.
Disable Print accelerator. Disable the Ctrl+P Disabled for DeltaV Operate
accelerator. only on both the Windows
and DeltaV desktops.
2. Establish the settings in the Environment Protection dialog box. You can disable the menu bar and the title bar based on your own
preferences.
Task switching does not need to be disabled because operators can only switch between DeltaV applications made available from
FlexLock, provided that Autoswitch Desktop is enabled. (Refer to the Enabling or Disabling Automatic Switching topic for more
information.). However, you might want to disable task switching if you want to display the title bar and menu bar in DeltaV Operate
without allowing operators to have access to the minimize, maximize, and exit buttons.
The following settings are recommended:
 Disable <Ctrl><Alt><Del> to provide a secure operating environment. The only resulting loss of functionality from the
engineering environment will be the ability to change passwords or lock the workstation while DeltaV Operate is running. If you
do not select this setting, an operator can log off, shut down, or lock the workstation from the Windows Security dialog. Invoking
the task manager from the Windows Security dialog launches the task manager on the Windows desktop rather than the DeltaV
desktop. Therefore, an operator is still unable to switch to or launch another application.
 Do not enable the menu bar. Emerson Process Management strongly recommends that you not change this setting.
Note While running DeltaV Operate, operators can access other DeltaV system software applications through the buttons in the
Toolbar window. If the currently logged-in operator does not have the privileges to run the application or to perform the function
that is accessed by the button, the button is enabled but the system does not allow the operation.
DeltaV User Manager and DeltaV Security
Inside this topic
Use the DeltaV User Manager to create and manage DeltaV user accounts without accessing the Windows User Manager application. You can
specify whether users are Windows users, DeltaV system users, or both.
Both DeltaV security and Windows security are based on the concept of user accounts and groups. A user account consists of unique
credentials (logon name and password) that allow the user to access resources. A group is an account that contains user accounts, called
members. Permissions and access rights are granted to groups and apply to all members of the group. A group is essentially a classification of
users, and it offers a convenient way to set access permissions for a collection of users of the same type. A user can be assigned to more than
one group.
The DeltaV User Manager
The User Manager window gives you three views: Users, Locks, and Groups. If DeltaV SIS is enabled, a fourth view, SIS Locks, is added.
You can open, close, and resize each pane. These views are available under the View menu.
User Manager Window

Built-in Windows Groups
This topic is concerned only with the default groups created by DeltaV software. It is possible to create additional Windows groups, but this is
not necessary and not recommended for use with DeltaV software. When you select File | New | User the New User dialog opens.
DeltaV User Manager New User dialog
By default, the check boxes Operating System (Windows) Account and DeltaV Database Account are selected.
Once a user account exists, you can modify the account type in DeltaV User Manager by double-clicking the account name to access the user
account properties.
Note To ensure proper tracking of security events, the software creates a record iin the Windows Events Viewer's Application log when a user
is added or deleted with the DeltaV User Manager application.
You do not assign DeltaV users to Windows groups directly. When you create a user in the DeltaV User Manager the selections you make for
each user determine the Windows groups to which the user is assigned. The following tables show how the New User dialog selections put
users in Windows groups that standard DeltaV software created during DeltaV software installation.
Note The DeltaV installation creates other groups to support DeltaV software that can be purchased and installed separately.
Adds user to this Adds user to this
New User dialog check Windows group Windows group
These users...
box... in a workgroup in a Domain
environment environment
Operating System
Can log on to Windows and the DeltaV
(Windows) Account
DeltaV Domain DeltaV system. DeltaV privileges are controlled by
and DeltaV Database
DeltaV locks.
Account
The following Windows account sub-type check boxes each assign a user to an additional
Windows group
Can perform privileged DeltaV operations
and have access to the Windows Desktop.
Domain DeltaV
DeltaV Administrator DeltaV Admins They are also members of the Windows
Admins
Administrators group and, therefore, are
allowed access to Windows System utilities.
DeltaV Batch
Domain Have unrestricted access to DeltaV Batch
Historian DVBHisAdmin
DVBHisAdmin Historian data.
Administrator
DeltaV Batch Domain Have restricted, read-only access to DeltaV
DVBHisUser
Historian User DVBHisUser Batch Historian data.
DeltaV Event
Domain Have access to the Event Chronicle
Chronicle DVECAdmin
DVECAdmin Administration tool.
Administrator
Windows Desktop Domain DeltaV
DeltaV Access Have access to the Windows Desktop.
Access Ax S
Windows Are allowed access to Windows System
Administrators Domain Admins
Administrator utilities.
Allow Terminal Remote Desktop Domain DeltaV
Are allowed to log in remotely.
Server Logon Users TSUsers
Are given a DeltaV account allowing the user
DeltaV Database
DeltaV Domain Deltav to log on to the DeltaV system. DeltaV
Account
privileges are assigned with DeltaV Locks.
DeltaV User Roles
In addition to the check boxes, the New User dialog has a Role drop-down field that contains two options. The following table lists the options
and the Windows group associated with them.
Adds user to this Adds user to this
Windows group Windows group
Selecting this Role... These users...
in a workgroup in a Domain
environment environment
Have restricted access to DeltaV
applications.
In workgroup settings, access to Windows
features is controlled by New Technology File
System (NTFS) security settings.
Domain DeltaV
DeltaV Basic
Basic Configuration Basic
Configuration In domain systems, access to Windows
Configuration
features for users in this group is controlled by
NTFS security settings and further limited by
the DeltaV Basic Configuration Group Policy
Object (GPO). Refer to DeltaV Security Using
Organizational Units, Group Policies, and File
Permissions.
Have restricted access to DeltaV
applications.
In workgroup settings, access to Windows
features is controlled by NTFS security
settings.
DeltaV Basic Domain DeltaV
Basic Operator
Operator Basic Operator In domain systems, access to Windows
features for users in this group is controlled by
NTFS security settings and further limited by
the DeltaV Basic Operator Group Policy
Object (GPO). Refer to DeltaV Security Using
Organizational Units, Group Policies, and File
Permissions.
Note Be aware that NTFS permissions and Group Policies can disallow privileges granted through DeltaV keys. For example, if a user is
granted the Can Configure or Can Download key but is prevented from accessing the DeltaV Explorer because of NTFS permissions
associated with that user's role, downloading and configuring privileges are disallowed.
Built-in DeltaV Groups
DeltaV groups are similar in function to Windows groups. They allow you to define a set of keys to DeltaV locks that can be easily assigned
to a number of users. For example, you can define a group that has the keys for several locks, then make your users members of that group
rather than assigning several locks to each user. For more information about DeltaV Locks, refer to the DeltaV Locks topic. The DeltaV
groups created during installation are:
 Maintenance
 Operate
 SIS Engineering (supports DeltaV SIS)
 SIS Operate (supports DeltaV SIS)
 SIS Supervise (supports DeltaV SIS)
 Supervise
 Tune
Each of these has default users assigned, as well as default keys. From the DeltaV User Manager you can see the default members of each
group and the default keys assigned to each group.
You can create your own groups, if necessary. For more information on creating and managing DeltaV groups, refer to the following help
topic:

DeltaV User Accounts
There are two types of user accounts in the DeltaV system: custom and built-in. You can create custom accounts to allow access to the system
and its resources. The system creates built-in accounts automatically.
The Administrator user account, a Windows built-in account, is a member of the Administrators group and, therefore, can access and modify
all resources. The Administrator account is used to manage the overall system and/or domain configuration.
Important The DeltaV service accounts, DeltaVAdmin and DVBatchAdmin, are listed in the Windows User Manager application but do not
appear in the DeltaV User Manager application. These accounts are used to manage DeltaV application services and internal DeltaV
functions. These accounts should not be modified or deleted.
The following table shows the default user accounts created by DeltaV software during installation. The table also shows the default Windows
groups and DeltaV groups each user is assigned to. The Windows Administrator account is included because its properties are modified when
DeltaV is installed.
Important The DeltaV installation creates other accounts not shown here that support other DeltaV software that can be purchased and
installed separately. These accounts are used to manage DeltaV application services and internal functions and should not be modified or
removed.
User Name Windows Groups DeltaV Groups

Administrators
Administrator DeltaV ---
DeltaV Admins
Configure DeltaV Supervise
Maintainer DeltaV Maintenance
Operator DeltaV Operate
SIS_Configure DeltaV SIS Engineering
SOFTPHASEUSER
DeltaV ---
(supports Soft Phases)
Supervisor DeltaV Supervise
Note that although the Administrator account is not assigned to any DeltaV groups, it is assigned all non-SIS DeltaV keys by default. No
DeltaV SIS keys and SIS groups are assigned to the Administrator account by default. However while no SIS keys are assigned to the DeltaV
Administrator account by default, the DeltaV Administrator can assign SIS keys and SIS groups to any user account including the DeltaV
Administrator account. Refer to the topic DeltaV User Manager and SIS Security for more information on SIS key assignments.
Note There can be additional user accounts and groups on your system that are created by Windows. To learn more about them, refer to your
Windows documentation.
For information on creating your own user accounts, refer to the following DeltaV User Manager help topic:

Managing DeltaV User Accounts
User accounts are managed through DeltaV User Manager. Users can be given Windows Operating System accounts, DeltaV accounts, or
both. In a workgroup environment, users must have both a Windows and a DeltaV account on each workstation where they log on. In a
domain environment, users must have a domain account (a Windows account on the domain server) but do not need a Windows account on
each of the individual workstations. To prevent a user from logging on to a particular workstation in a workgroup environment, do not give
that user a Windows account on that workstation. You can also prevent a user from logging on to a particular workstation in a domain. Refer
to the Domain section in your Windows documentation for information about restricting domain accounts from access to specific
workstations.
User accounts for domains and workgroups are set up in the same way. The main distinction is that in a workgroup, you access the user
accounts for the local workstation on which you are running DeltaV User Manager. In a domain system, whether you are running DeltaV User
Manager from the domain server or from a workstation in the domain, you are accessing the domain accounts.
Be aware that many of the default users are required for the DeltaV services (such as the DeltaV database service). Changes to these users (for
example, DeltaVAdmin user) affect how and if your DeltaV system continues to run as expected.
Note You must have administrative privileges (that is, be a member of the administrators group) to use DeltaV User Manager.
User Account Passwords
DeltaV user account passwords must comply with the operating system complexity settings. For more information on complexity
configuration, open Microsoft Help and Support Center and search for "complexity requirements" (in double quotes).
If the same username is going to be used on different workstations in a DeltaV workgroup environment, the password for that particular
username must be the same on all workstations. For a domain system, the username and password for all domain users reside on the domain
server rather than on each workstation. Each user has only one username and password that apply to all the workstations in the domain.
The DeltaVAdmin password is pre-assigned in your DeltaV system. This password should be changed after you receive your DeltaV System.
To change the DeltaVAdmin account password, you must use ServPwd.exe.
Note Never change the DeltaVAdmin account password from Windows User Manager. There is a special DeltaV utility under the directory
DeltaV\bin titled ServPwd.exe for changing this password (and the SoftPhaseUser account password). Several applications that run as
Windows services must be reregistered as Windows Services when the password on this account is changed. The password on this account is
stored only in SAM (the Windows Security Account Manager database). Therefore, you must use this special DeltaV utility to reregister
DeltaV Services.
Important Change the DeltaVAdmin password using ServPwd.exe.

Change the Administrator password using DeltaV User Manager.

Managing Computers and Domains
It is possible to create domain-specific accounts in which users have fully qualified names such as DomainName\BSmith. Including the
domain name with the user name ensures that the DeltaV user is the same user as the Windows user and avoids the use of passthrough
authentication from other domains. A drop down list for assigning users to computers and domains is on the General tab on the New User
dialog in the DeltaV User Manager application. The Manage Computers/Domains dialog, also accessed from the General tab, allows you to
add and delete computers and domains to the DeltaV system.
Note It is possible to configure local workstations in a domain environment and remote workstations in a workgroup environment. Be aware
that if you create local, domain-specific accounts with fully qualified names, remote users in a workgroup environment will be unable to log
onto the remote workstation's operating system because their user IDs are not domain-specific.

Audit Trail for User Manager
User security operations performed in the DeltaV User Manager are tracked by Version Control Audit Trail, for DeltaV database accounts
only. If the account is both a DeltaV database account and an operating system account, only the changes made through DeltaV User
Manager are tracked.
The audit trail tracks creation of new DeltaV database accounts and account modifications and deletions by storing the date, time, user name,
and description of the event in the Version Control Audit Trail database. Version Control Recover, Purge, and Show History commands can
be accessed from the User Manager. Version Control must be enabled for User Manager changes to be tracked. Refer to Version Control for
information on enabling Version Control and for other important information on using Version Control. Use the User Manager online help for
information on adding, deleting, and modifying accounts. The Version Control Check Out and Check In preferences do not apply to User
Manager. User security items are automatically checked out and checked in.
When Version Control is enabled and a change is made in DeltaV User Manager, the Version Control messages dialog provides a log of
Version Control activities. In some DeltaV applications such as the Explorer and Control Studio, check marks indicate that an item has been
checked out of Version Control. There are no indications of Version Control activity other than the messages dialog in the DeltaV User
Manager application.
Version Control Check In Message
In the example shown above, a new user account (Jane Doe) is added in DeltaV User Manager.
As shown in the following image, when a modification is made to an existing account, the messages dialog indicates that the account data is
checked out of Version Control and then checked in when the changes are made. Refer to Checking Items in and Out for more information on
these Version Control functions.
Version Control Check In Check Out Message
Similar Version Control messages are logged for all User Manager actions when Version Control is enabled.
Recovering Deleted Security Items, Purging Items, and Showing History
The Version Control Show History and Purge and Recover commands can be accessed from the DeltaV User Manager's Tools menu. With
Version Control enabled, deleted User Manager items can be recovered from the Version Control database or permanently removed from the
Version Control database. Refer to Recover/Purge for more information on the Version Control Recover and Purge commands. Similarly, you
can access a user account's version control history from the DeltaV User Manager. Select the user name and click Tools | Version Control |
Show History. Use the What's This help for information on the buttons on the Version Control History dialog box.
You can delete a user's DeltaV database account without deleting the operating system account. If this has been done and you recover that
account, the DeltaV Database Account box on the user account's properties (General tab) is selected. If both the DeltaV database account and
the operating system account are deleted and then recovered, the system prompts you for a password (that is compliant with the Windows
password complexity requirements) to be allowed to restore that account.
The following table lists what items Version Control restores when a user or a group is rolled back.
Restored Not Restored
User Groups the user is a member of Description
Keys assigned to the user The operating system account type
DeltaV Administrator
SIS keys assigned to the user DeltaV Batch Historian
Administrator
DeltaV Batch Historian User
DeltaV Event Chronicle
Administrator
Windows Desktop Access
Windows Administrator
Allow Terminal Server Logon
Logon Script

Account and Password Status
Disable Account
Password Must Change at Next
Logon
User Can’t Change Password
Password Never Expires

Home Directory
Group Description Members of the group
Keys assigned to the group SIS keys

Generating Reports from User Manager
From the DeltaV User Manager's Reports menu, you can generate an accounts summary report that includes information on all user accounts
and a rights and privileges report that includes a listing of the rights and privileges granted to selected users. The reports can be printed.
The DeltaV Desktop
The DeltaV system offers dual desktops to provide both a secure operating environment and an open engineering environment. The two
desktops are the Windows desktop and the DeltaV desktop. The Windows desktop allows access to DeltaV applications and Windows
resources, including other Windows programs that might be on the system. The DeltaV desktop limits the user to the DeltaV Operate
application and to those applications available to the user through DeltaV Operate.
Access to the Windows desktop is determined by the current user's privileges, which are based on group membership. A user with Windows
administrative, DeltaV administrative, or DeltaV access privileges has access to both the DeltaV desktop and the Windows desktop. A user
who is not a member of the Administrators group, the DeltaV Admins Group, or the DeltaV Access group cannot access the Windows
desktop.
Initial DeltaV configuration defaults to the DeltaV desktop. Users with the proper privileges can switch to the Windows desktop.
Unprivileged users are limited to the DeltaV desktop. This default setting can be changed so that all users (regardless of their privileges) go
directly to the Windows desktop upon logging on to the system. Refer to the Enabling or Disabling Automatic Switching topic for more
information.
Note To secure your operating environment, consider giving operators access only to the DeltaV desktop and other users, such as engineers,
access to both the DeltaV desktop and the Windows desktop.
Note Keep the default setting to restrict unauthorized users from accessing the Windows desktop.
For more information, refer to the DeltaV FlexLock topic.
Internet Explorer Settings for General DeltaV Software Use
The DeltaV install process installs Microsoft Internet Explorer on all workstations. The first time you use Internet Explorer, the software
enables you to choose settings. Select the following settings during Internet Explorer setup for general use. Certain DeltaV web-based
applications may require additional settings. Those settings are specified in the documentation for those applications.
Setting Recommended Selection
Internet search provider Select Keep my current default settings.
Phishing Filter Keep the default setting (the check box is cleared
to disable the setting).
Activate ClearType Keep the default setting (the check box is selected
to enable the setting).
Language and Region Click English (for English-language versions of
DeltaV software).
Join the Customer Experience Improvement Keep the default setting (the check box is cleared
Program to disable the setting).
Add-on support (you may be prompted to DeltaV does not support Internet Explorer Add-
allow support for various Add-ons). ons.
After you save these settings, make sure the Disable Phishing Filter is selected. This options is under Tools | Internet Options | Advanced.
Smart Cards
The DeltaV system supports the use of smart cards for logging on to DeltaV workstations. Standard DeltaV Workstations and Terminal Server
sessions support smart cards. Remote Desktop sessions do not support smart cards. The use of smart cards in the DeltaV system requires the
following:
 A Domain-based environment.
 A smart card for each DeltaV user who requires access to the workstation.
 A smart card reader installed on the workstation. The smart card reader must support the Microsoft CryptoAPI (for example, smart card
readers from Athena).
 A Windows 2003 Active Directory installation of DeltaV Software.
 A Windows Server 2003 on the DeltaV control network with certification authority deployed.
The DeltaV Administrator has the option of requiring the use of smart card, or making it optional on a per workstation basis. The DeltaV
system administrator is responsible for installing the smart card software and hardware on each workstation that requires it. Installation
includes connecting the smart card reader and installing the smart card software. The DeltaV administrator is also responsible for setting up
certificates for each card on the server machine where certification authority is deployed.
Note After enrolling the certificate for a smart card, you typically must pull the card and reinsert it before you can use it to log on.
To make sure a smart card is working correctly, use it first to log on to Windows before logging on to the DeltaV system. The card must be
able to log a user on to Windows in order to ensure that it can be used to log a user on to the DeltaV system.
Leave the card in the reader when using applications that interface with the DeltaV database (for example, Control Studio, DeltaV Explorer
and Recipe Studio). If you remove the card from the reader you lose user privileges for certain functions on these applications.

Keeping Security Current
User security changes do not take effect until the user logs off and then logs on again. Any time you make a change to user security, the user
must log off and then log on again.
Note that the system can also make changes to security because of a configuration change. For example, if you create a new plant area, the
system grants access to the new area to users with a site-wide security key. However, these access changes do not take effect until the
following events occur:
 The workstations receive the user security information and area name through a setup data download.
 The users log off and then log on again.
Whenever plant area or user security configuration changes are made, make sure to download workstations with setup data so that they have
the most current configuration and security information.
Workstations
This book contains information on using workstations in DeltaV sofware. Click on an item in the Table of Contents inside this book for more
information.

Workstation Software Licenses
You determine the functionality and size of each workstation with software licenses. The DeltaV Experience license and the workstation
license suites enable the use of specific functions and applications as defined in the product data sheets. The following briefly describes the
workstation licenses. Refer to the product data sheets and the DeltaV System Planning Guide for detailed information on these licenses.
The DeltaV Experience License
The DeltaV Experience license includes a broad set of operating, diagnostic and engineering tools. This license enables you to configure,
download, and control as many as 100 DSTs. These DSTs can include any combination of the following types: AI, AO, DI, DO, Serial,
Profibus, DeviceNet, HART, Foundation Fieldbus (provided the AMS Device Manager is installed).
See the section below on add-on and scale-up licenses for information on expanding the DST capacity.
ProfessionalPLUS Workstation
The ProfessionalPLUS workstation license suite supports the global database for a DeltaV system. You need one ProfessionalPLUS
workstation per system. A ProfessionalPLUS workstation has a complete set of operating, diagnostic and engineering tools. PCs defined as
ProfessionalPLUS workstation nodes during workstation configuration can accept the ProfessionalPLUS license suite.
Professional Station
The Professional Station license suite provides engineering workstation capabilities to Operator Station nodes. This suite is for systems that
require more than one engineering seat. It has a complete set of operating, diagnostic and engineering tools without the global database. PCs
defined as Operator Station nodes during workstation configuration can accept the Professional license suite.
Operator Station
The Operator Station license suite provides the licensing typically required for operators. The suite contains DeltaV Operate support as well as
support for viewing historical data. PCs defined as Operator Station nodes during workstation configuration can accept the Operator license
suite.
Base Station
The Base Station license suite provides fundamental software support. The Base Station is best suited to situations where you want to define
the functionality of the workstation using add-on licenses. PCs defined as Operator Station nodes during workstation configuration can accept
the Base license suite.
Application Station
The Application Station license suite provides a foundation for integrating the DeltaV system with other networks and 3rd-party applications.
PCs defined as Application Station nodes during workstation configuration can accept the Application license suite.
Maintenance Station
The Maintenance Station license suite provides software licenses tailored to maintenance personnel. This includes diagnostics, AMS Device
Manager, and the Inspect with InSight feature in DeltaV InSight. It also includes a maintenance version of Control Studio which enables users
to calibrate devices and view their configurations. It does not allow configuration or download. PCs defined as Operator Station nodes during
workstation configuration can accept the Maintenance license suite.
Add-on and Scale-up licenses
After you assign a license suite, you can assign add-on and scale-up licenses. Add-on licenses add new licensed features and functionality to
the initial license suite and scale-up licenses increase the capacity of an existing license feature.
To expand the DST capacity of a workstation that has the DeltaV Experience license assigned, you must first assign a base ProfessionalPLUS
license suite. Assigning a base license suite uninstalls the DeltaV Experience license and enables you to assign I/O base and scale-up licenses.
Refer to product data sheets and the DeltaV System Planning guide for detailed information about workstation add-on and scale-up licenses.

Securing the Workstation in the Workplace
Make sure that workstations are physically housed in secure locations. Emerson Process Management offers the following recommendations
for DeltaV workstations:
 The ProfessionalPLUS workstation is a mission-critical machine. Make sure it is located in an extremely secure location to avoid
physical tampering.
 Make sure the Application Station is located in a heightened-security area. However, if it must be located in the engineer’s workspace,
take precautionary measures to prevent unauthorized physical access to this workstation.
 Physically isolate the Operator Station CPU from the operator working on it so that it cannot be booted with custom media but can still
be reset in the event of a system crash.
 Use the DeltaV Screen Saver for multi-user operator workstations to make sure that the workstation is locked when the user leaves it
and to prevent operators from locking out other operators. Refer to the Recommended Maintenance Practices topic for information on
how to use this feature.
BIOS Security
BIOS security is system protection that can prevent authorized users from modifying your CMOS and unauthorized users from accessing your
workstations. To help prevent an authorized person from changing a workstation's CMOS settings, use the BIOS to create a supervisor
password that limits access to the workstation. To prevent an intruder from accessing your system by using software started from the A:/
drive, use the BIOS to lock the boot sequence so that the workstation starts only from the C:/ drive. Refer to your Dell documentation for
details on how to configure the BIOS.
Important Although it is not part of DeltaV security, Emerson Process Management recommends that you use BIOS security to avoid
unauthorized tampering on your workstations.
Windows Firewall
The DeltaV install procedure turns off the Windows firewall. Make sure the Windows firewall remains off for all DeltaV workstations. The
firewall can produce unpredictable results.
Windows System Logon and DeltaV System Logon
There are two different logons for your system: the Windows logon and the DeltaV logon. The Windows logon logs the user on to the
workstation to access the computer system. Access to specific Windows system resources and the type of access the user has depend upon
user privileges. User privileges are set using the DeltaV User Manager.
When a user logs on to the system, the DeltaV Logon window appears. The DeltaV logon allows the user to access DeltaV resources and
applications. Access to specific DeltaV system applications and resources and the type of access the user has depend upon user privileges.
User privileges are set using the DeltaV User Manager. Refer to the DeltaV User Manager and DeltaV Security topic for more information
about the DeltaV User Manager application.
Important When you log off of the DeltaV system, be sure to log off of Windows as well, especially if you are logged on with Windows
Administrator privileges. Until you log off of Windows, subsequent users logging on to the DeltaV system operate under the Windows
Administrator account. The Windows Administrator account grants the user the right to perform actions that could interfere with the operation
of the DeltaV system.
Important When setting up the DeltaV system, make sure that Autoswitch Desktop is enabled. Doing so helps protect against operators and
maintenance personnel having unrestricted access to the system if a user with administrator privileges is logged on to the underlying Windows
system. Refer to the Enabling or Disabling Automatic Switching topic for more information.

Make sure that all users with Windows administrator privileges log off of the Windows system after have finished using a workstation. Do
not allow non-administrative users to log on to the DeltaV system on top of an underlying Windows Administrator logon.
System Time
Inside this topic
DeltaV Systems use the Network Time Protocol (NTP) to synchronize the time on all Control Network nodes. Any DeltaV workstation may
be defined as the master time source using the Physical Network Properties dialog in the DeltaV Explorer. Systems that require more precise
time derive master time from a network time server connected to a specific IP address on the DeltaV Control Network. Network time servers
are a requirement for systems that include SOE cards (Sequence of Events). The Symmetricom NTS-200 GPS Network Time Server has been
tested and approved for use with the DeltaV System. Refer to the documentation for the network time server for installation and configuration
information and to the Installing Your DeltaV Digital Automation System manual for specific network settings that are required for
configuring a network time server for use with the DeltaV system.
If a network time server is not used, a single workstation (called the master time node) keeps time for the entire DeltaV system. The
ProfessionalPLUS workstation is the master time node by default. However, you can use the DeltaV Explorer to define another workstation as
the master time node. The Set/Synchronize Network Time program (available from the Tools menu in DeltaV Explorer) determines the time
and date for the DeltaV System.
Note Setting the time while a historian other than the Continuous Historian is running may cause unexpected results. If you are running the
Legacy Historian, stop the historian before setting the time in DeltaV. (To stop the Legacy Historian, run pisrvstop.bat in the /PI/adm folder.
After setting the time, use DeltaV Explorer to download the historian.) If you are running a compatible, third-party embedded enterprise
historian, consult its documentation before setting the time in DeltaV. If you are running the embedded Enterprise PI Historian from OSIsoft,
Inc., for example, it may be necessary to uninstall the historian and then reinstall it after setting the time or changing the time zone in DeltaV.
The TimeInSync diagnostics parameter retains a status of 1 (good) if the time for the node remains within the following specifications from
the NTP server time:
Systems without a network time server - Workstations: 50ms; Controllers: 50 ms; Remote I/O Nodes:50 ms
Systems with a network time server - Workstations 10ms; Controllers: 3 ms; Remote I/O Nodes: 3 ms
You can set and synchronize the time from any DeltaV workstation on the Control Network. The network time is derived from the same
internal clock used by the Date/Time tool in the Windows Control Panel.
Caution Do not change the time using the Windows Date and Time Properties (accessed from the Control Panel or by double-clicking the
clock in the Taskbar). Windows Date and Time Properties do not synchronize the time in all the workstations and controllers. Instead, use the
Set/Synchronize Network Time tool (accessed from the Tools command in the DeltaV Explorer) to change the system time. This ensures that
all workstations and controllers are synchronized.
The Set/Synchronize Network Time tool includes the following components:
 Apply – Sends the time and date changes to the master time node, which broadcasts the time to all nodes on the Control Network.
 Close – Closes this dialog without changing the time.
 New Time and Date – Allows you to set the date and time for the system. Select the values that match the current time and date.
Warning Setting and synchronizing the system time affects Event Journals and historical data.

Synchronizing Time with an External Network
This section explains how to synchronize the time on your DeltaV System with an external network--a plant-wide network for example.
Requirements:
 At least one Application Station or ProfessionalPLUS workstation must be connected to the plant-wide network.
 The time source must adhere to Network Time Protocol.
To set up the network, follow these steps:
1. From DeltaV Explorer, select Remote Network under the ProfessionalPLUS workstation or Application Station, as shown in the
following figure.
2. From the context menu, select Properties.

The Remote Network Properties dialog appears.
3. Select the Enable Remote Network check box.

The following figure shows the dialog with the check box selected.
4. Select the Advanced tab on the Remote Network Properties dialog.
5. If you use this setup procedure to synchronize a local DeltaV network to a plant-wide master, enter the IP address of the plant-wide
master into the Primary Master Time Server fields. If your network has a backup time server, enter its IP address in the Backup Master
Time Server fields.
6. Run Workstation Configuration on the Application Station to allow communication on the Remote Network. The Remote Network
address of the Application Station (or ProfessionalPLUS workstation) must be supplied by that network administrator.
7. Select the properties dialog for the Physical network and select the DeltaV node configured to communicate with the plant-wide time
source as the Master Time Server of the DeltaV network. Select a Backup Time Server, if appropriate.
After this procedure is finished and Workstation Configuration has been run to allow communication with the remote network, the IP address
of the plant-wide Time Server on that remote network is added to the NTP.ini file. For example, a plant-wide time source at 192.167.90.91
appears in the NTP.ini file as follows:
server 10.4.128.1 prefer
server 10.4.128.2
server 192.167.90.91
server 127.127.1.1
driftfile ntp.drift
This NTP.ini file is generated for the DeltaV node connected to the remote network and you do not have to create or edit it.
The 10.4.128.1 and .2 addresses are set up automatically. The 192.167.90.91 is the address configured for the plant-wide Time Master. The
127.127.1.1 address indicates that this DeltaV node is the Time master for the DeltaV Network.
Do not modify the NTP.ini file. Any changes you make will be overwritten each time that DeltaV node is downloaded. To configure a
permanent connection to a plant-wide time server, use the procedure outlined above.
Workstation Synchronization
The system setup information stored on the DeltaV workstations must be synchronized across workstations to ensure proper operation of the
system. To accomplish this synchronization, one workstation on the DeltaV network (by default, the ProfessionalPLUS workstation) ensures
that this system-wide setup data is distributed automatically to all the workstation nodes whenever this information is updated. This function
is called Auto-Update.
The benefit of auto-update is that it is not necessary for you to download each workstation individually whenever the system setup data
changes. Only workstation-specific setup information requires a workstation download. If the DeltaV Explorer shows a blue triangle
download status beside a workstation or workstation subsystem then a specific download needs to be made to that workstation.
If you change system setup data and download any specific workstation, the DeltaV system downloads the changed system tables to the
ProfessionalPLUS. If you change something that is workstation-specific and download that workstation node, it will download that
workstation with the workstation-specific data.
Note For remote workstations the workstation-specific data is actually downloaded to the ProfessionalPLUS and then distributed to the
remote workstation via the auto-update mechanism.
If you change a node's configuration, download that node. The system determines if the change was global and downloads the
ProfessionalPLUS as needed.
The Auto-Update Service Control application enables you to select the file types that are automatically transferred from the ProfessionalPLUS
to all other workstations after any node is downloaded. To access Auto-Update Service Control, click Start | DeltaV | Engineering | Auto-
Update Service. The User.fxg file is can be included or excluded from distribution through command files. If you do not want the User.fxg
file to be distributed globally, run the Exclude_User_fxg.cmd from the ProfessionalPLUS workstation. If this command has been run in the
past and you want to include User.fxg in global distribution, run the Include_User_fxg.cmd.
The Auto-Update Diagnostics application enables you to view information about the Auto-Update Service running on a node. It also enables
you to look for new downloaded setup data and copy and download the new setup data to all nodes. To access Auto-Update Diagnostics, open
DeltaV Diagnostics and select Tools | Auto-Update Diagnostics. Refer to the Diagnostics online help for information on this application.
A download consists of many individual script files, which exist locally on the workstation after a download occurs. The following is a
discussion of which parts of a download are managed automatically through workstation synchronization and which require a manual
download to the specific node.
The following download scripts are workstation-specific. You must download these scripts to each workstation manually using the DeltaV
Explorer Download command. These scripts contain information regarding software licenses, historical data collection, and batch
configuration on the ProfessionalPLUS and Application Station and any modules assigned to the ProfessionalPLUS or Application Station.
 General workstation-specific download scripts, which are always sent to the target node
 SWLIC.SCR (Software License Assignments)
 PHIST.SCR (Continuous Historian Assignments)
 ProfessionalPLUS-specific download scripts
 LOOPDOC.SCR
 Batch executive files, if enabled (for example, RECIPE.DIR)
 DVController Specific files, if enabled (for example, modules assigned to the node)
 Application Station specific downloads
 Batch executive files, if enabled (for example, RECIPE.DIR)
 DVController Specific files, if enabled (for example, modules assigned to the node)
The following download scripts are system-wide tables or configuration files (system setup information). The system downloads these scripts
to the ProfessionalPLUS the next time any download is initiated (even downloads unrelated to the ProfessionalPLUS) then automatically
propagates them to other workstation nodes through workstation synchronization.
 Non-node specific download scripts
 ANT.SCR (Area Name Table)
 APT.SCR
 ATTSECT.SCR (Attribute Security Table)
 BHIST.SCR (Batch History)
 BSL.SCR
 DEFASEC.SCR (Default Area Security)
 DSTT.SCR (DST Table - not replicated to Remote Nodes)
 DT.SCR (Device Table)
 ETT.SCR (Event Type Table)
 EUDT.SCR (Engineering Units Description Table)
 FLDSECT.SCR (Field Security Table)
 GAAG.SCR (Global Horn Ack Group Table, not replicated to Remote Nodes)
 MODT.SCR (Module Table, not replicated to Remote Nodes)
 NCP.SCR (ACN Network Configuration Parameters, not replicated to Remote Nodes)
 NCT.SCR (Network Time Publisher, not replicated to remote Nodes)
 PHSL.SCR (Continuous Historian List)
 REMNET.SCR (Remote Network Configuration)
 SJL.SCR (Event Chronicle Configurations)
 UENUMS.SCR (User Defined ENUMS)
 USERT.SCR (User Table)
 WLNAMES.SCR
The Auto-Update Service does not automatically distribute operator pictures and process history view charts. You must download
workstations to update their pictures. Refer to Downloading and Uploading Operator Pictures for information on how to distribute pictures
and charts to all workstations.
Configuring the Fault-Tolerant Server to Run the DeltaV System
Inside this topic
Read, understand and follow ALL instructions regarding the installation, maintenance and operations of your Stratus ftServer computer.
The Stratus ftServer provides fault-tolerance through redundancy of the major hardware sub-systems and can be used as the hardware
platform for Application Stations. Refer to the Installing Your DeltaV Digital Automation System manual for information on installing and
connecting the ftServer hardware and to any Emerson Process Management KBAs for more information on using the ftServer with the DeltaV
system. For complete technical information, refer to the Stratus ftServer hardware and software-related manuals or to the online
documentation.
Important Plant expertise must be developed in the maintenance of the Stratus ftServer; in understanding compatibility with DeltaV
versions; in performing DeltaV software upgrades; and, in the application of the Stratus IPL, and also the installation/maintenance of the
Windows operating system. Additional information regarding the Stratus ftServer can be found in the Emerson Process Management KBAs
and the DeltaV Release Notes KBA (which includes the DeltaV Compatibility Chart). It is important that you read, understand and follow
instructions given in these documents.

Configuring the CPU not to Automatically Synchronize
CPU redundancy is achieved through a pair of CPU units that house a pair of processors, RAM, and the Motherboard Chipset. The CPUs are
timed from a common synchronization signal in order to run in "lock-step". This means both CPUs receive the same instructions, run at the
same clock, and produce the same results. The results are monitored and compared and, if one unit fails, it is removed from the system while
the other continues to run. This occurs in milliseconds and is completely transparent to the operating system and application software. Since
each CPU has access to the entire system's resources, the system maintains complete redundancy of its other major sub-systems while running
with a simplex CPU unit.
A replacement CPU unit can restore the ftServer to full redundancy. However, the RAM of the running unit must be synchronized with the
RAM of the new, incoming unit. This requires both of the CPU units to pause. During this pause, the operating system on the ftServer is
suspended. The duration of this pause is based on the amount of RAM, for example, with 2 GB of RAM, the pause is 25 seconds on a Stratus
3210 ftServer and 4-8 seconds on a Stratus 3300 ftServer. It is highly recommended that you ensure that your process is in a steady state that
can withstand this pause before you restore the CPU units to redundancy. You can however, prevent an unintended pause by configuring the
ftServer to not automatically synchronize the CPU. This is the recommended configuration for DeltaV installations.
To prevent an unintended pause, the ftServer can be configured to not synchronize the CPUs until a user initiates it. This does not prevent the
system from booting or the application software from running. Rather, it causes the CPU to remain simplex until a user approves the
restoration to redundancy. This also works as a safety measure. If a CPU experiences a failure, it is rebooted immediately and runs
diagnostics. If the failure is intermittent, it may pass diagnostics. The default configuration allows the CPU unit to attempt to rejoin the system
and causes the RAM synchronization pause to occur. Setting the CPU unit not to synchronize on boot causes the redundancy status to be
degraded and the failure can be investigated.
The RAM synchronizes and the pause (described above) occurs during the regular boot process. If the system is configured not to
automatically synchronize, a user must initiate the inclusion of the second CPU unit after the system boots.
To disable the CPUs from auto synchronizing:
1. Open the ftServer MMC Console.
2. From the tree-view, expand ftServer Drivers, select Stratus BigBoard Driver, and click the right mouse button.
3. Select Properties from the context menu.
4. Choose the last Properties tab.
5. Change CPUBringUpPolicy to Defer Bringup-Allow Simplex.
6. Click OK.
The ftServer remains simplex when it boots until CPUBringUpPolicy is changed to Enable BringUp. Once this is done, the CPU will begin
synchronization. Be sure to reset the value to "Defer-Allow Simplex" after the CPU has synchronized.

Using the LEDs to Troubleshoot
LEDs on the front of the CPU units provide a good indication of their operational state. Refer to the Stratus ftServer documentation for your
ftServer model for a complete explanation about what the LEDs indicate on that model. Anything other than a good indication should be
investigated.

Configuring the Ethernet Ports
The DeltaV implementation of the ftServer uses the Ethernet port redundancy, that is the "teaming" Intel NIC driver feature of the ftServer
is implemented. It also relies on the DeltaV network redundancy. You can use the DeltaV Diagnostics application to validate that the NIC
redundancy is operational.
The Intel NIC driver teaming creates a pair of NICs that are redundant. Each pair is recognized as one NIC and has one IP address bound to
it. This is done through the use of the Intel NIC driver. For DeltaV systems, select "Adapter Fault Tolerant" (AFT) as the type of Ethernet
fault-tolerant team. All other settings can be found in the online manual, Stratus ftServer XXXX Series: Configuring Ethernet PCI Adapters
(where XXXX is your Stratus ftServer model).
When configuring the teaming for a DeltaV system, one pair of teamed NICs connects to the primary DeltaV network. A second teamed NIC
pair connects to the DeltaV secondary network. Install the paired NICs so that they span I/O Enclosures. For example, NIC_A and NIC_A1
will form a teamed pair that will be on the DeltaV primary network. NIC_A will physically reside in I/O Enclosure 10 and NIC_A1 will
reside in I/O Enclosure 11. For the DeltaV secondary network, install NIC_B and NIC_B1 where NIC_B is in I/O Enclosure 10 and NIC_B1
is physically in I/O Enclosure 11.
Refer to the online Stratus ftServer XXXX Series: System Monitoring and Troubleshooting manual for information on locating the I/O
Enclosures (where XXXX is your Stratus ftServer model).
Make note of your paired teams. This information is required when running DeltaV Workstation Configuration after installing the DeltaV
software.
Note If there are multiple Application Stations with connections to the same Plant LAN as the Stratus ftServer machine, then the Plant LAN
NIC in the ftStratus machine should also be teamed. This is due to how DCOM utilizes network pathways to send OPC data. It is possible for
the Plant LAN pathway to be used for DeltaV OPC data and therefore it needs to be teamed.
In the ftServer 3210 model, you can use the embedded Ethernet ports with a DeltaV system ONLY when you use the "teaming" Intel NIC
driver feature. This is the recommended configuration. The 3210's embedded Ethernet ports share the same MAC address and if they are not
used as part of a team they cannot be used with the DeltaV system. This is because the DeltaV system requires that all the Ethernet ports have
a unique MAC address. This is not an issue with the ftServer 3300 or 4300 Ethernet ports as those ports have unique MAC addresses.
In the ftServer 3300 model, you can use dual port Ethernet cards (available from Stratus) provided you are running the Stratus ftServer
software v3.x. In the ftServer 4300 model, you can use dual port Ethernet cards (available from Stratus) provided you are running the Stratus
ftServer software v4.x. Configuring teaming when using the dual port Ethernet cards follows the same rules as using regular single port
Ethernet cards. That is, the team must span the I/O Enclosure, the type of Ethernet fault-tolerant team to select is "Adapter Fault
Tolerant" (AFT). For all other settings, refer to the online manual, Stratus ftServer XXXX Series: Configuring Ethernet PCI Adapters (where
XXXX is your Stratus ftServer model).

Power Supplies and Subsystems
The CPU, I/O enclosures and power supply configurations in the Stratus ftServers differ between the models. This can affect how you setup
each subsystem in the ftServer to prevent problems in the event of a power supply failure.
In the Stratus 3210, the power supply system is independent of the I/O enclosure, SCSI disks, and PCI network cards. Therefore, a loss in one
power supply does not prevent the second power supply from supplying power to all the Stratus components.
In the Stratus ftServer 3300 and 4300, each power supply is physically attached to its own set that includes an I/O enclosure, the SCSI disks,
and the PCI network cards. Therefore, a failure in one power supply will cause a failure in the components attached to it. The loss of one
power supply forces the Stratus ftServer 3300 and 4300 to a simplex configuration.
The recommended configuration for all Stratus ftServers (but especially important in the 3300 and 4300) is to create an exact mirror image of
the subsystem (including I/O enclosure, SCSI disks, and PCI network cards) on a second power supply.
When first configuring the Stratus ftServer (all models), you should force an I/O enclosure failure. That is, after running the Initial Product
Loading (IPL) and before installing the DeltaV software, use the ftServer MMC Console to force a switchover from the current I/O enclosure
to the secondary enclosure. This forces the operating system to recognize two I/O enclosures and prevents any keyboard or mouse failures in
the event of a switchover.

DeltaV Installation and Integration
The ftServer runs the same software as the DeltaV Application Station. However, there are some installation and configuration requirements
to achieve full redundancy.
The ftServer comes fully installed with the operating system; however, you must install the DeltaV software. To install the DeltaV software,
use the standard DeltaV installation disk and run the setup procedure. The ftServer must have a C: and D: volume and you must install the
DeltaV program files on the C: drive and the "DVData" directory on the D: drive. This maximizes both redundancy and performance.
As mentioned above, the "teaming" Intel NIC driver feature of the ftServer is implemented. When running DeltaV Workstation
Configuration, you must select one of the paired (teamed) NICs (it is represented as a single NIC in the software's interface) for your DeltaV
primary network and one other paired (teamed) NIC for the DeltaV secondary network. The individual NICs are also displayed in DeltaV
Workstation Configuration; however, do not select those cards as they do not have the IP addresses bound to them and DeltaV Workstation
Configuration will not complete successfully.
The recommended minimum video resolution for use with the DeltaV system is 1024×768 at 256 colors.
The ftServer has a built in Phone-Home and Dial-In feature. The Phone Home feature allows the user to connect the ftServer to a phone line
and if a component fails, the system will automatically call Stratus and order a replacement part. The initial testing of the ftServer was with
the Phone Home feature disabled. There is no specific incompatibility with the Phone-Home feature; however, it is recommended that this
feature be disabled.
The DVFTSStatus Utility
The DVFTSStatus application integrates the redundancy status of Stratus ftServers with the DeltaV system.
It polls the status of the system, compiles it into an overall integrity, and transmits it to the DeltaV system via an OPC link. The OPC link
writes to a pre-made DeltaV module with an over-all integrity parameter. The module includes a watchdog timer and Change-Of-State alarm.
The DVFTSStatus application is intended to alert the operator/process engineer that the ftServer is in a less than fully redundant state. The
DVFTSStatus application also has a simplified tree structure that can help in the diagnosis of the problem.
A Change-of-State alarm applied to a pre-made DeltaV module (named DVFTSStatus) will trip if the status of the ftServer goes bad or is
unresponsive.
Using the DVFTSStatus Utility
The DVFTSStatus application is intended to run on the Stratus ftServer. A pre-made DeltaV module needs to be imported into the
configuration database and installed to run in the Virtual Controller of the ProfessionalPLUS workstation.
Caution The DVFTSStatus utility monitors a subset of the indicators in the Stratus ftServer, namely the 'Operational State' of the major
redundant components. It is possible for a component to have a bad status that does not reflect as an 'operational state' fault. For example, the
drive mirror status on a 3210 is not reflected as a bad operational state. Therefore, it is important that a maintenance engineer become familiar
with the system and periodically monitor for other symptoms or warnings.
DVFTSStatus Utility Setup
The DVFTSStatus application is located in the \DeltaV\Bin directory by default. To start the utility, double click the DVFTSStatus.exe file,
For instructions on setting up and using the utility, refer to the utility's online help.
How the DVFTSStatus Utility works
Using the WMI technology, specific status points are collected from the ftServer. Those items are enumerated into a hierarchy (tree) structure.
The hierarchy is then evaluated for critical, 'missing' components. If such a component is missing, then a place holder is created in the
hierarchy and a 'missing' state is assigned. The status of every component is scanned. The status of a bad component is traversed up the
hierarchy to the root. The end result is an overall integrity of the system at the root of the hierarchy view.
Two pieces of data are communicated to the DVFTS_Status DeltaV module via an OPC write. They are the Boolean overall integrity and a
number representing the system time. The system time is used as a watchdog timer in the module. If an update has not been received in 200
seconds, then the Change-of-State alarm is tripped.
The 'Refresh' button will clear the entire hierarchy and rebuild it. If you are not sure that the hierarchy is reading correctly, it is recommended
that the 'Refresh' button be clicked.
For additional help, refer to the application's on-line help.
Renaming Workstations
Important It is vital that you read this entire topic before renaming any workstation.
Note Do not rename ProfessionalPLUS workstations. You can rename all other workstations on your DeltaV network. The process of
renaming a workstation involves the entire DeltaV network.
For information on replacing a workstation on the DeltaV network, refer to the DeltaV Knowledge Base.
Important Do not change workstation names from Windows. Always use DeltaV Workstation Configuration to change workstation names.
Renaming a workstation changes the UNC name of that machine. You must make the other nodes aware of the new name in order to
communicate with that machine. This is true for all DeltaV workstation types. All of the nodes communicate with all other nodes on the
DeltaV network.
Renaming a workstation consists of three major steps:
 Rename the workstation in DeltaV Explorer
 Reconfigure the renamed workstation with DeltaV Workstation Configuration
 Download the new data to each node using DeltaV Explorer
You must complete all three of the steps listed above before DeltaV will function properly.
Note Each node (workstation or controller) is downloaded with configuration data. This information is stored locally in that node and must be
updated when you rename a workstation.
To rename workstations
1. Log in to Windows on the ProfessionalPLUS workstation as a user with Administrator privileges.
2. Log in to DeltaV as a user with Administrator privileges.
3. From the ProfessionalPLUS workstation open DeltaV Explorer.
4. Select the node being renamed, right click, and then select Rename. If this node has Alarms and Events enabled, you are prompted to
disable Alarms and Events prior to renaming the workstation. To disable it, expand the workstation in the DeltaV Explorer hierarchy
and right click the Alarms and Events item. Select Properties from the context menu. Uncheck the box and click OK.
5. Enter the new workstation name.
6. On the popup dialog that appears, click the Yes button to create a configuration diskette.
7. On the workstation you are renaming, log in to Windows as a user with Administrator privileges.
8. Stop all DeltaV programs.
9. Run DeltaV Workstation Configuration.
10. From DeltaV Workstation Configuration, click Next, Next, Browse, and select the correct workstation name from the list on your
configuration diskette.
11. Restart the computer when prompted by DeltaV Workstation Configuration. After the computer has restarted, log in to Windows as a
user with Administrator privileges and let DeltaV Workstation Configuration complete.
12. From the ProfessionalPLUS workstation use DeltaV Explorer to download all the nodes (you can either download them individually or
as a group) on your DeltaV network. Refer to the Downloading Data topic for details about partial downloads.
If you rename any workstations that are SQL servers (such as the Batch Historian, or Version Control machines), you must shut down and
restart the workstation or restart the SQL Server. For more information refer to the SQL Server Books Online topic Renaming a Server.
If you are renaming a workstation on a domain, you must verify the name and IP address of the newly renamed workstation has been updated
in Active Directory and also on the DNS server. Go to the workstation that was promoted to domain controller first and verify that Active
Directory is updated. Go to the DNS server (also on the first domain controller), right click the My Computer icon (this icon may have been
renamed to the actual computer's name) and select Properties. Verify the IP address for the newly renamed workstation is updated.
Workstation Configuration creates a new IP address for the workstation when it is renamed.
If you are renaming a Continuous Historian workstation, you will need to export your datasets and import them after the rename. This is due
to Continuous Historian using the workstation name as part of the data source name. Historical data collection will be stopped during the
renaming process.
To rename the Continuous Historian workstation
1. On the Continuous Historian workstation, select Start | Settings | Control Panel | Administrative Tools | Services.
2. Stop the DeltaV services (including DVCHScan.exe, DVHistorianserver.exe andDVHistorianserver_2.exe.
3. Run the Continuous Historian Administration application.
4. Create a new Active dataset. This allows you to export the currently Active dataset.
5. Export all Current and Extended datasets to the local drive.
6. Close the Continuous Historian Administration application.
7. Follow the To rename the workstation instructions.
Note Restarting the workstation after running DeltaV Workstation Configuration will restart the DeltaV services on this computer.
8. Stop the DeltaV services again.
9. Rename the existing Continuous Historian database directory (for example, DeltaVHistory to DeltaVHistory-old).
10. Copy the C:\DeltaV\fdbhist directory and paste it as the new D:\DeltaVHistory.
11. Open a DOS window and run the following Objectivity command to register the new database for use

C:\ooinstallfd -nocheck -standalone -lockserverhost COMPUTERNAME X:\DeltaVHistory\DvCHdb.hdb

(where COMPUTERNAME is the new name of the Continuous Historian workstation and X:\ is the drive where the DeltaVHistory
folder exists).

12. Reboot the machine.
13. Run the Continuous Historian Administration application.
14. Restore all the exported datasets.

Switching Host Machines
There are a few times when you need to switch which machine is your database host machine in a DeltaV system. If the current host machine
begins to fail (hardware failure) and is no longer dependably online, you must move the database to another machine. If you combine two or
more previously separate DeltaV control networks, you need to make one workstation the host for the entire control network. There can only
be one host machine on a network.
In order to become a host machine, a workstation must:
 be a ProfessionalPLUS machine
 have Objectivity's Lock Server installed
 have the control database on it
To change the host machine, you must take the database off of the current host and then configure and download the new host. You must
follow the instructions in the order given below or you might corrupt the data and end up reinstalling the DeltaV software. The database will
not function properly if corrupted. Refer to the Database topic for more information on correcting database problems.
Important Read both sets of instructions (that is, those under "Current Host" and under "New Host") before beginning the switch.
Current Host
Follow these instructions for the machine that is currently your host machine. The current host machine is a ProfessionalPLUS workstation
with Objectivity's Lock Server and the control database installed on it. If you are combining two networks, this is the machine that will no
longer be the host.
Note The control network must be off line while changing the host machine. No nodes can be accessing the database at this time.
1. Export your database and any graphics specific to this control strategy. You can export to floppy diskette or to a drive shared by both
the current host and the new host.
2. If you are keeping the current host machine on the control network (but not as the host), stop all of the DeltaV services. To do this, run
Workstation Configuration on the current host and download it as type Other.
Refer to the Workstation Configuration instructions for more information on configuring a workstation.
New Host
The DeltaV host machine is always a ProfessionalPLUS machine with Objectivity's Lock Server and the control database installed on it.
Follow these instructions after completing the Current Host instructions above. Designate which workstation will be the new host machine.
Remember, the control network must be off line. No nodes can be accessing the host machine.
Note If the new host is a machine of type Other or Application Station, uninstall and then reinstall the DeltaV software using the type
ProfessionalPLUS.
1. Create a new database using the Database Administrator Tools. Name it the same name as your exported database.
2. Run Workstation Configuration on the new host machine.
3. Refer to the Workstation Configuration instructions for more information on configuring a workstation.
4. Set Host Machine using Database Administrator Tools to this new machine (using the machine name you just assigned in Workstation
Configuration).
5. Set the new database as the Active Database using the Database Administrator Tools.
6. Run Synchronize Workstations in Database Administrator Tools. The control network is now on line.
Remote Access
This book contains information on remote access of DeltaV software. Click on an item in the Table of Contents inside this book for more
information.

DeltaV Remote Client Overview
Inside this topic
The DeltaV Remote Client application works seamlessly with two Microsoft applications, Remote Desktop Connection and Terminal Server.
It allows a remote user with network access and appropriate permissions to log into a DeltaV system. The client node must be running a 32-bit
Microsoft Windows operating system (such as Windows XP). The only other software requirement on the client is the Microsoft Remote
Desktop Connection software, which is part of the Windows operating system and is also available as a free download from Microsoft.
Remote access can be via a dial-up modem, cable modem, direct LAN connection, satellite, microwave, wireless, or other standard connection
that supports the remote communications protocol.
Note It is required that you configure the Terminal Server prior to installing the DeltaV software. The information in the topics here cover
configuring the DeltaV portion; that is, how to setup the DeltaV system to accept remote clients. For information on configuring the Windows
operating system to support the Terminal Server and Remote Clients, refer to the Emerson Knowledge Base Article for your operating system.
Only DeltaV ProfessionalPLUS or Operator Stations can function as DeltaV Remote Client servers; the workstation must be running
Windows Server (Server 2003 or higher) software (refer to Installing Microsoft Windows Server and Terminal Server). Sessions can be
reserved for specific users and specific client machines (nodes). Small DeltaV projects may have only one or two sessions defined with full-
function Professional licenses, while large applications may have numerous remote terminal sessions defined at varying levels of licensing
(for maintenance only, operators only, Professional, etc.)
Remote sessions are defined in the DeltaV Explorer. The functions available to the remote user depend upon the license (or licenses) assigned
to the session under which the user accesses the system and the user's own security privileges (as defined in the DeltaV User Manager). For
example, an engineer at a remote location can be given full access to a Remote Client server to make changes to a DeltaV system
configuration, build operator graphics, and do everything else that could be done sitting at a local DeltaV workstation. (On the other hand, if
the same engineer logs on to a remote session that is licensed for operator functions only, he will not be able to do any configuration tasks.)
Operators can be located away from the plant and yet have full control of the process as if they were at a local Operator Station. Emerson
Process Management experts can be given temporary access to a customer's system to help diagnose problems without the expense and time
delay of a trip to the field. It is possible for a user at a Remote Client node to open multiple windows to access different DeltaV systems
simultaneously.
Concurrent Session Limits
There is no limit to the number of remote sessions that can be defined under the Remote Client subsystem of the Operator Station or
ProfessionalPLUS workstation. However, there are limits to the number of concurrent remote sessions that can actually be open at one time.
The current tested limit for concurrent sessions is fifteen; this is not a fixed system limit, but a guideline.
Only one DeltaV Operate application can be in Configure mode at one time; that is, only one person can be editing graphics at a time on each
server. It is highly recommended that for larger numbers of remote users the engineering and operator functions use dedicated servers rather
than mixing engineering and operations functions on one server.
A Remote Client server can have a maximum of 60 database connections open at one time. After the limit is reached, any attempt to open an
application that needs a database connection will result in an error message and the application on the remote client will be closed.
Warning Another limitation on remote sessions is that there is a maximum of 7200 graphic data links on all displays open through a Remote
Client server. Beyond that number, graphic updates slow considerably and therefore the data on those graphics may not be updated as
frequently as required. No explicit warning messages are given about the reduced performance. It is important to limit the number of users so
that more than 7200 data links cannot be open at one time. For example, if displays are configured with 600 data links, then no more than 12
total sessions of any kind should be configured on the server.
Terminology
Following is a list of terms and their definitions.
DeltaV Remote Client - the DeltaV application that allows access to a DeltaV server through a Microsoft Remote Desktop connection
Remote Client server - the DeltaV ProfessionalPLUS or Operator Station that is set up to function as a host machine (server) for clients
accessing a DeltaV system through the DeltaV Remote Client application
Remote Client node- a computer, such as a desktop PC, laptop computer, or any DeltaV workstation that can be used to access a DeltaV
system through the DeltaV Remote Client application
Remote Client session - an object configured in the DeltaV Explorer that represents the availability of a remote session. It contains an
assigned license, assigned areas (from the DeltaV application's control strategy), and optional reserved lists of users/nodes.
Remote Session - an actual session in which a Remote Client server is accessed by a Remote Client node
Terminal Server - a Microsoft application that includes the basic functions necessary for administrators to set up server and client nodes,
manage connections, send messages, view sessions, and so forth.
Remote Desktop Connection - a Microsoft communications tool that allows a remote PC to connect to a host computer's desktop and run
applications as if the user were sitting at the host machine. It is available through the Start Menu under Programs | Accessories |
Communications.
Note For information about using the DeltaV screen saver to set up the auto-logoff feature on a remote terminal, refer to the Recommended
Maintenance Practices topic.
Installing Microsoft Windows Server and Terminal Server
Microsoft Windows Server (2003 or higher) and Microsoft Terminal Server must be installed on the server machine before the DeltaV
software is installed. Multiple reboots of the computer are required for this process.
Note For complete information on configuring the Windows operating system to support the Terminal Server and Remote Clients, refer to the
Emerson Knowledge Base Article for your operating system.
1. Install Windows Server (2003 Standard Edition or higher) on the server machine per the instructions found in the Emerson Knowledge
Base Article for that operating system. Use the Per Server licensing on Windows Server 2003.
2. Add the Microsoft Terminal Server component per the instructions found in the Emerson Knowledge Base Article for the operating
system. When installing on Windows Server 2003, select the Full Security option.
3. When installing the DeltaV software, use one of three choices as the workstation type for the server:
 ProfessionalPLUS as a Remote Client Server
 Operator Station as a Remote Client Server
 Simulate for standalone laptop or workstation
Important During installation of the DeltaV software, the correct workstation type must be selected to designate the workstation as a
Remote Client server.
4. After installing the DeltaV software, you must configure the Windows Server operating system properties to enable remote access.
a. From Administrative Tools, select Services.
b. Select the Routing and Remote Access service.
c. Right click and select Properties.
d. Set the service to enable automatically.
e. Click OK on the dialogs to close them.
f. Open the Systems Properties dialog by clicking Start | Settings | Control Panel | System.
g. Select the Remote tab.
h. In Windows Server 2003, select Allow Users to connect remotely to this computer. In Windows Server 2008, select Allow
connections from computers running any version of Remote Desktop.
i. Configure the users by following the instructions in the Administrator Functions: Adding Users topic.
j. Click OK.
5. On the remote node (the machine that connects remotely to the DeltaV system) you must install the appropriate Microsoft licenses.
DeltaV licenses for remote use are assigned in DeltaV Explorer and are based on the existing license structure for DeltaV workstations.
Starting and Ending a Remote Client Session
Inside this topic
Once you have connected to the Remote Client server, you have access to all the functions that you are authorized to use according to the
licenses assigned to the remote session to which you are connected and the user privileges associated with your user name. This section covers
the basic steps for starting and ending a session.

Remote Connection Settings
You may need to experiment to determine the settings that are optimal for your connection speeds and the type of work you are doing on
remote sessions. The Remote Desktop Connection dialog box has five tabs (General, Display, Local Resources, Programs, and Experience)
that allow you to define your choice of server computer, connection speed, display color preferences, sound preferences, and so on. Following
are a few general recommendations for settings:
 Local Resources tab - to hear alarms, select Bring to this computer
 Experience tab - select your connection speed
 Experience tab - do not select Bitmap caching
 General tab - save settings in a file if you will use remote sessions frequently
 Display tab - set to 16-bit, 65,536 colors
Note DeltaV Operate does not support color quality settings greater than 16-bit, 65,536 colors. If you change the display
resolution on the remote client system, it may be necessary to reset the color quality setting.
You can save one or more preconfigured connection files to store your remote connection settings. Thus, you can have customized settings for
a 28.8 Kbps modem connection, a direct LAN connection, and any other kind of connection you might use. If you routinely connect to more
than one server, you may want to customize your settings for each server. To further speed up the remote connection process, you can save
these files as shortcuts on your Windows desktop.
Warning Although it is possible to save your Windows password in the connection file, it is strongly advised that you do not do so. Although
it could speed up your connection time, it also provides a direct path for unauthorized access to both the server and your local computer. In
general, it is never a good idea to save your password.

Starting a Remote Client Session
The following procedure describes how to connect to a remote server. It includes information on how to select options on the Remote Desktop
Connection dialog tabs. The connection settings for your user name are automatically saved and used the next time you connect, so it is not
necessary to open the Options dialog again unless you wish to change one or more settings. Ensure that non-DeltaV users do not have
authorization to access the server desktop; trust relationships with other systems may accidentally permit this access.
Important If you connect from a remote client to a DeltaV workstation that is running the Windows Vista operating system and where
another user is logged on to the local workstation, you cannot run DeltaV Operate from the remote client. To run DeltaV Operate from a
remote client, have the other user log off the local DeltaV workstation.
To start a remote session from a client node
1. From the Windows taskbar, navigate to Remote Desktop Connection from the Start menu.. (It is preferable that a Remote Desktop
shortcut be provided for all users.)
Note If you intend to run DeltaV Operate in a multiple monitor configuration through a remote connection, start the Remote Desktop
Connection program with the /span option by typing the following at a command prompt: Mstsc /span. For more information about
considerations that apply when running DeltaV Operate in a multiple monitor configuration through a remote connection, refer to Using
Multiple Monitors on a Remote Client in Using DeltaV Remote Client from a Client Node.
2. In the Remote Desktop Connection dialog box, either browse for the name of the Remote Client server to which you want to connect or
type its name in the Computer field.
3. Click the Options button to expand the Connection dialog box.
4. On the General tab, type your user name and password.
5. Make other connection choices for sound, color, connection speed, etc., on the other tabs.
6. If you wish to save the settings in a file, click the Save As button on the General tab to save the settings in a file.
Note Even if you do not save the settings in a file, the settings are automatically saved and will be used the next time your user name
connects. You need to save the file only if you wish to create a shortcut for your desktop or if you wish to have multiple preconfigured
connection files for different servers, connection speeds, etc.
7. Click Connect. It will take a few seconds for DeltaV software to initialize.
8. On the DeltaV logon dialog box, the server computer name and your user name appear in the Computer and User name fields,
respectively. Enter your password and select a session. Only those sessions that are available for your use (as defined by the reserved
lists and not in use by another Remote Client node) appear in the list of sessions from which to choose.
9. After selecting a session, click OK.
Depending on your user privileges and the license assigned to your terminal session, you will then have access through the FlexLock system
to one or more of the following: the Windows Desktop, the DeltaV desktop, or the DeltaV Operate application.

FlexLock
The FlexLock application provides the same secure operating environment through the remote connection as it does on a normal DeltaV
workstation. Users with remote Windows desktop access and the necessary DeltaV privileges can launch most DeltaV applications through
the Windows Start menu, if they are connected to a remote session with an appropriate license. (Note, however, that any user who logs on to a
terminal session that is licensed only for operator control will be restricted to operator functions, regardless of their own user
privileges.) Typically, operators are restricted to the DeltaV Operate system, and the other buttons will be inactive on the FlexLock dialog.
Note It is possible that a Remote Client session running FlexLock does not appear on the Processes tab of the Windows Task Manager. If it is
necessary to close FlexLock (for instance, to uninstall the DeltaV system), select the checkbox "Show processes from all users" on the Task
Manager Processes tab. Then select and end the process DeskTop.exe, which is the FlexLock name in the process list.
You can access online help for FlexLock by pressing F1 when the dialog has input focus.

Log Off vs. Disconnect
The terms "log off" and "disconnect" mean different things when talking about remote sessions. In addition, the term "log off" has two distinct
uses.
Log off - In general, if you log off a remote session (from FlexLock or the Windows Start menu) or an Administrator logs you off, the result
is that your DeltaV User ID is logged off, all DeltaV applications are closed, and the remote session is deleted from the server. That DeltaV
Remote Client session becomes available for use by another user or node that is authorized to connect to that session.
Log off DeltaV User ID - In some DeltaV applications, such as DeltaV Operate, you can log off a DeltaV User ID, but leave the DeltaV
application open, with a user of <none>. (This type of logoff is possible through the DeltaV logon button on the DeltaV Operate or DeltaV
Explorer button bar.) When the operator session is on a Remote Client connection, this kind of logoff leaves the DeltaV Operate application
open on the server with no user. However, the Remote Client session is no longer marked as in use, so another remote user would be able to
connect and start a fresh session. (Note that an Administrator can set a time limit on idle sessions so the original session can be ended and
deleted from the server automatically.)
Disconnect - If your session is disconnected, either through a lost communications connection or because an Administrator disconnects the
session, the effects may be different, depending on settings in FlexLock and Windows.
Generally, without automatic logoff, time-out, or FlexLock DeltaV Autologon enabled the result of a disconnect is that your Windows
account is still logged in, but your DeltaV User account is logged off. Your DeltaV applications stay open with a user of <none>. If DeltaV
Autologon is set, and you were not disconnected by an administrator, and time-outs have not expired, when the connection is re-established,
your DeltaV session continues.
If DeltaV Autologon is not selected, and you are able to reconnect to that session or connect to a new session, you can log in to the DeltaV
software again and your applications will open as before under your user ID and you can continue what you were doing when the connection
was lost. If, however, an automatic time-out has been set for disconnected sessions, your applications will all be closed when the time limit is
reached. It is therefore recommended that you save work frequently when doing configuration work on a remote connection if you do not
enable DeltaV Autologon.

Logging Off the DeltaV Software and Disconnecting an Operator Session
After finishing a remote session, an operator normally leaves the DeltaV Operate application open for the next operator who will be using the
remote node. The next operator logs on to the DeltaV system through the DeltaV Logon button on the Operate toolbar. The new operator also
selects a remote session on the DeltaV logon dialog. If the operator wishes to log off his DeltaV User ID, but keep the DeltaV Operate
application open, he can do so by clicking the DeltaV Logon button and selecting Logoff. This changes the user to <none> and opens the
FlexLock application for the next operator to use to enter the system.
If, for some reason, the operator needs to close the DeltaV Operate application and disconnect from the remote session, he should do so by
selecting the Logoff Windows option from the FlexLock dropdown menu.

Logging Off and Disconnecting from the Windows Desktop
Engineers and administrators with Windows desktop privilege have two options for logging off and disconnecting from a remote session.
Before disconnecting from the Windows desktop, first close any DeltaV or Windows applications you are running (such as DeltaV Explorer,
Control Studio, or Terminal Services Manager). Then logoff using one of the following methods:
 Select Logoff Windows from the FlexLock dropdown menu
 Select the Log Off option on the Windows Start menu
Important It is very important that remote users do not use the Shut Down option from the Windows Start menu when they are connected to
a DeltaV Remote Client server because this will shut down the server machine. It is recommended that the Shut Down option be disabled by
the Windows Administrator.
If you are logged on to a remote terminal session, do not use the X on the remote Windows title bar to close your session. This will disconnect
your Windows session, but your programs will continue to run while you are disconnected.
Note The system administrator should configure automatic ending of disconnected or idle sessions after a specified amount of time. When a
session is ended this way, all Windows and DeltaV applications are closed and the session is deleted from the server.

Unintentional Disconnects
If you lose your remote connection while working with DeltaV or Windows software, what happens depends on settings made in a number of
places:
 Microsoft Terminal Services Configuration
 FlexLock DeltaV Autologon feature
Depending on the use and settings of these items, if you lose connection anything may happen from being disconnected from your windows
session after a timeout to having your Windows and DeltaV sessions re-established when the connection recovers within a time limit.
For more information, refer to Recommended Maintenance Practices and Limiting Time for Idle, Active, or Disconnected Sessions in
Administrator Functions: Managing Connections.

Forced Disconnects
There is also the possibility that your session will be terminated by an administrator. In such circumstances the Administrator will likely send
a message through either the DeltaV Diagnostics system or the Windows Terminal Services application to ask you to exit the programs you
are working on and logoff. However, if you are temporarily away from the remote terminal or otherwise unaware of the request, the
administrator can log you off the DeltaV system and force a disconnect without your consent through the Administrator functions. A message
will be displayed notifying you that the session was disconnected.
Using DeltaV Remote Client from a Client Node
Inside this topic
Using a remote node is, of course, not exactly the same as using a configured DeltaV workstation. A few of the main differences are discussed
in the following paragraphs.
Important To run DeltaV Operate in a terminal server client session that uses a widescreen monitor, you must have Remote Desktop
Connection (Terminal Services Client) version 6.0 or higher.
Connection Speed Considerations
When using slow connection speeds (generally 64 Kbps or slower), you may want to enable bitmap caching and perhaps change the color
settings for your connection. If you are using remote connections on a regular basis, you may need to experiment to find the combination of
settings that optimizes the performance of your connection. You can save your connection settings in a file. To do this, use the Connection
Settings option on the General tab of the Remote Desktop Connection dialog. (Click the Options button on the initial connection dialog to see
the full set of dialog tabs and connection choices.) Multiple configuration files can be saved to customize settings for different connection
speeds, different servers, and so on. (The Windows user name and password can also be stored.) Shortcuts for the configuration files can be
placed on the Windows desktop to further speed up the connection process.
Bitmap caching can be enabled or disabled using a checkbox on the Experience tab of the Remote Desktop Connection dialog. Connection
speed can also be selected on the Experience tab. Display color settings can be selected on the Display tab. Some considerations for making
connection choices are:
 For slower connections, it may be useful to enable bitmap caching. This improves subsequent access to pictures by storing frequently
used images on your local hard disk.
 For high-speed connections (greater than 512 Kbps), an error may occur when bitmap caching is enabled. The error states that the disk
is full or the cache directory is missing or corrupted. If you get this message, try reconnecting with bitmap caching disabled.
 Set the color quality in the display properties to 16-bit, 65,536 colors.
Note DeltaV Operate does not support color quality settings greater than 16-bit, 65,536 colors. If you change the display
resolution on the remote client system, it may be necessary to reset the color quality setting.
In general, the number of datalinks on a picture is not as great a factor in its startup time as the complexity of the bitmap (in terms of shape
and color changes within the picture). A simple graphic with 200 datalinks will come up on a "slow" remote connection almost as quickly as
on a direct LAN-connected machine; a picture with 700 datalinks will take longer to start up, but should operate normally. Alarm Summaries,
which are not graphics-intensive, should open in almost the same amount of time as a direct connection.
For slow connection speeds, it is suggested that you do not open complex, color-intensive graphics. Such graphics may take several minutes to
open. If network or protocol errors occur, DeltaV Operate may hang or appear to be hung. The connected client will not be able to exit DeltaV
Operate or log off. The user will be able to disconnect using the X on the remote session title bar. The session will then have to be logged off
by someone with administrator privileges (using Task Manager or DeltaV Diagnostics) or it may be automatically logged off through use of
the "timeout" option. This option can be set by the administrator to automatically log off disconnected sessions after a set period of time.
Replacing the DeltaV Operate Opening Pictures
On slow connections, DeltaV Operate may take several minutes to open. (As noted above, enabling bitmap caching may significantly improve
subsequent access.) For applications where slower remote connections are common, it may be useful to replace the opening DeltaV Operate
pictures (DeltaV and Startup) with simpler versions (DeltaV.BLANK and Startup.BLANK). The replacement pictures are stored in the same
directory as the originals.
The DeltaV.grf and DeltaV.BLANK files reside in the following directory:
D:\DeltaV\DVData\Graphics-iFIX\Pic\
The Startup.grf and Startup.BLANK files reside in the following directory:
D:\DeltaV\DVData\Graphics-iFIX\Pic\Standard\
To preserve the original Startup.grf and DeltaV.grf files, rename them to new names, for example, Startup.original and DeltaV.original. Then
rename the "blank" pictures (Startup.BLANK and DeltaV.BLANK) to Startup.grf and DeltaV.grf. This procedure is detailed below.
To replace the DeltaV.grf and Startup.grf files
1. Exit DeltaV Operate on the Server and any connected remote sessions.
2. Log on to the Server machine as a privileged user.
3. Open Windows Explorer.
4. Go to the \DeltaV\DVData\Graphics-iFIX\Pic directory.
5. Select the DeltaV.grf file, right-click, and select Rename.
6. Type the new file name, DeltaV.original, and click OK. Click OK to the warning and/or confirmation messages.
7. Select DeltaV.BLANK, right-click, and select Rename.
8. Type the new name, DeltaV.grf, and click OK. Click OK to the warning and/or confirmation messages.
9. Repeat the process for Startup.grf (rename to Startup.original) and Startup.BLANK (rename to Startup.grf) under Pic/Standard.
10. Restart DeltaV Operate.
Accessing the Server's Windows Desktop
The Start button for the remote Windows desktop is in the lower left corner. If you have access to the Windows desktop and the window is not
maximized, you can maximize it or scroll to the lower left corner to see the Start button.
If you are running Windows XP, when the remote Windows desktop is full screen, the name of the Remote Client server appears in a
Windows title bar at the top center with several buttons. If the pushpin to the left of the name is selected, then the title bar remains displayed.
If it is not selected, the title bar automatically hides until you move your cursor to the top of the screen. (This is similar to what happens when
auto-hide is selected on the Windows taskbar Properties menu.)
You can size the remote window so that you can see both your own local desktop and the remote desktop at the same time. When the remote
window is less than full size, the title bar is displayed along the top of the window, along with the standard buttons for minimizing,
maximizing/restoring, or closing the window. You can also use Alt+Tab or the Windows task bar to switch back and forth between desktops.
The remote Windows desktop will appear as one application on the task bar, even though it may be running several programs. On a two
monitor workstation, the local desktop may be on one monitor and the remote desktop may be shown either full-screen (maximized) or in a
reduced size on the other monitor.
When you are on the Windows desktop, you have access to the same functions as if you were sitting at the server. From a DeltaV workstation,
you can access the server through a remote session and have copies of, for instance, Control Studio open on both your local desktop and the
remote desktop.
Using DeltaV Operate in Configure Mode
All DeltaV Operate data and configuration resources are shared on the server. Therefore, only one DeltaV Operate session per server can be in
graphics configuration mode at one time. If a picture is changed, all users on the server will see the results the next time that picture is called
up. (A download is not required for the changes to be available to all sessions on the server.)
The first user to enter DeltaV Operate configure mode has access to the picture configuration tools, such as the toolbars, and will be able to
create, edit, and save pictures. If an additional user attempts to load toolbars in configuration mode, an error message is displayed warning of
a sharing violation, and the toolbars will not be available. The user will enter the configuration mode, but will have limited configuration
ability with the toolbars unavailable.
To free up the DeltaV Operate configuration resources so that another user can use configure mode, the first user must exit DeltaV Operate
completely. It is not sufficient to simply close the picture or exit configure mode. The Remote Client session does not need to be disconnected
as long as DeltaV Operate is closed.
It is suggested that graphics configuration only be done on sessions that provide the ability to shut down and restart the DeltaV Operate
Workspace application. Full-time operator interface sessions should not be used for graphics configuration. To avoid the share conflicts, users
should consider designating a specific engineering session to be used for graphics configuration.
Using Multiple Monitors on a Remote Client Node
In general, you have all the normal DeltaV operating capabilities from a remote client that you would have at a LAN-connected Operator
Station. However, the following considerations apply when running DeltaV Operate in a multiple monitor configuration through a remote
connection:
 The remote client must be running version 6.0 of the Remote Desktop Connection Terminal Services Client.
Remote Desktop Connection 6.0 was introduced in Windows Vista and Windows Server 2008 operating system software. You can
download the Terminal Services Client 6.0 update for Windows Server 2003 and Windows XP by visiting the Microsoft Knowledge
Base article 925876 at www.microsoft.com.
 The multiple monitors must be configured in a horizontal orientation (1×2, 1×3, or 1×4).
 The total resolution of all monitors must be no greater than 4096×2048 pixels.
Therefore, with multiple widescreen monitors configured for a resolution of 1680×1050, you are limited to a 1×2 layout; with multiple
4:3 aspect ratio monitors configured for a resolution of 1280×1024, you are limited to a 1×3 or 1×2 layout; with multiple 4:3 aspect
ratio monitors configured for a resolution of 1024×768, you can have a 1×4, 1×3, or 1×2 layout.
 To have the desktop of the remote client span multiple monitors, run the Remote Desktop Connection program with the /span option by
typing the following at a command prompt: Mstsc /span.
Continuous Historian for Remote Clients
Each DeltaV Server has one Continuous Historian database that is shared by all remote users connected to that server. (The real-time and
historical data are available through the Process History View application.) The same limits apply on historical data collection and viewing
that apply on a workstation directly connected on the LAN.
Alarms and Events
When remote sessions are created in the DeltaV Explorer, one or more areas must be assigned to Alarms and Events under the remote session.
This assignment defines the plant areas for which alarms will be seen by a user using that session. Remote session users acknowledge/silence
their own alarms independent from other remote session users.
Screen Resolution
Set the screen resolution of the remote client to match the resolution on the server. If the resolutions are different, it is possible that not all the
server's screen elements will be accessible from the client.
Administrator Functions: Configuring Remote Client Sessions
Inside this topic
Administrators have a number of responsibilities, the most important of which are setting up the licensing, configuring the Remote Client
session objects, and managing the connections if there are problems.
Setting up Licensing
License requirements exist for both Microsoft Remote Terminal Server and DeltaV Remote Client. It is the administrator's responsibility to
determine the Microsoft licensing requirements. DeltaV licenses for remote use are based on the existing license structure for DeltaV
workstations. This section includes some considerations for setting up licenses for use by Remote Client nodes.
Licenses are assigned to Remote Client sessions, which are treated like Operator Stations with respect to DeltaV licensing:
 You can assign licenses to Remote Client sessions using the drag-and-drop method in DeltaV Explorer. (Licenses can also be assigned
by right-clicking the Remote Client session and selecting Licensing | Assign License and then selecting from the list of available
licenses.)
 You can review the licensing for a Remote Client session using the Properties dialog for the session. (In DeltaV Explorer, right-click
the session and choose Properties; then click the Licensing tab of the Properties dialog.)
 Remote Client sessions appear in the system-wide Licensing report.
Users may wish to license each Remote Client session at a different level, particularly if some sessions will be used exclusively for specific
tasks such as viewing or maintenance. For example, sessions may be licensed as
 a full operator interface session (An Operator Station license is needed with an appropriate DST size.)
 a maintenance session (Only a Maintenance Station license is needed.)
 a full professional session (a Professional Station license with up to 30,000 DSTs.)
Each Remote Client session must have an assigned plant area or a set of plant areas. This is done by assigning the plant areas to the Alarms
and Events object under a Remote Client session in the DeltaV Explorer. (The assignment can be done using the drag-and-drop method or by
right-clicking the Alarms and Events object and selecting Assign Area.)
Any Remote Client session using OPC licenses on an Operator Station (such as when running the DeltaV Excel Add-In) requires that the OPC
license be assigned to the host machine (the DeltaV machine acting as the Remote Terminal Server). This allows the license to be shared by
the remote sessions.

Configuring Remote Client Sessions
To set up the DeltaV Remote Client subsystem, the user creates objects called Remote Client sessions under the server workstation name in
DeltaV Explorer. Remote users (clients) then connect to the Remote Client server by logging in to one of the available sessions. The number
and type of sessions that can be set up are determined by the licenses purchased and the number of servers available.
Configuring Remote Client sessions in the DeltaV Explorer involves these procedures:
 Enabling the DeltaV Remote Client functionality on the Properties dialog for the Operator Station to be used as a server
 Adding the Remote Client session under the server workstation name
 Renaming the Remote Client session to make it easier to identify (optional)
 Assigning one or more licenses to the Remote Client session
 Assigning plant areas to the Remote Client session
 Defining a reserved list of users or nodes (optional)
 Downloading the workstation's Setup Data

Naming Conventions for Remote Client Sessions
New sessions are automatically named workstationSESSIONn where workstation is the name of the server and n is the next session number
available. You can change this to a more meaningful name. The name may be up to 16 characters and must contain at least one alphabetic
character. Names may contain any alphanumeric characters, $, - and _. A session name may not be the same as a name already in use in the
DeltaV system. The session names appear in the DeltaV logon dialog so that users can select the session to which they want to connect.

Enabling DeltaV Remote Client
ProfessionalPLUS workstations have Remote Client functionality enabled by default. To enable DeltaV Remote client on an Operator Station,
the node must be running the server version of the operating system.
To enable DeltaV Remote Client on an Operator Station to be used as a Remote Client server
1. Open DeltaV Explorer.
2. Navigate to the Control Network and select the Operator Station for which you want to enable Remote Client.
3. Click the right mouse button and select Properties from the context menu.
4. Select the check box next to Enable Remote Client Functionality. The Remote Client subsystem is added under the workstation.

Adding a Remote Client Session
Remote Client sessions need to be added and configured under the Remote Client subsystem in the DeltaV Explorer.
To add a Remote Client session
1. In DeltaV Explorer, select the workstation name for which you want to create a Remote Client session.
2. Click the + sign next to the workstation name, if necessary, to expand its contents.
3. Select Remote Client, click the right mouse button, and select New Remote Client Session.
4. In the Remote Client Session Properties dialog box, give the session a meaningful name that will help users identify it, especially if it is
to be restricted to certain users.
5. Include a description to further identify any restrictions on the session's use (such as the plant areas or licenses that are assigned to it ).
The Participate in Global Horn Acknowledge Group field is selected by default. It is recommended that this field remain selected.
This allows the remote session user to acknowledge alarms that sound for the areas to which they have access.

Assigning a License to a New Remote Client Session
Each Remote Client session must have at least one DeltaV license assigned to it. License types are the standard DeltaV licenses. The license
or licenses assigned should be appropriate for the type of user/node (such as an operator or engineer) that will be logging in to the session.
There are two ways to assign licenses:
 using the drag-and-drop method in the DeltaV Explorer to drag a license from System Configuration | Setup | Licenses to the
appropriate Remote Client session under the server's Remote Clients subsystem
 selecting Assign License from the context menu for the Remote Client session name. This method is described in the following
procedure
To assign a DeltaV license to a Remote Client session
1. Right-click the Remote Client session name in the DeltaV Explorer.
2. Select Licensing | Assign License. A dialog box opens that displays valid licenses that can be assigned to this session.
3. Browse and select the license.
To view the assigned license features, open the Properties dialog box for the Remote Client session and click the Licensing tab. To see more
information on any of the license features, select the feature and then click the License Details button.

Assigning Plant Areas to Alarms and Events
To enforce DST license restrictions, each Remote Client session must have an area or set of areas assigned to it. This is done by assigning the
areas to the Alarms and Events object under a Remote Client session in the DeltaV Explorer. (The assignment can be done using the drag-and-
drop method or by right-clicking the Alarms and Events object and selecting Assign Area.) The Alarms and Events object under a Remote
Client Session object does not support the Event Chronicle database and therefore does not have an associated Properties dialog box.
Note The assignment of an area to Alarms and Events for a Remote Client session does not limit the areas to which the user has access; the
user's span of control is determined by User Manager settings. Rather, the area assignment defines which operator alarms will be seen by a
user using that terminal session.

Downloading the Workstation's Setup Data
After you have set up the Remote Client Sessions, assigned the licenses and areas, and set up the reserved list of users and nodes, you need to
download the workstation's Setup Data for the changes to take effect. In the DeltaV Explorer, right-click the remote server workstation, select
Download | Changed Setup Data or Download | Setup Data.
Administrator Functions: Adding Users
Inside this topic
The Administrator must define which users have permission to log into a Remote Client server. In addition, the Administrator can limit
specific sessions to a defined list of users or nodes.

Granting Login Permission
For security reasons, the Administrator needs to grant DeltaV users permission to log in to a Remote Client server. This is done through the
DeltaV User Manager.
To grant DeltaV users permission to log in to the server
1. Open the DeltaV User Manager application.
2. Select a user name, right-click, and select Properties from the context menu.
3. In the Properties dialog box, under Account Type, select the check box next to Allow Terminal Server Logon.
4. Click OK.

Defining the Reserved List of Users or Nodes
The Administrator setting up the Remote Client session can specify that the session be made available to a reserved list of user names or node
names. The same user/node names may appear on the reserved lists for more than one remote session.
Reserved lists allow connection according to the following rules:
 If the reserved list has only one name, then only that user/node can connect through that remote session.
 If there are multiple names in the list for a particular session, then access is available to those users/nodes on a first-come, first-served
basis.
 If there is no reserved list set up, then any DeltaV user/node will be allowed to connect under that remote session.
Even though a user is able to begin the process of connecting to a Remote Client server from a node on the reserved node list, the user must
still log in under a valid DeltaV user ID and password for the connection to be completed. Usage privileges are still as defined in the DeltaV
User Manager.
To add names to the Reserved for User (or Node) List
1. Open DeltaV Explorer.
2. Navigate to the Remote Client server workstation.
3. Select the Remote Client session for which you want to define a reserved user list, click the right mouse button, and select Properties
from the context menu.
4. Select the Reserved for User List tab on the Properties dialog box.
5. Click Add to open a dialog box where you can enter the user name or select the name from a pull-down list of available user names.
You can also use this dialog box to delete user names from the reserved list.
6. Similarly, if you wish to reserve the remote session for specific nodes, click the tab Reserved for Node List. Then click Add to open a
dialog box where you can enter the node name or select the name from a pull-down list of all the node names in the local network.
Administrator Functions: Managing Connections
Inside this topic
Some administrator functions with respect to managing remote connections can be accomplished through DeltaV Diagnostics. Most can also
be accomplished through several Microsoft Windows applications: Terminal Services Configuration, Terminal Services Manager, Terminal
Server Licensing, and Task Manager applications. It is recommended that administrators become familiar with the Help system
documentation for the Microsoft applications.

DeltaV Diagnostics for Remote Client
In the DeltaV Diagnostics system, you can access information about users who are logged on through remote sessions. Those with sufficient
privileges can send messages to other users and disconnect or log off other users. To access the diagnostics for remote clients, click Start |
DeltaV | Engineering | Remote Clients. (You can also access the remote client diagnostics from DeltaV Diagnostics by selecting the
workstation that is the remote client server, right-clicking, and selecting Remote Client Diagnostics.) The Remote Clients box appears, as
shown below
As an administrator with the proper access privileges, you can select a remote session, click the right mouse button, and choose from the
following options:
 Send message
 Disconnect
 Log Off
The fields in the Remote Clients box are as follows:
ID - A numerical identifier. An ID with a very high number, such as 65536 in the above example, is used for Windows server listener
sessions that wait for requests for new client connections. No user is logged on to a listener session.
DeltaV Session - The session name, as identified in the DeltaV Explorer hierarchy.
DeltaV User Name - The name of the DeltaV User logged on to the session.
XP User Name - The Windows user name of the user logged on to the session.
Client Name - The name of the remote node logged on to the session.
Connection state - One of 10 possible states:
Active - A user is logged on to the server
Connected - The server is connected to the client.
Connecting - The server is in the process of connecting to the client.
Shadow Connection - The server is shadowing another
Disconnected - The sever is active but the client is disconnected.
Idle - The server is waiting for a client to connect.
Listening - The server is listening for a connection.
Resetting WinStation - The server is being reset.
WinStation Error - The server is down due to an error.
Initializing - The server is initializing.
Client IP Address - The IP address of the client node

Disconnecting Users
Typically, the Administrator will send a request (via an online message) to the current session user to log off and disconnect before initiating a
forced disconnect. Circumstances when an Administrator may need to disconnect remote session users include the following:
 Another user with a more pressing need requires access and there are no terminal sessions available
 A major system maintenance task is to be performed
Administrators have 3 options for logging off or disconnecting users:
 Remote Client Diagnostics
 Windows Task Manager
 Terminal Services Manager
For more information on logging off and disconnecting, refer to Starting and Ending a Remote Client Session.

Temporary Blocking of New Connections
Sometimes it is necessary for the administrator to prevent remote users from initiating a session. This may be the case when system
maintenance is being performed and it is necessary to keep all non-critical usage to a minimum.
To temporarily block new connections
1. From the Windows task bar, select Start | Control Panel | System.
2. On the System Properties dialog, click the Remote tab.
3. Clear the checkbox for Enable Remote Desktop on this computer.
4. Click OK.

Limiting Time for Idle, Active, or Disconnected Sessions
As an Administrator, you can set time limits for individual users for limiting active sessions and idle sessions, and for ending a disconnected
session. To set these preferences, select Start | Settings | Control Panel | Administrative Tools | Computer Management. Under Local
Users and Groups, select Users, and double-click the user name in the right-hand pane. The Sessions tab on the user Properties dialog
provides options for setting time limits and for allowing reconnection. It is not recommended that you restrict active sessions unless you are
likely to have more remote users than remote sessions available. In that case, you may want to increase the number of Remote Client servers.
Contact your Emerson representative for information.
You can also override individual user settings for these options using Terminal Services Configuration. To access the RDP-Tcp Properties
dialog, click Start | Settings | Control Panel | Administrative Tools | Terminal Services Configuration and double-click the RDP-Tcp
connection. On the RDP-Tcp Properties dialog, select the Sessions tab, click Override User settings, and use the dropdown boxes to select the
preferred time options for the following:
 End a disconnected session
 Active session limit
 Idle session limit
Disconnecting a Session vs. Ending a Session
You can decide whether the session should be disconnected or ended when the session limit is reached or the connection is broken. When you
specify that a client session is to be disconnected, the client can reconnect if needed (and if reconnection is allowed). When you specify that a
client session is to be ended, the session is reset and cannot be reconnected. The remote user would need to open a new client session if one is
available. It is not recommended that you set these limits unless you have more remote users than remote sessions available.
How DeltaV Ends Disconnected and Idle Sessions
DeltaV handles ending a disconnected session slightly differently than ending an idle session, as described below. In both cases the the time
limit to end the disconnected or idle session is 30 minutes:
 Disconnected session - Approximately 2 minutes before the 30-minute time limit is reached, DeltaV applications running in the session
exit. The session ends in 30 minutes.
 Idle session - At the 30-minute time limit, DeltaV applications running in the session exit. The session ends 2 minutes after the time
limit.
The example below shows how these options might be configured. Note that the option to Allow reconnection defaults to "From any client"
and the option to override user settings is grayed out (not available). (The other option, to allow reconnection "From previous client" is
supported by Windows Terminal Services only for Citrix ICA-based clients that provide a serial number when connecting.)
As an Administrator, you may want to set up guidelines for ending disconnected sessions and to inform remote users of these time limits. For
instance, you might want to allow Engineering sessions to be reconnected within 30 minutes after a session connection is broken so that work
in progress is not lost. Since Operator sessions do not usually require saving work in progress, you may choose to end disconnected Operator
sessions after only 5 minutes.
Security Considerations
The DeltaV Remote Client application uses the standard Microsoft security along with normal DeltaV security. Securing the Remote Client
server from unauthorized access is primarily the responsibility of the administrator. When working at a remote site, it is important that the
individual user employ additional security measures as necessary to prevent unauthorized access. When remote clients are PCs on the plant
LAN, it is recommended that a router be installed between the DeltaV system and the plant LAN to prevent unnecessary plant LAN traffic
from getting to the server.
For more information on DeltaV security-related topics, refer to the following:
DeltaV FlexLock
DeltaV User Manager and DeltaV Security
User Manager Application
Security Recommendations Summary
Remote Workstations
Inside this topic
The DeltaV system supports connections to remote networks that are not part of the standard DeltaV control network. The workstations on a
remote network provide most of the functions of a workstation on the control network.
DeltaV ProfessionalPLUS workstations and Application Stations can be Remote Access Services (RAS) servers for remote networks. Each of
these workstation types have a Remote Network subsystem. You enable the Remote Network subsystem and add remote workstations to the
subsystem using the DeltaV Explorer. Refer to Explorer help for more information.

Remote Workstation Types
There are two types of remote workstation: the Remote Application Station and the Remote Operator Station. Remote Application Stations
can only connect to an Application Station. Remote Operator Stations can connect to the DeltaV System through either the ProfessionalPLUS
workstation or an Application Station. Remote Application Stations also contain a Remote Network subsystem allowing remote workstations
to be added to it.
The ProfessionalPLUS workstation supports a remote network with two Remote Operator Stations but does not support Remote Application
Stations. Application Stations support a network of as many as ten remote workstations. All ten of these remote workstations can be Remote
Operator Stations but only one can be Remote Application Station. Remote Application Stations support a remote network of as many as ten
Remote Operator Stations. The Remote Application Station network does not support another Remote Application Station.
Remote workstations can be licensed as Professional Stations to provide engineering capability at the remote workstation. If required, every
remote workstation can be licensed as a Professional Station. The ProfessionalPLUS workstation allows any of these remote workstations to
access the database. The ProfessionalPLUS computer hardware determines the number of concurrent engineering connections allowed.

Remote Applications Support
Remote workstations support the following DeltaV applications:
 DeltaV Operator Graphics
 Batch Operator Interface
 History View (Event Chronicle, Continuous Historian, and Batch History)
 Security related applications (FlexLock and DeltaV Logon)
 Diagnostics
 Excel
Note A remote workstation must have an Ethernet connection to the Batch Executive workstation which the remote workstation needs to
connect to. This can best be achieved by setting up the Batch Executive workstation with two additional Network Interface Cards (NIC) for
Remote Primary and Secondary networks. It is recommended that the plant LAN connection not be used for this purpose.
The following Engineering Tools applications are supported on remote workstations:
Note A remote workstation must have an Ethernet connection to the ProfessionalPLUS workstation to run the Engineering Tools
applications. This can best be achieved by setting up the ProfessionalPLUS with two additional Network Interface Cards (NIC) for Remote
Primary and Secondary networks. It is recommended that the plant LAN connection not be used for this purpose.
 DeltaV Explorer, including FOUNDATION fieldbus support.
 Control Studio
 Recipe Studio
 Advanced Control Applications – DeltaV Predict and DeltaV InSight (including Tune with InSight and Inspect with InSight)
 Database Administrator
 User Manager
Remote Operator Stations have the following three subsystems:
1. Operator - This subsystem provides the means to configure the operations scope (for Operation license enforcement) for the Remote
Operator Station. Remote Operator Stations will accept standard workstation licenses.
2. Continuous Historian – This subsystem provides the means to configure historical values collected on the remote workstation.
3. Alarms and Events – This subsystem provides a means to configure which Areas the workstation should participate in. However, a
remote system cannot collect alarm and event history on a Remote Operator Station.
Remote Application Stations have the following subsystems:
1. Continuous Historian – This subsystem provides the means to configure historical values collected on the remote workstation.
2. Alarms and Events – This subsystem provides a means to configure which Areas the workstation should participate in and, optionally,
can collect alarm and event information. If the Enable option is checked, the Remote Application Station stores alarms and events into a
local database.
3. Remote Network – This is a nested remote network. Nodes assigned to this network route their real-time communications through this
Application Station.
A remote network on a remote server is used when using satellites. This reduces the amount of slow message traffic sent to the control system.
Remote Network Topology

Licensing
Remote Application Stations and Remote Operator Stations accept the same licenses and upgrades as local workstations. Enforcement rules
are the same for both local and remote nodes.
Remote Installation
Installing DeltaV software on a remote workstation is basically the same as installing DeltaV software on a local workstation. For example, if
your ProfessionalPLUS will act as a server for remote workstations:
1. Execute the normal DeltaV Setup program on the ProfessionalPLUS workstation and the remote workstation.
2. Execute DeltaV Workstation Configuration on the ProfessionalPLUS. Check the Workstation will be a Remote Access Server box
indicating that this machine will be a remote server.
3. Using DeltaV Explorer, enable the remote network subsystem on the ProfessionalPLUS.
4. Add the remote workstations to the remote network.
5. Export the Workstation Configuration data to removable media or a network location that can be accessed from the workstation to be
configured.
6. Execute the DeltaV Workstation Configuration program on the remote workstations to complete the installation and configuration
process.
7. When the DeltaV Workstation Configuration program asks for it, browse to the Workstation Configuration data you saved in step 5 to
set up the remote workstation for remote access to the DeltaV System.
Note If you have already installed the DeltaV software without designating a remote server, you do not need to re-install the software. You
can designate a workstation as a remote server by running DeltaV Workstation Configuration and checking the Workstation will be a Remote
Access Server box.
Note You must have the same DeltaVAdmin password on the remote workstations and on the machines in the DeltaV System. Use
ServPwd.exe to change this password.
For more detailed information about these steps, see DeltaV Workstation Configuration and DeltaV Explorer Help.
IP Addresses
DeltaV software assigns IP addresses to all the workstations in the control network. Remote workstations typically will already have an IP
address to enable them to connect to a plant or office LAN. When you install DeltaV software on a remote workstation, the software finds the
available IP addresses and network adapters for that machine. You must select from this list of available choices as the DeltaV software does
not assign new addresses to remote workstations. DeltaV software requires that a permanent IP address be assigned to the machine, DHCP is
not supported.
Remote Workstation Diagnostics
Inside this topic
Diagnostics supports the Remote Network subsystem for all the normal DeltaV workstation types. Diagnostics also displays a list of all
Remote Operator Stations connected to the DeltaV Workstations for remote access.
Diagnostics Explorer View of the Remote Operation Network

Remote Operation Network Diagnostics
The following diagnostic attributes are supported for the Remote Operation Network:
 OInteg- Overall integrity of the remote network. The following can cause Bad OInteg on the remote network:
 Any remote workstation connection has a bad primary or secondary communication link
 Any remote workstation connected to the Remote Access Services (RAS) server cannot communicate with the RAS server. (The
remote workstation must have monitor integrity enabled.)
 SwRev (Software Revision) - Software revision of the selected component.
 Conn_Integ (Connection Integrity) - Indicates if the RAS server can successfully communicate with the remote workstations that
have been configured on the remote network. This value is Good if the RAS server can communicate with all the remote workstations
and Bad if the RAS server cannot communicate with at least one workstation.
Note A configuration option for remote workstations is Monitor Integrity. When this option is selected, Diagnostics reports an integrity
error for both the Remote Network subsystem and the remote workstation if the remote workstation is not connected and not
communicating with the RAS server. If this option is not selected, Diagnostics will not report an integrity error.
 Pri_CInteg (Primary Communications Integrity) - The overall integrity of communication on the remote network's primary
communication link. Bad if any remote connection has a bad primary communications link. Good if all remote connections have good
primary communications.
 Pri_ConGood (Primary Connections Good) - The number of good remote communication connections on the primary remote
network.
 Pri_ConBad (Primary Connections Bad) - The number of bad remote communication connections on the primary remote network.
 Sec_CInteg (Secondary Communications Integrity) - The overall integrity of communication on the remote network's secondary
communication link. Bad if any remote connection has a bad secondary communications link. Good if all remote connections have good
secondary communications.
 Sec_ConGood (Secondary Connections Good) - The number of good remote communication connections on the secondary remote
network.
 Sec_ConBad (Secondary Connections Bad) - The number of bad remote communication connections on the secondary remote
network.
 AvailCon (Available Connections) - The number of remote connections that are still available to other remote workstations that are
not configured to be connected through this RAS server.
 Enabled - Indicates if the remote network is enabled or not enabled. The remote network must be enabled to allow remote workstations
to connect to the RAS server and access runtime data. Yes means the remote network is enabled; No means the remote network is not
enabled.
 NetType (Network Type) - The type of remote network configured. The only value currently supported for network type is "Remote
Network."
 Licensed - Indicates of this workstation has a remote network license. Yes indicates a license and No indicates no license. The remote
network must be licensed before any remote connections are allowed.
 Pri_MCastCount (Primary Multicast Received Counter) - The number of multicast messages received on the primary remote
network.
 Sec_MCastCount (Secondary Multicast Received Counter) - The number of multicast messages received on the secondary remote
network.

Remote Operator Station Diagnostics
The following diagnostic parameters are supported for each Remote Node connected to the local workstation:
 OInteg (Overall Integrity) - Overall integrity of the remote workstation's communication with its RAS server. Good if the remote
workstation can successfully communicate with the RAS server. (If the workstation is configured for redundant communications, then
both the primary and secondary remote communication links must be Good.) Bad if either the primary or secondary remote
communications link are bad.
 Pri_CInteg (Primary Communications Integrity) - The integrity for the remote primary communications link on the remote
workstation. Good if the RAS server can communicate with this remote workstation over the primary link. Bad if the RAS server
cannot communicate with this remote workstation over the primary link.
 CStatus (Communications Status) - The remote workstation's communication status. Possible values are:
Good - all communication links are good
Bad - at least one communication link is bad
Not Connected - the remote workstation is no longer connected to the remote network
 TimeOut - The message acknowledgement timeout value (in milliseconds) for communications with this remote workstation.
 Retry - Current number of retries being used for communications with this remote node.
You must use the full path to a parameter on the Remote Operator Station to access the value of that parameter. Path is specified as:
Local Server Name/Remnet/Remote Station Name/parameter
(where Remnet is the required subsystem name)
For example, to access the value of OINTEG on a Remote Operator Station called Cosmos that uses the local server Galileo, the path is:
Galileo/Remnet/Cosmos/OINTEG
Tip The easiest way to find a parameter path is to right-click the parameter in the Contents pane in DeltaV Diagnostics and select Properties.
An exception is the channel value, which cannot be accessed directly from Operator Graphics. You must assign the channel value to a module
parameter in order to use it on graphics.

Configuring the Remote Operator Station to view event history
In order to view event history from a Remote Operator Station, you must use another DeltaV workstation as the default events data server. To
do this, configure the Process History View application to connect to a workstation where the DeltaV Alarms and Events subsystem is
enabled. You can configure the defaulthost value in Process History View by using one of the following methods:
 Use the File | Set Default Data Servers command to open the Default Data Servers dialog box, and then click the Event Chronicle tab
 For a specific Events or E+Charts page, use the Events | Configure Events command to open the Configure Event Chronicle dialog box
Remote Access Control Application
Inside this topic
The DeltaV Remote Access Control application allows a secondary or backup remote network connection such that when the primary or
preferred workstation node providing remote access to the runtime data fails, the system can switch over and use the secondary or backup
workstation for the remote network connection.

Ad Hoc Remote Connections
When you create a remote workstation in DeltaV Explorer and install DeltaV software on the remote workstation, the system establishes what
is referred to as a permanent connection between the remote workstation and the particular server that you specified. You can also connect a
remote workstation to other potential servers on the control network. The Remote Access Control application enables you to disconnect from
the permanent server and connect to any other potential server on the DeltaV Control Network. Potential servers are ProfessionalPLUS
workstation, Application Stations and Remote Application Stations that:
 were designated as remote servers during the DeltaV software installation
 have their Remote Network subsystems enabled through the DeltaV Explorer
If you want backup servers for your remote workstations, make sure that you install one or more of your workstations as remote servers and
enable the remote networks on these machines.
Note If you have already installed the DeltaV software without designating a remote server, you do not need to re-install the software. You
can designate a workstation as a remote server by running DeltaV Workstation Configuration and checking the Workstation will be a Remote
Access Server box.

Switching Remote Network Connections
Once you have determined that the primary server has failed, open the Remote Access Control application and select the Switch Remote
Access Server option. This can be performed from the DeltaV shortcuts (menus) in Windows or it can be launched from FIX for those
operators who do not have access to the DeltaV shortcuts (menus).
At this point, the Remote Access Control application builds a list of all the Remote Data Servers on the DeltaV System and the number of
available remote connections. The list of servers and their number of available connections is displayed.
Select the server that you want to connect to the DeltaV System through. Once you select a server node, all communications are switched
from the old server node to the new server node. The current DeltaV Server name and IP addresses are updated in the Registry on the remote
workstation.

Switching DeltaV Systems
To switch DeltaV systems, select the Switch DeltaV Systems option from the Remote Access Control application. This shuts down the DeltaV
services while the registry entries are modified to point to the new system. Afterward, the DeltaV services are restarted.

Remote Access Control Installation
In order to have a single remote workstation access two different DeltaV Systems, the remote workstation must be configured in both DeltaV
Systems. This means creating the remote workstation and then assigning it to a workstation's Remote Network subsystem on each system. The
remote workstation should be created with the same name on both systems. Export the workstation configuration file from the first DeltaV
System. The DeltaV System can then be installed on the remote workstation and the DeltaV Workstation Configuration program can be
executed using the exported workstation configuration file to set up access to the first DeltaV System.
To set up access to the second DeltaV System, export the workstation configuration file from the second DeltaV System. Select Add/Revise
DeltaV System Access from the DeltaV Remote Access Control application. The application will read the proper system information off the
workstation configuration disk and create the appropriate registry entries needed to allow the remote workstation to access the second DeltaV
System.
Remote System Security
The DeltaV Server and the remote workstation runtime databases must be synchronized for the DeltaV system to work properly. To keep the
databases synchronized, download the workstation every time you make changes to user accounts or user security configuration. Refer to the
Keeping Security Current topic for more details. To avoid conflicting settings and keep the runtime databases synchronized, perform the
administration of DeltaV accounts on the DeltaV server only. A Windows user who is logged on must have a DeltaV account on the remote
workstation in order to access any DeltaV application. If this Windows user does not have a valid DeltaV account on the server, all DeltaV
logon attempts will fail, even if the user has a DeltaV account on the remote workstation. Directory and file security should be implemented
on the server (whether in a domain or workgroup) to protect other resources on the DeltaV server (for example, drives, directories and files,
and so on). The DeltaV system requires share access to the following directories:
 C:\DeltaV\DVData
 C:\DeltaV\DVData\Databases
 C:\DeltaV\DVData\Databases\DeltaV_System
Remote System Configuration Scenarios
Inside this topic
There are seven different ways a remote system can be configured using workgroups and/or domains. Logon and setup requirements for each
configuration are discussed in the following scenarios.

Scenario 1: Remote Workstation Is in a Workgroup and DeltaV Server Is in a Workgroup
Logging on to the DeltaV System
In order to connect to the database server from the remote workstation in a workgroup to workgroup environment, the following must apply:
 The Windows user on the remote workstation must have a Windows account on both the remote workstation and the DeltaV server with
the same username and password.
 The Windows user on the remote workstation must have a DeltaV account on both the remote workstation and the DeltaV server.
 The DeltaV user on the remote workstation must have both a DeltaV account and a Windows account on the server with the same
username and password as on the remote system.
 The DeltaV user on the remote workstation must have a Windows account on the remote system.
Setting up a Workgroup to Workgroup Configuration
1. Create the Windows user account on the remote workstation using Windows User Manager:
 Create the Windows user account on the remote workstation. Refer to your Windows documentation for more details.
 Add the user to the appropriate DeltaV Group (DeltaV, DeltaV Access, DeltaV Admin). Refer to the DeltaV User Manager and
DeltaV Security topic for more information on DeltaV groups.
2. Create the user accounts on DeltaV server using DeltaV User Manager:
 Create the Windows and DeltaV user accounts. Refer to the Adding a New User topic for more information.
 Use the same username and password from the remote account for the DeltaV and Windows server accounts.

Scenario 2: Remote Workstation Is in a Workgroup and DeltaV Server Is in a Domain
In order to connect to the database server from the remote workstation in a workgroup to domain environment, the following must apply:
 The DeltaV user on the remote workstation must have a DeltaV account and a Windows account on the server with the same username
and password as on the remote system.
Setting up a Remote System in a Workgroup to Domain Configuration
 Create the Windows user account on the remote workstation. Refer to your Windows documentation for details.
 Add the user to the appropriate DeltaV Group (DeltaV, DeltaV Access, DeltaV Admin). Refer to the DeltaV User Accounts and
Groups topic for more information on DeltaV groups.
2. Create the user accounts on the DeltaV server using DeltaV User Manager:
 Create the Windows and DeltaV user accounts. Refer to the Adding a New User topic for more information.
 Use the same username and password for the DeltaV server and Windows server accounts as on the remote account.

Scenario 3: Remote Workstation Is in a Domain and DeltaV Server Is in a Workgroup
In order to connect to the database server from the remote workstation in a domain to workgroup environment, the following must apply:
Setting Up A Remote System in a Domain to Workgroup Configuration
Since the remote workstation is on a domain, users can include local users and domain users. An individual can have both a local account and
a domain account on the workstation. (Having both accounts is typical for an engineer who uses the workstation as a personal PC.) Most users
should only have a domain account. This simplifies the administration of user accounts.
 Domain users are not added directly as new users. They are given access to the machine and resources by being added to a local
group on the workstation. Refer to the Domain section of your Windows documentation for information regarding how to add
domain members to workstation groups.
 Add the domain user to the appropriate DeltaV group (DeltaV, DeltaV Access, DeltaVAdmin). Refer to the DeltaV User
Accounts and Groups topic for more information on DeltaV groups.
 Create the Windows and DeltaV user accounts on the server. Refer to the Adding a New User topic for more information.
 Use the same username and password for these accounts as on the remote account.

Scenario 4: Two Domains with No Trust Between Domains
In order to connect to the database server from the remote workstation in a two-domain, no trust environment, the following must apply:
Setting up a Remote System in a Two Domain, No-Trust Configuration
should only have a domain account. This simplifies the administration of user accounts.
Domain users are not added directly as new users. They are given access to the machine and resources by being added to a local
group on the workstation. Refer to the Domain section in your Windows documentation for information regarding how to add
domain members to workstation groups.
 Create the Windows server and DeltaV user accounts. Refer to the Adding a New User topic for more information.
 Use the same username and password for these accounts as on the remote account.

Scenario 5: Two Domains, One-Way Trust Configuration (DV Server Is Trusting Domain)
 In order for a domain user to connect to the DeltaV database server from the remote workstation in a one-way trust domain
environment, the following must apply:
 The Windows user on the remote workstation must have a DeltaV account on the remote system.
 The Windows user on the remote workstation must have a DeltaV account on the server.
 The DeltaV user on the remote workstation must have a DeltaV account on the server.
 For domain logons, the user does not need to have a Windows account on the remote workstation.
 In order for a non-domain user to connect to the DeltaV database server from the remote workstation in a one-way trust domain
environment, the followint must apply:
 The Windows user on the remote workstation must have a Windows account on both the remote workstation and the DeltaV
server with the same username and password.
 The Windows user on the remote workstation must have a DeltaV account on both the remote workstation and the DeltaV server.
 The DeltaV user on the remote workstation must have a DeltaV account and a Windows account on the server with the same
username and password as on the remote system.
 The DeltaV user on the remote workstation must have a Windows account on the remote system.
Setting up a Remote System in a Two Domain, One-Way Trust Configuration (DV Server is Trusting Domain)
should only have a domain account. This simplifies the administration of user accounts
1. Create the domain Windows user account on the remote workstation using Windows User Manager:
 Domain users are not added directly as new users. They are given access to the machine and resources by being added to a local
group on the workstation. Refer to the Domain section in your Windows documentation for details on adding domain members to
a workstation group.
 Create a DeltaV account for the domain user. Do not enter a password for the DeltaV account. (This assumes that the user already
has a domain account. If you still need to create the domain user account, refer to the Domain section of your Windows
documentation for more information.)

Scenario 6: Two Domains, One-way Trust Configuration (DeltaV Server Is Trusted Domain)
In a trust relationship where the DeltaV server is the trusted domain, users on the DeltaV domain can be allowed to access resources on the
plant domain. However, this is not relevant for this particular scenario. Having the plant domain trust the DeltaV domain does not affect the
users accessing DeltaV remotely and yields the same behavior as Scenario 4.

Scenario 7: Two Domains, Two-Way Trust Configuration
This yields the same behavior as Scenario 5.
DeltaV Database Overview
Inside this topic
This section describes the following concepts:
 DeltaV Database
 Database Access
 Database Purpose and Function
 Database Size and Structure
 Data Types
 Database Administration

DeltaV Databases
DeltaV configuration data is stored in a database in one of the workstations in the system. This database is referred to as the persistent
database. A system can have several databases, but only one database can be active within the system at a time.
A database includes everything you can see from the DeltaV Explorer. This includes:
 The library of control modules and function blocks included with the system
 The modules you create
 The workstations and controllers in the system (although they can all be viewed in Explorer, they might not all be physically connected
to the network)
 System-wide data, such as named sets and alarm preferences
Displays are not stored in the database; however, the modules in the database reference the displays. Events are not part of the database. For
information on managing the DeltaV database, refer to the Database Administrator Tools topic. Each Event Chronicle is a separate database of
events.

Database Access
Many DeltaV applications access the active database to some degree. When you add a new module through Control Studio, for example, the
module is added to the active database. The DeltaV Explorer provides the widest and most detailed view of a database. It also provides the
fastest means to populate your database.

Purpose/Function
The DeltaV database contains all the information about your control strategies and your control network (nodes, workstations, I/O channels,
and so on). The DeltaV system downloads with a template database for you. This makes getting the DeltaV system up and running easy.
Control Studio, DeltaV Explorer and Configuration Assistant modify the database as you create or modify your control strategy. All changes
to the database are made through the DeltaV interface: the DeltaV Explorer, Control Studio, Database Administrator, or Configuration
Assistant.
Database Administrator takes the basic database management tasks and makes them easier to do. With Database Administrator, you can
perform the following tasks:
 Create a new, empty database.
 Copy an existing database.
 Delete a database.
 Move a database to a new machine.
 Back up an existing database.
 Restore a database from a backup.
There are additional database management tasks that are important for keeping the DeltaV system running smoothly and efficiently. The
Database Administrator gives you the tools to perform these tasks.
 Monitor transaction locks on a database.
 Monitor application locks on the DeltaV applications.
 Set the active database for that workstation.
 Set the database host for all workstations to access.
 Register/deregister the database.
 Synchronize all the workstations for the same active database.
The Database Administrator Tools is not intended for making any changes to your control strategy, except in the creation or deletion of a
database. The Database Administrator Tools are for managing the DeltaV database that makes up your control strategy.

Structure and Size
The DeltaV system uses ObjectivityTM as the database engine. The structure of the DeltaV database is an Objectivity created, object-oriented
structure. This structure allows the DeltaV applications to access only those parts of the database that are needed for any particular operation.
It is a modular approach to data storage. One copy is used by all functions. You enter the information once, and all the functions that need the
data access it from the same database.
Note Do not attempt to edit the DeltaV database files directly. Always use the DeltaV interface for any changes to the data files.
The DeltaV system ships with a template database. The empty database resides in the \\DeltaV\DVData\Databases folder. You can use this
database as is or modify it to match your control strategy and plant configuration. As you add modules and modify the configuration in the
DeltaV system, the size of the database changes.
To check the size of a DeltaV database, use the Windows Explorer on the host machine:
1. Expand the \\DeltaV\DVData folder.
2. Highlight the Database folder by clicking it once.
3. Click the right mouse button.
4. Click Properties from the menu.
5. On the General Tab, you see the size of the entire Databases folder.
To see the size of the individual databases you have created, start Windows Explorer:
1. Expand the \\DeltaV\DVData\Databases folder.
2. Highlight the folder with the name of the database you are checking.
3. Click the right mouse button.
4. Click Properties from the menu.
5. On the General Tab you see the size of that individual database.

Type of Data Stored
A database includes everything you can see from the DeltaV Explorer. This includes:
 the library of control modules and function blocks included with the system
 the modules you create
 the workstations and controllers (I/O) in the system (Although they can all be viewed in Explorer, they might not all be physically
connected to the network.)
 system-wide configuration data, such as named sets and alarm preferences

When to Use the Database Administrator Tools
The Database Administrator is a set of tools you use periodically to manage your DeltaV databases. You might not use every tool every day.
In fact, some tools are used only if a problem occurs.
Some examples of when you use the Database Administrator tool are as follows:
 when a database error occurs
 when combining two separate DeltaV systems into one with a single host machine.
 when adding new workstations to synchronize all nodes on the network
These are just examples of when you can use the Database Administrator tools. Each tool is described in its own section to better help you
determine when to use the tools.

Who Uses the Database Administrator Tools?
The Database Administrator tools are used only by the person designated as the DeltaV administrator. That person must have administrator
access through Windows to the ProfessionalPLUS computer's hard drive. The administrator must also have the appropriate DeltaV security
access to the Database Administrator tools.
Refer to the Developing a Security Scheme topic and the DeltaV User Manager help system for information on setting up a user with access
rights.
Refer to the Windows help system or printed documentation for information about setting up a Windows user.
Configuration and Graphics Backup and Recovery
Inside this topic
Configuration data, operator displays and supporting files and data represent a large investment. To protect this investment, it is important to
develop processes for backing up and restoring this data. This section provides procedures for backing up your system data.

Backing Up the Configuration Database
There are two methods of backing up the configuration database:
 The Backup and Restore tool in the DeltaV Database Administration application
 The Daily Export tool in the DeltaV Database Administration application
The Backup and Restore tool is a key component of a plant's backup and recovery processes. The Backup and Restore tool restores the
database to the same state it was in before the backup. You run the Backup and Restore manually from the Database Administrator Tools
application. The utility performs a clean operation on the configuration database and creates a complete backup that includes the configuration
database and a synchronized VCAT database, if one is present.
Note You can backup the Version Control database separately. Backing Up the Version Control Database provides details on this procedure.
The Backup and Restore tool can only run when no users are logged on to the database. This may make it impractical to use the Backup and
Restore tool frequently. The DeltaV Daily Export tool can also be used in your data protection process.
The Daily Export tool creates an FHX file of the entire database. You can set up the tool to automatically create the FHX once per day. This is
not a database backup, it is a backup of the configuration data in FHX format. FHX backups can be effective in recovering from certain error
condtions. For example, to recover from database corruption, you can create a new database and then import the FHX file. In addition, when
you import from an FHX file, the database is optimally packed so performance may improved.
Do not back up over the area control network (ACN). Doing so causes extensive network traffic, which results in timeout when sending
control data. DeltaV Operator tools can remain active during the backup procedure. Close the DeltaV Engineering tools for best results. Do
not make any configuration changes while performing a backup procedure. Also, it is recommended that you do not maintain backups on the
same workstation that contains the configuration database. You can backup to a local path and copy the backed-up data to removable media.

Backing Up a Workstation
It is good practice to use Windows Backup to backup the workstation drives.

Backing Up Continuous Historian Data
Use the Continuous Historian Administration application to backup historical data sets manually. Continuous Historian Administration
provides more information about this application. For automated backups of Continuous Historian historical data, use the Continuous
Historian Automated Backup Utility.

Backing Up Event Data
The Event Chronicle Administration application enables you to manually backup event history data sets. Refer to the application help for
more information. Event Chronicle Automated Backup Utility enables you to use the Windows scheduler to automate backups.

Backing Up Batch Historian Data
Refer to Backing Up the Batch Historian Data for details.

Backing Up the POWERUP Directory
The controller and workstation downloads are stored in the \POWERUP directory. This directory effectively contains your run-time system
data. It is important to backup this information because it is used by redundant controllers during a switchover. It may also be used by
controllers after the loss and restoration of power. The Daily PowerUp Directory Backup utility in the Database Administrator Tools
application enables you to set up an automatic daily backup of the POWERUP directory.

Backing Up Supporting Data
The DeltaV system contains important data that is not backed up by any of the DeltaV backup applications or commands. However, this data
should be backed up regularly using the Windows Backup utility or a comparable third-party tool. This data is stored in subdirectories of the
DeltaV directory. Following table lists the major subdirectories and files in the DeltaV directory and what information they contain.
Directory Contents
DeltaV\DVData\amsdevices Directory containing fieldbus device files.
DeltaV\DVData\amshartdevices Directory containing HART device files.
Directory containing the template, sample format specification
DeltaV\DVData\Bulkedit
files, and sample .txt files for bulk edit.
DeltaV\DVData\Charts Directory containing saved Process History View charts
Directory containing predefined E+Chart files for module and
faceplate parameters. For example, AI_fp.phve contains a
chart of the PV parameter of the Analog Input function block
DeltaV\DVData\Charts\Lib
and an event log for the module. Process History View opens
these files when an operator presses the E+Chart button on the
module or function block's faceplate.
DeltaV\DVData\Databases Directory containing the active configuration database and any
backup databases
DeltaV\DVData\download Directory containing the download scripts for the last
downloaded configuration
DeltaV\DVData\Expressions Directory containing expressions created in Control Studio
DeltaV\DVData\Graphics-iFIX Directory containing operator displays and historical data files
DeltaV\DVData\Graphics-iFIX\Pic Directory containing pre-existing graphics as well as user-
created pictures that are used in operator displays
DeltaV\DVData\Import-Export Directory containing files that have data exported from the
configuration database
DeltaV\DVData\POWERUP Directory containing download files.
DeltaV\DVData\sound Directory containing *.wav files for audible alarms

Restoring your System
In case of a catastrophic system failure, perform a full system restore. The steps in the following procedure are required to restore the files you
backed up in the full system tape backup procedure.
Note Windows includes an option called System Restore on the System Properties dialog. This feature is not related to the procedure
documented here. Emerson Process Management recommends turning off the Windows System Restore feature.
The restore operation consists of four main steps:
1. Install the operating system according to the instructions provided in XPHelp.chm or VistaHelp.chm, located in the \_Support directory
on DeltaV installation disk #2.
2. Restore the full backup using the Windows Backup Utility.
3. Restore the Objectivity Database using the Database Administrator Backup and Restore tool.
4. The full system restore returns the hard drive's contents back to the way they were when the backup was made. All changes to the hard
drive's contents between the Backup and the Restore are lost. To ensure that the system matches the newly-restored contents of the hard
drive, perform a Total Download of the entire system as soon as plant operations allow it.

Legacy Historian Archive Backup and Security
This book contains information on backing up Legacy Historian data and file security.
For a description of the Legacy Historian and its relationship to the Continuous Historian, refer to the Legacy Historian subtopic in The
Continuous Historian topic. For additional information on the Legacy Historian requirements, refer to The Legacy Historian.
Click on an item in the Table of Contents inside this book for more information.

Backing Up the Legacy Historian Archives and Database Files
Inside this topic
The Legacy Historian's data archive files and the database configuration files should be backed up on a regular basis. The primary archive is
constantly changing and should be backed up daily. The database configuration files do not need to be backed up as frequently as the primary
archive. The database files are only changed when changes are made to the Legacy Historian and to the configured History Collection.

Backing Up the Legacy Historian Archives
The Legacy Historian has a data archive system that serves as its historical data server. Three archive files (PIARCH.001, PIARCH.002, and
PIARCH.003) are created and reside in C:\PI\DAT. Users can create additional archives to increase the historical capacity of the system. The
archive files are indexed and listed in chronological order, with empty archives at the end of the list. The primary archive, at index 0, is where
all current data is stored. When this archive is nearly full, an archive shift occurs, and the last archive in the list is initialized and moved to the
primary archive location at Index 0. The last archive in the list is either an empty archive or contains the oldest data. It is recommended that
you create automated backups to run daily to protect from loss of data in the event of disk failure or other unexpected action. Daily backups
need to focus on the primary archive 0 and archive 1, since an archive shift may have occurred since the last backup. Make permanent
backups of each archive if you want to preserve the data for future reference. A permanent backup is simply a copy of a full archive that is
stored on removable media and renamed so that it can be registered for viewing at some later time.
Historical data storage requirements vary greatly from site to site and so it is left to the user to develop appropriate backup and recovery
procedures. The following procedures are presented as a starting point for the development of your own procedures. Contact your local
representative for assistance in implementing your Historical Data backup procedures.
To back up the data archive files manually:
The Legacy Historian software provides a command line interface to perform many administrative functions either manually, or in an
automated script. The piartool command is the principle command used in administering the archives. The Backup Start (-bs qualifier), which
makes an archive available for copy, must be used to back up the primary archive. It can also be used to back up remaining archive files. The
–bs qualifier uses the Archive Index number to specify the archive file being backed up. The user must then know the archive by its file name
in order to copy the file to a backup location. The archive list (-al) qualifier lists all registered archives in chronological order, with archive 0
at the top. This helps the user identify the index of each archive file and also indicates the start and end times of the archives. Note that the –bs
qualifier also updates the backup date/time of each archive as listed in the archive list. The backup date/time of full archives should be later
than the End times of the archives.
Note Depending on your installation options, you can perform the following procedure on either the C: drive or the D: drive. (The C: drive is
used in the examples in this procedure.)
1. Click Start | Programs | Accessories | Command Prompt to open an MS-DOS window and go to C:\PI\ADM.

C:\> cd \PI\ADM

2. Type piartool -al to list archives.

C:\PI\ADM> piartool -al
Note Identify the name of each archive file associated with the index locations. The primary archive is index 0 and is first in the list.
3. Type piartool -bs 0 to flush the cache and take the primary (index=0) archive file offline.

C:\PI\ADM> piartool -bs 0

While the primary archive file is offline, all archive data that is currently being collected is sent to C:\PI\DAT\PIEVENTQ.DAT if
needed.
Note The archive index 0, 1, and 2 does not necessarily correlate to the PIARCH file extension of .001, .002, and .003. To identify the
indexes of the archive files, go to C:\PI\ADM and type piartool -al. This command lists the registered PIARCH files with all their
specific details in order of increasing index number. Archive 0 is the primary archive where current data is being stored.
4. Back up the specified archive file (C:\PI\DAT\PIARCH.001, PIARCH.002, or PIARCH.003) as an ordinary file to your backup
location, such as a tape backup or remote hard drive directory.
5. Type piartool -be to put the archive file back online.

C:\PI\ADM> piartool -be

6. Repeat steps 3-4, for each archive file that contains data that has changed since the last backup. Typically, this is only required
following an archive shift as the additional archives do not receive new data when they are no longer the primary archive.

Type piartool -bs 1 (instead of piartool -bs 0 ) in step 2, to start the backup of the specified archive.

Backing Up the Database Configuration Files
In addition to the archive files, the database configuration files must also be backed up to allow recovery of the Legacy Historian system.
Failure to backup the configuration database will result in the loss of historical data if the Legacy Historian software must be reinstalled.
Many of the database files cannot be copied while the associated historian process is running. To successfully copy these database files, first
stop the process. After the files have been copied to the backup location, restart the process before proceeding. Be sure the Legacy Historian is
working properly once you have completed the backup.
1. While the historian processes are running, copy the following files to the backup directory:
 C:\PI\LOG\*.dat
 C:\PI\DAT\shutdown.dat
 C:\PI\DAT\pisql.ini
 C:\PI\DAT\pifirewall.tbl
 C:\PI\DAT\pitimeout.tbl
 C:\PI\DAT\pisubsys.cfg
 C:\PI\DAT\Piproxy.dat (if it exists)

2. To copy the next group of files, you must first stop the pibasess process which owns the files.
Type net stop pibasess to stop the pibasess process.

C:\ net stop pibasess
The system returns the following messages:
The PI Base Subsystem service is stopping
The PI Base Subsystem service was stopped successfully
Copy the following files to the backup directory:
 C:\PI\DAT\pipoints.dat
 C:\PI\DAT\piptattr.dat
 C:\PI\DAT\piptclss.dat
 C:\PI\DAT\pidigst.dat
 C:\PI\DAT\pidignam.dat
 C:\PI\DAT\piusr.dat
 C:\PI\DAT\piusrgrp.dat
 C:\PI\DAT\piusrctx.dat
 C:\PI\DAT\piptunit.dat
 C:\PI\DAT\piptalia.dat
 C:\PI\DAT\PIModuleDb.dat
 C:\PI\DAT\pitrstrl.dat
Type net start pibasess to restart the pibasess process.
C:\ net start pibasess
The system returns the following message:
The PI Base Subsystem was started successfully
3. The PI Batch subsystem is not used in DeltaV software and should not be running. If it is running, shut it down:

Type net stop pibatch to stop pibatch:

C:\ net stop pibatch
The system returns the following messages:
The PI Batch Subsystem service is stopping
The PI Batch Subsystem service was stopped successfully
Copy the following files to the backup directory:
 C:\PI\DAT\ pibaunit1.nt
 C:\PI\DAT\ pibaalias.nt
Contact your local Service Representative to develop detailed and automated backup procedures that should also include appropriate recovery
procedures.
Sizing Guidelines for the Legacy Historian Archive
Inside this topic
This document describes an approach to sizing the Legacy Historian archive files to meet the data recording needs of a specific
implementation. Since the Legacy Historian uses compression algorithms to reduce the amount of data storage, the information presented here
will not provide exact results. However, information to estimate initial archive sizing and a methodology to view the actual data storage rate
and adjust accordingly are provided.

Sizing Calculations
The Legacy Historian system stores data into archive files. You can have multiple archive files of various sizes. For example, you can have
three 100-Megabyte files or five 250-Megabyte files. The maximum archive file size is 1 Gigabyte. The default installation provides for 3
archive files. It is recommended that you create no fewer than 3 archive files. The maximum number of archives is limited by the operating
system and the maximum file handles available, as well as by the available memory in the computer. The theoretical limit is 1022 archive
files, although the actual number is typically between 30 to 100 archive files on medium to large systems. Consult with your local
representative or Emerson Process Management service provider before expanding your archive count beyond 100.
Consider the following when determining archive file size and count:
 The total archive volume (size of a single archive file times the number of archive files) affects the length of time that files store data
before being overwritten.
 The individual archive volume (size of a single archive file) affects how often an archive shift occurs. The Legacy Historian performs
an archive shift to switch archiving from the active file to the file that contains the oldest data.
 The individual archive volume also affects how much available data is discarded when an archive shift occurs. For example, if each
archive stored approximately one month of data and there were three archives, there would be a maximum of three months data online
just prior to the shift and a maximum of two months data online after the archive shift.
Here are a few things to consider before setting the archive files:
 Consider future expansion. Estimate the point count for the next year or two and size archive files accordingly.
 Data storage rate increases with an increase in scan rate and decreases with an increase in compression deviation. The default
compression values are Compression=ON with a Compression Deviation of 0. If this is left unchanged, every change in data values will
be stored to disk, possibly consuming the archives much faster than expected.
 Each point stored requires a minimum of 4 Kilobytes of storage for the archive system to work correctly. However, archive storage is
more efficient if 5 Kilobytes per point are used.
 Make sure that the archive is of a size that will fit on the media used for long-term backup and will back up in a reasonable amount of
time. (For example, use 600-Mbyte archives if a writable CD drive is used to store archive files.)
 An archive file can be any size, but it is recommended that all archives be the same size to facilitate system administration. Once
created, a fixed archive's size cannot be changed. It must be deleted and then recreated at the larger size. Therefore, it is much easier to
add archives than to change archive sizes. Be generous in archive file sizing to meet the point count estimates and use the archive count
to adjust for total archive duration.
 Nominally, the archive should shift every 14 to 60 days. Keep in mind that a point will consume 1.5 Kilobytes per day.
Using the above criteria, a system with a projected size of 1000 points and a storage time of 30 days before an archive shift occurs would
require a 44-Mbyte archive file, as shown in the following calculation:
Minimum Size Requirement: 1000 *4.0Kbytes = 4 Mbytes
Estimate for 30 days storage: 1000 * 1.5Kbytes * 30 = 44 Mbytes
Given these calculations, the following table provides a quick reference (values are in Mbytes, which are rounded where appropriate):
Point Count Minimum Size 30 Days 60 Days

2 Mbytes (minimum archive
250 11 22
size, regardless of point count)
1,250 5 55 110
5,000 20 220 440
10,000 40 440 880
20,000 80 880 1760

Analyzing Results
Once the archive files are online, you can test the accuracy of the calculations by comparing the actual data storage rate to the estimated rate.
If the rate is too high, either adjust the compression deviation on values that do not require minute changes to be stored or increase the total
archive volume. Increase the archive file size to reduce the frequency of archive shifts, but do so only after careful evaluation of data
compression and scan rate configuration. Increase the number of archives so that it extends the total archive volume size to satisfy the
required online availability of data.
The Legacy Historian system is installed with the DeltaV system, and a default archive file size is selected. If the system was already
collecting data, the following procedure will give a good estimate of the rate at which the archive files are being consumed.
1. Log on to the PC running the Legacy Historian system that you want to analyze and then open a Command Prompt window.

For Windows NT, select Start | Programs | Command Prompt.

For Windows XP, select Start | Programs | Accessories | Command Prompt.
2. In the Command Prompt window, set the adm subdirectory under the PI installation directory to be the default directory. For example,
if the Legacy Historian was installed on the D: drive in the PI directory, you would enter the following commands:

C:\D:
D:\cd \PI\adm
3. Run the program piartool and supply the argument –AL:

D:\PI\adm>piartool –AL
4. View the output. It should appear similar to the following:
D:\PI\adm>piartool -AL
Archive shift prediction:
Shift Time: 5-Mar-03 13:11:05
Target Archive: d:\PI\dat\piarch.002
Archive[0]: d:\PI\dat\piarch.003
PIarcfilehead[$Workfile: piarfile.cxx $ $Revision: 56 $]::
Version: 5 Path: d:\PI\dat\piarch.003
State: 4 Type: 0 Write Flag: 1 Shift Flag: 1
Record Size: 1024 Count: 87040
Offsets: Primary: 24/21760 Overflow: 71431/87040
Start Time: 27-Aug-02 10:18:59
End Time: Current Time
Backup Time: 24-Sep-02 11:40:05
Start Time: 24-Jun-02 15:30:54
End Time: 27-Aug-02 10:18:59
Backup Time: 24-Sep-02 11:40:25
Start Time: Current Time
End Time: Current Time
Backup Time: Never
Understanding the Output
The archive files are listed according to their archive numbers. The archive number (0, 1, 2, and so on) should not be confused with the file
extension on the piarch files (001, 002, 003). The archive numbers are always defined as:
 Archive 0 — the active archive
 Archive 1 — the most recently active archive
 Archive 2 — the remaining archives (The more recently written archives have the smaller number.)
Therefore, Archive[0] is active and will have a defined Start Time showing when this archive became the active archive, and End Time of
Current Time. In the preceding output, the Start Time is 27-Aug-02 10:18:59.
Any file that has not been written to will have a Start Time and an End Time of Current Time. When the Legacy Historian system initially
starts, archives 1 and 2 will be in this state. As each archive is used, its Start Time will be defined. Once all archives have been used, each will
have a defined Start Time, and all except the active archive will have a defined End Time. The active archive always has an End Time of
Current Time.
Determining Archive Consumption Rates
To determine the archive consumption rates, subtract the Start Time from the End Time of any archive that has been filled. In the preceding
example output, only Archive[1] meets these criteria with a Start Time of 24-Jun-02 15:30:54 and an End Time of 27-Aug-02 10:18:59. This
archive, sized at 87,040 KB (85 MB), was filled in 64 days.
Since we have 3 archives, the system can store up to approximately 192 days of data when the 3 archives are filled, dropping to 128 days
when an archive shift empties the oldest archive file and begins storing new data into it.
If this is acceptable, no change is necessary. If the 64 day-archive size is acceptable but you want a minimum of one year's data online,
increase the number of archive files to (365 / 64 + 1) = 7 archives. If you want an archive to hold 90 days of data, increase it to (85 MB * 90 /
64) = 120 MB. At 90 days per archive, only 5 archives would be required for one year of online data.
Note You cannot change the size of a fixed archive. Create new archives at the size that you want and retire the existing archives once you no
longer need them.

Changing Data Archive File Size
Change the archive file size for any of the following reasons:
 The files are unable to store at least 14 days of data.
 The file size does not meet the minimum size requirement of 4 Kbytes per point. This only occurs if the Legacy Historian is installed
manually and the default archive size is undersized during install.
 The archives are too large for the number of tags in the system. The Legacy Historian software is installed with a default file size of 32
Mbytes, but the DeltaV system changes the file size to 80 Mbytes. Older systems may have archives of 40 Mbytes. Because the size
changes, you must use Windows Explorer to determine the actual file size. When creating archives, you can use the default size or
specify the archive size you need. The default size will be the size of the current, registered, primary archive.

Replacing Archive Files
Fixed archive files cannot be resized. However, you can create new archive files to replace smaller existing ones. The Legacy Historian can
continue to run during the following procedure. The Legacy Historian system will continue to write to the active archive until it is full and
then will perform an Archive Shift. It is possible to force the archive shift with the piartool utility. The following procedure backs up the
system, replaces the two inactive archives, performs a Force Shift on the active archive, and then replaces the archive.
1. Open a Command Prompt window.
2. Set the adm subdirectory under the PI installation directory to be the default directory. For example, if the Legacy Historian was
installed on the D: drive in the PI directory, you would enter the following commands:

C:\D:
D:\cd \PI\adm
3. Back up the Legacy Historian data using DvPiBackup.bat. You must specify the PI installation directory, the number of additional
archives to back up, and a backup location. The following command will back up the three most recent archives to the D:\PI_Backup
directory:

D:\PI\adm>dvpibackup D:\pi 2 d:\pi_backup
4. Use the piartool -al (-AL) command to determine which archive is active. In the above example, the active file is D:\PI\dat\piarch.003.
Important Near the top of the list output, there is an estimated shift time. Do not attempt the following resizing procedure if the estimated
shift time is in the near future. Allow at least 20 minutes for this procedure.
Follow these steps to resize the two other files (piarch.001 and piarch.002):
1. Take the .002 archive offline:

D:\PI\adm>piartool –au D:\PI\dat\piarch.002
2. Continue to run the list command until the file is no longer listed:

D:\PI\adm>piartool -al
3. Delete the .002 archive:

D:\PI\adm>del d:\PI\dat\piarch.002
4. Create a new .002 archive with the piarcreate command. The following example creates a new 150 Mbyte archive file size:

D:\PI\adm>piarcreate d:\PI\dat\piarch.002 150
5. Register the archive so that it is an active archive:

D:\PI\adm>piartool–ar D:\PI\dat\piarch.002
6. Run the list command again to ensure that the new .002 file is back online with the new size (the Count value should be the number of
Kbytes of the new file). Use Windows Explorer to ensure that it is the correct size. The list command is required to determine if the file
is back online.
7. Repeat the above steps for the other file that is not online. In this example, that is the .001 file.
8. The two non-current files have been replaced. The active file cannot be deleted while it is active; so, you must force a shift to the next
archive. The command is:

D:\PI\adm>piartool-fs
A message about the time it takes to complete the force shift request appears. A sample of this message follows. The actual file names
and number of records will differ according to your system.
Attempting to force an archive shift...
An archive shift has been initiated on the server.
Completion time will vary from a few minutes to hours,
depending on the machine and archive size. During this time the archive
subsystem will be unavailable and the PI System should not be stopped until
the shift is complete.
The status of the shift can be found in the message log using pigetmsg.
The current primary archive is d:\PI\dat\piarch.003
and the target archive for shift is d:\PI\dat\piarch.002
The current primary archive has 87040 records and the
target archive for shift has 51200 records.

The system generates a message to the messaging system. You can review the contents of this message and confirm the completion of
the shift. From the adm directory, enter the command pigetmsg and enter a T to view the tail end of the message. Look for a message
similar to the following:
>> Archive d:\PI\dat\piarch.003 shifted successfully.
New Primary Archive is d:\PI\dat\piarch.002
9. Now, you can repeat the above replacement steps for the archive that was originally active (In this example, archive 003).
10. Finally, make sure that all files appear as expected when you run the piartool –al command. All archives should be online, in the
correct directory, and of the same size.
You can add the newer, larger archives using different file names and keep the older archives online until they are no longer needed. When
they are no longer needed, you can take them offline and delete them.

Changing the Number of Data Archive Files
If the archives are already an acceptable size with respect to the amount of time it takes to fill them (recommended 14 to 60 days, not more
than 255 days), you may leave them at their current sizes. However, you may want to extend the total archive file size so that more history is
available online at any given time. As an example, if there are 3 archives and each archive only stores approximately one month's data, there
will be up to 3 months of data prior to an archive shift and 2 months of data after an archive shift. It is easy to add archives if more data
storage is required. The Legacy Historian system can have up to 99 archives, but 40 archives are more than enough for most applications.
Use the piartool utility with the –ac (archive create) argument to add an archive. This call creates an archive that is the same size as the
currently active archive and automatically registers it, making it easier to use than the piarcreate command. Archives can be added while the
Legacy Historian system is running; so, there is no need to disable the Legacy Historian or stop its services. Repeat the following procedure as
many times as necessary, changing only the file extension, until sufficient storage is created:
1. Log on to the PC running the Legacy Historian system and open a Command Prompt window:

For Windows NT, click Start | Programs | Command Prompt.

For Windows XP, click Start | Programs | Accessories | Command Prompt.
2. Set the adm subdirectory under the PI installation directory to be the default directory. For example, if the Legacy Historian was
installed on the D: drive in the PI directory, you would enter the following commands:

C:\>D:
D:\PI\adm>cd \PI\adm
3. Run the piartool program and supply the list argument –al (–AL):

D:\PI\adm>piartool al
Important Make sure that the predicted Shift Time, displayed near the top of the output, will not occur in the next few minutes.
4. For this example, it is assumed that the output of the piartool –al command is identical to the output displayed earlier in this document.
Therefore, the next archive to create will have a .004 extension:

D:\PI\adm>piartool ac
5. As part of this function, you are prompted for the complete path to the new archive (for example, d:\pi\dat\piarch.004). Confirm this
question by entering y.
6. When asked if you want to initialize the start and end times, decline this question by entering n.
7. When the archive name, Start Time, and End Time of "not specified" are presented for confirmation, confirm by entering y.
8. The function completes with a message indicating that the archive will remain offline until the creation process is complete and that the
Legacy Historian should not be stopped until the process is complete (It should complete in a few seconds).
9. Use the pigetmsg utility to ensure that the archive is online:

D:\PI\adm> pigetmsg
10. Enter a T to view the tail end of the message and look for the following string:

>> Archive file d:\pi\dat\piarch.004 loaded. This indicates that
the archive is active in the PI system.
11. Use piartool –al to list the archives and show the new archive.
12. Repeat the above steps for all required archives.
Modifying Legacy Historian File Security
Inside this topic
This document is intended for system managers. It describes how to modify the security for the piarch files (piarch.001, piarch.002, and so
on) and the executable files (piartool.exe and piconfig.exe) to prevent unauthorized users from modifying or deleting Legacy Historian data
files. Depending on your plant situation, you may need to modify other files, such as pipoints.dat.
This document ignores any site-specific security imposed for your specific application. Instead, power users are defined in the DeltaV Admin
accounts, which are members of the DeltaV Admins group. If your site’s implementation has a power user from a domain, modify the entries
for the following DeltaV Admins items to match your site’s privileged users.
The procedures presented in this document are specific to Windows XP with references to Windows NT included where appropriate.
Preliminary Steps
Before you can change the file permissions, you must disable the Legacy Historian and shut down the Legacy Historian system.
1. Open a Command Prompt window (select Start | Programs | Accessories | Command Prompt or select Start | Run and enter CMD).
2. Set the drive and directory to the Legacy Historian administration directory (\PI\adm by default).
3. Run pisrvstop.bat and wait until it completes.
4. Follow the instructions in the following topic, which is entitled "Changing Data File Permissions."
5. When the file permissions are changed, enable the Legacy Historian in DeltaV Explorer again. (If you are running DeltaV software
version 7.2 or above, you can start the Legacy Historian by running pisrvstart.bat.)
6. Download the Continuous Historian subsystem in DeltaV Explorer.

Changing Data File Permissions
This section describes how to change the permissions on the archive files and the two executable files. You can use a similar approach to
change any other file permissions in the \PI\dat directory, but you must make sure that data collection is not harmed.
Since the Legacy Historian services are run as user SYSTEM, the goal is to create file permissions that allow SYSTEM full access and then
limit other users as required. This procedure enables the following privileges and disables inheriting parent privileges:
 Full Access
 DeltaV Admins – Read, Write, Special (This is the group for DeltaV Administrators.)
 DeltaV – Read (This is the group for DeltaV Users.)
The executables that will be modified are piartool.exe, which is used to perform backup procedures, and piconfig.exe, which is used to
configure the Legacy Historian system. This procedure turns off access to any user who is not an administrator. Attempting to run the program
without privileges results in an Access Denied message.
The following procedure applies to default installations where the 3 default archives are in the PI\DAT directory. If yours is not a default
installation, run PIARTOOL -AL to identify the location of the registered archives and then modify them.
1. Start Windows Explorer.
2. Navigate to the data directory (\PI\dat by default) on the disk drive on which the Legacy Historian was installed.
3. Select all of the archive files (piarch.00x). By default, there are 3 piarch files, although an implementation may have been modified to
include additional archives.
4. Right-click one of the selected files and select Properties.
5. In the Properties dialog, select the Security tab and refer to the following specific instructions for either Windows XP or Windows NT.

Changing Permissions on PIARCH files on Windows XP
1. Click the Advanced button near the bottom of the page and delete all entries. If one of the entries cannot be deleted, clear the check box
entitled Inherit from parent the permissions that apply to child objects... There should be no entries.
2. Click Add.
3. On the Add page, click Locations, select your machine name, and click OK. The machine name should be listed in the From this
location field of the Select User or Group dialog.
4. Click the Advanced... button. On the Advanced page, click the Find Now button, select SYSTEM from the list, and click OK to return
to the Select User or Group dialog.
5. Click OK again. The Permission Entry for... dialog opens.
6. For SYSTEM, click the Allow check box for Full Control. (All of the check boxes below the Allow check box are selected
automatically.)
7. Click OK. There should be one entry in the Permissions tab of the Advanced Security Settings For... dialog.
8. Click OK in the Advanced Security Settings dialog to return to the Properties page for the multi-select files.
9. Click the Add button again, select the local computer for the location using the Locations… button, and then click the Advanced button.
10. Click the Find Now… button and select DeltaV as the group for DeltaV users.
11. Click OK and select the Read check boxes to give read privileges to DeltaV users.
12. Repeat step 10 and add DeltaV Admins as the group for DeltaV Administrators.
13. Click OK and select the Read and Write check boxes. Then, click the Advanced button and click the Edit button for the Administrator
users. In each case, select both the Change Permissions and Take Ownership check boxes to give any DeltaV Administrator sufficient
privileges to read, write, and modify files.
14. Continue to click OK in all of the dialogs until the Windows Explorer application is active.

Changing Permissions on PIARTOOL.EXE and PICONFIG.EXE Files on Windows XP
1. In Windows Explorer, navigate to the administration directory (\PI\adm by default) on the disk drive on which the Legacy Historian
was installed.
2. Select the piartool.exe and piconfig.exe files.
3. Right-click one of the selected files and select Properties.
4. Disable all current privileges (and the Inherit check box on the Advanced page) and add the following users privileges:
DeltaV Admins – Full Control
5. Click OK in each dialog until the Windows Explorer is active.

Changing Permissions on Windows NT
This procedure is very similar to that for XP. However, the File Properties dialog for NT is less complex than in XP.
1. In Windows Explorer, select all piarch.00x files, right click, and select Properties.
2. Select the Security tab in the Properties dialog and click the Permissions button.
3. Remove all of the current access rights and then click the Add button.
4. At the top of the Add Users and Groups dialog, select the computer from the List Names From drop-down list.
5. Select the SYSTEM user of the workstation and click the Add button in the middle of the dialog. Doing so moves SYSTEM to the
lower list area.
6. Select Full from the Type of Access list and click OK to accept this privilege.
7. Click the Add button again.
8. Again, select the computer name from the List Names From drop-down list at the top of the dialog, select DeltaV Admins, and click the
Add button.
9. At the bottom of the page, select the Change item from the Type of Access drop-down list. This includes all read and write privileges.
10. Click OK to return to the File Permissions dialog.
11. From the File Permissions dialog, double-click DeltaV Admins. A new dialog is displayed with each selectable privilege. Select the
bottom two check boxes, Change Permissions and Take Ownership.
12. Continue to click OK until the Windows Explorer is active.
13. Repeat these steps to provide the DeltaV Admins group full privileges to the piartool.exe and piconfig.exe files in \PI\adm and remove
all other privileges from those files.
Version Control
This book contains information on using version control in DeltaV software. Click on an item in the Table of Contents inside this book for
more information.

Version Control
Inside this topic
DeltaV Version Control (VCAT) helps you manage configuration and user security changes by retaining previous versions of the
configuration and security items. Version Control enables you to see who made changes and the reason given for any changes made. It allows
you to restore previous versions of items or entire databases, to archive Version Control databases, restore archives, and clean up the database
after restoring items. When enabled, Version Control affects all of the configuration items that you add, edit, or delete using DeltaV Explorer,
Control Studio, Recipe Studio, I/O Configuration, and System Alarm Management (SAM), and all of the security items that you add, edit, or
delete using DeltaV User Manager.
In addition, you can enable Version Control for DeltaV Displays. Version Control for DeltaV Displays requires DeltaV Version Control be
enabled. That is, Version Control for DeltaV Displays cannot be enabled alone. Setting up, enabling and disabling, preferences, and the
functions and locks options that are set for DeltaV Version Control apply to Version Control for DeltaV Displays. No additional configuration
is required. However, there are some behavioral differences between Version Control's management of configuration items and its
management of graphic and schedule files. Refer to Version Control for DeltaV Operate Displays for more information.
You can also enable Version Control for documents to manage changes for other types of files, for example, plant standard operating
procedures, instrumentation diagrams, and so on. VCAT for documents can store any type of file. To enable VCAT for documents, Version
Control or Version Control for DeltaV SIS must be enabled. That is, Version Control for documents cannot be enabled alone. Setting up,
enabling and disabling, preferences, and the functions and locks options that are set for DeltaV Version Control apply to Version Control for
documents. No additional configuration is required. However, there are some behavioral differences between Version Control's management
of configuration items and its management of documents and other files. Refer to Version Control for Documents for more information.
When you enable Version Control, the DeltaV system creates a Version Control database and populates it with the items in your current
configuration database. Once you have established the Version Control database and Version Control is enabled, you can see configuration
changes by comparing versions of items in the Version Control database with the items in the configuration database.
The version control database name is based on the configuration database name.
After enabling Version Control, you can set your Version Control preferences using DeltaV Explorer.
The following items are not tracked in the Version Control database.
 Changes to transducer and resource blocks in commissioned fieldbus devices.
 Changes to decommissioned fieldbus devices, including their resource and transducer blocks.
 Imported items from third-party sources (for example, fieldbus revisions in the library)
 Licenses

Setting up and Disabling Version Control
Version Control is an optional feature and requires an additional license. Only enable this feature if you need to keep a strict history of
configuration changes. Because Version Control retains copies of all versions of configuration items, it may require a substantial amount of
disk space. Version Control can have a slightly negative performance effect on the system.
Typically, Version Control should not be enabled until the system is ready for factory acceptance testing. However, the time at which Version
Control is enabled should be based on customer requirements. Note that once you have enabled Version Control, disabling it will create a gap
in your configuration history.
To install the Microsoft SQL Server, select the Install Microsoft SQL check box in the DeltaV Workstation Configuration, which appears
during the DeltaV software installation on a ProfessionalPLUS workstation. If DeltaV software has already been installed, you can run Setup-
SQL.exe, located in the DeltaV\bin directory.
After installing the SQL Server on the ProfessionalPLUS workstation, run the DeltaV Database Administrator application using a DeltaV
Administrator account type. The Database Administrator contains a tool called Version Control Configuration. Open this tool and select the
options you require.
Note Enabling Version Control for the first time can take several hours depending on the size of the configuration.
You can monitor VCAT's progress by watching the Version Control - Messages dialog. Avoid using other applications during VCAT enable.
The time required to enable VCAT may increase if other CPU-intensive activities are also being performed.
After enabling Version Control, you can set your Version Control preferences using DeltaV Explorer.
If you are logged on using a DeltaV Administrator account type, you can use the Version Control Configuration tool in the Database
Administrator tools to enable and disable Version Control. Once Version Control is disabled, you will no longer have a record of changes
made to the configuration. The Version Control Configuration tool warns you if there are any checked out items. You can disable Version
Control even with items checked out.

Setting Version Control Preferences
There is a choice of three preferences that affect Check In and Check Out behavior. To view or modify these preferences in Explorer, click
Tools | Version Control | Preferences in Explorer. In Control Studio or Recipe Studio click Preferences (on the Home tab, in the Version
Control group). These preferences pertain to all users and applications, other than the User Manager application, that are affected by Version
Control. Auto Check Out and In is always enabled when Version Control is used with the User Manager application to create an audit trail for
security items. Refer to the Checking Items In and Out topic for more information on check in and check out:
 Manual or Prompt user for Checkout - Prompts users to check out affected items before changes can be saved and prevents user edits
of an item in Control Studio or Recipe Studio unless the user clicks a Check Out command to check out the item. This is the default
preference.
 Auto Check Out - Automatically checks out any item that you edit or open. After saving an item, you must also check in the item for
the change to be added to the Version Control database.
 Auto Check Out and In - Automatically checks out any item that you edit or open. Automatically checks in items when you close
them if they were automatically checked out. The system also automatically checks in displays that were checked out manually.
Note When Auto Check Out or Auto Check Out and In are enabled, opening and saving configuration items typically takes longer than it
would without one of these preferences selected.

Version Control Functions and Locks
Keys are required for various version control functions:
 VC_ADMINISTRATOR -Enables a user to undo the check out of items checked out by other users.
 VC_CHECKOUT_CHECKIN - Enables a user to check configuration items in and out of the Version Control database
 VC_DOWNLOAD_CHECKEDOUT - Enables a user to download configuration items that are checked out
 VC_PURGE_RECOVER_ITEMS - Enables a user to permanently remove an item from the Version Control database
 VC_ROLLBACK_ITEMS - Enables a user to restore an item from the Version Control database
 VC_SET_LABEL - Enables a user to label configuration items so that they can be easily restored at a later date
Refer to the DeltaV Locks topic for information on the relationship between these functions and DeltaV locks.
Checking Items In and Out
Version Control introduces two new types of user actions: Check In and Check Out. In order to perform these actions, your user account must
have a key for the lock associated with the VC_CHECKOUT_CHECKIN function. This function is assigned to the Can Configure lock by
default. Note that it is possible for your system administrator to create accounts with conflicting privileges. For example, you may have the
privilege to create a certain type of configuration item, but you may not be able to check it in.
Security items differ from configuration items in check in and check out behavior. When Version Control is enabled, any User Manager item
that is opened or edited is automatically checked out of the Version Control database and any item that was checked out is automatically
checked in when it is closed.
To modify a configuration item, check out the item from the Version Control database. Checking out an item makes it available for editing in
the appropriate application (for example, DeltaV Explorer, Control Studio, or Recipe Studio). When Version Control is enabled, configuration
items are read-only until you check them out. Once you have checked out an item, you can modify it.
Checked out files are marked as follows:
A red check indicates that the item is checked out by the current user. A blue check indicates that the item is checked out by another user.
Only one person at a time can have an item checked out.
After you have finished editing an item, you can save the item as you normally would. Saving the item changes the item in the configuration
database. To update the item in the Version Control database, you must check it in. Check in retrieves a copy of the item from the
configuration database and places it in the Version Control database as a new version. Additionally, the configuration item then becomes read-
only again (the item can always be viewed by any user, and its data can be accessed whether it is checked out or not). The Version Control
database stores all the changes that have been made to the item. The most recent copy is always available from Version Control. You can also
restore or roll back to previous versions of the item.
If you have not made any changes to the file or you do not want your changes checked in, you can select Undo Checkout. Undoing the
checkout of an item restores it to the way it was before you checked it out. If there are no changes made to a checked out item, the Check in
command does the equivalent of the Undo Checkout command.
You can also check out recursively. This means that you can select an item in DeltaV Explorer and specify that you want to check it out along
with all of its subordinate items in the hierarchy. You can also check in recursively.
Note Recursive checkins and checkouts can take considerably longer than checkins or checkouts of single items because the system is
performing the checkin or checkout operation on multiple items. You can cancel recursive operations. Refer to the Version Control Messages
topic for more information about canceling operations.
Recursive operations do not affect assignments. For example, if you check out a controller with assigned modules, the modules are not
affected because they are simply referenced to the controller.
Whenever you check in an item, you have an opportunity to add a comment related to the item. Users can go back to the history for this item
and see your description of the changes. Use comments that will help you and other users understand the nature and reasons for changes.
When you add a configuration item, Version Control adds the item to the database and checks it out. You must eventually check in the item.
Finally, if you want to update an item periodically but you want to keep the item checked out, use the Keep checked out command.
Version Control Database Search
The Version Control database supports searches. You can search for the following:
 items checked out of the Version Control database
 items checked out by a specified user
 the whole database, a selected item, or the selected item and all subordinate items
Version Control Messages
A Version Control message dialog pops up to inform you of changes in the version control database. The changes monitored include:
 An item has been checked out.
 An item has been checked in.
 An item has been added or deleted.
 A label has been applied to an item.
 An item has been purged, recovered, or rolled back to a previous version.
 An item's version number changed during DeltaV upgrade (see Version Control and DeltaV Upgrade).
The dialog has the following buttons:
 Clear - Use the Clear button to remove all messages from the dialog.
 Cancel - Use the Cancel button to stop long operations such as recursive check ins. Canceling an operation interrupts it at the point at
which you click the button. Any portion of the operation that has already occurred is not undone by clicking the Cancel button.
 Copy - After you select one or more messages as shown the Copy button is available. Use the button to copy selected messages to the
clipboard. You can then paste the messages into another application.
Click the minimize (-) button in the upper right to hide the message dialog. When you perform an action that affects the Version Control
database, the message window pops up automatically.
Right-click the Control menu (the application icon in the upper-left corner) to define other behaviors of the dialog:
 Always on Top - places the message dialog on top of all other windows so that it is always visible
 Keep Minimized - keeps the message dialog minimized even during Version Control operations
 Auto Minimize - minimizes the message dialog when you select another window

Item History
To see a single item's history, select the item, then select Tools | Version Control | Show History. The History dialog appears, showing the
complete version history of the selected item.
Use the dialog to perform one of the following operations:
 Rollback - Replaces the current version of the item in the configuration database with the selected version. Note that Rollback does not
affect downloaded modules or physical devices in the field. Rollback only modifies the configuration database. For example, when you
roll back to an earlier version of a module, the module does not change the module in its assigned controller. You must download the
controller in order for the changes to take effect in the controller. Another example is a situation in which you have commissioned
fieldbus device and you roll back to a previous, decommissioned version of the device. The device is not decommissioned by the
rollback.
 Differences - When you select two items in the list, this button shows the differences textually or graphically between the two selected
versions in the Version Control database. When you select a single item, this button shows the differences between the version of the
item you select from the list and the item in the configuration database.
 Details - Displays user and system comments associated with an event.
 View - Displays the selected version of the item graphically or textually as appropriate.
 Print History - Prints the history list.
Sorting the List
You can sort the information in the list by clicking on a column header. The sorting behavior for the headers is:
 Version – First click sorts by decreasing number (latest version at top). Additional clicking toggles the sort order. If there are multiple
instances of the same version number, the instances of each version are sorted by date. The date sort order is the same as the version
sort (increasing if version increases and vice-versa).
 User – First click sorts alphabetically. Additional clicking toggles the sort order. If there are multiple instances of the same user, the
instances of each user are sorted by by date (most recent first).
 Date – First click sorts from newest to oldest date and time. Additional clicking toggles the sort order. If there are multiple instances of
the same date and time, the instances are sorted by Version. The Version sort will be the same sort as the Date (increasing if Date
increases, and vise-versa).
 Action – First click sorts alphabetically. Additional clicking toggles the sort order. The label prefix is not used to determine sort order.
If there are multiple instances of the same action, the instances are sorted by Date. The Date sort is always newest to oldest.
 Archive Status – First click sorts alphabetically. Additional clicking toggles the sort order. Multiple instances of the same status are not
sorted.
History Report
Use the History Report to create a list of objects filtered by criteria you select. To create a history report, select an object, then select Tools |
Version Control | History Report. The History Options dialog opens.
The History Report command opens the following dialog from which you query the configuration database.
The query lets you specify the time interval during which the changes were made as well as the user who made the changes. The options in
the Filter drop down list are:
 All History (with Labels) — Shows the history of the selected item, including labels assigned to the selected object.
 General Activity — The report shows user check ins and check outs, rollbacks, labels, and so on. It does not include upgrade check ins
or check outs.
 Upgrade Check In Only — Lists only the item check ins due to a DeltaV upgrade.
You can also specify a recursive query. A recursive query searches the selected item as well as its subordinate items. After you specify
options and click the OK button, the report appears, similar to the following.
The buttons on the dialog are:
 Rollback - Replaces the current version of the item in the configuration database with the selected version. Note that Rollback does not
affect downloaded modules or physical devices in the field. Rollback only modifies the configuration database. For example, when you
roll back to an earlier version of a module, the module does not change the module in its assigned controller. You must download the
controller in order for the changes to take effect in the controller. Another example is a situation in which you have commissioned
fieldbus device and you roll back to a previous, decommissioned version of the device. The device is not decommissioned by the
rollback.
 Differences - Compares the selected version of an item to any other version, or with a version you are currently working on in a DeltaV
application. To compare two different versions of an item, hold down the Ctrl key while selecting the two versions of interest. Then
click the Differences button. Refer to Item Differences for more information.
 Details - Displays user and system comments associated with the object.
 View - Opens the item in the VCAT viewer.
 Print History - Prints the history list.
 Print Latest Changes - For every unique selected item (for example, AREA_A and version 4) a difference report is created for that
item comparing that version with its previous version (in this case, AREA_A version 3 to version 4 differences). Refer to Print Latest
Changes in Item Differences for more information.
Sorting the List
You can sort the information in the list by clicking on a column header. The sorting behavior for the headers is:
 Name – First click sorts alphabetically. Additional clicking toggles the sort order. If there are multiple instances of the same name, the
instances are sorted by Date. The Date sort is always newest to oldest.
 Version – First click sorts by decreasing number (latest version at top). Additional clicking toggles the sort order. If there are multiple
instances of the same version number, the instances of each version are sorted by date. The date sort order is the same as the version
sort (increasing if version increases and vice-versa).
 User – First click sorts alphabetically. Additional clicking toggles the sort order. If there are multiple instances of the same user, the
instances of each user are sorted by by date (most recent first).
 Date – First click sorts from newest to oldest date and time. Additional clicking toggles the sort order. If there are multiple instances of
the same date and time, the instances are sorted by Version. The Version sort will be the same sort as the Date (increasing if Date
increases, and vise-versa).
 Action – First click sorts alphabetically. Additional clicking toggles the sort order. The label prefix is not used to determine sort order.
If there are multiple instances of the same action, the instances are sorted by Date. The Date sort is always newest to oldest.
 Archive Status – First click sorts alphabetically. Additional clicking toggles the sort order. Multiple instances of the same status are not
sorted.
Item Differences
Inside this topic
You can view and print differences between two versions of an item graphically or as text. There are several ways to display differences. With
an item of interest selected:
 From the context menu or Tools menu, select Version Control | Show Differences. This will show the differences between the current
version and the latest version in the VCAT database.
 From the context menu or Tools menu, select Version Control | Show History. This opens the History dialog that shows all the versions
of the currently selected item. Select any two versions and click the Differences button. Refer to Item History for more information on
this dialog.
 From the Tools menu, select Version Control | History Report. This opens the History Options dialog (see History Report for more
information). Click OK on the History Options dialog to open the History Report. The dialog has a Differences button that works the
same way as the Differences button on the History dialog. The History Report dialog also has a Print Latest Changes button.
The differences dialogs have a print icon you can use to print the current comparison.
Print Latest Changes
For every unique version of an item selected in the History Report dialog, the Print Latest Changes button prints the differences between the
selected version and the previous version. For example, if you have version 3 of an item selected, the Print Latest Changes button prints the
differences between versions 2 and 3 of the item.
If multiple items (or rows) are selected in the History Report, for all unique combinations of an item and its version number (for example,
AREA_A and version 4) a difference report is printed for that item comparing that version with its previous version (in this case, AREA_A
version 3 to version 4 differences). Multiple selections of a combination of item and version number are ignored. For example, if the list of
items looks like:
Item Version
AREA_A 4
AREA_A 4
AREA_A 3
AREA_A 3
AREA_A 2
MOD1 6
MOD4 9
MOD1 5
MOD99 1
and all rows were selected as shown, the output would consist of the following:
 Difference report for AREA_A from version 3 to 4
 Difference report for MOD1 from version 5 to 6
 Single page output for MOD99 that says: No differences between versions 0 and 1 for object System Configuration/Control
Strategies/AREA_A/MOD99. (The graphical differences report would show version 1 of MOD99 with no color highlighting.
If only the rows shown below were selected:
Item Version
AREA_A 4
AREA_A 4
AREA_A 3
AREA_A 3
AREA_A 2
MOD1 6
MOD4 9
MOD1 5
MOD99 1
The output would consist of the following:
 Single page output for MOD99 that says: No differences between versions 0 and 1 for object System Configuration/Control
Strategies/AREA_A/MOD99. (The graphical differences report would show version 1 of MOD99 with no color highlighting.
With one or more items selected in the History Report, click the Print Latest Changes button. The Latest Differences dialog opens.
Click a button to print the differences reports in text or graphically.
View Differences Graphically
For graphics, the system displays a diagram view containing a combination of all the elements in the two configuration items. The most
current version appears on top by default. The view shows the unchanged items without highlights, added items highlighted with green,
changed items highlighted with red, and deleted items highlighted with blue. The text above the graphics view indicates the two versions of
the item being compared.
The difference display enables you to transpose the graphic view of differences. This places the older version on top. Note that Added
elements such as function blocks (those that appeared in green when the newer version of the item was on top), will be highlighted in blue
when the older item is on top. Strictly speaking, these items have not been deleted. However when the system compares the two versions, it
recognizes that this item is absent from the older version and highlights the item in blue.
View Differences as Text
To see the differences in text, click the text button. The Textual Differences dialog opens. The view shows the unchanged items in gray, added
items highlighted with green, changed items highlighted with red, and deleted items highlighted with blue. The text above each pane of text
indicates the versions of the item being compared.
Print Differences Graphically
If you print difference reports the same information is displayed in slightly different form. The following shows how a graphical differences
view prints.
Print Differences as Text
The following figure shows how the textual differences prints.

Version Control History and Library Objects
Inside this topic
The following sections describe the behavior of version control history for items that are linked to objects in the library.

History for Class-Based Modules and Linked Composites
The values in class-based modules and linked composite modules are derived from objects in the DeltaV Explorer library. After creating these
module types from the library objects, users typically modify them to suit a specific control need. Such modifications are tracked in version
control history.
Class-based modules and linked composite modules also enable users to reset parameter values to the original values of the library objects.
The “Use default value from library object” check box resets a value to the value of the associated library object. This check box is available
for the editable parameters in the class-based module instance or linked composite.
Note how version control history indicates changes resulting from the Use default value from library object checkbox: resetting a parameter
value in this way simply removes the information about the parameter from the history view of the associated version of the object.
For example, L_TYPE is a configurable parameter in the instance of a module class. If you change the L_TYPE of the AI block in the module
instance by manually editing the properties of the parameter, version control history adds this change to the history because the value is no
longer derived from the class. The differences viewed from history would look similar to the following:
L_TYPE now has an override value because it is not derived from the class. A subsequent change to the override value of L_TYPE would
look similar to the following:
If the value of L_TYPE is reset using the “Use default value from library object”, the history for L_TYPE is deleted for the instance. The
L_TYPE parameter itself has not been deleted from the instance, but the value is now derived from the library default rather than from an
override in the instance.
When a parameter is actually deleted from a class or composite block, VCAT history indicates this in the same way. To determine if the
deleted information is the result of reverting to a library value or a deletion of a parameter in the class or linked composite, you must look at
the history for the class or linked composite rather than the instance.

History for Library Function Blocks
Modules in the Version Control database remain linked to the library function block definitions but also contain any values that have been
overridden. Understanding this relationship is helpful when viewing the Version Control history for a module.
For example, if you change the value of the GAIN parameter in a particular module's PID block, the change is made to that module. When
you check this change in and view history for the module, it appears that the GAIN parameter has been added to the module. This is because
the history is documenting the override of a value in the library definition for the PID block. The following graphic shows how the change is
displayed.
When you make additional changes to GAIN, these values appear as side-by-side changes since the parameter already exists in the previous
checked in version.
When a parameter value is reset to its default value the parameter appears to have been deleted from the module since the parameter once
again obtains its value from the library definition. This occurs when you import the module or perform a Version Control rollback or recovery
and the value matches the value in the library.
Recover/Purge
When you delete an item from the configuration database, the item is no longer visible in through the Version Control history. However,
deleting an item does not remove it from the Version Control database. You can restore deleted items using the Recover Purge command. To
recover an item, select its container item (the item one level higher than the item you want to recover) and click Tools | Version Control |
Recover/Purge. From the Recover - Purge dialog, select the item you want to restore and then click Recover. To remove an item from the
Version Control database permanently, select the item and then click Purge.
Version Control Labels
Labels mark a configuration or a specific item for later reference. There are two main types of labels:
 user-created labels
 download labels
In addition to these two types of labels, DeltaV software automatically labels all of the initial configuration items in the configuration database
when you enable Version Control.

User-Created Labels
The Version Control database enables you to mark either an entire configuration or a specific configuration for later reference or use. This
mark is called a label. For example, you might want to label a configuration prior to a significant change or a shutdown. The label can be
attached to all the configuration items, which makes it easy to restore that configuration at a later date using DeltaV Explorer. Refer to the
DeltaV Explorer help for more information.

Download Labels
The system labels downloaded configuration items. For example, when a module is downloaded to the controller, a download label is added
to the module. This allows you to track which configuration version is currently in the controller as well as which configuration version was in
the controller on a given date.
Version Control and Downloads
When you download configuration items, the system checks to see if any items are checked out. If you have the privilege to use the
VC_DOWNLOAD_CHECKEDOUT function, the system enables you to download the checked out items. Note that when you download
checked out items, the Version Control database does not have a record of the items. Therefore, the label applied to the version in the Version
Control database may not be the same as the item that was actually downloaded. Typically, you should check in items before downloading. If
items to be downloaded are checked out and the Download checked out items box is not checked, nothing is downloaded.
The download is cancelled if you do not have the necessary function privilege, or if you do not click the Proceed with download if items are
checked out check box. However, if you want to download the items that are checked out, the system downloads the version in the
configuration database.
Version Control Snapshot
Snapshot is a Database Administrator tool that captures a complete copy of your present configuration database and adds it to the Version
Control database. Unlike a check in or an add, snapshot does not affect the current versions of items in the Version Control database. Instead,
it makes the captured configuration database available to you at any time. This is useful since a rollback of an individual item to a previous
version might fail if it depends upon a library item, such as a composite block that has been deleted.
Snapshots are only visible when you select History from the DeltaV Explorer root. You can replace the existing configuration with a snapshot
by selecting the Version Control Snapshot tool in the Database Administrator. Select the Snapshot tool, and use the Restore option, and select
the desired snapshot. All items must be checked in before you can restore a snapshot.
When you restore a snapshot, the DeltaV system:
 deletes your current configuration database
 replaces your current configuration database with the snapshot
 synchronizes the configuration database with the Version Control database. Snapshot items that differ from those in the previous
configuration database are added to the Version Control database and marked as the most current version.
 labels the Version Control database
Synchronize Databases
The Synchronize Database tool in the Database Administrator application ensures that the latest configuration items in the Version Control
database are identical to those in the configuration database. More specifically, the Synchronize Databases tool does the following:
 deletes items from the Version Control database that have never existed in the configuration database
 creates items not found in the Version Control database that exist in the configuration database
 synchronizes the checked out state of the items, if necessary
 compares items' data. If items are different, the Synchronize tool creates a new version from the configuration database.
 labels the synchronized version of the configuration in Version Control database
The Synchronize Database tool is normally used when an abnormal situation has occurred in the Version Control database or when manually
attaching non-primary (active) VCAT databases (such as when migrating during an upgrade).
Backing Up the Version Control Database
When you back up the DeltaV configuration database using the Backup & Restore tool, the Version Control database is also backed up,
provided that the Version Control database is in the default location.
If you want to perform a backup without backing up the configuration database or you want to back up the Version Control database to tape,
you must perform a backup of the Version Control database through the SQL Server Management Studio. Be aware that when you use SQL
applications to restore the database, the backup copy of the Version Control database will overwrite the current Version Control database
resulting in the potential loss of Version Control history for your DeltaV configuration. In addition, you must run the Synchronize Database
Utility in the DeltaV Database Administrator application to ensure that the latest configuration items in the Version Control database are
identical to those in the configuration database.
Follow these instructions to back up the Version Control database with the SQL Server Management Studio:
1. Log in to the ProfessionalPLUS workstation as a DeltaV Administrator and as the Windows administrator.
2. Close all the DeltaV applications.
3. Use the SQL Server Mangement Studio database backup function. Documentation for this utility is available in the SQL Server online
help. The Version Control database is named VCAT_databasename.
4. Restore database using the SQL Server Management Studio.
Note Backing up the Version Control (VCAT) database to a destination drive that is not the SQL database's drive requires the MSSQLServer
and SQLAgent services to have access to the destination machine to perform the backup. In this case, the service accounts must be modified
with the Service Control Manager. The accounts must be changed from the default of SYSTEM to a Windows account that has access to
(permissions on) the destination machine (which must have a share) and is in the Administrators group on the DeltaV machine. An example of
such an account would be the DeltaVAdmin account if the destination machine is running DeltaV software or if the destination machine has
granted DeltaVAdmin access to the resource. Refer to Modify SQL Services Logon for more information.
Archiving the Version Control Database
Items in a Version Control Audit Trail database can be archived, restored, and cleaned from the database. Refer to the Version Control topics
for background information on Version Control. Only users with Windows Administrator privileges and VC_ADMINISTRATOR function
(normally granted with a key to the System Admin lock) can archive, restore, and clean Version Control databases. Refer to DeltaV User
Manager and DeltaV Security for information on user privileges.
Archiving a Version Control database allows you to reduce the database size by moving large amounts of Version Control data to an archive
file. Version Control databases can be archived by date and version and entire databases including graphics or graphics only can be archived.
Version Control databases can be archived to a hard drive anywhere on the network. Archiving an item removes the item's data from the
Version Control database. However, the archived item's history information is retained in the Version Control database and can be viewed
from Version Control history. Historical logs and comments are not archived; only data is archived. Version Control items that have been
previously archived (but not removed) can be restored to the current Version Control database. Refer to Restoring a Version Control Database
from an Archive.
More frequent archiving results in lower memory requirements and better restore performance.
Version Control databases can be archived, restored, and cleaned from the ProfessionalPLUS workstation only and only one instance of an
archive, restore, clean operation is allowed at one time.
Before attempting to archive a Version Control database, be sure that Version Control is enabled and a populated Version Control database
exists. Refer to Version Control for information on enabling Version Control and creating a Version Control database. You can continue to
use the DeltaV Control Studio and Explorer applications to edit items that have been checked out of the Version Control database while a
Version Control archive operation is in progress. However, you cannot check items into or out of the Version Control database while an
archive operation is in progress. Version Control Archive is available through the DeltaV Database Administrator application. Open the
DeltaV Database Administrator and double-click the Version Control Archive Database icon to open the Version Control Archive Database
dialog.
Version Control Archive Database Icon
You have the options of archiving an entire Version Control database or only the display items such as graphics in a Version Control database
and you can archive by date or by version. You can type in or browse to a valid location on the network to store the archive file. If you are
typing in a path to a remote location, be sure to use the UNC path (\\Servername\Sharename\Directory\Filename).
Dialog Box for Setting Archive Options
Tips: Be sure to keep track of the archive filename and location. You will need to provide this information later if you decide to restore the
archive. Also, it is recommended that you backup the Version Control database prior to archiving it. Depending upon the size of your Version
Control database, it could take several hours to create the archive.
Archive and remove by date
To remove and archive by date, select the Archive and remove by date option and use the drop down control to open a calendar from which
you can select a date. When this option is selected, the data for all versions of the items to be archived (selected in Archive Criteria 2) up to
and including the selected date are removed from the Version Control database and archived to the location specified. The current version of
each item remains in the Version Control database.
Archive and remove by version
To remove and archive by version, select the Archive and remove by version option and enter the number of versions that will be kept in the
Version Control database and not archived. The items selected for archive are removed from the Version Control database and archived to the
location specified. The current version of each item remains in the Version Control database.
Archive configuration items and display items
This option archives and removes the entire Version Control database by version or by date (selected in Archive Criteria 1). The archive is
saved to the specified location. The current version of each item remains in the Version Control database.
Archive display items only
This option archives and removes only graphics from the Version Control database by version or by date (selected in Archive Criteria 1). The
archive is saved to the specified location. The current version of each item remains in the Version Control database.
Restoring the Version Control Database from an Archive
Archived Version Control data that has not been purged from the Version Control database can be restored to the current Version Control
database. You can restore any or all items from a Version Control archive to the Version Control database. When a single item is selected for
restore, all versions of the item in the archive are restored. The Version Control Restore Database application is accessed from the DeltaV
Database Administrator application.
Version Control Restore Database Icon in Database Administrator
Double-click the Version Control Restore Database icon to open the Select Archive to Restore to Version Control Database dialog and type in
or browse to the archive file to be restored. If you are typing in a path to a remote location, be sure to use the UNC path
(\\Servername\Sharename\Directory\Filename). Archive files have a .ZIP extension.
After entering the archive file name, click OK to open the Restore Archived Items to Version Control Database.
Restore Archived Items to Version Control Database
Select the item(s) to be restored from the Available items list. To select an item, place the cursor in the grey box to the left of the item name
and click the left mouse button. Use the Add, Remove, Add All, and Remove All buttons to move the items between the Available items and
Selected items lists. When you have selected all the items that you want to restore, click the Restore button. The items in the Selected items
list are restored to the current Version Control database.
Restoring an archived item restores the data of all versions of that item. Restored items can be cleaned from the Version Control database.
Cleaning the Version Control Database
Archived items that have been restored to a Version Control database can be cleaned from the database. It is possible to clean a single restored
item, multiple restored items, or all restored items from the database.
Note If a Version Control item is purged from DeltaV Explorer, it cannot be restored with Version Control Restore. A Version Control item
purged through DeltaV Explorer is permanently removed from the database. (The user is informed through a system message that it is a
permanent removal.) On the other hand, if a Version Control item is removed from the Version Control database using Version Control
Cleanup, it can be restored with Version Control Restore.
Version Control CleanUp Database is available through the DeltaV Database Administrator application.
Version Control CleanUp Database
Double-click the Version Control CleanUp Database icon to open the CleanUp Version Control Database dialog.
CleanUp Version Control Database Dialog
Select the item(s) to be removed from the Items that have been restored list. To select an item, place the cursor in the grey box to the left of
the item name and click the left mouse button. Use the Add, Remove, Add All, and Remove All buttons to move the items between the lists.
Click the Cleanup button to remove all the items in the Selected items to clean up list from the current Version Control database.
It is possible to clean a single restored item, multiple restored items, or all restored items.
Version Control Error Conditions
The following table lists possible Version Control error conditions and corrective actions.
Version Control Error Conditions
Error Cause Corrective Actions

Error validating Version Either the Version Control Contact Customer Support.
Control database schema. database is from a different
The Version Control database DeltaV software version or the
schema .9 does not match the DeltaV software did not create the
code set schema 1.0. Version Control database
correctly.
[Microsoft][ODBC SQL Either the MS SQL server is not If the MS SQL Server is not
Server Driver][Named Pipes] running on the ProfessionalPLUS running, perform the following
machine or it is not correctly steps:
Specified SQL server not installed on the ProfessionalPLUS
found. machine. 1. Using the SQL Server Service
Manager, start the server on the
ProfessionalPLUS machine.

2. If the server fails to start, take
corrective action based on the
error returned.
If MS SQL Server 2005 is not
installed, reinstall SQL Server on
the ProfessionalPLUS
workstation by running the
Workstation Configuration
application and installing the
VCAT option.
[Microsoft][ODBC SQL Either the Version Control If the disk is unavailable, perform
Server Driver][SQL Server] database is on an unavailable disk the following steps:
(that is, one that is not mounted),
Device activation error. The the files have been deleted, or the 1. Take corrective action to make
physical file name [File files have been moved to another the disk available.
Name] may be incorrect. location.
2. Stop and restart the MS SQL
Manager using the MS SQL
Server Service Manager.

3. Use the SQL Server
Management Studio to verify that
the database in question is no
longer marked as suspect (gray
icon).
If the files have been deleted or
moved to another location,
perform the following steps:

1. Restore the Version Control
database from backup or move
back using Windows Explorer.

2. Stop and restart the MS SQL
Manager using the MS SQL
Server Service Manager.

3. Use SQL Server Management
Studio to verify that the database
in question is no longer marked
as suspect (gray icon).
If the database is marked as
suspect and exists from a
previous installation of DeltaV
software that has been removed
from the system, use SQL Server
Management Studio to delete the
database.
[Microsoft][ODBC SQL The Version Control database has Perform one of the following:
Server Driver][SQL Server] been removed from the SQL
Server. - Use the DbAdmin
Cannot open database Backup/Restore tool to restore the
requested in login configuration and Version
VCAT_fdb. Control database.

Login fails. or

- Open the SQL Server
Management Studio, select
Databases, and right-click
Restore Database.

or

- Disable and then enable Version
Control using Database
Administrator. Note that all
previous Version Control history
will be lost.
[Microsoft][ODBC SQL The SQL data files may have Refer to Increasing the Space
Server] limited free space and failed to Allocated for Version Control
automatically grow before the Data Files for information on
Timeout expired. timeout period. checking free space and resizing
the data files.
[Microsoft][ODBC SQL The SQL Server is not in a paused Start the MS SQL Manager using
Server Driver][SQL Server] state on the ProfessionalPLUS the MS SQL Server Service
machine. Manager.
SQL Server has been paused.
No new connections will be
allowed.
Failed to back-up Version To read the specific error and If the cause in the ERRORLOG is
Control's SQL database determine the cause of the access denied, then MSSQL
restriction, locate the file: Server's access to the destination
Note The configuration SQL_Results.txt in the machine (where the backup is
database will have been DeltaV\DVData\VCAT_Databases being written) is restricted.
backed up, but the VCAT folder.
database will have failed to Refer to the Modify SQL
be backed up. Also review the SQL error log for Services Logon and
clarification of the error, if needed. Backup/Restore topics for more
The file is located on the same information.
machine as the ProfessionalPLUS
in the MSSQL2K\MSSQL\LOG
folder and is named ERRORLOG.
You can also access this through
SQL Server Management Studio.
Increasing the Space Allocated for Version Control Data Files
The data files that support the Version Control Database are configured to automatically grow as needed with unrestricted file growth.
However, it is possible in some circumstances for the file space requirements to increase so quickly that the files are not automatically grown
to meet the need. The Timeout expired message is a possible indication of this condition.
If you receive a Timeout expired message, check the file size and increase it if necessary using the following procedure:
1. Click Start | Programs | Microsoft SQL Server | SQL Server Management Studio.
2. Browse to the Version Control database (for example, VCAT_DeltaV_System).
3. With the database name selected, right-click and select Properties.
4. On the Files page, review the space allocated to vcat_data, vcat_data2 and vcat_data3.
5. To increase any of the file sizes, click the Space allocated (MB) field.
6. Enter a file size twice the original size shown in the Space allocated column.
7. Click OK to exit the dialog, saving the changes.
8. Close SQL Server Management Studio.
n to open the CleanUp Version Control Database dialog.
CleanUp Version Control Database Dialog
Select the item(s) to be removed from the Items that have been restored list. To select an item, place the cursor in the grey box to the left of
the item name and click the left mouse button. Use the Add, Remove, Add All, and Remove All buttons to move the items between the lists.
Click the Cleanup button to remove all the items in the Selected items to clean up list from the current Version Control database.
It is possible to clean a single restored item, multiple restored items, or all restored items.
Version Control for DeltaV Operate Displays
Inside this topic
DeltaV Version Control and Audit Trail (VCAT) for Displays allows you to manage changes to displays, dynamo sets, and schedules by
retaining previous versions of these files. Version Control for DeltaV Operate utilizes the same rules and functionality as Version Control for
configuration and user security. Refer to the Version Control topics in Books Online to learn about DeltaV Version Control. The topics in this
section describe any specific information or instructions regarding Version Control for displays, dynamos and schedules.
Note Enabling Version Control for DeltaV Displays can take a considerable amount of time. This is in addition to the time it takes to enable
just Version Control. The time it takes to enable Version Control for DeltaV Displays increases with the number of pictures and also the size
of the pictures (that is, the file size).
DeltaV Operate with Version Control Enabled Considerations
The following lists the basic considerations to know when using Version Control for DeltaV Operate.
 When VCAT for DeltaV Operate is enabled or disabled, you must download the ProfessionalPLUS.
 All graphics files can only be changed, deleted, and moved using DeltaV Operate. You can check the files in and out of VCAT using
DeltaV Explorer. Do not attempt to manage these files from any other applications.
 After you have completed your edits of a display file, to use it in your runtime environment you must save and close the file, check the
file into VCAT, download the ProfessionalPLUS and all workstations where the operator graphic are used, then switch DeltaV Operate
to run mode.
 When changing Version Control preferences, you must stop and re-start DeltaV Operate in configure mode to re-initialize the
application with the new preferences (for example, enabling/disabling AutoCheckIn/Out). DeltaV Operate initializes all preferences on
startup only.
 When you rename a file in DeltaV Operate (and Version Control is turned on), the change is not recognized in other Operater Stations
that have DeltaV Operate currently open. You must restart DeltaV Operate in all the workstations to update the system tree. It is the
initialization process that populates the DeltaV Operate system tree.
 You must use DeltaV Explorer to check the files in to VCAT unless Auto CheckIn/Out is enabled.
 When using Version Control for DeltaV Operate, do not enable Remote Desktop. DeltaV Operate will warn you that it is enabled and
only open in run mode, where you cannot edit or create any graphics. Refer to the DeltaV Remote Client topic for more information on
enabling/disabling Terminal Services.
 When using Version Control for DeltaV Operate, you cannot edit or create any graphics from a Remote Operator Station.
 When disabling VCAT for DeltaV Operate Displays, you must download the ProfessionalPLUS and all workstations. This sends the
new setting (of disabled) to all the workstations.
 When VCAT for DeltaV Operate Displays is enabled, a copy of all the graphics files (.GRF, .PDS and .EVS) are stored in the DeltaV
configuration database. If VCAT for DeltaV Operate Displays is subsequently disabled, the graphic files remain in the database as a
copy that cannot be accessed. However, those files will make the database (and any export of the full database) substantially larger than
without the files.
 When importing an FHX file that contains displays, you will see the displays listed in the import log even if VCAT for displays is not
enabled on the current database.
 The Auto Check-Out feature only applies to the .GRF, .PDS and .EVS files. Any files that are not .GRF, .PDS, and .EVS must be
checked out (and in) manually from DeltaV Explorer.
DeltaV Operate File Types Managed by Version Control
The following DeltaV Operate file types are managed by Version Control.
 GRF = Display
 FDS = Dynamo Set
 EVS = Schedule
When viewing these files in DeltaV Operate, the system tree shows the following organization of files.
When viewing these files in DeltaV Explorer, the system tree shows the following organization of files. All Schedules are in the PDB folder.
The Dynamo sets (.fds) are found at the root of the PIC folder in DeltaV Explorer. All other files are in the same structure as found in DeltaV
Operate, that is, under the PIC folder (which is named Pictures in DeltaV Operate).
Important Do not move, copy, create or in any way manage these files using any Windows application, such as Windows Explorer. DeltaV
Operate and VCAT will not respond correctly to such changes.
DeltaV Operate File Locations with Version Control Enabled
With Version Control enabled, there is a difference on where DeltaV Operate looks for files you are editing. This is an important difference
from how DeltaV Operate functioned previously; however, DeltaV Operate retains the same tree structure as before.
With VCAT enabled, checked-out versions of any DeltaV Operate source files always reside on the ProfessionalPLUS machine in a working
directory (DVData\DisplayWorking). VCAT places the file there when you check the file out. You are able to edit checked-out files from
other DeltaV workstations through DeltaV Operate in configure mode because the non-ProfessionalPLUS workstation connects to the
ProfessionalPLUS machine and accesses the files in the ProfessionalPLUS's working directory.
However, when DeltaV Operate is in run mode, you are running the files in the local machine's graphics folder. Therefore, if you are editing a
checked-out file on a non-ProfessionalPLUS machine, you must first check the file back into Version Control and download the
ProfessionalPLUS and that workstation before switching to run mode to use the edited version of the file. Checking the file back into VCAT
allows the file to reside in a central storage location. Downloading the workstation's Setup Data places the current Version Control copy of the
file on the workstation. If you download the workstation without having checked in the edited file, you will not see the current changes.
Those changes still exist on the ProfessionalPLUS machine's working directory as that is where you were making the edits.
Additionally when Version Control is enabled, the picture path in the System Configuration Utility displays the ProfessionalPLUS's working
directory. When Version Control is disabled, this path will be the same as the local graphics directory for that workstation.
Starting DeltaV Operate with Version Control Enabled
FlexLock provides one button for launching DeltaV Operate. This button always launches DeltaV Operate in the mode you configured in the
Workspace | User Preferences | General tab. Additionally, the Start Menu provides two methods of starting DeltaV Operate; one to start
DeltaV Operate in configure mode (Start | DeltaV | Engineering Tools | DeltaV Operate Configure), the other to start DeltaV Operate in
run mode (Start | DeltaV | Operator | DeltaV Operate Run).
You can also launch DeltaV Operate from DeltaV Explorer when Version Control is enabled from either the Object menu or the right click
menu. To launch DeltaV Operate configure mode from the Object menu, select a file, go to the Object menu and select Open with DeltaV
Operate. To launch DeltaV Operate configure mode from the right click menu, select any DeltaV Operate file (display, dynamo, or schedule)
and right click. Select Open in DeltaV Operate. Both methods always opens the file in DeltaV Operate configure mode.
Note you can not quick switch between configure and run modes in DeltaV Operate with VCAT enabled.
Changes to User.fxg for Version Control
The following changes were made to the User.fxg file in support of Version Control for DeltaV Operate:
frsControlWPrivChk() is now being called instead of frsUserConfigPrivChk()
Public Sub FixGlobals_CtrlW()
'Disables switching from run mode to configure mode
If frsControlWPrivChk Then
'this function will switch modes, but use the event in the
'scheduler to ensure a clean switch
frszSwitchMode Nothing
'Application.SwitchMode intIFIX_CONFIG_MODE
End If
End Sub
Downloading DeltaV Operate Files with Version Control Enabled
Whenever new or modified files have been checked into the Version Control database, you must download the setup data to the
ProfessionalPLUS first and then to all Operator Stations. You can also download all workstations at the same time by downloading the
Control Network. This takes the current files (that is, the most recent files stored in the Version Control database) and places a copy of them
on the workstations. When DeltaV Operate is in run mode, the displays being used are on the local machine. Therefore, if the workstation has
not been downloaded, it will not have the most current files.
The ProfessionalPLUS workstation must be downloaded first (or with the other workstations). The ProfessionalPLUS behaves as a
configuration machine and also as an operating machine. Therefore, once the files are checked into the Version Control database, the working
directory on the ProfessionalPLUS is no longer active. The ProfessionalPLUS uses its local running directory updated with the current files
from the Version Control database, the same as any other workstation.
There is an option on downloading to allow downloads of checked out items. This allows you to download files to each workstation, even
though they are checked out of the Version Control database. However, you are not downloading the version of the file that is being worked
on. You are downloading the last version of the file prior to being checked out. The logged in user must have the
VC_DOWNLOAD_CHECKEDOUT key to select this option. Refer to Version Control Functions and Locks topic for more information.
Important You must download the ProfessionalPLUS and all workstations after enabling or disabling Version Control.
Uploading DeltaV Operate Files when Enabling Version Control
You are prompted to upload files in the following circumstance:
when you enable Version Control for Displays and
there are multiple DeltaV workstations containing operator graphics and
the graphics on the non-ProfessionalPLUS workstations are more recent than the ones existing on the ProfessionalPLUS, or they do not
exist on the ProfessionalPLUS.
The upload process checks the Graphics-iFIX directories of all workstations on the DeltaV system and compares the files against the
ProfessionalPLUS workstation's Graphics-iFIX directory. The upload process then will take any new files and any existing files that are more
recent (than the ProfessionalPLUS' copy) and copy it to the ProfessionalPLUS workstation's Graphic-iFIX directory. The Version Control for
Displays working folder resides on the ProfessionalPLUS and is created from the contents of the ProfessionalPLUS' Graphics-iFIX directory.
Therefore, if you want these files to be included as the VCAT source, upload the files. If you do not want these files to be included as the
VCAT source, do not upload them.
You must always download the ProfessionalPLUS machine after enabling Version Control for Displays. However, you must also download
the other workstations if you have uploaded any files. The download order is important; download the ProfessionalPLUS first and then
download the other workstations. You can also download all workstations at one time by downloading the Control Network.
Creating New DeltaV Operate Files with Version Control Enabled
New files (displays, dynamos or schedules) can only be created from DeltaV Operate. When a new file is created, the template is opened and
the new file is created from the template when you select the Save As option from the file menu. This is the normal process for creating a new
graphic, schedule or dynamo set.
Note Do not use Save on the templates as this can overwrite the existing template (if checked out). A dialog reminding you to use Save As is
displayed when you check out a template file.
When you close the new file, Version Control adds the file to the database and automatically checks the file out. This is true even if
AutoCheckIn/Out is not enabled. You can see the new file in DeltaV Explorer at this time. If AutoCheckIn is not enabled, you must check the
file in from DeltaV Explorer when done editing it.
You cannot create a file with the same name as another file with Version Control enabled, unless that file is checked out. If you do enter an
already existing name a dialog first warns you that you are using an existing name and then you are warned that you cannot overwrite the file.
You must give the file a unique name. However, if the file is checked out, you can overwrite that file. This does not create a new file, it
merely overwrites the existing file.
Important Files can be copied, deleted, renamed, and edited in DeltaV Operate ONLY. When opening a file from DeltaV Explorer, DeltaV
Operate is launched in configure mode.
Opening Existing DeltaV Operate Files with Version Control Enabled
Graphics files can only be opened in DeltaV Operate. DeltaV Operate is also the only application you can use to modify the files, delete the
files or create new files. This is true when VCAT is enabled or disabled. When you open a file in DeltaV Operate, DeltaV Operate locks the
opened file. This prevents multiple people from editing the same file.
When Version Control is enabled, only one user can check out any given file at a time. That user has control of the file until it is checked back
in to the Version Control database. At that point, another user can check the file out. However, other users can open the file in read-only
mode. This enables other users to see the file, but not change and save the file.
When AutoCheckOut (or AutoCheckIn/Out) is enabled, the files are checked out for you when you open them in DeltaV Operate.
When Manual Checkout is enabled and you open (in DeltaV Operate) a file that is not already checked out, you are prompted to either check
out the file or open it as read-only. If you open the file as read-only, you can perform a Save As and create a new file that is a copy of the
opened file but with a new name. When you close the file, it is then added to the Version Control database. The original file is left intact with
no changes.
Deleting DeltaV Operate Files with Version Control Enabled
Deleting DeltaV Operate files is the same with Version Control for Displays enabled or disabled. You must delete the pictures using DeltaV
Operate; and, you must delete the same files from each DeltaV workstation where the files exist.
Viewing DeltaV Operate File Differences with Version Control Enabled
VCAT show the differences between versions of the same file. When showing the differences of a graphics file, VCAT lists the description,
user who modified the file, the modify date, and the document size. VCAT does not list the actual change to the graphic or to the underlying
script. To better track those differences, add comments to your files as you check them into VCAT.
You can compare files two ways; between the configuration database and the VCAT database, and, between two versions of a file within the
VCAT database. To show differences between the configuration database and VCAT, select a file in DeltaV Explorer, right click and select
Version Control | Differences. To show differences of two files within the VCAT database, select the file, right click and select Show History.
From the history dialog, select two versions of the file using Ctrl-click and click Differences.
Syncing the Version Control Database and the Working Directory
If the files in the working directory are not in sync with the Version Control database, you can choose to synchronize the displays. Open
DeltaV Database Administrator and select Version Control Sync Database. Select the Synchronize Version Control Database for DeltaV
Displays option. Click the Synchronize button.
Recovering DeltaV Operate Files with VCAT Enabled
Version Control for Displays allows you to recover a file from the VCAT database. Therefore, if a file is deleted from a workstation you can
recover it from the VCAT database.
Select the top level component (for example, DeltaV Displays) right click and select Version Control | Recover Purge. Select the file and click
Recover.
Importing and Exporting DeltaV Operate Files.
With Version Control for Displays enabled, the DeltaV Operate files are listed in DeltaV Explorer. Therefore, you can export these files using
DeltaV Explorer's import and export functions.
When Version Control for Displays is not enabled, the DeltaV Operate files are not listed in DeltaV Explorer. Therefore, you cannot export
these files.
There are a couple of considerations when importing DeltaV Operate files.
 Version Control for Displays stores a copy of the graphic in the DeltaV database. This can make the database size large. Any full
database exports from a system with Version Control for Displays enabled includes those graphics, making the FHX files large.
Additionally, importing such an FHX file will increase the size of the new database, regardless of the state of Version Control for
Displays.
 If you are importing a complete database from a DeltaV system that had VCAT for Displays enabled (at any point), the FHX file
contains copies of those display files. When the FHX file is processed, the import log lists the graphics files as being imported.
 If you are importing from a DeltaV system that has VCAT for Displays enabled into a system does not have VCAT for Displays
enabled, you will not see the DeltaV Operate files in DeltaV Explorer.
 If you are importing from a DeltaV system that has VCAT for Displays enabled into a system that also has VCAT for Displays enabled,
and you have files of the same name but with different dates, you are prompted to overwrite existing files (yes or no).
Manually Copying DeltaV Operate Displays into a System with VCAT Enabled
There are times when you will need to copy a display file from one DeltaV system to another DeltaV system (for example, when creating
DeltaV Zone capable displays). To do this when Version Control for Displays is enabled, follow these steps:
Important You cannot rename any DeltaV Operate files using Windows Explorer. All files must be renamed from within DeltaV Operate
using the Save As function. Renaming using Windows Explorer or any method other than DeltaV Operate makes that graphic unusable by
DeltaV Operate.
1. Copy the file from the source workstation to the destination workstation using Windows Explorer (you may need to use a storage device
such as a memory stick if the two systems are not connected).
2. Paste the file into the DeltaV\DVData\DisplayWorking\Pic folder on the destination workstation (the one that has VCAT for DeltaV
Displays enabled).
3. Open DeltaV Operate on the destination workstation.
4. From the DeltaV Operate system tree in the Pictures folder, open the picture that was just pasted into the DisplayWorking\Pic folder.
5. Close the picture. Version Control for DeltaV Displays adds that picture to the VCAT database.
Continue with all pictures you added to the destination workstation so they are added to the VCAT database. You can then download your
workstations to propagate the displays to the Operator Stations.
Version Control for Documents
Inside this topic
DeltaV Version Control and Audit Trail (VCAT) for documents makes it possible to use the DeltaV database to manage changes to any type
of document or file by retaining previous versions of these files. Version Control for documents is similar in functionality to Version Control
for configuration and user security. Refer to the Version Control topics in Books Online to learn about DeltaV Version Control. The topics in
this section describe any specific information or instructions regarding Version Control for documents.
Introduction
To use VCAT for documents you must set working folders (directories on a hard drive accessible from the workstation) to hold documents
while you are working on them. After setting working folders you do not need to use Windows Explorer to navigate to the documents to work
on them. Because the documents are also in the DeltaV database, you can access all documents from DeltaV Explorer. That is, from DeltaV
Explorer you can check documents out of VCAT, edit the documents, save the documents, and check them back in to VCAT.
Note You cannot save documents larger than 25 megabytes. An error message appears if you attempt to save documents larger than this limit.
Setting Working Folders
Before you can store documents in VCAT and work on them from DeltaV Explorer, you must create a folder hierarchy in DeltaV Explorer
and move the documents you want to store in VCAT into that hierarchy. The folder hierarchy you create can be arbitrarily complex,
consisting of as many subfolders as you need. You can explicitly set a different working folder for each folder in DeltaV Explorer.
Alternatively, You can create a working folder structure that mirrors the folder hierarchy in DeltaV Explorer. A simple way to do this is:
1. Select the Documents folder and select Set Working Folder from the context menu.
If the working folder has not been previously set, the Browse For Folder appears as shown.
2. Navigate to the location where you want to create a working folder structure, the click Make New Folder.
A new folder appears in the dialog. Select Rename from the context menu and enter the name you want for the working folder, for
example, VCAT_WORK as shown in the following figure.
3. Click OK to accept the name and close the dialog.
Note Each user must set working folders on each workstation. The working folders can be different for each user and each
workstation.
4. Create the DeltaV Explorer folder hierarchy you need.
Select the Documents folder (or folders you created), then select New | Document Folder from the context menu. Folders are created
named Document Foldernn. You can rename the folders.
5. Add documents to the hierarchy in DeltaV Explorer.
There are several ways to add documents to the hierarchy in DeltaV Explorer:
 Select a folder and then select New | Text Document. You can rename the document after you created it.
 Select a folder and then select Add Documents. The Add Documents dialog appears. Navigate to documents then click Add.
 Drag and drop documents of any type from Windows Explorer to a folder in DeltaV Explorer.
Creating subfolders and adding documents to them in the DeltaV Explorer Documents folder adds them to the DeltaV database and the
VCAT database. When you add documents they are automatically checked out of VCAT.
Before you edit a document you must set the working folder for the directory the document is in and retrieve the document. You can set
the working folders for the entire Documents folder hierarchy in DeltaV Explorer and retrieve all the documents in the hierarchy at one
time as follows.
6. Select the Documents folder and select Retrieve from the context menu.
The Retrieve Documents dialog appears with the working directory you previously set for the Documents folder.
7. Select Recursive on the dialog.
8. Click OK.
Because you have not set a working folder for the subfolders, the following dialog appears:
9. Click Yes All to create all of the subdirectories in the working folder and retrieve all the documents in the hierarchy.
If you subsequently add subfolders, working folders are set to the appropriate place in the working folder structure. You must still retrieve
new folders and any documents you add, to new folders or existing folders, before you can edit these documents.
Note If you change a folder name in DeltaV Explorer after setting a working folder for it, the links to the working folders are retained.
The following figure shows an example folder hierarchy consisting of two subfolders below the Documents folder. The SOPs directory
contains an Excel workbook and three text documents. The Contents pane contains information about the documents in the current folder. For
example:
 dsts.xls is checked in (no check mark) and was last modified by user U1.
 SOP1.txt is checked out to the current user (red check mark).
 SOP2.txt is checked in (no check mark) and was last modified by ADMINISTRATOR.
 SOP3.txt is checked out to another users (blue check mark), U1 in this case.
Editing Documents
After you have created your Documents folder hierarchy, populated it with documents, set the working folders, and retrieved the documents,
you can edit documents. Edit documents only after you have checked them out or have determined they are already checked out to you.
VCAT for documents allows you to open documents from DeltaV Explorer whether they are checked out to you, checked out to someone
else, or not checked out at all, but you may not be able to check them in and could end up with three versions of a document: VCAT's copy,
DeltaV Explorer's copy, and the copy in your working directory. It may take some effort to resolve such a situation. If you establish the habit
of editing only documents checked out to you, you can avoid such situations.
The most straightforward way to manage documents is:
1. Make folder containing the document has a working folder set.
2. Check the document out of VCAT from DeltaV Explorer.
3. Retrieve the document from DeltaV Explorer.
4. Open the document from DeltaV Explorer.
The document opens in its associated application. If the application is not found, you are prompted to select an application.
5. Edit the document.
6. Save the document in its application (this saves the document to the working folder) and close the application.
7. An Exploring DeltaV popup appears saying the document has been modified and asking if you want to save it to the database now.
Clicking Yes on this dialog saves the document to the DeltaV database. Clicking No does not save it to the DeltaV database and the
versions of the document in the DeltaV database and in the working folder are now different.
8. Check the document back in to VCAT.

Version Control and DeltaV Upgrade
Inside this topic
Version Control and Audit Trail (VCAT) has features you can use to determine if database object versions were incremented as a result of an
upgrade or because of user configuration changes. The rest of this section explains how.
Introduction
Note To use Version Control histories and comparisons to determine which version changes are due to an upgrade of DeltaV software, you
must have followed the upgrade instructions in the root directory of the DeltaV Installation disk.
Synchronizing the VCAT database after upgrading DeltaV software can increment the VCAT version of configuration objects. Incrementing
the version maintains the history on changes made by the DeltaV Database Migration Utility, which is run during an upgrade. Synchronizing
VCAT also catalogs any new elements of the configuration introduced in the latest version of the DeltaV software (for example, new
functionality).
These version changes are always visible in subsequent VCAT comparisons, but are not marked as being due to an upgrade unless you have
performed the following tasks:
 Check in all items before beginning the upgrade.
 Enable VCAT when prompted during upgrading your DeltaV system.
 Select Yes to request Enhanced Version Incrementing on the Database Administration dialog that appears.
You must perform these tasks to mark all version changes resulting from the upgrade. If you do not perform these tasks some changes caused
by the upgrade do not appear until you check items out and back in. You will be unable to easily determine if these changes are the result of
configuration changes or the upgrade.
Detecting Changes Due to Upgrades
The features of VCAT that are useful when determining the cause of changes after an upgrade include:
 Labels for upgrade start and completion
 Labels for items changed by the upgrade
 A (U) indicator in the Version column of Histories and History Reports to indicate a change is the result of the upgrade.
After the upgrade is complete, use the VCAT history report dialog to determine where there are version changes due to the upgrade. For
example, the following figure shows that several AREA_A items changed as a result of the upgrade (they have (U) next to the version number
and the action column message is Checked In - Due to Upgrade). You can now use the VCAT differences views to examine the changes
caused by the DeltaV upgrade. For more information on using this dialog and other methods to view differences between versions, refer to
Item Differences.
Recommended Maintenance Practices
Inside this topic
When using the DeltaV system, there are certain practices that we recommend. Performing these tasks will enhance your system's
performance and preserve your information. The following sections describe these recommended practices.
Auto-Logon/Logoff
When setting up workstation security, one of the considerations is what happens to idle sessions, particularly on dedicated operator sessions.
There are additional considerations when setting up remote client sessions, such as what happens if communications are disrupted.
In addition to Windows Terminal Server and other Windows settings, there are two DeltaV features that affect DeltaV behavior after a screen
saver timeout or disconnect:
 DeltaV screen saver
 FlexLock DeltaV Autologon
Unlike other screen savers, the DeltaV screen saver does not blank the screen or display an alternate graphic. Instead, it provides an idle
timeout and two choices of action to take when the timeout expires. You can specify to log off the current user or log on another user when
the idle time elapses. If you specify a user to log on, this user is also logged on whenever a user logs off of the DeltaV system.
Note Most screen savers are not compatible with the DeltaV system. For this reason, Emerson Process Management recommends that you
either use only the DeltaV screen saver or do not use a screen saver at all.
FlexLock DeltaV Autologon automatically logs a user in to the DeltaV software when he logs in to Windows (if his account is both a
Windows and DeltaV account). If another user logs on to the DeltaV system, then logs off, Autologon logs the original Windows user on to
the DeltaV system. When DeltaV Autologon is enabled, there is always a DeltaV user logged on (if the user logged on to Windows is a valid
DeltaV user).
In addition, users who are logged on through terminal sessions are not logged off of their DeltaV session if the connection is temporarily
disrupted. When the connection is regained, these users' DeltaV sessions continue, subject to the limitations of the timeouts set in Windows
Terminal Server. If another DeltaV user has logged on to DeltaV after the original Windows user, the second user is logged off after a
disconnect or timeout and the original Windows user is logged on.
Note If you have DeltaV Autologon enabled and you have specified a Log On User with the DeltaV screen saver, the user specified in the
screen saver is logged on to the DeltaV system when a user logs off.
One way to use the FlexLock DeltaV Autologon for dedicated Operator Stations is as follows:
1. Create a generic user in DeltaV User Manager.
2. Assign this user one key that has no function security associated with it (by default, none of the User Locks have associated function
security).
3. Enable DeltaV Autologon.
4. Set up the DeltaV screen saver and select Log Off User.
When this generic user is logged on to Windows it is also logged on to DeltaV software. This user cannot operate anything, but alarms are
visible at the console. An operator who needs to perform a task can log on to DeltaV software. After he completes his task he can log off or let
the DeltaV session time out and the generic user is logged back on.
The steps required to implement these combinations depend on if you are concerned only with standalone dedicated Operator Stations or
remote sessions. If you are configuring for remote sessions, it also makes a difference if your terminal server software is Windows Server
2003 or Windows Server 2008. For detailed information refer to Using DeltaV Screen Saver and DeltaV Autologon.
Alarm on Low Disk Space
Low disk space on the ProfessionalPLUS workstation can corrupt the database. It is recommended that you create an alarm to notify you
when the disk space on the ProfessionalPLUS workstation drops below a certain level. A sample module, MONITOR_FREEDISK, is
included in DeltaV\Samples and can be used as a starting point to create the alarm. In the sample module, the alarm priority is set to Log when
the disk space on the ProfessionalPLUS workstation drops below 400 Mbytes and Warning when it drops below 200 Mbytes. The alarm
priority can be increased depending upon your needs.
In the DeltaV Diagnostics application, the FreeDisk parameter on the ProfessionalPLUS workstation shows the amount of free space (in
megabytes) on the disk.

Disk Check
Perform a disk check whenever Windows shuts down abruptly (without using the normal shutdown procedures). Use the following steps:
1. Start the Windows Explorer by selecting Start | Programs | Accessories | Windows Explorer.
2. Select the disk (s) where the DeltaV software and database reside. (If the software and database reside on two disks, perform these steps
separately for each disk.)
3. Click the right mouse button and then click Properties. The Local Disk Properties dialog appears.
4. Click the Tools tab. Then, click Check Now in the Error-checking pane.
5. Select both check boxes, as shown in the following figure.
6. A system message appears stating that you cannot get exclusive access to the disk and asking if you want to perform error-checking
restart. Click Yes.
7. Restart the computer. This runs the disk check.

Monitoring the Hard Drive Space
The FreDisk parameter shows the amount of free space (in megabytes) on the drive of the selected workstation where the DeltaV DVData
directory is installed. For controllers, the value of this parameter is always 0.
Note To avoid problems with the database, it is recommended that you create an alarm to notify you when the disk space on the
ProfessionalPLUS workstation drops below a certain level. A sample module, MONITOR_FREEDISK, is included in DeltaV\Samples and
can be used as a starting point to create the alarm.

Running Chkdsk
To aid in Windows, file system, or hard drive failure prevention or early warning, it is recommended that you run Chkdsk periodically and
reinstall the supported service pack each time a software change is made to the system.
Chkdsk is Windows' built-in file system error detection and repair utility. Running it scans the physical drive surface, checks each file, and
looks for problems on the hard drive. Run Chkdsk periodically to safeguard against data loss.
Running Chkdsk includes restarting a Windows workstation. Before performing this procedure, make sure of the following:
 All DeltaV applications on the workstation are closed.
 Your process is either properly shut down or being controlled by another node.
 You have adequate time to complete the procedure.
 If you are performing this procedure on a ProfessionalPLUS workstation, close all of the DeltaV Engineering Tools on all workstations
on your DeltaV network.
If you are unsure about any of the above requirements, call Technical Support.
To run Chkdsk, perform the following procedure:
1. Click Start | Programs | Accessories | Command Prompt.
2. From the command prompt, enter the following:
CHKDSK c: /f /r
A message appears stating that Chkdsk will run the next time that the system is restarted.
3. Restart the workstation.
4. Upon restart, during the blue screen portion of the process, Chkdsk will run. Chkdsk can take five minutes or longer if problems are
found on the drive.
5. Once you are finished, log on to Windows.
6. Click Start | Settings | Control Panels | Administrative Tools | Event Viewer.
7. If the top line of the Event Viewer windows does not read, "Event Viewer - Application Log on \\computer name", click Log |
Application.
8. An entry labeled Autochk appears in the log that correlates to the last boot process. Double-click the entry to view the results of the
Chkdsk.
9. If no errors are reported in the log, you are finished.

If errors are reported in the log, perform this process again.
10. If an error occurs the second time you run Chkdsk, you might have a hard drive media problem. Call Technical Support immediately.
If no errors occur the second time you run Chkdsk, Chkdsk has successfully corrected any problems it found.

Reinstalling Windows Service Packs
Configuration changes and loading of software can cause an older version of a file, (for example, a *.dll) to be copied back into the
configuration. This may require the reinstallation of a service pack included with the DeltaV software. Only install service packs that are on
the DeltaV software CDs. They have been tested with the DeltaV software.
The following procedure includes restarting a Windows workstation. Before performing this procedure, make sure of the following:
 All DeltaV applications on the workstation are closed.
 Your process is either properly shut down or being controlled by another node.
 You have adequate time to complete the procedure.
 If you are performing this procedure on a ProfessionalPLUS workstation, close all of the DeltaV Engineering Tools on all workstations
on your DeltaV network.
To install a service pack, browse to the Service Pack directory on DeltaV disk 1. There are service packs for dotNET servers and for
workstations. Install the appropriate service pack.

Emergency Repair Disk
The Windows Repair Disk utility protects Windows system settings by creating an Emergency Repair Disk (ERD) from which to restore a
workstation's configuration and security settings in case of a system failure. Create and update the ERD after making any significant changes
to the hardware or software setup or adding Windows accounts.
Note Installing DeltaV software, running Workstation Configuration, or running the DeltaV User Manager can change software settings or
add Windows accounts. Also, most of the Windows programs located in Control Panel as well as the Windows User Manager program in
Administrative tools can change the workstation's software settings. It is recommended that you create a new Emergency Repair Disk after
running any of these applications.
Note The Emergency Repair Disk does not create a system backup or a DeltaV backup. Do not use the Repair Disk utility in place of a
backup tool.
Online Windows documentation steps you through the creation of an ERD. To view these instructions, click Start | Help and enter ERD under
the Find or Index tab.

Backup and Restore
Caution It is vital that you maintain frequent backups of your DeltaV system's configuration.
Performing regular backups enables you to restore information that otherwise would have been lost in a catastrophic system failure, such as a
hard disk crash, accidental user deletions, operator error, and so on. Include the following items (at the minimum) in your configuration
backup:
 the controller's configuration
 operator displays
 historical configuration
 historical data archives; refer to the System Configuration manual for more information
 Batch Historian data; refer to the Backing Up the Batch Historian Data topic for more information
Perform a backup for any data that you change. Back up daily until you are no longer changing the data. Store several of the most recent
backups in a safe location free from environmental hazards (such as extreme heat, extreme cold, dust, or magnetic devices, including speaker
phones).
Refer to the DeltaV Administrator Tools Backup and Restore function for more information on backing up and restoring your DeltaV System.
Caution If you do not back up the control configuration, operator displays, and historical configuration on a regular basis, you do not have the
resources to restore the DeltaV system to its previous state.

NIC Binding Order
Windows binds communication protocols to the physical Network Interface Cards (NIC) in a particular order. That order can affect the
performance of engineering a DeltaV system. Refer to XPHelp.chm or VistaHelp.chm, located on the DeltaV installation disk #2 in the
_Support directory, for more information.

Synchronizing Time Stamps after Changing the Time Zone
After you change the time zone you must stop and restart the DeltaV Database Server to ensure that time stamps in the system are correct.
From any workstation:
1. Close any DeltaV applications
2. Select Start | DeltaV | Engineering | Database Administrator.
The DeltaV Database Administrator dialog opens.
3. Select File | Shutdown Server... to stop the Database Server.
4. Click OK on the Shutdown Server dialog that appears.
5. Wait until the text in the status line of the Database Administrator dialog is Database Server is shutdown, then select File | Connect to
Server to restart the Database Server.
If time stamps are not correct after completing these steps it may be necessary to restart the workstation.
Using DeltaV Screen Saver and DeltaV Autologon
Inside this topic
This topic provides detailed instructions for using DeltaV Screen Saver and FlexLock DeltaV Autologon to achieve specified behavior when a
DeltaV user logs off, the DeltaV screen saver times out, or a remote session is disconnected. The following table indicates which setup to use
to achieve a particular result depending on your DeltaV platform.
To achieve this result... On In Server 2003

Workstations Remote Sessions
Use this setup...
At DeltaV screen saver timeout, log off current DeltaV
user leaving <none> logged on. Workstation Server 2003
At DeltaV screen saver timeout, log on a specified Setup 1 Setup 1
DeltaV user.
At Windows log on, automatically log on DeltaV user
(Windows user and DeltaV user are the same).
Workstation
At DeltaV screen saver timeout, log off the current Setup 2
DeltaV user and log on the Windows user (if the
Windows user is also a DeltaV user).
If the Windows user was automatically logged on to
DeltaV at Windows log on, and the remote session Server 2003
becomes disconnected, keep the current DeltaV user Setup 2
NA
logged on (until the system idle timeout elapses). If the
connection is regained the DeltaV user's remote session
continues without interruption.
If a DeltaV user has logged on after the initial
automatically logged on Windows user and the session
NA
becomes disconnected, log off the current DeltaV user
and log on the original Windows user.
Note When setting up the DeltaV screen saver in any of the setups, make sure the On resume... check box is not selected.
XP and Vista Workstation Setup 1
Setting up the screen saver on XP and Vista workstations is similar.
To set up the DeltaV screen saver:
1. Log on to the workstation with a Windows account that DeltaV users log on to DeltaV software from.
The Windows user must have Windows desktop access.
2. Open the Windows Screen Saver properties dialog.
3. In the Screen saver field, select DeltaVScreenSaver.
4. Enter a Wait time.
5. Make sure the check box is not selected.
In XP, the check box text is On resume, password protect. In Vista the check box text is On resume, display logon screen.
6. Click Settings.
7. Select Log Off User or fill in the Log On User information depending on your requirements.
8. Click OK.
9. Click OK on the Display Properties dialog to accept your changes and close the dialog.
10. Repeat steps 1 through 9 for all other Windows accounts used to host DeltaV logons.
XP and Vista Workstation Setup 2
Setting up the screen saver on XP and Vista workstations is similar.
To set up the DeltaV screen saver and DeltaV Autologon:
1. Log on to the workstation with Administrator privileges.
2. Enable DeltaV Autologon from the FlexLock system menu.
3. Log in to the workstation with a Windows account that DeltaV users log on to DeltaV software from.
6. Enter a Wait time.
7. Make sure the check box is not selected.
In XP, the check box text is On resume, password protect. In Vista the check box text is On resume, display logon screen.
8. Click Settings.
9. Make sure the fields in the Log On User area are blank.
10. Select Log Off User.
11. Click OK.
13. Repeat steps 3 through 12 for all other Windows accounts used to host DeltaV logons.
Server 2003 Setup 1
If your server software is Windows Server 2003, you must set up the DeltaV screen saver from the server, then configure the screen saver
settings in the local computer policy. The settings apply to all users of the server, whether from the console or from a remote session.
To set up the DeltaV screen saver:
1. Log on to the server with a Windows account that DeltaV users log on to DeltaV software from.
3. Make sure the On resume, password protect check box is not selected.
Note You do not need to enter a Wait time. That is set in the group policy.
5. Click Settings.
6. Select Log Off User or select Log On User and fill in the information depending on your requirements.
7. Click OK.
Now follow the instructions in Setting the Screen Saver Policy on Windows Server 2003.
Server 2003 Setup 2
If your server software is Windows Server 2003, you must set up the DeltaV screen saver from the server, then configure the screen saver
settings in the server's local computer policy settings. The settings apply to all users of the server, whether from the console or from a remote
session.
To set up the DeltaV screen saver and DeltaV Autologon:
1. Log on to the server with an administrator account.
2. Enable DeltaV Autologon from the DeltaV FlexLock system menu.
3. Log on to the server with a Windows account that DeltaV users log on to DeltaV software from.
5. Make sure the On resume, password protect check box is not selected.
Note You do not need to enter a Wait time. That is set in the group policy.
7. Click Settings.
8. Select Log Off User or select Log On User and fill in the information depending on your requirements.
9. Click OK.
Now follow the instructions in Setting the Screen Saver Policy on Windows Server 2003.
Setting the Screen Saver Policy on Windows Server 2003
To set up the policy for the DeltaV screen saver:
1. Log in to the server as an administrator, either from the console or from a remote client session.
2. Select Start | Run and enter mmc.
An instance of the Microsoft Management Console opens. The console contains a folder labeled Console Root.
3. Select File | Add/Remove Snap-in...
4. In the Add/Remove Snap-in dialog, click Add.
5. In the Add Standalone Snap-in dialog, scroll down to Group Policy Object Editor, select it, and click Add.
6. In the Select Group Policy Object dialog, accept the defaults and click Finish.
7. Close the Add Standalone Snap-in dialog.
8. In the Add/Remove Snap-in dialog, click OK.
9. In the Console Root window, select Local Computer Policy | User Configuration | Administrative Templates | Control Panel | Display.
10. In the right pane of the window double click Screen Saver.
11. In the Screen Saver Properties dialog, select Enabled.
12. Click Next Setting.
13. On the Screen Saver executable name Properties dialog, click Enabled.
14. In the Screen Saver executable name entry field, enter DeltaVScreenSaver.scr
15. Click Next Setting twice.
Note Do not enable the Password protect the screen saver policy.
16. On the Screen Saver timeout Properties dialog, select Enabled.
17. Select or enter the number of seconds to wait to enable the Screen Saver.
Note The timeout time you specify here applies to all users: From the console, from Remote Desktop, and from remote client sessions.
18. Click OK to accept your changes and close the dialog.
Software
This book contains information on managing DeltaV Software. Click on an item in the Table of Contents inside this book for more
information.

Reinstalling DeltaV Software
The following sections describe procedures for reinstalling the DeltaV software. The DeltaV installation disk contains the DeltaV software
installation program.
For information on replacing a workstation on the DeltaV network, refer to the DeltaV Knowledge Base prior to reinstalling the DeltaV
software.
Installation Checklist
Verify the following:
 Objectivity services and DeltaV programs are not running.
 Disk size requirements meets the requirements listed in the DeltaV Release Notes KBA for the version of software being installed.
 Temp storage in your temp directory meets the requirements listed in the DeltaV Release Notes KBA for the version of software being
installed.
 Network cards:
 for redundant configuration
or
 for simplex configuration
 Memory:
 RAM based on the requirements listed in the DeltaV Release Notes KBA for the version of software being installed.
 Default paging file size based on the requirements listed in the DeltaV Release Notes KBA for the version of software being
installed.
 Operating System: Windows XP or Windows Server 2003. Required service packs (if any) are documented in the DeltaV Release Notes
KBA, found on the Emerson Process Management Customer Support website (http://www.emersonprocess.com/systems/support) and is
also included in your DeltaV software Media Pack.
 Authority: You must be logged on under the name Administrator on the target machine.
Note It is recommended that you use the Typical2 installation, which places DVData on the D drive.
Installation
Insert the DeltaV installation disk #2 and follow the Upgrade Wizard. This uninstalls the current version and reinstalls the DeltaV software.
Software Updates
DeltaV software updates are automatically distributed on CD or DVD media to Foundation Support and Guardian Support Plan subscribers.
Updates are also available for purchase by customers who decline these plans.
To purchase a license for added product functionality, contact your local Emerson Process Management service office or representative.
DeltaV Controller and I/O Upgrade Utility
The DeltaV Controller and I/O Upgrade Utility upgrades DeltaV controllers, remote I/O nodes, I/O modules, DeltaV SIS components, H1
fieldbus device firmware, and RS3 and PROVOX interfaces by downloading a new software image to specific controller cards and devices in
the DeltaV system. Refer to the online help for information on using the DeltaV Controller and I/O Upgrade Utility.
Caution The upgrade process can have serious negative effects if it is not performed properly. Only qualified personnel should attempt device
upgrades.
To run the utility, click Start | DeltaV | Installation | Controller Upgrade Utility.
Upgrading Controllers and Remote I/O Nodes
To successfully upgrade controllers and remote I/O nodes, you must know the controller name as well as the name and location of the
controller upgrade file (filename.udf). The upgrade file contains all the information you need to perform the upgrade successfully. Run the
utility to view controller and I/O card revision information and to identify the controller visually before upgrading. Refer to the DeltaV
Controller and I/O Upgrade Utility's online help for more information.
Upgrading I/O Modules
To upgrade I/O modules successfully, you must know the controller name and the name and location of the I/O module upgrade file
(filename.idf). In addition, the Passthrough Message Server (PTM) must be installed and running. Contact your system administrator to be
sure the PTM server is available. Refer to the DeltaV Controller and I/O Upgrade Utility's online help for more information.
Note All cards except the Series 1 Discrete cards can be upgraded.
Upgrading Fieldbus H1 Device Firmware
The DeltaV Controller and I/O Upgrade Utility supports upgrading the firmware in one or more H1 fieldbus devices. Only devices that are
commissioned or in standby are available for upgrading. H1 fieldbus devices with a Download class of "1" may be upgraded while they are
commissioned; it is not necessary for them to be in Standby mode. These devices are frequently referred to as "Class 1 devices." Class 2 and
Class 3 devices, however, must be put in Standby before upgrading.
To upgrade an H1 fieldbus device, you must know the port to which the device is connected and the name and location of the upgrade file
(filename.ffd). Software upgrade files are supplied by the device manufacturer and should not be modified or renamed. You have the option
of downloading and immediately activating the upgrade software or downloading and then activating at a later time. You can also revert to a
previous version of the software still saved in the device.
When you want to download new software to a device, the upgrade utility gives you the option to select an upgrade file and let the system find
the devices that can be upgraded with it or to select the devices and then select an upgrade file for each device.
Refer to the DeltaV Controller and I/O Upgrade Utility's online help for more information on upgrading H1 fieldbus devices.
Upgrading SIS Components
To upgrade Logic Solvers and SISNet Repeaters, select the "DeltaV SIS Components" option from the drop-down list on the opening window
of the DeltaV Controller and I/O Upgrade Utility program. Be sure that the Logic Solver is decommissioned and the controller with which it is
communicating is commissioned before starting the upgrade process. Refer to the DeltaV Controller and I/O Upgrade Utility's online help for
more information.
Software Additions
Contact your local Emerson Process Management service office or representative to order software additions to the system. The system
identification number is required to place an order.
Software additions are automatically added to the existing Foundation Support and Guardian Support plans and taken into account when
determining the Foundation Support and Guardian Support plan renewal fees.
DeltaV Excel Configuration
To install the DeltaV Excel Add-In in Excel 2003, follow these steps:
1. Open Excel.
2. Select Tools | Add-Ins…
3. From the Add-Ins dialog, click Browse.
4. Navigate to the \DeltaV\Excel folder, select DeltaV.xla, and then click OK.
5. The DeltaV Real-time Data check box appears selected in the Add-Ins dialog. Click OK.
Loading the DeltaV Excel Add-In creates the DeltaV menu option in Excel (if it does not already exist).
To install the DeltaV Excel Add-In in Excel 2007, follow these steps:
1. Open Excel.
2. Click the Office button.
3. Click Excel Options.
4. Click Add-Ins
5. Make sure Excel Add-Ins is selected in the Manage field, and then click Go…
6. From the Add-Ins dialog, click Browse.
7. Navigate to the \DeltaV\Excel folder, select DeltaV.xla, and then click OK.
8. The DeltaV Real-time Data check box appears selected in the Add-Ins dialog. Click OK.
Loading the DeltaV Excel Add-In creates the DeltaV menu command under the Excel Add-Ins tab (if it does not already exist).
System Administration and Maintenance
This book contains information on administering and maintaining DeltaV systems. Click on an item in the Table of Contents inside this book
for more information.

DeltaV Diagnostics
Use DeltaV Diagnostics as a starting point to diagnose nodes (controllers and workstations) and subsystems in your DeltaV System. You can
view diagnostic information any time after configuring nodes and placing devices on the control network and downloading the workstation.
You can access DeltaV Diagnostics locally from your workstation or remotely using a dial-in modem and standard, off-the-shelf, remote
access software. Click Start | DeltaV | Operator | Diagnostics to launch the Diagnostics program.
With DeltaV Diagnostics, you can perform the following tasks:
 Display overall status and detailed integrity information for any node and subsystem in the DeltaV control network
 View diagnostic parameters for nodes and subsystems
 Display communication information for controllers and workstations and detailed statistics on I/O cards and devices
 Launch the Process History View program in context with a selected item to display process events for that item
 Diagnose most problems on a remote network from a workstation on the control network and diagnose all problems on a remote
workstation from the remote workstation
DeltaV Diagnostics has the same look and feel as the DeltaV Explorer. The left pane shows the hierarchy of nodes and subsystems in the
control network. Typically, workstations have communications, assigned modules, alarms and events, Continuous Historian, OPC, and remote
network subsystems and controllers have communications, I/O, and assigned modules subsystems. Devices are below the I/O subsystem.
To explore the contents of a node or subsystem, click the plus sign next to it to expand the contents. To see diagnostic information for a node
or subsystem, select the node or subsystem, and view the diagnostic information for the selection in the right pane. To change how the
diagnostic information is presented, experiment with the different views: List, Details, Comparison, and Verbose. In this figure, diagnostic
information for the Primary communications subsystem of the workstation node USAUST-DOVETAIL is displayed.
Four indicators are used to show the status of nodes and subsystems. These indicators appear at the top level in the hierarchy as well as at the
specific node or subsystem:
Indicates the node is not communicating. Typically
this indicator occurs when there is a bad connection or
if the node is not powered up or is decommissioned.
Indicates that Diagnostics does not have all the
information on the node. For example if an
unconfigured I/O card is pulled, this indicator appears.
Indicates the node is communicating but has an
integrity problem. Integrity problems can occur for a
variety of conditions including hardware or connection
problems, a mismatch between the I/O configuration
and the installed I/O, or if the node is configured for
redundancy but does not have the necessary
connections to support redundancy.
Indicates the node has lost its configuration or the
configuration is not downloaded. A node can lose its
configuration if it loses power or is reset.
Refer to the online help for complete information on using DeltaV Diagnostics.
Database Administrator Tools
The DeltaV system stores your control strategy in a database. You can have multiple databases created but only one is the active (currently
used) database.
Database Administrator Control Panel Window
The Database Administrator contains tools for managing your DeltaV databases. These tools include:
Create Database - Creates a persistent database that is used primarily to store configuration information
Delete Database - Deletes a database
Copy Database - Copies an existing database
Rename Database - Renames a database
Synchronize Workstations - Specifies the active database in the registries of other workstations in the system
Backup and Restore - Backs up a database and restores a backup version of a database (into the current active database)
Set Server Host - Specifies the workstation on which the DeltaV Database Server resides. This setting is used by the database administrator
tools in those dialogs that provide a list of registered databases on a workstation (such as delete, copy, move, monitor, backup, and set active
database)
Set Active Database - Specifies the database to be used as the active database
Register Database from Files - Registers (and deregisters) the database on the database host
Clean Database - Rolls back transactions that have terminated abnormally. This tool also enables you to perform an extended clean which
consolidates and defragments the selected database in addition to rolling back transactions that have terminated abnormally
Database Connections - Displays the active database connections
Daily Export Enable or Disable - Provides the configuration and enabling (or disabling) of a daily export of the DeltaV database
Migrate Database - Migrates an older version of the DeltaV database to the current version. Used specifically after upgrading DeltaV
software.
Daily PowerUp Directory Backup - Enables a daily backup of the download scripts in the POWERUP directory.
Basic Database Functions
The Database Administrator tools fall under three groups: Basic, Utilities, and Configuration. This section describes the Basic database
functions.
Basic database management functions include the following:
 creating new, empty databases
 copying database files
 renaming database files
 deleting database files
Each of these functions is described individually in its own section. These functions are the most basic database functions but are not
necessarily the most frequently accessed functions.
Caution Never use Windows Explorer to copy, move, create or delete a database. Always use the Database Administrator Tools. Access to
the correct database could be compromised if you use Windows Explorer.
Database Function Precautions
These precautions are intended for all of the Basic Database tools. Follow these precautions. Failure to do so can cause unexpected problems
with the DeltaV database.
Never use Windows Explorer to copy, move, create, or delete a database. Always use the Database Administrator Tools. Access to the correct
database could be compromised if you use Windows Explorer.
Create
You would create multiple databases for a number of reasons. Here are a few examples:
 to modify the default control strategy to be your control strategy on the initial configuration of the DeltaV system
 to have one database as a production database and one as the simulation database
 to create a database for the addition of a new area of the plant that is identical to a current configuration and on the same DeltaV system
(for example, a new node on your current control network)
 to create a new database for a second DeltaV system that is separate from your current system, but has the same control strategy (for
example, a second control network)
Creating a new database does not create any new configuration, control, or device details. The DeltaV system takes the original (reference)
database and makes a copy of it to create the new database. It does not change the original (reference) database.
Note You can populate the new database with your current physical network configuration by selecting the option, Preserve the Network
Definition when creating a new database. When you choose this option you then can choose whether to use the current active database or an
existing export file. Depending on your configuration this option may cause some non-network database objects to be preserved.
You can also use Create to restore a backed up database as a new database. Restoring a database does not overwrite an existing database.
Instead, you have a new database (restored from the backup) with all the configuration and control data of the backed up (original) database.
The process of creating a new database automatically registers the database name in that computer's registry. Windows uses the convention
called a registry to track all programs and hardware on or attached to the computer and their respective settings. The DeltaV system also uses
the convention of the registry to track settings for the DeltaV databases, hardware and applications.
In order to use a newly created database as your control strategy on your DeltaV network, perform the following steps:
1. Define all of the existing nodes on your DeltaV control network in the newly created database.
2. Set the new database as Active from your master node using the Set Active Database tool.
3. Make sure that all of the nodes are powered on.
If you are having problems with the database not showing up as a choice in your DeltaV Explorer or in Set Active Database, you must
manually register the database with the Register Database from Files tool from the master node.
Delete
There are times when you might need to delete a database. Here are some examples of times when deleting a database is recommended:
 The database was a simulation database that you no longer want to have on the system.
 The control strategy that the database defines is no longer being utilized due to plant reorganization or other reasons.
 The database is no longer usable due to internal problems and cannot be repaired and you have already restored a good backup.
 You have a backup of an old (that is, no longer used) database on the system.
Deleting a database removes the data files (including all configuration information) from the computer's hard drive. The files are deleted from
the \\DeltaV\DVData\Databases\DatabaseName folder (where DatabaseName is the folder name of the database you are deleting). Once the
database is deleted, the DeltaV nodes (workstations and controllers) that are defined in that database are no longer recognized.
Note You must be logged on as the Windows user Administrator to delete a database.
The delete action automatically deregisters the database from the DeltaV system. The other workstations are no longer able to access that
database.
If, after deleting a database, you continue to see the database name as a choice in your DeltaV Explorer (or in the Set Active Database tool),
then you need to deregister the database manually. You manually deregister a database with the Register Database tool.
Rename
When you rename a database, you are changing the physical location of where that database resides. The files that are moved are found in
\\DeltaV\DVData\Databases\DatabaseName (where DatabaseName is the folder name of the database you are renaming).
Note You can only rename a database if you are logged on to the computer as the Windows user Administrator.
Renaming a database makes the old name invalid, so you must select the active database with its new name. Use the Set Active Database tool
to set the new database name as the active database.
There are a number of reasons when it is necessary to rename a database (for example, to change the name of a database to better describe the
functions or plant area that is controlled with the database).
Copy
To copy a database means to make a duplicate of an existing database. In order to copy the database, you must choose a different name for the
copy.
When you copy a database, you are copying the files found in \\DeltaV\DVData\Database\DatabaseName (where DatabaseName is the folder
name of the database you are copying).
Here are some rules for making copies of a database:
 You cannot make a copy of a database with the same name as the original.
 Copy does not overwrite existing databases.
Here are some reasons why you might make a copy of a database:
 Use a copied database to put a new area online that is an identical process and will be controlled through the same DeltaV controllers
 Use a copied database to set up a simulated change. This allows you to test the new machines and controllers in a simulated
environment without affecting the real-time data and plant controls.
The Copy tool automatically registers the database in the DeltaV system. If you are having problems with accessing the database: it is not
showing up as a choice in your DeltaV Explorer or in Set Active Database, then you need to manually register it. Use the Register Database
tool to manually register the new copy.
You might need to set the new copy as active if you plan on using the copy as the primary database.
Utility Functions
The Database Administrator tools fall under 3 groups: Basic, Utility, and Configuration. This section describes the Utility tools.
The Utility tools include:
 Clean Database
 Database Connections
 Backup and Restore
 Synchronize Nodes
 Daily Export
 Daily PowerUp Directory Backup
 Migrate Database
The Utility tools are used only as needed to correct problems with the database. You might use some of the Utility tools more frequently than
others.
Utility Function Precautions
These precautions are intended for all of the Database Utility tools. Follow these precautions. Failure to do so can cause unexpected problems
with the DeltaV databases.
 Always use the Database Administrator Tools to work with the DeltaV databases.
 Always keep the Objectivity Lock Server, the control database files, the Federated database (and related Boot file) on the same
machine. This machine is always the host machine.
 Never power off the workstation with the DeltaV applications active. This can cause problems with the Windows operating system as
well as the DeltaV databases. Always close the DeltaV applications and log out of Windows before powering off a workstation.
Note If your workstation does get powered off without exiting all applications and Windows first, use the Database Administrator tools to
correct any problems with the DeltaV databases.
Lock Server
Note The Lock Server is not a Database Administrator tool. It is an Objectivity program that is used by the DeltaV system.
The Lock Server is an Objectivity control for assigning locks on transactions and applications. This function is designed to track which
workstation or node is currently in control of the data. Locking out other workstations and nodes keeps multiple workstations from making
changes to the same data at the same time. This ensures data integrity in your database.
Transaction locks are applied when a node accesses the database and effects a change on that database. Application locks is applied when a
node has the application in use.
At startup, the Database Server reads what the Lock Server is doing to determine if any locks are currently applied to a transaction or
application. These locks are different than the DeltaV security locks. The Lock Server locks are specific to database functions and are not
related to user access and security. The Database Server attempts to clear any locks it detects at startup.
The DeltaV Monitor tools require that the Objectivity Lock Server be properly configured and running. You can verify the correct version and
setup of the Lock Server in Control Panel | Objectivity | Lock Server.
Note The Lock Server should reside on the host machine along with the Federated database (configdb.hdb.FDB), the Boot file related to the
Federated database (configdb.hdb) and the data files that make up the DeltaV control database. This is the default download.
A transaction lock occurs when a node accesses the database and effects a change on that database. A change on the database can be any
update, node removals, device configuration changes, addition of a control loop, or other configuration changes. While that change is
occurring the Objectivity Lock Server applies a lock on the data until that transaction is complete. No other node can change the data at this
time. Other nodes can utilize (read) the data, but not change (write) it. This is called MROW - Multiple Reads One Write.
If the system is interrupted (for example, powered off) before the transaction is complete, then the transaction lock remains but is not attached
to a specific node. This results in an invalid (unfinished) transaction lock.
An application lock is applied when a node has the application in use. This prevents other nodes from accessing that application and making
simultaneous changes through the application. Locking an application ensures configuration integrity. When that node (workstation or device)
is finished with the application, the lock is released and other nodes can now use the application.
An application lock is invalid when any part of the system (node or host computer) is interrupted before the lock is cleared. The lock remains
even though the node is no longer using the application. This prevents other nodes from accessing the same application.
Clean Database
The Database Administrator tools have a Clean and Extended Clean utility. Use the Clean utility to rollback transactions that have terminated
abnormally. Use the Extended Clean command to consolidate and defragment a DeltaV database in addition to rolling back transactions that
have terminated abnormally. These utilities recover disk space that is no longer needed in the database files.
The utility also supports a scheduled daily extended clean. Note that Windows XP task scheduling software identifies a successful scheduled
clean operation with a status of 0x0. A failed clean operation has a status of 0xc0043ca7.

Database Connections
The Database Administrators tools have a Database Connections utility. Use this utility to display the active database connections. This utility
also allows you to disconnect any active connection. Select the connection and click the Disconnect button.
Backup/Restore
The Database Administrator tools have a Backup and Restore utility. Use these utilities to make a backup of your DeltaV databases. This
utility is only backing up or restoring the DeltaV database files, as found in \\DeltaV\DVData\Databases\DatabaseName (where
DatabaseName is the folder name of the database you are backing up or restoring). The Backup and Restore tool does not back up historical
data from the Continuous Historian, event data, or process graphics. A backup can only be restored into the same version of the DeltaV
software. Only upgrade utility produces a file intended for import into a different version of DeltaV software.
All DeltaV applications must be closed and all locks cleared before backing up. If you back up a database with locks, those locks are also
backed up. If you restore a database that was backed up with locks, the locks are also restored.
Backup
It is important that you back up your entire DeltaV system often. To do that, follow the instructions in the Full System Backup topic.
There might be times when you only want to back up your DeltaV databases (controller configuration, I/O setup, the control strategy, and so
on), as found in \\DeltaV\DVData\Databases\DatabaseName (where DatabaseName is the folder name of the database you are backing up).
This situation applies before making any changes, adding new nodes, or when creating simulation configurations.
When you only want to back up your DeltaV databases, use the Database Administrator tool Backup and Restore.
With the Backup and Restore tool, you can only back up the database for the workstation configuration. You cannot back up the entire
system. The database is stored in UNC name: \\Machine Name\Databases. This is the same as the DeltaV\DVData\Databases folder if viewed
from Windows Explorer. To back up the entire system, follow the instructions in the Full System Backup topic.
Important When VCAT (Version Control) is enabled on the database, the Backup utility will back up the DeltaV database as well as the
VCAT database. The VCAT database is a SQL database. In order to back up the VCAT database to a destination drive that is not on the SQL
database machine, the MSSQLServer and SQLServerAgent services must be given access to (permissions on) the destination machine (which
must have a share where the backup will be written). Therefore, the service accounts must be modified with the Service Control Manager. The
accounts must be changed from the default of SYSTEM to a Windows account that has access to the destination machine (with permissions to
the share and the destination folder) and is in the Administrators group on the DeltaV ProfessionalPLUS machine. An example of such an
account would be the DeltaVAdmin account if the destination machine were running the DeltaV software or the destination machine had
granted DeltaVAdmin access to the resource. Refer to Modify SQL Services Logon for more information.
Restore
Restoring the DeltaV database is done when there is a problem with the database that the other Database Administrator tools (for example, Set
Active Database and Register Database) cannot solve.
Note With the Backup and Restore tool, you can only restore the DeltaV database (controllers, I/O configuration, and control strategy). You
are not restoring the entire DeltaV system.
The database is normally stored in UNC name: \\Machine Name\Databases. This is the same as the DeltaV\DVData\Databases folder if
viewed from Windows Explorer. To restore the entire system, follow the instructions in the Full System Restore topic.
If you restore the database to a different machine or under a new name, you need to set the server host machine, set the active database, and
synchronize the workstations.
Backing up the Objectivity Database
The Objectivity Database contains the control configuration data that defines the workstations, controllers, and modules that run in the
controllers. The display data consists of the operator displays.
1. Run the DeltaV Database Administrator tool by clicking Start | DeltaV | Engineering | Database Administrator.
2. Use the DeltaV Database Administrator tool to back up the configuration database. For instructions on how to back up this database,
refer to the online help for the DeltaV Database Administrator tool. The backup procedure takes several minutes.
3. If the previous backup is no longer needed, delete it using Windows Explorer.
Note It is required that you exit all DeltaV Engineering Tools before running a backup of the active configuration database. These tools access
the configuration database, and the integrity of a database backup is not guaranteed while any of these tools are open. An error dialog appears
during the backup if there are open programs. To determine which programs are open, double-click Database Connections in Database
Administrator.
Restoring the Objectivity Database
Note Exit the DeltaV Engineering tools before restoring the database. Use Database Connections if necessary.
1. Use the DeltaV Database Administrator tool to restore the configuration database. For instructions on how to restore this database, refer
to the online help for the DeltaV Database Administrator tool. Also, make certain that you are restoring the appropriate backup. The
restore procedure takes several minutes.
2. Click OK in the message box that states that the data has been restored.
3. Close the window and exit the application.
Modify SQL Services Logon
In order to back up the VCAT database to a destination drive that is not on the SQL database machine, it may be necessary to modify the SQL
services service logon. Refer to Backup/Restore for more information.
To modify the logon, perform the following steps:
1. Log on to the SQL database machine (the source machine) as the local administrator.
(To configure service startup, you must be logged on with a user account that has membership in the Administrators local group.)
2. Select Start | Settings | Control Panel | Administrative Tools.
3. Double-click Services.
4. Select the named SQL Server instance, SQL Server (MSSQL Server).
Note There can be other named SQL Server instances depending on what DeltaV functions or other applications are installed. For
VCAT, select SQL Server (MSSQL Server).
5. Right click and select Properties.
6. Click the Log On tab.
7. In the Log on as section, click the This Account: dot.
8. Click the Browse … button to browse for the account. The account must already exist in Windows User Manager.
9. Enter the name and click Check Names.
10. Click OK if the name is found.
11. Enter the password for that account on the Log On tab.
12. Repeat the process selecting the SQLServerAgent service.
Use the following table to determine the type of account to use and what the password must be.
If you are MSSQLServer and The destination Security access on the

backing up to: SQLServerAgent machine: destination machine:
Services Account
log in as:
a computer on a domain account uses the DeltaV domain The DeltaV domain
the same domain account account must have write
access to the backup
destination.
a computer on a a domain account uses DeltaV domain The DeltaV domain
different domain account account must have write
with a domain access to the backup
trust relationship Note Grant access to destination.
remote network and
directory to the DeltaV
domain account.
a computer on a a local or domain must have a local account The local account must
different domain account with same name and have write access to the
without a password backup destination.
domain trust
relationship
a computer in a local account must have a local account The local account must
the same or with same name and have a backup destination.
another password
workgroup
The destination (where the backup will be written) must be a shared device and the MSSQL services logon account must have Change
permission to the destination folder.
To configure the share, perform the following steps:
1. Go to the destination machine.
2. Select the drive or folder where the backup will be written and right click.
3. Select Sharing...
4. Select Shared As and provide a share name.
5. Set the User Limit.
6. Click Permissions.
7. Click Add and select the MS SQL services user account (the one that MSSQLServer and SQLServerAgent are using for logon on the
source machine).
8. Select Type of Access as Change.
9. Click OK until all dialogs are closed.
For more information on configuring sharing, refer to the Windows help system.
To set the permissions on the backup folder, perform the following steps:
1. Select the folder where the backup will be written. This can be a subfolder of the share.
2. Right-click and then select Properties.
3. Select the Security tab.
4. Click the Permissions button.
5. Set the MS SQL services user account (the one that MSSQLServer and SQLServerAgent are using for logon on the source machine) to
be listed with Change access. The account needs the ability to read from that folder, write to that folder, and create new files and folders
in that folder.
6. Click OK until all dialogs are closed.
For more information on permissions, security, and access type, refer to the Windows help system.

Synchronize Nodes
The Synchronize Nodes tool is used to get multiple workstations on the same DeltaV control network using the same server host machine and
the same active database. Synchronize Nodes actually synchronizes the registry on multiple workstations.
Synchronize Nodes Dialog Window
Synchronize Nodes forces the refresh so that multiple workstations are looking at the same machine's (that is, the host's) registry. This ensures
that all workstations are running from the same database and, therefore, the same control strategy.
Note You can have multiple DeltaV systems running as separate control strategies as long as they are separate systems. However, every
workstation on a single DeltaV system must run from the same database.
Use Synchronize Nodes when you bring a new workstation on line or change the host machine to another ProfessionalPLUS machine.
Repair
Note The Repair feature is not a tool accessed from the Database Administrator window. However, it is a function usually performed by the
database administrator, which is why it is covered in this section.
Most of the problems you encounter with a database are related to setting the active database, setting the server host, or other problems that
are solved by the Database Administrator tools.
However, there are times where the database becomes damaged. This is referred to as a corrupted database. This does not happen often but it
is a remote possibility. The database administrator must know how to recognize and fix this problem
A truly corrupted database is one where data are incorrect or the database in unable to be accessed (opened and written to). In a corrupted
database, the data integrity (accuracy of your control strategy) is at risk.
You can be sure that you have a corrupted database when the problem persists even after running the other Database Administrator tools. At
that point, stop and restart the database server. If the problem still persists, the only other option you should have left is to restore a backup
and that might be the preferred choice, if you have a current backup.
Remember, when you restore a database, you need to first delete or rename the existing, corrupted database and then restore the backup. You
also need to set the new database as active.
Daily Export
The Daily Export tool allows you to configure and enable (or disable) a daily export of the DeltaV configuration database. This includes
Version Control information in the configuration database but does not include the Version Control database. Refer to Backing Up the
Version Control Database for further information.
The Daily Export tool sets the exporting at the same time (using 24 hour format) each day and to the same network directory. This tool takes
the active DeltaV configuration database and exports it to the network location you specify.
Daily PowerUp Directory Backup
The Daily PowerUp Directory Backup tool enables you to backup the POWERUP directory. The POWERUP directory contains the download
scripts used in the run-time system. In order to maintain redundancy, the standby controller requires that the POWERUP directory contain all
of the modules, IO cards and other scripts that are on the active controller.
Migrate Database
The Migrate Database tool migrates a previous version of the DeltaV configuration database to the current database structure. This tool is used
to migrate a database after upgrading the DeltaV system.
Configuring Functions
The Database Administrator tools fall under three groups: Basic, Utility, and Configuration. This section describes the Configuration tools.
The Configuration tools include:
 Register Database from Files
 Set Server Host
 Set Active Database
Register Database from Files
The Register Database from Files tool makes the selected database known to the DeltaV workstations.
Register the Database from Files Dialog Window
You use the Register Database from Files tool when any workstation on the same system is having trouble recognizing the existence of the
database. You can test this by looking in the Set Active Database tool. If the database is not showing up in the list of databases, you need to
register the database and set it as active.
There might be times when you need to deregister a database using the Register Database from files tool. This removes the database name
from the list of possible databases to use. Deregister a database with the Register Database from Files tool if you see a decommissioned
(deleted) database in the Set Active Database list.
Normally the Register and Deregister functions occur automatically when using the Database Administrator tools to create, move, copy,
rename, or delete the DeltaV databases.
Set Server Host
The host machine contains the production database (your active database) and the database server (DvDBServer). It is also the machine where
the federated database, production database, and Lock Server reside. The host machine must be the ProfessionalPLUS machine.
Set a Server Host Dialog Window
There is always only one host machine and only one active database per DeltaV system. The host is the machine that controls all of the other
workstations through the Database Server application. It is also referred to as the ProfessionalPLUS machine. The active database and the
Lock Server reside on the host machine. The host machine controls all access to the DeltaV database.
All other workstations (also referred to as Visual machines) must point to the appropriate machine as the host machine and therefore
recognize the one active database residing on the host. The Visual workstations have access to the database and DeltaV applications based on
the Database Server, which resides on the host machine.
The Set Server Host tool is used to designate which machine is acting as the primary machine.
In order for all of the workstations in the DeltaV system to reference the active host, the Set Server Host tool calls the Synchronize
Workstations tool.
Note The host machine must have the Federated database (configdb.hdb.FDB), the Boot file related to the Federated database (configdb.hdb),
the data files that make up the DeltaV control database, and the Objectivity Lock Server residing on it.
Set Active Database
The Set Active Database tool is used to identify which database you want to work with.
Set Active Database Dialog Window
Once you set the active database on a workstation, the engineering tools on that workstation reference that database.
Importing and Exporting Database Objects
You can move database objects from one database to another using the import and export commands in the DeltaV Explorer.
Exporting Objects
The DeltaV Explorer enables you to select objects at several levels in the Explorer hierarchy for exporting. You can export nodes, a module,
the entire control network, or the entire configuration system. The Export command converts the database data for the object you select into
an ASCII file with an .fhx extension. This file includes the data for the selected object and everything beneath it. To back up an entire
database, use the Backup Database administrator tool.
Note Do not edit the ASCII text export files. Editing these files can cause later problems in your database.
Exporting Workstation Configuration Files
When you add a workstation to your configuration database, be sure to make a workstation configuration file that provides the new
workstation with all the database information it needs (an ID, address, and so on). To create your workstation configuration file, use the File |
Export | Workstation Configuration command. Save the workstation configuration file on removable media or a network location that can be
accessed from the workstation you are going to configure. The configuration file is saved as a file with a .cfg extension. To configure the new
workstation, browse to the Workstation Configuration data you saved when prompted.
Note Do not edit the configuration (.cfg) file. Editing this file can cause problems with your workstation configuration.
Importing Objects
You can incorporate database objects from an .fhx file into your database. An .fhx file is created using the Export command in the Explorer. A
single .fhx file can include one or many database objects.
Important If you export an .fhx file from an Application Station configured to use the Legacy Historian and then import this file to a new
Application Station, it will initially be configured to use the DeltaV Continuous Historian. If you want to use the Legacy Historian on the
Application Station to which you migrated the .fhx file, you must reconfigure it after importing the .fhx file.
Note Do not edit the import (.fhx) files. Editing these files can cause problems in your database.
User Manager Application
Inside this topic
Security information is defined in terms of users, groups, locks, keys and areas.
 Users are DeltaV and Windows users. You can assign users to one or more groups.
 Groups have access to a specific subset of the keys available in a site.
 Locks prevent users from changing specific module parameters and parameter fields. Locked objects can only be accessed by users who
have the appropriate key. Locks are assigned using the DeltaV Explorer or Control Studio.
 Locks and keys are also associated with some user functions. For example, the appropriate keys enable users to:
 Use AMS Device Manager device configuration and calibration features.
 Make changes to the configuration database and save Process History View configuration.
 Download configuration and setup data to system nodes.
 Use the database administrator tools to create, copy and rename databases.
 Keys can be held directly by the user or indirectly through association with a group that owns the key. Keys provide permission to
access locked parameters or parameter fields. (The granting of keys is done with the DeltaV User Manager.)
 A user's association with a group or ownership of a key can be global or limited to the scope of a plant area or set of plant areas.
 Areas - DeltaV system users can be granted different sets of keys in each area. This feature can be used to grant parameter write access
to operators for control modules within the operators' responsibility, yet withhold access to other similar modules outside their
responsibility.
Many of the changes you make in the DeltaV User Manager require that you perform a workstation download in the DeltaV Explorer. Before
you close the DeltaV User Manager, a message appears reminding you to download the workstation to ensure that all security changes take
effect.
Start User Manager from the task bar by clicking Start | DeltaV | Engineering | User Manager.
Start Menu for DeltaV User Manager
The User Manager window gives you three views; Users, Locks, and Groups. You can open, close, and resize each pane. These views are
available under the View menu.
User Manager Window

User Accounts
The first user who logs in to the system starts off with a default user name of Administrator. This person has administration privileges
associated with the computer work group as well as full access to all DeltaV functions, such as configuring hardware, configuring the process
system, downloading the configurations, and so on.
Note You cannot change the Administrator's privileges unless you have created another user with equal privileges.
The first user must configure the ProfessionalPLUS workstation. Before any other users log in to the system, some thought should be given to
the overall user access scheme. If more than just one or two users will be accessing the system, you might want to limit their ability to change
the process configuration or perform downloads. To do this, you need to set up user names and access privileges in the User Manager.
If you are the first user after the workstation has been configured, log in as Administrator. Click Start | DeltaV | Engineering | User
Manager. The default user accounts, displayed in the User Manager program screen, are Administrator, DeltaVAdmin, DVBatchAdmin,
SoftPhaseUser, DVPEHAdministrator, and Guest.
Note Do not change the password for DeltaVAdmin, DVBatchAdmin, or SoftPhaseUser from the DeltaV User Manager application. Always
use the ServPwd.exe utility (found in the DeltaV\Bin folder) to change the passwords on these accounts.
The following accounts are created as operating system and DeltaV database accounts as part of the DeltaV installation process.
User Account Default Password
Configure DeltaVC1
Operator DeltaVO1
Supervisor DeltaVS1
Maintainer DeltaVM1

Adding a New User
Follow these steps to add a new user:
1. Click File | New | User.
2. Enter the name (usually just the last name) in the Name field. Tab to the next field.
3. Enter the user's full name in the next field and press Tab.
4. Enter a password and inform the user of the password or leave it blank and let the user define a password.
5. Select both Account Types.
6. Fill in any other appropriate information for your environment, including keys, and then click OK.
Note If you press Enter or click OK before you have made all selections for this user account, the new user account is created with all
the default settings of Windows and DeltaV Account types but no Can Download or Can Configure privileges. To add these privileges,
you must edit the user account properties by selecting the user's name and then clicking the Keys tab.
Note Many of the changes you make in the DeltaV User Manager require that you perform a workstation download in the DeltaV Explorer.
Before you close the DeltaV User Manager, a message appears reminding you to download the workstation to ensure that all security changes
take effect.
To assign the user to a user group that has predefined access limits, click the Groups tab. To restrict or grant access to particular logical plant
areas, click the Keys tab.
DeltaV FlexLock
Inside this topic
The DeltaV FlexLock application creates dual desktops on a single workstation to provide both a secure operating environment and a wide
open engineering environment. Access to a desktop is determined by the current user's privileges.
FlexLock Application on the DeltaV Desktop
You can access online help for FlexLock by pressing F1 when the dialog has input focus.
Clicking the FlexLock icon in the left corner of the FlexLock window opens the System menu. The menu contains Windows standard options
and FlexLock options.
The available desktops are the Windows desktop and the DeltaV desktop. A user who is a member of the DeltaV Admins, Administrators, or
DeltaV Access Windows group has access to both the DeltaV desktop and the Windows desktop. The Windows desktop includes all of the
DeltaV programs as well as all programs available in Windows. A user who is not a member of one of these groups has access only to the
DeltaV desktop. The DeltaV desktop limits the user to the DeltaV Operate program and to those programs available to the user through
DeltaV Operate.
To secure your operating environment, consider giving operators access to the DeltaV desktop and other users, such as engineers, access to
both the DeltaV desktop and the Windows desktop.
Note You must also consider access to the underlying Windows account, especially when logged on with Windows Administrator privileges.
When you log off of the DeltaV software, be sure to log off of Windows also, especially if you are logged on with Windows Administrator
privileges. If you do not log off of Windows, the next user to log on to the DeltaV system will operate under the Windows Administrator
account. The Windows Administrator account grants the user the right to perform actions that could interfere with the operation of the DeltaV
system. In the Windows User Manager, consider creating an administrator group for users with unrestricted rights and an operator group for
users with restricted rights.
FlexLock Overview
FlexLock starts automatically on both desktops when a user logs on. When the Autoswitch Desktop option is selected (the default) the
DeltaV desktop opens initially. When the current user logs off, the next user to log on sees the FlexLock application with the DeltaV Desktop
button pressed. This indicates that FlexLock switched the user to the DeltaV desktop.
A user with Windows administrator or Windows Desktop Access can select the Windows Desktop button from FlexLock and switch to the
Windows desktop. A user who does not have Windows administrator or Windows Desktop Access is restricted to DeltaV Operate. If a user
without sufficient privilege attempts to switch to the Windows Desktop, a prompt appears. Users who have an administrator account can enter
a name and password and switch to the Windows desktop.
Users without Windows administrator or Windows Desktop Access who attempt to switch to the Windows Desktop receive a message
indicating that they lack the proper privileges and be prompted to enter an administrator name and password. If the user enters the proper
administrator name and password, FlexLock switches to the Windows desktop.
Users with the proper DeltaV account type can prevent FlexLock from automatically switching to the DeltaV desktop when subsequently
logging on by deselecting the Autoswitch Desktop option from the system menu.
If you exit the FlexLock application from the Windows desktop, click Start | DeltaV | Engineering | FlexLock to open the FlexLock
application. You cannot exit the FlexLock application from the DeltaV desktop.
Note It is possible that a Remote Client session running FlexLock does not appear on the Processes tab of the Windows Task Manager. If it is
necessary to close FlexLock (for instance, to uninstall the DeltaV system), select the checkbox "Show processes from all users" on the Task
Manager Processes tab. Then select and end the process DeskTop.exe, which is the FlexLock name in the process list.

FlexLock Buttons
The FlexLock window contains four buttons:
 DeltaV Desktop
 Windows Desktop
 DeltaV Operate
 DeltaV Logon
The following topics explain each of these buttons.
DeltaV Desktop
The DeltaV Desktop button in FlexLock switches to the DeltaV desktop, which, depending upon your privileges, allows you to access the
Windows desktop or launch the DeltaV Operate program. The Windows Desktop includes the DeltaV programs as well as the programs
available in Windows. DeltaV Operate allows operators to interact with the process control system through the use of high-resolution
graphics.
Windows Desktop
This button switches to the Windows desktop if the current user has sufficient privilege. Otherwise, a popup appears from which the user can
open a dialog to gain temporary access to the Windows desktop. From the dialog the user enters a user name and password of an account that
has Windows desktop access. The access on the Windows desktop is of the user logged on to the DeltaV software.
DeltaV Operate
This button launches the DeltaV Operate program. The DeltaV Operate application allows operators to interact with the process control
system through the use of high-resolution graphics.
To configure DeltaV Operate to launch automatically after a user logs on, select the Autorun DeltaV Operate option.
Note If you are logged on to the DeltaV system with Windows Desktop privileges, you are running DeltaV Operate on the Windows
desktop, and Flexlock's automatic switching is enabled, you must close DeltaV Operate before using DeltaV Logon to log off the DeltaV user.
The next user (specifically one without Windows Desktop privileges) may not be able to run DeltaV Operate because FlexLock only allows
one instance of DeltaV Operate to run on the system.
DeltaV Logon
This button launches the DeltaV Logon application, where you select a computer or domain name, select your user name, and enter your
password to gain access to DeltaV software.

FlexLock Options
FlexLock has a number of options available from the system menu. Open the system menu by clicking the icon in the upper left corner of the
FlexLock window.
Autorun DeltaV Operate
Select this option to run DeltaV Operate automatically when a user logs on. Use this option with the Autoswitch Desktop option.
Autoswitch Desktop
When this option is enabled, the system switches all users to the DeltaV desktop upon each instance of logging on to Windows. A DeltaV user
with Windows desktop access privileges can switch to the Windows desktop by clicking the Windows desktop button in FlexLock. A DeltaV
user without Windows desktop access privileges cannot switch to the Windows desktop and can only run DeltaV Operate.
A user who logs on with a Windows account that is not also a DeltaV account is switched to the DeltaV desktop and FlexLock and the DeltaV
Logon dialog open. The user cannot do anything unless he also has a DeltaV account.
Important Emerson Process Management recommends that you leave Autoswitch Desktop enabled to keep unauthorized users from
accessing the Windows desktop.
Smart Card Required
The DeltaV system supports the use of Smart Cards for logging on to the DeltaV system. This feature can be enforced through the Smart Card
Required option on the FlexLock drop-down menu. If the option is enabled, users must log on to the DeltaV system using a smart card and
PIN on this workstation. If the option is not enabled, users may log on with a card (if a card reader is installed) or without a card. The setting
also affects logging on to the Windows desktop from the FlexLock Windows Desktop button.
If a card is required, the user is instructed to insert a card and enter the PIN associated with the card on the DeltaV logon screen. Note that the
PIN is not the same as the DeltaV password and should not be configured to match a DeltaV password. Leave the card in the reader when
using applications that interface with the DeltaV database (for example, Control Studio, DeltaV Explorer and Recipe Studio). If you remove
the card from the reader you lose user privileges for certain functions on these applications.
If a card is optional the user may enter a user name and password or insert a smart card and enter a PIN.
Refer to Smart Cards for more information about using smart cards with the DeltaV System.
DeltaV Autologon
If this feature is enabled users whose accounts are both Windows and DeltaV accounts are automatically logged on to DeltaV software when
they log on to Windows. In addition, users who are logged on remotely are not automatically logged off of DeltaV software if their
connection is lost. When connection is re-established, these users' sessions are resumed and they are still logged on to DeltaV software. This
feature does not interact with any other FlexLock setting. If you also use the DeltaV screen saver, make sure its Log Off User checkbox is
selected.
Note If you enable DeltaV Autologon and are using the DeltaV screen saver and have entered a Log On User, DeltaV Autologon is ignored
when the DeltaV screen saver times out. The Log On User specified in the screen saver is logged on when the screen saver times out.
When Autologon is enabled, other DeltaV users can use the DeltaV Logon dialog to log on to DeltaV software. When they log off, the DeltaV
user reverts to the user who originally logged on through Windows (if the Windows user is also a DeltaV user).
For more information on using the DeltaV Autologon feature, refer to Auto-Logon/Logoff in Recommended Maintenance Practices.
Logoff Windows
Logs the current user off of DeltaV and Windows software.
Shutdown
Logs the current user off of DeltaV and Windows software, then turns off the computer.

Hardware Repairs and Additions
The following sections provide information on how to install hardware peripherals on DeltaV systems. They also contain details about DeltaV
equipment repair and warranty.
Equipment Repair
The DeltaV control system equipment is, with few exceptions, not reparable. Customer replacement orders are given a priority over standard
material orders and are typically shipped within 24 hours.
To enter a replacement order, contact your local Emerson Process Management service center or representative. To qualify an order as a
replacement order, you must provide the serial number of the failed assembly.
If the replacement order is for an assembly covered by warranty, either standard or extended, you will receive a Return Authorization number
and instructions for returning the item.
Equipment Warranty
The standard warranty period for the DeltaV Fisher-Rosemount Systems, Inc. manufactured equipment is 12 months from initial installation,
but no more than 18 months from shipment. Initial installation is defined as the day the software identifiers are first loaded by the end-user, as
reported on the registration form.
You can purchase an extended warranty service to cover Fisher-Rosemount Systems, Inc. manufactured equipment at either the time of
purchase or the time of registration. The extended warranty period is 36 months from the initial installation, but no more than 42 months after
shipment. (This does not include the personal computer.)
Equipment not manufactured by Fisher-Rosemount Systems, Inc. (for example, workstation, power supply, and control network hub) is
warranted by the manufacturers according to their warranty terms and period of coverage. Fisher-Rosemount Systems, Inc. will arrange the
warranty services for this equipment with the manufacturers.
To receive assistance, contact your local Emerson Process Management service center or the representative in your World Area.
Equipment Additions
Contact your local Emerson Process Management service center or representative to place an order for equipment additions to the system. The
system identification number is required to place an order.
When adding equipment to a system enrolled in the extended warranty plan, the DeltaV Response Center automatically enrolls the new
equipment in the existing extended warranty plan. The added hardware is taken into account when determining the fee for extensions to the
Extended Warranty Plan.
Installing a New Controller or I/O Card
If you install a new or replacement controller or I/O card in your DeltaV system, the new/replacement item might contain firmware that is not
compatible with your current system. Check the revision level of the new/replacement item and install the correct revision level firmware if it
does not match your system revision level.
Caution Incompatible revision levels can result in unstable operation.
To ensure compatibility of your controller or I/O card, perform the following steps:
1. Check the firmware revision level of the new/replacement item using the Controller Upgrade Utility. Click DeltaV | Installation |
Controller Upgrade Utility and then click the Show Revision Info button.
2. If the revision level of the new/replacement item matches your system revision level, you do not need to do anything further.
3. If the revision level of the new/replacement item does not match your system revision level, upgrade the controller or I/O card by
following the steps listed in the Software Updates topic.
Managing and Configuring Cisco Switches
This group of topics explain how to manage and configure Cisco switches.
Overview to Managing Cisco Switches
There are three ways to manage Cisco switches:
 Command line management through the switch’s serial port
 Telnet command line management over the DeltaV LAN
 Web-based switch management:
 with Cisco Systems’ Cluster Management Suite software for 2950 and 3550 series switches. The software is built into the
switches and a web browser is used to manage the switches.
 with Cisco Systems’ Device Manager software for the 3750 Series switches. The software is built into the switches and a web
browser is used to manage the switches.
 with Cisco Systems’ Network Assistant for 3750, 2950, and 3550 series switches. This software is used to manage the switches
and must be downloaded from the Cisco website. This is optional software and is not required for basic switch management.
Command Line and Telnet Switch Management
On the ProfessionalPLUS workstation only, the switches can be managed from the command line over the serial port or managed through
Telnet from the command line over the Primary and Secondary DeltaV Control Networks. Refer to Setting Up the ProfessionalPLUS
Workstation for Telnet Switch Management for more information.
Web-Based Switch Management
The Cisco Cluster Management Suite for 2950 and 3550 series switches and Cisco Device Manager for 3750 switches are embedded on every
managed Ethernet switch on the DeltaV Control Network. The software suite provides graphs of network statistics and displays front panel
views of the switch and its ports. It allows switch configuration, diagnostics, and troubleshooting in addition to network management.
Because this type of graphical web management requires additional CPU resources and memory, it is supported on a separate PC called a
Management station. It is not supported on any DeltaV workstation. Refer to Installing Your DeltaV Digital Automation System for
information on the Management station's hardware and installation requirements. To view all of the graphics that are embedded in the Cisco
2950 and 3550 series switches, the Management station must run Internet Explorer, Windows XP, and Java software Version 1.4.0. Java 1.4.0
can be downloaded from the Cisco website. Java software does not need to be downloaded to view all graphics for the 3750 series switches;
however, for additional graphics and switch management features that are not available with the standard, on-board, Device Manager
graphics, Cisco’s Network assistant can be downloaded from the Cisco website.
Switch management is required to set up fiber-optic ports on switches especially if the network contains a mixture of equipment from
different vendors (qualified for use with a DeltaV system). If equipment from different vendors is used, the speed or duplex settings for some
ports may need to be changed. These changes can be made using the embedded Original Equipment Manufacturer’s (OEM) switch
management software and the additional switch management station. Fiber-optic port configuration can be implemented using a telnet session,
a web browser, or the console port serial interface. Use of the console port serial interface does not require an IP addresses because it is a local
and direct connection to each switch. If a small system is being installed, it might be just as easy to manage the switch permanently using the
console port serial interface rather than implementing IP addressing. Determining which management method to use is a user preference and
depends on the complexity of the network and the availability of dedicated Management stations.
Overview to Configuring Cisco Switches
Cisco Switch Operating Software
DeltaV systems require a specific version of Cisco switch software and a special switch configuration. Using other versions of the switch
software or an improperly configured switch could cause serious problems with the operation of the DeltaV system. Switches ordered from
Emerson Process Management are shipped with the supported software version and are pre-configured to operate properly with the DeltaV
system. To ensure that you have the proper switch configuration and the correct switch software for your DeltaV system, you should purchase
the switch though normal Emerson channels. The DeltaV supported software version of the switch may not be the version that is currently
shipping on off-the-shelf Cisco switches.
To verify the configuration of a switch supplied by Emerson Process Management, refer to the sections (under this topic) about configuring
Cisco switches. These sections provide written examples of correct, DeltaV specific switch configuration for the supported revision level of
the switch software. Emerson Process Management does not provide the Cisco operating software separately for field configuration. If you
purchase Cisco switches from sources other than Emerson Process Management, the switch must be configured to DeltaV instructions and the
supplier is responsible for ensuring that the switch software is at the supported revision level.
Cisco Switch Configuration for DeltaV Use
All Cisco switches shipped from Emerson factories are pre-configured to operate properly with the DeltaV system. This means that any
combination of the model numbers supported and shown on the network diagrams in Appendix G of the Installing Your DeltaV Digital
Automation System manual can be interconnected and attached to any DeltaV device and will operate correctly with no further software
configuration. Some configuration is required to manage the switches over the DeltaV network. Refer to Appendix G of the Installing Your
DeltaV Digital Automation System manual for examples.
Cisco Switch Configuration and Cisco Factory Defaults
 Spanning-Tree and IGMP Snooping - The DeltaV system does not require the use of Spanning-Tree or IGMP Snooping to operate
properly; therefore, these features are disabled by Emerson Process Management. Under certain circumstances, these features may
cause unpredictable behavior of the DeltaV system.
 Cisco Discovery Protocol (CDP) - The DeltaV system does not require switch management for the system to operate properly;
therefore, Cisco Discovery Protocol (CDP), a process where each switch sends packets to all ports to discover other switches on a
periodic basis, is disabled by Emerson Process Management. By disabling this feature, unnecessary CDP packets are kept from reaching
controller and workstation ports that will never use them. CDP can be re-enabled on specific ports, for example ports that connect two
switches. This is an advantage if switch management, through Cisco's Cluster Management Suite, will be used. This web-based
management feature allows the assignment of one IP address to a cluster of up to 16 switches that can all be managed with one IP
address. If more than 16 switches are to be managed, more clusters can be created using this Cisco feature. Alternately, all switches on
the network can be managed using one IP address assigned to each switch. In this case, CDP need not be re-enabled on switch-to-switch
connection ports. Refer to the Cisco documentation for information on Cisco Cluster Management through the Internet Explorer and
web browser.
 Port Trunking - The DeltaV system does not require port trunking for the system to operate properly; therefore, Switchport Mode
Access and Switchport Nonegotiate are configured by Emerson Process Management so that controller and workstation ports do not
exchange unnecessary packets between the switch and DeltaV device ports.
 Fiber Optic Port Speed and Duplex - Fiber Optic ports on the Cisco 2950C switch (2 MTRJ ports) are configured by Cisco to
function at 100Mbit full duplex. These settings cannot be changed. The 24 MTRJ fiber optic ports on the Cisco 3550-FX fiber optic
switch and the 24 MTRJ fiber optic ports on the Cisco 3750FS switch are configured by Emerson Process Management to function at
100Mbit full duplex because they are initially configured to 100Mbit half duplex which is not optimal for switch-to-switch backbone
communications. This Emerson configuration allows all DeltaV-supported Cisco switches with fiber optic MTRJ ports to be
interconnected with fiber optic cable without further adjustments. If other manufacturers' equipment will be connected to Cisco
equipment, fiber optic port speed and duplex must be configured to match the Cisco ports and the Cisco ports must be configured to
match the other equipment's ports or there will be serious communications problems. Be cautious when attaching other DeltaV
approved 3rd party media converters or hubs or switches to the Cisco equipment – always be sure to make configuration adjustments
before attaching the cables to the Cisco switches.
 Twisted Pair Port Speed and Duplex - Twisted pair ports on the Cisco switches are configured to operate in auto-negotiate and auto-
sense mode. The ports automatically detect the speed and duplex of the attached device and adjust the port accordingly. There is no
need to hard-configure the twisted pair ports to any speed or duplex.
Setting Up the ProfessionalPLUS Workstation for Telnet Switch Management
This topic explains how to set up the ProfessionalPLUS workstation in order to use Telnet to manage Cisco switches.
Note The following steps are performed on the ProfessionalPLUS workstation.
1. Connect the ProfessionalPLUS workstation's Comm Port to the switch's Console serial port on the rear of the switch with the serial
cable that is included with the Cisco switch.
2. Start a terminal session such as a HyperTerminal session on the ProfessionalPLUS workstation and set the properties to 9600 baud, 8
data bits, No parity, 1 stop bit, no flow control, and save.
3. Connect power to the Cisco switch - the switch boot up process is displayed on the terminal.
4. The first line that is displayed when the Cisco switch begins to boot up varies between switches. Depending upon the switch type, it
takes about 1.5 to 2 minutes to boot.
5. After about 1.5 - 2 minutes, the following line is displayed:
Press RETURN to get started!
6. Do not immediately press return. Wait a few more seconds until this final line is displayed:
xx:xx:xx %LINEPROTO-5-UPDOWN:Line protocol on Interface Vlan1; changed state to up
7. Press Return. The default switch> prompt is displayed:
Switch>
8. Type enable at the initial command prompt and press Return. The privileged EXEC mode prompt is displayed:
Switch#
9. An IP address and subnet mask must be entered to manage the switch using Telnet. To begin the process of entering IP management
information, type config t at the Switch# prompt and press Return. The system displays:
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#
10. Type interface vlan1 at the prompt and press Return. The system displays:
Switch(config-if)#
11. Enter an approved IP address followed by the subnet mask by typing ip address 10.4.128.18 255.254.0.0 and press Return at the
prompt. The system displays:
Switch(config-if)#
12. Type no shutdown at the prompt and press Return. The system displays:
Switch(config-if)#
XXXXX: %LINK-3-UPDOWN: Interface Vlan1, changed state to up
XXXXX: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
13. Press Return at the prompt. The system displays:
Switch(config-if)#
Caution The following steps allow unrestricted, full Read/Write Telnet access to the switch through the use of passwords for the Telnet
sessions. Consult the Cisco documentation for information on configuring more restrictive access to the switch.
14. Type line vty 0 4 at the prompt and press Return. The system displays:
Switch(config-line)#
15. Type password <password> at the prompt and press Return. The system displays:
16. Type line vty 5 15 at the prompt and press Return. The system displays:
18. Type line con 0 at the prompt and press Return. The system displays:
20. Type end at the prompt. The system displays:
Switch#
XXXXX: %SYS-5-CONFIG_I: Configured from the console by console
Switch#
22. To permanently save the IP address, subnet mask, password, and shutdown configuration information, type write mem at the prompt.
The system displays:
Building configuration. . .
[OK]
Switch#
23. To view the new information, type sho config, and press Return at the prompt. Verify that the new IP address and subnet mask are
entered correctly toward the end of the configuration file and that the parameter “shutdown” is not present near the end of the file.
24. When all IP address information is verified, use the ProfessionalPLUS workstation to enter the switch's IP address to manage the switch
from a Telnet session.
25. Repeat this procedure for every switch that will be managed through Telnet. Be sure to use a unique IP address for each switch.
Configuring the Cisco 2950 and 2950C Switches
Inside this topic
This topic explains how to verify that the correct Emerson defaults have been configured on the Cisco 2950 and 2950C switches and explains
how to configure the defaults if necessary. It also provides additional configuration information.

Verifying Emerson Factory Defaults on the Cisco 2950 and 2950C Switches
To verify that you have the correct factory defaults configured on the switch, follow these instructions:
1. Connect the switch management station’s Comm Port to the switch’s Console serial port on the rear of the switch with the serial cable
that is included with the Cisco switch.
2. Start a terminal session such as a HyperTerminal session on the switch management station and set the properties to 9600 baud, 8 data
bits, No parity, 1 stop bit, no flow control, and save.
4. The first line that is displayed begins with:
C2950 Boot Loader . . .
5. After about 1-1.5 minutes, the following line is displayed:
6. Do not press return. Wait a few more seconds until this final line is displayed:
xx:xx:xx %LINEPROTO-5-UPDOWN:Line protocol on Interface Vlan1; changed state to down
Switch>
Switch#
9. Type show config at the prompt and press Return. The first few lines of the switch configuration file are displayed. Then press Return
repeatedly until the entire file is displayed as follows:
Note There are some differences between the 2950 and 2950C configuration files. The configuration file for the 2950 reports information for
its 24 ports in the sections beginning with Interface FastEthernet01 and ending with Interface FastEthernet24. The 2950C reports
additional configuration information for its two, MTRJ fiber optic ports in sections Interface FastEthernet25 through Interface
FastEthernet26. Finally, the line no ip address is valid only for the 2950C ports.
Using xxxx out of 32768 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Switch
!
!
ip subnet-zero
no ip igmp snooping
!

!
spanning-tree mode pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
no spanning-tree vlan 1
!
!
interface FastEthernet0/1
switchport mode access
switchport nonegotiate
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
ip http server
!
no cdp run
!
line con 0

line vty 5 15

!
end

Switch#

10. Verify that your switch configuration matches the preceding configuration. Note that as additional configuration occurs, some
information changes. The information above is for a new switch from the Emerson factory.
11. Type show flash at the prompt and press Return. The following lines display:
Directory of flash:/

Mar 05 1993 03:08:22 env_vars
Mar 01 1993 00:12:10 html
Mar 01 1993 00:02:14 config.text
Mar 01 1993 18:30:55 info
Mar 01 1993 18:30:55 info.ver
Mar 01 1993 00:02:15 private-config.text
Mar 01 1993 18:29:35 c2950-i6q4l2-mz.121-13.EA1c.bin

xxxxxxx bytes total (xxxxxxx bytes free)
Switch#
12. Verify that the filenames displayed match the above filenames. Note that as additional configuration occurs, file size changes. The
information above is for a new switch from the Emerson factory. If the file names do not match, refer to Configuring the 2950 and
2950C Switches to Emerson Defaults to configure the switch to the minimum defaults for use with the DeltaV system.

Configuring the Cisco 2950 and 2950C Switches to Emerson Defaults
Note When you get to step five, notice that there is a slight difference in the procedure for configuring the 2950 and 2950C switches.
Otherwise, the configuration procedure is the same for both switches.
1. To begin the process of configuring the switch to Emerson factory defaults, type config t at the Switch# prompt and press Return. The
following line is displayed.
Switch(config)#
Note If the Switch> prompt is displayed instead of the Switch# prompt, type ena at the Switch> prompt.
Switch(config-if)#
3. Type no ip igmp snooping at the prompt and press Return. The system displays:
Switch(config)#
4. Type no spanning-tree vlan 1 at the prompt and press Return. The system displays:
Switch(config)
5. For the Cisco 2950, type interface range fastethernet0/1 -24 at the prompt and press Return. For the Cisco 2950C type interface
range fastethernet0/1 -26 at the prompt and press Return. The system displays:
Switch(config-if-range)#
6. Type switchport mode access at the prompt and press Return. The system displays:
7. Type switchport nonegotiate at the prompt and press Return. The system displays:
8. Type no cdp enable at the prompt and press Return. The system displays:
9. Type end at the prompt and press Return. The system displays:
Switch#
xx:xx:xx: %SYS-5-CONFIG_I: Configured from console by console
10. Press Return. The system displays:
Switch#
11. Type write mem at the prompt and press Return. The system displays:
[OK]
Switch#
12. Verify that the configuration for the Cisco switches matches the Emerson factory defaults (except for IP address and “shutdown”
information you may have entered) by typing show config at the prompt and pressing Return repeatedly to step through the file.
Note There is a slight difference between the 2950 and 2950C switches in item 3 in the following configuration information. The
configuration information for the 2950C reads: 3) interface fastethernet0/1 (and all other ports through 0/26). In addition, the line no ip
address is valid for the 2950C ports only.
Verify that the following items are in the configuration file:
1) no ip igmp snooping (near the beginning of the file)
2) no spanning-tree vlan 1 (near the beginning of the file)
3) interface fastethernet0/1 (and all other ports through 0/24)
no ip address
no cdp enable
shutdown (near the end of the file unless removed for telnet/web management)
no cdp run (near the end of the file – unless Cisco Cluster Management is being used)
13. After verifying the above information, press Return until the Switch# prompt appears. This is the end of the Emerson Factory Default
configuration process.

Displaying Port Statistics on the Cisco 2950 and 2950C Switches
1. The serial console port can also be used for troubleshooting network problems. To view network statistics over this serial Console port
for Ethernet Port 1 for example, type show interface fastethernet 0/1 at the prompt and press Return repeatedly. The system displays
these lines: (Information varies depending on switch address, port connections, and network load.)
FastEthernet0/1 is down, line protocol is down (notconnect)
Hardware is Fast Ethernet, address is 0007.eca9.8941 (bia 0007.eca9.8941)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto-duplex, Auto-speed
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:51:16, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute ouxtput rate 0 bits/sec, 0 packets/sec
1 packets input, 64 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
1 packets output, 64 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
<>0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
Switch#
2. To view network statistics for all ports on the switch, type show interface at the prompt and press Return repeatedly to display all ports.
The information varies depending on switch address, port connections, and network load.
3. To clear or “zero” the fast ethernet port counters to get fresh data, type clear counters at the prompt and press Return. The system
displays:
Clear “show interface” counters on all interfaces [confirm]
Note Clear the counters after all cables have been attached so that temporary cable installation errors are not counted as part of the run time
statistics.
Switch#
%CLEAR-5-COUNTERS: Clear counter on all interfaces by console
Switch#
6. This serial console port can also be used to view Ethernet controller statistics. To view statistics for Ethernet Port 1 for example, type
the following at the prompt:
show controller ethernet-controller fastethernet 0/1 and press Return repeatedly. The system displays the following lines:
(Information varies depending on port connections, and network load.)
Transmit Receive
64 Bytes 64 Bytes
1 Frames 1 Frames
0 Multicast frames 0 FCS errors
0 Broadcast frame 0 Multicast frames
0 Pause frames 0 Broadcast frames
0 Single defer frames 0 Control frames
0 Multiple defer frames 0 Pause frames
0 1 collision frames 0 Unknown opcode frames
0 2-15 collisions 0 Alignment errors
0 Late collisions 0 Length out of range
0 Excessive collisions 0 Symbol error frames
0 Total collisions 0 False carrier errors
0 Control frames 0 Valid frames, too small
0 VLAN discard frames 0 Valid frames, too large
0 Too old frames 0 Invalid frames, too small
0 Tagged frames 0 Invalid frames, too large
0 Aborted Tx frames 0 Discarded frames
Transmit and Receive
2 Minimum size frames
0 65 to 127 byte frames
Switch#
7. To view controller statistics for all ports on the switch, type show controller ethernet-controller at the prompt and press Return
repeatedly. All ports are displayed. (Information varies depending on switch address, port connections, and network load.)
8. To clear or “zero” the ethernet controller counters to get fresh data, type clear controller ethernet-controller at the prompt and press
Return. The system displays:
Switch#
statistics.

Enabling the Cisco 2950 and 2950C Switches for Telnet and Web Management
1. An IP address and subnet mask must be entered to manage the switch using telnet or a web browser. To begin the process of entering IP
management information, type config t at the Switch# prompt and press Return. The system displays:
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
1d06h: %LINK-3-UPDOWN: Interface Vlan1, changed state to up
1d06h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
Switch(config-if)#
6. Type end at the prompt. The system displays:
Switch#
1d06h: %SYS-5-CONFIG_I: Configured from the console by console
Switch#
8. To permanently save the IP address, subnet mask, and shutdown configuration information, type write mem at the prompt. The system
displays:
[OK]
Switch#
9. To view the new IP address information, type sho config, and press Return at the prompt. Verify that the new IP address and subnet
mask are entered correctly toward the end of the configuration file and that the parameter “shutdown” is no longer present as it was
when viewing Emerson factory defaults in Verifying Emerson Factory Defaults on the Cisco 2950 and 2950C Switches.
10. When all IP address information is verified, use the management PC station’s web browser to enter the switch’s IP address for
managing the switch. See the Cisco documentation for use of the Cisco web management interface.

Using the Web Console to Set Up a Telnet Password to Manage the Cisco 2950 and 2950C Switches
Telnet switch management can be used from within the web browser by selecting telnet from the Cisco switch display in the web browser.
Before telnet can be used however, complete all of the steps in Enabling the Cisco2950 and 2950C Switches for Telnet and Web
Management. When those steps are complete, attach a shielded twisted pair cable to one of the switch’s Ethernet ports, then enter the IP
address of the new switch in the Internet Explorer address box of the switch management station and the Cisco switch display will appear. Use
the Administration/Users and Passwords/Terminal Lines dialog, found in the switch display, and the Cisco documentation to determine
the different levels of password protection options that can be used for telnet access. For example, enter a unique password and select level 15
for full read/write access to the switch. Different levels of access for different management functions are possible. Consult the Cisco
documentation for these options.
Be sure to OK and save the password and access level information to permanent memory. Save this information by using the Administration
Save Configuration dialog box and selecting the appropriate check-boxes to select Source/Running Configuration and
Destination/Startup Configuration. Alternately, if the serial connection is still attached to the switch once the passwords are entered from
the web browser, enter the write mem command from the config t switch prompt and the new password information will be saved in
permanent memory. You can view the new passwords and access levels by entering the show config command at the switch prompt either
from the serial console port or from telnet.

About Cisco Cluster Management
Cisco Cluster Management is sometimes used for managing a large number of switches. Cluster Management requires only one IP address for
managing up to 16 switches anywhere on the network. If there are more than 16 switches, additional clusters can be used. An IP address can
be assigned to every switch if desired, but it is not necessary if Cluster Management is used. Refer to Reserved IP address for the approved list
of IP addresses that can be used for Ethernet switches. Assigning a name to each switch is helpful for keeping track of a switch's location,
especially if Cluster Management is used and IP addresses are not assigned to every switch.
In a network where there is a mixture of different Cisco switch types, Cisco Systems recommends that the highest performance switch should
be used as the Cluster Command Switch. DeltaV systems makes use of Cisco 2950, 2960, 3550, and 3750-series switches. If these are mixed
on the network, use a 3750-series switch as the cluster command switch. This way, one 3750 switch could have an IP address assigned to it
and designated as the cluster command switch for up to 15 of the same or other switch types.
In order for cluster management to automatically discover up to 16 switches on the network, Cisco Discovery Protocol (CDP) must be running
on all switches but enabled only on ports that connect switches and not enabled on ports that are connected to DeltaV workstations or
controllers. For example, if a fiber optic port on a Cisco switch is connected to a fiber optic port on another Cisco switch, both switches must
have CDP enabled (running), and only the two fiber optic ports must have no cdp enable removed from their port configuration. The same
is true for any other port on a switch that is connected to another switch. Similarly, it is true for a twisted pair port on one switch that is
connected to a twisted pair port on a another switch. If cluster management is used, enable cdp run for the switch and remove no cdp
enable for each connected switch-to-switch port.

Enabling Cisco Discovery Protocol for Cisco Cluster Management on the Cisco 2950 and 2950C Switches
The following procedure shows how to configure a switch for Cisco Discovery Protocol (CDP) using the serial console port or telnet
interface. This allows the cluster command switch to ”find” the other switches on the network automatically and draw a network map:
1. At the Switch> prompt at either a telnet session or serial port session, type ena and press Return. The system displays:
Switch#
2. Type config t at the prompt and press Return. The system displays:
Switch(config)#
Switch(config-if)#
4. Type cdp run at the prompt and press Return. The system displays:
Switch(config)#
5. If port 24 is used as a connection to another switch, type interface fastethernet 0/24 at the prompt and press Return. The system
displays:
Switch(config-if)#
6. Type cdp enable at the prompt and press Return. The system displays:
Switch(config-if)#
Switch#
8. Press return. The system displays:
Switch#
Building configuration...
[OK]
Switch#
10. Type show config at the prompt and press Return repeatedly and verify that no cdp enable has been removed from the port 24
configuration (compare port 24 to other ports to see that no cdp enable is removed from this port). Press Return repeatedly to verify
that near the end of the file, no cdp run has been removed. Refer to Verifying Emerson Factory Defaults on the Cisco 2950 and 2950C
Switches to compare to the Emerson factory default configuration.
11. Cisco Discover Protocol (CDP) has now been successfully configured and saved to permanent memory. Repeat this process for all other
switches in this network and for each port that has a switch-to-switch port connection. When configuration is complete, use the Cisco
Cluster Management Suite in the web browser to start the automatic discovery of all switches on the network and then assign them to a
cluster for management. Consult Cisco documentation for this information.

Rebooting the Cisco 2950 and 2950C Switches
It is not often necessary to reboot a switch. Be sure that you reboot the switch at an appropriate time because rebooting the switch will cause
loss of communications to attached devices and loss of configuration changes if the changes have not been saved using the write mem
command. Be sure that if you intend to reboot the switch, you have saved your configuration changes and that you can safely reboot without
impacting plant operations. To reboot the switch, type reload at the prompt, and in about 1-1.5 minutes the switch will complete it’s boot
process. Press Return after the switch has stopped booting and wait until the Switch> prompt displays. The switch is now ready for normal
operation.
Configuring the Cisco 2960-8TC-L Switch
Inside this topic
This topic explains how to verify that the correct Emerson defaults have been configured on the Cisco 2960-8TC-L switch and explains how
to configure the defaults if necessary. It also provides additional configuration information.

Verifying Emerson Factory Defaults on the Cisco 2960-8TC-L Switch
1. Connect the switch management station’s Comm port to the switch’s Console serial port on the switch with the serial cable that is
included with the Cisco switch.
3. Connect power to the Cisco switch - the switch boot up process begins.
4. The first few lines of the boot process are displayed.
5. After about 1.5 – 2.5 minutes, the LED on the switch port that has the Ethernet cable attached illuminates green (not amber) and these
lines are displayed:
6. Do not press Return yet. Wait a few more seconds until this final line is displayed:
%LINEPROTO-5-UPDOWN:Line protocol on Interface Vlan1; changed state to up
7. Press Return. The default Switch> prompt is displayed:
Switch
8. Type enable at the Switch> prompt and press Return. The privileged EXEC mode prompt is displayed:
Switch#
Using xxxx out of xxxxxx bytes
!
version 12.2
no service pad

service password-encryption
vtp mode transparent
!
hostname Switch
!
!
No aaa new-model
System mtu routing 1500
ip subnet-zero
!
no ip igmp snooping
!
!
!
No file verify auto
!
!
vlan internal allocation policy ascending
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
interface GigabitEthernet0/1
no cdp enable
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
no ip http server
ip http secure-server
no cdp run
!
control-plane
!
!
line con 0
line vty 5 15
!
end

Switch#
11. Type show flash at the prompt and press Return. The following lines are displayed:

Mar 1 xxxx xx:xx:xx private-config.text
Mar 1 xxxx xx:xx:xx c2960-lanbasek9-mz.122-37.SE1
Mar 1 xxxx xx:xx:xx config.text

Switch#
information above is for a new switch from the Emerson factory. If the file names do not match, refer to Configuring the 2960-8TC-L
Switch to Emerson Defaults to configure the switch to the minimum defaults for use with the DeltaV system.

Configuring the Cisco 2960-8TC-L Switch to Emerson Defaults
Refer to Verifying Emerson Factory Defaults on the Cisco 2960-8TC-L Switch to get started with connecting and booting the switch to get to
the Switch> prompt.
1. To begin the process of configuring the switch to Emerson factory defaults, type enable at the Switch> prompt, then press Return, then
type config t at the Switch# prompt, and press Return. The following lines are displayed:
Switch(config-if)#
Switch(config)#
Switch(config)#
5. Type service password-encryption at the prompt and press Return. The system displays:
Switch(config)#
6. Type vtp mode transparent at the prompt and press Return. The system displays:
Switch(config)#
7. Type interface range fastethernet0/1 -8 at the prompt and press Return:
Switch#
Switch#
Switch(config)#
14. Type interface gigabitethernet0/1 at the prompt and press Return. The system displays:
Switch(config-if)#
Switch#
Switch#
Switch(config)#
Switch(config-if)#
22. Type no cdp run at the prompt and press Return. The system displays:
Switch(config)#
23. Type no ip http server at the prompt and press Return. The system displays:
Switch(config)#
Switch(config-if)#
25. Type shutdown at the prompt and press Return. The system displays:
Switch(config)#
Switch#
Switch#
[OK]
Switch#
29. Verify that the configuration for the Cisco switches matches the Emerson factory defaults (except for IP address and shutdown
information you may have entered) by typing show config at the Switch# prompt and pressing enter repeatedly to step through the file.
3) service password encryption (near the beginning of the file)
4) vtp mode transparent (near the beginning of the file)
5) interface fastethernet0/1 (and all other ports through fastethernet 0/8 and gigabitethernet 0/1)
no cdp enable
no ip http server (near the end of the file unless removed for telnet/web management)

Configuring a Giga-bit SFP Slot for a 100BASE FX Fiber Optic Module
Switch>enable
*****
Switch#config t
Switch(config)# interface gigabitethernet0/1
Switch(config-if)#
At the Switch(config-if)# prompt enter the following two commands
media-type sfp
duplex full

Switch(Config-if)#end
System displays
Switch#
xx:xx: %SYS-5-CONFIG_I: Configured from console by console
press Return
Switch#write mem
[OK]
Switch#

Displaying Port Statistics on the Cisco 2960-8TC-L Switch
The serial console port can also be used for troubleshooting network problems.
1. To view network statistics over the serial Console port for Ethernet Port 1 for example, type show interface fastethernet 0/1 at the
Switch> prompt and press Return repeatedly. The system displays these lines: (Information varies depending on switch address, port
connections, and network load.)
FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet,address is 001b.0d56.de81 (bia 001b.0d56.de81)
reliability255/255, txload 1/255, rxload 1/255
Keepaliveset (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
Output queue: 0/40 (size/max)
5 minute output rate 0 bits/sec, 0 packets/sec
Received 10 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 babbles, 0 late collision, 0 deferred
Switch>
3. To clear or zero all of the fastethernet port counters to get fresh data for all ports, type enable at the Switch> prompt and press Return,
then type clear counters at the Switch# prompt and press Return. The system displays:
statistics.
Switch#
xx:xx:xx %CLEAR-5-COUNTERS: Clear counter on all interfaces by console
Switch#
show controller ethernet-controller fastethernet 0/1 at the Switch> prompt and press Return repeatedly. The system displays the
following lines: (Information varies depending on port connections, and network load.)
Transmit FastEthernet0/1 Receive
49536 Bytes 1433 Bytes
774 Unicast frames 0 Unicast frames
0 Multicast frames 7 Multicast frames
0 Broadcast frames 10 Broadcast frames
0 Too old frames 0 Unicast bytes
0 Deferred frames 793 Multicast bytes
0 MTU exceeded frames 640 Broadcast bytes
0 1 collision frames 0 Alignment errors
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 0 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 14 Minimum size frames
0 8 collision frames 0 65 to 127 byte frames
0 13 collision frames 0 Overrun frames
0 14 collision frames 0 Pause frames
0 Late collisions 0 Invalid frames, too large
0 Excess defer frames 0 Invalid frames, too small
774 64 byte frames 0 Valid frames, too small
0 127 byte frames
0 255 byte frames 0 Too old frames
0 511 byte frames 0 Valid oversize frames
0 1023 byte frames 0 System FCS error frames
0 1518 byte frames 0 RxPortFifoFull drop frame
0 Too large frames
0 Good (1 coll) frames
0 Good (>1 coll) frames

Switch>
7. To view controller statistics for all ports on the switch, type show controller ethernet-controller at the Switch> prompt and press
Return repeatedly. All ports are displayed. (Information varies depending on switch address, port connections, and network load.)
8. To clear or zero the Ethernet controller counters to get fresh data for all ports, type clear controller ethernet-controller at the Switch#
prompt and press Return. The system displays:
Switch#
statistics.

Enabling the Cisco 2960-8TC-L Switch for Telnet and Web Management
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
xx:xx:xx: %LINK-3-UPDOWN: Interface Vlan1, changed state to up
xx:xx:xx: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
Switch(config-if)#
6. Type line con 0 (the numeral zero) at the prompt and press Return. The system displays:
7. Type password, enter password here and press Return. The system displays:
8. Type line vty 0 4 and press Return. The system displays:
12. Type ip http server at the prompt and press Return. The system displays:
Switch(config)#
Switch#
xx:xx:xx: %SYS-5-CONFIG_I: Configured from the console by console
Switch#
15. To permanently save the IP address, subnet mask, and shutdown configuration information, type write mem at the prompt and press
[OK]
Switch#
16. To view the new IP address information, type sho config at the prompt, and repeatedly press Return at the prompt. Verify that the new
IP address and subnet mask are entered correctly toward the end of the configuration file and that the parameter shutdown is no longer
present as it was when viewing Emerson factory defaults in Verifying Emerson Factory Defaults on the Cisco 2960-8TC-L Switch.
managing the switch. Refer to the Cisco documentation for information on using the Cisco web management interface.

Enabling Cisco Discovery Protocol for Cisco Cluster Management on the Cisco 2960-8TC-L Switch
Before enabling Cisco Discovery Protocol (CDC) refer to About Cisco Cluster Management for more information.
The following procedure shows how to configure a switch for CDP using the serial console port or telnet interface. This allows the cluster
command switch to find the other switches on the network automatically and draw a network map:
1. At the Switch> prompt at either a telnet session or serial port session, type enable and press Return. The system displays:
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
5. If gigabitethernet port 0/1 is used as a connection to another switch, type interface gigabitethernet 0/1 at the prompt and press Return.
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
10. Type show config at the prompt and press Return repeatedly and verify that no cdp enable has been removed from the gigabitethernet
port 0/1 configuration. press Return repeatedly to verify that near the end of the file, no cdp run has been removed. Refer to Verifying
Emerson Factory Defaults on the Cisco 2960-8TC-L Switch to compare to the Emerson factory default configuration.
11. Cisco Discover Protocol (CDP) configuration has now been successfully configured and saved to permanent memory. Repeat this
process for all other switches in this network and for each port that has a switch-to-switch port connection. When configuration is
complete, use the Network Assistant Tab in the web browser of the switch to download Cisco Network Assistant to your Network
Management Station (any non-DeltaV software PC). This application will allow you to start the automatic discovery of all switches on
the network and then assign the switches to a cluster for centralized switch management. Consult Cisco documentation for further
information on the use of Cisco Network Assistant.

Rebooting the Cisco 2960-8TC-L Switch
impacting plant operations. To reboot the switch, type reload at the Switch# prompt, and in about 1.5 – 2.5 minutes the switch will complete
the boot process. press Return after the switch has stopped booting (when the port LEDs are illuminated green (not amber). The switch is now
ready for normal operation.
Inside this topic

1. Connect the switch management station's Comm Port to the switch's Console serial port on the switch with the serial cable that is
5. After about 1.5 - 2.5 minutes, the LED on the switch port that has the Ethernet cable attached illuminates green (not amber) and these
Switch>
Switch#
Using xxxx out of xxxxx bytes
!
version 12.2
no service pad
!
hostname Switch
!
!
no aaa new-model
ip subnet-zero
!
no ip igmp snooping
!
!
!
no file verify auto
!
!
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
no ip http server
no cdp run
!
control-plane
!
!
line con 0
line vty 5 15
!
end

Switch#
Apr 13 xxxx xx:xx:xx xx:xx config.text
Apr 13 xxxx xx:xx:xx xx:xx private-config.text
Apr 13 xxxx xx:xx:xx xx:xx c2960-lanbasek9-mz.12-25.SEE4
xxxxxxxx bytes total (xxxxxxxx bytes free)
Switch#

Note Refer to the section titled Verifying Emerson Factory Defaults on the Cisco 2960-24TC-L Switch to get started with connecting and
booting the switch to get to the Switch prompt.
1. To begin the process of configuring the switch to Emerson factory defaults, type enable at the Switch> prompt and press Return. Then
Return configuration commands, one per line. End with CNTL/Z.
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config)#
5. Type service password encryption at the prompt and press Return. The system displays:
Switch(config)#
Switch(config)#
Switch#
Switch#
Switch(config)#
14. Type interface range gigabitethernet0/1 -2 at the prompt and press Return. The system displays:
Switch(config-if)#
Switch#
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch#
Switch#
[OK]
Switch#
information you may have entered) by typing show config at the Switch# prompt and pressing Return repeatedly to step through the
file.
5) interface fastethernet0/1 (and all other ports through fastethernet 0/24 and gigabitethernet 0/1 - 0/2)
no cdp enable
no cdp run (near the end of the file - unless Cisco Cluster Management is being used)

Configuring a Giga-Bit SFP Slot for a 100Base FX Fiber Optic Module
Note The port number listed below (interface gigabitethernet0/1) is an example. This entry should reflect the actual port number to be
configured (0/1 or 0/2).
Switch>enable
*****
Switch#config t
Switch(config-if)#
At the Switch(config-if)# prompt, enter the following two commands
media-type sfp
duplex full
Switch#
Press Return
Switch#write mem
[OK]
Switch#

1. The serial console port can also be used for troubleshooting network problems. To view network statistics over the serial Console port
for Ethernet Port 1 for example, type show interface fastethernet 0/1 at the Switch> prompt and press Return repeatedly. The system
displays these lines: (Information varies depending on switch address, port connections, and network load.)
Hardware is Fast Ethernet, address is 001c.0f8a.f281 (bia 001c.0f8a.f281)
Auto-duplex, Auto-speed, media type is 10/100BaseTX
Last input never, output never, output hang never
Received 0 broadcasts (0 multicast)

Switch#
3. To clear or zero all of the fastethernet port counters to get fresh data for all ports, type enable at the Switch> prompt and press Return.
Then type clear counters at the Switch# prompt and press Return. The system displays:
Clear "show interface" counters on all interfaces [confirm]
statistics.
Switch#
Switch#
show controller ethernet-controller fastethernet 0/1 at the Switch> prompt: and press Return repeatedly. The system displays the
following lines: (This information varies depending on port connections, and network load.)
0 Bytes 0 Bytes
0 127 byte frames
0 Too large frames

Switch>
Switch#
statistics.

Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
6. Type line con 0 (zero) at the prompt and press Return. The system displays:
7. Type password, then enter the password and press Return. The system displays:
9. Type password, then enter the password and press Return. The system displays:
11. Type password, enter the password here and press Return. The system displays:
Switch(config)#
Switch#
Switch#
[OK]
Switch#
16. To view the new IP address information, type sho config at the prompt, and repeatedly press Return. Verify that the new IP address and
subnet mask are entered correctly toward the end of the configuration file and that the parameter shutdown is no longer present as it was
when viewing Emerson factory defaults as shown in Verifying Emerson Factory Defaults on the Cisco 2960-24TC-L Switch.
17. When all IP address information is verified, use the management PC station's web browser to enter the switch's IP address for managing
the switch. Refer to the Cisco documentation for information on using the Cisco web management interface.

Before enabling Cisco Discovery Protocol (CDC) refer to About Cisco Cluster Management.
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
10. Type show config at the prompt, press Return repeatedly, and verify that no cdp enable has been removed from the gigabitethernet port
0/1 configuration. Press Return repeatedly to verify that near the end of the file, no cdp run has been removed. Refer to Verifying
11. Cisco Discover Protocol configuration has now been successfully configured and saved to permanent memory. Repeat this process for
all other switches in this network and for each port that has a switch-to-switch port connection. When configuration is complete, use the
Network Assistant Tab in the web browser of the switch to download Cisco Network Assistant to your Network Management Station
(any non-DeltaV software PC). This application will allow you to start the automatic discovery of all switches on the network and then
assign the switches to a cluster for centralized switch management. Refer to the Cisco documentation for more information on using the
Cisco Network Assistant.

impacting plant operations. To reboot the switch, type reload at the Switch# prompt, and in about 1.5 - 2.5 minutes the switch will complete
the boot process. Press Return after the switch has stopped booting (when the port LEDs are illuminated green, not amber). The switch is now
Configuring the Cisco 2960-24TT-L Switch
Inside this topic
This topic explains how to verify that the correct Emerson defaults have been configured on the Cisco 2960-24TT-L switch and explains how

Verifying Emerson Factory Defaults on the Cisco 2960-24TT-L Switch
1. Connect the switch management station’s Comm Port to the switch’s Console serial port on the switch with the serial cable that is
5. After about 1.5 – 2.5 minutes, the LED on the switch port that has the Ethernet cable attached illuminates green (not amber) and these
Press RETURN (Return) to get started!
Switch>
Switch#
Using xxxx out of xxxxx bytes
!
version 12.2
no service pad
!
hostname Switch
!
!
no aaa new-model
ip subnet-zero
!
no ip igmp snooping
!
!
!
no file verify auto
!
!
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
no ip http server
no cdp run
!
control-plane
!
!
line con 0
line vty 5 15
!
end

Switch#
Mar 1 xxxx xx:xx:xx xx:xx config.text
Mar 1 xxxx xx:xx:xx xx:xx private-config.text
Apr 1 xxxx xx:xx:xx xx:xx c2960-lanbasek9-mz.122-25.SEE4
xxxxxxxx bytes total (xxxxxxxx bytes free)
Switch#
information above is for a new switch from the Emerson factory. If the file names do not match, refer to Configuring the 2960-24TT-L

Configuring the Cisco 2960-24TT-L Switch to Emerson Defaults
Note Refer to Verifying Emerson Factory Defaults on the Cisco 2960-24TT-L Switch to get started with connecting and booting the switch to
get to Switch> prompt.
1. To begin the process of configuring the switch to Emerson factory defaults, type enable at the Switch> prompt, then press Return, then
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch#
Switch#
Switch(config)#
Switch(config-if)#
Switch#
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch#
Switch#
[OK]
Switch#
file.
no cdp enable
After verifying the above information, press Return until the Switch# prompt appears. This is the end of the Emerson Factory Default

Displaying Port Statistics on the Cisco 2960-24TT-L Switch

Switch#
3. To clear or zero all of the fastethernet port counters to get fresh data for all ports, type enable at the Switch> prompt and press Return,
then type clear counters at the Switch# prompt and press Return. The system displays:
statistics.
Switch#
Switch#
0 Bytes 0 Bytes
0 127 byte frames
0 Too large frames
Switch>
Switch#
statistics.

Enabling the Cisco 2960-24TT-L Switch for Telnet and Web Management
1. An IP address and subnet mask must be Returned to manage the switch using telnet or a web browser. To begin the process of
Returning IP management information, type config t at the Switch# prompt and press Return. The system displays:
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config)#
Switch#
Switch#
[OK]
Switch#
when viewing Emerson factory defaults. Refer to Verifying Emerson Factory Defaults on the Cisco 2960-24TT-L Switch.

Enabling Cisco Discovery Protocol for Cisco Cluster Management on the Cisco 2960-24TT-L Switch
Before enabling Cisco Discovery Protocol (CDP) refer to About Cisco Cluster Management.
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
10. Type show config at the prompt and press Return repeatedly and verify that no cdp enable has been removed from the gigabitethernet
port 0/1 configuration. Press Return repeatedly to verify that near the end of the file, no cdp run has been removed. Refer to Verifying
Emerson Factory Defaults on the Cisco 2960-24TT-L Switch to compare with the Emerson factory default configuration.
assign the switches to a cluster for centralized switch management. Refer to the Cisco documentation for further information on the use
of Cisco Network Assistant.

Rebooting the Cisco 2960-24TT-L Switch
the boot process. Press Return after the switch has stopped booting (when the port LEDs are illuminated green (not amber). The switch is now
Inside this topic

1. Connect the switch management station’s Comm Port to the switch’s Console serial port on the switch with the serial cable that is
5. After about 1.5 – 2.5 minutes, the LED on the switch port that has the Ethernet cable attached illuminates Green (not Amber) and these
Switch>
Switch#
!
version 12.2
no service pad
!
hostname Switch
!
!
no aaa new-model
ip subnet-zero
!
no ip igmp snooping
!
!
!
No file verify auto
!
!
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable

!interface GigabitEthernet0/2
no cdp enable
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
no ip http server
no cdp run
!
control-plane
!
!
line con 0
line vty 5 15
!
end

Switch#
Mar 1 xxxx xx:xx:xx c2960-lanbasek9-mz.122-25.SEE4
Switch#

Note Refer to Verifying Emerson Factory Defaults on the Cisco 2960-48TC-L Switch to get started with connecting and booting the switch to
get to Switch> prompt.
1. To begin the process of configuring the switch to Emerson factory defaults, type enable at the Switch> prompt, press Return, then type
config t at the Switch# prompt, and press Return. The following lines are displayed:
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch#
Switch#
Switch(config)#
Switch(config-if)#
Switch#
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch#
Switch#
[OK]
Switch#
file.
no cdp enable

Configuring a Giga-bit SFP Slot for a 100Base FX Fiber Optic Module
Note The port number listed below (interface gigabitethernet0/1) is an example only. This entry should reflect the actual port number to be
configured (0/1 or 0/2).
Switch>enable
*****
Switch#config t
Switch(config-if)#
At the Switch(config-if)# prompt enter the following two commands
media-type sfp
duplex full
The system displays
Switch#
press enter
Switch#write mem
[OK]
Switch#


Switch#
3. To clear or zero all of the fastethernet port counters to get fresh data for all ports, type enable at the Switch> prompt, press Return, then
type clear counters at the Switch# prompt and press Return. The system displays:
statistics.
Switch#
Switch#
the following at the Switch> prompt: show controller ethernet-controller fastethernet 0/1 and press Return repeatedly. The system
displays the following lines: (Information varies depending on port connections, and network load.)
0 Bytes 0 Bytes
0 127 byte frames
0 Too large frames

Switch>
Switch#
statistics.

Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config)#
Switch#
Switch#
[OK]
Switch#
when viewing Emerson factory defaults.

Before enabling Cisco Discovery Protocol (CDC) refer to About Cisco Cluster Management for more information.
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
10. Type show config at the prompt, press Return repeatedly and verify that no cdp enable has been removed from the gigabitethernet port

Configuring the Cisco 2960-48TT-L Switch
Inside this topic
This topic explains how to verify that the correct Emerson defaults have been configured on the Cisco 2960-48TT-L switch and explains how

Verifying Emerson Factory Defaults on the Cisco 2960-48TT-L Switch
1. Connect the switch management station’s Comm port to the switch’s Console serial port on the switch with the serial cable that is
5. After about 1.5 – 2.5 minutes, the LED on the switch port that has the Ethernet cable attached illuminates Green (not Amber) and these
Switch>
Switch#
!
version 12.2
no service pad
!
hostname Switch
!
!
no aaa new-model
ip subnet-zero
!
no ip igmp snooping
!
!
!
No file verify auto
!
!
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable

!interface GigabitEthernet0/2
no cdp enable
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
no ip http server
no cdp run
!
control-plane
!
!
line con 0
line vty 5 15
!
end

Switch#
Mar 1 xxxx xx:xx:xx c2960-lanbasek9-mz.122-25.SEE4
Switch#
information above is for a new switch from the Emerson factory. If the file names do not match, refer to Configuring the 2960-48TT-L

Configuring the Cisco 2960-48TT-L Switch to Emerson Defaults
Note Refer to the section titled Verifying Emerson Factory Defaults on the Cisco 2960-48TT-L Switch to get started with connecting and
booting the switch to get to Switch> prompt.
1. To begin the process of configuring the switch to Emerson factory defaults, type enable at the Switch> prompt, press Return, and then
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch#
Switch#
Switch(config)#
Switch(config-if)#
Switch#
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch#
Switch#
[OK]
Switch#
file.
no cdp enable

Displaying Port Statistics on the Cisco 2960-48TT-L Switch
1. The serial console port can also be used for troubleshooting network problems. To view network statistics over the serial console port

Switch#
3. To clear or zero all of the fastethernet port counters to get fresh data for all ports, type enable at the Switch> prompt, press Return, then
type clear counters at the Switch# prompt and press Return. The system displays:
statistics.
Switch#
Switch#
0 Bytes 0 Bytes
0 127 byte frames
0 Too large frames

Switch>
Switch#
statistics.

Enabling the Cisco 2960-48TT-L Switch for Telnet and Web Management
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config)#
Switch#
Switch#
[OK]
Switch#
subnet mask are entered correctly toward the end of the configuration file and that the parameter “shutdown” is no longer present as it
was when viewing Emerson factory defaults in Verifying Emerson Factory Defaults on the Cisco 2960-48TT-L Switch.

Enabling Cisco Discovery Protocol for Cisco Cluster Management on the Cisco 2960-48TT-L Switch
Before enabling Cisco Discovery Protocol (CDC) refer to About Cisco Cluster Management.
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
10. Type show config at the prompt, press Return repeatedly, and verify that no cdp enable has been removed from the gigabitethernet port
Emerson Factory Defaults on the Cisco 2960-48TT-L Switch to compare to the Emerson factory default configuration.

Rebooting the Cisco 2960-48TT-L Switch
Configuring the Cisco 3550FX Switch
Inside this topic
This topic explains how to verify that the correct Emerson defaults have been configured on the Cisco 3550FX switch and explains how to
configure the defaults if necessary. It also provides additional configuration information.

Verifying Emerson Factory Defaults on the Cisco 3550FX Switch
1. Connect the management station's Comm Port to the switch's Console serial port on the rear of the switch with the serial cable that is
2. Start a terminal session such as a HyperTerminal session on the management station and set the properties to 9600 baud, 8 data bits, No
parity, 1 stop bit, no flow control, and save.
3. Connect power to the Cisco switch. After a few seconds, the switch boot up process is displayed on the terminal.
4. The first line of the boot up process begins with this information:
Base ethernet MAC Address: . . .
5. After about 1-1.5 minutes, the system displays:
6. Do not press return, wait a few more seconds until the final line is displayed:
xx:xx:xx: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
Switch>
8. Type enable at the prompt and press Return. The system displays:
Switch#
9. Type show config at the prompt and press Return. The first few lines of the switch configuration file are displayed. Press Return
Using 3579 out of 393216 bytes
!
version 12.1
no service pad
!
hostname Switch
!
!
ip subnet-zero
no ip igmp snooping
!
!
!
!
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
duplex full
no cdp enable
!
no ip address
no cdp enable
!
no ip address
no cdp enable
!
interface Vlan1
no ip address
shutdown
!
ip classless
ip http server
!
!
no cdp run
!
line con 0
line vty 0 4
privilege level 15
password deltav
login line vty 5 15
privilege level 15
password deltav
login !
end
Switch#
10. Verify that your switch configuration displayed matches the preceding configuration. Note that as additional configuration occurs, some
11. Type show flash at the prompt and press Return. The system displays:
Mar 01 1993 00:01:31 config.text
Mar 01 1993 00:05:38 c3550-i9q3l2-mz.121-13.EA1c
Mar 01 1993 00:05:48 env_vars
Mar 01 1993 00:05:48 system_env_vars
Mar 01 1993 00:01:31 private-config.text
15998976 bytes total (10737664 bytes free)
Switch#
12. Verify that the filenames displayed match the above filenames. Note that as additional configuration occurs, some filenames change.
The information above is for a new switch from the Emerson factory. If the filenames do not match, refer to Configuring the Cisco
3550FX Switch to Emerson Defaults to configure the switch to the minimum defaults for use with the DeltaV system.

Configuring the Cisco 3550FX Switch to Emerson Factory Defaults
system displays:
Switch(config)#
Note If the Switch> prompt is displayed instead of the Switch# prompt, type ena at the Switch> prompt:
Switch(config-if)#
Switch(config)#
Switch(config)#
5. Type interface range fastethernet0/1 -24 at the prompt and press Return. The system displays:
9. Type duplex full at the prompt and press Return. The system displays:
Switch# xx:xx:xx: %SYS-5-CONFIG_I: Configured from console by console
Switch#
[OK]
Switch#
17. Type show config at the prompt to verify the configuration matches the Emerson factory defaults for a Cisco 3550FX Switch. Press
Return repeatedly to step through the file. Verify these items are present in the configuration file: (IP address and shutdown information
you may have entered will differ.)
1) no ip igmp snooping (near the begining of the file)
3) interface fastethernet0/1 (and all other ports through 0/24)
no ip address
duplex full
no cdp enable
4) interface GigabitEthernet0/1 and GigabitEthernet0/2
no ip address
no cdp enable
5) shutdown (near the end of the file unless removed for telnet/web management)
6) no cdp run (near the end of the file - unless Cisco Cluster Management is being used)
18. After verifying the configuration, press Return until the Switch# prompt appears. This is the end of the Emerson factory default

Configuring Port Duplex on the Cisco 3550FX Switch
A duplex mismatch on a fiber optic link will cause serious communications problems. Fiber optic speed and duplex must match on both ends
of the fiber optic cable before the two ports are connected together. The following procedure shows how to change the Emerson factory
default duplex from full duplex to half-duplex. It uses an example connection between a fiber optic port on a Cisco 3550FX to a 100Mbit half-
duplex media converter.
To configure the duplex setting of a fiber optic switch port to half-duplex:
1. Type config t at the Switch# prompt and press Return. The system displays:
Switch(config)#
2. Type interface fastethernet0/24 (or any fast ethernet port on the switch) and press Return. The system displays:
Switch(config-if)#
3. Type duplex half and press Return. The system displays:
Switch(config-if)#
Switch# xx:xx:xx: %SYS-5-CONFIG_I: Configured from console by console
Switch#
[OK]
Switch#
7. Type show config at the prompt to verify that the duplex setting is changed to half-duplex for this port. Press Return repeatedly to step
through the file until the port entered in step 2 is reached. Verify that "duplex full" has been removed from the port configuration

Displaying Port Statistics on the Cisco 3550FX Switch
1. The serial console port can also be used for troubleshooting network problems. To view network statistics over this serial Console port
for Ethernet Port 1 for example, type the following at the prompt: show interface fastethernet 0/1, Press Return repeatedly, these lines
will be displayed: (information will vary depending on switch address, port connections, and network load)
FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000b.5fbf.3481 (bia 000b.5fbf.3481)
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is off
Output queue :0/40 (size/max)
5 minute ouxtput rate 0 bits/sec, 0 packets/sec
Received 5327 broadcasts, 0 runts, 0 giants, 0 throttles
Switch#
2. To view network statistics for all ports on the switch, type show interface at the prompt and press Return repeatedly. (Information
varies depending upon switch address, port connections, and network load.)
3. To clear or "zero" the fast ethernet port counters to get fresh data, type clear counters and the prompt and press Return. The system
displays:
Clear "show interface" counters on all interfaces [confirm]
statistics.
Switch#
1d05h: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console
Switch#
show controller ethernet-controller fastethernet 0/1 at the prompt and press Return repeatedly. The system displays the following
lines: (information varies depending upon port connections, and network load)
14592 Bytes 442347 Bytes
0 Discarded frames 1 No dest, unicast
0 Too old frames 404 No dest, multicast
0 Deferred frames 0 No dest, broadcast
0 1 collision frames 0 2 collision frames 0 FCS errors
0 14 collision frames 0 Flooded frames
0 Excessive collisions 0 VLAN filtered frames
0 Late collisions 0 Source routed frames
0 Good (1 coll) frames 0 Valid oversize frames
0 Good(>1 coll) frames 0 Pause frames
0 Pause frames 0 Symbol error frames
0 VLAN discard frames 0 Invalid frames, too large
0 Excess defer frames 0 Valid frames, too large
0 Too large frames 0 Invalid frames, too small
0 127 byte frames
0 255 byte frames
0 511 byte frames
0 1023 byte frames
0 1518 byte frames
Switch#
7. To view controller statistics for all ports of the switch, type show controller ethernet-controller at the prompt and press Return
repeatedly. The system displays all ports. (Information varies depending on switch address, port connections, and network load.)
8. To clear or "zero" the ethernet controller counters to get fresh data, type clear controller ethernet-controller at the prompt and press
Switch#
statistics.

Enabling Telnet and Web Management on the Cisco 3550FX Switch
The procedure for enabling telnet and web management is the same for the 2950, 2950C and 3550FX switches. Refer to Enabling the Cisco
2950 and 2950C Switches for Telnet and Web Management .

Using the Web Console to Set Up a Telnet Password for a Cisco 3550FX Switch
Before telnet can be used however, complete all of the steps described in Enabling the Cisco 2950 and 2950C Switches for Telnet and Web
Management . (The procedure is the same for the 2950, 2950C and 3550FX switches. When telnet and web management are enabled, attach a
fiber optic cable between the switch's fiber optic Ethernet ports and the network. Refer to Extending the Control Network with Media
Converters for information on making this connection. When the connection is complete, enter the IP address of the new switch in the
Management Station's Internet Explorer address box and the Cisco switch display will appear. Use the Administration dialog box found in the
switch display and the Cisco documentation to determine the different levels of password protection options that can be used for telnet access.
For example, enter a unique password and select level 15 for full read/write access to the switch. Different levels of access for different
management functions are possible. Be sure to save the password and access level information to permanent memory. (Use the Administration
dialog box and select the appropriate check-boxes to "Save Running Configuration to Startup Configuration".) Alternately, if the serial
connection is still attached to the switch once the passwords are entered from the web browser, enter the write mem command from the
config t switch prompt to save the new password information to permanent memory. Now that the telnet configuration is complete, type
show config at the switch prompt either from the serial console port or from telnet to view the new passwords and access levels.

Enabling Cisco Discovery Protocol for Cisco Cluster Management on the Cisco 3550FX Switch
The procedure for enabling Cisco Discovery Protocol (CDP) is the same for the 2950, 2950C, and 3550FX switches. Refer to About Cisco
Cluster Management and Enabling the Cisco 2950 and 2950C Switches for Cisco Discovery Protocol for Cisco Cluster Management.

Rebooting the Cisco 3550FX Switch
The procedure for rebooting is the same for the 2950, 2950C, and 3550FX switches. Refer to Rebooting the Cisco 2950 and 2950C Switches.

Restoring the Cisco 2950C and 3550FX Switches to Cisco Factory Defaults
1. Enter ena at the Switch> prompt and press Return.
2. Enter write erase at the Switch# prompt and press Return. The system displays
Erasing the nvram filesystem will remove all configuration files! Continue? [confirm]
[OK]
Erase of nvram: complete
Switch# Xx:xx:xx %SYS-7-NV_BLOCK_INIT: Initialized the geometry of nvram
4. Press Return.
5. Enter reload at the Switch# prompt. The system displays:
Proceed with reload ? [confirm]
6. Press Return. The system displays the first line:
Xx:xx:xx: %SYS-5-RELOAD: Reload requested (starts to reboot)
7. After about 1-1.5 minutes the system displays:
-------System Configuration Dialog--------
Would you like to enter the initial configuration dialog? {yes/no]:
8. Wait a few seconds and the system automatically displays more information on the terminal. The last line is:
xx:xx:xx %LINEPROTO-5-UPDOWN: Line protocol on Interface . . .changed state to up
Would you like to enter the initial configuration dialog? {yes/no]:
10. Type n, and press Return. The system displays:
Press Return to get started!
xx:xx:xx: %LINK-5-CHANGED: . . .
xx:xx:xx: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
Switch>
12. Enter ena at the Switch> prompt.
13. Enter Sho config at the Switch# prompt. The system displays:
startup-config is not present
14. Enter Sho flash at the Switch# prompt
(shows files without config.text or private config.text)
Configuring the Cisco 3750G-12S Switch
Inside this topic
This topic explains how to verify that the correct Emerson defaults have been configured on the Cisco 3750-12S switch and explains how to

Verifying Emerson Factory Defaults on the Cisco 3750G-12S Switch
Base ethernet MAC address: . . .
After about 1.5-2.0 minutes, the following line is displayed:
5. Do not immediately press return. Wait a few more seconds until this final line is displayed:
Switch>
Switch#
8. Type show config at the prompt and press Return. The first few lines of the switch configuration file are displayed. Press Return
!
version 12.2
no service pad
!
hostname Switch
!
!
no aaa new-model
no boot auto-copy-sw
switch 1 provision ws-c3750g-12s
ip subnet-zero
!
no ip igmp snooping
!
!
!
no file verify auto
!
spanning-tree mode rapid-pvst
!
!
interface GigabitEthernet1/0/1
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
ip classless
no ip http server
!
no cdp run
!
control-plane
!
!
line con 0
line vty 0 4
no login
line vty 5 15
no login
!
!
end
Switch#
xxxxx config.text
xxxxx c3750-ipbase-mz.122-25.SEB2
Switch#
Verify that the filenames displayed match the above filenames. Note that as additional configuration occurs, file size changes. The
information above is for a new switch from the Emerson factory. If the file names do not match, refer to Configuring the 3750G-12S Switch
to Emerson Defaults to configure the switch to the minimum defaults for use with the DeltaV system.

Configuring the Cisco 3750G-12S Switch to Emerson Defaults
Switch(config)#
Switch(config-if)
Switch(config)#
Switch(config)#
5. Type no aaa new-model at the prompt and press Return. The system displays:
Switch(config)#
6. Type no boot auto-copy-sw at the prompt and press Return. The system displays:
Switch(config)#
7. Type no file verify auto at the prompt and press Return. The system displays:
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
11. Type interface range gigabitethernet1/0/1 - 12 at the prompt and press Return. The system displays:
Switch#
Switch#
[OK]
Switch#
18. Verify that the configuration for the Cisco switches matches the Emerson factory defaults (except for IP address and any “shutdown”
information you may have entered) by typing show config at the prompt and pressing Return repeatedly to step through the file.Verify
that the following items are in the configuration file:
1) no aaa new-model (near the beginning of the file)
2) no boot auto-copy-sw (near the beginning of the file)
4) no file verify auto (near the beginning of the file)
6) interface gigabitethernet1/0/1 through 1/0/12
no cdp enable
7)shutdown (near the end of the file)
8)no ip http server (near the end of the file)
9)no cdp run (near the end of the file)

Displaying Port Statistics on the Cisco 3750G-12S Switch
The serial console port can also be used for troubleshooting network problems. To view network statistics over this serial Console port for
Ethernet Port 1 for example, type show interface gigabitethernet1/ 0/1 at the prompt and press Return repeatedly. The system displays these
lines: (Information varies depending on switch address, port connections, and network load.)
GigabitEthernet1/0/1 is down, line protocol is down (notconnect)
Hardware is Gigabit Ethernet, address is 0014.a81b.6e81 (bia 0014.a81b.6e81)
Keepalive not set
Auto-duplex, Auto-speed, link type is auto, media type is Not Present
Queuing strategy: fifo
Switch#
displays:
statistics.
Switch#
Switch#
5. The serial console port can also be used to view Ethernet controller statistics. To view statistics for Ethernet Port 1 for example, type the
following at the prompt: show controller ethernet-controller gigabitethernet1/ 0/1 and press Return repeatedly. The system displays
the following lines: (Information varies depending on port connections, and network load.)
Transmit GigabitEthernet1/0/1 Receive
0 Bytes 0 Bytes
0 127 byte frames
0 Too large frames
Switch#
6. To view controller statistics for all ports on the switch, type show controller ethernet- controller at the prompt and press Return
repeatedly. All ports are displayed. (Information varies depending on switch address, port connections, and network load.) To clear or
“zero” the ethernet controller counters to get fresh data, type clear controller ethernet-controller at the prompt and press Return. The
system displays:
Switch#
statistics.

Enabling the Cisco 3750G-12S Switch for Telnet and Web Management
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
xxxxx %LINK-3-UPDOWN: Interface Vlan1, changed state to up
xxxxx %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
Switch(config-if)#
Switch(config-if)#
Switch#
xxxxx %SYS-5-CONFIG_I: Configured from the console by console
Switch#
[OK]
Switch#
when viewing Emerson factory defaults in Verifying Emerson Factory Defaults on the Cisco 3750G-12 Switch.
When all IP address information is verified, use the management PC station’s web browser to enter the switch’s IP address for managing the
switch. See the Cisco documentation for use of the Cisco web management interface.

Using the Web Console to Set Up a Telnet Password to Manage the Cisco 3750G-12S Switch
Before telnet can be used however, complete all of the steps in Enabling the Cisco 3750G-12S Switch for Telnet and Web Management.
When those steps are complete, attach a fiber optic cable between one of the switch’s gigabit interface ports with the appropriate twisted pair
gigabit transceiver to connect to the twisted pair port of the management PC. Then enter the IP address of the new switch in the Internet
Explorer address box of the switch management station and the Cisco switch display will appear. This display is the embedded Cisco switch
management software called Device Manager. Complete these steps to enable Telnet access to the switch:
1. From the Device Manager display, in the Contents section, select Tools | Telnet, then select the Express Setup link. In the Network
Settings section, enter a switch password and then confirm the switch password.
2. In the Optional Settings section, enter a Telnet password and then confirm the telnet password.
3. Select the Enable button.
4. At the bottom of the switch page, select Submit to save the configuration.
Alternately, if the serial connection is still attached to the switch once the passwords are entered from the web browser, enter the write mem
command from the config t switch prompt and the new password information will be saved in permanent memory. You can view the new
passwords and access levels by entering the show config command at the switch prompt either from the serial console port or from telnet.

Enabling Cisco Discovery Protocol on the Cisco 3750G-12S Switch
Before enabling Cisco Discovery Protocol (CDP), refer to About Cisco Cluster Management.
command switch to ”find” the other switches on the network automatically and draw a network map:
Note If you do not have access to download Cisco’s Network Assistant software from the Cisco website or have no plans to use cluster
management, there is no need to configure CDP on the switches. However if you still want to use web management for the switches, you
must assign individual IP addresses from the approved IP address list to each switch individually and then use the switch’s built-in Device
Manager software and web browser on the management station PC to manage the switches.
Perform these steps to configure CDP on the switches for use with the Cisco Network Assistant software (downloaded from the Cisco
website):
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
5. If port 12 is used as a connection to another switch, type interface gigabitethernet 1/0/12 at the prompt and press Return. The system
displays:
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
10. Type show config at the prompt and press Return repeatedly and verify that "no cdp enable" has been removed from the port 12
configuration (compare port 12 to other ports to ensure that "no cdp enable" is removed from this port). Press Return repeatedly to
verify that near the end of the file, "no cdp run" has been removed. Refer to Verifying Emerson Factory Defaults on the 3750G-12S
Switch to compare to the Emerson factory default configuration.
switches in this network and for each port that has a switch-to-switch port connection. When configuration is complete, use the web
browser on the network management station to start the Cisco Network Assistant application (available as a download from the Cisco
website). This will start the automatic discovery of all switches on the network; then they can be assigned to a cluster number and name
for management. Consult the Cisco documentation and information from the Cisco Network Assistant application for additional
information. If you do not have access to the Cisco Network Assistant application software, you can assign individual IP addresses
(from the approved IP address list) and manage the switches individually using the switch’s built-in Device Manager software.

Rebooting the Cisco 3750G-12S Switch
It is not often necessary to reboot a switch. Be sure that you reboot the switch at an appropriate time because rebooting the switch causes loss
of communications to attached devices and loss of configuration changes if the changes have not been saved using the write mem command.
If you intend to reboot the switch, be sure that you have saved your configuration changes and that you can safely reboot without impacting
plant operations. To reboot the switch, type reload at the prompt. In about 1.5 – 2.0 minutes the switch will complete its boot process. Press
Return after the switch has stopped booting and wait until the Switch> prompt displays. The switch is now ready for normal operation.

Restoring the Cisco 3750G-12S Switch to Cisco Factory Defaults
1. Type ena at the Switch> prompt and press Return.
2. Type write erase at the Switch# prompt and press Return. The system displays:
[OK]
Switch#
%SYS-CLUSTER_MEMBER_1-7_NV_BLOCK_INIT:Initialized the geometry of nvram
4. Press Return.
5. Type reload at the Switch# prompt and press Return. The system displays:
Xxxxx %SYS-5-RELOAD: Reload Requested by console. Reload reason: Reload command.
6. After about 1.5-2.0 minutes, the following line is displayed:
7. Do not press return right away. Wait a few more seconds until this final line is displayed:
xx:xx:xx %LINEPROTO-5-UPDOWN:Line protocol on Interface xxxxx changed state to up
8. Press Return, the system displays:
Would you like to terminate autoinstall? [yes]:
9. Type y and press Return. The system displays:
Would you like to enter the initial configuration dialog? [yes/no]:
10. Type n and press Return. The systems displays:
Switch>
11. Type ena at the Switch> prompt and press Return. The system displays:
Switch#
12. Type sho config at the Switch# prompt and press Return. The system displays:
13. Type sho flash at the Switch# prompt and press Return. The system displays:
c3750-ipbase-mz.122-25.SEB2 without config.text or private config.text files present
14. Return to the Configuring the 3750G-12S Switch to Emerson Defaults section for correct switch configuration.
Configuring the Cisco 3750-24FS Switch
Inside this topic
This topic explains how to verify that the correct Emerson defaults have been configured on the Cisco 3750-24FS switch and explains how to

Verifying Emerson Factory Defaults on the Cisco 3750-24FS Switch
After about 1.5-2.0 minutes, the following line is displayed:
Switch>
Switch#
!
version 12.2
no service pad
!
hostname Switch
!
!
no aaa new-model
switch 1 provision ws-c3750-24fs
ip subnet-zero
!
no ip igmp snooping
!
!
!
no file verify auto
!
!
!
interface FastEthernet1/0/1
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
duplex full
no cdp enable
!
no cdp enable
!
no cdp enable
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
ip classless
no ip http server
!
no cdp run
!
control-plane
!
!
line con 0
line vty 0 4
no login
line vty 5 15
no login
!
!
end
Switch#
xxxxx config.text
Switch#
information above is for a new switch from the Emerson factory. If the file names do not match, refer to Configuring the 3750-24FS

Configuring the Cisco 3750-24FS Switch to Emerson Defaults
following line is displayed:
Switch(config)#
Switch(config-if)
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
11. Type interface range fastethernet1/0/1 - 24 at the prompt and press Return. The system displays:
15. Type interface range gigabitethernet1/0/1 – 2 at the prompt and press Return. The system displays:
Switch#
Switch#
[OK]
Switch#
information you may have entered) by typing show config at the prompt and pressing Return repeatedly to step through the file. Verify
that the following items are in the configuration file:
6) interface fastethernet1/0/1 through 1/0/24 and gigabit ethernet1/0/1 through 1/0/2
no cdp enable
7) interface fastethernet1/0/1 through 1/0/24
duplex full
8) shutdown (near the end of the file)
9) no ip http server (near the end of the file)
10) no cdp run (near the end of the file)

Displaying Port Statistics on the Cisco 3750-24FS Switch
The serial console port can also be used for troubleshooting network problems. To view network statistics over the serial Console port for
Ethernet Port 1 for example, type show interface fastethernet1/ 0/1 at the prompt and press Return repeatedly. The system displays these
FastEthernet1/0/1 is down, line protocol is down (notconnect)
Hardware is Fast Ethernet, address is 0014.69a7.2403 (bia 0014.69a7.2403)

Switch#
displays:
statistics.
Switch#
Switch#
5. The serial console port can also be used to view Ethernet controller statistics. To view statistics for Ethernet Port 1 for example, type the
following at the prompt: show controller ethernet-controller fastethernet1/ 0/1 and press Return repeatedly. The system displays the
Transmit FastEthernet1/0/1 Receive
0 Bytes 0 Bytes
0 127 byte frames
0 Too large frames
Switch#
Switch#
statistics.

Enabling the Cisco 3750-24FS Switch for Telnet and Web Management
Switch(config)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
when viewing Emerson factory defaults in Verifying Emerson Factory Defaults on the Cisco 3750-24FS Switch.
When all IP address information is verified, use the management station’s web browser to enter the switch’s IP address for managing the
switch. See the Cisco documentation for information on using the Cisco web management interface.

Using the Web Console to Set Up a Telnet Password to Manage the Cisco 3750-24FS Switch
However, before telnet can be used, complete all of the steps in Enabling the Cisco 3750-24FS-S Switch for Telnet and Web Management.
When these steps are complete, attach a fiber optic cable between one of the switch’s MTRJ fiber optic Ethernet ports and a media converter
to connect to the twisted pair port of the management PC, or use the switch's gigabit interface port with the appropriate twisted pair gigabit
transceiver to connect to the twisted pair port of the management PC. Then enter the IP address of the new switch in the Internet Explorer
address box of the switch management station; the Cisco switch display will appear. This display is Cisco's embedded switch management
software called Device Manager.
Complete these steps to enable Telnet access to the switch:
1. From the Contents section of the Device Manager display, select Tools | Telnet, then select the Express Setup link. In the Network
Settings section, enter a switch password and then confirm the switch password.
2. In the Optional Settings section, enter a telnet password and then confirm the telnet password.

Enabling Cisco Discovery Protocol on the Cisco 3750-24FS
command switch to ”find” the other switches on the network automatically and draw a network map.
Note If you do not have access to download Cisco’s Network Assistant software from the Cisco web site or have no plans to use cluster
management, there is no need to configure CDP on the switches. If this is the case but you still want to use web management for the switches,
you will only need to assign IP addresses from the approved IP address list to each switch individually and then use the switch’s built-in
Device Manager software and web browser on the management station PC to manage the switches.
To configure CDP on the switches for use with the Cisco Network Assistant software (must be downloaded from the Cisco website), perform
the following steps:
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
5. If port 24 is used as a connection to another switch, type interface fastethernet 1/0/24 at the prompt and press Return. The system
displays:
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
10. Type show config at the prompt and press Return repeatedly. Verify that "no cdp enable" has been removed from the port 24
configuration (compare port 24 to other ports to see that "no cdp enable" is removed from this port). Press Return repeatedly to verify
that near the end of the file, "no cdp run" has been removed. Refer to Verifying Emerson Factory Defaults on the 3750-24FS Switch to
compare to the Emerson factory default configuration.
switches in this network and for each port that has a switch-to-switch port connection. When configuration is complete, use the web
browser on the network management station to start the Cisco Network Assistant application (available as a download from the Cisco
website). This will start the automatic discovery of all switches on the network. Then they can be assigned to a cluster number and
name for management. Consult Cisco documentation and information within the Cisco Network Assistant application for additional
information. If you do not have access to the Cisco Network Assistant application software, you can assign individual IP addresses
(from the approved IP address list) and manage the switches individually using the switch’s built-in Device Manager software.

Rebooting the Cisco 3750-24FS Switch
It is not often necessary to reboot a switch. Be sure that you reboot the switch at an appropriate time because rebooting the switch causes loss
of communications to attached devices and loss of configuration changes if the changes have not been saved using the write mem command.
Be sure that if you intend to reboot the switch, you have saved your configuration changes and that you can safely reboot without impacting
plant operations. To reboot the switch, type reload at the prompt, and in about 1.5 – 2.0 minutes the switch will complete its boot process.
Press Return after the switch has stopped booting and wait until the Switch> prompt displays. The switch is now ready for normal operation.

Restoring the Cisco 3750-24FS Switch to Cisco Factory Defaults
[OK]
Switch#
4. Press Return.
Xxxxx %SYS-5-RELOAD: Reload Requested by console. Reload reason: Reload command.
Switch>
Switch#
14. Return to the Configuring the 3750-24FS Switch to Emerson Defaults section for correct switch configuration.
Configuring the Cisco 3750-24TS Switch
Inside this topic
This topic explains how to verify that the correct Emerson defaults have been configured on the Cisco 3750-24TS switch and explains how to

Verifying Emerson Factory Defaults on the Cisco 3750-24TS Switch
xx:xx:xx %LINEPROTO-5-UPDOWN:Line protocol on Interface Vlan1;
changed state to up
Switch>
Switch#
!
version 12.2
no service pad
!
hostname Switch
!
!
no aaa new-model
switch 1 provision ws-c3750-24ts
ip subnet-zero
!
no ip igmp snooping
!
!
!
no file verify auto
!
!
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
no cdp enable
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
ip classless
no ip http server
!
no cdp run
!
control-plane
!
!
line con 0
line vty 0 4
no login
line vty 5 15
no login
!
!
end
Switch#
xxxxx config.text
Switch#
information above is for a new switch from the Emerson factory. If the file names do not match, refer to Configuring the 3750-24TS

Configuring the Cisco 3750-24TS Switch to Emerson Defaults
Switch(config)#
Switch(config-if)
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
Switch(config)#
11. Type interface range fastethernet1/0/1 - 24 at the prompt and press Return. The system displays:
15. Type interface range gigabitethernet1/0/1 – 2 at the prompt and press Return. The system displays:
Switch#
Switch#
[OK]
Switch#
information you may have entered) by typing show config at the prompt and pressing Return repeatedly to step through the file.
23. Verify that the following items are in the configuration file:

6) interface fastethernet1/0/1 through 1/0/24 and gigabit
ethernet1/0/1 through 1/0/2
no cdp enable
7) shutdown (near the end of the file)
8) no ip http server (near the end of the file)
9) no cdp run (near the end of the file)

Displaying Port Statistics on the Cisco 3750-24TS Switch
The serial console port can also be used for troubleshooting network problems. To view network statistics over this serial Console port for
Ethernet Port 1 for example, type show interface fastethernet1/ 0/1 at the prompt and press Return repeatedly. The system displays these
FastEthernet1/0/1 is down, line protocol is down (notconnect)
Hardware is Fast Ethernet, address is 0014.69a7.2403 (bia 0014.69a7.2403)
Switch#
To view network statistics for all ports on the switch, type show interface at the prompt and press Return repeatedly to display all ports. The
information varies depending on switch address, port connections, and network load.
displays:
statistics.
Switch#
Switch#
The serial console port can also be used to view Ethernet controller statistics. To view statistics for Ethernet Port 1 for example, type the
following at the prompt: show controller ethernet-controller fastethernet1/ 0/1 and press Return repeatedly.
The system displays the following lines: (Information varies depending on port connections, and network load.)
Transmit FastEthernet1/0/1 Receive
0 Bytes 0 Bytes
0 127 byte frames
0 Too large frames
Switch#
Switch#
statistics.

Enabling the Cisco 3750-24TS Switch for Telnet and Web Management
Switch(config)#
Switch(config-if)#
3. Enter an approved IP address followed by the subnet mask by typing: ip address 10.4.128.18 255.254.0.0 and press Return at the
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
when viewing Emerson factory defaults in Verifying Emerson Factory Defaults on the Cisco 3750-24TS Switch.
When all IP address information is verified, use the management PC station’s web browser to enter the switch’s IP address for managing the
switch. Refer to the Cisco documentation for information on using the Cisco web management interface.

Using the Web Console to Set Up a Telnet Password to Manage the Cisco 3750-24TS Switch
Before telnet can be used however, complete all of the steps in Enabling the Cisco 3750-24TS Switch for Telnet and Web Management. When
those steps are complete, attach a shielded, twisted pair cable to one of the switch’s Ethernet ports. Then enter the IP address of the new
switch in the Internet Explorer address box of the switch management station. The Cisco switch display will appear. This display is the
embedded Cisco switch management software called Device Manager. Complete these steps to enable Telnet access to the switch:
1. From the Device Manager display, in the Contents section, select Tools | Telnet, and select the Express Setup link. In the Network
Settings section, enter a switch password and confirm the switch password.
2. In the Optional Settings section, enter a Telnet password and confirm the telnet password.

Enabling Cisco Discovery Protocol on the Cisco 3750-24TS Switch
The following procedure shows how to configure a switch for the (CDP) using the serial console port or telnet interface. This allows the
cluster command switch to ”find” the other switches on the network automatically and draw a network map.
Note If you do not have access to download Cisco’s Network Assistant software from the Cisco website or have no plans to use cluster
management, there is no need to configure CDP on the switches. If this is the case but you still want to use web management for the switches,
you will only need to assign individual IP addresses from the approved IP address list to each switch individually and then use the switch’s
built in Device Manager software and web browser on the management station PC to manage the switches.
To configure CDP on the switches for use with the Cisco Network Assistant software that has to be downloaded from the Cisco web, do the
following steps:
Switch#
Switch(config)#
Switch(config-if)#
Switch(config)#
5. If port 24 is used as a connection to another switch, type interface fastethernet 0/24 at the prompt and press Return. The system
displays:
Switch(config-if)#
Switch(config-if)#
Switch#
Switch#
[OK]
Switch#
10. Type show config at the prompt and press Return repeatedly and verify that "no cdp enable" has been removed from the port 24
configuration (compare port 24 to other ports to see that "no cdp enable" is removed from this port). Press Return repeatedly to verify
that near the end of the file, "no cdp run" has been removed. Refer to Verifying Emerson Factory Defaults on the 3750-24TS Switch to
compare to the Emerson factory default configuration. Cisco Discover Protocol (CDP) has now been successfully configured and saved
to permanent memory. Repeat this process for all other switches in this network and for each port that has a switch-to-switch port
connection. When configuration is complete, use the web browser on the network management station to start the Cisco Network
Assistant application (available as a download from the Cisco web). This will start the automatic discovery of all switches on the
network and then they can be assigned to a cluster number and name for management. Consult Cisco documentation and information
within the Cisco Network Assistant application for additional information. If you do not have access to the Cisco Network Assistant
application software, you can assign individual IP addresses (from the approved IP address list) and manage the switches individually
using the switch’s built-in Device Manager software.

Rebooting the Cisco 3750-24TS Switch
impacting plant operations. To reboot the switch, type reload at the prompt and press Return. In about 1.5 – 2.0 minutes the switch will
complete its boot process. Press Return after the switch has stopped booting and wait until the Switch> prompt displays. The switch is now

Restoring the Cisco 3750-24TS Switch to Cisco Factory Defaults
[OK]
Switch#
4. Press Return.
Xxxxx %SYS-5-RELOAD: Reload Requested by console. Reload reason:
Reload command.
Switch>
Switch#
14. Return to the Configuring the 3750-24TS Switch to Emerson Defaults section for correct switch configuration.
Securing DeltaV Smart Switches
This topic explains how to use the DeltaV One-Click Lockdown application with DeltaV Smart Switches.
The DeltaV Smart Switches consist of the DeltaV MD base Smart Switches and media modules, the DeltaV RM100 base Smart Switches and
media modules, and the DeltaV FP20 8-port Smart Switches. Refer to the Installing Your DeltaV Digital Automation System manual for
hardware specifications and for the designated range of IP addresses for DeltaV Smart Switches. The DeltaV Smart Switches contain no
management network access (IP address) and function as unmanaged switches in a DeltaV network. However, the DeltaV Smart Switches
have built-in security features that enable end users to use the One-Click Lockdown application to lock the switches to prevent unauthorized
devices from being connected to unused ports including uplink ports. In order to use the One-Click Lockdown application, the switches must
be configured. Refer to Configuring DeltaV Smart Switches for information on how to configure the switches to use the One-Click Lockdown
application.
The One-Click Lockdown application finds all the DeltaV Smart Switches on the network and either locks or unlocks all ports on all switches
on either the primary or secondary network or on both networks. The utility finds, locks, and unlocks DeltaV Smart Switches only. Third
party switches, which can be used on the same network as DeltaV Smart Switches, are not eligible for locking and unlocking.
It is expected that users will connect the desired devices to the DeltaV Smart Switches, verify the connections, and then lock down the ports to
prevent unauthorized devices from being connected to a switch. When a switch is locked, all unused ports on the switch are disabled and
communication with these ports is prevented. If a device that was connected at the time the switch was locked is disconnected and a different
device is connected to the port, the switch refuses the connection. If the original device is reconnected to the same port, the switch
reestablishes connections with the device. Power cycling a switch does not enable unwanted connections. When a switch is power cycled, it
comes back up in the last locked or unlocked state.
Best Practices
As a best practice, unlock switches before connecting or disconnecting devices, cables, and troubleshooting switches. A locked switch may
need to be reset before a disconnected device or cable can be reattached.
Note You must have the Can Configure or Can Download or Can Calibrate keys to lock and unlock switches. Refer to DeltaV User Manager
and DeltaV Security for information on keys.
Running and Opening the One-Click Lockdown Application
Run the One-Click Lockdown application from one computer only, preferably the ProfessionalPLUS station and never open multiple
instances of the application on different computers at the same time.
To run the One-Click Lockdown application:
 Double-click DVOneClickLockdown.exe from DeltaV\bin.
 Once the executable is run, launch the application by clicking on the DeltaV Explorer toolbar or by clicking Applications | One
Click Lockdown.
Note It is recommended that you delete DVOneClickLockdown.exe from DeltaV\bin on all workstations other than the workstation that is
used for locking and unlocking DeltaV Smart Switches.
Updating the Switch List
Before using the One-Click Lockdown application, click the Update Switch Lists button to locate all the DeltaV Smart Switches on the
primary and secondary networks and populate the list with the switch names and IP addresses. The command buttons are enabled once the
switch lists are populated.
Lockdown Timer
The lockdown timer is a safety mechanism that when enabled, automatically locks all unlocked switches after 60 minutes. Suppose that you
unlock your switches for routine maintenance or to add devices and then get called away for several hours. When the lockdown timer is
enabled, the switches are automatically locked after an hour. This way, they are not vulnerable to a security breach if left in an unlocked state
for an extended period of time. This option should be enabled before unlocking the switches. When the timer is set, the Time Remaining
column shows the time, in seconds, before the switches are locked.
Note When switches are unlocked with the timer running (Lock Pending), it is possible to disable the lockdown timer without first locking the
switches. To disable the lockdown timer in this situation, uncheck the Enable Lockdown Timer option and then click Unlock All. The switch
status will change to Unlock. But when switches are unlocked without a timer, (Unlocked) sending an unlock request with a timer does not
enable the timer. To enable the lockdown timer in this situation, lock the switches and then click Unlock All.
Status
In addition to showing the IP addresses and names of DeltaV Smart Switches, the application also shows the following switch statuses:
 Locked
 Unlocked
 Lock Pending – the switches are unlocked and the lockdown timer is enabled
 Unknown – the switch is neither locked, unlocked, or in the lock pending state
 <lost communication> - the switch has lost communication with the DeltaV system. This status is shown any time communication with
the switch is lost regardless of whether the switch is in a locked or unlocked state with or without a timer.
Process History View Events
An event is created in the Event Chronicle for every lock or unlock command issued. The event shows the area associated with alarms and
events for the workstation and the user name. To view events click Start | DeltaV | Operator | Process History View to open the application
and then select Event from the New dialog.
Configuring DeltaV Smart Switches
DeltaV Smart Switches are intended for plug and play use with a DeltaV system and require no additional configuration to properly perform
their switching functions in a DeltaV network. They contain no management network access (IP address) and function as unmanaged switches
in a DeltaV network. However, if you want to use the DeltaV One-Click Lockdown application to prevent unauthorized devices from being
connected to unused ports on the switches or if you want to access a switch to monitor the network, it must be configured using the DeltaV
Setup Wizard. This topic explains how to configure the switches using the DeltaV Setup Wizard.
At a minimum, the DeltaV MD20, MD30, FP20, and RM100 Smart Switches must be set up with an IP address in order for the One-Click
Lockdown application to locate the switches on the network and lock them down. It is also possible to set up the switch with more advanced
features. The procedure for basic switch setup (name and IP address) is documented in steps 1-14. More information on the advanced setup
option is available after step 14.
Refer to DeltaV Smart Switches and Media Modules for information on the Smart Switches and to Securing DeltaV Smart Switches for
information on the One-Click Lockdown application.
1. Connect power to the DeltaV Smart Switch and wait for the Run light on the switch's front panel to stop flashing and turn green.
2. Connect the management's station Comm port to the switch's serial port with a serial interface cable purchased from Emerson Process
Management or refer to DeltaV Smart Switches and Media Modules for information on building your own serial interface cable
assembly.
3. Start a terminal session such as a HyperTerminal session on the Management station and set the properties to 9600 baud, 8 data bits, no
parity, 1 stop bit, no flow control, and save.
4. Press Return. A login prompt, Username and Password, appears.
5. Type admin at the User prompt and press Return. The Password prompt appears.
6. Type Emerson1 at the Password prompt and press Return. The Emerson prompt, which is Emerson MD for an MD switch,
Emerson FP for an FP switch, and Emerson RM for an RM switch appears.
At this point, it is highly recommended that you clear the switch setup to ensure that the switch operates with the default DeltaV setup. This
ensures that the switch operates properly with the One-Click Lockdown application. You will have to reenter User and Password after
clearing the setup. The option to clear the setup is available only from a HyperTerminal session. It is not available from a Telnet session.
7. Type deltav default at the Emerson prompt and press Return. The setup application prompts you to confirm that the switch's
current setup will be cleared.
8. Type y to clear the setup. The User prompt appears.
9. Type admin at the User prompt and press Return. The Password prompt appears.
10. Type Emerson1 at the Password prompt and press Return. The Emerson prompt: Emerson MD for an MD switch, Emerson FP
for an FP switch, and Emerson RM for an RM switch appears.
11. Type deltav at the Emerson prompt and press Return.
Once you begin the next step, entering an IP address, you must finish the initial setup questions to exit the application. Pressing Return
at a question does not change the existing value. The exception is the IP address. If the IP address is 0.0.0.0, you must enter a valid IP
address to continue. Once the switch setup has a valid IP address, you must perform the advanced setup to return the switch address to
0.0.0.0.
12. Type an IP address for the switch and press Return.
Be sure that the switch has an unique IP address. Refer to Reserved DeltaV IP Addresses for a list of IP addresses that have been
reserved for switches on the DeltaV control network. The IP address appears in the One-Click Lockdown application when it finds and
lists the DeltaV Smart Switches on the network.
13. Type a name for the switch and press Return. This item is optional. The switch name appears in the One-Click Lockdown application
when it finds and lists the DeltaV Smart Switches on the network.
14. Type a description of the switch's physical location and press Return. This item is optional.
At this point, you are prompted to configure optional advanced items for the switch. These optional items are:
 Change the default admin and user password
 Configure the network IP address of the SNMP trap destination node, the SysLog server node, the time server, and the backup time
server
 Disable remote access
 Disable Telnet access
 Disable HTTP access
15. Type y or n to configure the advanced options.
If you select n or press Return, the initial setup is saved to the switch memory and the setup application closes. The switch is enabled
for One-Click Lockdown after the initial setup is saved. Further setup can be performed remotely using a Telnet interface. If you choose
to enter advanced configuration, be sure to read the message that appears on the screen.

After all the advanced questions have been answered, you must answer yes (y) to save the configuration. If you answer no (n) or press
Return, the setup, including the initial setup is not saved.
16. To view the IP address, switch name and location, type show sysinfo. The setup is not saved if the configuration state is not in
sync. To save the configuration, type deltav and press Return at the initial four setup questions.
This completes the switch set up.
17. Disconnect the serial cable.
After an IP address has been set up, a web browser can be used to view items such as port statistics. The web browser application is view-
only. No switch configuration is allowed through the web browser. Connect the switch to the management station with an Ethernet cable to
use the web browser. When the web browser opens, type the switch's address in the Address field, and use the following username and
password to view the switch's information:
 username: user
 password: Emerson1
Monitoring DeltaV Smart Switches with the Built-in Browser
After a DeltaV Smart Switch is configured with an IP address and the Java software has been installed on the Management station, you can
use the switch's built-in browser to monitor the switch. You cannot make changes to the switch configuration from the web browser. Changes
to switch configuration can be made only through the DeltaV Setup Wizard. Refer to Configuring DeltaV Smart Switches for information on
using the DeltaV Setup Wizard to configure an IP address and to Downloading Java Software for use on an Management Station.
1. Enter the switch's IP address in the browser’s address line.
2. Click Cancel if a warning dialog appears.
3. Be sure that User is the Login name, enter Emerson1 for the password, and click OK.
4. You can now expand the various items in the left hand column of the display to view information about the switch.
Accessing DeltaV Smart Switches with Telnet
After a DeltaV Smart Switch is configured with an IP address, you can access the switch through a Telnet session to get useful diagnostic
information for troubleshooting network problems. Refer to Configuring DeltaV Smart Switches for information on configuring a switch's IP
address.
1. From a command prompt on the Management station, enter telnet and press Return. The Microsoft Telnet> prompt is displayed:
Microsoft Telnet>
2. Enter open switch IP address and press Return. The User:_ prompt is displayed:
User:_
3. Enter admin at the User_prompt and Emerson1 at the Password prompt. The Emerson [switch type] prompt appears.
Emerson [switch type]
4. Enter deltav to open the DeltaV Setup Wizard.
You can change the switch setup through a Telnet session. Changing the IP address will require you to restart the Telnet session using the new
address once you save the settings.
Following are examples of Telnet switch commands that can be used to troubleshoot network problems.
 show running-config
 show sysinfo
 show temperature
 show port-locking
 show port-locking all
 show port all
 show interface ethernet x/x (x/x is module/port on switches that are modular)
If you plan to use Telnet for ongoing switch access, it is recommended that you change the default “admin” password to prevent unauthorized
access or to disable Telnet access using the advanced setup parameters in the DeltaV Setup Wizard.
Safety Instructions for DeltaV Network Switches and Media
Modules
Inside this topic
This topic contains safety instructions for the following DeltaV network switches and media modules:
FP20 Network Switches
 FP20-6TX2TX and FP20-6TX2TX-ES
 FP20-6TX1MM1TX and FP20-6TX1MM1TX-ES
 FP20-6TX1SM1TX and FP20-6TX1SM1TX-ES
 FP20-6TX1SMLH1TX and FP20-6TX1SMLH1TX-ES
 FP20-6TX2MM and FP20-6TX2MM-ES
 FP20-6TX2SM and FP20-6TX2SM-ES
 FP20-6TX2SMLH and FP20-6TX2SMLH-ES
RM100 Network Switches
 RM100- Base Module
 RM100- Base Module-RP
 RM100-8TX
 RM100-24TX
RM100 Media Modules
 RM100- EM-8TX
 RM100- EM8MM-FX
 RM100-EM-8SM-FX
 RM100-EM-8SFP
MD20 and MD30 Network Switches
 MD20-8 and MD20-8-ES
 MD20-16 and MD20-16-ES
 MD20-24 and MD20-24-ES
 MD30-8 and MD30-8-ES
 MD30-16 and MD30-16-ES
 MD30-24 and MD30-24-ES
MD20 and MD30 Media modules
 MD4-2TX/SFP and MD4-2TX/SFP-ES
 MD2-2FXM2 and MD2-2FXM2-ES
 MD2-2FXS2 and MD2-2FXS2-ES
 MD2-4TX1 and MD2-4TX1-ES
 MD3-2FXM2/2TX1 and MD3-2FXM2/2TX1
 MD3-2FXS2/2TX1 and MD3-2FXS2/2TX1-ES
 MD3-4FXS2 and MD3-4FXS2-ES
 MD3-2FXM4/2TX1 and MD3-2FXM4/2TX1-ES
 MD3-1FXS2/3TX1 and MD3-1FXS2/3TX1-ES
 MD2-4TX1-POE and MD2-4TX1-POE-ES
These instructions must be observed to ensure your own personal safety and to avoid damage to devices and machinery.
Note When a safety instruction is specific to an item such as a particular DeltaV network switch or DeltaV media modules, that item is
specified in parenthesis in the heading. For example, the heading "Supply Voltage (Media Modules)" indicates that the safety instructions
following the heading apply to media modules only. When a heading applies to all items, the heading will contain no parenthesis. For
example, the heading "Qualification Requirements for Personnel" refers to all DeltaV network switches and media modules.

Certified Usage
Please observe the following: The device may only be employed for the described purposes and only in conjunction with external devices and
components recommended or approved by Emerson Process Management. The product can only be operated correctly and safely if it is
transported, stored, installed and assembled properly and correctly. Furthermore, it must be operated and serviced carefully.

Supply Voltage (DeltaV MD20/MD20-ES, MD30/MD30-ES and FP20/FP20-ES Switches)
The devices are designed for operation with a safety extra-low voltage. Thus, they may only be connected to the supply voltage connections
and to the signal contact with SELV circuits with the voltage restrictions in accordance with IEC/EN 60950-1. The supply voltage is
electrically isolated from the housing.
 Use only undamaged parts
 Relevant for North America: The subject unit is to be supplied by a Class 2 power source complying with the requirements of the
National Electrical Code, table 11(b). If power is redundant supplied (two individual power sources) the power sources together should
comply with the requirements of the National Electrical Code, table 11 (b).
 Relevant for North America: Use 60/75°C or 75°C copper (CU) wire only.
 Relevant for North America for devices certified for hazardous locations: Peripheral equipment must be suitable for the location it
is used in. Power, input and output (I/O) wiring must be in accordance with Class I, Division 2 wiring methods [Article 501-4(b) of the
National Electrical Code, NFPA 70] and in accordance with the authority having jurisdiction.
 For devices installed in explosive gas atmospheres according to ATEX 100a (only for devices labeled accordingly): Relevant for
Europe (ATEX 100a): 8 II 3G EEx nA IIC T4 - refer to the device label. Must be mounted in a suitable certified IP 54 housing – tested
to 4 J impact due to low risk of mechanical danger. For ambient temperatures below -10°C and above +60°C use wiring suitable for
both the minimum and maximum temperatures.

Supply Voltage (DeltaV MD20/MD30 Media Modules)
To be supplied by a NEC Class 2 power supply via the switch basic modules (MD20s and MD30s). For Power over Ethernet Modules:
Connect a NEC Class 2 power supply only. Use 60/75°C or 75°C copper (CU) wire only.
Supply Voltage (DeltaV RM100 Switches)
The supply voltage is electrically isolated from the housing.
 Use only undamaged parts.
 The device does not contain any service components. Internal fuses are only triggered if there is a fault in the device. If the device is not
functioning correctly, or if it is damaged, switch off the voltage supply and return the device to the plant for inspection.
 Only switch on the device when the housing is closed.
 Only use connection cables that are permitted for the specified temperature range.
 Relevant for North America:
 Only use copper wire/conductors of class 1, 60/75°C or 75°C.
 Only connect a supply voltage that corresponds to the type plate of your device.
 Install an input fuse in the ungrounded voltage cables for every voltage supply connection. For the AC input of
the AC/DC power units, use a nominal rating of 3 A, characteristic B.
 Make sure that the disconnecting device is easily accessible so that the RM100 device can be disconnected from the mains voltage. If
you disconnect the device from the mains voltage using either the plug in the socket or an on/off switch, it must be easily accessible.
Note: For devices with redundant voltage supply, both non-heating appliance plugs must be pulled to disconnect the device from the mains
voltage.

Shielding Ground
The shielding ground of the connectable twisted pairs lines is connected to the front panel as a conductor. Beware of possible short circuits
when connecting a cable section with conductive shielding braiding.

Housing
 Only technicians authorized by Emerson Process Management are permitted to open the housing.
 The lower covering panel of the MD20/MD30 and MD20-ES/MD34-ES housing is grounded by the DIN rail and, as an option, by the
separate ground screw.
 The FP20 and FP20-ES is grounded through a separate ground screw located on the left under the front panel.
 The switch basic module forms an inseparable unity. By removing the display and connecting parts, you risk damage to the switch basic
module.
 Make sure that the electrical installation meets local or nationally applicable safety regulations.
 The ventilation slits must not be covered to ensure free air circulation.
 The distance to the ventilation slots of the housing has to be a minimum of 10 cm.
 Never insert pointed objects (thin screwdrivers, wires, etc.) into the inside of the subrack. This especially applies to the area behind the
socket connectors. Failure to observe this point may result in injuries caused by electric shocks.
 The device has to be mounted in an upright position.
 If installed in a living area or office environment, the device must be operated exclusively in switch cabinets with fire protection
characteristics according to EN 60950-1.

Housing (DeltaV RM100 Switches)
 Only technicians authorized by Emerson Process Management are permitted to open the housing.
 The device is grounded via the voltage supply socket.
 Make sure that the electrical installation meets local or nationally applicable safety regulations.
 The ventilation slits must not be covered to ensure free air circulation.
 The distance to the ventilation slots of the housing has to be a minimum of 10 cm.
 Never insert pointed objects (thin screwdrivers, wires, etc.) into the inside of the subrack. Failure to observe this point may result in
injuries caused by electrical shocks.
 Close all empty slots with a covering panel.
 The device must be installed in the horizontal or upright position, either as a table unit in the switch cabinet or on the wall.
 When installing the device, make sure there is at least one free rack space (approx. 5 cm) above the device, because heat is discharged
via the housing of the device.
 If you are operating the device in a 19 inch switch cabinet: install sliding/mounting rails for holding the device.

Environment
 The device may only be operated in the listed maximum surrounding air temperature range at the listed relative air humidity range (non-
condensing). Refer to Appendix A in the manual Installing Your DeltaV Digital Automation System.
 The installation location is to be selected so as to ensure compliance with the climatic limits listed in Appendix A in the manual
Installing Your DeltaV Digital Automation System.
 To be used in Pollution Degree 2.

Qualification Requirements for Personnel
Qualified personnel as understood in this manual and the warning signs, are persons who are familiar with the setup, assembly, startup, and
operation of this product and are appropriately qualified for their job. This includes, for example, those persons who have been:
 trained or directed or authorized to switch on and off, to ground and to label power circuits and devices or systems in accordance with
current safety engineering standards
 trained or directed in the care and use of appropriate safety equipment in accordance with the current standards of safety engineering
 trained in providing first aid

General Safety Instructions
This device is electrically operated. Adhere strictly to the safety requirements relating to voltages applied to the device as described in the
operating instructions.
Failure to observe the information given in the warnings could result in serious injury and/or major damage.
 Only personnel that have received appropriate training should operate this device or work in its immediate vicinity. The personnel must
be fully familiar with all of the warnings and maintenance measures in these operating instructions.
 Correct transport, storage, and assembly as well as careful operation and maintenance are essential in ensuring safe and reliable
operation of this device.
 Only use undamaged parts.
 These products are only to be used in the manner indicated. Particular attention is to be paid to all warnings and items of information
relating to safety.
 Any work that may have to be performed on the electrical installation should be performed by fully qualified technicians only.
 For RM switches: Please note that products recommended as accessories may have characteristics that do not fully correspond to those
of the corresponding product. This may limit their possible usage in the overall system.
LED- or LASER components according to IEC 60825-1 (2001): CLASS 1 LASER PRODUCT. LIGHT EMITTING DIODE -
CLASS 1 LED PRODUCT.

National and International Safety Regulations
Make sure that the electrical installation meets local or nationally applicable safety regulations.

ESD Guidelines (DeltaV RM100 Switches)
The media modules are equipped with electrostatically sensitive components. These can be destroyed, or their life cycles reduced, by the
effects of an electrical field or by a charge equilization if the card is touched. For this reason, the cards are packaged in a conductive ESD
protective bag on delivery. The packaging can be reused.
Make sure you adhere to the following protection measures for electrostatically endangered assemblies:
 Create electrical equipotential bonding between yourself and your environment, e.g. using a wristband, which you clamp to the basic
device (knurled screw of an interface card). When the power supply cable is connected, the basic device is grounded via the power
supply connection.
 Only now do you take the card out of the conductive bag.
 Outside the basic device, only store the cards in a conductive ESD protective bag.
ESD protective field equipment is available for the safe handling of electrostatically endangered assemblies.
You can find more information about electrostatically endangered assemblies in DIN/IEC 47 (Sec) 1330; February 1994 Edition and DIN EN
100 015.

Note on the CE Marking
The devices comply with the regulations contained in the following European directives:
2004/108/EG (FP20/FP20-ES switches)
2006/95/EG, 89/336/EEC (MD20/30 and MD20/30-ES switches)
2004/108/EG, 2006/95EG (RM100 switches)
Directive of the European Parliament and the Council for standardizing the regulations of member states on electromagnetic compatibility. In
accordance with the above-named EU directives, the EU conformity declaration will be at the disposal of the relevant authorities at the
following address:
Emerson Process Management
12301 Research Blvd.
Austin, Texas 78756
The product can be used in living areas (living area, place of business, small business) and in industrial areas.
 Interference immunity: EN 61000-6-2:2005
 Emitted interference: EN 55022:2006 Class A (MD20/MD30, MD20-ES, MD30-ES and RM100 switches)
 Emitted interference:EN55022:1998 + A1:2000 + A2:2003, Class A (FP20/FP20-ES switches)
This is a class A device. This device can cause interference in living areas, and in this case the operator may be required to take
appropriate measures. The assembly guidelines must be strictly adhered to in order to observe the EMC value limits.

FCC Note
Appropriate testing has established that this device fulfills the requirements of a class A digital device in line with part 15 of the FCC
regulations.
These requirements are designed to provide sufficient protection against interference where the device is being used in a business
environment. The device creates and uses high frequencies and can radiate same, and if it is not installed and used in accordance with this
operating manual, it can cause radio transmission interference. The use of this device in a living area can also cause interference, and in this
case the user is obliged to cover the costs of removing the interference.

Recycling Note
After usage, this product must be disposed of properly as electronic waste in accordance with the current disposal regulations of your county /
state / country.
Downloading Java Software for use on a Management Station
DeltaV workstations, including the Management station, should never be connected to the Internet. Java software is required for some
Management station functions. To install Java software onto a Management station, you must first download the Java software from the Java
website to a USB flash drive or other portable media on a computer that is not connected to the DeltaV Control Network and then install Java
onto the Management station from the portable media.
1. Go to the Java website and select Downloads from the title bar.
2. Scroll to the middle of the page and click the "See all Java downloads here" link.
3. Click the link for your operating system and follow the prompts to save the Java software to your USB flash drive or other portable
media.
Note: You can also navigate directly to the Java Downloads for all Operating Systems page on the Java website to find the download for your
operating system.
4. Scan your USB flash drive or other media with your anti-virus software. Be sure that you have the latest anti-virus updates.
5. Connect the USB flash drive to the Management station's USB port and install Java from the USB flash drive or other media to the
Management station. We recommend that you do not install the MSN tool bar.
The DeltaV Smart Switch must be configured with an IP address before the web browser on the Management station installed with Java can
be connected to the switch. Refer to Configuring DeltaV Smart Switches for information on configuring the IP address and other parameters
for the switch.
Problem Solving
These sections provide information to assist you in troubleshooting various issues that you may encounter with a DeltaV system. They include
topics pertaining to controller and I/O, the DeltaV database, network performance, and so on.
Communication
If you have communication problems, run the DeltaV Diagnosticsprogram. Select the ACN and check the communication status. Then, check
each device on the network to see if it is communicating properly.
When communication problems exist, clicking Control Network on the tree view in the Diagnostics program provides a quick overview to
help determine the source of the problem. A communication integrity problem is indicated on a node when it is unable to communicate on the
affected link. As shown in the example diagram below, workstation WRKS1 is running the Diagnostics program and gathering information on
nodes CTRL1, CTRL2, and WRKS2 (in addition to itself —WRKS1). A communication problem exists on the secondary connection between
nodes WRKS1 and CTRL1, as indicated by the overlay on the Secondary communications level of the hierarchy tree. Communications on
the secondary are OK to node CTRL2, and node WRKS2 has no secondary connection.
The Contents View shows all 4 nodes and their current communication status. PRI and SEC indicate primary and secondary links. In this case,
both WRKS1 and CTRL1 show BAD SEC-OCInteg. OCInteg is the Overall Connection Integrity, which is BAD when ANY connection to
this node is BAD. To determine which of these nodes is causing the BAD integrity, look at the SEC-OLInteg parameter. OLInteg is the
Overall Link Integrity, which is BAD when ALL connections to this node are BAD (same information as shown by the overlay on the
hierarchy tree). In this case, WRKS1 shows GOOD SEC-OLInteg (able to communicate with at least one other node—CTRL2 in this case),
and CTRL1 shows BAD SEC-OLInteg (unable to communicate with any other node). From this you can see that the source of the problem is
the secondary connection on node CTRL1.
In summary, the OLInteg Overall Link Integrity parameter being BAD typically indicates the source of the problem.
Note If a node is communicating with only one other node, both OLInteg and OCInteg are bad regardless of whether or not the node is the
source of the problem.
For additional details (typically not required), select the Communications (or Primary or Secondary) level on one of the affected nodes. Then,
click the right mouse button and click Display Comm Connection List. This list shows the current status of communications between this node
and all the nodes with which it is communicating.
In this case, the SecStatus shows BAD on node CTRL1.
Selecting the node of interest (controller CTRL1 in the example above) from the list under Connection To and then clicking the Node Details
button displays specific packet and error counters for the connection between WRKS1 (the node originally selected) and node CTRL1.
The secondary normally has no traffic, so the communications scheme relies on background traffic (Heartbeats) to determine whether the
integrity/connection is good. Heartbeats are sent/received every 15 seconds between nodes expecting to communicate. Integrity is not marked
bad until 3 Heartbeats are missed, so it takes 45–60 seconds maximum for a disconnected cable to show bad.
The above statistics show that the secondary on node WRKS1 sent 6 Heartbeats Out to node CTRL1 and received 0 Heartbeats In from it.
Similar statistics are displayed if you select the node CTRL1 and then select detailed statistics between CTRL1 and node WRKS1. In this
case, you would not know which of the 2 nodes was at fault, only that they could not communicate with each other.
You can reset these Communication Details counters by selecting the Reset Details button. You can also confirm proper connection by
selecting the Controller secondary on diagnostics, clicking the right mouse button, and then clicking TCP/IP Ping.
Troubleshooting Fieldbus Devices
There are a number of reasons why fieldbus information may not display on your screen. To troubleshoot issues, first use the Diagnostics
program to verify device communication with the DeltaV system. Then, use the following table to check other issues.
If… Check these Items…
Device Alarms do not show up The device supports Device Alarms (the Fieldbus Device
in the Alarm Banner or Event Alarms icon appears in the DeltaV Explorer).
Chronicle
The device is connected to a Series 2 H1 card.

The device has Device Alarms enabled (click Device
Properties and then select the Alarms and Displays tab
check box).

The area in which the device is located is assigned to the
workstation. Select the workstation in the DeltaV
Explorer and then in the Alarms and Events subsystem
and check assigned areas.

The device's specific Device Alarms-Failed,
Maintenance, Advisory, Abnormal, or Comm, are
enabled (In Explorer, click Fieldbus Device Alarms icon,
right-click each specific alarm, choose properties. In
System Alarm Management, you can do this by adding
the Plant Area(s) where the alarms originate and choosing
the Display Device Alarms option.)

The individual device condition is enabled (device's
Configure screen, location is manufacturer dependent).

The device alarm is not suppressed (Check faceplate,
Alarm Suppression screens, or Alarm Summary screens
in DeltaV Operate).

The individual device condition is not suppressed
(Conditions screen).
A Device Alarm cannot be The device was deleted or decommissioned while there
acknowledged was one or more active Device Alarms. Download the
device port.
Fieldbus Device Alarms (FDA) Device does not support Device Alarms. Check with
icon does not show up in manufacturer for device revision that supports Device
DeltaV Explorer Alarms.
Individual fieldbus Device Enable Device Alarms on the device's properties page,
Alarms (Failed, Maintenance, alarms and displays tab.
Advisory, Abnormal, or No
Comm) from a particular device
do not show up in the right pane
of DeltaV Explorer
Unable to download fieldbus Use DeltaV Diagnostics to verify connections with the
device (conditions related to device.
Device Alarms may cause this)
Verify that you have the correct controller and I/O.
Device Alarms are only supported with Series 2 H1
cards.
Controller and I/O
Inside this topic
This section discusses controller and I/O problems you might encounter and includes a checklist of LED indicators.

Is Controller Not Accessible from DeltaV Explorer?
If the controller is not accessible from the DeltaV Explorer, the controller might need to be decommissioned.

Are the Devices Not Responding?
If the DeltaV System is running, start the DeltaV Diagnostics program to see the status of the devices.

Is There a Communication Error after Reinstalling?
If the DeltaV System is not communicating with a previously decommissioned controller after reinstallation, verify that the primary and
secondary IP addresses are correct.
Note If Auto Sense I/O is enabled, the controller LEDs do not indicate a problem if the IP addresses are incorrect.

Is the System Not Communicating after Configuration?
If the DeltaV System is not communicating after configuration, verify that the controller and I/O have power. If they do, use the tables in the
Checking the LED Indicators topic to identify problems indicated by the status of the LEDs.
Refer to Diagnosing Fieldbus Devices for more information.

Has the H1 Card Failed?
If the H1 card fails, the system loses visibility on the attached fieldbus segments. On a segment that does not support the backup Link Active
Scheduler (LAS), if the H1 card failure causes the PCMCIA within the H1 card to go down, all communication on the attached fieldbus
segment stops.
To recover from an H1 card failure, replace the card. The H1 card is automatically downloaded and resumes functioning as the LAS. Startup
of the loop depends on how the loop is configured.

What Happens to Control on the Segment When the H1 Card Fails?
On a segment that does not support backup Link Active Scheduler (LAS), if the PCMCIA card goes down, all communication on the fieldbus
segment stops. Depending on the configuration, output blocks might go to a Fault State state.

How Can You Detect a Problem with the Backup Link Active Scheduler (LAS)?
View the integrity of the device in DeltaV Diagnostics.

What Happens to Control on the Segment When the Controller Fails?
If the control loop is running completely on the fieldbus segment (that is, the control is running in the devices and not in the controller), the
loop keeps running. However, if the loop is getting input from the controller, the loop performs its configured error processing.
To recover from a controller failure, replace the controller and then commission and download it. If the controller failure affected the fieldbus
loop, startup of the loop depends on how the loop is configured.

Is the Configuration Information Missing?
The loss of I/O Device Tags (or Dataset Tags) and assigned modules can be caused by improper decommissioning of a controller. When
decommissioning a controller, do not select Delete or Delete Assignments. Instead, select the controller in the left pane of the DeltaV
Explorer, click the right mouse button, and click Decommission. When you decommission a controller, the placeholder remains intact,
preserving the configuration information.

Is Controller Not in Decommissioned Controllers Tree?
Possible Cause Corrective action
Control network cable is not Test the cable between the
working correctly. controller and the hub. If the
cable is not working correctly,
repair or replace it.*
Node is not connected correctly Make sure cables are connected
to the network. to the correct ports on the hub
and the controller.*
Connection on the carrier is not Remove the controller from the
secure. two-wide power/controller
carrier for at least 15 seconds
and replace it onto the carrier.
This decommissions the
controller so it appears in the
Decommissioned Controllers set.
Either the DeltaV Explorer is not Exit the DeltaV Explorer and
connected to the active database restart the connection to the
or the DeltaV Database server is active database.
not running.
*For more information about cable connections, refer to Installing
Your DeltaV Digital Automation System.

Does the Controller Have an X Indicator?
The indicator appears for nodes that are not communicating. Typically, this indicator occurs when there is a bad connection or the
controller is not powered up. To clear this indicator, go to the node and make sure that it is connected, that the wiring is correct and sound,
and that the node is powered up. This indicator also occurs for a few seconds after a controller is commissioned.
Control network cable is not Test the cable between the controller and the hub. If the
working correctly. cable is not working correctly, repair or replace it.*
You are looking at the wrong Use the Identify Controller function in the DeltaV Explorer
controller. Node Properties menu to flash the controller LEDs.
Primary and secondary control 1. Use the Identify Controller function in the DeltaV
network connections are crossed. Explorer Node Properties menu to flash the controller
LEDs.
2. Verify that the primary control network cables are
connected to the correct primary ports on the controller,
workstation, and hub.
3. Verify that the secondary control network cables are
connected to the correct secondary ports on the controller,
workstation, and hub.
Primary and secondary IP Check the IP addresses for the primary and secondary
addresses are switched. control networks (using Workstation Configuration). If
switched, the DeltaV system does not communicate with
the controller, but the controller appears to be
commissioned (lights indicate this). The only evidence is
that the controller is listed with the X indicator in DeltaV
Explorer.
*For more information about cable connections, refer to Installing Your DeltaV Automation
System.

Are Control Modules Not Executing at Configured Scan Rate?
The FRETIM parameter in the DeltaV Controller represents the percentage of time available to run control modules. Controller resources are
partitioned so that most of actual microprocessor (CPU) resources are allocated for module execution and the remainder of CPU resources is
allocated for communications, self diagnostics, interrupt service routines, operating system overhead, and so on. Current CPU utilization can
be examined using the Diagnostics application's Time Utilization Chart function. If no modules are downloaded to the controller, the FRETIM
value is 100. If control module execution is equal to the time allocated for control, controller FRETIM value is 0. Control module execution
and controller overhead are not allowed to exceed the maximum time allocated. This ensures a balance of resources between controller
overhead and control module execution.
A scheduler in the controller manages control module execution. If the configuration downloaded to the controller requires more than 65
percent of the CPU, the scheduler clamps module execution as close to 65 percent as possible. In the clamp situation, control module slippage
occurs. If there is no control module slippage, all modules are executing at the configured rate. If slippage occurs, one or more modules is not
executing on time. The Diagnostic parameters LPctOnTime, MPctOnTime, and HPctOnTime indicate the degree of control module slippage.
Significant slippage as indicated by these parameters can cause the OINTEG for the controller to be BAD.
When the FRETIM parameter value is 0, one of two conditions exist:
 All modules are running at their configured execution rate. There is no module slippage. In this case, it is likely that adding control
modules to the configuration will introduce slippage.
 Control module execution attempted to exceed the 65 percent allocation and has been clamped. Not all modules are executing on time,
and module slippage is occurring. The degree of slippage is indicated by the diagnostics parameters LPctOnTime, MPctOnTime, and
HPctOnTime.
Either of these two cases is undesirable. Either the maximum configuration is reached or slippage is occurring. For this reason, it is
recommended that the modules configured in the controller (when downloaded) allow for a FRETIM value no less than 5-10. You can
improve a FRETIM by slowing down the execution rate of one or more modules.
As previously mentioned, a FRETIM value of 0 allows 35 percent of the CPU for other processing, such as communications. If the control
modules are at 65 percent and the number of data links requested from outside the DeltaV system exceeds 35 percent of the CPU resources,
the controller CPU is overloaded. In an overload condition, controller operation degrades. In this case, communication requests cannot all be
serviced in a timely fashion, resulting in stale data at the PC or timeout indications and downloads or diagnostic requests.
The FREMEM parameter is an indication of the amount of free memory (in bytes) available for user configuration. Control modules, function
blocks diagrams, and sequential function charts all consume configuration memory. It is inadvisable to construct configurations that drive the
FREMEM value to 0. A minimum of 400K is recommended for controller FREMEM.
Note that loaded phases dynamically consume memory. Consider the impact of loaded phases when calculating FREMEM.
Database
Inside this topic
This section discusses problems you might encounter with the database.

Are You Unable To Find the Database?
Perhaps the database was moved, or your workstation is pointed at the wrong database or the wrong database server. Click DeltaV |
Engineering | Database Administration and use the tools in the Control Panel to set which database and host are active.

Are You Unable To Open the Database?
Verify that the Lock Server is running on the ProfessionalPLUS workstation. (Click Start | Settings | Control Panel | Administrative Tools.
Then double-click the Services icon.) This background service is required for database access.
Click Start | Settings | Control Panel | Administrative Tools and then double-click the Services icon or click the right mouse button on the
task bar and then click Task Manager to verify that this service is running. If this service is not running, start it. (Click Start | Settings |
Control Panel | Administrative Tools and then double-click the Services icon.)

Is the Database Locked?
The database can become locked due to an unexpected occurrence, such as a system crash. The system displays messages informing you that
you cannot change the database because it is in use.
Caution Perform the following procedure only when you are certain that all programs are not running and that a program crash has occurred.
The Database Connections tool in the Database Administrator Utility displays the locks and allows you to remove them. To open this tool,
click DeltaV | Engineering | Database Administrator on the Start menu. Double-click Database Connections, select the connection, and
then select the Disconnect button. If this does not clear the problem, shut down the database server and restart it.
Use the Database Administrator Utility to verify that there are no open connections. Click File | Shut Down Server. Then, stop the DeltaV
Database Server. Once it has stopped, exit the Database Administrator Utility. Run any database application to restart the server.

Are You Unable To Perform Database Operations?
The DeltaV software requires that the Lock Server background service is running before performing any database operations.
Click Start | Settings | Control Panel | Administrative Tools and then double-click the Services icon or click the right mouse button on the
task bar and then click Task Manager to verify that this service is running. If this service is not running, start it. (Click Start | Settings |
Control Panel | Administrative Tools. Then, double-click the Services icon.)

Is the Workstation Using the Wrong Database?
When you convert a workstation of the type Other to a ProfessionalPLUS, the Workstation Configuration program defaults to any active
database that was previously registered on the workstation rather than creating a new database.
To convert a previously configured workstation from a type of Other to a ProfessionalPLUS workstation and create a new database on the
workstation, you must uninstall the DeltaV system from the workstation and reinstall before running Workstation Configuration.
DeltaV Programs
Inside this topic
The DeltaV software consists of many executable files, and some are dependent on other executable files. This section some issues that you
might encounter with DeltaV Programs. You might also want to run the Diagnostics program to obtain more detailed information about what
is happening in your DeltaV system.

Do DeltaV Services Fail To Start Automatically?
The three main problems that cause this to occur are:
 The DeltaV software might be installed under an account other than the one you usually log in to. The installation program only
adds the user who installed the DeltaV software to the DeltaV security group. To add the account under which you are trying to run
DeltaV software to the security group, use the User Manager.
 The DeltaVAdmin password has expired. Normally this password is set to never expire. However, if that setting has been changed
and an expiration has been set and you stop the DeltaV services or reboot a node, then the login for the service will fail and the services
do not start. The DeltaV system then cannot function as expected. If an expiration has been set, the password must be changed before
expiration using the ServPwd utility.
 The file permissions for the path you installed to might be too restrictive. The file permissions are inherited from the parent
directory. If you install into a parent directory that has restricted access, the DeltaV system will not be able to access the files it needs to
run. Change the file permissions so that the DeltaV group is allowed access to the installation directories and all of its subdirectories.
 There might be a problem with one of your network interface cards. In the Diagnostics program, click Tools | Windows Event
Viewer | Windows Logs | System.
To verify that the DeltaV program was started, click Start | Settings | Control Panel | Administrative Tools and then double-click the
Services icon.

Does the System Not Function as Expected?
Check the event log by clicking Start | Settings | Control Panel | Administrative Tools | Event Viewer. Look for a DeltaV log entry. If it
indicates an error with a status of 5, you might be getting an access denied error from Windows. Here are a few things to check:
 Do not change the DeltaVAdmin, DVBatchAdmin, or SoftPhaseUser account passwords through DeltaV User Manager or Windows
User Manager. Always use the ServPwd.exe (found in the DeltaV\Bin folder). Several programs depend on these accounts to operate
properly and this utility handles changing the password where needed for you.
 Do not assign the node name of DeltaV to your machine.
 Make sure that the DeltaVAdmin account is a member of the DeltaV group.
 Grant Log on as service and Change system time privileges to the DeltaVAdmin account.
 Grant Read Execute access to the bin and library directories to the DeltaV group.
 Grant Write access to the data directory and its subdirectories to the DeltaV group.

Is the System Time Inconsistent?
The system time might have been changed using the Control Panel instead of the Set/Synchronize Network Time program. For more
information, refer to the System Time topic.

Does Process History View Display an Error Message?
A message box entitled ODBC Error appears with text similar to the following:
SQLState='S1109'
NativeError=4294966279
error message="Microsoft ODBC Microsoft Access 7.0 Driver, Record is deleted."
The most probable cause for this error message is that you requested data from the Event Chronicle database while records were being deleted
to keep the database within its configured maximum record. Wait a couple of minutes and try your request again.

Does Process History View Fail To Open Files?
This problem can occur if the user variable (Temp) is deleted or if the value for this variable (C:\Temp) is changed and the computer is not
rebooted. Since the Event Chronicle creates two temp files when it is opened, it might fail to open if this variable is deleted or if the value for
this variable has changed without a reboot.
It is recommended that you not delete the temp user variable. If you change the definition of this user variable, be sure to reboot your
computer. User variables are set in Control Panel | System | Environment.

Is Channel CV Misleading in Excel or DeltaV Operate?
If the status field associated with a CV has a value of 128, the Current Value (CV) represents a valid value. Any status value other than 128
indicates a stale CV value. When reading a channel Current Value (CV) in Excel, include the status value in a cell adjacent to the CV so that
you can determine if the CV is valid. For DeltaV Operate, you can configure dynamic coloring of the CV. To do this, use color by value,
specifying the ST field with a threshold value of 128 as the normal color and 127 and 255 as the Stale Color.
Directories and Disks
If you are unable to share your disk or one of your directories, perform the following the steps:
1. In Windows Explorer, select the directory you want to share.
2. On the File menu, click Properties.
3. Select the Sharing tab, and then click Shared As.
4. To add a comment about the share, type the text in Comment.
5. To set a User Limit other than Maximum Allowed, click Allow and specify a number of Users.
6. To set share permissions, click Permissions.
If the Sharing tab is not visible, try using Services in Control Panel (click Start | Settings | Control Panel | Administrative Tools and then
double-click the Services icon) to start your Server service.
Comments help users locate shared information. To read comments, click Details on the Network Neighborhood View menu and look under
Comment.
DeltaV Function Blocks
This section addresses some of the issues you might encounter with DeltaV function blocks.
Are Parameters Not Displayed on the Diagram?
Not all parameters of a function block are displayed on the diagram by default. You can make a parameter visible so that you can wire to it on
the diagram by clicking the right mouse button while the cursor is on the block and then clicking Show Parameter. A list of parameters is
displayed, and you can select which one you want to view.
Are Values on Function Blocks Scrambled or Missing?
Function blocks too close together or near the edge can cause scrambled or missing values.
Log On
Users might be unable to log on to the DeltaV system for several reasons:
 The user might not have an account on the workstation.
 The user might not have an Operating System (Windows) account and/or a DeltaV Database Account.
 The user might not have a password or might have forgotten the password.
Perform the following actions.
1. Use the DeltaV User Manager to verify that the user has an account on the workstation. Click Start | DeltaV | Engineering | User
Manager.

The DeltaV User Manager program opens.


If the user's name does not appear in the list of users, create an account for the user. If the user has an account, verify that the user has
an Operating System (Windows) account and/or a DeltaV Database Account.
2. Create a new user account by clicking File | New | User.

The New User program opens.

3. Enter the user's username in the Name field. The username is the name that identifies this user to the DeltaV system. For example,
Jsmith.
4. Enter the user's full name in the Full Name field. The full name identifies the user to the system administrator rather than to the DeltaV
system (for example, John Smith).
5. Enter a password for this user in the password field. (Make a note of the password because you will give this password to the user.)
6. Retype the password in the Confirm Password field to confirm that this is the correct password.
7. Click DeltaV Database Account to allow this user to log on to the DeltaV system. Select the Operating System (Windows) account to
allow this user to log on to the DeltaV system from this machine.
8. Write a short description of the account in the Operating System (Windows) Description field.
9. Click OK.
10. Download the runtime database with the new information. Refer to the Download the Runtime Database topic for more information.
A user might have an account but might lack the required account type. There are two account types:
 DeltaV database account
 Operating System (Windows) Account
The DeltaV database account defines the set of DeltaV privileges that a particular user has. Users cannot log on to the DeltaV system without
a DeltaV database account. An operating system account allows DeltaV users access to the DeltaV system on a specific machine. DeltaV
users can log on to a specific machine only if they have an operating system account on that machine. To verify user accounts, perform the
following tasks:
1. Click Start | DeltaV | Engineering | User Manager.

2. Double-click the user's name.
The Properties for User dialog box opens.
3. Verify that both account types (Operating System (Windows) Account and DeltaV Database Account) are checked and then click OK.
However, if one of the account types is not checked, click the check box for that account type and then click OK.
4. Download the workstation.
Users might be unable to log on because they forgot the password or because their accounts were created without a password.
To create a new password:
1. Open the DeltaV User Manager.
2. In the list of names, double-click the user's name to open the Properties for User dialog box.
3. Enter a password for this user in the password field. (Make a note of the password because you will give this password to the user.)
4. Retype the password in the Confirm Password field to confirm that this is the correct password.
Modules
Inside this topic
This section contains some options for troubleshooting your modules.

Debugging Modules
There are two views in Control Studio that enable you to debug a module's algorithm. They are On-line view and Debug view. The On-line
view allows you to perform testing of SFCs, function blocks, and modules. The Debug view is used to solve problems, identify areas to
increase performance, or gain an understanding of a module.
Each view lets you look at the block's input and output value and lets you step through the algorithm one block at a time. In Debug view, you
can set breakpoints to stop execution at a particular block.
Note You can only debug downloaded modules, and you can affect your process if you change values or stop execution.
If you receive the message Failure to establish session, verify that the module you are debugging or viewing online is downloaded in
the controller. This message also appears if the controller is reset while an online (or debug) session is in progress.
For more information on debugging, refer to the Online and Debug Viewing of Function Blocks topic.

Restoring One Module
If you need to restore just one module in the DeltaV database and do not need to restore the entire database, you have two options using the
DeltaV Import feature.
Note Normally you will restore the entire database. Use either of these processes only when restoring the entire database is not feasible.
If you have an export file of a particular module, you can restore the module by importing the export file. You can export a module any time
prior to making adjustments. Use the DeltaV Explorer Export feature (click File | Export). Then, if you need to import that module (the one
that you exported), you can do so by using the DeltaV Import feature (click File | Import from the DeltaV Explorer program).
If you do not have an export file containing only that module, but you do have the entire database exported, you can still use the DeltaV
Import feature (click File | Import). When prompted, respond No to overriding all existing modules except the one module you want to import.
On that one module, respond Yes.
Network Performance
Network performance problems might be caused by address conflicts. If you configure a new database, you must use the DBAdmin tools to
create a database and set the database to Active. Then, to create the master node in the database, you must run DeltaV Workstation
Configuration (PCInstall) under the DeltaV | Installation menu.
If you do not run PCInstall to create the master node, the IP address in the database might not be the IP address at which the workstation
network cards are configured. As a result, when you create a new controller in the DeltaV Explorer using drag-and-drop, a decommissioned
controller address can conflict with the IP address of the workstation.
The DeltaV ProfessionalPLUS or Application Station connects your DeltaV system to your Plant LAN. Make sure that this connection only
transfers the information that you intend it to transfer. Transferring unnecessary information can cause your network to slow down. Therefore,
it is important that you understand routing characteristics and take the necessary actions to make sure that your system is properly configured.
Refer to your router documentation for more information.
Parameters/Fields
If you are unable to write to a parameter or field, make sure that you have the keys to unlock this parameter or field. You must have the Can
Configure key to look at locks. Contact your system administrator to find out whether or not you have the Can Configure key. To verify the
current user, follow these steps:
1. Determine the lock on the parameter or field.
2. Use the DeltaV Explorer to determine which lock protects this parameter or field.
3. Verify the area that has been assigned to the workstation.
4. Click Help | About DeltaV Explorer. Look at the Current User panel.
If your name appears in this panel, you are the current user.
If you are not the current user, click Tools | DeltaV Logon and log on. Contact your system administrator if you do not know your user name
or password or if you get an error when logging on.
Once you have verified the current user, perform the following steps:
1. Click Start | DeltaV | Engineering | DeltaV Explorer.
2. In the DeltaV Explorer, expand System Configuration as well as Setup. Then, click Security. In the Contents of Security area of the
window, click Parameter Security to look at locks on parameters or Field Security to look at locks on fields.
The Parameter Security Properties or Field Security Properties dialog box opens.
3. Scroll through the list in the Parameter Security or Field Security dialog box, find the parameter or field you want to write to, and make
a note of the lock that protects the parameter or field.
4. Close the dialog box.
If you do not have a key to the lock, ask the system administrator to grant you that key for the area assigned to the workstation.
The system administrator uses the following procedure to grant a key to the lock that protects the field or parameter:

2. Double-click the user name to open the Properties For User dialog box and click the Keys tab.
3. Select the lock in the All Locks list, click the Grant Key button to grant that key to the user, and then select the Plant Area for which the
user needs the key. That is, the same area as assigned to the workstation.
4. Click OK.
5. Return to the DeltaV Explorer to download the runtime database.
You must have the Can Download key to download the runtime database. Contact your system administrator to find out whether or not you
have this privilege.
To download the runtime database using the DeltaV Explorer:
1. Select the workstation that you want to download, click the right mouse button, and then click Download.
2. Click the first option on the slide-off menu (for example, ProfessionalPLUS workstation).
3. Follow the prompts to download the workstation.
If you are still unable to download, contact DeltaV Technical Support.
Recovering from a System Crash
If the system software does not seem to respond (for example, keyboard and mouse operation has stopped and screens are not updating), you
might be able to recover.
Checking Task Manager
Run Task Manager to see if a process is monopolizing the CPU or memory. If you can identify the process, you can stop that process and
avoid rebooting. If you cannot tell from the Task Manager which process is causing problems, reboot the workstation.
Restarting
When recovering from a system crash, perform the following steps:
1. Restart the computer (that is, click Start | Shut Down, click Restart the computer, and then click Yes).
Caution When restarting, do not cycle power. This can affect the entire system and potentially cause more extensive damage.
2. Restart the DeltaV software.
3. Wait until all services have started (the disk stops) before you log on.
Workstation
Inside this topic
This section discusses workstation problems that you might encounter.

Does the Workstation Have an X Indicator?
The indicator appears for nodes that are not communicating. Typically, this indicator occurs either if there is a bad connection or the
workstation is not powered up. To clear this indicator, go to the node and make sure that it is connected, that the wiring is correct and sound,
and that the node is powered up.
Workstation is not set up Make sure the workstation is powered up. Click Start |
properly. Settings | Control Panel. Double-click Administrative Tools
then double-click Services, and verify that DeltaV Services are
running.
Node is not connected to the hub. Check the control network cables to make sure they are
connected to the correct ports on the hub and workstation.
Control network cable is not Test the cable between the workstation and the hub. If the cable
working correctly. is not working correctly, repair or replace it.*
Workstation address is set to a 1. Look at the Internet Protocol (IP) address and verify that the
default value or an incorrect address matches the DeltaV Explorer address for the node.
address. (Click Start | Settings | Control Panel. Then, double-click the
Network Connections icon. Click the connection and then click
View status of this connection under the Network Tasks list.
Click the Support tab. If the address is not correct, run
Workstation Configuration.

2. Use the Utilities from the 3Com Install disk to verify that the
Plug N Play feature is turned off for the workstation network
card. If you have 3Com ISA cards, run 3C5X9CFG.EXE.
*For more information about cable connections, refer to Installing Your DeltaV Digital
Automation System.

Is the Workstation Using the Wrong Database?
When you convert a normal workstation to a ProfessionalPLUS, the Workstation Configuration program defaults to any active database that
has been previously registered on the workstation, rather than creating a new database.
To convert a previously configured workstation from a type of Other to a ProfessionalPLUS and keep the currently active database, simply
run Workstation Configuration on the other workstation and select ProfessionalPLUS as the type.
To convert a previously configured workstation from a type of Other to a ProfessionalPLUS workstation and create a new database on the
workstation, you must uninstall the DeltaV system from the workstation and reinstall before running Workstation Configuration.

Are You Unable To Download or Configure the Workstation?
If you are unable to download or configure your workstation, the cause could be one or more of the following:
 You might not be logged on to the DeltaV system. Refer to the Log On to the DeltaV System topic for more information.
 A piece of hardware called a System Identification Key might be missing. Refer to the Check the System Identification Key topic for
more information.
 You might be missing execution keys. Refer to the Check Execution Keys topic for more information.
 The runtime database might have been modified but not downloaded to the workstation. Refer to the Download the Runtime Database
topic for more information.

Log On to the DeltaV System
Use the DeltaV Login program to log on to the DeltaV system.
1. Click Start | DeltaV | Operator | DeltaV Login.
The DeltaV Logon program opens.
2. If your name and computer or domain appears after Current user:, you are already logged on to the DeltaV system. Go to the Check
Execution Keys topic.
3. If <none> or another user name appears after Current user:, find your name in the User Name drop-down list, enter your user password,
and click OK. Contact your system administrator if you do not know your user name or password or if your user name is not listed in
the User Name drop-down list.
4. If another user name appears after Current user:, find your name in the User Name drop-down list, enter your password, and click OK.
Contact your system administrator if you do not know your user name or password or if your user name is not listed in the User Name
drop-down list.
Note You can also use the Windows Run command to log on and off of the DeltaV system.
To log on and off (respectively) of the DeltaV system using the Windows Run command, perform the following steps:
1. Click Start | Run and type the following:
hlo.exe -user UserName -password UserPassWord -computer ComputerName

(where UserName is the user's name, UserPassword is the user's password, and ComputerName is the workstation name.)
hlo.exe -logoff
2. Click OK.
If you are still unable to download, refer to the following topics:
Check the System Identification Key
Check Execution Keys
Download the Runtime Database

Check the System Identification Key
The System Identification Key plugs into the USB port of the ProfessionalPLUS workstation and provides authorization services. Ensure that
a System Identification Key is securely plugged into the workstation.
If the System Identification Then…
Key is…
Missing Contact DeltaV Technical
Support.
Securely plugged in Make sure that you are logged on
to the DeltaV system, check the
execution keys, and ensure that
the most recent runtime database
has been downloaded to the
workstation.
Listed as "No system key Make sure all other avenues have
attached" in DeltaV Explorer been checked (see items above).
If the System Identification Key
is still not being recognized,
unplug the device and plug it
into another USB port. This will
initiate Windows' Plug and Play
feature.
If the System Identification Key is plugged in securely and you are still unable to download the workstation, contact DeltaV Technical
Support.

Check Execution Keys
Execution keys, which allow users to download and configure workstations, are assigned in the DeltaV User Manager. It is possible that
execution keys have not been assigned.
Note You must be logged on to Windows as administrator to grant execution keys.
To determine if execution keys are assigned:
2. Double-click the user name to open the Properties For User dialog box and click the Keys tab.
Note You must have the Can Download key to download the workstation and the Can Configure key to modify the configuration
database.
3. Look at the Has Key For area. If Can Download and Can Configure are not in the list, add them and then click OK.
4. Go to the Download the Runtime Database topic.

Download the Runtime Database
Use the DeltaV Explorer to download the workstation. Downloading the workstation downloads the current runtime database to the
workstation.
If you granted this user the Can Download and Can Configure keys in Step 3, the runtime database must be updated with this new
information.
If this user already had the Can Download and Can Configure keys, it is possible that the runtime database was not downloaded at the time the
keys were granted. Download the runtime database now to ensure that this is not the cause of the problem.
Note You must have the Can Download key to download the runtime database. (System administrators, refer to the Check Execution Keys
topic for information on granting the Can Download key.)
To download the runtime database:
1. Click Start | DeltaV | Engineering | DeltaV Explorer.

The DeltaV Explorer program opens.
2. Select the workstation that you want to download and click the right mouse button. Then, click Download and click the first item from
the slide-off menu (for example, ProfessionalPLUS workstation).
3. Follow the prompts to download the workstation.
If you are still unable to download the workstation, verify that the System Identification Key is securely plugged into the workstation.
Technical Support
Refer to the DeltaV Service Guide that was packed with your license for information about available services.
Before You Contact Technical Support
Before you contact Technical Support, use the following checklist to gather information so that we can better help you solve your DeltaV
problem:
1. What are the indications of an error?
 Print out any error messages.
 Print out any Dr. Watson logs.
2. Have you previously been able to successfully run DeltaV software?
3. Determine which DeltaV services are running by clicking the right mouse button in the task bar and clicking Task Manager. Click the
Processes tab to see a list of tasks that are currently running.
4. Is the DeltaV software the only program that does not work?
5. What is the succession of events that occurred just before this problem appeared?
Contacting DeltaV Technical Support
Contact DeltaV Technical Support using the information at:
http://www.emersonprocess.com/systems/support
Make sure you have the following information ready before you call:
 System Identification Number
 Software Version Number
 Description of the problem
If you are calling, be at your computer if possible. This enables the Technical Support Representative to step you through the proper problem
solving procedures.

Increasing Version Control Space

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Increasing Version Control Space

Uploaded by

Copyright:

Available Formats

Increasing

Setting Description Applications / Desktops

User Name Windows Groups DeltaV Groups

User Groups the user is a member of Description

Point Count Minimum Size 30 Days 60 Days

Error Cause Corrective Actions

To achieve this result... On In Server 2003

If you are MSSQLServer and The destination Security access on the

switchport mode access

3) no ip igmp snooping (near the beginning of the file)

4) no file verify auto (near the beginning of the file)

5) no spanning-tree vlan 1 (near the beginning of the file)

switchport mode access

no cdp enable

9) no ip http server (near the end of the file)

10) no cdp run (near the end of the file)

1) no aaa new-model (near the beginning of the file)

You might also like