Suddenly we started receiving this error on one of our operator workstations (running DV 11.3) when we attempt to bring up process history:
"Login failed. The login is from an untrusted domain and cannot be used with windows authentication. Invalid connection string attribute. Possible reasons include: The Event chronicle is not enabled; the data server doesn't exist or can't be reached; the dataset does not exist; or the workstation has not been assigned the event chronicle license"
Several notes: We have a workgroup network architecture. The Pro Plus serves the Event Chronicle. The App Station serves the continuous historian. I attempted to run workstation configuration, using a freshly generated worklist configuration file exported from Pro Plus, and re-downloaded the workstation & setup data afterwards. It downloads fine & shows alarms, but no history. All other workstations display history. I have set the server names appropriately. Since upgrading about a year and a half ago, we've had this problem on other workstations, but simply ran workstation configuration & that resolved it. Why does this problem occur spontaneously and how does one correct it? Why did running configuration not correct it this time? I am sure DeltaVAdmin password is set correctly. This workstation cannot connect to EITHER Pro Plus (Event Chronicle) OR to App Station (historical data archives), as I tried creating a new chart and event list and both had the error.
Also, since the upgrade, on the center of process history view dispalys, reads 'Evalutating ProEssentials! www.gigasoft.com" appears. Apparently gigasoft provides the charting module, but as a licensed DeltaV user, why am I seeing this message? Finally, I'm wondering if something is wrong with the computer, a few weeks back it displayed a gray screen & horn wasn't audible, but then problem went away.
In reply to Deb Colclazier:
Frank,
Emerson GSC would be the right place to get help in trouble shooting something like this. They have a collection of experiences to draw from in the CTS databse, with validated results in cases where they've reproduced the propblem. Also, your issue gets logged and if needed, elevated to a higher level attention.
I found one of their calls that showed the exact same error message you describe.
It relates to the connection to the EJOURNAL which is a SQL database. In this case, the user profile was recreated on the Workstation, and that fixed the issue. They concluded the User Profile was corrupted. Corrupted is such a harsh word, but basically means they don't know what went wrong in the profile.
Does this happen with all users logged in on this workstation? Are you logging into Windows and DeltaV with the same user? The windows user's privileges take over when accessing applications in the system, so the login fail relates to the windows user.
The LOGON FAILURE indicates to me that you are making it to the targeted SQL server, so I don't think this is related to a Failed Switch. But you can Ping the other nodes on the primary and secondary and even third network if exists to confirm network connections are good.
Are you launching a CHART with Events in PHV? Try just a CHART. That may only try to connect to the Continuous Historian. If that works, try an Event View only. If that fails, the issue would be with the EJournal.
The CTS call I found indicated the issue was corrected by recreating the user. Since you're in a workgroup, accounts and passwords must match on both machines. Can you browse to shared folders or add mapped network drives of the Ejournal node from the Workstation? Can you launch PHV from other workstations with the same User account logged into Windows and DeltaV? That would indicate if the issue is with the Account on the workstation or security settings at the Ejournal server.
The CTS calls also talked about some DB_OWNER security rights and membership roles relating to the Built In/USER. I'm not too familiar with SQL security, so I don't want to mislead you there. If the above points you to the SQL connections, I'd suggest you call the GSC.
Andre Dicaire
In reply to Andre Dicaire:
Thanks for the tips, we renewed Foundation Support recently, I was able to resolve the issue on one workstation by running servpwd and/or running a fix I was sent DeltaV_113X_TFS51960_Utility.zip -- not sure which since I did both. On the second workstation, problem was resolved when I re-entered Operator password on Pro Plus. That made NO sense, but immediately remedied problem. We've had the same operator password on all the other workstations and no one had changed it, but it is consistent with the corrupt account problem you describe. So if it recurs, I will try deleting entirely and re-creating 'Operator'. I knew to try another account but did NOT realize I should log into Windows with it (GSC was not as clear as you in their directions), so your message is most helpful if this problem recurs. From what you are describing, it sounds like these database connections use Windows security. Also I still had at least one issue; Pro Plus started looking for events on a server called "MANAGEMINT". I reset default data server & it then worked as well. I do not understand why it [DeltaV PHV] *ever* changes the data server, is there a way to fix this/make it constant? We have a small system, only one server for Events, one for History. I understand to create Events or Chart to test connectivity to either Events of continuous history. I also need to double check that I didn't fix the problem, merely by logging into Windows as 'Administrator' and into DeltaV as 'Operator within DeltaV desktop, which is quite likely.
In reply to Frank Seipel:
Regarding your comment: "I do not understand why it [DeltaV PHV] *ever* changes the data server, is there a way to fix this/make it constant?"
See the following discussion I posted about enforcing dataservers.
community.emerson.com/.../620.aspx
A system could have multiple dataservers, and you may wish only certain workstations to connect to certain servers. Additionally, the setting is user profile based, not just workstation based. Enforcing a group policy (or a local policy in the case of a workgroup) can smooth this over and always set the right data server.