Moving users with Global Subscriber Manager - duplicate DTFM Access ID?

[jonathanwalton]

I'm trying to move users from a unity 4.2 server to our new unity 5 server using the Global Subscriber Manager tool. In the GSM tool, if I sort by “DTMF Access ID” field, I see some extensions(dtfm access IDs) are shared by multiple users, and that is preventing me from moving those users to the new server. It's sort of complicated, so I'll do my best to explain.

If I run the GSM tool from my unity4.2 server and have it connected to itself, the subscribers on unity4.2 look fine, I don't see any duplicate “Dtmf Access ID”.

If I run the GSM tool from my new unity5.0 server and have it connected to itself, but if I browse the old unity4.2 server, I see a lot of duplicate DTMF Access IDs.

This is keeping me from moving users from 4.2 to 5.0 because from 5.0's point of view, the extension is in use (if I add them manually through system administration, that's exactly what it tells me).

So I'm wondering if there is any way to have my unity 5.0 server see the DTMF Access IDs that my unity 4.2 server shows so I can move those users to the new server, or anything that might help.

For the users that unity5.0 are reading at the wrong extension, I notice the fields “ciscoEcsbuDtmfId” and “ciscoEcsbuTransferId” in their active directory accounts are showing the wrong extension, so I guess that's where unity5.0 GSM is getting it's info, but Unity 4.2 GSM is not.

I tried the “bunny” tool and even tried to remove subscriber properties from those accounts, but it seems to delete everything BUT the “ciscoEcsbuDtmfId” and “ciscoEcsbuTransferId” fields.

Any advice? Thanks in Advance

P.S. I'm running Active Directory with exchange 2003 in case that matters.

[Ginger Dillon]

Hi Jonathan -

Did you have some subscribers imported into the Unity 5.x system prior to establishing networking with the Unity 4.2 system? Once your Unity servers started replicating with AD and storing subscriber info about the other server in the UnityDb, I suspect that's when the duplicate conflict showed up. Prior to digital networking the two, your Unity subscribers had no knowledge of each other. The subscriber extension, like the Exchange alias, must be unique in your Unity digital network (Dialing Domain). Here is the 5.0 networking reference - http://www.cisco.com/en/US/docs/voice_ip_comm/unity/5x/networking/guide/ex/5xcunet020e.html#wp1050661

What is your intention with the Unity 5.x users, meaning did you want them to keep these extensions that the current 4.2 users have? If not, I would delete the 5.0 users from Unity that have duplicate DMTF ids. Wait for replication and then GSM move your 4.2 users over. The two ciscoEcsbu**** fields you mentioned get cleared when the user is deleted from Unity, so I'm not quite sure what is happening there. However, you could use ADSIEdit and remove the attribute from the users if needed. Once you get the 4.2 users moved, import the other users into the 5.x server with unique extensions.

Ginger

[jonathanwalton]

Thanks for the reply!

My unity5 server was brand new with no users on it. After networking them I have used GSM to move about 5 users over from unity4.2 to unity 5 as a test, and those went fine. Most users move without problems, but some users seem to sharing the DTMF Access ID. So I don't think it's the case of 2 databases coming together with some duplicate information since my unity 5 server was new and empty. But whats interesting, is from my unity5.0 server - running GSM that's "attached" to my unity4.2 server, it shows different information than what my unity4.2 sever shows when "attached" to itself. Whats stranger is the duplicate extension was a previous extension for one of the users. For instance, if UserA was at extension 1111, and he changes jobs and takes extension 2222, and everything was moved and worked fine, UserB replaces him at his first position and takes extension 1111. Now everything is working for both users fine, but when I look through GSM on my new unity server while "attached" to my old server I see both UserA and UserB at extension 1111. So if I then try and move UserB to the unity5.0 server, it won't let me because "1111" is already in use by UserA(even though UserA is no longer at 1111). That's basically what's happening, I hope that makes sense.

I'm trying to move all users (in small groups over the next few weeks) from unity4.2 to unity5.0 and then shutting down unity4.2 for good.

I think I might try the ADSIEdit tool to clear those fields (or edit them), but I'm going to hold off on that for a while in case someone comes to my rescue.

[Ginger Dillon]

Hi -

Was User A on the 4.2 server that previously had extension 1111 deleted and then recreated? Or was the information just changed in the Unity SA when the extension was changed to 2222? If you just edited the Unity subscriber's record, I suspect User A still has 1111 in the Transfer settings or Legacy mailbox fields. These fields can cause the same error message for duplicate extension. The 5.x server is getting this information from the user attribute data of User A in AD and populating its own database. If you are comfortable using SQL query on the 4.2 server, check out the Subscriber table in the UnityDb and run a query for the XferString; DtmfAccessID; and LegacyMailbox fields. Look for example in your query (where xferstring = '1111'). If you don't find anything here or are able to edit the user record with ADSIEdit, you can then try editing the Global Subscriber table on the Unity 5.x server and change the ObjectChangedID field for the user in question from whatever value it has currently to 0. This effectively forces a replication with AD and Unity pulls the user attribute info again into its database. You will need to query by display name or xferstring as there is no dtmfaccessid field in this table.

Ginger

[jonathanwalton]

Thanks for your reply, I believe this will help. I suspect it was changed and not deleted since UserA changed positions before I learned to delete and re-create. I will not be able to work on this anymore today, but I will try it tomorrow and let you know what I find. Thanks for your help!