Emerson Exchange 365

In reply to Andre Dicaire:

I can fully understand this requirement but I do have two questions.  1. Does the Domain Controller with ProPlus on it require any of the Active Directory fsmo roles to be on that domain controller?  2. If not can the Domain Controller with ProPlus on it be setup as a Read Only Domain Controller?

In reply to cjshively:

From NK-1300-0027:

(http://www3.emersonprocess.com/Systems/Support/documentation/deltav/kba/NK-1300-0027/carticle.asp?qsproductlineid=2)

"Like the rest of the Flexible Single Master Operation (FSMO) roles, only one DC can be the PDC Emulator. The ProfessionalPLUS is intended to be the first DC and thus should have all five FSMOs by default."

From Windows Server 2008 Help Manual Installation Instructions'

"If the DeltaV System needs to be in a Windows domain environment, the ProfessionalPLUS station must be promoted as the first Domain Controller"

 

In reply to Youssef.El-Bahtimy:

FSMO roles can be moved to any DC.  You are right the PDC emulator is one of the roles.  Why does the Pro Plus need to be on the same DC that has the PDC emulator?  Here is why I ask.  We have many sites with TMS systems.  We would like to setup a single TMS domain accost all our sites.  To do this we want our Read Write domain controllers housed inside our centralized secured datacenter.  The Domain controller at the site running Pro Plus would just be a normal DC that does not have any FSMO roles on it.  

Also, why is this system even designed like this in the first place?  It is Microsoft best practice to not have any other applications installed on a domain controller.      

In reply to cjshively:

Emerson has consideration for the Microsoft recommendation as such - from  NA-0800-0097 Pertinent Active Directory Requirements for a DeltaV Installation

"The ProPlus server must hold all five Flexible Single Master Operations (FSMO) Roles.

• This is generally discouraged by Microsoft for loading reasons, but given the system size limitations of a DeltaV system, it is not an issue to have the FSMO roles hosted by the ProPlus"

(http://www3.emersonprocess.com/Systems/Support/documentation/deltav/kba/NA-0800-0097/carticle.asp?qsproductlineid=2)

 You should also look into this KBA as a guide for how you wish to implement integration of enterprise accounts into DeltaV. 

We have done enterprise active directory integration to DeltaV using external domain trusts, allowing DeltaV OS users to be authenticated by the Enterprise DC.  I am co-presenting on this topic for Emerson Exchange this year: https://www.emersonexchangeregistration.org/2014/connect/sessionDetail.ww?SESSION_ID=1951

 

In reply to Youssef.El-Bahtimy:

Youssef, I think with all your great contributions to the DeltaV track, that your presence at the Exchange in Orlando this fall should give lots of folks a great reason to attend, which
<shameless promotion>has a $995 (US) Early Bird registration rate through August 15.</shameless promotion> 

In reply to Jim Cahill:

Ha.  and I thought I was he only shameless promoter here.

In reply to Youssef.El-Bahtimy:

El-Bahtimy, I am the IT Manager working on a project to allow an esight application to get meter readings out of DeltaV.  The eSight application is installed on our business network and business domain.  The Business network and automation network are joined using firewalls.  In order for eSight to gather the data from DeltaV we much create a trust between the two domains.  The department that manages the automation systems and the local deltaV vendor does not want us to create the trust for fear of the "unknown".

Reading through your comments it seems like the trust is the correct way to go.  My only problem is when we look at the bigger picture.  We have over 20 sites running Delta-V.  I do not want to create over 20 different trust between my business domain and each site automation domain.  I would like to stand up a new automation domain called "TMS.com" that all DeltaV systems at all our sites join.  This allows us to great a single trust between the tms.com domain and the business domain.  It also allows us to centrally manage and secure all TMS systems.  

In reply to AdrianOffield:

It uses OPC but it requires the use of a business domain service account.  The trust is required so the service account on the business domain can access the data on the DeltaV domain.

In reply to AdrianOffield:

Matrikon’s OPC Tunneller looks promising.  I assume you have this running in your environment.   How stable has it been?

In reply to cjshively:

So I read the original request as a need to have multiple enterprise users authenticate into the DeltaV domains for interactive use.

 As stated, if it is just a need to have one service account access the system via OPC, then using local user impersonation of the enterprise service account on the app station OPC server may be enough.  You have to ensure the service account is given a DeltaV application account with a domain matching the APP station that serves as the OPC server.  If DCOM or firewalls are giving you problems, then a tunneller is a good solution.

A one-way trust poses little risk, and 20 trusts is not that many (microsoft warns about having more than 2400 due to performance issues).

In reply to Youssef.El-Bahtimy:

Tunneller was created to overcome the challenges of DCOM through the firewall. However, it strips out user security and all connections are seen at the OPC server end as the same user.  It there is no need to have write access to any clients that might use Tunneller, this should not be a concern.  

ith the release of OPC.NET wrappers, the OPC connection is much easier to implement through firewalls and removes the need for encapsulation provided by Tunneller.  But this gets you back to the security issue between domains.

I've used local machine accounts instead of domain accounts to get access between two machines in different Domains.  The local accounts trigger authentication locally and if account names and passwords match, authentication is granted.  But I'm sure you know more about this than I. The DeltaV account used for OPC access is created as a local account in the DeltaV User manager where you can assign DeltaV security.

Andre Dicaire

In reply to Jim Cahill:

I second that!

In reply to Youssef.El-Bahtimy:

Thank you Youssef for the details you provided here very useful. Please I want to join a redundant application station (workgroup) to an existing proplus dc, will I need to uninstall deltav, opc mirror on the application station and reinstall dv on the application station after joining the domain.