Remote access

Configuring remote user account access to DeltaV SQL databases

This topic applies to connections coming from a remote workgroup or domain and accessing a SQL database, such as the DeltaV Event Chronicle or Batch Historian databases.

One example of this is a Remote DeltaV workstation that, using Process History View, needs to access the Event Chronicle on the DeltaV system the Remote Workstation is connected to. The SQL database in some cases, requires modification.

DeltaV is in a domain and the remote node is in a workgroup

Configure the remote user as follows:
  • The remote user (RU) exists on the remote node with the appropriate Windows rights and privileges for it to function as a user on that remote node.
  • RU account name and same password exists as a DeltaV domain user.
  • RU account name and same password exists as a DeltaV Database account, with the computer/domain field set to Unspecified.
  • RU account name and same password exists on the Event Chronicle node as a local user if the Event Chronicle node is not the DeltaV domain's domain controller.
  • The RU account name is added as an individual user to the SQL database's allowed logins.
Note

If you do not have the SQL Server Management Studio installed, it is available for download.

DeltaV is in a domain and the remote node is in a domain

Configure the remote user as follows:
  • First, configure a two-way trust between the domains
  • The trusted remote domain user (RDU) exists on the remote node with the appropriate Windows rights and privileges for it to function as a user on that remote node.
  • The trusted RDU account is a member of the appropriate DeltaV domain groups (for example, DeltaV users group, or DVBHisUsers, and so on).
  • The trusted RDU account exists as a DeltaV Database account.
Note
When configuring users between trusted domains, you must add the users at the appropriate forest level. DeltaV domains are their own forest, however, your other domain (to/from which a trust exists), might be a child of a larger domain (the forest). You can only associate the users at the common domain level. Domain groups/users are noted as follows:

  • Domain\DomainName\Group = the forest domain's groups.

  • Domain\DomainName\UserName = the forest domain's user account.

  • DomainName\Group = the local domain (child)'s groups.

  • DomainName\UserName = the local domain (child)'s user account.

(where DomainName is the name of the domain, such as MyDeltaV.com and Group/UserName is the name of the actual group (Administrators) or user account (JSmith).) All domains contain both notations, even when the entire domain is the forest (no child domains under it).

DeltaV is in a workgroup and the remote node is in a workgroup

Configure the remote user as follows:
  • The remote user (RU) exists on the remote node with the appropriate Windows rights and privileges for it to function as a user on that remote node.
  • RU account name and same password exists as a DeltaV user on the node to which it is connecting (for example, the Event Chronicle or Batch Historian node).
  • RU account name and same password exists as a DeltaV Database account, with the computer/domain field set to Unspecified.
  • The RU account name is added as an individual user to the SQL database's allowed logins.

Adding a local user to the SQL database's allowed logins

Follow these steps to add a local user to the SQL database's allowed logins
  1. Start SQL Server Management Studio.
  2. Connect to the server (for example, the Event Chronicle or Batch Historian).
  3. Expand the server node name.
  4. Expand the Security folder below the server name.
  5. Right click the Logins folder and select Login - New from the context menu.
  6. Provide that user login with at least read access to the SQL database.
    Note

    You can apply the same access as given the DeltaV group in that SQL database.