Notifications
Clear all
Topic starter
Running Centricity 10.1.3.300
First we haven’t made any changes to either our Prod or Test system in quite a while this issue just popped up all of a sudden. As far as setup for accounts, we have the accounts set to synch with AD but not to automatically create the account.
The issue is as follows, UserA changes their password on the network and logs into Centricity just fine. Only when they try to go into the Chart Module does it pop up with an error “Error occurred in class GEHC.Centricity.Common.Framework.Threading.ExceptionHandlerBackgroundWorker, method OnRunWorkerCompleted”. When this error pops up the account is pretty much toast unless I perform the work around I’ve found…meaning it won’t eventually start working again after a certian time period.
The workaround I've been using is to have them log out of Centricity and I go into Administration and remove them from any group membership and simply add them back. After that they can go back into the program without issue. While its a quick an easy fix, we can't have our accounts breaking anytime a user changes their password.
We originally just had the main AD.domainname.org in the security settings of the server and we also tried to add the AD servers indiviually in the 4 slots in server setup as well in our last downtime.
Has anyone run into anything like this before?
Posted : December 20, 2012 12:49 am
you need to use the Server Setup and run the utility to re-sync your domain security with CPS.
Posted : December 21, 2012 12:07 am
Topic starter
You talking about about Server Setup > Utilities > Security > ? What specifically would you do to re-synch the domain secutiry with CPS?
Posted : December 21, 2012 3:54 am
derekhaneman said:
You talking about about Server Setup > Utilities > Security > ? What specifically would you do to re-synch the domain secutiry with CPS?
1. Open server setup.
2. Click on Advanced Setup Options
3. Select Utilities > Next
4. Next >
5. Input SQL Server Name, User Name (sa), Password
6. Select your CPS Database
7. Security
8. Now, you should see Active Directory as a security type on top
9. Make sure you domain is correct
10. Login Name should be administrator
11. Then input the new administrator password
12. Re-enter administrator password to confirm
13. Click Verify Account
14. Should pass, then click Finish, that should take care of it
Posted : December 24, 2012 12:35 am
Topic starter
Finally had time to do this and it only fixes the issue for about an hour. Same with a Server reboot, that will fix the issue for about an hour.
GE is trying to point figures at our AD replication or AD in general but that doesn't make sense. We have a ton of other systems, Cerner, PACS/RIS, and many others in our environment and not a single one has had issues with AD.
The issue only came up after we upgraded to CPS10. If it was in fact an AD issue I don't think the password would even work to log into CPS..but it does. Logging in works fine, it takes the new password just fine.
Any other ideas? Could it be a DB thing that is forced to sync when I manually change any account details within CPS? I can go into an account with the problem and unchecked any box and recheck it and that will fix the issue for that account.
Posted : January 9, 2013 2:26 am
Hi Deb,
We've seen this issue as well and GE Support reported it as a product defect and gave us a product defect SPR number. We support multiple databases on 10.1.3 but only a couple have reported this issue (we're still investigating that part).
We have tested the individual usre workaround (in CPS Administration) but have not yet had a chance to test the Server Setup potential workaround.
We have requested follow up from our GE account manager on this issue to better understand GE's priority in resolving this product defect.
Posted : January 9, 2013 2:40 am
After reading your response, it is starting to make a bit since. We do not change our password besides one year, so i do the resync then. So we do not run into that problem. We are a smaller office, and do not have to have a strict policy on password changing. But I can see how this can effect you guys.
Posted : January 9, 2013 2:44 am
Topic starter
We are part of a Medium size Hospital, so we have a reasonably strict policy on a a 120 day cycle.
I'm waiting to hear back from GE to see if we can get our issue escalated as well. I will update this post as soon as I have some more info.
Posted : January 9, 2013 2:48 am
thanks, sorry, i meant once a year
Posted : January 9, 2013 2:50 am
I know what the issue is though. If you go to your database, and go the Security and then Logins, see all those users with W then numbers, those are automated logins created to work with the Charting part of CPS. And when users change their AD password, it doesn't change their assigned W#### password, so that is why you get that error. It stinks I know. But they need to create an automated process to check it during login and if it is successful, to update that password if it is different.
Posted : January 9, 2013 2:53 am
Topic starter
Do you know any way to tie those W### to a certain account? I want to find my test account and document the hashed/encrypted password it shows..change the password on the network so it breaks. I bet the encrypted line doesn't change, then I can do my work around that forces the update and I bet it WILL change.
If I can show that, maybe they will be a little more eager in developing a fix.
Posted : January 9, 2013 3:05 am
Yes,
SELECT LoginName, ServerID
FROM iLicUserInfo
ORDER BY LoginName ASC
Posted : January 9, 2013 3:08 am
Or if this helps
SELECT LoginName, ServerID, (SELECT password FROM sys.syslogins WHERE sys.syslogins.name = iLicUserInfo.ServerID) As Password
FROM iLicUserInfo
ORDER BY LoginName ASC
Posted : January 9, 2013 3:32 am
Topic starter
That was perfect, thanks. I was able to reproduce the problem, the database is not updating when the password is changed. Just waiting on a call back from GE now.
Posted : January 9, 2013 3:36 am
We are having this issue also! Thanks for the info and please let us know what GE says. We currently are set to sync with AD, but not all passwords seem to be synchronizing correctly.
Posted : January 9, 2013 4:03 am
Page 1 / 3
Next
