[cisco-voip] Moving LDAP Integrated Users across domains

Wed May 23 16:06:48 EDT 2018

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/527cdf1b/attachment.html>