Cannot Bulk Import Existing AD/Exchange Mailboxes into 4.0(3)

[jerake]

Every time I try to run Bulk Import on a new install of Unity 4.0(3), it tells me that it "found another Unity Subscriber with the same DTMF access ID." I get the following errors in the CUBI log:

******************* Starting Pre-Import Check of Unified Subscribers ***********************

Tue Mar 09 16:29:51.164

Tue Mar 09 16:29:51.164 Started on March 09, 2004 at 16:29:51.

Tue Mar 09 16:29:51.164

Tue Mar 09 16:29:51.242 CDBAccess::IsDuplicate. Stored Procedure [sp_FindSubscriberByAlias]. Parameter = strAlias[TESTPH3035] returned [false] \DBAccess.cpp (line 317)

Tue Mar 09 16:29:51.242 CDBAccess::IsDuplicate. Stored Procedure [sp_FindCallHandlerByAlias]. Parameter = strAlias[ch_TESTPH3035] returned [false] \DBAccess.cpp (line 317)

Tue Mar 09 16:29:51.242 CDBAccess::IsDuplicate. Stored Procedure [sp_FindObjectbyExtensionIter]. Parameter = strDtmfAccessId[3035] returned [true] \DBAccess.cpp (line 311)

Tue Mar 09 16:29:51.242 (Error)

Tue Mar 09 16:29:51.242 Duplicate DTMF access ID (3035). Found another Unity Subscriber with the same DTMF Access ID.

Tue Mar 09 16:29:51.242 Subscriber record: CCMLAB,TEST PH,3035,TESTPH3035

Tue Mar 09 16:29:51.242 Error code: 0x8004030a. Method: CMULoader::PreCheckDtmfAccessID. \MULoader.cpp (line 1964)

Tue Mar 09 16:29:51.242 CCMLAB,TEST PH,3035,TESTPH3035

Tue Mar 09 16:29:51.257 CDBAccess::IsDuplicate. Stored Procedure [sp_FindSubscriberByAlias]. Parameter = strAlias[TESTPH4570] returned [false] \DBAccess.cpp (line 317)

Tue Mar 09 16:29:51.257 CDBAccess::IsDuplicate. Stored Procedure [sp_FindCallHandlerByAlias]. Parameter = strAlias[ch_TESTPH4570] returned [false] \DBAccess.cpp (line 317)

Tue Mar 09 16:29:51.257 CDBAccess::IsDuplicate. Stored Procedure [sp_FindObjectbyExtensionIter]. Parameter = strDtmfAccessId[4570] returned [true] \DBAccess.cpp (line 311)

Tue Mar 09 16:29:51.257 (Error)

Tue Mar 09 16:29:51.257 Duplicate DTMF access ID (4570). Found another Unity Subscriber with the same DTMF Access ID.

Tue Mar 09 16:29:51.257 Subscriber record: CCMLAB,TEST PH,4570,TESTPH4570

Tue Mar 09 16:29:51.257 Error code: 0x8004030a. Method: CMULoader::PreCheckDtmfAccessID. \MULoader.cpp (line 1964)

Tue Mar 09 16:29:51.257 CCMLAB,TEST PH,4570,TESTPH4570

Tue Mar 09 16:29:51.257 CDBAccess::IsDuplicate. Stored Procedure [sp_FindSubscriberByAlias]. Parameter = strAlias[TESTPH4569] returned [false] \DBAccess.cpp (line 317)

Tue Mar 09 16:29:51.273 CDBAccess::IsDuplicate. Stored Procedure [sp_FindCallHandlerByAlias]. Parameter = strAlias[ch_TESTPH4569] returned [false] \DBAccess.cpp (line 317)

Tue Mar 09 16:29:51.273 CDBAccess::IsDuplicate. Stored Procedure [sp_FindObjectbyExtensionIter]. Parameter = strDtmfAccessId[4569] returned [true] \DBAccess.cpp (line 311)

Tue Mar 09 16:29:51.273 (Error)

Tue Mar 09 16:29:51.273 Duplicate DTMF access ID (4569). Found another Unity Subscriber with the same DTMF Access ID.

Tue Mar 09 16:29:51.273 Subscriber record: CCMLAB,TEST PH,4569,TESTPH4569

Tue Mar 09 16:29:51.273 Error code: 0x8004030a. Method: CMULoader::PreCheckDtmfAccessID. \MULoader.cpp (line 1964)

Tue Mar 09 16:29:51.273 CCMLAB,TEST PH,4569,TESTPH4569

I can import existing AD accounts via the SA just fine; I can create new subscribers via CSV just fine, but I cannot import existing subscribers whatsoever. I've run SysCheck and all my permissions are fine...am I missing something obvious here?

This is on a test lab, and we are performing a new install (wiping out 3.1.5 and doing a fresh install of 4.0(3)) with 600+ existing AD/Exchange users next week...this is not something I want to run into on the production box.

Any help would be greatly appreciated -

TMH

[jerake]

I found this post:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.eeaa596

Which was very helpful - the DTMF access ID's that CUBI said were duplicates were listed in the SQL table, and when I used CUDLE, it did say they were global subscribers.

I also noticed that before I wiped out the previous Unity box, I did not delete the Unity Locations folder in AD (it said in the Uninstall Unity instructions that it was optional). I was poking around in Global Subscriber Manager and saw that all of the users that were not listed as subscribers on the Unity box were listed under the "Default (Primary)" listing of GSM. So, I went in, deleted the old Locations file, and imported the subscribers I was having problems with manually.

Still, odd. If anyone can shed some light on this, I'd appreciate it.

TMH

[lindborg]

Removing the Locations folder is optional, but removing the location objects in that folder is not - the dialog at the end of Uninstall lists a few objects you need to be sure to delete and that's one of the. The new uninstall I posted today actually deletes it for you in 4.0(2) installs and later to avoid this type of thing.

If you had done an uninstall of your previous system it shouldn't have behaved like you describe unless you did the "skip doh removal" stuff - I see this most often with sites that do a "yank and install" reinstall - the existing subscribers are still "Stamped" as Unity users and they are set to reference the primary location object (i.e. one of the objects in that locations folder). When you install the new Unity server the directory monitor finds all these users and locations in the directory and pulls them into the global tables - it assumes there is another Unity server installed it needs to know about. If you'd had them in a dialing domain (i.e. you configured a dialing domain name on the primary location object in the directory) it'll assume these are users that we can't have conflicting IDs for - hence the conflicts reported by CUBI.

However, you probably didn't have a dialing domain setup so I'm not sure if that's what was happening or not - it could be that the CUBI application is being too aggressive when checking for duplicates (i.e. not restricting itself to members of the dialing domain) - I'm not sure, I'd have to look at the system.

But regardless, that's why the IDs were in that table - the users were still stamped as subscribers in the directory - if you'd done a full uninstall they would have been cleaned of those properties and that wouldn't happen.

[jerake]

Thanks so much for your post - yeah, I went back through my uninstall procedures and realized that I did forget to delete the locations object; that's where I went wrong.

I'll do a full uninstall on the system again, this time deleting the locations object, and see if I get the same result.

Thanks for the explanation, though, it cleared a lot of things up for me.

TMH