[cisco-voip] Moving LDAP Integrated Users across domains

Wed May 23 16:09:14 EDT 2018

To change the UID you have to delete all LDAP directories on 11.5 at least.
I deleted the directories the users went inactive then changed the UID then
tried a resync and just ended up with two user sets.

On Wed, May 23, 2018 at 3:06 PM, Brian Meade <bmeade90 at vt.edu> wrote:

> At what point did they go inactive?  As soon as you switched to email for
> CUCM UID?
>
> On Wed, May 23, 2018 at 4:01 PM, Josh Nordquist <joshnordquist at gmail.com>
> wrote:
>
>> Has anyone done this where the AD attributes are different between
>> domains besides email? We tried changing the CUCM UID for the LDAP accounts
>> to email then did the steps above but the current users just went inactive
>> and the new users with the email for UID did retain any access/devices/etc.
>>
>> We are thinking we may have to do a migration that doesn't include
>> carrying over PINS/passwords which is going to be hard to stomach.
>>
>>
>>
>> On Wed, May 23, 2018 at 11:26 AM, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>>
>>> I had to open a case once, on changing the domain in the JID for rosters
>>> in IM&P, because there is no intuitive way (I.e., GUI Administration) to
>>> change this.
>>>
>>> Here are the case notes for the corrective action that was taken:
>>>
>>> Actions taken:
>>> ===========
>>> + Anthony explained how he had already worked out that Outlook contacts were
>>> being prioritised for the IM address field when adding new contacts to
>>> Jabber
>>> + He exported the contact list from IM&P server and modified 300+
>>> entries that had incorrect JID and imported it back into IM&P
>>> + The remaining issue was that the old incorrect contact remained in
>>> the rosters table alongside the updated correct contact
>>> + We tested by adding an incorrect user to Anthony’s contact list and
>>> deleting it from the rosters table but the contact still displayed in
>>> Jabber
>>> + We found that restarting XCP Router, Presence Engine, SIP Proxy
>>> services and restarting Jabber client removed the contact
>>> + Applied this to all incorrect users
>>>
>>> ++ Stopped XCP Router
>>> ++ Stopped Presence Engine
>>> ++ Stopped SIP Proxy
>>> ++ Ran the SQL query: run sql delete from rosters where contact_jid like
>>> 'beforedomain.com’
>>> ++ 306 rows were deleted
>>> ++ Started XCP Router
>>> ++ Started Presence Engine
>>> ++ Started SIP Proxy
>>> ++ Started XCP Connection Manager
>>> ++ Started XCP Authentication Service
>>> ++ Restarted Anthony’s Jabber client to confirm contact was removed
>>>
>>> On Wed, May 23, 2018 at 10:46 AM Ryan Huff <ryanhuff at outlook.com> wrote:
>>>
>>>> Hello Mr. Loraditch!
>>>>
>>>>
>>>>
>>>> If you have on-prem IM and Presence, send a note about folks’
>>>> contact/buddy lists needing updated (or take care of it on the backend with
>>>> CSV files). My experience here though; its best, easiest and simpler if
>>>> that remain a user action/item post move.
>>>>
>>>>
>>>>
>>>> Alternatively, you could enable Flexible Jabber ID (FJID), so that the
>>>> “moved” users have reachability through both domains (Ex.
>>>> rhuff at beforedomian.com and rhuff at afterdomain.com). Though, it depends
>>>> on whether your AD migration strategy includes leaving the “E-Mail”
>>>> attribute in the AD profile for “rhuff at beforedomain.com” even though
>>>> the profile itself is in a OU at afterdomain.com. Although, since FJID
>>>> doesn’t work via MRA, it would only offer limited support if Collab Edge
>>>> exists in your environment.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> == Ryan ==
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *Anthony Holloway <avholloway+cisco-voip at gmail.com>
>>>> *Sent: *Wednesday, May 23, 2018 11:30 AM
>>>> *To: *Matthew Loraditch <MLoraditch at heliontechnologies.com>
>>>> *Cc: *cisco-voip at puck.nether.net
>>>> *Subject: *Re: [cisco-voip] Moving LDAP Integrated Users across domains
>>>>
>>>>
>>>>
>>>> I actually just did this recently, and it was pretty painless.  Here is
>>>> what I wrote in my plan for that step (high level):
>>>>
>>>>
>>>>
>>>> ---
>>>>
>>>>
>>>>
>>>> We’ll delete the two AD sync agreements in place, then add the two new
>>>> ones for the new domain, followed by updating the AD authentication to
>>>> point to the new domain.
>>>>
>>>>
>>>>
>>>> We’ll restart DirSync service on CUCM Publisher, and wait/watch for AD
>>>> accounts to come back from Inactive status to Active status.
>>>>
>>>>
>>>>
>>>> ---
>>>>
>>>>
>>>>
>>>> I would caution you if you have UCCX, to not login to it while you are
>>>> doing this change.  That means, either shut it down, shut tomcat down, or
>>>> just be really scary in your tone of voice when you tell everyone with
>>>> login rights to not login.  UCCX will delete any Agent which is Inactive at
>>>> the time you look at the Resource page.  I know from experience.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 23, 2018 at 10:17 AM Matthew Loraditch <
>>>> MLoraditch at heliontechnologies.com> wrote:
>>>>
>>>> Anyone ever done this? We are doing Domain migrations at a client
>>>> because of an acquisition. The users UPN will change, but not their
>>>> sAMAccountName but the LDAP agreement they are coming from will.
>>>>
>>>> Gonna test some dummy users today, but if anyone has any tips or known
>>>> gotchas, let me know!
>>>>
>>>>
>>>>
>>>> *Matthew Loraditch***
>>>>
>>>> *Sr. Network Engineer*
>>>>
>>>> p: *443.541.1518* <443.541.1518>
>>>>
>>>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>>>>
>>>>  |
>>>>
>>>> e: *MLoraditch at heliontechnologies.com*
>>>> <MLoraditch at heliontechnologies.com>
>>>>
>>>> [image: cid:image722348.png at C60F9430.10BEDD26]
>>>>
>>>> [image: Facebook] <https://facebook.com/heliontech>
>>>>
>>>> [image: Twitter] <https://twitter.com/heliontech>
>>>>
>>>> [image: LinkedIn]
>>>> <https://www.linkedin.com/company/helion-technologies>
>>>>
>>>> [image: Helion joins Automotive CX Summit]
>>>> <https://heliontechnologies.com/events/14th-annual-automotive-cx-summit-hosted-thought-leadership-summits/>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20180523/3428e840/attachment.html>