[cisco-voip] COBRAS import PIN issue

[Justin Steinberg]

I was also using cobras.
On Mar 4, 2014 8:24 AM, "Ed Leatherman" <ealeatherman at gmail.com> wrote:

> So going in and setting do not expire on the pin policy did not fix the
> issue when I tried to re-import. I ended up with the same warning, along
> with a new error:
> failed updaging user's PIN credentials in UpdatePhonePin <snip> The
> credential matches a previous credential for this user.
>
> Possibly this is the hash issue then where the PIN was actually restored
> but versions use a different hash function? OR the users that reported the
> issues were doing something wrong?
>
>
>
> On Tue, Mar 4, 2014 at 8:09 AM, Ed Leatherman <ealeatherman at gmail.com>wrote:
>
>> 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 <jsteinberg at 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" <jsteinberg at 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" <btalley at 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 <ealeatherman at 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 at puck.nether.net
>>>>> > https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>
>>
>>
>> --
>> Ed Leatherman
>>
>
>
>
> --
> Ed Leatherman
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140304/bc087505/attachment.html>