Emerson Exchange 365

Setting up DeltaV systems as part of an Enterprise domain.

I'm looking for experiences and/or lessons learned on setting up DeltaV control system as a "TREE" in the domain "FOREST". The goal is for better user account management, i.e. single login password, single user account, etc.

I'm sure there will be trade-off with individual domain setup versus the "enterprise" setup, it would be great if you can share that information also. Lastly, I understand that it may not be currently not supported, but I heard that there was an Emerson Exchange presentation about this type of setup awhile back. So I wanted to know if there are plans to support this type of setup.

• Domain Forest
• Domain Tree
• DeltaV Enterprise Setup

PTulen

• 4 May 2016 11:25 PM
• Cancel

10 Replies

• Steve Linehan

  

  • 5 May 2016 11:47 AM

  I have not seen this presentation, if you do locate it please post information.
  
  I have not seen this done before but I have seen trust relationships setup between DeltaV and a site. In that way the user account (Windows Only) is created and updated by the site. From the DeltaV side then a windows account can be selected and enabled as a DeltaV user. I am not sure if this is supported but it is an easier way to have the system do what you want and still follow Emerson Install guidelines.
  
  Anybody else weigh in on this as I am interested to see what best practices are out there.

  • Cancel
• Daniel Parrish

  

  • 5 May 2016 12:31 PM

  We routinely establish one-way outgoing trusts from our DeltaV domains to our corporate domain expressly so that operators can use their domain accounts, which employ complexity and expiration rules, for authentication. Those accounts then are configured in DeltaV for authorization. This is a supported configuration, books online describes the options, see System Administration and Maintenance.
  
  We have had to home-grow a few solutions to unique problems this can create though.
  
  In our case, corporate domain accounts do not reflect a person's actual name, and DeltaV user manager doesn't let you define full/last name for an account associated with an external name (I don't expect it to, it assumes it can get that from the domain, which it can't or doesn't), and so, we've built our own name resolution system to put a person's actual name on the toolbar. The other, and more important issue to address, is what happens when the corporate domain isn't available for authentication, local credential caching, login timeouts in those cases, etc. The solution we came up with is to monitor the remote domain's presence and check for it when the login button is pressed from the toolbar, giving operators at least a warning that their login may not be successful, and give them the option to login as an "emergency" (local domain) user. We've seen login timeouts take as long as a couple of minutes if the remote domain isn't available, and decided that that wasn't acceptable when trying to login to the control system. There are likely better ways to handle this, but based on our research, this is the best we could come up with.

  • Cancel
• Steve Linehan

  

  • 5 May 2016 1:16 PM

  In reply to Daniel Parrish:

  Daniel great information. One question is how to you implement the watchdog to tell the operator that the corporate domain is not available. In particular how you make this visible on the graphics. This could be a great idea for the user enhancement program if you could define failover domain Active Directorys to authenticate the user. If the corporate domain is available then authenticate there else use the local domain. Then use the alt key to access the menu to select local or corporate or even machine admin account so engineers can fix issues. This would remove one selection on the logon screen that the operator has to make.

  • Cancel
• István Orbán

  

  • 5 May 2016 2:01 PM

  We were considering the same, but opted to use independent domains with two-way trusts. Password synchronization is done with Dell Quick Connect Express. In a tree there is a risk that some enterprise-level policies are pushed down to DeltaV with negative consequences (e.g. restricting who can change the system time paralyzes the DeltaV NTP service causing time drifts).

  • Cancel
• Youssef.El-Bahtimy

  

  • 5 May 2016 2:33 PM

  I presented on this topic several years ago. Here is the video link: http://bcove.me/ltmgij03. If you were an attendee to the conference, you can download it here (original link did not work, trying different things)

  
  

  https://www.emersonexchange365.com/events/2014_orlando/m/mediagallery/3262

   

  
  DeltaV is not actually a child domain within the forest, but is setup with a one way trust as Described by Daniel Parrish. KBA NA-0800-0097 is referenced in the presentation.

  • Cancel
• PTulen

  

  • 5 May 2016 3:50 PM

  In reply to Daniel Parrish:

  Daniel, excellent information! Thank you for sharing. I have the same question as Steve's, can you give more information about the system monitoring for presence of corporate domain?

  • Cancel
• PTulen

  

  • 5 May 2016 3:51 PM

  In reply to Youssef.El-Bahtimy:

  Youssef, thank you for sharing. I will check out the link you provided.

  • Cancel
• Daniel Parrish

  

  • 14 Jul 2016 1:50 PM

  In reply to Steve Linehan:

  I'm no Windows expert, so what I did is implement a scheduled task on one of the servers that participates in the trust and ping the thing. If successful, I write a file to a known location indicating such. We customized the toolbar's login event to check for the presence of this file and prompting the user if it looks like the domain linkage is down and the likelihood of login success is low. This gives them the option to login with a local domain account with a single button press. We call this the "Emergency" user. Further, we modified our toolbars to indicate on the User field and the Login button when a non-corporate-domain account is logged in, showing very clearly when a non-preferred user account is used (Administrator, Emergency, any of our local admin/engineering accounts, etc.) I can give more details if needed, but this is the gist of it. (sorry for the delayed response)
  
  -dap

  • Cancel
• LostEngineer0

  

  • 8 Jun 2017 6:16 AM

  In reply to Daniel Parrish:

  Dear Engineers,
  since april our DelatV plant is connectet to our "Automation Plant Lan" . Now we have to add new User on DomainController via Active Directory, and then add this User on Proplus via User Manager. That works fine, but the User is not abble to change his Password via DeltaV Logon PopUp on deltaV Operate. Have somebody experience how to allow the Operator to change his PW on Operator Station like in the past.
  Thank you.

  • Cancel
• Alexandre Peixoto

  

  • 8 Jun 2017 1:16 PM

  In reply to LostEngineer0:

  I couple of things to check: When the new account was created: Did you check the "Operating System (Windows) Account" option in User Manager? In the User Manager Advanced Tag: Is the option "User Can't Change Password" disabled/unchecked?
  There might be other areas to check, including your Domain environment deployment, but I'd start by these basic checks.
  It might be hard to explain in this forum everything you've done in your system so far, so if basic instructions do not provide the answer your looking for, I'd also try to reach out to GSC to get a dedicated support for your case.
  Regards,
  Alexandre Peixoto

  • Cancel