Notifications
Clear all
Thought I'd update this thread after our issue was resolved. Not sure if this will fix your issue or not. We had to run the server setup utility with the instructions above on both the cps server and the cspsl servers. Once we did this passwords started synchronizing instantly.
Posted : January 10, 2013 9:16 pm
Topic starter
Make sure to keep an eye on it and test it for a few days. That briefly fixed out issues as well, but it only lasted for a few hours 48 hours at most.
Posted : January 11, 2013 12:24 am
We are planning to upgrade to 10.1.3.3 soon. I was wondering if this is still an issue or if there is a fix for it. I haven't able to replicate this issue on our test server but just in case. Thanks.
Posted : January 23, 2013 3:34 am
Topic starter
We are still having the issue and we actually had two users today who ran into the problem. I'm still going back and forth with GE with the issue.
It seems to be stumping them and they really don't want to look into the database as the problem. All the troubleshooting has been focused around AD Replication our our Work Stations setup. So far we have been able to rule out everything they have suggested.
I will post any updates if we get any movement on this.
Posted : January 23, 2013 3:46 am
The only issue we've run into regarding the conversion to AD handling the passwords is that if users enter the wrong password into CPS it locks them out. One bad password in CPS locks their AD account out. I've got an open ticket and nothing we've done has resolved the issue.
Posted : January 23, 2013 3:56 am
We escalated this to our account manager and have been working with development to show them what has been going on. Just yesterday they were able to reproduce the steps that we had shared with them. I do not currently have an SPR product defect number.
Posted : January 23, 2013 3:58 am
lic08 said:
We are planning to upgrade to 10.1.3.3 soon. I was wondering if this is still an issue or if there is a fix for it. I haven't able to replicate this issue on our test server but just in case. Thanks.
Hi @lic08 - you'll want to check on the following:
-Are you set up for Active Directory syncing?
-What is your organization's group policy for password expiration
Posted : January 23, 2013 4:09 am
Yes we have it setup for AD and 120 days for password expiration
Posted : January 23, 2013 4:19 am
Hello all -
Just an FYI that the SPR that we received from engineering for the Active Directory-based password expiration issue was SPR 53069. Currently they are reporting that no other customers than us have been tied to this SPR, so you may want to provide this SPR to support if you're still working with them on password expiration issues on CPS 10.1 SP3 and Active Directory. Additional customers tied to this SPR will help to increase the priority for a resolution by development.
--Lauren
Posted : January 29, 2013 11:21 pm
Topic starter
I was out of town last week but It looks like we are tied to SR#53069 as of 1/29/2013. Got an email from one of the techs explaining the specifics of the issue. for those who are interested I will post that below.
"Currently I have a software problem report # 53069 on this issue from GE. They have been able to reproduce the issue and it is in the hands of development to implement a fix in a future service pack of the application. It seems that the JBoss service layer is doing some LDAP caching. GE has advised that beyond what you have found as a workaround, they have observed that *sometimes* an affected user need only close the error dialog, reset the CPS application (using the Reset CPS utility from the programs menu) and log in again."
Luckily the work around is easy enough I was able to document the process and hand it off to our internal helpdesk/servicedesk for the larger organization. CPS users at our hospital now have a process that when they change their Network password they just call the helpdesk and have them do a quick change on their account (add a middle initial or something) and its fixed. Still looking forward to this being fixed in a patch but at least its something.
- Derek
Posted : February 4, 2013 5:12 am
Hi Derekhaneman,
when you say a quick change on their account, do you mean in cps administration users management? how is that working for you?
Thanks
Posted : February 22, 2013 3:02 am
Topic starter
Yeah exactly. I outlined a process for our Helpdesk should they get a call, the Helpdesk employee does the following.
- Log into CPS
- Go to the Administration Module
- Drill down to the User Management and find the user having the issue
- Edit any detail in the users account attributes such as a Middle Initial, Address, Organization., etc, etc. example - (I usually tell them add a middle initial click ok then remove the initial).
Note: I created a security group for Helpdesk staff that only has access to update account attributes and not more more.
Posted : February 22, 2013 6:32 am
does that fix the issue until the next password update?
Posted : February 22, 2013 6:34 am
Topic starter
Sorry I forgot to type that part out.
Yes, it fixes it. As soon as we update that area of the account it fixes the account until the next password change is completed. Our Hospital users are on a 120 password cycle, so its not to bad.
Posted : February 22, 2013 6:41 am
We get this problem fairly regularly (CPS 10.1.3.300 and 10.1.3.312), but not on every user. Our workaround is to uncheck "Chart Contributor", save, and reapply the "Chart Contributor" settings.
I was doing some testing today and maybe someone will be able to verify the same findings.
I noticed some of our users logins were camel case and some were all lowercase. If I change the username exhibiting the problem in Centricity to all lowercase, after a password change the 1st login will crash centricity with a system error right after sign in. But, afterwards, you can log into Centricity and it will operate normally.
I dont know if this means anything, but I did not have to reset the chart contributor setting. The problem "resolved" itself...
Posted : June 7, 2013 12:39 am
