Justin, Thanks for the insight. Was this a straight-up upgrade rather than an cobras import? I'm starting to think I need to scrap the idea of using cobras and do a swing server/"normal" instead if this turns out to be the issue.
On Mon, Mar 3, 2014 at 11:24 PM, Justin Steinberg <jsteinb...@gmail.com>wrote: > Just went back through my notes for that upgrade and it was a 7.1.3 to > 8.6.2 upgrade. > > Just speculating, but maybe the users that were impacted by my upgrade had > last changed their pin on 7.0x. > On Mar 3, 2014 11:12 PM, "Justin Steinberg" <jsteinb...@gmail.com> wrote: > >> I ran into this issue once and tracked it down to the time when the user >> had last changed/set their pin. In my situation only about 20% of the >> users were affected. The other 80% were fine. >> >> I tracked the issue down by running a user data dump, and all the users >> that had reported the problem had the last pin changed time of much older >> than everyone else. In my case, the authentication rules on this system >> did not expire the pins, so some users had the same pins for years. >> >> Instead of rolling back, I opted to run a bulk pin reset to the default >> for these users and then sent a mass email to all of them telling them that >> their PIN had been reset. >> >> If you don't expire your pins this might be your problem. While I didn't >> try this, you could go into the current 7 system and set the password >> policy to force users to change their pin on the next login and let >> everyone update their pin before you run the upgrade again. >> >> I believe the aggravating factor is that the users in question last >> changed their pin on an older version of connection that used a different >> encryption type, that is not supported by v9. >> On Mar 3, 2014 8:57 PM, "Bill Talley" <btal...@gmail.com> wrote: >> >>> I interpreted the issue as being from or to version 7.0 as it also >>> suggests upgrading to 7.1.3 prior (IIRC) to using COBRAS. >>> >>> Sent from an Apple iOS device with very tiny touchscreen input keys. >>> Please excude my typtos. >>> >>> > On Mar 3, 2014, at 5:48 PM, Ed Leatherman <ealeather...@gmail.com> >>> wrote: >>> > >>> > Hello! >>> > >>> > This weekend I exported some voice mail accounts from Connection 7.0.2 >>> and imported them into 9.1(2) using COBRAS tool. >>> > >>> > When I did this, the users were not able to sign into their mailbox, >>> as if PIN was changed. >>> > >>> > Retracing my steps, I did have this in the COBRAS log during the >>> import: >>> > [Thread 001], [14/03/02 08:51:34], Updating subscriber phone >>> PIN from Connection backup >>> > [Thread 001], [14/03/02 08:51:34], (warning) unable to find mapping >>> for MDBObjectId=051ee60c-4e21-42f6-bea4-9f845e6e96c8, >>> ObjectType=CredentialPolicy in GetNewObjectId on >>> DirectoryBackupDatabaseFunctions.cs >>> > >>> > Unfortunately I had did not have a whole lot of time to troubleshoot >>> on live 9.1 server - weather emergency dictated that I swing them back the >>> 7.0 version asap so that users could update various greetings and info >>> prompts. Right now i'm working with the 9.1 VM in a isolated network. >>> > >>> > My hypothesis is that the old system had PIN set to not expire, and >>> the new system has PIN set to expire in 120 days - and this somehow caused >>> the PIN to not get updated somehow. I can't see any other difference >>> related to credential policy. Anyone know if this is the case or why PINs >>> might not have carried over, or if I'm barking up the wrong tree? >>> > >>> > I had read that there was some issues importing PINs into version 7.0, >>> but exporting from 7.0 TO a version 7.1.3+ was not cited as a problem. >>> > >>> > Thanks! >>> > >>> > >>> > -- >>> > Ed Leatherman >>> > _______________________________________________ >>> > cisco-voip mailing list >>> > cisco-voip@puck.nether.net >>> > https://puck.nether.net/mailman/listinfo/cisco-voip >>> >>> _______________________________________________ >>> cisco-voip mailing list >>> cisco-voip@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >> -- Ed Leatherman
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
