[cisco-voip] COBRAS import PIN issue

[Ed Leatherman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140304/6780b346/attachment.html>