http://lnkd.in/wkP-Y6
When opening Process History View for the first time, a user will be prompted to select the source data server for Event Chronicle and Historical Process Data. The default is localhost, but typically there will be one preferred application station that should serve as the system-wide data source for each of these functions. Most operator workstations (where you will be likely accessing the client) will not have these server functions enabled. Once the Windows user sets these servers, they will persist on that workstation for that user. However, when they log in to another workstation, they will have to set it again. In fact, every single windows user will have to set it for every single workstation they log in to. Typically, operations users don't even know which server to pick. I have been implementing a method to set this system-wide for all users by utilizing Windows Domain Group Policy for many years. First of all, the settings are stored in the Current Windows User registry hive. Group Policy is technically not for implementing system-wide registry settings that are not part of a Microsoft Policy setting; Server 2003 will warn you about this, while Server 2008 gives you a wizard with which to do it!. Using the group policy editor in Server 2008 (I'd create a new policy specifically for site policy settings) browse to User Configuration-->Preferences-->Registry. Add two new settings using the following registry keys: HIVE: HKEY_CURRENT_USER Key Path: Software\FRSI\DeltaV\CurrentVersion\PHV\SourceNodes ValueName: EventNode (for the event chronicle) ValueName: HistorianNode (for the continuous historian) Enter the server names for the Value Data fields. Ensure the policy is enforced. Re-log into windows on any workstation in the domain and open Process history view. The servers configured in the policy will already be set for use by the client. The process for doing this on Server 2003 is a little trickier, but fundamentally the same. I've used the same process to change things like Regional settings, as well (time and date format). For a system with hundreds of users and dozens of workstations, this modification will eliminate a lot of questions and headaches for administrators.
This is awesome. Nice work!
In reply to Aaron Crews:
For the reasons Youssef suggests, we utilise a single WIndows account on operator stations, and have operators log in at the DeltaV level, the common windows account has all the correct PHV, screensaver settings. User auditing is done through event history.
In reply to AdrianOffield:
I agree with Adrian; all dedicated operating workstations need a default windows account to automatically log in when booting. Problem is, I typically have a cast of engineering, quality, etc. users accessing the system through terminals services, professional workstations, and other means where their windows account is required for log in to the OS (by virtue that these type of workstations/servers would not have any user logged in, normally). The domain group policy (which can be used for many purposes, including enforcing the idle time out screensaver as Adrian gave as an example) updates network-wide, is centrally managed, and requires suprisingly little technical expertise to set up and administer.
In reply to JoshC:
In reply to Tim Alexander:
Ah yes i see they are still there after looking at some other systems.
The development 13.3.1 Proplus i was looking at seems to be missing several subkeys under the Current Version Key
I can confirm the keys are still present for DeltaV 14.3.0 on Server 2016.